微服務網關和服務注冊中心
SOA團隊 2020-03-16
對于傳統的ESB總線我們看到實際上包括了微服務架構中的微服務注冊和發現中心，微服務網關兩個方面的能力，但為何在微服務架構里面會將這兩個點分解為獨立的兩個子組件，我們通過以下分析了解一下。
首先還是要說下微服務網關，微服務網關更多是在前后端分離，或者說涉及到獨立的類似手機APP等前端應用的時候使用的最多，即把內部各個微服務組件模塊的API接口能力統一注冊和接入到網關，對于APP也只需要訪問網關暴露的接口即可，同時通過網關還可以進一步的實現安全隔離。也就是說在這種場景下，網關更多的是實現了接口服務的代理和路由轉發能力，更多的是向外的一種能力發布。
我們可以想下在一個微服務架構里面，分解為了A，B，C，D四個微服務組件和模塊，但是這四個模塊都有各自的前端應用展現，四個模塊之間本身也存在相互的接口調用，但是都在在數據中心內部調用。在這種情況下我們是否需要使用微服務網關？而實際上在這種架構下，完全可以不使用微服務網關，只需要使用服務注冊和發現中心即可。
也就是我們常說的引入微服務網關后，微服務網關本身又變成為一個中心化的節點，雖然你可以對網關也進行集群部署，但是這種模式不符合我們去中心的期望。如果一個業務應用全部都是在內部使用，那么微服務模塊之間的交互完全可以不接入到微服務網關進行管理。
但是微服務模塊間相互調用的接口地址如何管理，微服務模塊本身又集群化后如何進行負載均衡，包括微服務模塊間相互點對點調用時日志如何監控和分析，服務鏈如何監控和管理？這些都是在去中心化后要考慮的問題，而這個在當下微服務架構下完全是可以解決的。其核心的思路就是將微服務網關的部分能力下沉到微服務模塊中去完成，類似在微服務模塊里面注冊一個很小的SDK插件。
也就是我們常說的，微服務模塊間的調用只需要服務注冊和發現中心，模塊A從服務注冊中心獲取到模塊B的接口服務調用地址后，直接發起對模塊B的接口服務調用。注冊中心本身需要提供服務目錄庫和負載均衡的能力。而對于微服務模塊內部SDK包僅僅是將本地SDK API調用轉變為遠程的Rest服務調用接口。同時在SDK代理包中可以很方便的實現日志攔截，安全管理，緩存等能力。在這種架構下，即使是服務注冊中心宕機也不會影響到整個微服務架構的平穩運行。從而達到真正的去中心化的目標。
也就是說在微服務架構里面，不涉及到對外發布統一的服務接口的時候，只需要保留服務注冊中心這個組件即可滿足內部多個微服務模塊的平穩運行。對于服務注冊中心一般需要提供負載均衡的能力，比如我們可以在服務注冊中心對提供同樣一個服務接口的多個組件都注冊進來，到時候通過服務注冊中心進行動態的負載均衡。如果我們是和Docker容器和K8s結合的化，整個微服務組件都是動態部署和托管的，K8s本身就提供了負載均衡和路由分發的能力，在這種情況下實際上只需要對K8s最終發布出來的負載均衡地址進行注冊即可。
但是這個外部本身又不絕對，如下圖，當一個大的業務系統，分成了三組微服務模塊，同時分給三個獨立開發廠商開發時，那么三個開發團隊間的接口交互仍然可以理解為外部，這樣往往才能夠確保每個開發團隊的高度獨立自治能力。
基于上圖，再總結下在使用網關和注冊中心的時候一些關鍵點：
1. 一個獨立的開發團隊，為保證獨立自治，以及內部多個微服務模塊間的交互集成，最好啟用獨立的服務注冊中心實現服務注冊，發現能力。即開發團隊內部多個微服務模塊間的集成，不需要通過網關，只需要通過服務注冊中心進行集成即可。
2. 開發團隊需要暴露能力給外部，包括暴露能力給其它的開發團隊，需要考慮將該API接口注冊到外部的網關上。在這里建議是拆分兩個獨立網關，一個是內部API網關，一個是放置到DMZ區面對公網訪問的API網關。對于服務如果同時涉及到內部和外部使用，則兩邊注冊。建議不要通過兩次網關去路由，一個是影響性能，一個是不方便后續問題排查。
3. 構建在開發團隊之外的API網關必須具備負載均衡能力，可以配置多個IP地址。通過該API網關也最好具備和Docker容器擴展后的服務自動注冊和地址加入擴展能力。
4. 對于開發團隊內部，如果考慮和Docker容器的進一步自動化集成，可以考慮在內部先啟用微服務網關，再將微服務網關開發的API地址進一步注冊到外部的API網關上面。
5. 如果內部和外部啟用各自獨立的網關，但是定制化SOA管控治理平臺的時候只需要一個，同時適配兩個網關，同時能夠對兩個網關進行監控和日常管理。
遠行科技
遠行云商
