資訊專欄INFORMATION COLUMN
摘要：引發(fā)什么問題了呢最核心的問題是香港處在國際網(wǎng)絡環(huán)境，訪問大陸服務器時經(jīng)常會出現(xiàn)網(wǎng)絡抖動的現(xiàn)象，非常無解。其中，負責配置，則負責執(zhí)行即真正發(fā)送請求。
挖洋貨這項目，因為沒有公司的名頭，也就無法備案，所以前端機放在阿里云香港ECS，另配一臺阿里云杭州ECS來跑crontab——執(zhí)行爬蟲、保存圖片到阿里云OSS等。最近覺得杭州ECS有點多余了（原本還有個杭州RDS的，統(tǒng)一搬到香港RDS了），打算撤掉，就把杭州ECS上的crontab全部搬回香港ECS來跑，這下就引發(fā)不少問題了。
引發(fā)什么問題了呢？最核心的問題是香港ECS處在國際網(wǎng)絡環(huán)境，訪問大陸服務器時經(jīng)常會出現(xiàn)網(wǎng)絡抖動的現(xiàn)象，非常無解。具體一點來說，比如香港ECS向阿里云杭州open search（open search沒有香港節(jié)點呀親 ╥﹏╥...）查詢的時候，經(jīng)常報錯；又比如香港ECS抓到圖片后上傳杭州OSS（OSS是有香港節(jié)點，問題是沒有圖片處理的服務啊，你們說這不是坑死人嗎），慢是其次，經(jīng)常卡住一段時間后才報錯，這使得上傳的效率極其低下（我會告訴你就因為這個原因，積壓了好幾千爬回來的商品等著上傳圖片才能上架嗎）。
open search的問題還是很好解決的，SDK有提供超時的配置，我把超時限制設大了一點（5秒），基本上就不會報錯了。
而OSS的SDK根本沒有提供這方面的配置，為了解決這個問題，我決定深入到這SDK來修改源碼。
OSS的SDK是通過php-curl來請求api的，經(jīng)調查后，我發(fā)現(xiàn)此SDK有個名為requestcore.class.php的文件中定義了一個RequestCore類，很明顯，這個類就是負責發(fā)送請求的。其中，prep_request()負責配置curl，send_request($parse = false)則負責執(zhí)行curl（即真正發(fā)送請求）。
首先來看看prep_request()，其中包含兩個php-curl的兩個超時配置：CURLOPT_TIMEOUT以及CURLOPT_CONNECTTIMEOUT
curl_setopt($curl_handle, CURLOPT_TIMEOUT, 5184000);
curl_setopt($curl_handle, CURLOPT_CONNECTTIMEOUT, 120);
CURLOPT_TIMEOUT好理解，就是整個curl請求過程（http request & response）的超時限制，以秒為單位，設置為0則無限制。
CURLOPT_CONNECTTIMEOUT比較難理解，目前確認的是，這是curl請求過程中的一小部分，因此必須要設得比CURLOPT_TIMEOUT小，不然CURLOPT_TIMEOUT無意義。網(wǎng)上的資料是這么說的：
CURLOPT_CONNECTTIMEOUT 在發(fā)起連接前等待的時間，如果設置為0，則無限等待。
這個發(fā)起連接前等待的時間比較模糊，我傾向于這指的是完成TCP三次握手過程前所耗費的時間，或者換句話說，TCP三次握手的整個過程必須要在CURLOPT_CONNECTTIMEOUT內完成，否則就超時。TCP三次握手無法在指定時間內完成表示服務器正處在繁忙/奔潰的狀態(tài)或網(wǎng)絡異常，這正符合本文所提到的場景。
基于這一猜想下，我把CURLOPT_CONNECTTIMEOUT設成3秒：
curl_setopt($curl_handle, CURLOPT_CONNECTTIMEOUT, 3);
如此，就不需要在網(wǎng)絡抖動的時候等待2分鐘（SDK設定的CURLOPT_CONNECTTIMEOUT是120秒）才報錯了。
PS:如果想要設置超時時間少于1秒，需要用到CURLOPT_TIMEOUT_MS，但此配置據(jù)鳥哥說有bug，未測試，留個心眼：《Curl的毫秒超時的一個”Bug”》
文章版權歸作者所有，未經(jīng)允許請勿轉載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉載請注明本文地址：http://www.ezyhdfw.cn/yun/21271.html
摘要：優(yōu)雅的服務降級微服務架構最大的優(yōu)點之一就是當組件出現(xiàn)故障時，能隔離這些故障并且能做到優(yōu)雅地服務降級。 本文首先介紹微服務架構存在的風險，然后針對如何避免微服務架構的故障，提出了多種有效的微服務架構中的方法和技術，其中例如服務降級、變更管理、健康檢查和修復、斷路器、限流器等。 目錄 1、微服務架構的風險 2、優(yōu)雅的服務降級 3、變更管理 4、健康檢查和負載均衡 5、自我修復 6、故障轉移...
摘要：優(yōu)雅的服務降級微服務架構最大的優(yōu)點之一就是當組件出現(xiàn)故障時，能隔離這些故障并且能做到優(yōu)雅地服務降級。 本文首先介紹微服務架構存在的風險，然后針對如何避免微服務架構的故障，提出了多種有效的微服務架構中的方法和技術，其中例如服務降級、變更管理、健康檢查和修復、斷路器、限流器等。 目錄 1、微服務架構的風險 2、優(yōu)雅的服務降級 3、變更管理 4、健康檢查和負載均衡 5、自我修復 6、故障轉移...
摘要：微服務架構的風險微服務架構將應用程序邏輯移動到服務，并使用網(wǎng)絡層在它們之間進行通信。在微服務架構中，服務依賴于彼此。您始終只能部署其中一個，并且在驗證新版本是否符合預期之后才，將負載均衡器指向新的。 [譯] 設計一個容錯的微服務架構 摘要：本文屬于原創(chuàng)，歡迎轉載，轉載請保留出處：https://github.com/jasonGeng88/blog 原文地址 https://blog....
閱讀 2979·2021-11-24 09:39
閱讀 2551·2019-08-30 15:53
閱讀 3082·2019-08-30 13:47
閱讀 1391·2019-08-30 12:50
閱讀 1538·2019-08-29 16:31
閱讀 2698·2019-08-29 13:14
閱讀 1637·2019-08-29 10:55
閱讀 861·2019-08-26 13:32
