servicemesh去中心化

1. mesh組網原理

mesh組網原理是Mesh 客戶端通過無線連接的方式接入到無線 Mesh 路由器，無線 Mesh 路由器以多跳互連的形式，形成相對穩定的轉發網路。

在 WMN 的一般網路架構中，任意 Mesh 路由器都可以作為其他 Mesh 路由器的數據轉發中繼，並且部分 Mesh 路由器還具備網際網路網關的附加能力。網關 Mesh 路由器則通過高速有線鏈路來轉發 WMN 和網際網路之間的業務。

WMN 的一般網路架構可以視為由兩個平面組成，其中接入平面向 Mesh 客戶端提供網路連接，而轉發平面則在Mesh路由器之間轉發中繼業務。隨著虛擬無線介面技術在 WMN 中使用的增加，使得WMN 分平面設計的網路架構變得越來越流行。

(1)servicemesh去中心化擴展閱讀

Mesh網路的很多技術特點和優勢來自於其Mesh網狀連接和尋路，而路由轉發的設計則直接決定Mesh網路對其網狀連接的利用效率，影響網路的性能。在設計無線Mesh網路路由協議時要注意：

首先，不能僅根據「最小跳數」來進行路由選擇，而要綜合考慮多種性能度量指標，綜合評估後進行路由選擇；

其次，要提供網路容錯性和健壯性支持，能夠在無線鏈路失效時，迅速選擇替代鏈路避免業務提供中斷；

第三，要能夠利用流量工程技術，在多條路徑間進行負載均衡，盡量最大限度利用系統資源；

第四，要求能同時支持MP和Mesh STA。

常用的無線Mesh路由協議可參照Ad Hoc網路的路由協議，幾種典型的路由協議包括：動態源路由協議（DSR）、目的序列距離矢量路由協議（DSDV）、臨時按序路由演算法（TORA）和Ad Hoc按需距離矢量路由協議（AODV）等。

2. Service Mesh 淺析：從概念、產品到實踐

近幾年，微服務架構逐漸發展成熟，從最初的星星之火到現在大規模的落地和實踐，幾乎已經成為分布式環境下的首選架構。然而軟體開發沒有銀彈，基於微服務構建的應用系統在享受其優勢的同時，痛點也越加明顯。Service Mesh 技術也因此而生，受到越來越多的開發者關注，並擁有了大批擁躉。本文會從概念介紹開始，讓大家理解 Service Mesh 技術出現的原因以及願景；接著會對目前最主流的兩個產品 Istio 和 AWS App Mesh 進行詳細的比較；最後簡要介紹一下我們目前在該領域的一些探索與實踐。

Service Mesh - 服務通信的濟世良方

Service Mesh 是什麼？

Service Mesh（中文譯做服務網格）這一概念由 Buoyant 公司的 CEO，William Morg」n 首先提出。2017 年 4 月該公司發布了第一個 Service Mesh 產品 Linkerd，這篇同一時間發表的文章 What』s a service mesh？ And why do I need one? 也被業界公認是 Service Mesh 的權威定義。

「A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It』s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.」

其定義翻譯為：Service Mesh 是一個處理服務通訊的專門的基礎設施層。它的職責是在由雲原生應用組成服務的復雜拓撲結構下進行可靠的請求傳送。在實踐中，它是一組和應用服務部署在一起的輕量級的網路代理，對應用服務透明。這段話有點晦澀難懂，但只要抓住下面 4 個關鍵點就能輕松理解：

本質：基礎設施層

功能：請求分發

部署形式：網路代理

特點：透明

如果用一句話來總結，我個人對它的定義是：Service Mesh 是一組用來處理服務間通訊的網路代理。

為什麼需要 Service Mesh？

上面晦澀抽象的定義很難讓你真正理解 Service Mesh 存在的意義。你可能會想，服務間通信（service-to-service communication）無非就是通過 RPC、HTTP 這些方式進行，有什麼可處理的？沒錯，服務間只需要遵循這些標准協議進行交互就可以了，但是在微服務這樣的分布式環境下，分散的服務勢必帶來交互的復雜性，而規模越大的系統其通信越加錯綜復雜。 分布式計算下的 8 個謬論 很好的歸納了分布式環境下存在的網路問題。而為了解決這些問題，提高系統的容錯能力和可用性，出現了服務注冊與發現、負載均衡、熔斷、降級、限流等等和通信相關的功能，而這些才是 Service Mesh 要真正處理的問題。

Pattern：Service Mesh 這篇文章詳細的講述了微服務架構下通訊處理的演進，由此引出 Service Mesh 出現的意義和核心價值。下圖為服務通信演變的過程：

最初，流量管理和控制能力（比如圖例中的熔斷、服務發現）是和業務邏輯耦合在一起，即便以引用包的方式被調用，依然解決不了異構系統無法重用的問題。

流控功能和業務耦合相當不美好，於是出現了提供這些功能的公共庫和框架。但這些庫通常比較復雜，無論是學習使用，與業務系統整合、維護都會帶來很大的成本。

為避免花費太多時間開發和維護這些通用庫，人們希望流量控制能力可以下沉到網路通訊棧的層面，但幾乎無法實現。

於是另一種思路出現，就是將這些功能獨立成一個代理，由它先接管業務服務的流量，處理完成後再轉發給業務服務本身，這就是 Sidecar 模式。

為統一管理 Sidecar，該模式進一步進化，形成網路拓撲，增加了控制平面，演變成 Service Mesh（最後的網格圖中，綠色代表業務服務，藍色代表 sidecar 服務）。

可以說，Service Mesh 就是 Sidecar 的網路拓撲形態，Mesh 這個詞也由此而來。（關於 Sidecar 模式這里不做討論，你可以自行 Google）。

業務系統的核心價值應該是業務本身，而不是服務，微服務只是一種實現手段，實現業務才是目標。現有的微服務架構下，為解決可能出現的網路通信問題，提升系統的彈性，開發人員不得不花費大量時間和精力去實現流量控制相關的非業務需求，不能聚焦在業務本身。而 Service Mesh 的出現解決了這一問題，帶來了下面 2 個變革：

解決了微服務框架中的服務流量管理的痛點，使開發人員專注於業務本身；

將服務通信及相關管控功能從業務程序中分離並下層到基礎設施層，使其和業務系統完全解耦。

在雲原生應用中，面對數百個服務或數千個實例，單個業務鏈路的請求經由服務的拓撲路徑可能會非常復雜，單獨處理非常必要。這就是 Service Mesh 的意義所在。

Service Mesh 的主要功能

那麼 Service Mesh 到底能帶來哪些實用的功能呢？可以把它們歸納為下面 4 個部分：

流量控制：流控是最主要也是最重要的功能，通過 Service Mesh，我們可以為應用提供智能路由（藍綠部署、金絲雀發布、A/B test）、超時重試、熔斷、故障注入、流量鏡像等各種控制能力；

-安全：在安全層面上，授權和身份認證也可以託管給 Service Mesh；

策略：可以為流量設置配額、黑白名單等策略；

可觀察性：服務的可觀察性一般是通過指標數據、日誌、追蹤三個方式展現的，目前的 Service Mesh 產品可以很容易和和主流的後端設施整合，提供給應用系統完整的監控能力。

