1、2018/6/12極客時間 | 左耳聽風管理設計篇之"網關模式"2018-05-03前面，我們講了 Sidecar 和 Service Mesh 這兩個設計模式，這兩種設計模式都是在不侵入業務邏輯的情況下，把 面（control plane）和數據面（data plane）的處理解耦分離。但是這兩種模式都讓我們的運維成本變得特別大，因為每個服務都需要一個 Sidecar，這讓本來就復雜的分布式系統的架構就更為復雜和難以 。在談 Service Mesh 的時候，我們提到了 Gateway。我個人覺得并不需要為每個服務的實例都配置上一個 Sidecar。其實，一個服務集群配上

2、一個 Gateway 就可以了，或是一組類似的服務配置上一個 Gateway。這樣一來，Gateway 方式下的架構，可以細到為每一個服務的實例配置上一個 的Gateway，也可以粗到為一組服務配置一個，甚至可以粗到為整個架構配置一個接入的Gateway。于是，整個系統架構的復雜度就會變得簡單可控起來。1/9管理設計篇之"網關模式"朗讀人： 1616 | 7.45M2018/6/12極客時間 | 左耳聽風這張圖展示了一個多層 Gateway 架構，其中有一個總的 Gateway 接入所有的流量，并分發給不同的子系統，還有第二級 Gateway 用于做各個子系統的接入 Gat

3、eway。可以看到，網關所管理的服務粒度可粗可細。通過網關，我們可以把分布式架構組織成一個星型架構，由網絡對服務的請求進行路由和分發，也可以架構成像 Servcie Mesh 那樣的網格架構，或者只是為了適配某些服務的 Sidecar但是，我們也可以看到，這樣一來，Sidecar 就不再那么輕量了，而且很有可能會變得比較重了。總的來說，Gateway 是一個服務器，也可以說是進入系統的唯一節點。這跟面向對象設計模式中的 Facade 模式很像。Gateway 封裝內部系統的架構，并且提供 API 給各個客戶端。它還可能有其他功能，如授權、監控、負載均衡、緩存、熔斷、降級、限流、請求分片和管理、

4、靜態響應處理，等等。下面，我們來談談一個好的網關應該有哪些設計功能。網關模式設計一個網關需要有以下的功能。請求路由。因為不再是 Sidecar 了，所以網關必需要有請求路由的功能。這樣一來，對于調用端來說，也是一件非常方便的事情。因為調用端不需要知道自己需要用到的其它服務的地址，全部統一地交給 Gateway 來處理。服務注冊。為了能夠代理后面的服務，并把請求路由到正確的位置上，網關應該有服務注冊功能，也就是后端的服務實例可以把其提供服務的地址注冊、取消注冊。一般來說，注冊也就是注冊一些 API 接口。比如，HTTP 的 Restful 請求，可以注冊相應的 API 的 URI、方https:

5、//column/article/60862/92018/6/12極客時間 | 左耳聽風法、HTTP 頭。 這樣，Gateway 就可以根據接收到的請求中的信息來決定路由到哪一個后端的服務上。負載均衡。因為一個網關可以接多個服務實例，所以網關還需要在各個對等的服務實例上做 負載均衡策略。簡單的就直接是 round robin 輪詢，復雜點的可以設置上權重進行分發，再復雜一點還可以做到 session 粘連。彈力設計。網關還可以把彈力設計中的那些異步、重試、冪等、流控、熔斷、監視等都可以實現進去。這樣，同樣可以像 Service Mesh 那樣，讓應用服務只關心

6、 的業務邏輯（或是說數據面上的事）而不是 邏輯（ 面）。安全方面。SSL 加密及 管理、Session 驗證、 、數據校驗，以及對請求源進行的防范。錯誤處理越靠前的位置就是越好，所以，網關可以做到一個全站的接入組件來對后端的服務進行保護。當然，網關還可以做 的更有趣的事情，比如：灰度發布。網關完全可以做到對相同服務不同版本的實例進行導流，并還可以收集相關的數 據。這樣對于軟件質量的提升，甚至 試錯都有非常積極的意義。API 聚合。使用網關可將多個單獨請求聚 一個請求。在微服務體系的架構中，因為服務變小了，所以一個明顯的問題是，客戶端可能需要多次請求才能得到所有的數據。這樣一來，客戶端與后端之間

