淺談服務的治理

關鍵詞：“服務化”、“服務治理”、“服務治理框架”。

        在分散式系統的構建之中，服務治理是類似血液一樣的存在，一個好的服務治理平臺可以大大降低協作開發的成本和整體的版本迭代效率。在服務治理之前，簡單粗暴的RPC呼叫使用的點對點方式，完全通過人為進行配置操作決定，運維成本高（每次佈置1套新的環境需要改一堆配置檔案的IP），還容易出錯，且整個系統執行期間的服務穩定性也無法很好的感知。

隨著網際網路的發展，網站應用的規模不斷擴大，常規的垂直應用架構已無法應對，分散式服務架構以及流動計算架構勢在必行，亟需一個治理系統確保架構有條不紊的演進。

• 單一應用架構 
  • 當網站流量很小時，只需一個應用，將所有功能都部署在一起，以減少部署節點和成本。
  • 此時，用於簡化增刪改查工作量的 資料訪問框架(ORM) 是關鍵。
• 垂直應用架構 
  • 當訪問量逐漸增大，單一應用增加機器帶來的加速度越來越小，將應用拆成互不相干的幾個應用，以提升效率。
  • 此時，用於加速前端頁面開發的 Web框架(MVC) 是關鍵。
• 分散式服務架構 
  • 當垂直應用越來越多，應用之間互動不可避免，將核心業務抽取出來，作為獨立的服務，逐漸形成穩定的服務中心，使前端應用能更快速的響應多變的市場需求。
  • 此時，用於提高業務複用及整合的 分散式服務框架(RPC) 是關鍵。
• 流動計算架構 
  • 當服務越來越多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增加一個排程中心基於訪問壓力實時管理叢集容量，提高叢集利用率。
  • 此時，用於提高機器利用率的 資源排程和治理中心(SOA) 是關鍵。實際上這樣是一種雲架構，實現了服務的動態擴充套件，在高併發情況下，服務端可以快速部署機器，而對於應用端沒有任何其他影響

常見的服務治理：

服務降級、服務流控、服務動態擴充套件、超時控制、優先順序排程、負載均衡策略調整、分組調整等

服務治理是什麼

       服務治理（SOA governance），按照Anne Thomas Manes的定義是：企業為了確保事情順利完成而實施的過程，包括最佳實踐、架構原則、治理規程、規律以及其他決定性的因素。服務治理指的是用來管理SOA的採用和實現的過程。

分散式服務治理框架和平臺

Dubbo、HSF、JSF、Tars、Motan和RestCloud

服務治理針對的問題

服務治理中一些典型的問題是：

    1.交付價值到利益相關者，這是投入與回報的問題

    2.對標準和規則的遵從（這是和審計相關的）

    3.變更管理：變更一個服務通常會引起不可預見的後果，因為服務的消費者對服務的提供者來說是不可知的。

    4.服務質量的保證：彈性新增新服務需要對這些服務給予額外的關注。

服務治理包括的行為

服務治理的一些關鍵活動包括：

    1.對開發新服務和升級現有服務的計劃

    2.管理服務的生命週期：確保升級服務不會影響目前的服務消費者制定方針來限制服務行為：

    3.制定所有服務都要遵從的規則，確保服務的一致性

    4.監控服務的效能：由於服務組合，服務停機和效能低下的後果是嚴重的。通過監控服務的效能和可用性，當問題出現的時候能馬上採取應對措施。

    5.管理由誰來呼叫服務、怎樣呼叫服務

其實服務治理這個東西都創業公司到成熟的大公司都在用，只是做到的程度不同。

　　先說說服務治理的邊界。本質上任何能提升服務可用性，效能，讓服務更穩定等等，只要是能讓服務執行的更好，都屬於服務治理的範疇。服務治理比較常見的話題：服務發現，服務變更管理，服務監控，服務擴容縮容，服務自我保護，服務降級，服務授權防攻擊，服務上線驗證和灰度釋出，服務問題定位和跟蹤，服務負載，服務例項的排程等等。

        說服務治理就要先聊聊服務。從業務角度而言，服務是一個可重複的任務。我是個做業務的，業務可以被粗粒度的劃分為一系列粗粒度的服務和流程。這本質上符合SOA架構的風格，而現在比較流行的微服務出現實際上應當歸功於SOA原則的成功。而微服務將服務劃分的更細，更多，會導致出問題的概率變大。這時候，服務治理的手段沒有進步的話，實際上服務的壓力是變大了。所以大家在選擇架構的時候，需要按照自己的業務發展現狀和趨勢合理的辯證的做決斷。就好像我在上篇文章裡舉的例子：如果要建一間房子，可能隨便建個土房子或者茅草房子就能用幾十年，但是隨著規模的擴大，建成四合院就要講究格局，建成一個小區，建成一座城市，就需要運用各種工程學的知識更加統籌的規劃。

服務治理的歷史變遷：

