PowerDotNet平台化軟體架構設計與實現系列（03）：系統應用平台
為了復用和解耦，快速開發更多的系統和應用，我們對自己經常說的「系統」和「應用」進行更高級的提取和抽象。
十多年前入行，輾轉至今，寫過很多很多應用，個人喜歡分門別類整理知識，也看到有些公司這樣管理應用（照貓畫虎還是挺容易的），所以有個趁手的系統應用管理平台就是順理成章的事情。現在PowerDotNet就把我自己所理解的系統應用平台最基礎最核心的功能做出來，迭代幾次後比初始版本加了不少擴展，給系統應用良好運維和管理打下基礎。
一、系統
不同的業務部門，我們可以抽象為一個或多個系統，比如金融部門，可以抽象出賬戶系統、支付系統，財務系統，結算系統，風控系統等。
對於一個完備的電商解決方案，我們能想到的業務系統包括：供應鏈、庫存、生產加工、訂單、購物車、支付、財務、結算、票券、虛擬貨幣、商城、商品、原料、運輸、配送、搜索、秒殺、團購、（雲）列印、CRM、CTI、活動、消息（含郵件、簡訊、微信、釘釘）、多媒體、倉庫管理、開放平台等。可能用到的最底層的基礎設施系統包括：負載均衡、消息隊列、分散式快取、海量文件、企業服務匯流排ESB、網關、分散式資料庫、日誌、定時作業、應用升級、程式碼生成器、資料庫管理、數據同步、自動化發布、自動化運維和監控等。我個人實際參與或主導開發過的系統，包括：基礎數據、CRM、訂單、OA、支付平台、定時任務、網關、應用升級、程式碼生成器、服務治理、財務、結算、搜索、物流、消息、票券、虛擬貨幣、MES（生產加工）、WMS（倉庫管理）、QMS（品質管理）、TMS（運輸管理）、DMS（配送管理）、監控等等，基本上電商領域的資金流、資訊流和物流都有涉獵，咩哈哈。好幾年前流行的所謂全棧，其實只要多搬幾年磚，PC、H5、APP、RF、PAD等形式的應用都寫寫，後端、前端、客戶端、小程式等等都給它覆蓋到，外加程式設計師都愛折騰，各種環境自己負責發布和運維，誰還不是獨當一面的多面手呢？
系統的抽象和分解， 非常考驗開發人員的架構（業務架構、應用架構、數據架構、技術架構）水平。
二、應用
應用有不同的表現形式，不同的應用類型有不同的關注點。
一般公司的應用都可以分為帶介面或者不帶介面的，服務或者非服務等等等等，拆分方法不同，關注的應用形態也就不同。
應用的命名也是一門學問，通常要適合自己公司的規範，雜亂無章缺少規劃的命名是必須要避免的，關於命名的規範和通用規則本文不再贅述。
2、應用部署管理
我們的應用，最終是要在伺服器或者客戶端上運行的，運維部署同樣是開發需要著重考慮的問題。尤其是DevOps流行以後，可運維便於部署的開發模式肯定更容易被開發人員接受。
支援應用部署心跳健康檢查、移入或移除集群等操作：
後續講到配置中心和服務治理的時候，為了保證應用配置或者API服務的及時性和高可用，可能會按需引入ETCD和Redis等基礎組件，當然這些基礎組件都是插件化使用的，不是必須，我也提前實現了ETCD和Redis的人工管理（其實ETCD和Redis完全值得我們寫出獨立的管理平台去運維管理，後續文章我會詳細介紹）。
應用部署還需要考慮多數據中心多機房多集群的問題，PowerDotNet在這方面考慮的比較周到，並預留了很多擴展介面，比如下面幾個重要基礎設施：
（1）、數據中心和集群
集群主要描述了一個集合，一些相似的東西，提供相似的功能，這個就叫做集群。單機處理到達瓶頸的時候，把單機複製幾份，這樣就構成了一個「集群」。
（2）、伺服器
集群中每台伺服器就叫做這個集群的一個「節點」，所有節點構成了一個集群。每個節點都提供相同的服務，那麼這樣系統的處理能力就相當於提升了好幾倍（有幾個節點就相當於提升了這麼多倍）。
（3）、域名和負載均衡
上述圖片僅列出部分功能效果，供大家參考。
如果系統和應用很多，關係複雜，完全可以獨立出一個一級菜單進行應用集群管理。
當然實際的集群管理比我截圖複雜的多。
3、應用配置
如果熟悉常見的配置中心，大家都能夠猜到配置管理主要是用來做什麼的。
PowerDotNet配置中心借鑒了ZooKeeper、Apollo、Nacos等成熟解決方案，並貼近實際開發人員進行了整合創新，通常業務需求應用開發只要點點按鈕即可快速搞定。
配合配置中心客戶端工具，可以達到配置增刪改「實時」生效的效果。
配置文件會在本地磁碟生成一份，每次配置有變更，拉取成功後再保存在本地，這樣哪怕配置中心掛了，也不影響應用正常啟動和使用。
配置變更的歷史都有保存，變更之間能進行diff，支援配置的快速回滾操作。
在分散式環境下，可以追溯各個應用伺服器部署實例獲取配置的生效狀態，便於快速排查定位伺服器問題。
PowerDotNet配置中心完美支援對配置的增刪改查、推送、回滾、追溯和審計功能。
三、系統分組
一個系統，由一個或多個應用構成。而系統和系統之間，有時候也會有這樣那樣的聯繫。
系統間的關係，需要我們繼續抽象。於是便有了系統分組概念。比如上面提到的金融部門，可以抽象出賬戶系統、支付系統，財務系統，結算系統，風控系統等。我們可以把支付、財務、結算、風控等系統歸到一個或多個分組裡。
再比如某個集團公司業務部門很多，業務邏輯複雜，按主業務拆分後每個業務部門都有獨立的CRM、庫存、訂單、支付、財務、結算等業務系統，系統分組也是必不可少的，有時候甚至需要按照獨立公司進行部署，這種情況個人開發多商戶平台系統的時候就遇到過，這個多商戶平台系統，其實就是支付平台，PowerDotNet系列後續文章會詳細介紹，咩哈哈。
四、互聯繫統
系統和系統之間，不可避免的需要進行數據互聯互通。
通常我們通過對外發布RPC介面的形式進行數據交互（特殊情況下也可能進行直接資料庫訪問，特殊情況有機會再說）。
如果沒有系統和應用基礎設施的抽象，互聯互通會困難重重，自動化運維部署基本無從談起。
工欲善其事，必先利其器。
系統和應用的提取和抽象，是大中型互聯繫統解耦的基石，是軟體架構設計思想的提升，是程式開發良好組織管理的必要條件，為後續各種中間件、框架或工具的高效組織和使用打下基礎。
下一篇介紹PowerDotNet實現的互聯繫統。
