2.2 正向服務治理

正向治理是通過相應的治理手段，解決微服務改造后帶來的一系列問題，接下來圍繞效率、穩定性和效果方面的治理工作展開討論。

2.2.1 效率治理

效率包括的范圍很廣，具體包括開發效率、測試效率、運維效率等。開發效率一般通過采用微服務框架的方式解決，運維效率放到穩定性治理里面討論，接下來主要討論測試效率相關的治理，包括測試環境構造，以及測試數據的獲取。

1.基于流量錄制和回放的測試

微服務化架構下，微服務自身依賴的第三方服務、數據越來越多，給傳統的測試方式帶來很多困難，如被依賴的線下服務不穩定；服務無法提供期望的響應數據；缺少測試場景構造標準等。針對這些問題，一般能想到的思路是提高測試環境穩定性、自己構造測試數據和測試場景等方式，提高測試的確定性和有效性，但這些方式不能從根本上解決問題。比如，服務不穩定的情況仍然無法避免，通過更改代碼注入對象等方式不僅繁雜而且非常容易出錯，并且沒有一定的依據，構造的測試場景不充分，心里沒底。

上述問題導致了代碼質量下降、自測/測試困難，在業務越來越復雜，依賴服務越來越多的大環境下，這些問題變得越加嚴重，到了必須要升級解決方案的地步。

針對上述微服務測試的不足，嘗試推出了流量錄制和回放解決方案，通過一定的方式將線上的真實流量錄制下來，在線下進行回放。線下測試時，基于線上的回放流量可以靈活地測試服務的各自功能，還可以基于回放流量進行編輯修改，對服務依賴的第三方請求進行mock和定制，使代碼開發變得簡單方便，且可隨改隨測，解決RD開發不便、自測流程過長的問題。

錄制的流量要包含服務的請求/返回流量，以及能關聯上的與其對應的第三方交互流量。如果僅有服務的請求/返回流量，則只能被應用在查詢類只讀系統中，應用范圍受限；如果第三方交互不能和請求正確關聯，則無法正確應用這些流量。

要解決流量的關聯難題，一個解決方案是將流量整流，使其串行化。將線上原本服務并行流量的一臺機器，控制其接收到的流量，將其服務的流量降低至串行，且流量之間間隔一定的時間（以便給異步第三方請求預留時間），那么這些流量的請求/響應和其第三方交互流量就被自動地關聯了起來。

還有一個難題是如何將請求和第三方交互流量關聯起來，這塊其實沒有一個特別通用的解決方案，可以基于分布式跟蹤技術將請求和對第三方系統調用的流量關聯起來。但這種方式難點是并非所有第三方交互流量都帶有請求跟蹤標識。還有一種思路是通過攔截語言層面的系統調用，將請求和對第三方系統的調用進行關聯。

2.基于仿真環境的測試

作為在線服務，為了滿足灰度發布、測試等多維度的需求，一般需要支持靈活的分流策略，將流量調度到不同的環境中。

為了支持精細的灰度發布策略，需要根據一定的規則將線上流量分流到小流量集群，為了支持使用真實流量進行高仿真測試，還需要根據策略規則將一定流量引到仿真環境中。小流量分流的特點是流量發往小流量集群后，不再進行任何處理，直接等待小流量集群的返回結果，然后將該結果轉發給調用側。仿真環境分流的特點是發往仿真環境的流量只是一份“影子”流量，相當于Oneway請求（不需要應答消息），對業務處理過程沒有任何影響，還是和沒有仿真環境的情況下一樣處理。

仿真環境支持可以在服務框架層面進行，為了實現基于請求內容的路由和轉發，框架充當了一個Proxy的角色，將請求解析后再發包發送給下游環境。

基于仿真流量的特點，為了不對業務產生影響，發送到下游仿真環境的超時時間可以設置得非常小，即使有一些流量超時也沒有關系，同時為了在自動生成的代碼框架下實現仿真環境處理后的Oneway效果，可以自定義一個傳輸層，這個傳輸層的具體實現是什么都不進行處理，直接丟棄即可。

2.2.2 穩定性治理

穩定性治理是服務治理的重中之重，下面重點討論穩定性治理的體系和模型。

1.穩定性治理模型

穩定性治理是一個對故障進行管理的過程。從故障管理的視角看，可以分為故障預防、故障發現、故障定位、故障止損以及故障恢復5個階段，穩定性建設的各項工作融入故障模型的各個階段。如果將穩定性故障和火災進行類比，穩定性工作模型實際上是一個防火–放火–滅火模型。所謂防火，就是通過各種機制和措施，提前排查出系統中各種可能的隱患，防止災難的發生；滅火是指實際發生了問題，就要最大限度地進行止損，減少災難的影響面，盡快恢復業務的正常運行；放火類似于消防演習，定期模擬災難的發生，并制定相應的疏散通道，通過演習可以排查出當前仍然有哪些待改進的地方。比如，消防意識不夠，疏散通道設計不太合理等，通過不斷的周期性演習和針對性改進，可以提高大家在面對真實火災的應對速度和處理能力，可以對實際的災難的控制有很好的參考價值，演習盡可能有一定的逼真度，如果只是例行的走個過場，不會收到太大的效果。

