我一直在講架構，這個詞聽起來是挺高大上，各大公司的線下CTO演講也經常會提到這一點，可架構其實很多，涉及到的概念也很複雜，光是經典的架構就有20多種。
軟件架構就是軟件的基本結構。架構的本質是管理複雜性。如果你覺得架構不重要，可能是你做的事情不夠複雜，或者是你沒有管理好複雜性。架構模式雖多，但常用的也就那麼幾種：
1.分層架構
2.事件驅動架構
3.微核架構（又稱插件架構）
4.微服務架構
5.雲架構
一、分層架構
分層架構（layered architecture）是最常見的軟件架構，也是事實上的軟件標準架構。如果你不知道要用什麼架構，那就用它。有人說軟件職業生涯中只用到了一種架構，那一定也是它。當前很多產品的頂層架構，幾乎無一例外的也是分層架構。
分層架構將軟件分成若干個水平層，每一層都有清晰的角色和分工，不需要知道其他層的細節。層與層之間通過接口通信。雖然沒有明確約定軟件一定要分成多少層，但是最常見的是四層結構。
- 表現層（presentation）：用戶界面，負責視覺和用戶互動
- 業務層（business）：實現業務邏輯
- 持久層（persistence）：提供數據，SQL 語句就放在這一層
- 數據庫（database） ：保存數據
有的軟件在邏輯層和持久層之間，加了一個服務層（service），提供不同業務邏輯需要的一些通用接口。用戶的請求將依次通過這四層的處理，不能跳過其中任何一層。
分層架構的優點：
1、結構簡單，容易理解和開發；
2、不同技能的程序員可以分工，負責不同的層，天然適合大多數軟件公司的組織架構。雖說架構決定組織，但實際上架3、構往往都是服從於組織；
3、每一層都可以獨立測試，其他層的接口通過模擬解決。
分層架構的缺點：
1、 一旦環境變化，需要代碼調整或增加功能時，通常比較費時費力；
2、部署比較麻煩，即使只修改一個小地方，往往需要整個軟件重新部署，不容易做持續發佈；
3、軟件升級時，可能需要整個服務暫停；
4、擴展性差。用戶請求大量增加時，必須依次擴展每一層，由於每一層內部是耦合的，擴展會很困難。
二、事件驅動架構
所謂事件（Event），是狀態發生變化時，軟件發出的通知，觸發相關的操作。事件驅動架構（event-driven architecture）就是通過事件進行通信的軟件架構。它分成四個部分：
- 事件隊列（event queue）：接收事件的入口
- 分發器（event mediator）： 將不同的事件分發到不同的業務邏輯單元
- 事件通道（event channel）：分發器與處理器之間的聯繫渠道
- 事件處理器（event processor）：實現業務邏輯，處理完成後會發出事件，觸發下一步操作
對於簡單的項目，事件隊列、分發器和事件通道，可以合為一體，整個軟件就分成事件代理和事件處理器兩部分。
事件驅動架構的優點：
1、分佈式的異步架構，事件處理器之間高度解耦，軟件的擴展性好；
2、適用性廣，各種類型的項目都可以用；
3、性能較好，因為事件的異步本質，軟件不易產生堵塞；
4、事件處理器可以獨立地加載和卸載，容易部署。
事件驅動架構的缺點：
1、涉及異步編程（要考慮遠程通信、失去響應等情況），開發相對複雜；
2、難以支持原子性操作，因為事件通過會涉及多個處理器，很難回滾；
3、分佈式和異步特性導致這個架構較難測試。
事件驅動架構在通信產品中應用得也非常廣泛，典型的如狀態機處理。事件驅動架構不適於做頂層架構，但適合做局部實現，幾乎遍佈在通信軟件的各個角落。
三、微核架構
微核架構（microkernel architecture）又稱為"插件架構"（plug-in architecture），指的是軟件的內核（core）做得相對較小，主要功能和業務邏輯都通過插件實現。
內核通常只包含系統運行的最小功能，插件則是互相獨立的業務功能。插件之間的通信，應該減少到最低，避免出現互相依賴的問題。
微核架構的優點：
1、良好的功能延伸性（extensibility），需要什麼功能，開發一個插件即可；
2、功能之間是隔離的，插件可以獨立的加載和卸載，使得它比較容易部署；
3、可定製性高，適應不同的開發需要；
4、可以漸進式地開發，逐步增加功能。
微核架構的缺點：
1、擴展性（scalability）差，內核通常是一個獨立單元，不容易做成分佈式；
2、開發難度相對較高，因為涉及到插件與內核的通信，以及內部的插件登記機制。
微核架構的設計和開發難度較高，這就註定它在企業產品中用得不多，雖然它的優點還不少。
四、微服務架構
微服務架構（microservices architecture）是面向服務架構（service-oriented architecture，縮寫 SOA）的升級。每一個服務就是一個獨立的部署單元（separately deployed unit）。這些單元都是分佈式的，互相解耦，通過遠程通信協議（比如REST、SOAP）聯繫。
微服務架構分成三種實現模式：
- RESTful API 模式：服務通過 API 提供，雲服務就屬於這一類；
- RESTful應用模式：服務通過傳統的網絡協議或者應用協議提供，背後通常是一個多功能的應用程序，常見於企業內部；
- 集中消息模式：採用消息代理（message broker），可以實現消息隊列、負載均衡、統一日誌和異常處理，缺點是會出現單點失敗，消息代理可能要做成集群。
微服務架構的優點：
1、展性好，各個服務之間低耦合；
2、容易部署，軟件從單一可部署單元，被拆成了多個服務，每個服務都是可部署單元；
3、容易開發，每個組件都可以進行持續集成式的開發，可以做到實時部署，不間斷地升級；
4、易於測試，可以單獨測試每一個服務。
微服務架構的缺點：
1、由於強調互相獨立和低耦合，服務可能會拆分得很細。這導致系統依賴大量的微服務，變得很凌亂和笨重，性能也會不佳；
2、一旦服務之間需要通信（即一個服務要用到另一個服務），整個架構就會變得複雜。典型的例子就是一些通用的 Utility 類，一種解決方案是把它們拷貝到每一個服務中去，用冗餘換取架構的簡單性；
3、分佈式的本質使得這種架構很難實現原子性操作，交易回滾會比較困難。
微服務架構易開發、易測試、易部署，解耦，擴展性好，所以它成為當今的網紅也絕非偶然。但服務變多變細，勢必帶來新的管理複雜性。好在當前工具工程能力的強大，管理複雜性在一定程度上可以通過自動化來解決。儘快如此，服務的劃分仍然很重要，不要通過後端的自動化來掩蓋前端的不足。
五、雲架構
雲架構（cloud architecture）主要解決擴展性和併發的問題，是最容易擴展的架構。雲化軟件架構的核心是數據庫去中心化，數據變成可複製的內存數據單元。業務處理能力封裝成一個個處理單元。業務流程和數據分離，業務狀態外置，處理單元水平擴展。訪問量增加，就新建處理單元；訪問量減少，就關閉處理單元。由於沒有中央數據庫，所以擴展性的最大瓶頸消失了。由於每個處理單元的數據都在內存裡，最好要進行數據持久化。雲化架構對於雲上應用的可靠性、高擴展和高併發至關重要。
這個模式主要分成兩部分：處理單元（processing unit）和虛擬中間件（virtualized middleware）。
處理單元：實現業務邏輯；
虛擬中間件：負責通信、保持sessions、數據複製、分佈式處理、處理單元的部署。
虛擬中間件又包含四個組件：
- 消息中間件（Messaging Grid）：管理用戶請求和session，當一個請求進來以後，決定分配給哪一個處理單元；
- 數據中間件（Data Grid）：將數據複製到每一個處理單元，即數據同步。保證某個處理單元都得到同樣的數據；
- 處理中間件（Processing Grid）：可選，如果一個請求涉及不同類型的處理單元，該中間件負責協調處理單元；
- 部署中間件（Deployment Manager）：負責處理單元的啟動和關閉，監控負載和響應時間，當負載增加，就新啟動處理單元，負載減少，就關閉處理單
雲架構的優點：
1、高負載，高擴展；
2、動態部署。
雲架構的缺點：
1、實現複雜，成本較高；
2、主要適合網站類應用，不合適大量數據吞吐的大型數據庫應用；
3、較難測試。
以上是從技術本質，對架構進行分類。實際應用中，各種架構並不是孤立的，可以根據業務環境和業務訴求，對各種架構進行綜合和嫁接。曾對微服務架構和微核架構進行綜合，總結出微插件架構，適合於在資源受限的場景應用微服務的架構。另外，就如上面列舉，每種架構都有其優點和缺點。優點不必多說，缺點則幾乎都是通過工具工程能力的方法來規避，工具工程對軟件架構非常重要。
閱讀更多 IT技術管理那些事兒 的文章
