摘要：的服務(wù)治理平臺(tái)發(fā)源于早期的個(gè)人項(xiàng)目?？蛻舳税l(fā)現(xiàn)模式要求客戶端負(fù)責(zé)查詢注冊中心，獲取服務(wù)提供者的列表信息，使用負(fù)載均衡算法選擇一個(gè)合適的服務(wù)提供者，發(fā)起接口調(diào)用請(qǐng)求。

系統(tǒng)和系統(tǒng)之間，少不了數(shù)據(jù)的互聯(lián)互通。隨著微服務(wù)的流行，一個(gè)系統(tǒng)內(nèi)的不同應(yīng)用進(jìn)行互聯(lián)互通也是常態(tài)。

PowerDotNet的服務(wù)治理平臺(tái)發(fā)源于早期的個(gè)人項(xiàng)目Power.Apix。這個(gè)項(xiàng)目借鑒了工作過的公司的服務(wù)治理方案，站在巨人的肩膀上，一步一步從無到有模仿設(shè)計(jì)和實(shí)現(xiàn)。

一開始，Power.Apix被設(shè)計(jì)用于基于XML的Web服務(wù)通信，因?yàn)閃eb服務(wù)在當(dāng)時(shí)是主流通信方式，樸素版本大概長下面這個(gè)樣子：

服務(wù)端：

服務(wù)端只要加上ApixClazz、ApixMethod兩個(gè)特性，一個(gè)Apix服務(wù)就完美實(shí)現(xiàn)了：

客戶端：

后來，隨著個(gè)人開發(fā)經(jīng)驗(yàn)的豐富，陸陸續(xù)續(xù)添加了更多的序列化協(xié)議的支持，而初期設(shè)計(jì)的僅支持Web服務(wù)通信則被改的面目全非。

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

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

通過抓包分析，可以發(fā)現(xiàn)Power.Apix已經(jīng)支持自定義請(qǐng)求頭：

十年磨一劍。經(jīng)過多年優(yōu)化和改進(jìn)，負(fù)載均衡、限流、黑白名單、日志等功能逐步迭代開發(fā)出來，在以HTTP協(xié)議為主流的文本協(xié)議框架里，Power.Apix現(xiàn)在已經(jīng)非常完善和強(qiáng)大，尤其是部署非常方便，在一般請(qǐng)求應(yīng)答業(yè)務(wù)場景下，完全可以取代.NET Remoting、WebApi、WebService和WCF。

簡單介紹完P(guān)ower.Apix，下面再來說說本文的主題服務(wù)治理平臺(tái)。

我們常見的傳統(tǒng)的RPC接口調(diào)用，比如WebApi、WebService、WCF、.NET Remoting、gRPC、Thrift、Hessian、自定義RPC協(xié)議（比如個(gè)人項(xiàng)目Power.Apix）等，如果是少量調(diào)用，還好說。但是一旦接口多起來，系統(tǒng)關(guān)系復(fù)雜，就容易造成各種混亂。

我已經(jīng)不止看到一個(gè)系統(tǒng)，不論是.Net還是Java開發(fā)的應(yīng)用，都要配置各種接口服務(wù)地址，調(diào)用的地方各種拼接接口名稱，各種HTTP幫助類，看著就不夠優(yōu)雅，可以說都是demo水平。咩哈哈，就是demo水平。

PowerDotNet在借鑒主流微服務(wù)治理框架和協(xié)議（包括但不限于ZooKeeper、Consul、Nacos、HSF、ETCD、Dubbo、Spring Cloud、Ocelot、Hessian、gRPC、Thrift、Kubernates等）的基礎(chǔ)上，獨(dú)立開發(fā)出了一套簡潔高效的服務(wù)治理平臺(tái)。

在一個(gè)基于服務(wù)（SOA）的分布式環(huán)境中，常見的消息交互模式（Message Exchange Pattern，即MEP）主要包括如下幾種：

1、RequestReply：經(jīng)典請(qǐng)求應(yīng)答模型，客戶端發(fā)起一個(gè)請(qǐng)求后會(huì)等待一個(gè)響應(yīng)才可以進(jìn)行下一次請(qǐng)求

2、Oneway：客戶端發(fā)起一個(gè)請(qǐng)求后不等待一個(gè)響應(yīng)