通過上面的講述，我相信 Service Mesh 的概念大家都已經有所了解。接下來我們來介紹兩個重要的網格產品，讓大家進一步了解 Service Mesh 的產品形態是什麼樣的。

Istio vs AWS App Mesh - 開源與閉環之爭

目前市面上比較成熟的開源服務網格主要有下面幾個：Linkerd，這是第一個出現在公眾視野的服務網格產品，由 Twitter 的 finagle 庫衍生而來，目前由 Buoyant 公司負責開發和維護；Envoy，Lyft 開發並且是第一個從 CNCF 孵化的服務網格產品，定位於通用的數據平面或者單獨作為 Sidecar 代理使用；Istio，由 Google、IBM、Lyft 聯合開發的所謂第二代服務網格產品，控制平面的加入使得服務網格產品的形態更加完整。

從今年的風向看，作為構建雲原生應用的重要一環，Service Mesh 已經被各大雲廠商認可，並看好它的發展前景。在 Istio 紅透半邊天的情況下，作為和 Google 在雲服務市場競爭的 Amazon 來說，自然不願錯失這塊巨大的蛋糕。他們在今年 4 月份發布了自己的服務網格產品：AWS App Mesh。這一部分內容我們會聚焦於 Istio 和 App Mesh 這兩個產品，通過橫向的對比分析讓大家對 Service Mesh 的產品形態和兩大雲廠商的策略有一個更深入的認識。

產品定位

從官方的介紹來看，Istio 和 App Mesh 都明確的表示自己是一種服務網格產品。Istio 強調了自己在連接、安全、控制和可視化 4 個方面的能力；而 App Mesh 主要強調了一致的可見性和流量控制這兩方面能力，當然也少不了強調作為雲平台下的產品的好處：託管服務，無需自己維護。

從某種程度上講，Istio 是一個相對重一點的解決方案，提供了不限於流量管理的各個方面的能力；而 App Mesh 是更加純粹的服務於運行在 AWS 之上的應用並提供流控功能。筆者認為這和它目前的產品形態還不完善有關（後面會具體提到）。從與 AWS 技術支持團隊的溝通中可以感覺到，App Mesh 應該是一盤很大的棋，目前只是初期階段。

核心術語

和 AWS 里很多產品一樣，App Mesh 也不是獨創，而是基於 Envoy 開發的。AWS 這樣的閉環生態必然要對其進行改進和整合。同時，也為了把它封裝成一個對外的服務，提供適當的 API 介面，在 App Mesh 這個產品中提出了下面幾個重要的技術術語，我們來一一介紹一下。

服務網格（Service mesh）：服務間網路流量的邏輯邊界。這個概念比較好理解，就是為使用 App mesh 的服務圈一個虛擬的邊界。

虛擬服務（Virtual services）：是真實服務的抽象。真實服務可以是部署於抽象節點的服務，也可以是間接的通過路由指向的服務。

虛擬節點（Virtual nodes）：虛擬節點是指向特殊工作組（task group）的邏輯指針。例如 AWS 的 ECS 服務，或者 Kubernetes 的 Deployment。可以簡單的把它理解為是物理節點或邏輯節點的抽象。

Envoy：AWS 改造後的 Envoy（未來會合並到 Envoy 的官方版本），作為 App Mesh 里的數據平面，Sidecar 代理。

虛擬路由器（Virtual routers）：用來處理來自虛擬服務的流量。可以理解為它是一組路由規則的封裝。

路由（Routes）：就是路由規則，用來根據這個規則分發請求。

上面的圖展示了這幾個概念的關系：當用戶請求一個虛擬服務時，服務配置的路由器根據路由策略將請求指向對應的虛擬節點，這些節點最終會與集群中某個對外提供服務的 DNS 或者服務名一一對應。

那麼這些 App Mesh 自創的術語是否能在 Istio 中找到相似甚至相同的對象呢？我歸納了下面的表格來做一個對比：

App MeshIstio

服務網格（Service mesh）Istio並未顯示的定義這一概念，我們可以認為在一個集群中，由Istio管理的服務集合，它們組成的網路拓撲即是服務網格。

虛擬服務（Virtual services）Istio中也存在虛擬服務的概念。它的主要功能是定義路由規則，使請求可以根據這些規則被分發到對應的服務。從這一點來說，它和App Mesh的虛擬服務的概念基本上是一致的。

虛擬節點（Virtual nodes）Istio沒有虛擬節點的概念，可以認為類似Kubernetes里的Deployment。

虛擬路由器（Virtual routers）Istio也沒有虛擬路由器的概念。

路由（Routes）Istio中的目標規則（DestinationRule）和路由的概念類似，為路由設置一些策略。從配置層面講，其中的子集（subset）和App Mesh路由里選擇的目標即虛擬節點對應。但Istio的目標規則更加靈活，也支持更多的路由策略。

從上面的對比看出，App Mesh 目前基本上實現了最主要的流量控制（路由）的功能，但像超時重試、熔斷、流量復制等高級一些的功能還沒有提供，有待進一步完善。

架構

AWS App Mesh 是一個商業產品，目前還沒有找到架構上的技術細節，不過我們依然可以從現有的、公開的文檔或介紹中發現一些有用的信息。

從這張官網的結構圖中可以看出，每個服務的橙色部分就是 Sidecar 代理：Envoy。而中間的 AWS App Mesh 其實就是控制平面，用來控制服務間的交互。那麼這個控制平面具體的功能是什麼呢？我們可以從今年的 AWS Summit 的一篇 PPT 中看到這樣的字樣：

控制平面用來把邏輯意圖轉換成代理配置，並進行分發。

熟悉 Istio 架構的朋友有沒有覺得似曾相識？沒錯，這個控制平面的職責和 Pilot 基本一致。由此可見，不管什麼產品的控制平面，也必須具備這些核心的功能。

那麼在平台的支持方面呢？下面這張圖展示了 App Mesh 可以被運行在如下的基礎設施中，包括 EKS、ECS、EC2 等等。當然，這些都必須存在於 AWS 這個閉環生態中。

而 Istio 這方面就相對弱一些。盡管 Istio 宣稱是支持多平台的，但目前來看和 Kubernetes 還是強依賴。不過它並不受限於單一的雲平台，這一點有較大的優勢。

Istio 的架構大家都比較熟悉，數據平面由 Envoy sidecar 代理組成，控制平麵包括了 Pilot、Mixer、Citadel、Galley 等控制項。它們的具體功能這里就不再贅述了，感興趣的同學可以直接去 官網 查看詳細信息。

功能與實現方式

部署

無論是 Istio 還是 App Mesh 都使用了控制平面+數據平面的模式，且 Sidecar 都使用了 Envoy 代理。Istio 的控制平面組件較多，功能也更復雜，1.0.x 版本完整安裝後的 CRD 有 50 個左右。架構修改後 Mixer 的一些 adapter 被獨立出去，crd 有所降低。下面是最新的 1.4 版本，安裝後仍然有 24 個 crd。

而 App Mesh 就簡單得多，只針對核心概念添加了如下 3 個 crd，用一個 controller 進行管理。

