聊一聊微網關與服務嚙合
現在越來越多的大型組織在向更加自組織的團隊結構轉型，這些團隊擁有并運營自己的微服務，但他們如何在不依賴集中式托管的基礎架構下，確保服務之間必要的一致性與兼容性呢?為了確保服務之間的有效協作，即使是自組織的微服務也需要與一些組織標準對齊。服務嚙合(SERVICE MESH)在服務發現、安全、跟蹤、監控與故障處理方面提供了一致性，且不需要像API網關或ESB這樣的共享資產。服務嚙合的一個典型實現包含輕量級反向代理進程，這些進程可能伴隨每個服務進程一起被部署在單獨的容器中。反向代理會和服務注冊表、身份提供者和日志聚合器等進行通信。通過該代理的共享實現(而非共享的運行時實例)，我們可以獲得服務的互操作性和可觀測性。一段時間以來，我們一直主張去中心化的微服務管理方法，也很高興看到服務嚙合這種一致性模式的出現。隨著linkerd和Istio等開源項目的成熟，服務嚙合的實現將更加容易。
新瓶舊酒還是厚積薄發?
對于持續關注云服務架構設計***發展趨勢的同學來說，剛過去的2017年，最火的詞莫過于CNCF了，這是一個專注于“云原生”(Cloud Native)的基金會，由眾多戰斗在云服務一線的公司(包括了谷歌、AWS、阿里云等等)組建而來，旨在推進云原生的架構標準化與***實踐的普及。
最近，“云原生”(Cloud Native)和 “微服務”(Microservices)也引出了許多相關的技術，隨著 Kubernetes、Docker 等一眾容器管理工具的普及，我們也看到在容器的內部，微服務的架構設計也發生著一些變化，其中“服務嚙合”(Service Mesh)就成為了大家關注的熱點。
那么這些變化到底是新瓶舊酒，還是厚積薄發?我們不妨先從一個更耳熟能詳的架構——“網關”(Gateway)談起。
網關(Gateway)的作用
作為微服務工具鏈中的元老，“網關”(Gateway) 的引入為微服務API提供統一的入口和平臺，不同的服務可以得到一致的管理。使用網關的架構可以減少企業大量的重復開發。甚至有一些通用的邏輯也可以使用網關來承載(如Zuul、Enovy、OpenResty等)。
不論初心為何，這些網關們隨著時光流轉，功能也變得越來越豐富，網關可以負責解決不同服務的服務注冊發現、負載均衡、配額流控、監控日志、緩存加速、配置分離、安全管控、跟蹤審計等問題。這一系列的功能，我們可以大致分為兩類：“數據面”和“控制面”。
數據面(Data Plane)負責在數據包粒度上進行篩選和處理：
- 路由轉發
- 負載均衡
- 安全通信
- 緩存加速
- 認證鑒權
- 日志審計
- 健康檢查
- 熔斷限流
控制面(Control Plane)負責在服務粒度上進行統籌和管理：
- 注冊發現
- 配置管控
- 彈性伸縮
- 統籌遙測
- 容錯自愈
- 策略執行
- 證書簽發
這一系列的功能，就是網關面臨的問題域。在了解問題域之后，讓我們回歸本篇的主題：繼承了“網關”(Gateway)衣缽的“微網關”(MicroGateway)和“服務嚙合”(Service Mesh)，它們到底是什么?
什么是微網關?
隨著微服務的普及，傳統的中心化網關變得越來越厚重，由于與中心化節點通信，帶來了大量網絡、IO開銷以及單點問題，往往無法滿足我們對于實時性、高可用的要求。另外越來越多的自治化需求，與原有集權式微服務治理方法之間，也產生出許多沖突矛盾。因此，與微服務化相適應的，可以本地化、分布式部署的微網關(MicroGateway)也逐漸涌現出來。
什么是服務嚙合?
服務嚙合(Service Mesh)是一種為了保證“服務到服務”的安全、快速和可靠的通信而產生的基礎架構層，區別于應用層、通信層的一種新的云原生上下文內的抽象層。如果你正在構建云原生的應用程序，在微服務拓撲結構日益復雜的今天，服務嚙合層的提出，可以幫助開發者將服務的交互通信問題與微服務內部的業務問題隔離開來，專注于各自的領域。
演進中的微網關與服務嚙合
當我們了解到微網關與服務嚙合的作用之后，就可以一起來看一下微網關與服務嚙合架構是如何一步步設計出來的。
1. 低侵入性組件(Low-Invasive Component)
最初的服務間互訪，常常由于業務尚不清晰，給標準化帶來了障礙。因此我們常常見到一些由領域專家提供的低侵入性的組件，為服務的開發者提供抽象的規范，使其能輕松獲得定制化能力。
組件可以更好地規范問題，并且盡可能地將組件封裝為簡單的接口，早期的服務發現常常通過該類方式實現，例如 Eureka 套件通過引入 Client 來獲得完整的如報告、監控、熔斷等能力。
我們在一些 IAM (Identity Access Management)的服務設計中采用了這種模式，為各個業務服務提供了一致的認證鑒權接口，由領域專家驅動，設計規范化的調用模式。由于該類組件盡可能設計為低侵入性的接口，因此微服務團隊也可以更加便利地根據不同場景取舍是否使用該組件提供的功能，例如通過配置文件加 feature toogle 簡單地在開發環境中關閉認證鑒權的功能，以加快開發進程。
2. 反向代理(Reverse Proxy)
隨著服務成熟度的提高，我們可以發現一些常見的非業務強相關的邏輯，可以從原有的服務中剝離出來，通過反向代理統一進行過濾處理。
反向代理，可以為微服務處理請求的前后環節增添通用邏輯，例如 apigee 提供的 API proxy 封裝，通過反向代理模式為原有的服務添加 PreFlow、PostFlow，解決請求生命周期前后常見的問題，例如檢查配額和記錄調用頻度，對 CORS 等 Http Header 的添加和消費，這些功能有些類似于傳統的 Filter 模型，但是卻可以獨立部署。
反向代理可以提供更高的可用性，并幫助微服務開發者從這些常見細節中解脫出來。
3. 側車模式(Sidecar Pattern)
準確來說，側車模式(Sidecar Pattern)本身并非微網關或者服務嚙合技術獨有，它只是一種特定的軟件模塊共生關系。側車模式可以是一個反向代理，也可以作為一個服務存在。
作為反向代理使用的Sidecar進程可以過濾請求與返回內容，實現如安全通信、認證鑒權、服務端/客戶端負載均衡、自動路由等功能。
作為服務使用的Sidecar進程可以為主服務提供額外能力，實現分布式緩存同步、配置文件拉取、日志搜集等功能。
側車模式常見于分布式緩存和安全基礎設施網關，通過與微服務進程共同啟停的服務或容器，可以更方便地與微服務一并調度，享受微服務管理平臺本身提供的服務發現、注冊、配置、擴容能力。通過共享生命周期，在簡單部署和靈活應用中尋找一個平衡。
我們在微服務框架 Jhipster 提供的基礎能力中，可以直接通過注解使用 Hazelcast 的分布式緩存，正是通過 Sidecar 模式實現的，擁有共生的分布式緩存實例后，可輕松實現服務接口的緩存，而分布式緩存自身的同步策略等問題都被封裝在 Sidecar 進程中，無需開發者花費大量時間重新開發和調試。Sidecar也可以用于實現例如OAuth等安全相關的守護服務，幫助微服務處理業務界限外的專項問題。
4. 原生的基礎設施(Native Infrastructure)
服務嚙合帶來的***的不同就是原生無感知，通過側車模式部署的反向代理，與一些容器系統級的配置結合，更徹底地解決微服務在數據面與管理面的能力一致性問題。
服務嚙合框架 Istio 提供了 Istio-Initializer 和 istioctl 工具，你可以在Kubernetes的容器整備過程中，注入所需的配置和 Envoy 容器，將Sidecar Proxy、Sidecar Service注冊為容器集群中的原生服務，可以在享受彈性部署的同時，享受數據面和控制面協同提供的標準化能力。無痛地加入Istio提供的功能，如 iptables 代理轉發、雙向TLS認證、限流策略、日志收集等等。
我們在設計服務嚙合層時也可以考慮使用更原生的服務組織與部署策略，例如將微服務容器注冊為系統服務、通過控制流對容器進行編排、盡可能與微服務共享生命周期和運行環境來提高可用性與性能等等。
從現在開始，擁抱微服務的云原生生態
既是新瓶舊酒，又是厚積薄發，云原生趨勢下的微服務也在不斷的演進，逐漸變成我們最初希望的“會呼吸”的模樣。我們建議您考慮在一些適用的場景，尤其是微服務化的架構設計中，考慮使用微網關與服務嚙合，并總結***實踐與我們交流。
讓我們一起期待云原生生態下的微服務，為數字化時代提供更多的想象力。
【本文是51CTO專欄作者“ThoughtWorks”的原創稿件，微信公眾號：思特沃克，轉載請聯系原作者】
