進入IT行業6年，見證了整個系統架構的變遷，經歷了一輪又一輪架構浪潮。從最早的單體架構的一整個系統的雜亂無章，發展到多模塊的單體架構，再到SOA架構的分佈式解構系統，進而又更進一步進化到當今流行的微服務架構。每一種架構形態都不是萬能的，都有其優劣所在，以及其所適應的場景和團隊構成。
1. 單體架構
單體架構不是一無是處的，任何架構都有其優勢和劣勢。單體快速開發和驗證想法，證明產品思路是否可行，投入資源和成本，包括人力和物力相對比較節約。但是隨着時間的推移，業務複雜度的增加，單體架構會存在一些缺陷。
單體架構的缺陷：
（1）隨着業務的複雜度增加，單體的靈活度會逐漸下降。
（2）IDE過載：隨着代碼量增加，代碼整體編譯效率下降。
（3）規模化：無法滿足團隊規模化高效開發。
（4）系統開發、測試、部署的衝突和效率低下等問題
（5）只能關注一套技術棧
（6）應用擴展性比較差
（7）海量用戶高併發訪問數量有限
架構設計的三大原則：簡單，合適，演化。對於項目起步階段，單體是最高效也是最節省成本的方式。因爲初期階段，由於人力，成本，業務熟悉程度，微服務技術積累等因素，如何過度設計可能工期和複雜度會急劇上升，造成交付困難，問題百出，從而錯過了時間窗口。最合適，簡單的方式還是單體優先，這是創業公司的特點決定的。當然設計面向微服務的單體架構也是一種聰明的方法，這遵守了系統演化的法則。
無論採取何種維度的架構分層，分層的最核心目的是保證各層之間的差異足夠清晰，邊界足夠明顯，爲將來可能產生的變化提供最容易、最小化的修改。
如果前期在業務不十分清晰，求的是驗證想法，證明產品思路是否可行性，並且業務量不大，僅限於省級範圍，建議只要對當前架構稍加改良升級就可以了，這樣改動量相對較小。
總之一句話總結：新系統不適合採用微服務，來做細粒度的拆分，因爲業務不清，主次不明，反而可能造成系統混亂，更適合模塊化的單體應用來做第一步開發。
2. SOA架構
SOA 全稱是: Service Oriented Architecture，中文釋義爲 “面向服務的架構”它是一種設計理念，其中包含多個服務， 服務之間通過相互依賴最終提供一系列完整的功能。各個服務通常以獨立的形式部署運行，服務之間 通過網絡進行調用。
SOA的核心理念爲：松耦合帶來的服務重用，通過服務編排助力業務的快速響應和創新。
系統集成：站在系統的角度，解決企業系統間的通信問題，把原先散亂、無規劃的系統間的網狀結構，梳理成 規整、可治理的系統間星形結構，先散亂、無規劃的系統間的網狀結構，梳理成 規整、可治理的系統間星形結構，這一步往往需要引入一些產品，比如 ESB、以及技術規範、服務管理規範； 這一步解決的核心問題是有序。
系統的服務化：站在功能的角度，把業務邏輯抽象成可複用、可組裝的服務，通過服務的編排實現業務的快速再生，目的：把原先固有的業務功能轉變爲通用的業務服務，實現業務邏輯的快速複用；這一步解決的核心問題是複用。
業務的服務化：站在企業的角度，把企業職能抽象成 可複用、可組裝的服務；把原先職能化的企業架構轉變爲服務化的企業架構，進一步提升企業的對外服務能力；“前面兩步都是從技術層面來解決系統調用、系統功能複用的問題”。第三步，則是以業務驅動把一個業務單元封裝成一項服務。這一步解決的核心問題是高效。
SOA架構有如下優點：將重複的功能抽取爲服務，提高開發效率，提高系統的可重用性、可維護性。可以針對不同服務的特點制定集羣及優化方案。採用ESB減少系統中的接口耦合。
但也存在明顯的缺點：系統與服務的界限模糊，不利於開發及維護。雖然使用了ESB，但是服務的接口協議不固定，種類繁多，不利於系統維護。抽取的服務的粒度過大，系統與服務之間耦合性高。
3. 微服務架構
SOA的出現其實是爲了解決歷史問題：企業在信息化的過程中會有各種各樣互相隔離的系統，需要有一種機制將他們整合起來，所以纔會有上邊所述的ESB的出現。同樣的，也造成了SOA初期的服務是很大的概念，通常指定的一個可以獨立運作的系統（這樣看，好像服務間天然的松耦合）。這種做法相當於是「把子系統服務化」。
而微服務沒有歷史包袱，輕裝上陣，服務的尺寸通常不會太大，關於服務的尺寸，在實際情況中往往是一個服務應該能夠代表「實際業務場景中的一塊不可分割或不易分割的業務實體」。
微服務架構倡導將軟件應用設計成多個可獨立開發、可配置、可運行和可維護的子服務，子服務之間通過良好的接口定義通信機制，通常使用 RESTful 風格的 API 形式來通信 ，因爲RESTful 風格的 API 通常是在 HTTP 或者 HTTPS 通道上傳輸 JSON 格式的數據來實現的， HTTP協議有跨語言、跨異構系統的優點， 當然，也可以通過底層的進制協議、消息隊列協議等進行交互。這些服務不需要中心化的統一管理，每個服務的功能可自治，並且可以由不同的語言、系統和平臺實現。
微服務架構有如下優點：
（1）易於開發和維護：一個微服務只會關注一個特定的業務功能，所以業務清晰、代碼量較少。開發和維護單個微服務相對簡單。
（2）單個微服務啓動較快
（3）局部修改容易部署：單體應用只要有修改，就得重新部署整個應用。微服務解決了這樣的問題。一般來說，對某個微服務進行修改，只需要重新部署這個服務即可。
（4）技術棧不受限制：在微服務架構中，可以結合項目業務及團隊的特點，合理的選擇技術棧。
（5）按需伸縮：可根據需求，實現細粒度的擴展。
但是微服務架構也是存在明顯的缺點：
（1）運維要求高：更多的服務意味着要投入更多的運維。
（2）分佈式固有的複雜性：使用微服務構建的是分佈式系統。對於一個分佈式系統，系統容錯、網絡延遲、分佈式事務等都會帶來巨大的問題。
（3）接口調整成本高：微服務之間通過接口進行通信。如果修改某一個微服務的API，可能所有用到這個接口的微服務都需要進行調整。
總之，微服務架構場景設計方面，要儘可能避免產生分佈式事務，儘量按照BASE原則，採用最終一致性。小規模新項目，不建議採用微服務架構，拆得不好，反而會產生混亂。
4. 架構展望中臺化
合久必分，分久必合，由於微服務化，導致服務碎片化，調用鏈路複雜，服務之間依賴關係雜亂，從而很多大型企業將高內聚低耦合的平臺能力打包成中臺化的系統，供前臺系統調用。中臺化，最近在架構圈很火熱，但是也要看到中臺化，是在基礎能力都拆解到位，基礎後臺能力均具備的前提下，面向于敏捷化管理的一種後端平臺演變路徑。
中臺的出現，是爲了滿足前臺不斷變化的需求，以及後臺需要穩定和安全無法滿足需求的快速變化，從而抽取出來中臺層來匹配前臺業務的變化，提取出可服用的企業級能力包，來滿足前臺的不斷變化的業務需求。
中臺的落地不僅僅是軟件系統組織形態的變化，也需要企業組織形態變化相呼應，比如說原來每個業務系統都有自己的訂單中心，現在企業抽出來統一的訂單中心中臺系統，來支持各個業務的訂單業務，這也就意味着原來各個系統負責訂單子系統的人員的調整與劃轉。沒有企業人員組織架構的調整來配合，中臺化是沒有辦法很好落地的。