7、的頻繁通信會對應用程序的性能和規模產生非常不利的影響。于是， 我們可以讓網關來幫客戶端請求多個后端的服務（有些場景下完全可以并發請求），然后把 后端服務的響應結果拼裝起來，回傳給客戶端（當然，這個過程也可以做成異步的，但這需要客戶端的配合）。API 編排。同樣在微服務的架構下，要走完一個完整的業務流程，我們需要調用一系列API，就像一種工作流一樣，這個事完全可以通過網頁來編排這個業務流程。我們可能通過一 個 DSL 來定義和編排不同的 API，也可以通過像 AWS Lambda 服務那樣的方式來串聯不同的 API。Gateway、Sidecar 和 Service Mesh通過上面的描述，我們

8、可以看到，網關、 和 Service Mesh 是非常像的三種設計模式，很容易 。因此，我在這里想明確一下這三種設計模式的特點、場景和區別。首先，Sidecar 的方式主要是用來改造已有服務。我們知道，要在一個架構中實施一些架構變更時，需要業務方一起過來進行一些改造。然而業務方的事情比較多，像架構上的變更會低優先級 處理，這就導致架構變更的 " 政治復雜度 " 太大。而通過 Sidecar 的方式，我們可以適配應用服務，成為應用服務進出請求的 。這樣，我們就可以干很多對于業務方完全透明的事情了。3/92018/6/12極客時間 | 左耳聽風當 Sidecar 在架構中越來越

9、多時，需要我們對 Sidecar 進行統一的管理。于是，我們為 Sidecar 增加了一個全局的中心 器，就出現了我們的 Service Mesh。在中心 器出現以后，我們發現，可以把非業務功能的東西全部實現在 Sidecar 和 Controller 中，于是就成了一個網格。業務方只需要把服務往這個網格中一放就好了，與其它服務的通訊、服務的彈力等都不用管了， 像一個服務的 PaaS 平臺。然而，Service Mesh 的架構和部署太過于復雜，會讓我們運維層面上的復雜度變大。為了簡化這個架構的復雜度，我認為 Sidecar 的粒度應該是可粗可細的，這樣更為方便。但我認為， Gateway 更

10、為適合，而且 Gateway 只負責進入的請求，不像 Sidecar 還需要負責對外的請求。因為 Gateway 可以把一組服務給聚合起來，所以服務對外的請求可以交給對方服務的Gateway。于是，我們只需要用一個只負責進入請求的 Gateway 來簡化需要同時負責進出請求的 Sidecar 的復雜度。總而言之，我覺得 Gateway 的 Sidecar 和 Service Mesh 更好。當然，具體問題還要具體分析。網關的設計重點高性能。在技術設計上，網關不應該也不能成為性能的瓶頸。對于高性能，最好使用高性能 的編程語言來實現，如 C、C+、Go 和 Java。網關對后端的請求，以及對前端的

11、請求的服務一定要使用異步非阻塞的 I/O 來確保后端延遲 導致應用程序中出現性能問題。C 和C+ 可以參看 Linux 下的 epoll 和 Windows 的 I/O Completion Port 的異步 IO 模型， Java 下如 Netty、Vert.x、Spring Reactor 的 NIO 框架。當然，我還是更喜歡 Go 語言的goroutine 加 channel 。高可用。因為所有的流量或調用經過網關，所以網關必須成為一個高可用的技術組件，它的 穩定直接關系到了所有服務的穩定。網關如果沒有設計，就會成變一個單點故障。因此，一 個好的網關至少要做到以下幾點。集群化。網關要成為

