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ǔ)央拖。