一個(gè)高可用的接口是該考慮哪些內(nèi)容

前言

作為一個(gè)后端研發(fā)人員，開(kāi)發(fā)服務(wù)接口是我正常不過(guò)的工作了，這些接口不管是面向前端 HTTP 或者是供其他服務(wù) RPC 遠(yuǎn)程調(diào)用的，都繞不開(kāi)一個(gè)共同的話題就是 “高可用”，接口開(kāi)發(fā)往往看似簡(jiǎn)單，但保證高可用這塊實(shí)現(xiàn)起來(lái)卻不并沒(méi)有想想的那么容易，接下來(lái)我們就看一下，一個(gè)高可用的接口是該考慮哪些內(nèi)容，同時(shí)文中有不足的歡迎批評(píng)指正。

到底啥是高可用

用一句簡(jiǎn)單的話來(lái)概就是我們的系統(tǒng)具不具備應(yīng)對(duì)和規(guī)避風(fēng)險(xiǎn)的能力。

為啥做高可用

1. 程序都是有人開(kāi)發(fā)的，在開(kāi)發(fā)過(guò)程中會(huì)犯錯(cuò)從而導(dǎo)致線上事故的發(fā)生 2. 系統(tǒng)運(yùn)行依賴各種運(yùn)行環(huán)境：CPU、內(nèi)存、硬盤(pán)、網(wǎng)絡(luò)等等，而這些都有可能損壞 3. 業(yè)務(wù)拉新用戶正在注冊(cè)賬號(hào)，結(jié)果注冊(cè)接口掛了用戶體驗(yàn)受影響 4. 雙十一、618等大促大量用戶下單，結(jié)果下單服務(wù)接口掛了GMV受影響等等 5. 其他未知因素等等 總之為了應(yīng)對(duì)這些不可控因素的發(fā)生，我們必須要做高可用

高可用的關(guān)鍵點(diǎn)

我們說(shuō)過(guò)高可用的本質(zhì)是系統(tǒng)是否具備應(yīng)對(duì)和規(guī)避風(fēng)險(xiǎn)的能力，那么從這個(gè)角度出發(fā)來(lái)設(shè)計(jì)高可用接口的有以下幾個(gè)關(guān)鍵因素：Dependence（依賴）、Probability（概率）、Time（時(shí)長(zhǎng)）、Scope（范圍） 1. 依賴的資源相對(duì)少 2. 風(fēng)險(xiǎn)的概率足夠低 3. 影響的范圍足夠小 4. 影響時(shí)長(zhǎng)足夠短

接口高可用設(shè)計(jì)的幾個(gè)原則

結(jié)合這些關(guān)鍵點(diǎn)，我們來(lái)看一下具體具體注意事項(xiàng)

1、控制依賴

能少依賴就少依賴，能不強(qiáng)依賴就不強(qiáng)依賴

少依賴 例如：日常每分鐘10個(gè)請(qǐng)求，查詢Mysql數(shù)據(jù)即可滿足，此時(shí)盲目引入Redis中間件，不僅浪費(fèi)資源而且增加系統(tǒng)復(fù)雜性 弱依賴 例如：用戶注冊(cè)服務(wù)強(qiáng)依賴新用戶優(yōu)惠券發(fā)放服務(wù)，當(dāng)優(yōu)惠券發(fā)放服務(wù)故障后，整個(gè)注冊(cè)不可用，好的方式是采用弱依賴，使用異步化的 方式，這樣優(yōu)惠券發(fā)送服務(wù)不可用時(shí)，不會(huì)影響注冊(cè)鏈路。

2、避免單點(diǎn)

避免單點(diǎn)故障的核心是通過(guò)備份或者冗余快速的進(jìn)行容錯(cuò)

