PowerDotNet平台化軟體架構設計與實現系列（04）：服務治理平台

2021 年 11 月 21 日
筆記
AOP, architecture, DevOps, microservices, System, WCF, WebApi, WebService, 工具, 服務, 架構, 系統, 經驗

系統和系統之間，少不了數據的互聯互通。隨著微服務的流行，一個系統內的不同應用進行互聯互通也是常態。

PowerDotNet的服務治理平台發源於早期的個人項目Power.Apix。這個項目借鑒了工作過的公司的服務治理方案，站在巨人的肩膀上，一步一步從無到有模仿設計和實現。

一開始，Power.Apix被設計用於基於XML的Web服務通訊，因為Web服務在當時是主流通訊方式，樸素版本大概長下面這個樣子：

服務端：

服務端只要加上ApixClazz、ApixMethod兩個特性，一個Apix服務就完美實現了：

客戶端：

後來，隨著個人開發經驗的豐富，陸陸續續添加了更多的序列化協議的支援，而初期設計的僅支援Web服務通訊則被改的面目全非。

Power.Apix支援常見的HTTP方法：

Power.Apix支援不同的序列化方式：

通過抓包分析，可以發現Power.Apix已經支援自定義請求頭：

十年磨一劍。經過多年優化和改進，負載均衡、限流、黑白名單、日誌等功能逐步迭代開發出來，在以HTTP協議為主流的文本協議框架里，Power.Apix現在已經非常完善和強大，尤其是部署非常方便，在一般請求應答業務場景下，完全可以取代.NET Remoting、WebApi、WebService和WCF。

簡單介紹完Power.Apix，下面再來說說本文的主題服務治理平台。

我們常見的傳統的RPC介面調用，比如WebApi、WebService、WCF、.NET Remoting、gRPC、Thrift、Hessian、自定義RPC協議（比如個人項目Power.Apix）等，如果是少量調用，還好說。但是一旦介面多起來，系統關係複雜，就容易造成各種混亂。

我已經不止看到一個系統，不論是.Net還是Java開發的應用，都要配置各種介面服務地址，調用的地方各種拼接介面名稱，各種HTTP幫助類，看著就不夠優雅，可以說都是demo水平。咩哈哈，就是demo水平。

PowerDotNet在借鑒主流微服務治理框架和協議（包括但不限於ZooKeeper、Consul、Nacos、HSF、ETCD、Dubbo、Spring Cloud、Ocelot、Hessian、gRPC、Thrift、Kubernates等）的基礎上，獨立開發出了一套簡潔高效的服務治理平台。

在一個基於服務（SOA）的分散式環境中，常見的消息交互模式（Message Exchange Pattern，即MEP）主要包括如下幾種：

1、RequestReply：經典請求應答模型，客戶端發起一個請求後會等待一個響應才可以進行下一次請求

2、Oneway：客戶端發起一個請求後不等待一個響應

3、Duplex：雙向通訊，客戶端發起請求得到服務端一個響應，服務端再回調通知客戶端一個響應，HTTP和TCP協議會有不同的實現邏輯

4、Streaming：客戶端發起一個或多個請求 , 等待一個或多個響應

PowerDotNet目前完美支援RequestReply這一經典交互模式，畢竟來源於web環境下以HTTP為文本協議的Power.Apix，當然簡單的Oneway模式只需要簡單改造不多的框架程式碼就可以支援。

PowerDotNet早期自研了一套基於ZooKeeper的註冊中心Power.RegistryCenter，後來逐步改造放棄ZooKeeper為默認註冊中心，因為曾經某廠的ZooKeeper由於磁碟IO太高，導致ZooKeeper集群掛掉，進而導致重大生產事故。

從CAP理論上來說，ZooKeeper保證的是CP（一致性和分區容錯性），然而註冊中心尤其是服務發現功能更應該保證的是AP（可用性和分區容錯性），可用性比數據一致性更加重要。

PowerDotNet最新自研的註冊中心遵循AP原則，高可用性基於DB、本地快取、Redis和ETCD，且Redis和ETCD都是可插拔的插件式可選模式，用戶選擇更多，同時還能保證高可用。

從服務拉取方式和性能上來看，PowerDotNet的註冊中心採用的是客戶端（Power.RegistryCenter.Client）拉取模式，客戶端定時（默認間隔30秒，這個參考了SpringCloud的Eureka）主動拉取（續租）服務端（Power.RegistryCenter.Server）服務並快取在本地，而早期的ZooKeeper客戶端監聽服務列表變化，服務變更主動推送給消費者，在規模較大的服務集群上，很容易產生性能問題。