3、Duplex：雙向通信，客戶端發(fā)起請(qǐng)求得到服務(wù)端一個(gè)響應(yīng)，服務(wù)端再回調(diào)通知客戶端一個(gè)響應(yīng)，HTTP和TCP協(xié)議會(huì)有不同的實(shí)現(xiàn)邏輯

4、Streaming：客戶端發(fā)起一個(gè)或多個(gè)請(qǐng)求 , 等待一個(gè)或多個(gè)響應(yīng)

PowerDotNet目前完美支持RequestReply這一經(jīng)典交互模式，畢竟來源于web環(huán)境下以HTTP為文本協(xié)議的Power.Apix，當(dāng)然簡單的Oneway模式只需要簡單改造不多的框架代碼就可以支持。

PowerDotNet早期自研了一套基于ZooKeeper的注冊中心Power.RegistryCenter，后來逐步改造放棄ZooKeeper為默認(rèn)注冊中心，因?yàn)樵?jīng)某廠的ZooKeeper由于磁盤IO太高，導(dǎo)致ZooKeeper集群掛掉，進(jìn)而導(dǎo)致重大生產(chǎn)事故。

從CAP理論上來說，ZooKeeper保證的是CP（一致性和分區(qū)容錯(cuò)性），然而注冊中心尤其是服務(wù)發(fā)現(xiàn)功能更應(yīng)該保證的是AP（可用性和分區(qū)容錯(cuò)性），可用性比數(shù)據(jù)一致性更加重要 。

PowerDotNet最新自研的注冊中心遵循AP原則，高可用性基于DB、本地緩存、Redis和ETCD，且Redis和ETCD都是可插拔的插件式可選模式，用戶選擇更多，同時(shí)還能保證高可用。

從服務(wù)拉取方式和性能上來看，PowerDotNet的注冊中心采用的是客戶端（Power.RegistryCenter.Client）拉取模式，客戶端定時(shí)（默認(rèn)間隔30秒，這個(gè)參考了SpringCloud的Eureka）主動(dòng)拉?。ɡm(xù)租）服務(wù)端（Power.RegistryCenter.Server）服務(wù)并緩存在本地，而早期的ZooKeeper客戶端監(jiān)聽服務(wù)列表變化，服務(wù)變更主動(dòng)推送給消費(fèi)者，在規(guī)模較大的服務(wù)集群上，很容易產(chǎn)生性能問題。

復(fù)用是PowerDotNet設(shè)計(jì)的時(shí)候優(yōu)先考慮的主題。針對(duì)不同協(xié)議的RPC接口，PowerDotNet設(shè)計(jì)的時(shí)候做了各種妥協(xié)，現(xiàn)已經(jīng)完美支持WebApi、WebService、WCF(支持常見的幾種綁定協(xié)議，包括BasicHttpBinding、WSHttpBinding、NetTcpBinding等)、.NET Remoting(支持HTTP和TCP協(xié)議)、gRPC、Thrift、Hessian、IHttpHandler（ASPX、ASHX、個(gè)人項(xiàng)目Power.Apix）的互聯(lián)互通。

PowerDotNet還有一個(gè)后續(xù)開發(fā)計(jì)劃PowerDotNetCore，以支持.NetCore下的主要通信協(xié)議，目前.NetCore2.1、.NetCore3.0和.NET5下的WebApi已經(jīng)完美支持，其他等我有空慢慢來開發(fā)實(shí)現(xiàn)，咩哈哈，都是臟活累活苦活呀。后續(xù)再考慮開發(fā)支持和Java接口互通。

僅需要遵循一點(diǎn)點(diǎn)PowerDotNet規(guī)范，接口生產(chǎn)者可以快速開發(fā)API接口，接口消費(fèi)者利用PowerDotNet自動(dòng)生成工具，快速生成接口消費(fèi)代理類，就和調(diào)用本地方法一樣容易。

如果你的系統(tǒng)里有不同的RPC接口形式需要互聯(lián)互通，比如WebApi調(diào)用WCF，WebService調(diào)用WebApi......或者相同的RPC形式互調(diào)，PowerDotNet都能夠讓你以一種優(yōu)雅愉悅的方式實(shí)現(xiàn)接口調(diào)用。

環(huán)境準(zhǔn)備

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