12、一個集群，其最好可以 組成一個集群，并可以 同步集群數據，而不需要依賴于一個第 來同步數據。服務化。網關還需要做到在不間斷的情況下修改配置，一種是像 Nginx reload 配置那樣，可以做到不停服務，另一種是最好做到服務化。也就是說，得要有 的 Admin API 來在運行時修改 的配置。持續化。比如重啟，就是像 Nginx 那樣優雅地重啟。有一個主管請求分發的主進程。當我們需要重啟時，新的請求被分配到新的進程中，而老的進程處理完正在處理的請求后 就 。高擴展。因為網關需要承接所有的業務流量和請求，所以一定會有或多或少的業務邏輯。而 我們都知道，業務邏輯是多變和不確定的。比如，需要在網關上

13、加上一些和業務相關的東4/92018/6/12極客時間 | 左耳聽風西。因此，一個好的 Gateway 還需要是可以擴展的，并能進行二次開發的。當然，像Nginx 那樣通過 Module 進行二次開發的固然可以。但我還是覺得應該做成像 AWS Lambda 那樣的方式，也就是所謂的 Serverless 或 FaaS（Function as a Service）那樣的方式。運維方面。網關應該有以下的設計原則。業務松耦合，協議緊耦合。在業務設計上，網關不應與后面的服務之間形成服務耦合， 也不應該有業務邏輯。網關應該是在 應用層上的組件，不應該處理通訊協議體，只應該 和處理通訊協議頭。另外，除了服

14、務發現 關不應該有第 服務的依 賴。應用監視，提供分析數據。網關上需要考慮應用性能的 ，除了有相應后端服務的高可用的統計之外，還需要使用 Tracing ID 實施分布式鏈路跟蹤，并統計好一定時間內每個 API 的吞吐量、響應時間和返回碼，以便啟動彈力設計中的相應策略。用彈力設計保護后端服務。網關上一定要實現熔斷、限流、重試和超時等彈力設計。如 果一個或多個服務調用花費的時間過長，那么可接受超時并返回一部分數據，或是返回 一個網關里的緩存的上一次 請求的數據。你可以考慮一下這樣的設計。DevOps。因為網關這個組件太關鍵了，所以需要 DevOps 這樣的東西，將其發生故障的概率降到最低。這個軟

15、件需要經過精良的測試，包括功能和性能的測試，還有浸泡測 試。還需要有一系列自動化運維的管控工具。架構方面。有如下一些注意事項。不要在網關中的代碼里內置聚合后端服務的功能，而應考慮將聚合服務放在網關 代碼之外。可以使用 Plugin 的方式，也可以放在網關后面形成一個 Serverless 服務。網關應該靠近后端服務，并和后端服務使用同一個內網，這樣可以保證網關和后端服務 調用的低延遲，并可以減少很多 上的問題。這里多說一句，網關處理的靜態內容應該靠近用戶（應該放到 CDN 上），而網關和此時的動態服務應該靠近后端服務。網關也需要做容量擴展，所以需要成為一個集群來分擔前端帶來的流量。這一點，要么

16、通過 DNS 輪詢的方式實現，要么通過 CDN 來做流量調度，或者通過更為底層的性能更高的負載均衡設備。對于服務發現，可以做一個時間不長的緩存，這樣不需要每次請求都去查一下相關的服 務所在的地方。當然，如果你的系統不復雜，可以考慮把服務發現的功能直接集成進網 關中。5/92018/6/12極客時間 | 左耳聽風為網關考慮 bulkhead 設計方式。用不同的網關服務不同的后端服務，或是用不同的網關服務前端不同的客戶。安全方面。因為網關成了為用戶請求和后端服務的橋接裝置，所以需要考慮一些 的東西。加密數據。可以把 SSL 相關的 放到網關上，由網關做統一的 SSL 傳輸管理。校驗用戶的請求。一些

