微服務與閘道器技術（SIA-GateWay）

宜信技術學院發表於2019-08-12
微服務Gateway

一、背景

軟體架構，總是在不斷的演進中...

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

早期軟體架構基本都是單體架構，系統之間往往不需要進行互動，這也導致資料孤島和ETL工具的發展。隨著企業應用越來越多，相互的關係也越來密切，應用之間也迫切需要進行實時互動訪問，隨後基於XML的異構系統整合和資料互動技術開始被很多公司採用，SOA的概念被提了出來，web service逐漸流行。

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

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

二、微服務架構特性

微服務，其實是一種架構風格...

2.1 異構

服務不同最適合的技術方案不同，微服務可以幫助我們輕鬆採用不同的技術，並且理解這些新技術的好處。嘗試新技術通常伴隨著風險，但對於微服務系統而言，總會存在一些地方讓你可以選擇一個風險最小的服務採用新技術，並降低風險。

2.2 隔離

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

2.3 擴充套件

龐大的單體服務只能作為一個整體進行擴充套件，即使系統中只有一小部分模組存在效能問題，也需要對整個系統進行擴充套件。而微服務架構可以根據效能需要對不同的模組進行水平擴充套件，微服務的彈性也可以很好地處理服務不可用和功能降級問題。

2.4 部署簡單

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

2.5 靈活

在微服務架構中，系統會開放很多介面供外部使用，當情況發生改變時，可以使用不同的方式構建應用。而整體化的應用程式只能提供一個非常粗粒度的介面供外部使用。把單體應用分解成多個微服務，可以達到可複用、可組合的目的。

三、微服務與閘道器技術

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

3.1 什麼是微服務閘道器

微服務閘道器是微服務架構中的一個關鍵的角色，用來保護、增強和控制對於微服務的訪問，微服務閘道器是一個處於應用程式或服務之前的系統，用來管理授權、訪問控制和流量限制等，這樣微服務就會被微服務閘道器保護起來，對所有的呼叫者透明。因此，隱藏在微服務閘道器後面的業務系統就可以更加專注於業務本身。

3.2 微服務閘道器的分類

常見的微服務閘道器根據使用特性大致被分成流量閘道器和業務閘道器。兩種閘道器分別有不同關注點，下圖總結了兩種閘道器型別特性：

3.3 微服務閘道器的作用

微服務閘道器作為連線服務的消費方和服務提供方的中介軟體系統，將各自的業務系統的演進和發展做了天然的隔離，使業務系統更加專注於業務服務本身，同時微服務閘道器還可以為服務提供和沉澱更多附加功能，微服務閘道器主要作用如下：

四、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的延遲統計，呼叫計數等指標。

五、總結

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

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

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

SIA相關開源產品連結

作者： 王佩華


來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/69918724/viewspace-2653375/，如需轉載，請註明出處，否則將追究法律責任。

相關文章