摘要：的服務治理平臺發源于早期的個人項目。客戶端發現模式要求客戶端負責查詢注冊中心，獲取服務提供者的列表信息，使用負載均衡算法選擇一個合適的服務提供者，發起接口調用請求。

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

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和簽名校驗特殊邏輯。

四、黑名單

通過配置黑名單規則，按配置實現動態黑名單功能。

?五、灰度發布

通過灰度發布規則，實現灰度發布功能。

六、API網關

主流的RPC框架在服務消費的時候，都有完備的客戶端工具，支持服務鑒權、負載均衡、黑白名單、限流等功能。

PowerDotNet也優先實現了客戶端形式的服務調用，支持主流功能。

但是，很多種場景下，都不得不考慮加入API網關，把API網關放到各種API服務的最前端，并且讓API網關變成由各應用所發起的每個請求的入口。這樣做可以明顯的簡化客戶端調用服務端API。

PowerDotNet實現了一個通用簡易功能的API網關，也支持服務鑒權、負載均衡、限流、黑白名單、灰度發布等功能，比客戶端調用API接口功能還略豐富，并且可以繼續擴展新功能。

PowerDotNet自研的負載均衡組件，包含隨機、加權隨機、輪詢、加權輪詢和客戶端IP哈希五種算法，并提供了負載均衡接口，可按需動態擴展。

PowerDotNet自研的限流組件，通過配置中心動態調整開關，在注冊中心通過后臺管理系統動態配置，支持根據IP地址或者應用名稱進行限流，并提供了接口，可按需動態擴展。

PowerDotNet負載均衡和限流組件，已經運用在網關和客戶端，是通用的可擴展組件。

API網關支持對內外網開放，也可以同時部署兩套，對內和對外的分開。在對外的網關上，建議對被消費的接口勾選加上驗證簽名和Token功能，網關會自動處理判斷客戶端請求是否合法。

七、常用工具

1、服務測試

為了更好的測試待發布的部署服務器，可以通過選擇或者輸入來動態切換，非常靈活

2、代理類生成和下載

早期的遠程服務調用好像一直是比較啰嗦且費力不討好的，要么配置繁瑣，要么引入很多依賴，要么IDE裝啥插件，要么調用代碼demo水平的寫法（尤其各種HTTP工具類，煩不勝煩），總之調用別人的服務整體感覺就是乏味無趣。

PowerDotNet設計的遠程服務調用，目標是“無配置，無引用，全自動”，截至目前來看，可以說出色的達到了這一目標。

咩哈哈，通過PowerDotNet調用RPC服務，只需要一個方法RemoteApiClient.Invoke(methodName, request);完成調用，有點太簡潔太優雅了。

?3、API文檔管理

只要每個獨立API自動集成Swagger，通過管理后臺都能自動識別查看。

?也自動支持.Net Core應用：

上面這些工具對快速開發和排查問題非常有幫助。

?

參考：

https://www.consul.io/

https://dubbo.apache.org/zh/

https://zookeeper.apache.org/

https://github.com/alibaba/nacos

https://nacos.io/zh-cn/index.html

https://blog.csdn.net/marine2010/article/details/5401366

https://spring.io/projects/spring-cloud

http://hessian.caucho.com/

http://doc.oschina.net/grpc/

https://thrift.apache.org/

https://etcd.io/

https://kubernetes.io/

https://dapr.io/

https://github.com/ThreeMammals/Ocelot

?