摘要:當(dāng)接口相應(yīng)時(shí)間明顯超過(guò)其歷史平均響應(yīng)時(shí)間時(shí),動(dòng)態(tài)降低此接口的可用線程數(shù)量。文章中給出的解決方案增大工作線程數(shù)降低超時(shí)時(shí)間拆分接口和服務(wù)層治標(biāo)不治本。
跨公網(wǎng)調(diào)用第三方接口的服務(wù)層的思考 問(wèn)題
前日有幸拜讀了架構(gòu)師之路的58沈劍所寫(xiě)的 跨公網(wǎng)調(diào)用的大坑與架構(gòu)優(yōu)化方案 一文。文中,作者提到了一個(gè)很值得思考的問(wèn)題:
如何設(shè)計(jì)一個(gè)為內(nèi)部系統(tǒng)提供跨公網(wǎng)第三方接口調(diào)用的服務(wù)層,才能避免因部分接口問(wèn)題導(dǎo)致整體失效的問(wèn)題?問(wèn)題的具體描述請(qǐng)參見(jiàn)原文。
在看到問(wèn)題后,我先試著想了幾個(gè)解決方案。
我的解決方案對(duì)于每次接口調(diào)用,都記錄其響應(yīng)時(shí)間,并對(duì)服務(wù)層內(nèi)每個(gè)接口求出其平均響應(yīng)時(shí)間。
對(duì)于每個(gè)接口,根據(jù)其平均調(diào)用時(shí)間,設(shè)置其可用工作線程數(shù)的閾值,保證當(dāng)接口出現(xiàn)異常時(shí),不會(huì)影響到所有工作線程。
當(dāng)接口相應(yīng)時(shí)間明顯超過(guò)其歷史平均響應(yīng)時(shí)間時(shí),動(dòng)態(tài)降低此接口的可用線程數(shù)量。
當(dāng)接口的異常狀態(tài)持續(xù)一段時(shí)間仍未恢復(fù)時(shí),停止為該接口提供服務(wù),改用對(duì)進(jìn)行輪詢(xún)的方式,來(lái)保證當(dāng)其恢復(fù)可用后可以迅速恢復(fù)對(duì)該接口的服務(wù)。
文章中給出的解決方案增大工作線程數(shù)、降低超時(shí)時(shí)間、拆分接口和服務(wù)層(治標(biāo)不治本)。
對(duì)于可以接受非實(shí)時(shí)數(shù)據(jù)的內(nèi)部系統(tǒng)調(diào)用方提供異步代理,對(duì)其屏蔽具體細(xì)節(jié)。即緩存外部接口調(diào)用的返回結(jié)果,對(duì)內(nèi)部調(diào)用方直接提供對(duì)應(yīng)的緩存結(jié)果,并定期調(diào)用外部接口來(lái)完成數(shù)據(jù)的更新。
對(duì)于可以冗余的外部接口,保證其冗余性,在主接口調(diào)用失敗后迅速將服務(wù)轉(zhuǎn)移至備份接口。
對(duì)于是向外部接口推(主動(dòng)同步)數(shù)據(jù)而不是拉數(shù)據(jù)的業(yè)務(wù)場(chǎng)景,先同步寫(xiě)本地?cái)?shù)據(jù)庫(kù),本地寫(xiě)成功后對(duì)內(nèi)部調(diào)用方返回調(diào)用成功的消息,其后異步地向第三方接口推數(shù)據(jù)。
我對(duì)自己的反思解決方案局限在一個(gè)具體的技術(shù)實(shí)現(xiàn)思路上(限流、動(dòng)態(tài)規(guī)劃),考慮太窄,沒(méi)有結(jié)合實(shí)際的業(yè)務(wù)需求分析可行性。目前還停留在解決具體技術(shù)問(wèn)題的階段,看山只是山,應(yīng)該努力培養(yǎng)自己的宏觀思維。
我提出的解決方案需要直接操作服務(wù)容器的線程調(diào)度,難度大,技術(shù)可行性也未知。
因?yàn)槲业挠?jì)算機(jī)網(wǎng)絡(luò)相關(guān)從業(yè)背景,我在思考過(guò)程中受到各種網(wǎng)絡(luò)協(xié)議的設(shè)計(jì)思路影響很大(比如IP SLA探針、GLBP中的各種權(quán)重判斷等),這點(diǎn)我認(rèn)為在我的程序設(shè)計(jì)思維中可能會(huì)讓我持續(xù)受益。雖然現(xiàn)在已經(jīng)不從事網(wǎng)絡(luò)相關(guān)行業(yè)了,但是也應(yīng)該保持住網(wǎng)絡(luò)工程師對(duì)于系統(tǒng)穩(wěn)定性、可用性、擴(kuò)展性的不懈追求。
文章版權(quán)歸作者所有,未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址:http://systransis.cn/yun/11838.html
摘要:負(fù)載均衡器又分為四層和七層負(fù)載均衡器,顧名思義,四層的工作在協(xié)議棧上,通過(guò)修改請(qǐng)求報(bào)文的源目的地址和源目的端口來(lái)轉(zhuǎn)發(fā),比如,一個(gè)主機(jī)對(duì)應(yīng)一個(gè)域名,適用于每秒超過(guò)一萬(wàn)的業(yè)務(wù)。每一次變更都是一次發(fā)布,每一次發(fā)布都是一個(gè)獨(dú)立的鏡像啟動(dòng) showImg(https://segmentfault.com/img/bVbvtgW?w=1080&h=720); 以一個(gè)經(jīng)典問(wèn)題拋磚引玉,當(dāng)用戶(hù)在瀏覽器...
摘要:接入層作用一的聚合。接入層作用二服務(wù)發(fā)現(xiàn)與動(dòng)態(tài)負(fù)載均衡既然統(tǒng)一的入口變?yōu)榱私尤雽?,則接入層就有責(zé)任自動(dòng)的發(fā)現(xiàn)后端拆分,聚合,擴(kuò)容,縮容的服務(wù)集群,當(dāng)后端服務(wù)有所變化的時(shí)候,能夠?qū)崿F(xiàn)健康檢查和動(dòng)態(tài)的負(fù)載均衡。 此文已由作者劉超授權(quán)網(wǎng)易云社區(qū)發(fā)布。 歡迎訪問(wèn)網(wǎng)易云社區(qū),了解更多網(wǎng)易技術(shù)產(chǎn)品運(yùn)營(yíng)經(jīng)驗(yàn)。 這個(gè)系列是微服務(wù)高并發(fā)設(shè)計(jì),所以我們先從最外層的接入層入手,看都有什么樣的策略保證高并發(fā)。...
摘要:接下來(lái)繼續(xù)介紹三種架構(gòu)模式,分別是查詢(xún)分離模式微服務(wù)模式多級(jí)緩存模式。分布式應(yīng)用程序可以基于實(shí)現(xiàn)諸如數(shù)據(jù)發(fā)布訂閱負(fù)載均衡命名服務(wù)分布式協(xié)調(diào)通知集群管理選舉分布式鎖和分布式隊(duì)列等功能。 SpringCloud 分布式配置 SpringCloud 分布式配置 史上最簡(jiǎn)單的 SpringCloud 教程 | 第九篇: 服務(wù)鏈路追蹤 (Spring Cloud Sleuth) 史上最簡(jiǎn)單的 S...
摘要:通常情況下,偽都是基于第一層次與第二層次設(shè)計(jì)的。為了解決這個(gè)版本不兼容問(wèn)題,在設(shè)計(jì)的一種實(shí)用的做法是使用版本號(hào)。例如,建議第三位版本號(hào)通常表示兼容升級(jí),只有不兼容時(shí)才需要變更服務(wù)版本。 原文地址:梁桂釗的博客 博客地址:blog.720ui.com 歡迎關(guān)注公眾號(hào):「服務(wù)端思維」。一群同頻者,一起成長(zhǎng),一起精進(jìn),打破認(rèn)知的局限性。 有一段時(shí)間沒(méi)怎么寫(xiě)文章了,今天提筆寫(xiě)一篇自己對(duì) API 設(shè)...
摘要:通常情況下,偽都是基于第一層次與第二層次設(shè)計(jì)的。為了解決這個(gè)版本不兼容問(wèn)題,在設(shè)計(jì)的一種實(shí)用的做法是使用版本號(hào)。例如,建議第三位版本號(hào)通常表示兼容升級(jí),只有不兼容時(shí)才需要變更服務(wù)版本。 原文地址:梁桂釗的博客博客地址:http://blog.720ui.com 歡迎關(guān)注公眾號(hào):「服務(wù)端思維」。一群同頻者,一起成長(zhǎng),一起精進(jìn),打破認(rèn)知的局限性。 有一段時(shí)間沒(méi)怎么寫(xiě)文章了,今天提筆寫(xiě)一篇...
閱讀 1123·2021-09-22 15:19
閱讀 1757·2021-08-23 09:46
閱讀 2262·2021-08-09 13:47
閱讀 1433·2019-08-30 15:55
閱讀 1441·2019-08-30 15:55
閱讀 1998·2019-08-30 15:54
閱讀 2829·2019-08-30 15:53
閱讀 735·2019-08-30 11:03