新來老大年前開會說：各位同學，公司業(yè)務(wù)越來越重，未來幾年要成倍增長......，我們要梳理出一套新架構(gòu)，才能更好的支持N萬用戶.....，以后升職加薪當上....打敗.....
樓主感動淚奔，于是過年時樓主趁等待相親妹紙無聊的時候，反思了目前系統(tǒng)現(xiàn)狀，構(gòu)思設(shè)計新架構(gòu)如下。
閱讀目錄：
鄙司業(yè)務(wù)比較重，系統(tǒng)也有些年頭，各研發(fā)團隊、系統(tǒng)都比較穩(wěn)定了。所以不差也不太好，總之也能滿足現(xiàn)有需求。但近2年O2O，移動互聯(lián)網(wǎng)等大行其道，老大們也都心動了，開始磨刀霍霍了。而現(xiàn)有系統(tǒng)應(yīng)對復(fù)雜的變化，在一些地方頗顯不足：
這是新架構(gòu)的核心部分，主要功能如下：
各系統(tǒng)通過Web管理頁面進行服務(wù)配置發(fā)布。
也可以通過管理中心提供的組件，進行配置發(fā)布：
protected void Application_Start() { ServicePublisher.Pushlish(new ServiceConfig() { ServiceName = "獲取預(yù)訂單詳情", Qps = 1000, Level = 1, Key = "xxxx-yyyy", Source = SubscribeSource.All, ServiceAddress = "/Order/GetDetail", //其他 }); } [ServiceFilter] void GetDetail() { }
各系統(tǒng)通過管理中心提供的組件，去獲取訂閱的服務(wù)，然后通過適配器去訪問接口，服務(wù)變更在心跳里面做:
protected void Application_Start() { //獲取服務(wù)列表 var serviceList = ServiceManager.GetServiceList(); GlobalService.ServiceList=serviceList; } void Heartbeat() { var serviceList = ServiceManager.GetServiceList(); GlobalService.ServiceList=serviceList; } ServiceAdapter.Access(GlobalService.ServiceList[0]);
這點是非常重要的，如果不能很好的重用已有的系統(tǒng)或侵入性太強，勢必會導(dǎo)致：
基于這種考慮，才采用服務(wù)分布式而不是服務(wù)集中式。
好處是：A系統(tǒng)與B系統(tǒng)是直接交互的，服務(wù)調(diào)用不走中轉(zhuǎn)路由，性能也好。而組件的作用僅是輔助性的約束。
由于侵入性較小，所以各個系統(tǒng)之間的服務(wù)變更，維護完全由各自研發(fā)團隊維護。
本系統(tǒng)之間通訊不走服務(wù)，直接內(nèi)部調(diào)用。調(diào)用通過ServiceAdapter組件訪問，ServiceAdapter包含對進程內(nèi)、WCF、WebApi等訪問的封裝，這樣便于以后替換成其他服務(wù)。各服務(wù)在擴展上不受管理中心節(jié)制，自行做負載、增加服務(wù)器即可。
當有個新需要過來時，會根據(jù)產(chǎn)品是否需要獨立部署，和現(xiàn)有系統(tǒng)耦合性等因素，來評估是模塊級還是系統(tǒng)級。
對于舊模塊，根據(jù)重要程度、訪問量等評估出分數(shù)。達標的由模塊抽離出子系統(tǒng)，單獨管理。
同樣對于舊系統(tǒng)，不達標的進行降級處理，縮小成模塊整合到其他系統(tǒng)里面。
這塊其實很重要，如果不對項目做好評估的話，往往會導(dǎo)致一個系統(tǒng)越來越沉重。最后的結(jié)果就是維護越來越麻煩，經(jīng)常出問題。最后逼不得已就推到重來，這個成本就較大些，當然成本的事情老大會考慮更多些。處于這種情況下猿類們會一邊吐槽著之前的同類渣渣，一邊躍躍欲試準備大展身手，讓你們瞧瞧什么叫DDD、TDD、設(shè)計模式......。
前提是在需求開發(fā)時，按模塊進行分小層而不是整個大層，這樣方便協(xié)作開發(fā)和抽取成子系統(tǒng)。
ClientApi這個在前期用的比較多的辦法。優(yōu)點很明顯：簡單快捷，從Nuget上安裝引用即可。這樣后期會問題越來越多。
就拿緩存Redis來說，多個系統(tǒng)都使用客戶端直接訪問Redis服務(wù)器。如果有個系統(tǒng)連接數(shù)忘記關(guān)閉，就會影響整個大系統(tǒng)，原因就是Client權(quán)限過大，客戶端是可以對redis服務(wù)器直接進行操控。這種情況下redis服務(wù)器本身是暴露在外的，哪怕客戶端封裝的再好也不行，只要研究下通信協(xié)議規(guī)范，就可以自己寫個客戶端連(參見:c#實現(xiàn)redis客戶端(一))。 這個通信期間無法管控，無法做攔截，同樣隊列等其他也是同樣情況。
ServiceApi：
服務(wù)的顆粒度一直是SOA設(shè)計的頭疼事情。太粗了就很難復(fù)用，太細了需要多次往返交互，其性能、事務(wù)處理都是個問題。比如下訂單服務(wù)，這個過程中包含創(chuàng)建用戶資料，生成預(yù)訂單、支付訂單，更新賬務(wù)關(guān)系，更新庫存等一系列的操作。這是個粗粒度服務(wù)，里面包含若干子系統(tǒng)的提供的細粒度服務(wù)。粗粒度服務(wù)下，多個子系統(tǒng)避免不了互相交互，長久下去會讓系統(tǒng)過于沉重，變得職責混亂。
服務(wù)設(shè)計準則就是讓服務(wù)高內(nèi)聚，服務(wù)之間松耦合、邊界清晰。所以我們抽離一個聚合服務(wù)系統(tǒng)，它專門負責把各系統(tǒng)提供的細粒度服務(wù)進行整合，提供給前端使用。而其他各個系統(tǒng)只做自己職責之內(nèi)的事情。在聚合服務(wù)系統(tǒng)中，方便我們更合理的把控服務(wù)的顆粒度，提高服務(wù)復(fù)用。
多個研發(fā)團隊協(xié)作時，很難每個人都對全部業(yè)務(wù)熟悉。所以為了避免服務(wù)調(diào)用混亂，甚至循環(huán)依賴調(diào)用，增加了對服務(wù)的分級。
按圖中所示，1級服務(wù)不能調(diào)2級服務(wù)，即低級不能調(diào)高級，高級可調(diào)低級，同級互相可調(diào)。
這個級別針對單個服務(wù)而分的。比如有個更新庫存服務(wù)，它沒有外部依賴的服務(wù)，只是更新自己的DB，這樣我們就可以把它劃分為1級服務(wù)。 而我們的聚合服務(wù)系統(tǒng)中有個下訂單粗粒度服務(wù)，它內(nèi)部調(diào)用更新庫存服務(wù)，那么它就是2級服務(wù)。很明顯這里的1級不應(yīng)該調(diào)用2級，對服務(wù)分級也是這個目的。