第一代：以IBM為首的SOA解決方案提供商退出的針對企業IT系統的服務治理框架，主要聚焦在對企業IT系統中異構服務的質量管理、服務釋出審批流程和服務建模、開發測試以及執行生命全週期的管理。（服務治理源於SOA的成功）

第二代：以阿里為首的基於同一分散式框架的全新服務治理理念誕生，聚焦於對內部同構服務的線上治理，保障線上服務的執行質量

微服務架構+雲端服務治理2013年至今，隨著雲端計算和微服務架構的發展，以AWS為首的基於微服務架構+雲服務化的雲端服務治理體系誕生

傳統的SOA主要包括：

1）服務建模：驗證功能需求和業務需求，發現和評估當前服務，服務建模和效能需求，開發治理規劃

2）服務組裝：建立服務更新計劃，建立和修改服務以滿足業務需求，按照一定策略評估服務，批准組裝完成

3）服務部署：確保服務的質量，措施包括效能測試，功能測試和滿足度測試，批准服務部署

4）服務治理：早整個生命週期內管理和監控服務，跟蹤服務登錄檔中的服務，根據服務治理等級協議(SLA)上報服務的效能KPI資料進行服務質量管理

缺點：

1）分散式服務框架的發展，內部服務框架需要統一，服務治理也需要適應新的架構，能夠由表及裡對服務進行細粒度的控制

2）微服務架構的發展和業務規模的擴大，導致服務規模量變引起質變，服務治理的特點和難度也隨之發生變化

3）缺少服務執行時動態治理的能力，面對突發的流量高峰和業務衝擊，傳統的服務治理在響應速度，恢復故障等方面存在不足，無法敏捷的應對業務需求

分散式服務框架的服務治理：

是面對網際網路業務的服務治理，聚焦在對內部採用統一服務框架進行服務化的業務執行太、細粒度的敏捷治理體系

治理物件：基於分散式服務框架開發的業務服務，與協議本身無關，治理的可以是SOA服務，也可以是基於內部服務框架私有協議開發的各種服務

治理策略：針對網際網路業務的特點，eg 突發的流量高峰、網路延時、機房故障等，重點針對大規模跨機房的海量服務進行執行態治理，保障線上服務的高SLA，滿足使用者的體驗，常用的策略包括限流降級、服務嵌入遷出、服務動態路由和灰度釋出等

AWS雲端微服務治理：AWS作為全球最大的雲端計算解決方案提供商，在微服務雲化開發和治理方面提供了非常多的經驗，eg：

1）全公司統一服務開發環境，統一簡化服務框架(Coral Service)，統一執行平臺，快速高效開發

2）服務後端應用服務化，系統由多想服務化元件構成

3）服務共享、原子化、重用

4）服務由小研發團隊負責服務開發測試部署和治理，運維整個生命週期支撐

5）高度自動化和Dev&Ops支援，一鍵部署和回退

6）超大規模支援：後臺幾十萬個服務，成千上萬個開發者同時使用，平均每秒有1~2個服務治理

7）嘗試基於Docker的容器部署微服務

8）服務治理的核心是：服務效能KPI統計、告警、服務健康管理、靈活的彈性伸縮策略、故障自動遷移、服務限流和服務降級等多種治理手段，保障服務高質量執行

應用服務化之後面臨的挑戰：

1）跨團隊協作問題：服務變多之後一般會分小組開發，涉及跨團隊聯調，如何快速找到開發者 ？ 當前系統提供了那些服務，服務介面定義和引數是什麼？服務使用示例，注意事項和約束是什麼？開發完成之後除錯，消費者A和服務提供者S進行聯調會存在2個問題：a. 提供者S分散式部署，存在多個服務例項，路由動態分發，沒辦法確定會路由到哪一臺伺服器  b.若打斷點，其它的消費者可能也正在使用，除錯會被干擾，需要通知所有的開發者不要呼叫服務S，有點兒不太現實

2）服務的上下線管控：由於服務的釋出很簡單，上線會越來越隨意，導致有時候架構師都不知道上線了什麼服務，甚至出現重複服務，而服務下線比上線還要困難，因為業務調整，需要 結束某些服務的生命週期，服務提供者有時會直接將服務下線，導致依賴該服務的應用不能正常工作，應該是先將該服務標識為過時，然後通知呼叫方儘快修改呼叫，通過效能KPI介面和呼叫鏈分析，確認沒有消費者再停用服務

服務安全：針對內部應用，服務框架常採用長連線管理客戶端連線，針對非信任的第三方應用，或者而已消費者，需要具備黑白名單訪問機制，防止客戶端非法鏈路過多，佔用大量的控制程式碼，執行緒和快取資源，影響服務提供者的質量

服務高SLA保障：業務高峰期，系統資源會成為瓶頸，需要對非核心服務 eg 使用者評論、粉絲管理、積分管理等服務做限制，保障核心服務的正常執行，服務框架需要考慮如何關停非核心服務又不影響其它的合設服務

