雲世 公衆号
在“自己動手用 Go 實作 Service Mesh”這個大的子產品中，會帶你動手用 Go 語言實作一套簡單的 Service Mesh 系統，以加強你對 Service Mesh 原理的掌握和了解。在編寫代碼之前，這一講我們先來講一下項目背景，包括為什麼要進行自研、自研 Service Mesh 的優勢、自研 Service Mesh 可以解決哪些問題，以及項目架構的初步搭建等内容。
首先，我們先來看一下這個項目的背景。假定你所在的 B 公司目前已經初具規模，正在進行從單體服務到微服務的初步拆分，公司的主要語言為 Go 語言，同時存在 Python、Node.js、PHP 等多種語言。
項目背景
公司的 X 項目目前已經初具規模，随着人員的擴張，從單體服務拆解到了多個子服務。但現在遇到了一些問題，急需解決方案。該項目目前面臨如下困難。
- 入口層缺乏統一的系統網關：多個服務同時對外暴露，無法進行統一的登入驗證、加/解密等功能，隻能在各個對外暴露的服務中單獨實作，無法進行統一的維護。
- 存在雪崩現象：某一個核心微服務出現故障後，導緻級聯故障，依賴的服務因為響應延時變高，都将出現故障，最終導緻整站故障。
- 無法處理突發流量：很多時候因為營運活動，前期沒有配合提前擴容資源, 導緻服務被突發流量打挂。
- 内部通過内網集中網關調用：内部通過統一的網關調用，一旦内部集中網關出現問題，導緻所有服務出現故障，繼而引起整站故障。
- 項目可觀測性不足，問題排查困難：各個服務自己實作監控名額，沒有統一的監控，随着服務數量增多，問題越來越難以排查。
鑒于以上多種問題，已經影響了線上 App 的穩定性，急需技術手段解決。
下面我們針對上述問題，進行技術選型，調研以下幾種解決方案，包括微服務架構、開源 Service Mesh 方案、自研 Service Mesh 方案。
以下三種方案，通過服務治理的方式，都可以解決上述問題，其中微服務架構需要再引入一個開源系統網關或者用架構實作聚合層。下面我們來看幾種常見的架構選型。
技術選型
微服務架構
【了解更多DDD系列課程，搜尋 雲世 公衆号擷取】
微服務架構在 Web 架構的基礎上，增加了服務治理、注冊發現、可觀測性、負載均衡、RPC 等多種功能，目的是提高微服務架構的穩定性。
優點：
- 通過服務發現的方式直接調用 upstream 服務，無須經過中間代理層，性能高；
- 微服務架構相對比較成熟。
缺點：
- 架構維護更新成本高，微服務的拆分會導緻服務數量非常多，一旦架構釋出，後續更新幾乎不可能完成；
- 舊服務接入困難，修改代碼成本高；
- 語言相關，一般情況下隻能維護一種語言的微服務架構，對于小衆語言無法支援。
總結：
相對來說 Go 語言的微服務架構并不算豐富，更多架構還停留在 Web 方面，比如 Gin、Echo 都是出色的 Web 架構。如果是新項目，微服務架構 go-zero 是相對不錯的選擇。
開源 Service Mesh 方案
開源 Service Mesh 方案，我們在前面章節“技術選型：在衆多 Service Mesh 開源産品中選擇合适自己的”中，已經做了詳細講解，這裡我們還是通過一張技術方案對比圖做一個簡單的回顧：
下面我們對開源 Service Mesh 方案的優缺點也做一個簡單的總結。
優點：
- 相對于微服務架構，通過和業務架構解耦的方式，降低了更新維護的成本；
- 新舊服務接入同樣簡單，可以通過 iptables 網絡劫持無感覺方式接入，也可以通過修改少量代碼支援；
- 語言無關性，公司的小衆語言也可以很好地支援；
- 可以持續跟進社群方案，獲得社群的最新成果；
- 項目啟動快，不需要研發，隻需要做好測試。
缺點：
- 代碼二次擴充難度比較大，需要特定的語言開發經驗，公司個性化的需求無法滿足；
- 開源軟體往往版本變化比較大，向前相容性比較差，如果想要維護更新，也需要對源碼有一定的掌握，否則更新風險比較大。
總結：
開源 Service Mesh 方案最大的優勢是和社群貼近，項目啟動快，但也有二次擴充的瓶頸，難以滿足公司的個性化需求。
自研 Service Mesh 方案
自研 Service Mesh 方案分為兩種，一種是資料面 Sidecar 和控制面全部自研，另外一種是使用開源資料面，但是自研或者二次開發控制面。
- 完全自研
我們先來看一下資料面和控制面完全自研的方案。
優點：
- 具備開源 Service Mesh 方案相對于微服務架構的優勢；
- 可擴充性強，可以相容公司運維環境，對于一些定制型需求，比如新的 RPC 協定支援、多協定服務治理、新的負載均衡支援等；
- 項目把控力強，出現問題可以快速解決。
缺點：
- 研發成本高，需要一定的研發時間，上線灰階到穩定版本也需要時間，在灰階過程中可能會有 Bug 出現；
- 和社群有一定的割裂。
- 開源資料面+自研控制面
因為公司運維環境的原因，直接使用開源控制面方案基本上無法滿足控制面個性的需求，比如第三方注冊中心的支援、虛拟機環境的支援等。下面看一下這種方案的優缺點。
優點：
- 可以滿足公司多樣的運維環境；
- 控制面自研或者二次開發，有一定的定制性。
缺點：
- 資料面 Sidecar 依然有開源方案的弊端。
- 首先于資料面無法定制，其次對于控制面能做的關聯有一定的局限性。
最終選擇
結合以上調研，最終我們決定選擇資料面和控制面都自研的 Service Mesh 方案。相對于上述缺點，完全自研的方案可控性和可擴充性都很出色，對比微服務架構方案又有維護更新成本低、相容多種語言等優勢。
至此，我們的方案已經确定了。下面我們來看一下技術實作部分，具體包括資料面和控制面需要實作的功能點，以及技術選型，如何依靠開源社群的力量快速實作核心功能。
技術實作
下面我們來看一下本次方案要實作的功能點，因為篇章有限，這裡隻講解最核心的部分。具體的資料面和控制面的實作部分，接下來的兩講我們将詳細展開。
功能點
資料面 Sidecar：
- 實作基礎架構，能夠代理 HTTP 協定，并具備擴充性；
- 支援限流、熔斷等服務治理中間件；
- 支援可觀測性元件，包括 Log、Trace 和 Metrics；
- 支援服務注冊和發現，能夠代理業務服務進行注冊；
- 通過 xDS 和控制面通信。
控制面：
- 同時相容虛拟機和 Kubernetes，和公司現有的 CMDB 系統打通，同步機器中繼資料。
- 支援 xDS 協定，相容現有的、采用 xDS 協定的資料面。
技術選型
為了快速實作，這裡我們就不從頭設計架構層了，經過調研，Go-Micro 架構完全可以滿足我們資料面 Sidecar 的需求，其本身也支援了多種協定。（Go-Micro 項目位址https://github.com/asim/go-micro）
控制面 Envoy 也提供了基礎架構，為了降低複雜度，我們不使用 Istio 二次開發，直接用 Envoy 提供的控制面基礎架構來開發。（位址為https://github.com/envoyproxy/go-control-plane）
總結
今天我們主要了解了自研 Service Mesh 項目的原因，對比了微服務架構和多種開源 Service Mesh 方案，結合項目的背景現狀确定了自研 Service Mesh 的方案。
本講内容總結如下：
根據今天内容的講解，結合公司項目背景，如果讓你選擇合适的方案，你會做出何種選擇呢，是選用微服務架構還是開源Service Mesh 方案，抑或和我一樣選擇自研的方案呢？
歡迎你關注【雲世】公衆号，在留言區分享你的觀點。
雲世
【雲世】專注職場人的硬實力和軟技能提升。為産品上雲，微服務和雲原生前沿技術和落地實踐布道，分享微服務架構、容器、K8s、Service Mesh等雲技術幹貨、案例、經驗；持續釋出職場做事方法論、團隊管理、讀書筆記，好書推薦等軟技能。
公衆号
今天的内容到這裡就結束了，下一講我們講解資料面：基于 Go-Micro 快速實作代理子產品，在這一講會實作一個 Sidecar，然後結合代碼講解，幫助你從源碼出發更好地了解 Service Mesh 資料面的原理。
更多“service mesh”系列課程，在 雲世 公衆号搜尋：
微服務的問題、微服務架構選型、微服務技術選型、servicemesh架構、servicemesh自研架構優缺點