2、（必須）關(guān)系型數(shù)據(jù)庫MySQL或SqlServer或PostgreSQL或MariaDB四選一

3、（可選）分布式鍵值存儲(chǔ)ETCD

4、（可選）分布式緩存Redis或Memcached二選一

5、（可選）消息隊(duì)列RabbitMQ或MSMQ 二選一

6、（可選）ElasticSearch

一、服務(wù)注冊

支持自動(dòng)注冊和人工注冊，自動(dòng)注冊類、字段等相關(guān)元數(shù)據(jù)。

?二、服務(wù)發(fā)現(xiàn)

通過心跳程序，定時(shí)（默認(rèn)5秒間隔）發(fā)送心跳來判斷應(yīng)用服務(wù)器的可用狀態(tài)（?；睿?。心跳程序健壯可靠，可以通過配置中心對(duì)心跳參數(shù)進(jìn)行動(dòng)態(tài)設(shè)置。

配合服務(wù)治理客戶端工具，可以自動(dòng)發(fā)現(xiàn)新接入或者心跳停止的服務(wù)器，自動(dòng)實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)。

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

推模式指應(yīng)用服務(wù)器主動(dòng)發(fā)送心跳至平臺(tái)注冊中心，這是常規(guī)的心跳檢查方式。

拉模式指平臺(tái)注冊中心通過定時(shí)任務(wù)主動(dòng)對(duì)應(yīng)用服務(wù)器發(fā)起心跳接口調(diào)用，間接觸發(fā)應(yīng)用服務(wù)器心跳程序自檢。

通過推模式和拉模式進(jìn)行心跳檢查，可以最大程度減少某些應(yīng)用（如寄宿在web容器上的服務(wù)，如果你熟悉IIS的話，應(yīng)該知道IIS Worker Process默認(rèn)會(huì)配置Idle Timeout 為20分鐘，即該進(jìn)程在20分鐘內(nèi)沒有任何請(qǐng)求的話就會(huì)自動(dòng)結(jié)束）自動(dòng)“休眠”導(dǎo)致心跳線程不能被喚醒而造成的心跳判斷錯(cuò)誤。

當(dāng)然拉模式是一種可關(guān)停的備選方案，通常推模式的心跳程序可以支持絕大多數(shù)應(yīng)用服務(wù)的心跳檢查。

在這篇文章中，我們可以從【應(yīng)用部署管理】看到應(yīng)用部署服務(wù)器的心跳情況，從而為實(shí)現(xiàn)基于心跳的服務(wù)發(fā)現(xiàn)打下基礎(chǔ)。

服務(wù)發(fā)現(xiàn)的關(guān)鍵部分是注冊中心，注冊中心提供注冊和查詢（發(fā)現(xiàn)）功能。

服務(wù)發(fā)現(xiàn)主要有兩種發(fā)現(xiàn)模式：客戶端發(fā)現(xiàn)和服務(wù)端發(fā)現(xiàn)。

客戶端發(fā)現(xiàn)模式要求客戶端負(fù)責(zé)查詢注冊中心，獲取服務(wù)提供者的列表信息，使用負(fù)載均衡算法選擇一個(gè)合適的服務(wù)提供者，發(fā)起接口調(diào)用請(qǐng)求。

服務(wù)端發(fā)現(xiàn)模式則要求客戶端每次都請(qǐng)求注冊中心，由注冊中心內(nèi)部使用負(fù)載均衡算法選擇一個(gè)合適的服務(wù)提供者，并將請(qǐng)求轉(zhuǎn)發(fā)至該服務(wù)提供者。

這兩種模式都有自己的優(yōu)點(diǎn)和缺點(diǎn)，PowerDotNet可以通過開關(guān)動(dòng)態(tài)實(shí)現(xiàn)兩種發(fā)現(xiàn)模式的自由切換，就問你靈不靈活吧？

目前業(yè)界開源的有Nacos、Netflix Eureka、ETCD、Consul和Zookeeper等注冊中心方案，PowerDotNet在參考了這些現(xiàn)有成熟方案之后，結(jié)合實(shí)踐經(jīng)驗(yàn)，選擇了支持ETCD。PowerDotNet服務(wù)注冊和發(fā)現(xiàn)，在使用ETCD的基礎(chǔ)上進(jìn)行了優(yōu)化和改進(jìn)，通過開關(guān)動(dòng)態(tài)控制，使得ETCD只是一種可插拔的服務(wù)治理實(shí)現(xiàn)。

