63管理設(shè)計(jì)篇之網(wǎng)關(guān)模式

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

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

3、eway?？梢钥吹?，網(wǎng)關(guān)所管理的服務(wù)粒度可粗可細(xì)。通過網(wǎng)關(guān)，我們可以把分布式架構(gòu)組織成一個星型架構(gòu)，由網(wǎng)絡(luò)對服務(wù)的請求進(jìn)行路由和分發(fā)，也可以架構(gòu)成像 Servcie Mesh 那樣的網(wǎng)格架構(gòu)，或者只是為了適配某些服務(wù)的 Sidecar但是，我們也可以看到，這樣一來，Sidecar 就不再那么輕量了，而且很有可能會變得比較重了。總的來說，Gateway 是一個服務(wù)器，也可以說是進(jìn)入系統(tǒng)的唯一節(jié)點(diǎn)。這跟面向?qū)ο笤O(shè)計(jì)模式中的 Facade 模式很像。Gateway 封裝內(nèi)部系統(tǒng)的架構(gòu)，并且提供 API 給各個客戶端。它還可能有其他功能，如授權(quán)、監(jiān)控、負(fù)載均衡、緩存、熔斷、降級、限流、請求分片和管理、

4、靜態(tài)響應(yīng)處理，等等。下面，我們來談?wù)勔粋€好的網(wǎng)關(guān)應(yīng)該有哪些設(shè)計(jì)功能。網(wǎng)關(guān)模式設(shè)計(jì)一個網(wǎng)關(guān)需要有以下的功能。請求路由。因?yàn)椴辉偈?Sidecar 了，所以網(wǎng)關(guān)必需要有請求路由的功能。這樣一來，對于調(diào)用端來說，也是一件非常方便的事情。因?yàn)檎{(diào)用端不需要知道自己需要用到的其它服務(wù)的地址，全部統(tǒng)一地交給 Gateway 來處理。服務(wù)注冊。為了能夠代理后面的服務(wù)，并把請求路由到正確的位置上，網(wǎng)關(guān)應(yīng)該有服務(wù)注冊功能，也就是后端的服務(wù)實(shí)例可以把其提供服務(wù)的地址注冊、取消注冊。一般來說，注冊也就是注冊一些 API 接口。比如，HTTP 的 Restful 請求，可以注冊相應(yīng)的 API 的 URI、方https:

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

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

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

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

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

10、為適合，而且 Gateway 只負(fù)責(zé)進(jìn)入的請求，不像 Sidecar 還需要負(fù)責(zé)對外的請求。因?yàn)?Gateway 可以把一組服務(wù)給聚合起來，所以服務(wù)對外的請求可以交給對方服務(wù)的Gateway。于是，我們只需要用一個只負(fù)責(zé)進(jìn)入請求的 Gateway 來簡化需要同時負(fù)責(zé)進(jìn)出請求的 Sidecar 的復(fù)雜度?？偠灾?，我覺得 Gateway 的 Sidecar 和 Service Mesh 更好。當(dāng)然，具體問題還要具體分析。網(wǎng)關(guān)的設(shè)計(jì)重點(diǎn)高性能。在技術(shù)設(shè)計(jì)上，網(wǎng)關(guān)不應(yīng)該也不能成為性能的瓶頸。對于高性能，最好使用高性能 的編程語言來實(shí)現(xiàn)，如 C、C+、Go 和 Java。網(wǎng)關(guān)對后端的請求，以及對前端的

11、請求的服務(wù)一定要使用異步非阻塞的 I/O 來確保后端延遲 導(dǎo)致應(yīng)用程序中出現(xiàn)性能問題。C 和C+ 可以參看 Linux 下的 epoll 和 Windows 的 I/O Completion Port 的異步 IO 模型， Java 下如 Netty、Vert.x、Spring Reactor 的 NIO 框架。當(dāng)然，我還是更喜歡 Go 語言的goroutine 加 channel 。高可用。因?yàn)樗械牧髁炕蛘{(diào)用經(jīng)過網(wǎng)關(guān)，所以網(wǎng)關(guān)必須成為一個高可用的技術(shù)組件，它的 穩(wěn)定直接關(guān)系到了所有服務(wù)的穩(wěn)定。網(wǎng)關(guān)如果沒有設(shè)計(jì)，就會成變一個單點(diǎn)故障。因此，一 個好的網(wǎng)關(guān)至少要做到以下幾點(diǎn)。集群化。網(wǎng)關(guān)要成為

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

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

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

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

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

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

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

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

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

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