合適的體系結構是軟件成功的最重要因素之壹。大型軟件公司通常有專門的架構師職位，只能由有經驗的程序員擔任。
O'Reilly出版了壹本免費的小冊子《軟件架構模式》(PDF)，介紹了五種最常見的軟件架構，是壹本非常好的入門讀物。
軟件架構是軟件的基本結構。架構的本質是管理的復雜性。如果妳覺得架構不重要，可能是妳做的不夠復雜，或者是妳沒有很好的管理復雜性。建築圖案雖然很多，但是經過抽象沈澱，只有這麽幾種:
1.分層架構(更傳統的單壹架構)
2.事件驅動架構(壹般適用於本地應用場景實現異步解耦)
3.微內核架構(也稱插件架構，開發難度較大，壹般用於工具軟件開發，如Eclipse，不適合分布式業務場景)。
4.微服務架構(目前流行的壹種服務架構，解決了單壹架構面臨的問題，適合敏捷開發和快速叠代)
5.雲架構(-雲原生架構，基於Docker、Kubernetes和服務網格)。
在原文的基礎上，我根據自己的想法做了壹點小調整。
分層架構是最常見的軟件架構，也是事實上的標準架構。如果不知道用什麽架構，就用吧。
這種架構將軟件分成幾個橫向層，每壹層都有明確的角色和分工，不需要知道其他層的細節。各層通過接口相互通信。
雖然沒有明確的協議規定軟件必須分為多少層，但四層結構是最常見的。
有些軟件在邏輯層(業務)和持久層之間增加了壹個服務層，為不同的業務邏輯需求提供壹些通用的接口。
用戶的請求會依次通過這四層進行處理，任何壹層都不能跳過。
優勢
劣勢
事件是軟件在狀態改變時發出的通知。
事件驅動架構是壹種通過事件進行通信的軟件架構。它分為四個部分。
事件驅動架構核心組件:
對於簡單的項目，可以將事件隊列、分發器和事件通道合二為壹，整個軟件分為事件代理和事件處理程序兩部分。
優勢
劣勢
事件驅動架構也廣泛應用於通信產品，如狀態機處理。事件驅動架構不適合頂層架構，但適合本地實現，在通信軟件中幾乎無處不在。
微內核架構(Microkernel architecture)又稱“插件架構”，是指軟件的內核相對較小，主要功能和業務邏輯都是由插件實現的。
核心通常只包含系統的最小功能。插件之間是相互獨立的，插件之間的通信應該減少到最低限度，以避免相互依賴的問題。
優勢
劣勢
微內核架構很難設計和開發，這意味著它在企業產品中的應用並不廣泛，盡管它有很多優點。
微服務架構是面向服務架構(簡稱SOA)的升級。
每個軍種都是獨立部署的單位。這些單元是分布式的，彼此解耦，通過遠程通信協議(比如REST和SOAP)連接。
微服務架構可以分為三種實現模式。
目前有很多開源的微服務框架，比如Spring Cloud，Dubbo，ServiceComb等等。
優勢
劣勢
雲架構(現在叫-Cloud Native)主要解決可擴展性和並發性的問題，是最容易擴展的架構。
其高可擴展性主要得益於其基於雲上計算資源的靈活可擴展性。然後，將業務處理能力封裝到處理單元中。當訪問次數增加時，會新建壹個處理單元(Docker容器)；當訪問次數減少時，處理單元(Docker容器)被關閉。因為沒有了中心數據庫，擴展性的最大瓶頸消失了。因為每個處理單元的數據都是獨立分庫的。
該模型主要分為兩部分:處理單元和虛擬化中間件。
虛擬中間件由四個組件組成:
隨著Docker、Kubernetes等容器化技術的快速發展，上面對雲架構的描述已經有點過時了。目前最新的雲原生架構以Docker+Kubernetes為核心，尤其是容器排列Kubernetes已經成為事實上的行業標準。
雲原生架構圖的主要特性:
主要目標:
1.讓開發者專註於業務邏輯的實現，剩下的交給容器雲平臺；
2.支持業務系統的快速叠代和業務的快速變化與發展；
3.建設以* * *服務體系為核心的商務中心；
下面是我為壹家新零售企業設計的雲原生架構示意圖，基於雲和微服務架構構建雲原生應用，其中雲可以是公有雲、私有雲、混合雲等等。
以上是從不同角度對建築的分類。在實際應用中，各種架構並不是孤立的，可以根據業務環境和業務需求進行整合和嫁接。每種架構都有其優點和缺點。優點和缺點不用多說，幾乎都是借助工具工程(比如自動發布工具，自動測試等)來避免的。)，這對軟件架構非常重要。