單體式的架構(gòu)更適合輕量級的簡單應(yīng)用，微服務(wù)架構(gòu)適合大型宾添、大團隊船惨、敏捷迭代型項目。
后臺架構(gòu)的演變：單體結(jié)構(gòu)（巨無霸） --> Dubbo 單體結(jié)構(gòu)（小巨無霸） --> 微服務(wù)普通結(jié)構(gòu) --> 微服務(wù)中臺結(jié)構(gòu)
微服務(wù)架構(gòu)更加敏捷缕陕，如果單體結(jié)構(gòu)的話粱锐，任何一次改動的發(fā)版，都要重啟整個應(yīng)用榄檬。系統(tǒng)之間的耦合度降低
- 代碼的獨立卜范。各自團隊負責各自微服務(wù)的代碼維護，互相不會影響鹿榜，也不容易造成代碼沖突。也包括code review锦爵、還有功能測試舱殿。下載代碼也不需要下載全部的代碼。如果共用代碼险掀，有的功能沒有開發(fā)好沪袭，有的小功能已經(jīng)開發(fā)好了，已經(jīng)開發(fā)好的功能沒法單獨上線樟氢。除非采用很多分支冈绊，拆分上線侠鳄。
- 微服務(wù)系統(tǒng)間的獨立。系統(tǒng)之間相對獨立死宣，非核心系統(tǒng)的發(fā)版或者異常伟恶，不會影響整個系統(tǒng)核心業(yè)務(wù)的運行。更加敏捷毅该。
- 數(shù)據(jù)的獨立博秫。各自服務(wù)負責各自的數(shù)據(jù)，特別是機密數(shù)據(jù)不需要開放給無關(guān)的人員眶掌。
- 業(yè)務(wù)的切分挡育，降低了單個服務(wù)的復雜性，負責某一服務(wù)的開發(fā)人員朴爬，只需要了解自己相關(guān)的業(yè)務(wù)即寒。快速上手召噩，focus在各自的業(yè)務(wù)上母赵。
- 人的獨立。團隊管理更方便蚣常。比如招一個人負責商品的服務(wù)市咽，則該小伙伴不需要了解支付、優(yōu)惠券抵蚊、庫存相關(guān)的業(yè)務(wù)場景施绎，只需要清楚商品相關(guān)的業(yè)務(wù)規(guī)則就可以了
微服務(wù)架構(gòu)缺點：
- 分布式事務(wù)的問題
- 提升了運維的難度（發(fā)版、問題排查贞绳、配置管理谷醉、監(jiān)控) -->催生了Jenkins + ELK +Spring Config + Spring Admin + Docker
- 單體結(jié)構(gòu)資源利用率比較高
- 性能降低。單體架構(gòu) 函數(shù)都是內(nèi)部調(diào)用冈闭，微服務(wù)的間通過REST俱尼、RPC等形式進行交互，通信的時延會受到較大的影響萎攒。
微服務(wù)的拆分：項目拆分 --> 業(yè)務(wù)拆分（中臺）--> 功能拆分
業(yè)務(wù)拆分：訂單系統(tǒng)遇八、支付系統(tǒng)、用戶中心耍休、卡券系統(tǒng)刃永、商品系統(tǒng) 等等
功能拆分：支付portal系統(tǒng) + 支付admin管理系統(tǒng)
