低調的牛肉
軟件產品的架構，通常都是隨著業務的發展而不斷演變的；我從事軟件開發行業也有十餘年了，遇到過的軟件（企業級應用，我是從事Java開發）架構主要有這麼幾種：
單體架構架構
總的概括來說，單體架構就是應用所有的功能，只有一個代碼包，開發和部署都在一起，這是一種比較傳統的架構風格；當然，單體架構也有著諸多的缺點：
代碼越來越多，增加了代碼的複雜性；作為開發人員一定深有感觸，每當修改一個老方法的時候，一定會格外的小心翼翼，生怕影響了其他的功能；
單體應用需要統一技術棧，團隊中的開發人員，都需要掌握相同的開發語言和框架；
隨著開發人員的流動，老員工離開項目組，複雜且龐大的項目代碼又讓新成員難以閱讀和理解，技術債務越積越多；
代碼都在一個代碼包中，就算是修改一個小小的功能，都要把整個項目打包上線；
所有的模塊都運行在同一個JVM中，非關鍵性業務可能佔用大量的資源，導致關鍵性業務發生問題；不能單獨對某一個模塊進行擴展。
SOA架構
因為單體應用架構的種種缺點，已經不能再滿足業務需求的時候，於是就出現了SOA架構。
SOA架構的主要思想是把應用程序的模塊化組件，通過接口聯繫起來（接口可以獨立於語言、框架、硬件、操作系統）；在SOA架構中，有兩個主流實現方式：
Web Service：使用WSDL定義接口，SOAP協議通信，傳輸XML數據；缺點是SOAP、XML較重；服務管理不完善；
ESB：企業服務總線，每個服務提供者通過總線模式插入系統，總線完成服務的編排和轉發；但ESB本身就比較中，而且它本身算是一個單點，在軟件架構中，單點意味著風險；
微服務架構
微服務的產生，也是由於SOA架構的一些缺點，這裡再次印證了這句話，【應用架構的演進的過程通常是被業務逼出來的】。
在微服務的架構中，服務拆分粒度更細，提高了複用性；各個微服務可以獨立開發，獨立部署；
微服務之間通常使用Restful風格的API通信，傳輸格式也通常選擇JSON；
微服務是SOA架構的延續，它們和單體應用相比，大大提高了系統的負載能力，解決了應用高併發的需求；
服務和服務之間的耦合度也被降低，並且項目團隊可以被拆分成多個小團隊，每個微服務都可以進行敏捷開發部署；
每個團隊的技術棧也可以不相同，只要遵守接口協議即可。
當然SOA、微服務的出現，在解決一些問題的時候，也帶來了另外一部分的問題，比如增加了網絡開銷、服務依賴性、增加了測試運維難度、數據一致性問題等等。
我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。
