軟體開發中常見的幾種不同服務模型包括SaaS（軟體即服務）、LaaS（許可即服務）、PaaS（平臺即服務）、CaaS（容器即服務）、IaaS（基礎設施即服務）和FaaS（功能即服務），
很多人認為IaaS和FaaS是趨勢，是未來軟體設計與開發人員的基本必備技能，PowerDotNet和PowerDotNetCore也特別注重這方面的設計開發和積累，目前已經做出了一些嘗試、實踐和探索，
PowerDotNet和PowerDotNetCore實作的公共服務按照主要功能模塊進行劃分，可以分為基礎設施、框架工具以及業務（微）服務三大類，客戶端和前端也小有所成，作業量較為飽和，
根據個人經驗，框架類別庫和各種流行中間件代碼質量相對都比較高. 直接原因是需求明確，邏輯變動少，再加上有很多牛人出手或者設計優秀比較具有前瞻性，實作之后，通常都會穩定很多年不變，
PowerDotNet和PowerDotNetCore實作的公共服務雖然不完全等同于框架類別庫和中間件，但也最大程度將穩定的改動極少的部分抽象提取出來沉淀固化，隔離變化點，面向介面編程應對變化，
面向物件編程的很多原則和規范同樣適用于PowerDotNet和PowerDotNetCore，經過積累、改進和優化，PowerDotNet經受了多次大規模實踐的檢驗，也逐漸形成了自己的一套平臺技術規約和接入規范，
本文結合自己的開發實踐經驗，給PowerDotNet和PowerDotNetCore應用開發、部署和運維等事項記個流水賬，畢竟積累歷史較為悠久且內容豐富，就算淡忘了也能做為參考檔案使用，咩哈哈，
一、根應用
在PowerDotNet和PowerDotNetCore中，DBKey是應用的起點和基石，是所有PowerDotNet和PowerDotNetCore應用中唯一需要配置資料庫連接串用戶名和密碼的地方，
一開始DBKeyApi服務在資料庫管理平臺進行管理，后續開發DataX應用的時候，經過重構和完善，所有關系型資料庫、NoSQL、NewSQL等連接和元資料管理都被劃分到DataX資料同步平臺，
1、DBKeyApi
DBKey服務所在的應用名稱叫Power.DataX.DBKeyApi，這是PowerDotNet必選應用，基于WebApi開發的服務介面，性能中規中矩，滿足絕大多數業務需求，
DBKeyApi需要對敏感字串進行加密解密處理，目前PowerDotNet和PowerDotNetCore默認直接使用Framework下的DESUtil類（也可配置使用AES），需要在本地組態檔中新增加密和解密組件配置，
PowerDotNet同時還開發了Power.DataX.ThriftDBKeyApi和Power.DataX.GrpcDBKeyApi兩個備選應用，
（1）、Power.DataX.ThriftDBKeyApi
這是備選應用，基于Thrift協議開發的服務介面，對比下來，性能最好，
（2）、Power.DataX.GrpcDBKeyApi
這也是備選應用，基于Grpc協議開發的服務介面，對比下來，性能最差，
如果追求極致的性能體驗，建議使用Thrift協議，根據我的性能測驗對比，Thirft>WebApi>Grpc，默認推薦使用WebApi，畢竟DBKey服務屬于資料量極少的字典型應用，訪問量并不大，
2、外部依賴
DBKeyApi是應用的基石介面，不依賴任何外部API服務，不接入配置中心、日志平臺和監控平臺，也不使用訊息佇列和分布式快取，可以說是PowerDotNet和PowerDotNetCore中最簡單最穩定的應用，
3、安全呼叫
API服務開發好了總是需要被呼叫，對于內容敏感的DBKey服務，PowerDotNet做了最為嚴格的安全規約，呼叫方有IP和域名白名單限制，所有呼叫DBKey的應用必須添加應用安全訪問審計日志，
在PowerDotNet的服務治理平臺中，所有應用對DBKey服務的呼叫都需要進行嚴格審核和授權，APP、客戶端、前端等應用禁止直接通過內部或者外部網關呼叫DBKey服務，
4、心跳檢查
DBKey服務支持心跳檢查，服務啟動后會定時（默認5秒）異步發送心跳包到注冊中心，PowerDotNet和PowerDotNetCore服務治理框架對所有服務介面都支持心跳檢查，
因為DBKey是根應用，也就是需要被第一個部署和啟動的應用，而注冊中心是后續依賴DBKey的應用，那么我們就會有疑問：注冊中心沒有啟動的情況下心跳檢查不是一種浪費嗎？
這個問題很好解決，一種是直接將PowerDotNet配置的心跳檢查設定為禁用，另一種是對心跳檢查結果進行特殊code處理，注冊中心不啟動的情況下，忽略心跳結果，延遲當前間隔的6倍時間再發送心跳，
除了普通介面和頁面應用自動內置了心跳健康檢查，其他如關系型資料庫、NoSQL、Redis、MQ等都自動根據DBKey實作了簡易心跳檢查（判斷連接是否成功），排查問題有立竿見影的效果，
PowerDotNet和PowerDotNetCore從最初的設計開始算起，心跳就是最基礎最核心最穩定的功能之一，可以說很多系統可靠性和可用性的基礎就是心跳健康檢測，
二、根服務
有根應用，就有根服務，根應用和根服務就像核彈一樣，可以不用，但不能沒有^_^，
DBKeyApi應用下的所有介面都是全域系統根服務，但是PowerDotNet和PowerDotNetCore的系統根服務遠遠不止DBKeyApi下的服務，
PowerDotNet全域根服務介面名稱，不可被修改或清理（移除），在服務治理平臺，根服務被修改時，系統會給出明顯的錯誤提示，
下面根據系統分組的不同列舉幾個PowerDotNet和PowerDotNetCore中典型的根服務，
1、資料庫管理
（1）、查詢DB資訊
（2）、查詢DBKey和DB型別資訊
（3）、清理DBKey本地快取
2、應用基礎
（1）、查詢系統資訊
（2）、查詢應用資訊（不含應用密鑰）
（3）、查詢應用密鑰
（4）、應用移入集群
（5）、應用移出集群
3、配置中心
（1）、查詢應用配置資訊
（2）、根據版本號增量查詢配置
（3）、回呼通知已獲取最新版本配置的應用和服務器
（4）、查詢應用配置的DBKey資訊
4、監控預警
（1）、添加日志
（2）、添加監控
5、ETCD
（1）、查詢ETCD路由分組
（2）、重繪ETCD鍵值對
6、服務治理
（1）、注冊應用服務器
（2）、下線應用服務器
（3）、注冊API服務
（4）、下線API服務
（5）、查詢API服務資訊
（6）、查詢可用的應用部署資訊
（7）、心跳檢查
（8）、查詢服務器資訊
（9）、人工注冊API服務
（10）、查詢快取統計資訊
上面列舉的監控預警和ETCD介面都是可選的根服務，PowerDotNet內置了很多開關，如果你有更好的監控預警和一致性方案，完全可以自己按需二次開發，
三、監控預警
1、日志平臺
記錄日志API介面，不依賴于平臺基礎和服務治理根服務介面，也不依賴配置中心，僅依賴于DBKey服務，
DBKey服務不依賴于日志平臺，日志平臺則直接呼叫DBKey的服務，日志API介面需要保證極高的性能和穩定性，當然應對業務和流量變化的可控的開關必不可少，
日志平臺支持分片查詢，建議按照應用進行查詢，應用必選，支持全鏈路呼叫鏈跟蹤查詢，
日志平臺支持敏感資訊過濾功能，默認情況下，DEV和Test環境可配置為不過濾敏感資訊，便于發現并快速排查問題，
2、監控平臺
記錄監控API介面，不依賴于平臺基礎和服務治理根服務介面，也不依賴配置中心，僅依賴于DBKey服務和日志平臺，
和日志API介面非常類似，監控API介面也需要保證極高的性能和穩定性，當然應對業務和流量變化的可控的開關也是必不可少，
四、平臺基礎
1、應用基礎
應用基礎根服務直接呼叫DBKey服務，同時也依賴日志平臺和監控平臺，但不需要接入配置中心，
當然日志平臺和監控平臺是可選的，可按需要進行配置，因為應用基礎也是字典型應用，穩定后改動極少，為了保證穩定和性能，依賴的外部服務當然是越少越好，
注意，平臺應用基礎服務依賴快取，如使用Redis分布式快取，建議配置分布式快取優先 ：
<add key="RedisCacheFirst" value="1"/>
2、配置中心
配置中心直接呼叫DBKey服務，同時也依賴日志平臺和監控平臺，當然日志平臺和監控平臺是可選的，可按需要進行配置，
配置中心定時異步拉取資料，間隔時間默認為15秒，可以配置ConfigRefreshSeconds達到動態控制的目標，建議是15的整數倍，配置中心通過ETCD或者RDBMS和Redis達到配置“及時”更新的目的，
PowerDotNet創建的默認Power.Platform.RootApp是一個虛擬根應用，主要用于供其他新應用復制配置用，減少開發人員的配置作業量，
PowerDotNet開發的配置中心客戶端，對外暴露的類ConfigClientTool和KVConfigService，推薦ConfigClientTool類，但是如果需要取非當前應用的配置，可以使用KVConfigService類，
對于一些快取資料，建議應用拼接快取鍵的時候加上快取版本CacheVersion，這樣可以集中控制資料變更，
通過DBKey服務獲取的資料庫連接串通常不會修改，所以建議快取鍵不帶版本CacheVersion，且快取時間長一點，系統默認快取一天，
對于需要心跳檢查的應用，在配置中心配置心跳健康檢查相關引數時，建議將心跳間隔時間設定為快取時間的五分之一或十分之一，系統資料正常快取5分鐘，心跳間隔時間可以設定為1到2分鐘或30秒，
配置中心支持配置自動服務器注冊引數，平臺部署的服務器，如選擇docker容器，請降低docker銷毀頻率或者優先將docker設定固定ip地址，否則頻繁注冊服務器容易導致服務不可達問題，畢竟心跳保活有時間間隔，
五、服務治理
1、對內網關
直接呼叫DBKey根服務和平臺基礎根服務，依賴日志平臺、監控平臺和配置中心，不需要向注冊中心注冊服務器和介面資訊，日志平臺和監控平臺是可選的，可按需要進行配置，
因為對內網關和注冊中心的緊密關系，對內網關又被稱為注冊中心網關，
2、對外網關
和對內網關類似，對外網關直接呼叫DBKey根服務和平臺基礎根服務，依賴日志平臺、監控平臺和配置中心，不需要向注冊中心注冊服務器和介面資訊，日志平臺和監控平臺是可選的，可按需要進行配置，
但是，對外網關對安全性要求極高，必須嚴格授權訪問的服務介面，添加安全審計日志，而且通過對外網關呼叫的介面必須要進行簽名和token校驗，否則網關會直接報錯，
對內和對外網關主要業務邏輯差不多，對外網關多了些安全審計需求，通過配置中心的SecureGateway配置可以輕松切換對內或對外網關控制，
支付網關是一種特別典型的對外網關，大中型電商系統幾乎都會有完備的支付網關解決方案和實作，在移動互聯網時代，支付網關更加不可或缺，
3、網關呼叫
通常根據公司的業務需要，API服務網關可以拆分為線上（對外）網關和線下（對內）網關，
一個非常經典的示例，外部商戶系統和內部財務系統都需要呼叫支付服務，根據實際業務需要，可能外部商戶系統走公網通過線上網關呼叫支付介面，而內部財務系統則走內網通過線下網關呼叫支付介面，
線上網關可以根據業務規模，繼續進行拆分為PC網關、移動端網關、第三方應用網關等，如果業務資料量不大，終端呼叫也不復雜，可能一個線上網關就足夠應對業務需求，
如果業務邏輯復雜，呼叫量很大，終端型別很多，每種終端的業務邏輯差異也較大，線上網關可能就需要繼續拆分，
有些公司還需要為開放平臺或者合作商戶等開發專用的安全網關，網關選擇就更復雜更豐富了，
4、客戶端呼叫
除了通過網關進行API服務呼叫，也可以在配置中心配置客戶端形式的直接服務呼叫，支持主流的服務鑒權、負載均衡、黑白名單、限流、熔斷等功能，
上圖簡單展示了業務微服務通過客戶端方式呼叫基礎設施微服務，同理，業務微服務之間的呼叫或者基礎設施微服務之間互調也適用，
對于內網應用服務或者追求更高性能的應用服務，推薦使用客戶端形式的直接服務呼叫，
5、網關心跳
心跳檢查主要有推模式和拉模式兩種，PowerDotNet兩種心跳模式都支持，通過服務端BroadCast廣播進行健康檢查性能較差，注冊中心不采用此方案，
每一個接入注冊中心的應用API服務都會被自動賦予一個心跳檢查框架服務方法，這個心跳檢測根服務僅限內部呼叫，
應用服務器會主動向注冊中心發送心跳包，實作心跳健康檢查功能，對于呼叫客戶端或網關而言，從注冊中心查詢到的心跳正常的應用服務器部署串列被認為是正常可用的，
如果部署的應用服務器回傳心跳停止，網關會嘗試呼叫API服務器的心跳介面，超時時間默認為2秒，如果沒有回傳正常心跳結果，就認為服務真的下線，移除快取中的部署資訊，
如果網關將檢測下線的部署服務器移除后，發現所有的部署資訊都不存在了，重新讀取遠程部署服務器資訊，做兜底嘗試，這個程序都是異步完成，整體性能沒有太大影響，
如果網關呼叫API服務器心跳成功，則網關會呼叫平臺基礎心跳介面，代替某個具體的API服務發送一次心跳，這個邏輯主要是為了防止某些Web服務器因為環境或心跳時間間隔不當導致的保活滯后，
6、注冊中心
注冊中心直接依賴對內網關、日志平臺和監控平臺，間接呼叫DBKey根服務和平臺應用基礎根服務，
注冊中心基礎服務，通過對內網關進行應用服務器、API介面的注冊、查詢和下線，支持Power.Apix、WebApi、WebService、WCF、Thrift、gRPC和.Net Remoting等形式的RPC介面，
注冊中心專門開發了客戶端，支持自動注冊物體類，物體類的集合型別建議使用具體型別，而不是介面，比如推薦使用List而不是IList，
注冊中心強烈建議介面開發程序中不要再使用Hashtable、ArrayList、DataTable和DataSet等型別，也不要使用指代不明的字典和dynamic型別，API介面型別越具體越好，
注冊中心客戶端目前支持集成Power.Apix、WebApi、WebService、WCF、Thrift、gRPC和.Net Remoting等形式的介面并進行統一網關呼叫或直接遠程呼叫，減少客戶端各種服務呼叫配置，
注意：注冊中心基礎服務不需要通過注冊中心客戶端自動注冊服務器和API介面資訊，因為這樣容易造成回圈依賴，雖然注冊中心基礎服務也是介面，
在PowerDotNet和PowerDotNetCore中，開發API介面服務，可通過ApiCallClassAttribute和ApiCallMethodAttribute兩個特性，自動定位唯一服務方法，
但是介面中呼叫實際方法并不是通過ApiCallMethodAttribute來定位，而是根據注冊時反射的服務方法，注冊服務的時候有唯一別名和方法名，通常這兩個都是相同的，
注冊中心的服務治理支持白名單和黑名單功能，黑名單目前已經實作了IP、用戶、系統、APP黑名單功能，這些都需要元資料支持，服務治理平臺可以配置出萬能黑名單功能，
7、自我保護
心跳健康檢查的優點很明顯，通用且實作簡單，但在SOA和微服務架構下，服務間通常都是跨行程呼叫，網路通信往往會面臨著各種問題，比如微服務正常，但是網路磁區發生故障，導致心跳檢查失敗，
默認情況下，如果注冊中心在60秒內沒有接收到某個服務實體的心跳，會自動注銷下線該服務實體，為什么是60秒心跳失敗就自動下線呢？
因為PowerDotNet和PowerDotNetCore注冊中心的默認心跳間隔為15秒，心跳支持3次重試，加上網路延遲和重試等待時間，60秒是一個較為合適易記的數字，
在配置中心我們可以配置心跳健康檢查時間間隔（默認15秒），所以60秒只是默認情況，實際的時長應該是應用配置的心跳健康檢查間隔時間的4倍，
注冊中心除了通過應用心跳健康檢查實作服務可用性，也可以配置（配置分組SafeGuard）自我保護機制（參考了Eureka），防止因為網路磁區故障心跳健康檢查誤判導致的服務不可用問題，
因為網路問題導致固定時間內大量服務實體被注銷下線，可能會嚴重威脅整個SOA或微服務架構的可用性，我們寧可將現有的服務節點都保留，也不能盲目注銷下線任何健康的服務，這就是所謂的兜底思維，
PowerDotNet注冊中心開發的自我保護機制主要邏輯如下：
（1）注冊中心在運行期間會去統計15分鐘（可配置）內應用服務心跳失敗比例，如果心跳失敗比例低于80%（可配置），注冊中心即會進入自我保護機制（可在配置中心配置開關控制）；
（2）進入自我保護機制后，通常認為現在注冊串列中的應用服務節點都是穩定可靠的，哪怕是長時間沒收到心跳而應該過期的服務節點，也不會再去主動注銷移除并下線；
（3）注冊中心仍然能夠接受新服務的注冊和查詢請求，并通過ETCD嘗試同步資料，但不會強制要求這些新增的服務被全部同步（默認ETCD來同步）到其它節點上，保證當前節點依然可用；
（4）當網路穩定心跳健康檢查恢復以后，當前實體新的注冊資訊會被全部同步到其它節點中，也就是達到注冊服務的最終一致性，這時候注冊中心自動關閉自我保護機制，
特別注意，如果在自我保護開啟后在保護期內剛好有某個服務提供者非正常下線，服務消費者就會有一個無效的服務實體，此時呼叫這個實體的服務就會失敗，服務消費者要有一些容錯機制，比如重試等，
目前PowerDotNet和PowerDotNetCore服務消費客戶端支持簡單重試（默認3次，可配置）和自動切換可用服務實體嘗試，如果所有服務實體都呼叫不通，客戶端拋出例外，自動異步發出心跳檢查嘗試，
8、斷路器
在分布式系統中，重復故障可能會導致雪球效應并使整個系統癱瘓，為了限制操作的持續時間，我們可以使用超時機制，因為超時可以防止掛起操作并保持系統回應，
但是，在微服務中合適的超時設定是不可能精確到每個介面方法的，根據個人開發經驗，系統里通常都是配置一個大概的全域超時時間或框架默認超時時間，
系統處于高度動態的環境下，一段時間內，某些介面呼叫多，某些介面呼叫少，網路帶寬占用也隨著介面呼叫而改變，超時時間不可能隨著環境和資源變化而動態改變，
有些公司會通過配置中心來自動適配超時時間，但是哪怕可以通過配置中心動態配置超時時間，開發和業務又不可能隨時隨地修改發布合適的超時配置來適應環境變化，
為了解決靜態超時機制的不足，我們可以使用斷路器來處理錯誤，相對靈活動態應對環境變化，
斷路器（Circuit Breaker）以現實世界的電子元件命名，因為它們的作用是相同的，斷路器的主要作業原理是：
（1）、當特定型別的錯誤在短時間內多次發生時，斷路器會被打開；
（2）、開路的斷路器可以防止進一步的請求，就像我們平時所說的電路跳閘一樣；
（3）、斷路器通常在一定時間后關閉，在這期間可以為底層服務提供足夠的空間來恢復，
一些斷路器也具有半開狀態，在這種狀態下，服務發送第一個請求以檢查系統可用性，同時讓其他請求失敗，如第一個請求成功，它將使斷路器恢復到關閉狀態并使流量流動，否則，它保持打開，
總的來說，斷路器的核心功能主要就是三大塊：
（1）、呼叫資料度量統計，比如介面例外或者超時次數等
（2）、維護斷路器自身的狀態，包括Closed（關閉）、Open（打開）和Half Open（半開）三種狀態
（3）、基于前兩點保護包裹在斷路器中執行的呼叫
目前PowerDotNet和PowerDotNetCore實作的默認斷路器按照介面消費者介面呼叫例外和超時總次數，進行斷路器狀態的變更及快速失敗回傳處理，個人認為這是最簡單的斷路器實作，
想給介面消費者應用添加呼叫介面斷路器功能，手動在配置中心點點，配置好三個引數發布后就可以正常使用了，可任意控制斷路器開關啟停，極致的便利，
9、API風格
PowerDotNet和PowerDotNetCore的服務治理平臺早期支持RPC和REST兩種常見風格的API命名，隨著開發迭代積累，越來越發現REST相對RPC沒有任何優勢，多數情況下反而成為開發和管理的負擔，
信奉REST教條的老學究們在口頭理論上說的頭頭是道，開發者卻為想URL名、寫對接檔案以及回傳code而苦不堪言，這些明明都是可以通過看RPC介面名和說明就能分分鐘搞定的事情，
PowerDotNet和PowerDotNetCore的服務治理平臺目前已經從REST邪路回歸到RPC正途，尤其是所有基礎設施服務做了微服務改造后，極大地降低了開發者心智負擔，顯著減少了API對接作業量，
RPC風格的API命名也很有講究和規律，最直接最推崇的命名方式是【公司.產品線.系統.子系統.服務類名.服務方法】或者【公司.系統.子系統.服務類名.服務方法】，看公司規模大小，按需選擇介面命名方式，
六、基礎設施
基礎設施即服務，PowerDotNet和PowerDotNetCore現有的基礎設施服務已完成微服務改造，在穩定性可靠性高可用性最大程度得到保障的前提下，部署運維方便程度也有了極大提升，
將PowerDotNet和PowerDotNetCore依賴的所有基礎設施服務抽象并進行統一管理，能夠最大限度的復用，降低開發運營成本，提升開發效率，
下面列舉下PowerDotNet和PowerDotNetCore主要應用和服務的依賴關系和啟動順序，
1、啟動Power.DataX的Power.DataX.DBKeyApi服務
最穩定的介面服務，零依賴，
2、啟動Power.XLogger的Power.XLogger.WebApi服務
僅依賴Power.DataX的DBKey服務， 如日志服務使用佇列，還需啟動佇列消費者Power.XLogger.MQConsumer，
3、啟動Power.XMonitor的Power.XMonitor.WebApi服務
依賴Power.DataX的DBKey服務和Power.XLogger，如監控使用佇列 ，還需啟動佇列消費者Power.XMonitor.MQConsumer，
4、啟動Power.Platform的Power.Platform.WebApi服務
依賴Power.DataX的DBKey服務、Power.XLogger和Power.XMonitor，這個應用包含了應用基礎服務和配置中心相關服務，
5、啟動Power.RegistryCenter的網關Power.SGS.Gateway服務
依賴Power.DataX的DBKey服務、Power.XLogger、Power.XMonitor和Power.Platform
6、啟動Power.RegistryCenter的Power.SGS.RegistryWebApi服務
依賴Power.SGS.Gateway、Power.DataX的DBKey服務、Power.XLogger、Power.XMonitor和Power.Platform
7、啟動其他框架服務
PowerDotNet和PowerDotNetCore開發的其他常用框架服務，比如訊息佇列、快取、資料同步、定時任務等等，這些應用就無所謂順序了，
以上可以認為是PowerDotNet和PowerDotNetCore的平臺基礎設施，搭建好環境并啟動服務以后可以按需開發很多種形式的應用，
強烈建議將PowerDotNet和PowerDotNetCore的平臺基礎設施服務以非Web宿主的形式部署運行起來，這樣便于后續撰寫啟動腳本來控制啟動順序，
目前可以通過bat腳本啟動這些基礎設施服務，對于多機器多容器多集群部署，總體復雜度可控，不過隨著外部依賴和部署復雜度的增加，腳本復雜度必然也會隨之增加，
PowerDotNet基礎設施服務看上去有點多，但如果你折騰過Dubbo、Nacos（Apollo）、Envoy、Redis等自建微服務環境或直接使用SpringCloud全家桶，PowerDotNet實在是太易用太人性化了，
從基礎設施服務可以看出，目前PowerDotNet和PowerDotNetCore還是屬于輕量級侵入式的名字服務范疇，不支持目前大廠比較流行的非侵入性的服務網格（Service Mesh），
注：服務網格（Service Mesh）是一個對于業務開發而言“非侵入性”的基礎設施層，通常采用邊車（SideCar）模式，用于處理服務間通信，典型代表包括Istio和Linkerd，還有后起之秀Dapr，
PowerDotNet和PowerDotNetCore核心功能已成熟穩定，且性能良好，能滿足絕大多數業務場景，對于服務網格，正如奧卡姆剃刀原理所說，如無必要，勿增物體，目前沒有進化到這個階段的迫切需求，
PowerDotNet和PowerDotNetCore基礎設施在通用性、可用性和易用性方面已經得到了充分驗證，遵循KISS原則，簡單即是美，反對恐龍設計，堅持自我，我就是我，是顏色不一樣的煙火，咩哈哈，
保證基礎設施的高可用是PowerDotNet開發的重中之重，目前主要技術選型都有完善的后臺管理和監控工具，也有兜底解決方案，比如添加備用節點排除單點，添加可啟停配置開關等，這些都是管理后臺點點按鈕的事情，
網路和IO是計算機上最典型的兩個瓶頸，尤其是網路，在互聯系統中網路通常是最容易爆出問題的節點，同時也是各個大中小廠工程師們甩鍋的萬能借口^_^，
PowerDotNet源于SOA架構，主要基礎設施原來是兩個單體服務，現在也按照微服務架構徹底拆分了，但是相比單體服務，拆分后出現事件的概率反而極低，
原因我猜可能是網路問題有了極大改善，因為千兆網卡對中小公司可以算是標配，現在中大型公司自建IDC多數都是萬兆網卡，土豪公司用RDMA網卡也不稀奇，
PowerDotNet和PowerDotNetCore雖然內部基礎設施服務較多，呼叫關系復雜，呼叫鏈路冗長，但是在服務治理平臺治理下，已經在實踐中證明能夠保證服務的穩定可靠，
基礎設施服務除了要求穩定可靠之外，還要求像普通業務邏輯型API服務一樣支持無感橫向擴容，服務治理平臺支持所有API服務的無感橫向擴容，對于分布式場景下的穩定性保障非常有意義，
七、框架工具
這部分偏重于框架的工具服務能極大提升開發者作業效率，減少重復建設，比如定時任務調度平臺、資料同步平臺、快取平臺、訊息平臺、檔案平臺等等，
框架工具建議技術選型優先選擇成熟穩定用戶眾多資料齊全的，不迷信大廠或所謂大牛的新作品，當然私下自己學習參考這些新作品毫無問題，但一定要謹慎在生產環境推廣使用，否則出現問題自己體會吧，
這些框架工具服務當前都是可選或者可擴展的，默認技術選型都是主流技術產品，預留出可擴展的介面定義，對于豐富PowerDotNet和PowerDotNetCore的技術選型大有裨益，
八、代碼生成
PowerDotNet和PowerDotNetCore的自動代碼生成工具主要包括基于DBKey和自研ORM一鍵前后端代碼生成、服務代理自動生成、組態檔生成和自動心跳集成工具等，
有了這些輔助代碼生成工具，對于日常開發作業而言，可以至少減少百分之八十的作業量，解放開發者的雙手，讓開發人員將更多時間和精力集中放在更有價值的事情上，
九、服務編排
我們開發的絕大多數業務邏輯型應用服務天生就會產生依賴關系（比如對保持高度穩定的基礎設施產生依賴），尤其是流行的SOA或者微服務架構，有時候呼叫鏈的復雜程度非常恐怖，
舉例來說，比如支付系統中的信用卡服務，在支付系統內部，信用卡服務依賴支付基礎、風控等服務，在公司內部可能還依賴個人用戶服務，在公司外部還依賴銀行、銀聯、清算中心等等，
為了編排服務的啟動順序，PowerDotNet參考了網上很多文章，比如Docker-compose、Docker Swarm、Helm、Kustomize、Apache Mesos和Google Kubernetes（K8S）等等解決方案，
經過權衡對比后，還是認為這些解決方案太重太復雜，單單一個重寫以支持容器部署就有不少的作業量，更不要說還需要人工寫很多易錯的啟動腳本，和PowerDotNet的初衷背道而馳，
服務編排是PowerDotNet和PowerDotNetCore需要解決的一大技術難題，我個人所服務過的公司沒有一家有完美的解決方案，也許K8S是個不錯的選擇，或者土豪一把直接使用云服務，
所謂傻人有傻福，笨人有笨方法，對于呼叫關系復雜的應用部署，PowerDotNet提供了簡易自檢程式，可以在啟動服務前，在自檢小程式中輸入服務名稱檢測服務是否可達，
同時服務治理平臺Power.RegistryCenter提供了快速呼叫服務助手，可以通過切換應用服務器地址進行心跳健康檢查來達到檢測服務是否可用的目的，對于一般應用也堪堪夠用，
十、應用開發
亂花漸欲迷人眼，CRUD特別繁，現在的應用程式越來越呈現出依賴項多，業務流程冗長，呼叫鏈復雜等技術特點，由此也產生了很多依賴復雜的開發套件和工具，也出現了Serverless等新的架構模式，
和很多流行的全家桶式開發套件有異曲同工之妙，通過PowerDotNet和PowerDotNetCore的基礎設施、框架工具和自動代碼生成工具，開發人員可以快速無障礙的流水線式開發業務邏輯型應用程式，
本文不直接比較流行的全家桶套件和PowerDotNet（PowerDotNetCore）的優缺點，看前面本系列的介紹你應該能感受到PowerDotNet和PowerDotNetCore的易用性，
下面簡單演示下在PowerDotNet和PowerDotNetCore環境中如何快速開發接入一個新應用，讓你直觀理解到開發業務邏輯型應用程式是多么快速而幸福的事情，
1、創建應用
系統應用平臺負責創建系統和應用，
新增應用歸屬哪個產品線哪個系統，需要和業務部門負責人溝通好，應用開發和負責人都是必填的，后續監控預警發送郵件等都需要這些人員資訊，
應用密鑰是必須的，對于內網應用，呼叫非敏感介面通常可以放行，但是如果服務治理中心勾選了驗證簽名，應用密鑰是最重要的驗簽引數，所以需要應用開發者妥善保管，
如果應用密鑰因為安全需要必須進行變更，需要業務部門負責人審核才能修改，否則密鑰修改而應用端沒有及時更新造成大面積簽名失敗事件，
2、配置中心
系統應用平臺可直接初始化應用配置，
所有需要接入配置中心的新應用，都可以在系統應用平臺初始化應用配置，系統應用平臺提供快捷工具分組拷貝或者匯入配置，非常方便，
如果是前端、客戶端、APP等不需要接入配置中心的應用，可跳過自動初始化應用配置這一步，當然某些特殊情況下也支持客戶端通過網關自動獲取配置中心配置，
初始化的配置中，除了通用配置引數，心跳，服務治理，DBKey、RPC、快取、檔案、日志、監控等配置引數應有盡有，開發人員通常點點按鈕改幾個配置引數就好，
如果配置中心的配置直接復制于同系統下的相似應用，絕大多數情況下一個引數都不用改動，對于開發人員而言簡直摸魚偷懶神器，
特別提醒，日志資料庫的DBKey約定都以LogDB_開頭，比如：LogDB_Writer_MySQL,LogDB_Writer_PostgreSQL,LogDB_Writer_MongoDB,LogDB_Writer_ElasticSearch，
對于不需要應用自己直接寫日志資料庫記錄日志的情況，可以在配置中心配置日志服務地址，間接通過日志平臺記錄日志，這也是PowerDotNet推薦的做法，
3、應用示例
PowerDotNet有很多腳手架模板，包括WebForms、MVC、Winform、RF、Android、VUE、React、WebApi、WebService、Apix、WCF、.NET Remoting、Hessian、gRPC、Thrift等，
這些腳手架內置了接入PowerDotNet或PowerDotNetCore的默認配置，絕大多數應用只需要對默認配置稍作修改，開箱即用，大大降低了開發人員搭建環境的時間成本，
通過PowerDotNet和PowerDotNetCore，最多5分鐘就能創建一個自動集成網關、配置中心、注冊中心、快取、日志、監控等服務的新應用，想想用SpringCloud寫個HelloWorld搭建環境要折騰多久，
有了PowerDotNet和PowerDotNetCore基礎設施服務和框架工具的強有力的支撐，開發人員寫一個兩個應用，十個八個應用，幾十上百個應用甚至成千上萬個應用都不在話下，
（1）、后端應用
我們以一個典型的WebApi服務來舉例，新增一個應用，名稱叫Power.BaseData.WebApi，那么這個應用的默認組態檔如下：
<?xml version="1.0" encoding="utf-8" ?> <appSettings> <add key="SystemCode" value="BaseData" /> <add key="AppName" value="Power.BaseData.WebApi" /> <!--配置是否本地優先--> <add key="LocalFirst" value="0" /> <!--網關相關配置 支持多個 以;或,分隔開--> <add key="GatewayURL" value="網關1;網關2;網關3"/> <!--API相關配置--> <!--自動推送Api介面服務物體--> <add key="App.AutoPushClazz" value="true" /> <!--服務負載均衡型別 Random表示隨機 Polling表示輪詢--> <add key="App.LoadBalance" value ="Random"/> <!--服務介面是否為本地部署 除錯選項用到 對應的是遠程服務器部署--> <add key="App.UseLocal" value ="false"/> <!--應用入口URL 由協議、主機或域名及埠號構成 80或443埠可以省略--> <add key="App.HostUrl" value="http://{ServerIP}:{Port}" /> <!--實際部署宿主應用型別 參考：WebApi、WebService、WCF、WindowsService、WinForm等--> <add key="App.DeployAppType" value="WebApi" /> <!--資料庫相關配置--> <add key="DBType" value="MySQL"/> <!--啟用的資料庫型別 目前支持SQLServer、MySQL和PostgreSQL--> <add key="BaseDataDB_Writer_MySQL" value="BaseDataDB_Writer_MySQL"/> <!--日志資料庫型別 目前支持SQLServer、MySQL、PostgreSQL、MongoDB和ElasticSearch--> <add key="LogDB_Writer_MongoDB" value="LogDB_Writer_MongoDB"/> </appSettings>AppConfig
在系統應用平臺我們可以對IP、埠、域名等進行申請和系結操作，
上面的配置中，App.HostUrl可以通過占位符自動決議應用服務器IP（當然也可以自己直接手動系結IP或域名），埠號則需要在系統應用平臺指定，防止應用程式埠沖突，埠分配必須規范有序，
在開發環境中，我們可以將是否為本地部署App.UseLocal配置為true，這樣服務治理平臺就知道這是一個除錯服務器，暫時不拉人集群給其他服務呼叫，對開發除錯排除干擾非常有用，
一個后端服務，組態檔通常只有上面這么多，其實示例中API相關配置（App.HostUrl必選）、資料庫相關配置都是可選的，這些都可以在配置中心處理，也就是說一個后端新應用，配置可精簡到只有5個，
如果某些應用的App.HostUrl就沒有，PowerDotNet自定義了一套規則，可以像下面這樣配置：
<add key="App.HostUrl" value="none://{ServerIP}:noport" />
歸根結底，一個新應用，最多只需要SystemCode、AppName、LocalFirst、GatewayURL最后再加一個App.HostUrl這5個配置，不能再多了，這樣就能享受到PowerDotNet開發的便利，咩哈哈，
（2）、客戶端應用
在PowerDotNet和PowerDotNetCore中，所有非后端應用都必須通過服務治理平臺的網關間接呼叫介面完成互動，所有非后端應用都不能直接呼叫敏感介面，如DBKey、支付、財務、結算、人員資訊等介面，
以一個WinForm程式舉例，應用名稱叫Power.BaseData.ApixTool，這是一個呼叫Apix介面的WinForm程式，它的默認配置可能是下面這樣的：
<?xml version="1.0" encoding="utf-8" ?> <appSettings> <add key="SystemCode" value="BaseData" /> <add key="AppName" value="Power.BaseData.ApixTool" /> <!--配置是否本地優先--> <add key="LocalFirst" value="0" /> <!--網關相關配置 支持多個 以;或,分隔開--> <add key="GatewayURL" value="網關1;網關2;網關3"/> <!--自動推送Api介面服務物體--> <add key="AppSecret" value="應用密鑰" /> </appSettings>AppConfig
客戶端程式默認配置只是把App.HostUrl換成AppSecret，AppSecret內容可以是明文也可以是密文，如果是內網客戶端，被呼叫的服務都沒有勾選驗證簽名和token，AppSecret配置也不是必須的，
（3）、前端應用
最典型的就是Angular、VUE、React、Svelte等SPA單頁應用，配置好網關、系統、應用名和應用密鑰，通過Axios模板方法呼叫網關就可以間接通過服務治理平臺和后端服務進行資料互動，
上面示例是React應用，對于后端介面，除了驗簽，可能還會有登錄token校驗邏輯，PowerDotNet和PowerDotNetCore都支持，
（4）、其他應用
其他應用包括安卓、RF、Pad、iOS等等形式的應用，和客戶端應用非常類似，配置好網關、系統、應用名和應用密鑰，就可以通過網關間接和后端服務進行資料互動，簡直神速，
4、服務治理
如果新增的應用是后臺服務介面，可通過配置中心自動注冊服務介面，也可以在服務治理平臺管理后臺人工注冊服務介面，默認注冊的新介面都會自動加入服務消費白名單，
新增應用如果需要呼叫并消費其他應用的API服務，分兩種情況進行處理：
（1）、網關間接呼叫介面，要看服務治理中心授權的服務是否勾選驗簽和驗證token，如果是外網網關，必須構造簽名和token驗證，否則介面消費驗證不通過，
（2）、客戶端直接呼叫介面，也要看服務治理中心授權的服務是否勾選驗簽和驗證token，當然如果是內網不敏感介面，直接呼叫即可，
5、集群管理
系統應用平臺可進行大規模集群管理，
所有后端應用，都可以在系統應用平臺將應用拉入某個資料中心的集群，便于集群管理，當然對于一些不需要集群管理的后臺管理系統，這不是必須的，
對于所有后端服務介面應用，注冊應用API介面后，必須在系統應用平臺將應用拉入某個資料中心的集群，進行集群管理，發布時可通過拉入拉出集群控制服務器是否可達，
系統應用進行集群化管理可以實作應用的優雅上線和下線功能，軟體可以控制的事情就不要讓硬體來做，PowerDotNet能完成的事情就不要讓其他軟體來做，
6、日志管理
如果新增應用在配置中心接入了日志平臺，登錄日志平臺管理后臺，自動同步DBKey即可在日志平臺查詢日志，
7、監控管理
如果新增應用在配置中心接入了監控平臺，登錄監控平臺管理后臺，可以看到監控收集到的資料，尤其是對于后端應用，監控平臺能及時預警發現問題，
十一、資料處理
我們平常所開發的大部分業務邏輯型應用程式都是資料密集型（data-intensive）而非計算密集型（compute-intensive），也就是說系統的瓶頸通常都來自于對資料的處理而非CPU，
資料庫、訊息佇列、快取、檔案等中間件或軟體工具都可以被統稱為資料系統，隨著技術的不斷發展，它們之間的界限也越來越模糊，
比如某些NoSQL資料存盤軟體可以被當成訊息佇列用（參考Redis），而訊息佇列則帶有類似資料庫的持久保證（比如RabbitMQ、RocketMQ和Kafka等），
PowerDotNet和PowerDotNetCore平臺化軟體的設計與實作偏重于資料處理，對主流的技術選型都做了大量深度開發，簡化運維部署的復雜度，提高資料系統的高可用性，
同時業務功能模型選擇也有很多講究，比如支付和財務平臺系統的壓力非常大，所以系統互聯互通的時候，優先推薦拉模式，而不是支付和財務平臺主動推送模式，雖然支付財務主動推送是標配，
對于經典的發布-訂閱模式，建議采用訊息總線進行統一管理，PowerDotNet和PowerDotNetCore不建議接入應用方直接使用各種中間件的發布訂閱功能，否則高并發下容易產生性能問題，
PowerDotNet和PowerDotNetCore已經開發出了典型的資料處理為主的公共服務平臺，如支付、財務、結算、CRM等系統，后續文章會講講支付平臺、財務平臺等系統的架構設計與開發，
作者：Jeff Wong
出處：http://jeffwongishandsome.cnblogs.com/
本文著作權歸作者和博客園共有，歡迎圍觀轉載，轉載時請您務必在文章明顯位置給出原文鏈接，謝謝您的合作，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/540418.html
標籤：其他