淺談服務接口的高可用設計

作者：京東零售 王磊

前言

作為一個後端研發人員，開發服務接口是我正常不過的工作了，這些接口不管是面向前端HTTP或者是供其他服務RPC遠端調用的，都繞不開一個共同的話題就是“高可用”，接口開發往往看似簡單，但保證高可用這塊實作起來卻不并沒有想想的那麼容易，接下來我們就看一下，一個高可用的接口是該考慮哪些内容，同時文中有不足的歡迎批評指正。

到底啥是高可用

用一句簡單的話來概就是我們的系統具不具備應對和規避風險的能力。
           

為啥做高可用

1. 程式都是有人開發的，在開發過程中會犯錯進而導緻線上事故的發生
2. 系統運作依賴各種運作環境：CPU、記憶體、硬碟、網絡等等，而這些都有可能損壞
3. 業務拉新使用者正在新增賬號，結果注冊接口挂了使用者體驗受影響
4. 雙十一、618等大促大量使用者下單，結果下單服務接口挂了GMV受影響等等
5. 其他未知因素等等
總之為了應對這些不可控因素的發生，我們必須要做高可用
           

高可用的關鍵點

我們說過高可用的本質是系統是否具備應對和規避風險的能力，那麼從這個角度出發來設計高可用接口的有以下幾個關鍵因素：Dependence（依賴）、Probability（機率）、Time（時長）、Scope（範圍）

1. 依賴的資源相對少
2. 風險的機率足夠低
3. 影響的範圍足夠小
4. 影響時長足夠短
           

接口高可用設計的幾個原則

結合這些關鍵點，我們來看一下具體具體注意事項

1、控制依賴

能少依賴就少依賴，能不強依賴就不強依賴

少依賴
例如：日常每分鐘10個請求，查詢Mysql資料即可滿足，此時盲目引入Redis中間件，不僅浪費資源而且增加系統複雜性

弱依賴
例如：使用者注冊服務強依賴新使用者優惠券發放服務，當優惠券發放服務故障後，整個注冊不可用，好的方式是采用弱依賴，使用異步化的
方式，這樣優惠券發送服務不可用時，不會影響注冊鍊路。
           

2、避免單點

避免單點故障的核心是通過備份或者備援快速的進行容錯

1. 我們采用多機房多實力部署我們應用來保障故障風險分攤，一旦有一台伺服器出現問題，其他服務仍然能夠繼續支撐我們的服務
2. 每次上線我們都會保留上一次上線釋出版本，這樣一旦上線的程式出現問題我們能夠快速復原到上一版本
3. 每個接口至少保障2人知道相關業務，一旦線上服務出現問題，其中任何一人一個能夠快速處理相關線上問題
4. 不管是Mysql還是Redis等中間件都支援資料主備機群部署

類似的例子很多這裡就不再一一列舉了
           

3、負載均衡

将風險進行分攤避免分險擴散

例如：無論是Ngnix或者JSF的，其負載均衡目的就是盡量的将流量分散到不同的伺服器節點上，這樣可以有效的保障單節點因系統瓶頸
問題而引發一系列的風險。 

像上面這個例子我想每個研發人員都知道也都會這麼做，但是是不是所有的場景我們都考慮到均衡這個問題？

例如：通常為了提高讀并發的能力，我們會把資料緩存到JIMDB中，但是因為緩存的key出現了熱點資料導緻JIMDB單分片負載過高，恰
好，這個分片上也緩存了其他資料，但是因為CPU負載過高，導緻查詢性能變差，大量的逾時，影響了業務。是以，我們在接口設計
的時候，假如遇到類似場景，也要充分考慮資料存儲的均衡性，同時針對熱點資料做好監控，随時支援動态均衡。
           

4、資源隔離

隔離的目的将風險控制在可控範圍内，避免風險擴散

例如：接口部署之間服務部署實體上是互相隔離的，避免單機房或者單伺服器出現故障影響整個服務

例如：我們在存儲業務資料的時候會将資料分庫分表，資料通過不同分片存儲，這樣就不會導緻某個伺服器挂掉影響到整個服務
           

5、接口限流

限流是一種保護措施，目的是将風險控制在可控範圍内

我們在開發接口的時候，一定要結合業務流量情況進行限流措施，限流一方面處于對自身服務資源的保護，同時也是對依賴資源的一種
保護措施。

目前集團JSF在流量控制這塊已經有了對應的限流處理能力，同時我們也可以結合實際業務進行限流子產品的開發。
           

6、服務熔斷

熔斷也是一種保護措施，目的是将風險控制在可控範圍内，避免風險擴散

例如：經常我們服務A會同時調用B、C、D多個服務，當我們依賴的服務其中一個出現故障或者性能下降的時候，就是導緻整體服務
可用率下降，是以我們在開發此類服務的時候，一定要注意接口之間的隔離。我們可以利用類似Hystrix元件實作，也可以借助DUCC
進行手動隔離。

其實熔斷也是一種控制資源依賴的一種，将強依賴降級為弱依賴
           

7、異步處理

将同步操作轉為異步操作

例如：使用者頁面領取一些權益，針對領取這個服務在大促期間因為使用者流量較大，為了避免系統負載，此時采用MQ異步接收使用者領取
請求然後進行優惠券發放,這樣不僅極大的減少了事故的影響範圍，也減少問題發生機率。
           

8、降級方案

服務降級屬于一種問題發生後的補救措施，通過服務降級可以減少一部分風險影響範圍

對于重要的服務接口我們都要具備完善的降級方案，這裡需要說明的是，降級有損的，我們一定要在系統開發前就要考慮各種問題
發生的可能，降級的前提是通過降級非核心業務保證核心業務運作。

例如：大促峰值期間，一般會提前降級掉很多功能，同時限流，主要是為了保護峰值絕大部分人的交易支付體驗。
           

9、灰階釋出

通過灰階釋出降低風險影響範圍

例如：我們上線一個新服務，通過一定的灰階政策，讓使用者先行體驗新版本的應用，通過收集這部分使用者對新版本應用的回報以及
對新版本功能、性能、穩定性等名額進行評論，進而決定繼續放大新版本投放範圍直至全量更新或復原至老版本。根據線上回報結果，
做到查漏補缺，發現重大問題，可復原“舊版本”
           

10、混沌工程

通過提前對系統進行一些破壞性的手段，提前發現潛在問題

例如：一個複雜接口系統依賴了太多的服務群組件，這些元件随時随地都可能會發生故障，而一旦它們發生故障，會不會如蝴蝶效應
一般造成整體服務不可用呢，我們并不知道，是以我們可以借助泰山平台混沌工程進行演練，針對發生的場景制定各種預案，将風險
控制在可控範圍内。