基于CSE的微服務工程實踐-以契約為中心

微服務架構有一個核心特征：采用REST進行通信。微服務之間通過網絡進行通信，不通過共享文件、數據庫、內存等方式進行通信。亞馬遜最早引入微服務的時候，強制所有開發團隊必須通過網絡的方式開放服務能力，不允許任何其他方式進行能力開放。REST作為一種輕量級的網絡通信方式，在微服務架構下被廣泛采用。

為了滿足微服務團隊之間的交流，OPENAPI Initiative制定了Open API標準，該標準綜合考慮了不同語言、REST等接口習慣，定義了完整的跨平臺接口標準。CSE是最早采用和實現該標準的微服務開發框架，并將“以契約為中心”的概念，應用于整個微服務開發實踐。下圖展現了軟件開發周期的各個環節“契約”所扮演的角色。

1????? 管理、設計環節

微服務的能力全部通過REST接口開放，從管理和設計角度，提供了一個很好的管控點。在實際的項目團隊里面，需求分析和設計人員首先對微服務的接口進行設計，并創建獨立的git庫存放接口定義。通過做好git庫的權限管理，并將Code Review流程納入接口項目的管控，管理者能夠保證軟件規格是按照設計要求進行的。

CSE開發的微服務，啟動的時候會分析微服務所有的對外接口，并將契約信息注冊到服務中心，服務之間的調用需要嚴格滿足契約的要求，并提供了管理界面，可以方便的查詢契約。

通過靜態的方法管控規格一般是不夠的，管理者還可以使用契約生成測試代碼，書寫一定的驗收測試用例，或者將契約提交給第三方進行驗收測試。