ETCD的管理在下一篇文章中多帶帶講講。

三、服務(wù)消費(fèi)

支持服務(wù)白名單和服務(wù)消費(fèi)特殊邏輯配置。

白名單里的接口可以直接消費(fèi)。

服務(wù)消費(fèi)可以對(duì)接口進(jìn)行配置Token和簽名校驗(yàn)特殊邏輯。

四、黑名單

通過配置黑名單規(guī)則，按配置實(shí)現(xiàn)動(dòng)態(tài)黑名單功能。

?五、灰度發(fā)布

通過灰度發(fā)布規(guī)則，實(shí)現(xiàn)灰度發(fā)布功能。

六、API網(wǎng)關(guān)

主流的RPC框架在服務(wù)消費(fèi)的時(shí)候，都有完備的客戶端工具，支持服務(wù)鑒權(quán)、負(fù)載均衡、黑白名單、限流等功能。

PowerDotNet也優(yōu)先實(shí)現(xiàn)了客戶端形式的服務(wù)調(diào)用，支持主流功能。

但是，很多種場景下，都不得不考慮加入API網(wǎng)關(guān)，把API網(wǎng)關(guān)放到各種API服務(wù)的最前端，并且讓API網(wǎng)關(guān)變成由各應(yīng)用所發(fā)起的每個(gè)請(qǐng)求的入口。這樣做可以明顯的簡化客戶端調(diào)用服務(wù)端API。

PowerDotNet實(shí)現(xiàn)了一個(gè)通用簡易功能的API網(wǎng)關(guān)，也支持服務(wù)鑒權(quán)、負(fù)載均衡、限流、黑白名單、灰度發(fā)布等功能，比客戶端調(diào)用API接口功能還略豐富，并且可以繼續(xù)擴(kuò)展新功能。

PowerDotNet自研的負(fù)載均衡組件，包含隨機(jī)、加權(quán)隨機(jī)、輪詢、加權(quán)輪詢和客戶端IP哈希五種算法，并提供了負(fù)載均衡接口，可按需動(dòng)態(tài)擴(kuò)展。

PowerDotNet自研的限流組件，通過配置中心動(dòng)態(tài)調(diào)整開關(guān)，在注冊中心通過后臺(tái)管理系統(tǒng)動(dòng)態(tài)配置，支持根據(jù)IP地址或者應(yīng)用名稱進(jìn)行限流，并提供了接口，可按需動(dòng)態(tài)擴(kuò)展。

PowerDotNet負(fù)載均衡和限流組件，已經(jīng)運(yùn)用在網(wǎng)關(guān)和客戶端，是通用的可擴(kuò)展組件。

API網(wǎng)關(guān)支持對(duì)內(nèi)外網(wǎng)開放，也可以同時(shí)部署兩套，對(duì)內(nèi)和對(duì)外的分開。在對(duì)外的網(wǎng)關(guān)上，建議對(duì)被消費(fèi)的接口勾選加上驗(yàn)證簽名和Token功能，網(wǎng)關(guān)會(huì)自動(dòng)處理判斷客戶端請(qǐng)求是否合法。

七、常用工具

1、服務(wù)測試

為了更好的測試待發(fā)布的部署服務(wù)器，可以通過選擇或者輸入來動(dòng)態(tài)切換，非常靈活

2、代理類生成和下載

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

PowerDotNet設(shè)計(jì)的遠(yuǎn)程服務(wù)調(diào)用，目標(biāo)是“無配置，無引用，全自動(dòng)”，截至目前來看，可以說出色的達(dá)到了這一目標(biāo)。

咩哈哈，通過PowerDotNet調(diào)用RPC服務(wù)，只需要一個(gè)方法RemoteApiClient.Invoke(methodName, request);完成調(diào)用，有點(diǎn)太簡潔太優(yōu)雅了。

?3、API文檔管理

只要每個(gè)獨(dú)立API自動(dòng)集成Swagger，通過管理后臺(tái)都能自動(dòng)識(shí)別查看。

?也自動(dòng)支持.Net Core應(yīng)用：

上面這些工具對(duì)快速開發(fā)和排查問題非常有幫助。

?

參考：

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

?