服務網格(ServiceMesh)這兩年異常之火,號稱是下一代微服務架構,接下來兩個月,準備系統性的寫寫這個東西,希望能夠讓大家對最新的架構技術,有個初步的瞭解。
畫外音:我的行文的風格了,“為什麼”往往比“怎麼樣”更重要。
互聯網公司,經常使用的是微服務分層架構。
畫外音:為什麼要服務化,詳見《服務化到底解決什麼問題?》。
隨著數據量不斷增大,吞吐量不斷增加,業務越來越複雜,服務的個數會越來越多,分層會越來越細,除了數據服務層,還會衍生出業務服務層,前後端分離等各種層次結構。
不斷髮現主要矛盾,抽離主要矛盾,解決主要矛盾,架構自然演進了,微服務架構,潛在的主要矛盾會是什麼呢?
引入微服務架構,一般會引入一個RPC框架,來完成整個RPC的調用過程。
如上圖粉色部分所示,RPC分為:
- RPC-client,它嵌在調用方進程裡
- RPC-server,是服務進程的基礎
不只是微服務,MQ也是類似的架構:
如上圖粉色部分所示,MQ分為:
- MQ-send-client
- MQ-server
- MQ-recv-client
框架只是第一步,越來越多和RPC,和微服務相關的功能,會被加入進來。
例如:負載均衡
如果要擴展多種負載均衡方案,例如:
- 輪詢
- 隨機
- 取模
- 一致性哈希
RPC-client需要進行升級。
例如:數據收集
如果要對RPC接口處理時間進行收集,來實施統一監控與告警,也需要對RPC-client進行升級。
畫外音,處理時間分為:
- 客戶端視角處理時間
- 服務端視角處理時間
如果要收集後者,RPC-server也要修改與上報。
又例如:服務發現
服務新增一個實例,通知配置中心,配置中心通知已註冊的RPC-client,將流量打到新啟動的服務實例上去,迅猛完成擴容。
再例如:調用鏈跟蹤
如果要做全鏈路調用鏈跟蹤,RPC-client和RPC-server都需要進行升級。
下面這些功能:
- 負載均衡
- 數據收集
- 服務發現
- 調用鏈跟蹤
- …
其實都不是業務功能,所以互聯網公司一般會有一個類似於“架構部”的技術部門去研發和升級相關功能,而業務線的技術部門直接使用相關框架、工具與平臺,享受各種“黑科技”帶來的便利。
完美!!!
理想很豐滿,現實卻很骨感,由於:
- RPC-client,它嵌在調用方進程裡
- RPC-server,是服務進程的基礎
往往會面臨以下一些問題:
- 業務技術團隊,仍需要花時間去學習、使用基礎框架與各類工具,而不是全心全意將精力花在業務和產品上
- client要維護m個版本, server要維護n個版本,兼容性要測試m*n個版本
- 如果要支持不同語言,往往要開發C-client,Python-client,go-client,Java-client多語言版本
- 每次“黑科技”的升級,都需要推動上下游進行升級,這個週期往往是以季度、半年、又甚至更久,整體效率極低
畫外音:兄弟,貴司推廣一個技術新產品,週期要多長?
這些耦合,這些通用的痛點,有沒有辦法解決呢?
一個思路是,將服務拆分成兩個進程,解耦。
- 一個進程實現業務邏輯(不管是調用方,還是服務提供方),biz,即上圖白色方塊
- 一個進程實現底層技術體系,proxy,即上圖藍色方塊
畫外音:負載均衡、監控告警、服務發現與治理、調用鏈…等諸多基礎設施,都放到這一層實現。
- biz和proxy共同誕生,共同消亡,互為本地部署,即上圖虛線方框
- biz和proxy之間,為本地通訊,即上圖黑色箭頭
- 所有biz之間的通訊,都通過proxy之間完成,proxy之間才存在遠端連接,即上圖紅色箭頭
這樣就實現了“業務的歸業務,技術的歸技術”,實現了充分解耦,如果所有節點都實現瞭解耦,整個架構會演變為:
- 綠色為biz
- 藍色為proxy
整個服務集群變成了網格狀,這就是Service Mesh服務網格的由來。
架構演進,永無窮盡,痛點多了,自然要分層解耦。希望大家有收穫,後續再細聊SM的設計與架構細節。
思路比結論更重要。
天下數據是國內屈指可數的擁有多處海外自建機房的新型IDC服務商,被業界公認為“中國IDC行業首選品牌”。
天下數據與全球近120多個國家頂級機房直接合作,提供包括香港、美國、韓國、日本、臺灣、新加坡、荷蘭、法國、英國、德國、埃及、南非、巴西、印度、越南等國家和地區的服務器、雲服務器的租用服務,需要的請聯繫天下數據客服!
除提供傳統的IDC產品外,天下數據的主要職責是為大中型企業提供更精細、安全、滿足個性需求的定製化服務器解決方案,特別是在直銷、金融、視頻、流媒體、遊戲、電子商務、區塊鏈、快消、物聯網、大數據等諸多行業,為廣大客戶解決服務器租用中遇到的各種問題。
閱讀更多 香港IDC 的文章