1. 我們采用多機(jī)房多實(shí)力部署我們應(yīng)用來(lái)保障故障風(fēng)險(xiǎn)分?jǐn)?，一旦有一臺(tái)服務(wù)器出現(xiàn)問(wèn)題，其他服務(wù)仍然能夠繼續(xù)支撐我們的服務(wù) 2. 每次上線我們都會(huì)保留上一次上線發(fā)布版本，這樣一旦上線的程序出現(xiàn)問(wèn)題我們能夠快速回滾到上一版本 3. 每個(gè)接口至少保障2人知道相關(guān)業(yè)務(wù)，一旦線上服務(wù)出現(xiàn)問(wèn)題，其中任何一人一個(gè)能夠快速處理相關(guān)線上問(wèn)題 4. 不管是Mysql還是Redis等中間件都支持?jǐn)?shù)據(jù)主備機(jī)群部署 類似的例子很多這里就不再一一列舉了

3、負(fù)載均衡

將風(fēng)險(xiǎn)進(jìn)行分?jǐn)偙苊夥蛛U(xiǎn)擴(kuò)散

例如：無(wú)論是Ngnix或者JSF的，其負(fù)載均衡目的就是盡量的將流量分散到不同的服務(wù)器節(jié)點(diǎn)上，這樣可以有效的保障單節(jié)點(diǎn)因系統(tǒng)瓶頸 問(wèn)題而引發(fā)一系列的風(fēng)險(xiǎn)。 像上面這個(gè)例子我想每個(gè)研發(fā)人員都知道也都會(huì)這么做，但是是不是所有的場(chǎng)景我們都考慮到均衡這個(gè)問(wèn)題？ 例如：通常為了提高讀并發(fā)的能力，我們會(huì)把數(shù)據(jù)緩存到JIMDB中，但是因?yàn)榫彺娴膋ey出現(xiàn)了熱點(diǎn)數(shù)據(jù)導(dǎo)致JIMDB單分片負(fù)載過(guò)高，恰 好，這個(gè)分片上也緩存了其他數(shù)據(jù)，但是因?yàn)镃PU負(fù)載過(guò)高，導(dǎo)致查詢性能變差，大量的超時(shí)，影響了業(yè)務(wù)。所以，我們?cè)诮涌谠O(shè)計(jì) 的時(shí)候，假如遇到類似場(chǎng)景，也要充分考慮數(shù)據(jù)存儲(chǔ)的均衡性，同時(shí)針對(duì)熱點(diǎn)數(shù)據(jù)做好監(jiān)控，隨時(shí)支持動(dòng)態(tài)均衡。

4、資源隔離

隔離的目的將風(fēng)險(xiǎn)控制在可控范圍內(nèi)，避免風(fēng)險(xiǎn)擴(kuò)散

例如：接口部署之間服務(wù)部署物理上是相互隔離的，避免單機(jī)房或者單服務(wù)器出現(xiàn)故障影響整個(gè)服務(wù) 例如：我們?cè)诖鎯?chǔ)業(yè)務(wù)數(shù)據(jù)的時(shí)候會(huì)將數(shù)據(jù)分庫(kù)分表，數(shù)據(jù)通過(guò)不同分片存儲(chǔ)，這樣就不會(huì)導(dǎo)致某個(gè)服務(wù)器掛掉影響到整個(gè)服務(wù)

5、接口限流

限流是一種保護(hù)措施，目的是將風(fēng)險(xiǎn)控制在可控范圍內(nèi)

我們?cè)陂_(kāi)發(fā)接口的時(shí)候，一定要結(jié)合業(yè)務(wù)流量情況進(jìn)行限流措施，限流一方面處于對(duì)自身服務(wù)資源的保護(hù)，同時(shí)也是對(duì)依賴資源的一種 保護(hù)措施。 目前集團(tuán)JSF在流量控制這塊已經(jīng)有了對(duì)應(yīng)的限流處理能力，同時(shí)我們也可以結(jié)合實(shí)際業(yè)務(wù)進(jìn)行限流模塊的開(kāi)發(fā)。

6、服務(wù)熔斷

