微服務與網關技術（SIA-GateWay）

時間 2019-11-16

標籤微服網關技術 sia gateway 欄目 CGI 简体版

原文原文鏈接

1、背景

軟件架構，老是在不斷的演進中...git

把時間退回到二十年以前，當時企業級領域研發主要推崇的仍是C/S模式，PB、Delphi這樣的開發軟件是企業應用開發的主流。隨着時間的推移，基於瀏覽器的B/S架構開始漸漸流行了起來。初期，Web開發ASP還佔據了很多優點，但JSP的預編譯模式讓性能有了很大提高，隨後基於JAVA語言的J2EE架構變得愈來愈流行。github

早期軟件架構基本都是單體架構，系統之間每每不須要進行交互，這也致使數據孤島和ETL工具的發展。隨着企業應用愈來愈多，相互的關係也越來密切，應用之間也迫切須要進行實時交互訪問，隨後基於XML的異構系統集成和數據交互技術開始被不少公司採用，SOA的概念被提了出來，web service逐漸流行。web

互聯網時代，不少公司爲了適應更加靈活的業務需求，基於HTTP協議和Restful的架構風格及簡潔和結構清晰的JSON語言成爲企業開發的最佳實踐，在SOA架構中，企業服務總線技術ESB所暴露的集中式架構的劣勢讓開發者明白基於註冊和發現的分佈式架構纔是解決問題的關鍵辦法。由此，微服務架構開始盛行。編程

在《微服務設計》中如何界定一個微服務，就是使用鬆耦合&高內聚原則，把因相同因素變化的事情彙集在一塊兒，把因不一樣因素變化的事情區隔開來。後端

2、微服務架構特性

微服務，實際上是一種架構風格...瀏覽器

2.1 異構

服務不一樣最適合的技術方案不一樣，微服務能夠幫助咱們輕鬆採用不一樣的技術，而且理解這些新技術的好處。嘗試新技術一般伴隨着風險，但對於微服務系統而言，總會存在一些地方讓你能夠選擇一個風險最小的服務採用新技術，並下降風險。安全

2.2 隔離

微服務架構將系統分解爲獨立運行單元，給系統帶來更好的隔離性，獨立的微服務在發生異常時更容易定位和隔離問題，隔離性也是服務擴展性的基礎。網絡

2.3 擴展

龐大的單體服務只能做爲一個總體進行擴展，即便系統中只有一小部分模塊存在性能問題，也須要對整個系統進行擴展。而微服務架構能夠根據性能須要對不一樣的模塊進行水平擴展，微服務的彈性也能夠很好地處理服務不可用和功能降級問題。架構

2.4 部署簡單

在微服務架構中，各個服務的部署是獨立的，這樣就能夠更快地對特定部分的代碼進行部署。服務出現問題也更容易快速回滾，同時敏捷的交付和部署帶來了更好的業務需求響應體驗。負載均衡

2.5 靈活

在微服務架構中，系統會開放不少接口供外部使用，當狀況發生改變時，可使用不一樣的方式構建應用。而總體化的應用程序只能提供一個很是粗粒度的接口供外部使用。把單體應用分解成多個微服務，能夠達到可複用、可組合的目的。

3、微服務與網關技術

下圖是一個典型的微服務架構，僅供參考。

3.1 什麼是微服務網關

微服務網關是微服務架構中的一個關鍵的角色，用來保護、加強和控制對於微服務的訪問，微服務網關是一個處於應用程序或服務以前的系統，用來管理受權、訪問控制和流量限制等，這樣微服務就會被微服務網關保護起來，對全部的調用者透明。所以，隱藏在微服務網關後面的業務系統就能夠更加專一於業務自己。

3.2 微服務網關的分類

常見的微服務網關根據使用特性大體被分紅流量網關和業務網關。兩種網關分別有不一樣關注點，下圖總結了兩種網關類型特性：

3.3 微服務網關的做用

微服務網關做爲鏈接服務的消費方和服務提供方的中間件系統，將各自的業務系統的演進和發展作了自然的隔離，使業務系統更加專一於業務服務自己，同時微服務網關還能夠爲服務提供和沉澱更多附加功能，微服務網關主要做用以下：

4、SIA-GateWay

SIA-GATEWAY是基於SpringCloud微服務生態體系下開發的一個分佈式微服務網關係統。具有簡單易用、可視化、高可擴展、高可用性等特徵，提供雲原生、完整及成熟的接入服務解決方案。

4.1 關鍵特性