盡管 Istio 更多的 crd 在一定程度上代表了更加豐富的功能，但同時也為維護和 troubleshooting 增加了困難。

流量控制

盡管兩者的數據平面都基於 Envoy，但它們提供的流量控制能力目前還是有比較大的差距的。在路由的設置方面，App Mesh 提供了相對比較豐富的匹配策略，基本能滿足大部分使用場景。下面是 App Mesh 控制台里的路由配置截圖，可以看出，除了基本的 URI 前綴、HTTP Method 和 Scheme 外，也支持請求頭的匹配。

Istio 的匹配策略更加完善，除了上面提到的，還包括 HTTP Authority，埠匹配，請求參數匹配等，具體信息可以從官方文檔的虛擬服務設置查看。下面兩段 yaml 分別展示了兩個產品在虛擬服務配置上的差異。

App Mesh 配置：

Istio 配置：

另外一個比較大的不同是，App Mesh 需要你對不同版本的服務分開定義（即定義成不同的虛擬服務），而 Istio 是通過目標規則 DestinationRule 里的子集 subsets 和路由配置做的關聯。本質上它們沒有太大區別。

除了路由功能外，App Mesh 就顯得捉襟見肘了。就在筆者撰寫本文時，AWS 剛剛添加了重試功能。而 Istio 藉助於強大的 Envoy，提供了全面的流量控制能力，如超時重試、故障注入、熔斷、流量鏡像等。

安全

在安全方面，兩者的實現方式具有較大區別。默認情況下，一個用戶不能直接訪問 App Mesh 的資源，需要通過 AWS 的 IAM 策略給用戶授權。比如下面的配置是容許用戶用任意行為去操作網格內的任意資源：

因此，App Mesh 的授權和認證都是基於 AWS 自身的 IAM 策略。

Istio 提供了兩種認證方式，基於 mTLS 的傳輸認證，和 基於 JWT 的身份認證。而 Istio 的授權是通過 RBAC 實現的，可以提供基於命名空間、服務和 HTTP 方法級別的訪問控制。這里就不具體展示了，大家可以通過官網 文檔 來查看。

可觀察性

一般來說，可以通過三種方式來觀察你的應用：指標數據、分布式追蹤、日誌。Istio 在這三個方面都有比較完整的支持。指標方面，可以通過 Envoy 獲取請求相關的數據，同時還提供了服務級別的指標，以及控制平面的指標來檢測各個組件的運行情況。通過內置的 Prometheus 來收集指標，並使用 Grafana 展示出來。分布式追蹤也支持各種主流的 OpenTracing 工具，如 Jaeger、Zipkin 等。訪問日誌一般都通過 ELK 去完成收集、分析和展示。另外，Istio 還擁有 Kiali 這樣的可視化工具，給你提供整個網格以及微服務應用的拓撲視圖。總體來說，Istio 在可觀察方面的能力是非常強大的，這主要是因為 Mixer 組件的插件特性帶來了巨大的靈活性。

App Mesh 在這方面做的也不錯。從最新發布的 官方 repo 中，App Mesh 已經提供了集成主流監控工具的 helm chart，包括 Prometheus、Grafana、Jaeger 等。同時，AWS 又一次發揮了自己閉環生態的優勢，提供了與自家的監控工具 CloudWatch、X-Ray 的整合。總的來說，App Mesh 在對服務的可觀察性上也不落下風。

Amazon 與 Google 的棋局

AWS App Mesh 作為一個 2019 年 4 月份才發布的產品（GA），在功能的完整性上和 Istio 有差距也是情有可原的。從 App Mesh 的 Roadmap 可以看出，很多重要的功能，比如熔斷已經在開發計劃中。從筆者與 AWS 的支持團隊了解的信息來看，他們相當重視這個產品，優先順序很高，進度也比較快，之前還在預覽階段的重試功能在上個月也正式發布了。另外，App Mesh 是可以免費使用的，用戶只需要對其中的實例資源付費即可，沒有額外費用。對 AWS 來說，該產品的開發重點是和現有產品的整合，比如 Roadmap 列出的使用 AWS Gateway 作為 App Mesh 的 Ingress。藉助著自己的生態優勢，這種整合即方便快捷的完善了 App Mesh，同時又讓生態內的產品結合的更緊密，使得閉環更加的牢固，不得不說是一步好棋。

和 App Mesh 目前只強調流控能力不同，Istio 更多的是把自己打造成一個更加完善的、全面的服務網格系統。架構優雅，功能強大，但性能上受到質疑。在產品的更迭上貌似也做的不盡如人意（不過近期接連發布了 1.3 到 1.4 版本，讓我們對它的未來發展又有了期待）。Istio 的優勢在於 3 大頂級技術公司加持的強大資源，加上開源社區的反哺，利用好的話容易形成可持續發展的局面，並成為下一個明星級產品。然而 Google 目前對 Istio 的態度有一些若即若離，一方面很早就在自家的雲服務 gcloud 里提供了 Istio 的默認安裝選項，但同時又發布了和 Istio 有競爭關系的 Traffic director 這個託管的控制平面。筆者的猜測是 Google 也意識到 Istio 的成熟不可能一蹴而就，鑒於網格技術託管需求的越發強烈，先提供一個輕量化的產品以佔領市場。

目前各大廠商都意識到了網格技術的重要性並陸續推出了自己的產品（包括 AWS App Mesh，Kong 的 Kuma，國內的螞蟻金服、騰訊雲等），競爭也會逐漸激烈。未來是三分天下還是一統山河，讓我們拭目以待。

我們的實踐 - 從 Service Mesh 邁向雲原生

最後這部分給大家簡要介紹一下我們（FreeWheel）在 Service Mesh 領域的實踐。希望通過一些前瞻性的探索，總結出最佳實踐，為我們將來的微服務應用全面擁抱雲原生提供一定的經驗和指導。目前我們已經開發完成的 Data service 項目就整合了 AWS App Mesh，即將上線，並使用網格的能力進行智能路由和發布。

Data service 項目只包含兩個服務：Forecast service 和 Query service，前者作為業務服務通過 Query service 查詢來自持久層（ClickHouse）的數據；後者作為數據訪問代理，從持久層獲取數據並進行對象化的封裝。這個 mini 的微服務系統非常適合作為一個先行者為我們探索網格的功能、性能、易用性等方面的能力，且范圍足夠小，不會影響到其他業務系統。

選擇 AWS App Mesh 作為該項目的網格產品主要原因如下：

FreeWheel 是一個重度使用 AWS 各項服務的公司，未來所有的服務也都會全部託管的 AWS 上。作為一個閉環生態，App Mesh 可以和現有服務無縫整合，提高易用性；

相比 Istio 這樣還不太成熟的開源產品，我們可以得到 AWS 技術團隊的全力支持；

數據平面基於成熟高效的 Envoy，控制平面不存在 Istio 中的性能問題；

完全免費

下圖是該項目的部署視圖。前端請求從我們的業務系統 UIF 發送到 Forecast service，它作為 App Mesh 的一個虛擬節點，調用 Data service 進行數據查詢。Data service 作為數據平面，會注入 App Mesh 的 sidecar 代理。這兩個服務組成了一個 Mesh 網格，並無縫整合在 AWS 的 EKS 中。