從各階段的抓手上看，故障預防包括穩定性設計、風險度量分析體系以及變更管理這幾個環節，分別從服務設計、風險檢測和分析及變更攔截這幾個維度，在研發生命周期的不同環節對故障進行多級攔截。

服務上線后需要有相應的機制能夠檢測當前系統是否正常工作，當系統不正常時有相應的控制措施，因此從故障發現、定位和止損上，需要有一連串的基礎設施支持，保證系統可見、故障可發現可定位、可控制。

2.基于容器化的穩定性治理

微服務在開發、測試、運維、容量成本等方面帶來了諸多難題，容器技術的使用可以很大程度上緩解微服務架構所帶來的問題。將容器技術和微服務架構結合，從開發、測試到上線，實現了“一次編寫，到處運行”。

容器的最有革命性的創新是鏡像技術，它將應用程序、基礎庫和環境等封裝在一起，作為微服務封裝和運行的基石。輕量級的鏡像技術作為微服務的交付方式，從如下幾個方面極大地影響和改變了微服務生態體系。

（1）測試

物理機環境下，如果直接基于裸機，那么環境搭建的開銷很大，并且很難保證不同環境的一致性。虛擬機環境下，雖然也引入了鏡像，但鏡像特別大，一般都是幾十GB，甚至上百GB，很難快速創建和遷移。容器環境下，由于鏡像比較輕量，每次變更后，可以快速創建本次變更對應的鏡像，同時可以基于本次鏡像快速創建多個完全相同的測試環境，容器鏡像封裝了所有運行應用程序所必需的相關細節，比如應用依賴以及操作系統。這就使得鏡像從一個環境移植到另外一個環境更加靈活，有力地支撐了微服務快速迭代場景下的測試。

（2）部署

微服務架構下微服務個數比較多，并且每個服務的變更非常頻繁，運維的工作量很大，借助容器鏡像，可以把環境交付提前。每個研發多付出5%的工作量，換取運維200%的工作量，可以加速微服務變更的快速部署和落地。

微服務架構下流量變化很快，遇到突發大流量時，如果系統具備快速便捷的擴容/縮容能力，可以極大地提高系統的穩定性和靈活性。我們可以借助容器技術，快速構建完善的擴縮容基礎設施，流量峰值時快速擴容，流量低峰時縮容。

微服務的云化架構，在運維層面和之前會有很大的差異，基礎設施層面，比如部署系統、配置系統、監控系統等都需要針對上云進行相應的適配調整，服務云化過程中也會遇到很多特有的問題，下面會梳理下之前微服務云化過程中實際過程中遇到的一些典型問題，以便給后續的微服務云化落地一些幫助。

（1）容器網絡和物理機網絡打通

之前的微服務云化遷移是直接從物理機遷移到Kubernetes容器集群，遷移一般是一個服務一個服務逐漸遷移的，如果Kubernetes集群和原來物理機集群通信上完全不互通，會使服務遷移前后在部署上有很多的改動。比如以服務間調用來說，之前是集群內部的調用，遷移期間需要修改為以Kubernetes Ingress的方式進行調用，但整個物理機集群都被遷移到Kubernetes集群后，在Kubernetes網絡中，又需要改回到集群內部調用的方式。從終態看，整個遷移過程中做了很多無用的工作。

為了減少Kubernetes容器化改造過程中頻繁的調用方式改動，我們在遷移過程中遵循一個重要的原則，遷移前后網絡互通，這樣遷移過程中調用方式不需要有任何變化，遷移過程中業務完全不需要感知。

（2）認清物理機和容器環境上的差異

云化架構下，雖然使用上和之前沒有明顯的差異，但畢竟是兩個完全不同的環境，在物理機上驗證完全沒有問題，不代表容器環境下也可以正常工作。之前遇到過一個問題，服務之前運行完全正常，遷移到云化架構下一段時間后，由于日志被錯誤地輸出到了內存型文件系統中，內存被一點點耗盡，由于沒有完善的線上監控，引發線上故障；導致問題的具體原因是物理機日志組件使用了字符設備，容器環境下雖然在宿主機下也配置了對應的字符設備，但并未為宿主機下的容器單獨創建，因此云化遷移過程中，應該對容器和物理機環境上的一些差異有著清醒的認識。

（3）容器資源隔離

容器環境下，各種服務混部，當某個容器消耗的資源超過一定限度時，如果沒有完善的資源隔離機制，就會導致同一宿主機上的其他服務異常。精細化的資源隔離技術是容器技術大規模推廣的一個必要前提。

（4）故障容災

服務上云畢竟是個全新的環境，可能會遇到各種類型的問題，特別是網絡層面，從硬件網絡過渡到軟件定義網絡（SDN），雖然靈活性比之前大大加強，但SDN網絡在成熟度和穩定性上比之前的硬件網絡還有不小的差異。之前遇到過一次SDN網絡異常，導致整個機房的容器服務不可用，幸好當時有多機房流量切換預案，才沒有導致更大的問題。因此服務上云前，需要提前想到有哪些可能的故障類型，針對每種故障設置相應的容災預案。