簡單易用, 支持基於Docker容器的快速部署及交付。
兼容性良好, 兼容SpringBoot微服務及傳統HTTP-URL的負載均衡及路由服務。
高可擴展性, 支持基於Java語言的第三方插件擴展特性及動態加載機制。
支持多租戶，多用戶角色下的網關拆分管理。
可視化管理，提供實時路由拓撲、網關集羣拓撲展現功能。
服務治理，支持網關集羣Dashboard、實時日誌、歷史日誌查詢、熔斷管理、預警管理等功能。
多註冊中心支持，提供分佈式網關集羣下對多註冊中心集羣的切換管理功能。
動態路由組件綁定機制，提供包括URL統計、日誌、灰度發佈、限流、安全等公共服務組件。

下圖是SIA-GATEWAY的總體架構圖，架構由CORE和 Admin Cluster組成，其中：

CORE承載網關HTTP請求的主要服務節點，CORE節點能夠根據所屬的網關組信息自動註冊到Admin管理端。
Admin是網關集羣的管理後臺，由Admin、Service、Stream、Monitor等服務組成。

網關的總體部署架構以下圖所示：

4.2 面向業務系統的微服務網關

微服務網關係統是一個處於應用程序或服務（提供REST API接口服務）以前的中間件系統， SIA-GateWay在建設初期作技術選型時就充分考慮到所使用的技術方案應該兼容後端代理業務系統所使用的技術棧和技術體系，所以咱們使用了Netflix的ZUUL做爲網關係統技術棧，單純的脫離使用場景談某一種網關功能如何強大的作法，後續都會給業務方的使用帶來更多的麻煩。

更明確的說若是目前大部分業務系統採用的技術棧是JAVA系統，那麼不建議使用Nginx、Kong或者OpenResty等網關係統，這裏主要是出於軟件工程性方面考慮。

舉個例子，業務方須要將一個公共組件以Plugin 機制集成到微服務網關，若是使用Lua腳本文件或者其餘腳本語言，那麼引入一種新的語言技術棧所帶來的複雜度會給業務系統帶來更多的不肯定性，系統後期維護成本和運維的難度都會呈指數級的提高。

4.3 基於組件模塊化的設計

微服務網關的一個很重要的做用就是能夠將微服務的API聚合後，提供一個統一的EntryPoint做爲業務使用方的一個統一入口，以及屏蔽和隱藏業務內部邏輯。下面是SIA-GateWay提供的公共組件類型及分類。

目前SIA-GateWay經過組件管理的機制實現了5個大類8個子類的公共服務組件供業務方使用，其中提供的路由組件綁定機制可讓業務方靈活地決定是否要在運行時執行相關組件邏輯。

4.4 去中心化的網關架構設計

微服務架構的一個重要特性就是去中心化的架構設計思路，SIA-GateWay在軟件設計層面上增長了一個「網關組」的抽象概念，一個網關組對應一個獨立的業務領域。網關組的概念也契合了微服務架構中的一些理念：業務系統依賴微服務網關提供明確清晰的服務邊界；業務系統經過微服務網關對外暴露業務的標準服務接口。

從實現層面，SIA-GateWay充分利用並結合了容器自動化的部署技術，在解決最後一千米的問題上，將網關以雲端容器資源的方式交付給不一樣業務方，經過共享網關SDK部署包的方式將網關的服務下沉到容器中實現和執行，從而在時間和空間上作到了系統的彈性和靈活交付。同時中心化的管理能力又給使用網關的具備不一樣權限的用戶能夠同時維護各自所屬網關組下的網關節點帶來了便利。

上圖展現的是SIA-GateWay去中心化的網關架構。固然除了微服務網關模式，目前下一代微服務架構ServiceMesh技術也是典型的去中心化架構，ServiceMesh是從SideCar邊車模式演進而來，是一種經過將服務治理能力下沉到業務節點的方式，經過控制面（control plane）和數據面（data plane）的處理解耦分離實現服務通訊更加快速、便捷、智能。

然而目前來看，從技術上及各大公司的實踐中，ServiceMesh在落地方面還存在諸多複雜性及不可控性，這種模式會給運維帶來極大的成本，若是貿然使用會給本就複雜的分佈式系統帶來更多的複雜和難度。而GateWay網關的模式在組織粒度上能夠調整，在實現方式上更加簡單可控，是目前的微服務架構中比較適合採用的模式。

4.5 網關如何保證高可用