熔斷也是一種保護(hù)措施，目的是將風(fēng)險(xiǎn)控制在可控范圍內(nèi)，避免風(fēng)險(xiǎn)擴(kuò)散

例如：經(jīng)常我們服務(wù)A會(huì)同時(shí)調(diào)用B、C、D多個(gè)服務(wù)，當(dāng)我們依賴的服務(wù)其中一個(gè)出現(xiàn)故障或者性能下降的時(shí)候，就是導(dǎo)致整體服務(wù) 可用率下降，所以我們?cè)陂_(kāi)發(fā)此類服務(wù)的時(shí)候，一定要注意接口之間的隔離。我們可以利用類似Hystrix組件實(shí)現(xiàn)，也可以借助DUCC 進(jìn)行手動(dòng)隔離。 其實(shí)熔斷也是一種控制資源依賴的一種，將強(qiáng)依賴降級(jí)為弱依賴

7、異步處理

將同步操作轉(zhuǎn)為異步操作

例如：用戶頁(yè)面領(lǐng)取一些權(quán)益，針對(duì)領(lǐng)取這個(gè)服務(wù)在大促期間因?yàn)橛脩袅髁枯^大，為了避免系統(tǒng)負(fù)載，此時(shí)采用MQ異步接收用戶領(lǐng)取 請(qǐng)求然后進(jìn)行優(yōu)惠券發(fā)放,這樣不僅極大的減少了事故的影響范圍，也減少問(wèn)題發(fā)生概率。

8、降級(jí)方案

服務(wù)降級(jí)屬于一種問(wèn)題發(fā)生后的補(bǔ)救措施，通過(guò)服務(wù)降級(jí)可以減少一部分風(fēng)險(xiǎn)影響范圍

對(duì)于重要的服務(wù)接口我們都要具備完善的降級(jí)方案，這里需要說(shuō)明的是，降級(jí)有損的，我們一定要在系統(tǒng)開(kāi)發(fā)前就要考慮各種問(wèn)題 發(fā)生的可能，降級(jí)的前提是通過(guò)降級(jí)非核心業(yè)務(wù)保證核心業(yè)務(wù)運(yùn)行。 例如：大促峰值期間，一般會(huì)提前降級(jí)掉很多功能，同時(shí)限流，主要是為了保護(hù)峰值絕大部分人的交易支付體驗(yàn)。

9、灰度發(fā)布

通過(guò)灰度發(fā)布降低風(fēng)險(xiǎn)影響范圍

例如：我們上線一個(gè)新服務(wù)，通過(guò)一定的灰度策略，讓用戶先行體驗(yàn)新版本的應(yīng)用，通過(guò)收集這部分用戶對(duì)新版本應(yīng)用的反饋以及 對(duì)新版本功能、性能、穩(wěn)定性等指標(biāo)進(jìn)行評(píng)論，進(jìn)而決定繼續(xù)放大新版本投放范圍直至全量升級(jí)或回滾至老版本。根據(jù)線上反饋結(jié)果， 做到查漏補(bǔ)缺，發(fā)現(xiàn)重大問(wèn)題，可回滾“舊版本”

10、混沌工程

通過(guò)提前對(duì)系統(tǒng)進(jìn)行一些破壞性的手段，提前發(fā)現(xiàn)潛在問(wèn)題

例如：一個(gè)復(fù)雜接口系統(tǒng)依賴了太多的服務(wù)和組件，這些組件隨時(shí)隨地都可能會(huì)發(fā)生故障，而一旦它們發(fā)生故障，會(huì)不會(huì)如蝴蝶效應(yīng) 一般造成整體服務(wù)不可用呢，我們并不知道，因此我們可以借助泰山平臺(tái)混沌工程進(jìn)行演練，針對(duì)發(fā)生的場(chǎng)景制定各種預(yù)案，將風(fēng)險(xiǎn) 控制在可控范圍內(nèi)。

編輯：何安