FPNN 服務治理與服務網格

來自專欄 FPNN10 人贊了文章

FPNN RPC 框架及FPNN 技術生態逐步開源後，有越來越多的同學和合作夥伴在問，使用 FPNN 時，服務治理該如何進行？特別是開發微服務時，對於數萬台微服務，FPNN 又如何進行服務治理？ FPNN 是否支持服務網格？雲上曲率的實時消息服務又是如何實踐服務治理的？

其實 FPNN 技術生態對服務治理的結構非常清晰，FPNN 的服務治理需要配合 FPNN 技術生態的幾個可獨立使用的服務，一同完成。

常見的 FPNN 服務治理拓撲如下圖所示：

對應的 FPNN 服務治理架構如下圖所示：

其中除了 Web Console 集群外，出現了五個 FPNN 技術生態的獨立服務：

• FPManage Center：FPNN 集群控制管理服務，負責 FPNN 服務各項參數的動態實時調整、配置管理、運行監控，和狀態統計。
• FPMonitor：FPNN 監控分析服務。實時監控、分析和統計所有 FPNN 服務狀態，並根據用戶自定義規則，進行通知和報警。
• FPZK：FPNN 集群管理服務，負責集群管理、服務註冊與服務發現、配合 FPZK Client 和 proxy 進行負載均衡，和數據路由。
• DCA（Data Collection & Analysis Service）：全球數據採集分析服務。在服務治理中，主要用於數據採集。
• DATS（Distributed Automated Testing Suite）：FPNN 分散式自動測試套件。在服務治理中，主要用於分散式自動化測試，亦可用於服務的自動化部署，和服務的監控。

為了進一步深入理解，本文將按以下結構層次，逐項介紹說明：

內容目錄

• 服務治理
• 服務的註冊與發現
• 服務網路的分裂與合併
• 數據路由與負載均衡
• 服務的安全與訪問控制
• 服務的分層架構與子集群
• 服務的依賴關係
• 服務升級、灰度發布與介面兼容
• 服務彈性與擴容、縮容
• 服務的新增與撤除
• 服務降級與熔斷
• 服務的監控與日誌的採集和分析
• 服務的版本管理
• 服務的部署
• 服務的自動化測試
• 服務的工程模版與IDE集成
• 服務網格
• 雲上曲率實時消息服務的服務治理實踐

服務治理

• 服務的註冊與發現

FPNN 技術生態使用 FPZK 作為集群管理服務。

FPZK 是一個對等分散式集群服務，CAP 採用可用性優先策略，犧牲強一致性，而採用最終一致性。避免業內之前曾多次出現過的，因投票無法達成一致，而導致線上業務長時間無法提供服務的情況出現。

業務服務程序只需集成 FPZK 客戶端模塊，便可接入 FPZK 服務，自動上報運行狀態、系統負載，自動維護心跳。如果關注/訂閱了依賴服務，則當依賴服務發生變動時，FPZK 集群將把依賴服務的變動狀態實時推送給訂閱者。

而當訂閱者使用 FPNN 框架自帶的 proxy 模塊訪問依賴服務時，所有依賴服務的變動導致的路由調整和變動，將會由框架自動處理，並對業務透明，業務服務無需關心。

FPNN 框架已經自帶了 FPZK 的客戶端模塊。

• 服務網路的分裂與合併

一般的集群管理服務不建議跨機房部署，但 FPZK 集群，有必要時，可以進行跨機房，甚至洲際部署，應對全球化的服務集群管理。

上圖為 FPZK 全球部署的一個實例。

如果網路出現異常，比如因為網路蠕蟲或者網路攻擊導致的洲際光纜擁堵，亞洲與歐美網路被迫斷開。如下圖所示：

此時亞洲成為孤島。

對於多數常見的強一致性優先的集群管理服務，亞洲的集群管理服務節點將停止服務（因為自己是少數節點），而要求業務服務去連接因網路異常已無法連接的歐美節點。此時使用常見的強一致性優先的集群管理服務的亞洲服務，將陷入拒絕服務之中，所有亞洲的業務進入癱瘓狀態。

但對於 FPZK 服務，此時全球集群將自動退化為歐美、亞洲兩個獨立集群。兩個獨立集群仍將正常運轉。

當網路異常消失，光纜恢復正常，歐美和亞洲兩個獨立集群就會自動合併成單一的全球集群。其中一切變動，均對業務透明。

• 數據路由與負載均衡

配合 FPZK 服務，FPNN 框架自帶了4種數據路由與負載均衡方式。

分別是

• 隨機策略的負載均衡/路由：TCPFPZKRandomProxy
• 輪流/輪轉策略的負載均衡/路由：TCPFPZKRotatoryProxy
• 一致性哈希策略的負載均衡/路由：TCPFPZKCarpProxy
• 強一致/廣播策略的負載均衡/路由：TCPFPZKConsistencyProxy

業務使用 proxy 如同直接使用 TCPClient，直接調用

// sync modeproxy->sendQuest(interface_name, quest);// async modeproxy->sendQuest(interface_name, quest, callback);