做爲一個微服務網關係統，由於全部流量都會通過網關，網關必須成爲一個高可用的中間件服務，網關係統的穩定性及可用性直接決定了所用下游服務的穩定性。所以SIA-GateWay在架構設計上主要作了以下幾點：

1）集羣化

在生產環境中，所用網關節點至少保證有2個節點組成集羣同時提供服務，目前SIA-GateWay在公司內部主要使用容器化部署，避免單點故障。

2）健康檢查

在容器環境下，SIA-GateWay會暴露一個HTTP健康檢查接口，經過Kubernetes的健康檢查機制，按期檢查HTTP訪問是否可用，若是不可用，利用Kubernetes的服務編排能力能夠作容器的切換；在Zstack環境下，經過後臺啓動一個Crontab做爲守護進程檢查進程的狀態，保證網關的穩定可用和進程重啓機制。

3）備份機制

SIA-GateWay提供了一種備份網關機制，在Zstack上會啓動一個備份網關API-GATEWAY-CORE，全部在容器環境（Kubernetes）中啓動的網關節點，都會將本身的路由信息同步到備份網關中。

另外，利用Nginx的高可用性和健康檢查機制，當Kubernetes集羣出現問題，全部容器流量沒法響應時，會將Nginx上的流量自動切換到API-GATEWAY-CORE備份節點。API-GATEWAY-CORE在工做時也會觸發預警，提示目前有不可用的K8s網關節點。

4.6 提供機制而不是策略

Unix編程哲學裏，一個重要的概念是：「提到機制而不是策略」，通俗的講「機制」就是接口，「策略」就是具體的實現。SIA-GateWay提供的組件集成能力正是基於這樣的理念。

SIA-GateWay將架構的可擴展性做爲重要的對外輸出能力，第三方插件機制主要支持JAVA語言的Filter組件動態加載機制。Filter機制是JAVA工程師最爲熟悉的標準組件，因此對於業務方集成本身的業務邏輯提供了極大的便利，第三方業務組件加載到網關平臺大致有以下幾個步驟：

根據SIA-GateWay提供的模板類及註解，實現動態業務邏輯。
將實現好的動態組件經過Maven打包。
在組件管理界面，經過組件上傳按鈕將組件上傳到Admin-組件管理器。
組件管理器執行文件存儲邏輯。
組件管理器執行組件下發操做，將組件分發到對應網關組。
網關節點經過ClassLoader反射解析組件並動態加載到內存。
網關節點經過異步信號量機制響應組件加載狀態。
組件管理器同步插件Plugin狀態。

下圖是SIA-GateWay組件加載機制的執行邏輯圖：

4.7 強化可視化和微服務治理能力

俗話說流水的架構，鐵打的監控，任何架構都須要軟件監控。微服務應用自己RPC的交互方式帶來了對監控系統瞭解系統運行狀態的難題。SIA-GateWay對微服務監控主要作了以下方面加強：

1）全局的集羣狀態查看和容器狀態DashBoard統計。

2）實時的路由拓撲和網關拓撲調用關係及狀態展現。實時的路由拓撲圖以下：

3）網關集羣拓撲管理界面，包含實時日誌、實時Hystix監控、JVM配置等。

4）可視化的組件管理界面。

5）日誌回溯，利用EKK架構實現日誌歸集到日誌查看功能。

6）熔斷管理的分類及錯誤Stacktrace查看。

7）URL細粒度的監控統計功能（默認不打開，須要路由綁定監控組件）,包括URL的延遲統計，調用計數等指標。

5、總結

軟件工程沒有銀彈，軟件系統的不肯定性和複雜性貫穿軟件工程的整個生命週期，微服務架構本質上是經過分層和解耦來下降系統的複雜性，這裏組織的溝通方式、企業文化、團隊技術學習能力都會對微服務架構的落地產生重要的影響。

對業務系統的核心能力洞察和業務邊界的識別是系統微服務架構落地的重要環節；微服務基礎設施的技術選型應該考慮到業務系統所使用的技術體系，選擇成熟的生態體系和合適的技術方案有利於微服務架構的推廣和持續的技術演進；SIA-GATEWAY做爲微服務基礎設施充分考慮到了與業務系統的兼容性和相關技術生態的成熟度。

最後在微服務架構下，隨着微服務規模的擴大，必然帶來分佈式事務一致性、網絡響應、容錯等等問題，因此微服務治理是微服務架構的難點，保障微服務架構的高可用和高可擴展性須要在基礎設施層面增長更多的技術投入和技術保障，這樣才能讓業務更好的專一於業務實現、敏捷的開發、持續快速的服務交付。