煙囪式系統(tǒng)建設的弊端：
1.重復功能的建設和維護帶來的重復投資
2.煙囪式系統(tǒng)交互集成和協(xié)作成本高
3.不利于業(yè)務的沉淀和持續(xù)發(fā)展
?
1.重復功能的建設和維護帶來的重復投資
這一條很好理解就是當我們公司內部擁有多套子系統(tǒng)的時候屎暇，勢必會帶來一些重復性的工作先巴，比如說公司內部OA系統(tǒng)和報表系統(tǒng)闷营、兩個系統(tǒng)按照單獨的設計都會存在用戶管理功能锋叨，如果某一天公司需要在加一套管理系統(tǒng)的話，那么在管理系統(tǒng)中還需要添加一套用戶管理的邏輯玛瘸，該重復功能的建設工作和維護勢必會帶來時間璧针、資源上的浪費匕争。
?
2.煙囪式系統(tǒng)交互集成和協(xié)作成本高
隨著公司內部系統(tǒng)業(yè)務不斷的增加以及完善，多個系統(tǒng)之間的集成和交互也將變得困難贯卦，多系統(tǒng)之間的協(xié)作资柔、溝通成本較高，例如公司有一套mes系統(tǒng)（生產(chǎn)制造系統(tǒng)）該系統(tǒng)當中有wip模塊撵割、alm模塊當有一天我新建了一個報表系統(tǒng)去統(tǒng)計使用人數(shù)贿堰，那我需要從兩個系統(tǒng)當中分別去獲取用戶，帶來的時間成本和溝通成本是比較高昂的
3.不利于業(yè)務的沉淀和持續(xù)發(fā)展
不利于產(chǎn)品的快速跟新和迭代啡彬，當今互聯(lián)網(wǎng)項目每周每月都在不停的變化官边、市場的反饋根業(yè)務上的需要都需要得到快速的響應沸手，而傳統(tǒng)系統(tǒng)的迭代周期長對業(yè)務響應不及時。
為什么要微服務化
1.協(xié)作成本高注簿，業(yè)務響應慢?
傳統(tǒng)單體架構如果功能模塊100個以上一般的公司內部按照功能模塊進行劃分工作契吉，每一次新版本上線總會出現(xiàn)各種問題，例如分支合并沖突诡渴、代碼不一致捐晶、等各種問題也會帶來很大的協(xié)作成本，溝通成本妄辩。
2.系統(tǒng)復雜度增加難以維護
單體架構隨著業(yè)務量不斷的增加和擴展以及隨著組織人員的變化惑灵，業(yè)務代碼也會變得越來越難以維護，一次小小的改動可能會帶來災難行的風險眼耀！
3.錯誤不能隔離
當所有的業(yè)務功能模塊都聚集在一個程序集當中英支，如果其中的某一個小的功能模塊出現(xiàn)問題，那么都有可能會造成整個系統(tǒng)的崩潰
4.數(shù)據(jù)庫連接能力很難擴展
數(shù)據(jù)庫集群的連接數(shù)量是有限的哮伟，當數(shù)據(jù)庫的連接數(shù)量資源隨著實例的增加將難以保證
5.應用擴展能力差
單體架構不能夠按需擴展干花，例如某一天我們的網(wǎng)站當中部分業(yè)務模塊訪問量暴增，如果我們要對服務擴展只能把整個系統(tǒng)進行打包楞黄、發(fā)布而不能針對特定的模塊進行擴容
綜合上述煙囪式建設模式帶來的一些弊端接下來講到了soa方法池凄，SOA的主要特點有如下幾種：
面向服務的分布式計算
服務間松耦合
支持服務的組裝
服務注冊和自動發(fā)現(xiàn)
以服務契約方式定義服務交互方式
SOA架構帶來的真正核心意義價值：服務重用。
單體架構
所謂的單體架構就是把所有的業(yè)務模塊編寫在一個項目中鬼廓，最終會打包成一個war包肿仑，然后進行部署
單體架構的優(yōu)點：
部署簡單：由于是完整的結構體，可以直接部署在一份服務器上即可
技術單一：項目不需要復雜的技術棧碎税，往往一套熟悉的技術棧就可以完成開發(fā)
用人成本低：單個程序員可以完成業(yè)務接口道數(shù)據(jù)庫的整個流程
單體架構的缺點：
系統(tǒng)啟動慢：一個進程包含了所有的業(yè)務邏輯尤慰，涉及到的啟動模塊過多，導致系統(tǒng)的啟動時間周期過長
系統(tǒng)錯誤隔離性差：可用性差雷蹂，任何一個模塊的錯誤均可能造成整個系統(tǒng)的宕機
可伸縮性差：系統(tǒng)的擴容只能對這個應用進行擴容伟端，不能做到對莫謳歌功能點進行擴容
線上問題修復周期長：任何一個線上問題修復需要對整個應用系統(tǒng)全面升級
微服務系統(tǒng)架構：
微服務架構風格是一種將一個單一應用程序開發(fā)為一組小型服務的方法，每一個服務運行在自己的進程中萎河，服務間通信采用的輕量級通信機制（通常用Http資源API）荔泳，這些服務圍繞業(yè)務能力構建并且可通過全自動部署機制獨立部署，這些服務公用一個最小型的集中式的管理虐杯，服務可用不同的語言開發(fā)玛歌，使用不同的數(shù)據(jù)存儲技術
微服務架構的優(yōu)點：
易于開發(fā)和維護：一個微服務只會關注一個特定的業(yè)務功能，所以他的業(yè)務清晰擎椰，代碼量少支子，開發(fā)和維護單個微服務相當簡單，而整個應用是若干個微服務構建而成的达舒，所以整個應用也被維持在一個可控狀態(tài)
單個微服務啟動較快：單個微服務代碼量較少值朋，所以啟動會比較快
局部修改容易部署
技術棧不受限
按需收縮：可根據(jù)需求叹侄，實現(xiàn)細粒度的擴展，例如：系統(tǒng)中的某個微服務遇到了瓶頸昨登，可以結合這個微服務的業(yè)務特點趾代，增加內存，升級CPU或者增加節(jié)點
可以承受高并發(fā)
微服務架構的缺點：
運維要求較高：更多的服務意味著更多的運維投入丰辣，在單體架構中撒强，只需要保證一個應用的正常運行，而在微服務中笙什，需要保證幾十甚至幾百個服務正常運行與協(xié)作飘哨，這給運維帶來了很大的挑戰(zhàn)
分布式固有的復雜性：使用微服務構建的是分布式系統(tǒng)，對于一個分布式系統(tǒng)琐凭，系統(tǒng)容錯芽隆，網(wǎng)絡延遲等都會帶來巨大的挑戰(zhàn)
接口調整成本高：微服務之間通過接口進行通信，如果修改某一微服務API统屈，肯呢個所有使用該接口的微服務都需要調整
推薦閱讀
面試題