復用是PowerDotNet設計的時候優先考慮的主題。針對不同協議的RPC介面，PowerDotNet設計的時候做了各種妥協，現已經完美支援WebApi、WebService、WCF(支援常見的幾種綁定協議，包括BasicHttpBinding、WSHttpBinding、NetTcpBinding等)、.NET Remoting(支援HTTP和TCP協議)、gRPC、Thrift、Hessian、IHttpHandler（ASPX、ASHX、個人項目Power.Apix）的互聯互通。

PowerDotNet還有一個後續開發計劃PowerDotNetCore，以支援.NetCore下的主要通訊協議，目前.NetCore2.1、.NetCore3.0和.NET5下的WebApi已經完美支援，其他等我有空慢慢來開發實現，咩哈哈，都是臟活累活苦活呀。後續再考慮開發支援和Java介面互通。

僅需要遵循一點點PowerDotNet規範，介面生產者可以快速開發API介面，介面消費者利用PowerDotNet自動生成工具，快速生成介面消費代理類，就和調用本地方法一樣容易。

如果你的系統里有不同的RPC介面形式需要互聯互通，比如WebApi調用WCF，WebService調用WebApi……或者相同的RPC形式互調，PowerDotNet都能夠讓你以一種優雅愉悅的方式實現介面調用。

環境準備

1、（必須）.Net Framework4.5+

2、（必須）關係型資料庫MySQL或SqlServer或PostgreSQL或MariaDB四選一

3、（可選）分散式鍵值存儲ETCD

4、（可選）分散式快取Redis或Memcached二選一

5、（可選）消息隊列RabbitMQ或MSMQ 二選一

6、（可選）ElasticSearch

一、服務註冊

支援自動註冊和人工註冊，自動註冊類、欄位等相關元數據。

二、服務發現

通過心跳程式，定時（默認5秒間隔）發送心跳來判斷應用伺服器的可用狀態（保活）。心跳程式健壯可靠，可以通過配置中心對心跳參數進行動態設置。

配合服務治理客戶端工具，可以自動發現新接入或者心跳停止的伺服器，自動實現服務發現。

如何保證心跳程式健壯可靠？PowerDotNet的心跳設計包含了兩種常見模式：推模式和拉模式。

推模式指應用伺服器主動發送心跳至平台註冊中心，這是常規的心跳檢查方式。

拉模式指平台註冊中心通過定時任務主動對應用伺服器發起心跳介面調用，間接觸發應用伺服器心跳程式自檢。

通過推模式和拉模式進行心跳檢查，可以最大程度減少某些應用（如寄宿在web容器上的服務，如果你熟悉IIS的話，應該知道IIS Worker Process默認會配置Idle Timeout 為20分鐘，即該進程在20分鐘內沒有任何請求的話就會自動結束）自動「休眠」導致心跳執行緒不能被喚醒而造成的心跳判斷錯誤。

當然拉模式是一種可關停的備選方案，通常推模式的心跳程式可以支援絕大多數應用服務的心跳檢查。

在這篇文章中，我們可以從【應用部署管理】看到應用部署伺服器的心跳情況，從而為實現基於心跳的服務發現打下基礎。

服務發現的關鍵部分是註冊中心，註冊中心提供註冊和查詢（發現）功能。

服務發現主要有兩種發現模式：客戶端發現和服務端發現。

客戶端發現模式要求客戶端負責查詢註冊中心，獲取服務提供者的列表資訊，使用負載均衡演算法選擇一個合適的服務提供者，發起介面調用請求。

服務端發現模式則要求客戶端每次都請求註冊中心，由註冊中心內部使用負載均衡演算法選擇一個合適的服務提供者，並將請求轉發至該服務提供者。

這兩種模式都有自己的優點和缺點，PowerDotNet可以通過開關動態實現兩種發現模式的自由切換，就問你靈不靈活吧？

目前業界開源的有Nacos、Netflix Eureka、ETCD、Consul和Zookeeper等註冊中心方案，PowerDotNet在參考了這些現有成熟方案之後，結合實踐經驗，選擇了支援ETCD。PowerDotNet服務註冊和發現，在使用ETCD的基礎上進行了優化和改進，通過開關動態控制，使得ETCD只是一種可插拔的服務治理實現。

ETCD的管理在下一篇文章中單獨講講。

三、服務消費

支援服務白名單和服務消費特殊邏輯配置。

白名單里的介面可以直接消費。

服務消費可以對介面進行配置Token和簽名校驗特殊邏輯。