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