建站
咨詢
售后
建站咨詢
新聞中心
服務(wù)網(wǎng)格(ServiceMesh)這兩年異常之火，號稱是下一代微服務(wù)架構(gòu)，接下來兩個月，準備系統(tǒng)性的寫寫這個東西，希望能夠讓大家對架構(gòu)技術(shù)，有個初步的了解。
為茫崖等地區(qū)用戶提供了全套網(wǎng)頁設(shè)計制作服務(wù)，及茫崖網(wǎng)站建設(shè)行業(yè)解決方案。主營業(yè)務(wù)為成都做網(wǎng)站、網(wǎng)站建設(shè)、外貿(mào)營銷網(wǎng)站建設(shè)、茫崖網(wǎng)站設(shè)計，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務(wù)。我們深信只要達到每一位用戶的要求，就會得到認可，從而選擇與我們長期合作。這樣，我們也可以走得更遠！
畫外音：我的行文的風(fēng)格了，“為什么”往往比“怎么樣”更重要。
互聯(lián)網(wǎng)公司，經(jīng)常使用的是微服務(wù)分層架構(gòu)。
畫外音：為什么要服務(wù)化，詳見《服務(wù)化到底解決什么問題?》。
隨著數(shù)據(jù)量不斷增大，吞吐量不斷增加，業(yè)務(wù)越來越復(fù)雜，服務(wù)的個數(shù)會越來越多，分層會越來越細，除了數(shù)據(jù)服務(wù)層，還會衍生出業(yè)務(wù)服務(wù)層，前后端分離等各種層次結(jié)構(gòu)。
不斷發(fā)現(xiàn)主要矛盾，抽離主要矛盾，解決主要矛盾，架構(gòu)自然演進了，微服務(wù)架構(gòu)，潛在的主要矛盾會是什么呢?
引入微服務(wù)架構(gòu)，一般會引入一個RPC框架，來完成整個RPC的調(diào)用過程。
如上圖粉色部分所示，RPC分為：
- RPC-client，它嵌在調(diào)用方進程里
- RPC-server，是服務(wù)進程的基礎(chǔ)
不只是微服務(wù)，MQ也是類似的架構(gòu)：
如上圖粉色部分所示，MQ分為：
- MQ-send-client
- MQ-server
- MQ-recv-client
框架只是開始，越來越多和RPC，和微服務(wù)相關(guān)的功能，會被加入進來。
例如：負載均衡
如果要擴展多種負載均衡方案，例如：
- 輪詢
- 隨機
- 取模
- 一致性哈希
RPC-client需要進行升級。
例如：數(shù)據(jù)收集
如果要對RPC接口處理時間進行收集，來實施統(tǒng)一監(jiān)控與告警，也需要對RPC-client進行升級。
畫外音，處理時間分為：
- 客戶端視角處理時間
- 服務(wù)端視角處理時間
如果要收集后者，RPC-server也要修改與上報。
又例如：服務(wù)發(fā)現(xiàn)
服務(wù)新增一個實例，通知配置中心，配置中心通知已注冊的RPC-client，將流量打到新啟動的服務(wù)實例上去，迅猛完成擴容。
再例如：調(diào)用鏈跟蹤
如果要做全鏈路調(diào)用鏈跟蹤，RPC-client和RPC-server都需要進行升級。
下面這些功能：
- 負載均衡
- 數(shù)據(jù)收集
- 服務(wù)發(fā)現(xiàn)
- 調(diào)用鏈跟蹤
- …
其實都不是業(yè)務(wù)功能，所以互聯(lián)網(wǎng)公司一般會有一個類似于“架構(gòu)部”的技術(shù)部門去研發(fā)和升級相關(guān)功能，而業(yè)務(wù)線的技術(shù)部門直接使用相關(guān)框架、工具與平臺，享受各種“黑科技”帶來的便利。
理想很豐滿，現(xiàn)實卻很骨感，由于：
- RPC-client，它嵌在調(diào)用方進程里
- RPC-server，是服務(wù)進程的基礎(chǔ)
往往會面臨以下一些問題：
- 業(yè)務(wù)技術(shù)團隊，仍需要花時間去學(xué)習(xí)、使用基礎(chǔ)框架與各類工具，而不是全心全意將精力花在業(yè)務(wù)和產(chǎn)品上
- client要維護m個版本， server要維護n個版本，兼容性要測試m*n個版本
- 如果要支持不同語言，往往要開發(fā)C-client，Python-client，go-client，Java-client多語言版本
- 每次“黑科技”的升級，都需要推動上下游進行升級，這個周期往往是以季度、半年、又甚至更久，整體效率極低
畫外音：兄弟，貴司推廣一個技術(shù)新產(chǎn)品，周期要多長?
這些耦合，這些通用的痛點，有沒有辦法解決呢?
一個思路是，將服務(wù)拆分成兩個進程，解耦。
- 一個進程實現(xiàn)業(yè)務(wù)邏輯(不管是調(diào)用方，還是服務(wù)提供方)，biz，即上圖白色方塊
- 一個進程實現(xiàn)底層技術(shù)體系，proxy，即上圖藍色方塊
畫外音：負載均衡、服務(wù)發(fā)現(xiàn)與治理、調(diào)用鏈…等諸多基礎(chǔ)設(shè)施，都放到這一層實現(xiàn)。
- biz和proxy共同誕生，共同消亡，互為本地部署，即上圖虛線方框
- biz和proxy之間，為本地通訊，即上圖黑色箭頭
- 所有biz之間的通訊，都通過proxy之間完成，proxy之間才存在遠端連接，即上圖紅色箭頭
這樣就實現(xiàn)了“業(yè)務(wù)的歸業(yè)務(wù)，技術(shù)的歸技術(shù)”，實現(xiàn)了充分解耦，如果所有節(jié)點都實現(xiàn)了解耦，整個架構(gòu)會演變?yōu)椋?/p>
- 綠色為biz
- 藍色為proxy
整個服務(wù)集群變成了網(wǎng)格狀，這就是Service Mesh服務(wù)網(wǎng)格的由來。
架構(gòu)演進，永無窮盡，痛點多了，自然要分層解耦。希望大家有收獲，后續(xù)再細聊SM的設(shè)計與架構(gòu)細節(jié)。
思路比結(jié)論更重要。
【本文為專欄作者“58沈劍”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者】
當(dāng)前文章：ServiceMesh究竟解決什么問題？
文章出自：http://fisionsoft.com.cn/article/cdepipo.html