17、基本的用戶驗證可以放在網關上來做，比如用戶是否已登錄，用戶請求中的 token 是否合法等。但是，我們需 衡一下，網關是否需要校驗用戶的輸入。因為這樣一來，網關就需要從只關心協議頭，到需要關心協議體。而協議體中的東西一方面不像協議頭是標準的，另一方面 協議體還要耗費大量的運行時間，從而降低網關的性能。對此， 說的是，看具體需求，一方面如果協議體是標準的，那么可以干；另一方面，對于 協議所帶來的性能問題，需要做相應的 。檢測異常 。網關需要檢測一些異常 ，比如，在一段比較短的時間內請求次數超過一定數值；還比如，同一客戶端的 4xx 請求出錯率太高對于這樣的一些請求訪問，網關一方面要把這樣的請求

18、掉，另一方面需要發出警告，有可能會是一些比較的安全問題，如被 。小結好了，我們來總結一下今天 的主要內容。首先，網關模式能代替 模式，區別是它將分布在各個服務邊上的 換成了集中式的網關。網關不必管理所有服務節點，而是可以根據需要， 為指定的服務集群配上網關，也可以在網關前面加上更 的網關，從而構造出一個星型的結 構。接著，我列舉了網關模式的功能特性。然后，我 了網關模式的設計重點。由于網關的功能比較多，因此在設計上要考慮的點也比較多，需要我們仔細思考和斟酌。下篇文章中，我們講述部署升級策略。希望對你有幫助。也歡迎你 一下你接觸到的分布式系統有沒有用到網關？網關的功能如何？有沒有把服務的彈力設計

19、做在里面？文末給出了分布式系統設計模式系列文章的目錄，希望你能在這個列表里找到 感 的內容。彈力設計篇認識故障和彈力設計 設計 Bulkheads異步通訊設計 Asynchronous6/92018/6/12極客時間 | 左耳聽風冪等性設計 Idempotency 服務的狀態 State補償事務 Compensating Transaction 重試設計 Retry熔斷設計 Circuit Breaker 限流設計 Throttle降級設計 degradation 彈力設計總結管理設計篇分布式鎖 Distributed Lock配置中心 Configuration Management 模式

20、Sidecar服務網格 Service Mesh 網關模式 Gateway部署升級策略性能設計篇緩存 Cache異步處理 Asynchronous 數據庫擴展秒殺 Flash Sales邊緣計算 Edge Computing歸 科技所有， 不得7/92018/6/12極客時間 | 左耳聽風精選留言microshaoft微服務之間的"內部"互相調用是否經過gateway2018-05-033Ken一直對服務聚合有比較多的疑問，聚合可能包括以下三種情況，假設后端服務A和B。第一 種：簡單的A+B的返回，第二種：A+B返回還需進一步數據轉換再返回，第三種：需要先訪 問A，依賴A的

21、結果再調用B。以上三種方式，哪些適合在網關層聚合處理？網關聚合處理有 什么比較好的參考實現？2018-05-032nut1一下我們用到的網關，工作中內網微服務主要是HSF，而網關對我們來說，是服務對外開放給外部用戶的 ，他幫我們實現了軟件商的資格審核備案，API調用權限管理，用戶和軟件商的 ，調用健康度管理，用戶緯度的限流熔斷，API內部協議和外部協議之間的轉換，全球 專線的優化，API緯度的 告警。大家工作中的網關都是什么用途呢？2018-05-15（美麗人生）晚上好，我們最近想開發一個這樣的SaaS軟件，用戶可以綁定不同的郵件帳號（如0和163等），可以在我們的郵箱里接收郵件，也可以 郵件，并且用戶的郵件也需要 在我們的服務器上（數據安全及數據同步策略），這方面有有一些開源的項目可以做二次開發 嗎?如果沒有，能否講講郵件服務器開發方面的 技術及思路呢?如果有相關的資料，也可以推薦給我。萬分感謝，盼復！2018-05-07Ken一直糾