下圖是網格內部的邏輯視圖，展示了如何利用 App Mesh 進行智能路由。Forecast service 作為調用者被定義為虛擬節點，Data service 作為虛擬服務，掛載著虛擬路由，內部根據需要可以設定若幹路由規則。用 App Mesh 實現一個金絲雀發布的過程非常簡單：假設在 Data service 的新版本（V2）發布前，流量都被指向 V1 版本；此時我們在 App Mesh 里配置好一個新的路由規則，將 10%的流量指向新的 V2 版本；只需要將新的規則通過 kubectl apply -f new-rule.yaml 應用到集群中，金絲雀發布就可以完成，且無縫切換，對用戶透明。

在後續的工作中，我們會先驗證 App Mesh 的性能和可靠性，然後逐漸的將更多的流量控制（如超時重試、熔斷等）功能添加進來，並總結出一整套可行的實施方案，供大家參考。也歡迎對 Service Mesh 感興趣的同學加入到我們的團隊中，一起學習，共同進步。

總結

解耦是軟體開發中永恆的主題，開發人員對消除重復的偏執是推動軟體、以及架構模式演進的主要動力。而 Service Mesh 的核心價值就是將服務通信功能從業務邏輯中解耦，並下沉為基礎設施，由控制平面統一管理。有人將 Service Mesh、Kubernetes 和 Serverless 技術稱為雲原生應用開發的三駕馬車。Kubernetes 是雲應用實際意義上的操作系統；Service Mesh 將服務通信功能剝離，實現了與業務的解耦；Serverless 讓你不用關心應用的伺服器。這三項技術讓我們有能力實現應用開發的終極目標，那就是：只關注業務本身。而它們，也會引領我們通向未來雲原生應用的詩和遠方。

3. 什麼是無線Mesh網路

無線Mesh網路即」無線網格網路」,它是「多跳（multi-hop）」網路，是由ad hoc網路發展而來，是一個動態的可以不斷擴展的網路架構，任意的兩個設備均可以保持無線互聯，呈現出明顯的去中心化態勢。

無線Mesh網路基於呈網狀分布的眾多無線接入點間的相互合作和協同，具有以下特點：

部署速度快，安裝簡單。無線Mesh網路中，除了少部分節點設備需要網線和AP連接外，絕大部分設備都只需要一根電源線，不需要和AP連接，所有數據都是無線傳輸的，降低了有線布局的難度，同時擴展靈活。

傳輸可靠性高。在無線Mesh網路中，由於其多跳網路的特性，一個節點可以連接至少兩個其他的節點，當某一個節點堵塞或者無響應時，無線Mesh網路可以根據情況選擇其他的節點進行數據轉播。換句話來說，就是無線Mesh網路擁有至少一條備用路徑，提升了數據傳輸的可靠性。

非視距傳輸。在無線Mesh網路中，每一個節點都相當於一個中繼器，相當於擴大了數據覆蓋的范圍，能夠為連接AP的節點視距之外的用戶提供網路，大幅度提高了無線網路的應用領域和覆蓋范圍。

盡管無線Mesh聯網技術有著廣泛的應用前景，但也存在一些影響它廣泛部署的問題：

通信延遲。既然在Mesh網路中數據通過中間節點進行多跳轉發，每一跳至少都會帶來一些延遲，隨著無線Mesh網路規模的擴大，跳接越多，積累的總延遲就會越大。一些對通信延遲要求高的應用，如話音或流媒體應用等，可能面臨無法接受的延遲過長的問題。

安全問題。與WLAN的單跳機制相比，無線Mesh網路的多跳機制決定了用戶通信要經過更多的節點。而數據通信經過的節點越多，安全問題就越變得不容忽視。

網路容量。實際應用中，由於mesh網路存在轉發，每次轉發之後速率都會降低，因此需要限制每個網路中節點的數量，否則會影響業務質量，即實際mesh網路中節點數量並非無限制增加。

4. API網關從入門到放棄

假設你正在開發一個電商網站，那麼這里會涉及到很多後端的微服務，比如會員、商品、推薦服務等等。