快速定位故障：服務化之後一個業務流程底層可能涉及成千上百的服務呼叫，任何一個服務發生故障都可能導致業務不可用，由於分散式部署，部署在成千上百臺機器上，若仍使用原來的故障定位手段效率會非常低，服務化帶來的價值也會大打折扣

服務治理非目標：

1）防止業務架構腐化：通過服務註冊中心對服務強弱依賴進行分析，結合執行時服務呼叫鏈條分析，梳理不合理的依賴和呼叫路徑，優化服務架構，防止程式碼腐化

2）快速故障定界：通過Flume等分散式日誌採集框架，實時收集呼叫鏈日誌，服務效能KPI資料，服務介面日誌，執行日誌等，實時彙總和線上分析，集中儲存和展示，實現故障的自動發現，自動分析和線上條件檢索，方便運維和開發人員進行快速問題定位

3）服務微管控：較細粒度的進行執行期服務治理，包括限流降級，服務遷入遷出、服務超時控制、智慧路由,  統一配置、優先順序排程和流量遷移等，提供方法級治理和動態生效功能，通過一系列的細粒度的治理策略，在故障發生時可以多管齊下，線上調整，快速回復業務

4）服務生命週期管理：包括服務的上線審批、下線通知，服務的線上升級以及上下線的服務文件庫的建設。
 

成熟的解決方案

　　查閱的一些資料，目前的業界一些比較成熟的解決方案如下：

名稱	所屬公司	是否開源	資料文件	備註
Dubbo	阿里巴巴	是	多
HSF	阿里巴巴	否	中	目前已作為阿里雲產品EDAS其中的套件開放使用
Tars	騰訊	是	中	已作為騰訊雲應用框架對外提供使用
JSF	京東	否	少
Linkerd	CNCF	是	少	原型是Twitter所構建的一個基於scala的可擴充套件RPC系統Finagle
Motan	新浪微博	是	中
istio	谷歌、IBM、Lyft	是	少

引入服務治理是為了對整體的RPC呼叫進行集中化管理。對我們來說其核心價值在於，減少重複勞動、避免手動配置物理檔案產生的問題、降低開發人員的技術運用成本。下面針對其中的功能點進行分別講解。

服務的自動註冊：

　　這是一個服務治理框架的基礎功能。大家運用WCF的時候應該感受更加明顯，我們要配置一個WCF服務端的時候需要在config檔案中做很多配置，甚至大部分公司其實配置都是一模一樣的到處複製黏貼，整個這個過程其實是價值較低的重複性勞動。

　　解決這個問題需要通過動態的感知到服務端的地址資訊，然後針對該地址資訊進行自動化配置或者模板化配置，讓其快速可用。那麼這些額外的資訊儲存在哪，就需要引入一個註冊中心的概念來進行集中化管理。

客戶端的自動發現：

　　當我們在config檔案中指定具體的IP和埠來定義遠端服務的地址，或者直接在程式裡硬編碼遠端服務地址時，本身就是一個端到端的訪問方式。無法靈活的在程式執行過程中去增加或減少後端的服務節點。

　　解決這個問題需要和服務註冊的實現方式配套。還可以針對於不同型別的應用制定一些負載均衡的策略進行切換。

變更下發：

　　客戶端的自動發現就依賴於此下發的資料，需要及時把提供服務的節點資訊變化下發到各個客戶端。它面向的場景如：當我們進行一個釋出的時候，先將需要釋出的節點從負載均衡列表中移除，然後再進行更新，最後再新增到負載均衡列表中。這個時候避免了訪問到正在釋出中的程式。

　　當然這點也可以基於狀態檢測模組去做，這樣可以對服務節點的健康狀態感知能力得到更好的加強。

            微服務設計——架構——平臺——框架——部署與實現——運維和運營——優化

                                                     從技術整合項業務服務的轉變

【參考案例】

1、服務治理深入淺出- 服務治理出現的必要性探索（京東為例） - https://segmentfault.com/a/1190000010224335

2、服務治理框架 - (美團點評) HackerVirus - https://www.cnblogs.com/Leo_wl/p/7513531.html

3、分散式系統中的服務治理（各大公司）  https://www.cnblogs.com/Zachary-Fan/p/service_manage_discovery.html

4、分散式服務治理框架Dubbo-學海無涯 心境無限- http://blog.51cto.com/zhangfengzhe/1931170

5、服務治理與Dubbo架構 -  https://blog.csdn.net/qq418517226/article/details/51784825

6、微服務架構打造別具一格的服務治理體驗（宜信技術）https://blog.csdn.net/linlzk/article/details/65444487

7、淺談服務治理與微服務 - Heaven Wang 的專欄  https://blog.csdn.net/suifeng3051/article/details/53992560（推薦閱讀）

8、RestCloud國產微服務治理及開發平臺 - RestCloud微服務治理及快速開發平臺 https://blog.csdn.net/kezi/article/details/78319072