為了更好的支持接口管控和微服務實現分離，需要對代碼組織方式提出一定的要求。[基于CSE的微服務工程實踐-Native API先行](https://bbs.huaweicloud.com/blogs/7c03a4793cd011e9bd5a7ca23e93a891) 提供了一個可以供開發者參考的項目。

2????? 開發、測試環節

基于契約，可以開發代碼生成工具，生成開發項目或者測試項目。開發者只需要按照接口要求，實現業務邏輯和測試邏輯。

[單體應用微服務改造實踐](https://bbs.huaweicloud.com/blogs/17ad483f325f11e9bd5a7ca23e93a891) 里面提到了自動化測試在保障軟件質量方面起到的關鍵作用，也提到了如何通過開發測試微服務進行更好的集成測試。通過工具生成開發、測試項目，使得開發人員能夠在開發業務邏輯的時候，同步開發測試微服務。

3????? 部署環節

契約能夠幫助用戶更好的管理能力開放?！癆PI經濟” 打開了公司能力通過API的方式對外界開放的窗口，很多公司通過提供接口給其他公司使用，并通過計費系統，按調用次數或者時長進行收費。能力開放的核心組件是APIG，APIG能夠幫助用戶完成開放接口的配置、計費以及常見的管控，比如流量控制等。有了契約，完成這些配置，不需要人工輸入，只需要將契約導入，勾選對應接口的規則就完成了能力開放。

4????? 治理

治理是本文討論的重點。談到微服務，就會談到微服務治理。不同的地方對于微服務治理有不一樣的定義。本文認為，保障微服務可靠運行的機制集合，共同構成了服務治理。為了更好的理解這個概念，下面分幾種最常見的場景進行分解，幫助理解什么樣的服務治理才是最好的，同時也可以幫助用戶理解在采用其他技術，比如Istio在微服務治理能力方面的差異。

4.1????? 負載均衡管理

彈性擴縮容、服務永遠在線是微服務的核心價值和特征。彈性擴縮容意味著通常運行環境一個微服務都會有多個版本，永遠在線則意味著運行環境不可避免的需要考慮多個微服務版本并存的狀況。負載均衡管理器的核心功能是將用戶請求轉發到正確的實例上面去。下面假設微服務A訪問微服務B。B的實例采用B11， B12， B21， B22這樣的方式描述，比如B11表示微服務B版本1的實例1，B21表示微服務B版本2的實例1，以此類推。

負載均衡策略考慮的是在目標微服務存在多個實例的情況下，采用什么規則轉發請求，常見的有Round Robin，Rondam和基于權重的負載均衡策略。負載均衡策略的配置一般是針對目標服務進行配置的，CSE允許給每個微服務配置獨立的負載均衡策略：

```

cse:

loadbalance:

B:

strategy:

name: RoundRobin

```

接口兼容是微服務管理里面非常常見的問題，雖然可以通過管理要求，讓開發者符合一定的規則，比如：

·???????? 不允許刪除接口

·???????? 不允許修改接口原型定義

·???????? 只允許新增接口，或者對老接口的bug進行修改

但是微服務處理請求轉發仍然面臨問題，比如B2相對于B1，新增了接口op2，也就是B11，B12存在接口op1，B21，B22存在接口op1，op2，當A請求op1的時候，可以將請求轉發給B11，B12，B21，B22，當A請求op2的時候，只能將請求轉發給B21，B22。負責均衡器需要通過契約識別微服務B的哪個實例具備op1和op2。CSE有了契約，這個轉發過程是框架自動完成的，將開發者從處理接口兼容場景下的轉發問題中解放出來。

在修改接口語義的情況下，這種情況會稍微變得更加復雜一點。比如B1的op1接口存在bug，修復后，升級到B2，升級后，期望A對于B的訪問，都到B2，而不到B1。這個時候，就需要根據灰度規則手工引流?；谄跫s，CSE能夠允許開發者基于請求參數定義轉發規則，比如：

```

cse.darklaunch.policy.B={"policyType":"RULE","ruleItems":[{"groupName":"test","groupCondition":"version=2","policyCondition":"operation=op1","caseInsensitive":true}]}

```

上面的配置，將operation參數值為op1的請求，轉發到微服務B的版本2實例上去。其中operation通常是接口參數名稱，用于將接口參數值不同的請求轉發到不同的實例，比如將userid=Chengdu的請求，轉發到B2。CSE對接口參數進行了擴展，在InvocationContext里面的參數名稱也可以用于灰度規則，這樣就實現了在bug修改過程中的對于某個接口的灰度引流。

A將請求轉發給B的時候，可能存在故障。有些故障是可恢復的，比如短暫的網絡波動，導致請求失敗，重試一下就可能成功；有些故障是不能恢復的，或者恢復時間較長，比如B11由于接收到大量請求，出現大量超時，如果B11繼續接收新請求，那么會加重超時情況。對于可以恢復的故障，需要能夠進行重試；對于不可恢復故障，則要考慮對于故障實例的隔離。CSE在負載均衡方面，對故障進行了分類，以針對具體的異常情況，進行重試和隔離。

負載均衡策略也會影響到性能。在容災部署模式下，微服務實例被部署到不同的AZ上面，A在訪問B的過程中，需要考慮當前A的實例所在的AZ，并將請求轉發到同AZ的B實例上面去。AZ親和能夠提升性能，在本AZ無實例可用的情況下，還需要將請求轉發到其他AZ，以實現可靠。

4.2????? 流量控制和隔離倉

流量控制通常分為客戶端流控和服務端流控。流量控制的難題是無法在產品開發的時候，就預測微服務的處理能力。有些用戶場景，需要根據業務需要，人為降低部分接口的調用頻率，以保證重點業務的資源能夠得到及時滿足。CSE基于契約，提供了非常簡單易用的限流配置能力，可以控制具體到接口的流量。

```

cse.flowcontrol.Provider.qps.limit.[ServiceName].[Schema].[operation]=100

cse.flowcontrol.Consumer.qps.limit.[ServiceName].[Schema].[operation]=100

```

流量控制機制有很多不足。在微服務架構下，進行全局限流需要在性能和準確性方面進行折中，設計很復雜的算法，所以通常沒有提供全局限流能力。服務處理能力和運行環境有關系，需要很復雜的并發測試工具，來識別服務的處理能力，針對接口級別的限流策略面臨著在實際環境中無法實施的尷尬境地。進行限流控制的本質原因，是解決計算資源分配的需要，所以從實際微服務實踐中，進行必要的資源隔離，是比限流更有效的手段，通過資源隔離限制資源占用，不需要對處理能力進行預估，讓業務系統盡最大能力處理更多的請求而不至于導致全局崩潰。通過線程池進行資源隔離，是非常有效的手段。基于契約，CSE能夠非常方便的給具體接口分配獨立資源。

```

cse.executors.Provider].[Schema].[operation]: custom-executor

```

線程池隔離的最早實踐來源于Hystrix，CSE也通過biz-keeper模塊集成了相關功能。但是Hystrix具體在使用的時候，存在性能差、調用棧過長并隱藏了底層錯誤導致無法定位問題等，Hystrix組件在實際業務系統中無法發揮本來設計上要解決的問題。CSE提供的線程池能力，在幾乎不降低業務性能的情況下，提供了很好的資源隔離機制。

線程池排隊隊列的大小，是采用線程池隔離需要考慮的一個重要問題。設置合理的隊列大小，及時丟棄請求（新來的請求，在隊里里面排隊超時的請求）對于系統可靠性和故障快速恢復顯得非常重要。否則突發的大規模請求，可能導致系統癱瘓，長時間無法自動恢復。

5????? 運維

在運維階段，契約仍然發揮非常重要的作用。基于契約，metrics可以生成接口級別的時延分布數據。

```

servicecomb.invocation.role=CONSUMER

servicecomb.invocation.operation=[ServiceName].[Schema].[operation]

servicecomb.invocation.status=200

servicecomb.invocation.type=latencyDistribution

servicecomb.invocation.scope=[1,3)

```

基于契約和metrics數據，可以開發強大的的運維工具，展現系統接口運行狀況，快速查詢接口運維數據。

CSE的metrics數據深入底層運行環境，能夠讀取和統計接口在隊列排隊、業務處理等非常細粒度環節的時延，從而為分析“毛刺”問題提供了數據支持。（“毛刺”是同事在分析性能問題的時候，對于部分請求某些時刻時延偏高，但是又不容易模擬重現現象的生動描述）

CSE 契約

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。