新來老大年前開會說：各位同學，公司業務越來越重，未來幾年要成倍增長......，我們要梳理出一套新架構，才能更好的支援n萬使用者.....，以後公升職加薪當上....打敗.....
想想還有點小激動呢，於是過年時樓主趁等待相親妹紙無聊的時候，反思了目前系統現狀，構思設計新架構如下。
現有系統
新架構2.1 邏輯架構圖
2.2 解釋說明
系統實施
3.1 soa管理中心
3.2 發布服務
3.3 訂閱服務
3.4 採蘑菇示例
設計目標
4.1 盡可能少的侵入
4.2 服務自治&&水平擴充套件
4.3 系統公升級降級
常見問題
5.1 clientapi vs serviceapi
5.2 聚合服務
5.3 服務分級
總結心得
鄙司業務比較重，系統也有些年頭，各研發團隊、系統都比較穩定了。所以不差也不太好，總之也能滿足現有需求。但近2年o2o，移動網際網路等大行其道，老大們也都心動了，開始磨刀霍霍了。而現有系統應對複雜的變化，在一些地方頗顯不足：
邏輯架構圖：
檢視大圖
解釋說明：
這是新架構的核心部分，主要功能如下：
各系統通過web管理頁面進行服務配置發布。
也可以通過管理中心提供的元件，進行配置發布：);}
[servicefilter]
void getdetail()
各系統通過管理中心提供的元件，去獲取訂閱的服務，然後通過介面卡去訪問介面，服務變更在心跳裡面做:
這點是非常重要的，如果不能很好的重用已有的系統或侵入性太強，勢必會導致：
基於這種考慮，才採用服務分布式而不是服務集中式。
然後通過serviceadapter訪問服務，serviceadapter中會做許可權等一些校驗。
在服務上增加servicefilter，fileter會做許可權校驗及服務被呼叫的資訊採集。
然後在管理中心新增服務，文件描述。
好處是：a系統與b系統是直接互動的，服務呼叫不走中轉路由，效能也好。而元件的作用僅是輔助性的約束。
由於侵入性較小，所以各個系統之間的服務變更，維護完全由各自研發團隊維護。
本系統之間通訊不走服務，直接內部呼叫。呼叫通過serviceadapter元件訪問，serviceadapter包含對程序內、wcf、webapi等訪問的封裝，這樣便於以後替換成其他服務。 各服務在擴充套件上不受管理中心節制，自行做負載、增加伺服器即可。
當有個新需要過來時，會根據產品是否需要獨立部署，和現有系統耦合性等因素，來評估是模組級還是系統級。
對於舊模組，根據重要程度、訪問量等評估出分數。達標的由模組抽離出子系統，單獨管理。
同樣對於舊系統，不達標的進行降級處理，縮小成模組整合到其他系統裡面。
這塊其實很重要，如果不對專案做好評估的話，往往會導致乙個系統越來越沉重。最後的結果就是維護越來越麻煩，經常出問題。最後逼不得已就推到重來，這個成本就較大些，當然成本的事情老大會考慮更多些。處於這種情況下猿類們會一邊吐槽著之前的同類渣渣，一邊躍躍欲試準備大展身手，讓你們瞧瞧什麼叫ddd、tdd、設計模式......。
前提是在需求開發時，按模組進行分小層而不是整個大層，這樣方便協作開發和抽取成子系統。
clientapi這個在前期用的比較多的辦法。優點很明顯：簡單快捷，從nuget上安裝引用即可。這樣後期會問題越來越多。
就拿快取redis來說，多個系統都使用客戶端直接訪問redis伺服器。如果有個系統連線數忘記關閉，就會影響整個大系統，原因就是client許可權過大，客戶端是可以對redis伺服器直接進行操控。這種情況下redis伺服器本身是暴露在外的，哪怕客戶端封裝的再好也不行，只要研究下通訊協議規範，就可以自己寫個客戶端連線(參見c#實現redis客戶端(一))。 這個通訊期間無法管控，無法做攔截，同樣佇列等其他也是同樣情況。
我們在中間加了一層，在快取系統裡面做管控，同樣依賴抽象，redis可替換。快取系統以服務的形式發布給其他系統使用。 避免不了的就是效能有損耗，當然這個損耗可以通過一些手段減小。
服務的顆粒度一直是soa設計的頭疼事情。太粗了就很難復用，太細了需要多次往返互動，其效能、事務處理都是個問題。 比如下訂單服務，這個過程中包含建立使用者資料，生成預訂單、支付訂單，更新賬務關係，更新庫存等一系列的操作。這是個粗粒度服務，裡面包含若干子系統的提供的細粒度服務。 粗粒度服務下，多個子系統避免不了互相互動，長久下去會讓系統過於沉重，變得職責混亂。
服務設計準則就是讓服務高內聚，服務之間松耦合、邊界清晰。所以我們抽離乙個聚合服務系統，它專門負責把各系統提供的細粒度服務進行整合，提供給前端使用。而其他各個系統只做自己職責之內的事情。 在聚合服務系統中，方便我們更合理的把控服務的顆粒度，提高服務復用。
多個研發團隊協作時，很難每個人都對全部業務熟悉。所以為了避免服務呼叫混亂，甚至迴圈依賴呼叫，增加了對服務的分級。
按圖中所示，1級服務不能調2級服務，即低階不能調高階，高階可調低階，同級互相可調。
這個級別針對單個服務而分的。比如有個更新庫存服務，它沒有外部依賴的服務，只是更新自己的db，這樣我們就可以把它劃分為1級服務。 而我們的聚合服務系統中有個下訂單粗粒度服務，它內部呼叫更新庫存服務，那麼它就是2級服務。很明顯這裡的1級不應該呼叫2級，對服務分級也是這個目的。
SOA架構設計
架構是 套構建系統的準則，通過這套準則，把 個複雜的系統劃 分為一套更簡單的子系統的集合，這些子系統之間保持相互獨立，並與 整個系統保持一致，而且每 個子系統還可以繼續細分下去，從而構成 個企業級架構。soa是一種面向企業級服務的系統架構，簡單來說，soa就是一種 進行系統開發的新的體系架構，在基於...
SOA架構設計概要
主要內容也是來自 stevey對amazon和google平台的長篇大論 我們理解的soa必然是通過介面的方式將資料與功能開放出來的，但要想要往平台方向發展，必須保證用且僅用服務介面的形式提供資料和服務 團隊間的程式模組的資訊通訊，都要通過這些介面 除此之外沒有其它的通訊方式。其他形式一概不允許 不...
Atittit 研發公司的組織架構與部門架構總結
atittit.研發公司的組織架構與部門架構總結1.archi組織架構與 部門規劃21 1.最高五大組織機構21 2.宗教事務部21 3.制度與重大會議委員會21 4.糾紛處理部 31 5.行政部31 6.保安與治安維護部 31 7.31 8.行政大部下面的小部門31 8.1.總務部 負責具體的團隊...