隨著企業發展，傳統的中心化，大平台的軟體系統設計越來越難以滿足現實要求。對於位於決策中心的集團總公司來說，制定管理規則，收集核心資料當然是it系統的主要功能。對於一線業務部門來說，他們也需要在總公司所制定規則基礎上相應的進行擴充套件以滿足其自身實際的需要。另外，無論是集團總公司還是一線業務部門，隨著業務的發展，管理系統也需要同步發展。由於不同業務部門的具體業務以及專案進度存在區別，中心化的大平台系統也很難滿足成長性要求。本文試圖給出一種星型結構的系統構架方案以解決以上所述問題。
基本結構
在本文中所述系統分為核心服務和衛星子系統兩部分。核心服務關注於規則的制定和實現。衛星子系統針對具體業務提供功能實現。核心服務對衛星子系統提供資料交換介面，通過資料對衛星系統進行干預。衛星子系統通過呼叫核心服務的介面獲取自身所需的資料。
圖 1核心服務和衛星子系統
核心服務通過最小資料集和流程簽名干預衛星子系統作業。最小資料集是指核心服務所關注的最小資料集合，比如個人基本資訊。核心服務不感興趣但是對於一線業務有意義的資料，則儲存在衛星子系統中。流程簽名是核心服務用來校驗衛星子系統是否按照既定規則交換資料。衛星系統中的某些功能被定義為若干工作節點所組成的流程，如審批流程。被訪問過的流程節點完成其工作後給出自己的簽名。多個工作節點的簽名由默克爾樹組織為簽名樹。默克爾樹的根節點即流程簽名（見圖2）。
這種星型的體系結構下，既能滿足**節點控制全域性的目的，又給衛星子系統留出了足夠的彈性。從成本結構來看，由於衛星子系統大量呼叫**核心服務介面，衛星子系統的建設和維護成本極低。核心服務的服務質量要求較高，相較衛星子系統維護成本較高。從時間維度來看，由於這種結構所提供的彈性更適合實際需求，免除了重複開發的問題，所以總體來說開發和運維成本還是低於傳統結構的。
圖2流程簽名
兩種結構的區別
子系統建設過程中，位於中心節點的核心服務需要面臨業務和技術兩個層面的挑戰。在業務層面，核心服務需要實現決策中心的集團總公司所指定的相關制度，也就是要提出具有指導性的業務模型。在技術層面，核心服務需要面臨流量、安全和io均衡三大挑戰。相應的，衛星子系統所服務的一線成員人數有限，特色服務數量有限，所以衛星子系統的開發主要是面臨業務層面的挑戰。由此，核心服務的建設過程對於業務專家和技術專家的要求都比較高。而衛星子系統則側重於業務專家。
相對於傳統的中心化大平台這種結構來說，衛星型系統的管理相交來說更為複雜。傳統的中心化大平台只需要維護乙個服務節點即可。衛星型的系統結構使得維護人員必須同時維護多個節點。當核心服務發生變更時，所有衛星子系統的資料獲取和處理都會受到影響。如果這種變化出現在流程控制上，對於衛星系統來說影響更大。衛星型系統結構會增強整個系統應對業務變化時的彈性，也極大的延長了其壽命。與此相對應的，維護工作的週期也變長了。
虛擬化技術提供了穩定且一致的it基礎設施服務。微服務和配置服務維護了一致性執行環境。通過這些技術可以減輕核心服務節點變動所帶來的影響。但是解決這一問題的根本還在於系統使用和運維規則的制度和相關人員的培訓。
區別於傳統的中心化大平台，星型結構的系統開發過程由資料、業務驅動轉變為由測試驅動。運維工作由監控轉為調整，特別是核心服務。為了應對業務和技術層面的挑戰，核心服務必然異常複雜。為了保證複雜系統中各部分的正常工作，單元測試、壓力測試、安全測試將成為週期性的工作。同樣的，核心服務這樣複雜的系統在長期執行過程中將產生大量的資料。運維工作需要根據這些資料適時地調整系統引數，以保證系統效能最優。另外，由於業務週期的變化，計算需求也是週期性變化的。在空閒期維持同樣量級的裝置空轉顯然是對計算資源的浪費。運維人員也需要對計算資源進行排程，實現彈性計算。
最小資料集和校驗方法
最小資料集是指核心服務關心的資料項，也稱必要資料集。最小資料集是衛星子系統必須向核心服務提交的資料。核心服務也只接受最小資料集中所要求的資料。對於超出最小資料集要求的資料，核心服務將預設忽略。
在星型系統結構下，衛星子系統向核心服務提交最小資料集時，對於核心系統而言有兩方面校驗問題。最小資料集的校驗過程是整個軟體體系（衛星子系統+核心訪問）魯棒性保證的核心方法。如果沒有這一過程，整個軟體體系的故障率無法保證收斂。
首先是最小資料集在網路傳輸過程中是否損壞。所以衛星子系統需要提供最小資料集的md5碼進行資料校驗。特別的，對於跨國業務，由於各國基礎設施質量差距巨大，在全球化部署時，這種驗證更加重要。
第二種是最小資料集的完整性校驗，也就是指最小資料集是否按照核心服務的規則，包含完整的資料項。用於區別不同資料集的資料項成為關鍵資料項。關鍵資料項的集合成為關鍵資料集。通過雜湊演算法，關鍵資料集轉化為雜湊值成為關鍵資料集的數字簽名。通過校驗關鍵資料集的數字簽名，核心系統可以校驗最小資料集的結構完整性。
最後一點，當最小資料集是非線性的，也就是說當最小資料集無法用行記錄表示，而是需要用「樹」結構來表示時，關鍵資料項就需要使用「模式」來進行完整性校驗。「模式」是關鍵資料項的結構定義（類似於xml體系中的xslt或dtd）。
流程控制
流程管理是指核心服務為了實現決策中心所規定的工作流程而制定的流程校驗方法。如前所述核心服務規定了必要的流程。這些流程由1個或多個必要節點組成。衛星子系統可以在必要流程中加入自己需要的邏輯節點。對於核心服務來說，除了要保證資料集的完整性，資料集結構的正確，還需要保證衛星子系統在邏輯處理過程中按照必要流程的規定，業務細節的處理過程經歷了必要流程中所有必要節點。
一種校驗方法是記錄節點簽名。當必要節點被訪問和執行結束後，必要節點給出自己的簽名。必要流程中所有的必要節點可以被組織為雜湊樹，根節點就是必要流程簽名。同時，這種方法也可以校驗哪些節點被忽略了。
訪問校驗
本系統結構為分布式的星型結構，所以區別於傳統的方式，oauth 2.0成為不二之選。oauth 2.0使得衛星子系統的訪問驗證可以由核心服務進行，實現了系統安全最重要的部分由核心服務控制。按照rfc6749的規定，oauth 2.0流程描述如下圖。
圖表 3
oauth 2.0
訪問控制
常見的訪問控制模型包括訪問控制表（acl）、按角色劃分的訪問控制（rbac）、按屬性劃分的訪問控制（abac）。對於管理系統而言，訪問控制常為以rbac為核心，輔以acl和abac模型的混合結構。訪問控制系統屬於核心服務範圍，但是在星型軟體結構下，訪問控制系統的快取系統大量分布於衛星子系統中。從結構上講，訪問控制在本文中是由核心服務控制，散布於衛星子系統中的一種分布式服務。
圖表 4
分布式控制訪問
如圖所示，大部分的訪問控制執行單元（這些單元大部分是快取系統）位於衛星子系統中。但是其過濾鏈和訪問控制a由核心服務控制。核心服務週期性的更新其資料。這種結構讓衛星子系統承載了訪問控制的壓力，並且為核心服務控制和衛星子系統的彈性提供了空間。
資料隔離
衛星子系統中大量的資料儲存在核心服務中。為了保障資料安全，核心服務需要針對不同的服務採取資料隔離策略。常用的資料隔離策略有庫隔離、表隔離和邏輯隔離。對於邏輯隔離，為了提公升訪問速度，資料將會均勻儲存於眾多資料庫中。但是這與庫隔離策略是不同的。庫隔離策略是指在單一客戶資料非常大或者非常敏感時，單獨建立資料庫為其提供排他的資料儲存。而邏輯隔離雖然將資料分別儲存於多個資料庫，但是並不具有邏輯上的排他性。
就邏輯隔離策略來講，資料通常以其主鍵的雜湊值進行模運算後進行分配。當資料查詢條件缺乏主鍵時，往往需要遍歷所有資料庫。這一操作的時間複雜度為o(n)級別。為了避免此類操作，通常採用redis或memcached簡歷外部的資料索引。通過結構設計，缺少主鍵的查詢操作可以降為o(1)或。
很多時候衛星子系統與核心系統差距不大。常見的情況是衛星子系統只有某些功能與核心服務有異。這種情況下衛星子系統需要裝配乙個路由閘道器（如spring cloud zuul），根據url選擇呼叫核心服務還是自己的特色服務。
圖表 5
輕衛星子系統
一種基於Makefile的編譯系統架構實現及自動化
一.我分享的是乙個簡化版的編譯架構，我要實現的目標是 對遵循以下組織結構的資料夾進行編譯 bb inc src entry modules module1 module2 src 目錄下可以允許有遞迴目錄或者檔案，最大深度不超過 5,makefile 定義規則會去自動搜尋所有的 c原始檔，編譯出的所...
一種應用程式命令執行架構設計
一種應用程式命令執行架構設計 袁永福 2011 7 5 有感於一些程式中aspx頁面中直接編寫功能性 難於組織和維護，實現不了程式的高度可配置化，自此提出一種應用程式命令執行架構，其架構圖如下 在這個架構中，每乙個應用程式中存在乙個host 宿主 它是應用程式功能模組組織中的頂級結構，它戰略上管理著...
跨國際鏈路的資料服務系統架構設計的一種實現思路
1.高效性 資料服務系統api嵌入到產品之後，不能對產品產生阻塞，如果因為這一點造成產品卡得不行，影響使用者體驗，那就和我們的初衷背道而馳了 2.穩定性 如果我們的資料中心宕機，對產品造成破壞性影響，那這就是個非常重要的隱患 3.易用性 api的介面必須簡潔，嵌入必須方便，這是出於控制擴充套件成本方...