介面發送數據即可。同時，FPNN 自身提供的 proxy 也支持 server push，因此，proxy 本質上是面對 FPNN 業務集群的集群客戶端。

• 服務的安全與訪問控制

FPNN 服務的安全與訪問控制可以分為四部分：

• FPNN 框架自身提供的安全控制
• Dispatcher 服務提供的訪問控制
• UniversalGate 提供的拓撲屏蔽和路由與訪問控制
• FPZK 提供的 Token 機制

FPNN 框架自身提供了基於 ECC/ECDH 的密鑰交換機制和 AES 加密機制。FPNN 框架本身可以強制所有介面必須加密訪問，或者在開放訪問的同時，部分介面必須加密訪問，或者僅內網訪問，或者僅能內網加密訪問。

同時，FPNN 自身提供白名單功能。啟用白名單後，僅白名單內指定的地址，或者 IP 段內的機器，才可以進行訪問。

Dispatcher 服務在進行負載均衡的同時，對外屏蔽了後端所有細節，只有被允許訪問的服務類型才能通過 Dispatcher 獲取，並進行訪問。

UniversalGate 可以作為業務集群的通用網關使用。其不僅包含了 FPNN 框架自身提供的所有安全特性，還在提供代理訪問的同時，限定了外界可以對網關內部訪問的服務種類，以及路由方式。

FPZK 集群管理服務則將業務劃分為數個項目，每個項目均可設置不同的 token。如果沒有對應的 token，則相應的項目內的所有服務，及服務拓撲，均不可觸及。

• 服務的分層架構與子集群

FPNN 建議將業務劃分為多個不同的項目、集群，以此建立服務的分層結構，和模塊化集群。

通過合理使用 Dispatcher、UniversalGate 和數據路由與負載均衡的 proxy，業務可獨立成數個黑盒模塊，以減少不同服務之間的依賴和交互，避免內網連接隨服務數量增加而暴增。

此外，FPZK 集群服務配合數據路由 proxy，提供多層次結構管理。

首先，FPZK 將業務劃分稱為多個不同的項目；然後每個項目下面將會有不同的服務類別；然後每個服務類別還可以進行分組。

而且，不論是項目級別，服務類別級別，還是服務分組級別，都可以很容易地構成一個子集群。再配合 UniversalGate 的合理使用，任意組合的服務都可以很容易地劃分為獨立的子集群。且各個子集群還能有獨立的嵌套和內部層次結構。

• 服務的依賴關係

通過 DCA 與 FPMonitor、FPManage Center 的配合使用，可通過 FPMonitor 或者 FPManage Center 直接獲取到所有服務之間的相互依賴關係。

同時還可以直接獲取具體依賴的介面名稱、調用次數和訪問統計。

• 服務升級、灰度發布與介面兼容

FPNN 通過類似字典形式的參數封裝，配合參數提取介面，解決了介面的兼容性，及參數順序的問題。

• FPNN 不關心參數順序
• FPNN 無視不處理的參數
• 通過使用 getXXX(...) 函數，當參數缺失或類型不匹配時，將返回默認值（可自定義）
• 通過使用 wantXXX(...) 函數，當參數缺失或類型不匹配時，將拋出異常。業務不捕獲的情況下，框架將自動返回參數異常的相關錯誤給客戶端。

此外，FPNN客戶端「一個 API 解決所有操作」的特性，決定了 FPNN 無需通過 IDL 生成樁代碼，即可著手代碼編寫，並進行服務開發。

因此 FPNN 技術生態對 IDL 並無依賴。一旦介面改動，配合 FPNN 的 getXXX(...) 函數，業務無需同時修改和升級關聯的所有服務，且能實現自動兼容，多版本兼容。在此基礎上，可實現服務的灰度發布。

• 服務彈性與擴容、縮容

配合 FPZK 集群管理服務，以及數據路由和負載均衡的 proxy 模塊，FPNN 服務在良好的設計下可做到同類型服務，所有實例使用完全相同的配置文件。

在此基礎上，配合雲主機的彈性服務，可根據業務需求，隨時、動態地增加，或者減少服務實例。相關的變動，會經由 FPZK 實時下發到所有的訂閱方，訂閱方的 proxy 模塊將實時做出調整，而無需業務進行處理。

• 服務的新增與撤除

對於新增服務，配合 FPZK 集群管理服務，按需直接啟動新增服務的運行實例即可，無需其他操作。

對於服務的撤除，如果是減少服務實例，可根據 FPMonitor 的監控數據，直接停止相應服務實例即可。

對於完全撤除某類型服務的所有實例，則可通過 FPMonitor，或者目標服務 FPNN 框架自身提供的 *infos 介面，在所有介面訪問統計均為 0 後，直接停止相應服務實例即可。

• 服務降級與熔斷

一般情況下，服務降級用於處理訪問異常增大，需要停止或者中斷非核心服務，以保證核心服務正常運行時採用。

FPNN 框架在 4 核虛擬機上即可應對上百萬長鏈，或者每秒20萬以上的請求。配合 FPZK 和雲主機的彈性服務，在訪問流量異常突增時，無需服務降級，直接追加服務實例即可。

