IMG_20161026_142532.jpg
隨著業(yè)務(wù)發(fā)展球恤，業(yè)務(wù)功能的堆疊和復(fù)雜化辜昵，團(tuán)隊壯大，代碼量也增加咽斧，各種問題開始凸顯：
- 代碼結(jié)構(gòu)開始變得混亂堪置，難以管理，提交沖突张惹，改一處引多處舀锨。
- 溝通成本變高。
- 代碼維護(hù)難：“修復(fù)越多宛逗，缺陷越多”坎匿。
- 引入和集成技術(shù)變得困難，依賴版本沖突雷激，新特性無法使用替蔬。
最后開發(fā)效率也開始下降，代碼維護(hù)的成本提高屎暇。
上線后穩(wěn)定性不高承桥，更大幾率的影響可靠性和可用性，所有功能都運(yùn)行在一個進(jìn)程中根悼，任何一個功能中出現(xiàn)bug凶异，比如內(nèi)存泄露，邏輯死循環(huán)耗盡CPU等挤巡，可以導(dǎo)致整個應(yīng)用掛掉剩彬。
其中幾個高并發(fā)功能，也不得不部署將所有功能增加部署實(shí)例矿卑，內(nèi)存和CPU利用不夠充分襟衰，靈活性也變差。
其缺點(diǎn)也很明顯：
- 運(yùn)維工作量增加，應(yīng)用運(yùn)維管理復(fù)雜瀑晒。
- 代碼重復(fù)率增加绍坝，團(tuán)隊自治帶來的重復(fù)勞動。
- 分布式系統(tǒng)固有的復(fù)雜性和缺點(diǎn)：網(wǎng)絡(luò)延遲苔悦，不可靠轩褐，負(fù)載均衡，調(diào)用玖详，事務(wù)等等
微服務(wù)架構(gòu)可以從一定程度上解決或緩解上述問題把介，但它也不是萬能的，但也帶來了一系列的非功能性需求蟋座，比如說分布式事務(wù)拗踢、自動化運(yùn)維，服務(wù)發(fā)現(xiàn)向臀，服務(wù)路由等額外需求巢墅，但其帶來的好處以及克服其缺點(diǎn)總結(jié)如下：
- 服務(wù)發(fā)現(xiàn)帶來很多自運(yùn)維特性。
- 單一職責(zé)原則在各種各種場景的解耦合
- 業(yè)務(wù)開發(fā)：只關(guān)注小團(tuán)隊所熟悉和負(fù)責(zé)的業(yè)務(wù)券膀，做到專而精君纫，并且容易實(shí)現(xiàn)持續(xù)交付。
- 代碼管理：無論多git repository還是多maven module都可以做到一般的代碼隔離芹彬，尤其是積累很多年的代碼蓄髓，拆分后更清晰不混亂，易管理舒帮。
- 技術(shù)實(shí)現(xiàn)：處理的業(yè)務(wù)不同会喝，可能會采取不同的技術(shù)棧，如果是單體玩郊，依賴有沖突的時候不得不花時間fix沖突或者妥協(xié)放棄集成肢执。微服務(wù)拆分后，相互獨(dú)立瓦宜，集成新技術(shù)更容易。
- 測試：尤其是對單元測試和自動化測試更有好處岭妖，但對于整個集成測試卻帶來了挑戰(zhàn)临庇，通過可視化運(yùn)維系統(tǒng)和一個完整的測試環(huán)境搭建，以及架構(gòu)上適當(dāng)調(diào)整昵慌，成熟化測試環(huán)境后假夺，可以彌補(bǔ)這種不便。
- 獨(dú)立部署斋攀，快速而出錯幾率比較低已卷，但運(yùn)維量比較大，但通過可視化自動運(yùn)維系統(tǒng)來克服淳蔼。
- 運(yùn)行時的隔離侧蘸，這個是顯而易見的裁眯，就跟汽車道路一樣，誰跑誰的道讳癌，互補(bǔ)干擾穿稳。
- 分布式事務(wù)也有很多成熟的參考方案來解決：補(bǔ)償型，可靠事件型晌坤，TCC型等逢艘。
- 服務(wù)調(diào)用上，可以通過超時骤菠、隔離它改、服務(wù)發(fā)現(xiàn)負(fù)載均衡提高可用性和可靠性。
- 網(wǎng)絡(luò)延遲商乎，可以采用輕量級協(xié)議和連接池技術(shù)等來彌補(bǔ)央拖。
