二、從迭代的角度去考慮
服務拆分的缺點：
1.每個服務都需要單獨的機器部署，浪費資源,增加運維負擔；
2.服務拆分後會產生分布式事務、跨庫事務、跨庫分頁；
3.服務較多時，服務之間的依賴關係複雜，不好治理；
4.拆分後不便於排查問題，不便於debug；
5.特殊業務的服務歸屬問題難以決定，當乙個介面即可以放在a這邊，又可以放在b這邊或放在a這邊a覺得不合適，放在b這邊b覺得也不合適，即a覺得a要解耦，b應該內聚，而b恰恰相反，覺得自己的服務要解耦，讓其他服務內聚，會出現雙方架構上的爭論；
7.技術難度增加：一些服務拆分的細節問題需要考慮，定時任務問題，快取問題等；
服務拆分的優點：
1.將服務拆分後**整潔，模組分明，邏輯清晰，降低業務複雜度，減少不同業務之間的表的關聯查詢；
2.服務拆分將提高迭代速度和質量：服務拆分後乙個模組的版本回退不會影響另乙個（如果api不變的話），這樣可以先開發後決定是否提交測試；開發之間的依賴較少，可以流水線似的進行交付；
3.以服務為單位建立ab雙角色的負責人機制：傳統的以業務為單位建立負責人機制容易出現甩鍋現象，以服務為單位時，你在**上為別人提供服務的同時也要在開發過程中提供相關的服務；
4.降低耦合，乙個模組更新公升級對其他模組影響小
5.負載：
6.水平擴充套件、垂直拆分容易
7.讓各模組職責明確，邊界清晰，業務不會亂成一團，否則新加功能時只知道往整體塞，但不知道各個業務之間的聯絡和職責，導致最後系統越來也複雜。
8.乙個人乙個模組可以伴隨著個人的成長進行模組的優化，前提是需要經常由架構做**review。
服務拆分的粒度：
通過確定哪些優點你優先考慮，哪些缺點你可以接受來決定服務的粒度。
每個迭代會引起系統**的變動，從下面三個維度去考慮架構是否方有以下耦合
依賴的兩個層次：
1.系統間依賴：乙個系統的變動影響其他系統;
2.系統內依賴：乙個模組的變動影響同乙個系統內的其他模組；
影響的兩個層次：
1.介面依賴：乙個單元介面引數的變動會引起另乙個單元實現的變動
2.服務依賴：乙個單元停止服務會導致另乙個單元不能正常提供服務
變動的兩個層次：
1.改變依賴：乙個單元的修改或乙個介面的修改會影響到另乙個單元
2.新增依賴：乙個單元的增加或乙個介面的增加會影響到另乙個單元
服務拆分的粒度：
服務的拆分需要根據具體業務的重要性來決定細到哪乙個層次。
微服務架構思考
近些年來非常火爆的微服務架構，曾經讓我以前團隊 某團 後台組 從泥沼中脫身出來，輕鬆的應對線上大量的業務壓力，而如今卻讓我現在的團隊深入泥沼中。12年剛來某團 後台組的時候，只有乙個專案groupapi。只有4個rd因對c端版本迭代的開發，從3.5版本每日訪問量1kw。後來隨著業務隊伍的擴大，乙個專...
企業架構思考
roger sessions是objectwatch的cto。在紐西蘭teched2009的session arc203 services and complexity 分享了自己關於企業架構的獨特觀點，非常令人印象深刻，無疑可以給大家帶來很多思考。roger認為ea企業架構可以實現的所謂 立即的 ...
程式架構思考
可以將程式分為3部分，乙個是邏輯 logic 乙個是控制 control 資料結構 data structures 邏輯是用來解決實際問題的，也就是具體問題的實現。控制是將多個邏輯組合起來工作的方式，即邏輯組合的策略。資料結構是計算機中儲存 組織資料的方式。程式執行的效率取決於這三者的組合結果。如果...