而服務熔斷是避免內網雪崩效應的應對手段。通過修改和調整 FPNN 框架最大請求隊列長度的配置，在當最大請求隊列滿後，框架將自動實行服務熔斷。

所有使用 FPNN 框架開發的服務，均具備自動熔斷的功能，包括 UniversalGate 服務。

因此，不僅可以實現服務實例的熔斷，也可以直接實現集群的整體熔斷。

此外，配合 FPManage Center，可以直接啟用/關停任意服務的任意業務介面，或者任意集群的任意業務介面，以便及時終止相關服務，但不影響同屬於統一進程的其他介面和服務。

• 服務的監控與日誌的採集和分析

FPNN技術生態採用 DCA（Data Collection & Analysis Service 全球數據採集分析服務）進行日誌收集，並配合 FPMonitor 進行監控和分析、統計。

通過 FPMonitor，可直接獲取到任意服務的介面統計；通過 FPManage Center，可以直接獲取到任意服務、任意類別服務、任意集群的訪問信息、訪問統計；通過 Web Console 可隨時隨地地查看當前的服務狀態。

此外，FPMonitor 支持自定義報警規則。在規則觸發時，可根據條件，進行郵件、簡訊、或者電話通知。

• 服務的版本管理

FPZK 集群管理服務支持同一服務類別的多版本管理。業務服務在通過 FPZK 客戶端訂閱依賴服務時，可指定訂閱的服務版本。如果訂閱時指定版本為空，則訂閱該服務類別的所有版本。

因此，通過 FPZK 集群管理服務，可以按需訪問和管理同一服務的不同版本。同時，配合服務的灰度發布，可實現 A/B 版本的不同流程與服務依賴。

• 服務的部署

FPNN 框架和技術生態對服務的部署並無具體要求。可使用第三方自動化部署工具，或者使用 FPNN 技術生態中 DATS（Distributed Automated Testing Suite）的自動分發部署功能。DATS 的自動分發部署功能，可以指定設備，或者邏輯區域同步部署，亦可遠程啟動指定的服務實例。

• 服務的自動化測試

FPNN 技術生態提供 DATS（Distributed Automated Testing Suite）分散式自動化測試套件進行自動化的測試。

根據具體的業務，使用 DATS 提供的執行器（Actor）和控制器（Controller）模版編寫相應的測試用例，和測試控制流程後，即可通過 DATS 自動分發、部署測試用例，並按照測試控制流程啟動、彙報、匯總、分析、和停止測試。同時可以生成實時報表，亦可實時監控測試機和目標機的壓力/負載狀態、內存使用、網路使用、鏈接數量、響應時間等狀態信息。

• 服務的工程模版與IDE集成

FPNN 框架是一個分散式微服務框架，在設計之初便將簡單易用作為核心指標。因此 FPNN 無論是作為服務端還是客戶端，均無需工程模版，寥寥數行代碼即可構建出一個 FPNN 應用。因此，亦無需和 IDE 進行集成。

服務網格

服務網格主要用於解決原生服務導致的複雜的網路拓撲，其次便是原生服務的服務註冊、服務發現、負載均衡、限流、熔斷、監控、訪問控制等。

具備良好設計的分散式網路無需服務網格多一次數據輾轉，但如需使用，請使用 FPNN 技術生態中的 UniversalGate。以上功能，全部具備，無需額外處理。

雲上曲率實時消息服務的服務治理實踐

最後，我們以雲上曲率的實時消息服務作為一個實例，簡單介紹一下 FPNN 服務治理在其中的運用。

以下是雲上曲率的實時消息服務產品結構圖：

在結構圖中，可以發現，有 FPNN 技術生態的 FPZK、DBProxy、UniversalGate、Dispatcher 四個服務出現。

下圖是雲上曲率的實時消息服務運維結構圖：

運維結構圖中，出現了產品圖中省略的 DCA、FPMonitor、FPManage Center、DATS 四個服務。

雲上曲率的實時消息服務，採用 FPZK 作為集群管理服務，所有服務和子集群均向 FPZK 註冊。然後使用 Dispatcher 服務為客戶端網關提供負載均衡服務，每次返回負載權重最輕的一台 rtmGated 供客戶端接入。

然後採用 UniversalGate 作為內部網關，對客戶用管理系統屏蔽所有實時消息服務集群內拓撲細節，並提供訪問控制和代理服務。

之後採用 DBProxy 對內屏蔽所有資料庫拓撲和分庫分表細節，並提供資料庫訪問代理服務。

在實時消息服務運維繫統中，採用 DCA（Data Collection & Analysis Service）採集實時消息服務所有數據，使用 FPMonitor 分析和報警。

然後使用 FPManage Center 全局管理和控制、動態調節各個服務的參數、介面狀態。

最後，實時消息服務採用 DATS（Distributed Automated Testing Suite）對整個系統進行自動化的分散式壓力測試，和全球送達速率測試。

最後

最後，相關項目和信息如下：

FPNN 項目：