那麼這里就會遇到一個問題，APP/Browser怎麼去訪問這些後端的服務? 如果業務比較簡單的話，可以給每個業務都分配一個獨立的域名(https://service.api.company.com)，但這種方式會有幾個問題:

更好的方式是採用API網關，實現一個API網關接管所有的入口流量，類似Nginx的作用，將所有用戶的請求轉發給後端的伺服器，但網關做的不僅僅只是簡單的轉發，也會針對流量做一些擴展，比如鑒權、限流、許可權、熔斷、協議轉換、錯誤碼統一、緩存、日誌、監控、告警等，這樣將通用的邏輯抽出來，由網關統一去做，業務方也能夠更專注於業務邏輯，提升迭代的效率。

通過引入API網關，客戶端只需要與API網關交互，而不用與各個業務方的介面分別通訊，但多引入一個組件就多引入了一個潛在的故障點，因此要實現一個高性能、穩定的網關，也會涉及到很多點。

API 注冊

業務方如何接入網關?一般來說有幾種方式。

協議轉換

內部的API可能是由很多種不同的協議實現的，比如HTTP、Dubbo、GRPC等，但對於用戶來說其中很多都不是很友好，或者根本沒法對外暴露，比如Dubbo服務，因此需要在網關層做一次協議轉換，將用戶的HTTP協議請求，在網關層轉換成底層對應的協議，比如HTTP -> Dubbo, 但這里需要注意很多問題，比如參數類型，如果類型搞錯了，導致轉換出問題，而日誌又不夠詳細的話，問題會很難定位。

服務發現

網關作為流量的入口，負責請求的轉發，但首先需要知道轉發給誰，如何定址，這里有幾種方式:

服務調用

網關由於對接很多種不同的協議，因此可能需要實現很多種調用方式，比如HTTP、Dubbo等，基於性能原因，最好都採用非同步的方式，而Http、Dubbo都是支持非同步的，比如apache就提供了基於NIO實現的非同步HTTP客戶端。

因為網關會涉及到很多非同步調用，比如攔截器、HTTP客戶端、bbo、redis等，因此需要考慮下非同步調用的方式，如果基於回調或者future的話，代碼嵌套會很深，可讀性很差，可以參考zuul和spring cloud gateway的方案，基於響應式進行改造。

優雅下線

性能

網關作為所有流量的入口，性能是重中之重，早期大部分網關都是基於同步阻塞模型構建的，比如Zuul 1.x。但這種同步的模型我們都知道，每個請求/連接都會佔用一個線程，而線程在JVM中是一個很重的資源，比如Tomcat默認就是200個線程，如果網關隔離沒有做好的話，當發生網路延遲、FullGC、第三方服務慢等情況造成上游服務延遲時，線程池很容易會被打滿，造成新的請求被拒絕，但這個時候其實線程都阻塞在IO上，系統的資源被沒有得到充分的利用。另外一點，容易受網路、磁碟IO等延遲影響。需要謹慎設置超時時間，如果設置不當，且服務隔離做的不是很完善的話，網關很容易被一個慢介面拖垮。

而非同步化的方式則完全不同，通常情況下一個CPU核啟動一個線程即可處理所有的請求、響應。一個請求的生命周期不再固定於一個線程，而是會分成不同的階段交由不同的線程池處理，系統的資源能夠得到更充分的利用。而且因為線程不再被某一個連接獨占，一個連接所佔用的系統資源也會低得多，只是一個文件描述符加上幾個監聽器等，而在阻塞模型中，每條連接都會獨佔一個線程，而線程是一個非常重的資源。對於上游服務的延遲情況，也能夠得到很大的緩解，因為在阻塞模型中，慢請求會獨佔一個線程資源，而非同步化之後，因為單條連接所佔用的資源變的非常低，系統可以同時處理大量的請求。

如果是JVM平台，Zuul 2、Spring Cloud gateway等都是不錯的非同步網關選型，另外也可以基於Netty、Spring Boot2.x的webflux、vert.x或者servlet3.1的非同步支持進行自研。

緩存

對於一些冪等的get請求，可以在網關層面根據業務方指定的緩存頭做一層緩存，存儲到Redis等二級緩存中，這樣一些重復的請求，可以在網關層直接處理，而不用打到業務線，降低業務方的壓力，另外如果業務方節點掛掉，網關也能夠返回自身的緩存。

限流

限流對於每個業務組件來說，可以說都是一個必須的組件，如果限流做不好的話，當請求量突增時，很容易導致業務方的服務掛掉，比如雙11、雙12等大促時，介面的請求量是平時的數倍，如果沒有評估好容量，又沒有做限流的話，很容易服務整個不可用，因此需要根據業務方介面的處理能力，做好限流策略，相信大家都見過淘寶、網路搶紅包時的降級頁面。

因此一定要在接入層做好限流策略，對於非核心介面可以直接將降級掉，保障核心服務的可用性，對於核心介面，需要根據壓測時得到的介面容量，制定對應的限流策略。限流又分為幾種:

穩定性

穩定性是網關非常重要的一環，監控、告警需要做的很完善才可以，比如介面調用量、響應時間、異常、錯誤碼、成功率等相關的監控告警，還有線程池相關的一些，比如活躍線程數、隊列積壓等，還有些系統層面的，比如CPU、內存、FullGC這些基本的。

網關是所有服務的入口，對於網關的穩定性的要求相對於其他服務會更高，最好能夠一直穩定的運行，盡量少重啟，但當新增功能、或者加日誌排查問題時，不可避免的需要重新發布，因此可以參考zuul的方式，將所有的核心功能都基於不同的攔截器實現，攔截器的代碼採用Groovy編寫，存儲到資料庫中，支持動態載入、編譯、運行，這樣在出了問題的時候能夠第一時間定位並解決，並且如果網關需要開發新功能，只需要增加新的攔截器，並動態添加到網關即可，不需要重新發布。

熔斷降級

熔斷機制也是非常重要的一項。若某一個服務掛掉、介面響應嚴重超時等發生，則可能整個網關都被一個介面拖垮，因此需要增加熔斷降級，當發生特定異常的時候，對介面降級由網關直接返回，可以基於Hystrix或者Resilience4j實現。

日誌

由於所有的請求都是由網關處理的，因此日誌也需要相對比較完善，比如介面的耗時、請求方式、請求IP、請求參數、響應參數(注意脫敏)等，另外由於可能涉及到很多微服務，因此需要提供一個統一的traceId方便關聯所有的日誌，可以將這個traceId置於響應頭中，方便排查問題。

隔離

比如線程池、http連接池、redis等應用層面的隔離，另外也可以根據業務場景，將核心業務部署帶單獨的網關集群，與其他非核心業務隔離開。

網關管控平台

這塊也是非常重要的一環，需要考慮好整個流程的用戶體驗，比如接入到網關的這個流程，能不能盡量簡化、智能，比如如果是bbo介面，我們可以通過到git倉庫中獲取源碼、解析對應的類、方法，從而實現自動填充，盡量幫用戶減少操作；另外介面一般是從測試->預發->線上，如果每次都要填寫一遍表單會非常麻煩，我們能不能自動把這個事情做掉，另外如果網關部署到了多個可用區、甚至不同的國家，那這個時候，我們還需要介面數據同步功能，不然用戶需要到每個後台都操作一遍，非常麻煩。

這塊個人的建議是直接參考阿里雲、aws等提供的網關服務即可，功能非常全面。

其他

其他還有些需要考慮到的點，比如介面mock，文檔生成、sdk代碼生成、錯誤碼統一、服務治理相關的等，這里就不累述了。

目前的網關還是中心化的架構，所有的請求都需要走一次網關，因此當大促或者流量突增時，網關可能會成為性能的瓶頸，而且當網關接入的大量介面的時候，做好流量評估也不是一項容易的工作，每次大促前都需要跟業務方一起針對介面做壓測，評估出大致的容量，並對網關進行擴容，而且網關是所有流量的入口，所有的請求都是由網關處理，要想准確的評估出容量很復雜。可以參考目前比較流行的ServiceMesh，採用去中心化的方案，將網關的邏輯下沉到sidecar中，

sidecar和應用部署到同一個節點，並接管應用流入、流出的流量，這樣大促時，只需要對相關的業務壓測，並針對性擴容即可，另外升級也會更平滑，中心化的網關，即使灰度發布，但是理論上所有業務方的流量都會流入到新版本的網關，如果出了問題，會影響到所有的業務，但這種去中心化的方式，可以先針對非核心業務升級，觀察一段時間沒問題後，再全量推上線。另外ServiceMesh的方案，對於多語言支持也更友好。

5. mesh組網會因為某一方路由器性能的好壞影響wifi質量嗎

對於家用 Mesh網路的看法。 Mesh網路構架示意圖 如果要用一個詞來概括 Mesh的優勢,那就是「去中心化」。雙頻路由器的無線MESH組網，都會有衰減，因為要佔用無線帶寬進行組網，給終端的帶寬就不足了，

建議改橋接（中繼模式）
wifi統一，，如華為的AX3
或 /WS5200（雙頻（2.4GHz，5GHz）二百元）最高傳輸速率：1167Mbps

設置中繼模式：華為WS5200路由器設置無線橋接(Wi-Fi中繼)的方法。 無線橋接或者Wi-Fi中繼,指的是讓WS5200路由器,通過無線的方式,與另一個可以上網的路由器連接起來,

6. 基於ServiceMesh服務網格的去中心化微服務管控治理平台

首先說明下我最近在思考的一個產品規劃，即基於ServiceMesh服務網格思路，參考開源的Istio等實現架構來搭建一個完整的微服務治理管控平台。

在前面文章裡面我就提到了，在實施微服務架構後，由於微服務將傳統的單體應用進行了拆分，顆粒度更細。因此整個集成的復雜度，後續的管控治理復雜度都急劇增加。

當前也出現了類似SpingCLoud主流的微服務開發框架，實現了服務注冊和發現，安全，限流熔斷，鏈路監控等各種能力。同時對於服務注冊，限流，服務鏈監控等本身又出現了大量的開源組件，類似服務注冊的Nacos，Consul，限流熔斷的Sentinel，鏈接監控的SKyWalking等開源組件。

當我們在思考微服務開發框架和開源組件的時候你會發現。

在SpingCLoud外的各類開源組件本身和微服務開發過程是解耦的，也就是說這些開源組件更加方便地通過配置增加管控能力，或者通過下發一個SDK包或Agent代理組件來實現管控能力。以盡量減少對微服務開發過程的影響。

而對於SpingCLoud微服務框架，在使用中有一個最大的問題就是開發態和治理態的耦合，也就是說一個微服務模塊在開發的時候，你會引入很多治理態的內容。類似限流熔斷，類似鏈路監控等能力，都需要你在開發狀態增加配置文件，或對介面實現類進行擴展等。

微服務開發本身應該是一個簡單的事情。

其核心是實現業務功能和規則邏輯，並暴露輕量的Http Rest API介面實現和前端交互或者實現和其它微服務模塊之間的橫向交互協同。

也就是說如果不考慮管控治理層面的內容，你採用最小化的SpingBoot來進行微服務開發足夠的，或者你仍然可以採用傳統的Java架構進行微服務開發，只要確保最終暴露Http API介面即可。

但是如果要考慮治理的內容，你會發現會引入注冊中心，限流熔斷，安全，服務鏈監控一系列的管控治理組件，導致整個微服務開發過程，集成過程都復雜化。

因此構建微服務治理平台的初衷即：

在這里還是先簡單梳理下業務需求和業務功能場景。

01 服務注冊和服務發現

仍然需要實現最基本的當前微服務自注冊，自發現能力。這個在開發階段需要暴露的介面增加註解還是必須的。在ServiceMesh下，由於存在本地Sidecar代理，因此在本地代理和微服務一起容器化部署下去後，會掃描微服務中需要暴露的介面，並完成微服務和API介面服務的注冊工作。 也就是傳統的應用開發集成中，手工介面API介面服務注冊和接入的過程沒有了，這個過程應該徹底地自動化掉。

注意這里的注冊不僅僅是到微服務粒度，而是可以到微服務API介面粒度。

因此我們需要實現在微服務部署和交付後，微服務注冊和微服務中的API介面注冊全部自動完成。在微服務集群擴展的時候，相關的注冊信息和配置信息也自動更新和擴展。

一個微服務模塊在部署和交付後。

進入到微服務治理平台就能夠看到當前有哪些微服務已經注冊，進入到單個微服務裡面，就可以看到當前微服務究竟有哪些細粒度的API介面已經注冊。

02 服務安全和雙重管理

對於一個微服務暴露的API介面，可以看到部分API介面僅僅是提供給前端微服務使用，但是部分API介面是需要提供給其它橫向的微服務模塊使用。

一個是前端調用後端API介面，一個是後端各個微服務中心間介面交互。

在安全管理的時候實際需要對這兩類API介面分別進行管理。如果僅僅是前端功能使用，那麼類似JWT+Token的安全措施即可，同時對於的日誌流量並不一定需要完全記錄和入庫。如果是橫向微服務間調用，那麼安全要求更高，需要支持Token，用戶名密碼，IP地址驗證等多種安全管控要求。

對於前後端的使用，往往僅授權到微服務層級即可。但是對於橫向微服務間調用，那麼服務授權必須到API介面服務粒度， 能夠針對單個微服務API介面獨立授權和管理。

03 服務限流熔斷

同樣這個功能不應該在微服務開發階段進行任何配置或代碼文件的增加。

在微服務成功的部署和交付上線後，應該能夠針對微服務，微服務API介面兩個不同的顆粒度進行服務限流設置。當然需要支持類似並發量，時長，錯誤數，數據量等多種限流熔斷策略。

比如一個微服務單點能夠支撐的最大並發量是1000TPS，那麼這就是最基本的限流條件。我只需要設置單點能量，而不是設置集群能力。管控治理平台要管理的是通過負載均衡分發後到單個節點的流量能夠控制到1000TPS。如果你部署了5個微服務節點，那麼實際能夠支撐的最大流量就是5000TPS。

由於採用Mesh去中心化的架構模式，因此實際微服務間的調用數據流量並不會通過微服務治理平台，微服務治理平台本身並沒有太大的性能負荷壓力。這個是和傳統的ESB或API網關不同的地方，即API網關的限流一方面是保護API網關本身，一個是保護下游的微服務模塊。

04 介面調用日誌記錄

注意這個功能本身也是可以靈活配置的，可以配置單個微服務，也可以配置單個API介面服務是否記錄日誌，包括日誌記錄是只記錄調用時間和狀態，還是需要記錄想的介面調用消息報文數據。

在去中心化架構模式下，介面調用日誌記錄相對來說很容易實現。

即通過Sidecar邊車首先對消息和數據流量進行攔截，任何將攔截的數據統一推送到消息中間件，消息中間件再將日誌信息存入到分布式文件存儲或對象存儲中。

對於介面調用日誌本身應該區分日誌頭信息和消息日誌信息，對於日誌頭調用記錄信息應該還需要推送到類似ELK組件中，以方便進行關鍵日誌的審計和問題排查。

05 服務鏈路跟蹤和監控

注意，在傳統的服務鏈跟蹤中，需要在微服務端配置Agent代理。而採用Mesh化解決方案後，該部分代理能力也移動到了Sidecar邊車代理中實現。

服務鏈路監控不僅僅是微服務和API介面間的調用鏈路，也包括融入常規APM應用性能監控的能力，能夠實現前端界面操作後發起的整個應用鏈路監控。

應用鏈路監控一方面是進行日誌和錯誤分析，一方面是進行性能問題排查和優化。

06 和DevOps和容器雲的集成

簡單來說就是開發人員只需要按照標准規范開發單個微服務模塊，然後走DevOps持續集成和交付過程進行部署。

在和DevOps平台進行集成後，DevOps在進行自動化部署前會下發Sidecar代理邊車，實現對微服務本身的流量攔截和各種管控治理能力。在整個過程中Sidecar對開發者不可見，滿足最基本的服務透明要求。

在通過DevOps部署到容器雲平台後，滿足基於資源調度策略進行後續微服務集群資源的自動化動態擴展能力。同時微服務在擴展後自動進行相應的集群注冊，微服務API介面注冊等操作。

在傳統的SpingCLoud開發框架中，本身注冊中心包括了對微服務模塊的心跳檢查和節點狀態監控能力。在和Kurbernetes集群集成和融合後，完全可以採用Kurbernetes集群本身的心跳監控能力。

簡單總結

最後總結下，整個微服務治理平台基於ServiceMesh去中心化架構思路來定製，但是需要實現類似傳統ESB匯流排或API網關的所有管控治理能力。

對於最終的使用者來說並不關心治理能力實現是否是去中心化架構，而更加關心兩個點。第一個點是開發階段不要引入治理要求，第二就是能夠實現核心能力的集中化管控和可靈活配置擴展。

也就是你可能上層看到的是一個傳統的SOA治理管控平台，但是底層卻是採用了去中心化的ServiceMesh架構來實現微服務治理管控能力。

7. 無線mesh原理

無線Mesh網路即」無線網格網路」,它是「多跳（multi-hop）」網路，是由ad hoc網路發展而來，是一個動態的可以不斷擴展的網路架構，任意的兩個設備均可以保持無線互聯，呈現出明顯的去中心化態勢。

無線Mesh網路基於呈網狀分布的眾多無線接入點間的相互合作和協同，具有以下特點：

部署速度快，安裝簡單。無線Mesh網路中，除了少部分節點設備需要網線和AP連接外，絕大部分設備都只需要一根電源線，不需要和AP連接，所有數據都是無線傳輸的，降低了有線布局的難度，同時擴展靈活。

傳輸可靠性高。在無線Mesh網路中，由於其多跳網路的特性，一個節點可以連接至少兩個其他的節點，當某一個節點堵塞或者無響應時，無線Mesh網路可以根據情況選擇其他的節點進行數據轉播。換句話來說，就是無線Mesh網路擁有至少一條備用路徑，提升了數據傳輸的可靠性。

非視距傳輸。在無線Mesh網路中，每一個節點都相當於一個中繼器，相當於擴大了數據覆蓋的范圍，能夠為連接AP的節點視距之外的用戶提供網路，大幅度提高了無線網路的應用領域和覆蓋范圍。

盡管無線Mesh聯網技術有著廣泛的應用前景，但也存在一些影響它廣泛部署的問題：

通信延遲。既然在Mesh網路中數據通過中間節點進行多跳轉發，每一跳至少都會帶來一些延遲，隨著無線Mesh網路規模的擴大，跳接越多，積累的總延遲就會越大。一些對通信延遲要求高的應用，如話音或流媒體應用等，可能面臨無法接受的延遲過長的問題。

安全問題。與WLAN的單跳機制相比，無線Mesh網路的多跳機制決定了用戶通信要經過更多的節點。而數據通信經過的節點越多，安全問題就越變得不容忽視。

網路容量。實際應用中，由於mesh網路存在轉發，每次轉發之後速率都會降低，因此需要限制每個網路中節點的數量，否則會影響業務質量，即實際mesh網路中節點數量並非無限制增加。

8. Service Mesh概述

第一代微服務架構 Spring Cloud ，基於SDK/開發框架的微服務治理體系。

第二代微服務架構 Service Mesh（服務網格），基於透明代理的服務治理體系。

Service Mesh的優勢：是微服務時代的通信層。Buoyant的CEO William Morgan，也就是Service Mesh這個詞的發明人，對Service Mesh的定義：
服務網格是一個 基礎設施層，用於處理服務間通信 。雲原生應用有著復雜的服務拓撲，服務網格 保證請求在這些拓撲中可靠地穿梭 。在實際應用當中，服務網格通常是由一系列輕量級的 網路代理 (可以看成Nginx)組成的，它們與應用程序部署在一起，但 對應用程序透明 。

9. mesh組網原理

mesh組網原理：WMN由三類不同的無線網元組成：網關路由器（具有網關/網橋功能的路由器），Mesh路由器（接入點）和Mesh 客戶端（移動端或其他）。

其中，Mesh 客戶端通過無線連接的方式接入到無線 Mesh 路由器，無線 Mesh 路由器以多跳互連的形式，形成相對穩定的轉發網路。

在 WMN 的一般網路架構中，任意 Mesh 路由器都可以作為其他 Mesh 路由器的數據轉發中繼，並且部分 Mesh 路由器還具備網際網路網關的附加能力。網關 Mesh 路由器則通過高速有線鏈路來轉發 WMN 和網際網路之間的業務。

WMN 的一般網路架構可以視為由兩個平面組成，其中接入平面向 Mesh 客戶端提供網路連接，而轉發平面則在Mesh路由器之間轉發中繼業務。隨著虛擬無線介面技術在 WMN 中使用的增加，使得WMN 分平面設計的網路架構變得越來越流行。

10. 溯源微服務：企業分布式應用的一次回顧

微服務作為架構風格幾乎成為雲時代企業級應用的事實標准，構成微服務的技術元素本身卻並非革命性。跨平台的分布式通信框架、地址無關的服務注冊與發現、智能路由與編排等技術早已在CORBA、SOA時代實現了一遍又一遍，我們不禁好奇，微服務有什麼不同？本文是對企業分布式應用的一次回顧，與前微服務時代相比，我們究竟在哪些領域吸取了教訓，哪些方面持續搞砸。

架構的關鍵在於構造合理的封裝抽象。良好的抽象構造如進程，由操作系統接管CPU調度、內存地址空間分配和I/O，程序員的心智從此解放，得以聚焦在業務邏輯上。糟糕的抽象往往引向萬丈深淵，大量精力被浪費在抽象泄露帶來的問題上。

讓我們從組件間的通信開始，最初人們認為這只是需要被解決的技術要素。

關於如何實現跨平台的分布式通信，30年前誕生的CORBA架構在今天來看仍然非常漂亮：通過定義IDL/ORB/API我們可以將內存對象任意分布於網路中。只要共享IDL，對象可以由C++/Java等不同的語言實現，其互相調用就像本地方法一樣簡單。然而實踐經驗告訴我們，分布式系統總是會出現本地調用不會發生的各種問題：網路的開銷、傳輸的延遲、消息的超時和丟包、遠端系統的崩潰……物理世界的技術約束是無法被忽略的，我們沒有辦法把分布式調用抽象成簡單的本地方法。因此Martin Fowler在他的< 企業應用架構模式>里提出了著名分布式對象第一定律：「不要分布式你的對象」。相反，你應該把盡可能多的操作置於進程之內，通過replicate整個應用的方式來實現系統的scale。

由分析師們發起的SOA運動從另一個角度看待這個問題，Web Service應該是對企業資產和業務能力的封裝。我們開始站在更高的維度，遠過程調用不再只是技術意義上的集成。WSDL不僅是通信調用的介面，更是服務間的契約；UDDI不僅是服務描述、發現、集成的中心，更是企業業務與服務的黃頁。WS-*在廠商的裹挾下發展成包羅萬象，卻也沒幾個人能掌握。開發者們抱怨花了太多時間寫冗餘的XML制定所謂的規范，WSDL生成的客戶端也將不同服務耦合在一起。是否有更加輕量敏捷的方式，讓我們快點開始寫第一行生產代碼？

於是我們看到REST的興起。起初是作為反叛，用更加輕量級的方式(http+json)使用Web。然後我們發現」企業級」應用並非需要ESB這樣昂貴的專有中間件，由」消費級」技術組成的萬維網是世界上最大規模的分布式網路，我們應該向其學習如何構建健壯、可演化的系統。Roy Fielding那篇論文所提出的無狀態、可緩存等特徵已經深入人心，而狹義上的REST API(基於資源的URI、HTTP動詞和狀態碼的標准介面)也成為API設計的最佳實踐。

既然API和網站一樣都是基於通用Web技術，API是否可以像網站一樣作為產品提供呢(APIs as proct)？於是越來越多的企業開始將自己的業務能力封裝成API，提供給消費者，隨之而來的是更彈性的商業應用和更靈活的計費方式。很多組織也著手構建自己的API市場，把內部IT能力整合、復用，並為孵化外部產品做准備。API已經成為商業價值主張的一部分。

我們從聚焦實現細節的rpc出發，來到了更具價值導向的REST API。即使構建內部系統，以消費者驅動的方式，也總是能幫助我們設計出更加松耦合和易於演進的API。

編程語言中的組件構造(如Java中的jar, C#中的dll)是軟體架構師們封裝可復用單元的最常用武器。組件作為理論上的最小部署單元，在工程實踐中卻並不容易獨立變更。一般應用程序需要講多個組件打包成一個部署單元(如war包)，鏈接在內存地址中進行調用。對單個組件的熱更新往往對組件間耦合和對象狀態管理有很高的要求，重新部署整個應用一般是默認選項。以進程為邊界構建可獨立部署的服務成為架構師的另一項選擇。

早期的服務只是單純的技術構件，大多數組織從純粹的技術實現角度考慮服務的劃分。SOA的推動者們指出企業的信息資產應該被復用，信息孤島應該被打通。通過將不同的服務編排組合，我們應該能夠實現IT對業務更加靈活的支撐。

SOA的服務建模一般採用業務流程驅動的方式。一個典型的SOA設計是由業務分析師自頂向下地對企業現有業務流程進行分析，通過BPM引擎對流程進行建模，向下分解成組合服務，並進一步拆分成數據訪問服務(很多可憐的SOA實現中數據的訪問被拆分成不同的讀服務和寫服務)。然而這帶來的問題是，服務跟服務間的耦合非常嚴重。當我的業務發生了變化，可能會需要修改很多不同的服務，涉及到多個團隊的溝通和協調。在運行時層面，伺服器間的通信非常頻繁，用戶在界面上的一次點擊按鈕，對應的後台多層服務間的級聯通信。這給系統性能和穩定性也帶來了巨大的挑戰。SOA式的服務建模從分析型思維出發，卻往往低估了分布式系統和跨團隊協調的復雜度，導致服務拆分粒度過細。

微服務的名字常常讓人誤解，但實施正確的微服務粒度可能並不」微」。Martin Fowler與James Lewis在開創微服務定義的一文中已經指出微服務應該圍繞完整的業務能力。今天我們在做微服務設計時，常常利用領域驅動設計中的Bounded Context來進行服務邊界的劃分。假設你的庫存管理是一個獨立的業務子域，針對庫存的維護和操作應該被放到通過一個上下文和微服務中，由一個團隊進行開發維護。多數業務變更都發生在上下文內部，不涉及跨團隊協調。單個codebase內的重構和部署讓發布更加容易。維護庫存所需要的信息查詢的調用多發生在進程內，更好的性能，同時無需處理額外的一致性問題。

如今我們對服務的定義已經超越了技術組件，領先的組織已經在嘗試將design thinking, business operating model應用到微服務設計中。

即使有了設計合理的服務於API，我們仍然需要與之匹配的工程實踐才能將其順利實施。

今天仍有很多企業使用集中式的應用伺服器部署應用：開發團隊將軟體包構建出來，再統一安裝到應用伺服器中。對應用團隊來說，這往往意味著漫長的反饋周期和痛苦的自動化。我們很早就推薦用Jetty這樣內嵌式的應用容器部署軟體，啟動更快，測試環境更接近生產。one Tomcat per VM的部署方式雖然運行時開銷較大，卻是前容器時代隔離性最好的服務部署模式。Docker將這個實踐更進一步，除了更輕量級的隔離，我們第一次可以將軟體和所依賴的環境本身打包成版本化的artifact，徹底統一開發和生產環境。容器技術的成熟讓我們可以將部署去中心化，開發團隊可以獨立部署一個服務。

資料庫耦合是影響服務獨立變更的另一重要因素。相比代碼構成的應用軟體，資料庫schema更加難以變動。因為難以測試、難以兼顧性能優化和耦合的發布周期等因素，服務間以資料庫集成成為臭名昭著的反模式。服務間的集成應該依賴封裝好的顯示介面，而不是資料庫這種實現細節。我們應該在兼顧數據一致性的情況下，為每個微服務分配獨立的db schema甚至db instance。如果說十年前數據幾乎等同於關系資料庫。如今數 據則可能呈現出各種形態：鍵值、文檔、時間序列、圖…我們完全可以採用更加合適的技術，以去中心化的方式進行微服務的數據治理。

即使將這一切都解耦，如果將交給一個集中的團隊去實施，很有可能最終還是得到一個耦合的架構。這就是是著名的康威定律。康威定律告訴我們「設計系統的架構受制於產生這些設計的組織的溝通結構」。但同樣我們可以將康威定律反轉應用：如果你想達成一個目標架構，則必須對團隊結構進行調整，使之和目標架構對齊。相比單體系統，微服務在運行時監控和運維所帶來的挑戰更大。」you build it, you run it」的DevOps文化成為必須。監控運維不再是Ops部門的事情，產品團隊必須對微服務的整個生命周期負責。授權的去中心化自治團隊是實施微服務的必要條件。

我們在很多方向的確取得了進展。但即使在微服務時代，很多問題仍然在輪回發生著，似乎我們總是無法吸取 歷史 的教訓。讓我們看一看那些揮之不去的反模式陰雲。

另一個揮之不去的陰影是ESB。ESB在將異構的應用wire在一起有著關鍵的作用。然而當越來越多的職責被加入：數據報文的裁剪轉換、難以測試和版本控制的編排(orchection)邏輯、服務發現智能路由監控治理分布式事務等All in One的solution將ESB變成了一個可怕的單點夢魘。所以微服務發出了「智能終端啞管道」的吶喊：我們只是需要一個不那麼智能的代理處理可靠消息傳輸，將靈活的邏輯交給服務本身去編配(choreography)吧。

於是在典型的微服務架構里，負載均衡、服務注冊發現、分布式追蹤等組件以Unix way的方式各司其職。然而在利益誘惑和特性競爭壓力之下，很多廠商不斷將更多的功能放進他們的中間件，其中為代表的Overambitious API gateways儼然要重新實現占據中心的ESB。如果API gateway只是處理鑒權、限流等橫切層邏輯沒有問題，如果API gateway開始處理數據轉換和業務邏輯編排，你應該提高警惕！

盡管行業在不斷發展，但很多時候人們仍然沿用舊的思維，用新的技術去一遍遍重新實現這些舊的反模式。

你總是可以在技術雷達里追蹤微服務的state of art，如今這個領域的前沿方向是什麼，Service Mesh, Chaos Engineering, 還是Observability as Code？然而 歷史 告訴我們，新的技術在解決一些問題的同時，也可能會產生新的問題。更糟糕的是，我們永遠無法記住 歷史 ，用新的工具更高效地重現舊日問題。

Technologies come and go, Principles stay forever。好在那些架構和實踐背後的原則是經久不變的。從操作系統到移動應用都會需要高內聚低耦合的架構，任何軟體開發都需要版本控制、自動化構建等實踐。謹記這些核心原則、謹記軟體被創造出來是為了解決有價值的問題，可以幫我們更好的借鑒 歷史 的經驗，理解和採納新的技術。

文/ThougtWorks劉尚奇

本文首發於劉尚奇個人網站：https://6up7.com/a-retrospective-for-enterprise-distributed-application/