分布式體系結構
在分布式應用架構中，它們相互獨立，代碼獨立開發和部署，通過API接口相互通信。通信協議壹般使用HTTP，數據格式為JSON(壹種輕量級數據交換格式)，所以應用集成方式比較簡單。
優點:應用內部高內聚，獨立開發、測試和部署，應用之間松耦合，業務邊界清晰，業務依賴明確，支持大型項目並行開發。
缺點:API接口需求變化時，需要重新部署應用程序，通信可靠性和數據封裝相對進程內調用較差。
SOA架構[現在也稱為流程SAAS服務模型架構，也稱為雲架構]
SOA也是壹種分布式應用架構。
SOA架構提供支持服務治理，包括服務註冊、服務路由、服務授權、服務降級、服務監控等。
SOA架構不僅體現了業務的拆分，也體現了業務的整合，更多的是從整體業務考慮系統拆分。
優點:以服務層為主，專註核心業務，同時為整個系統提供* * *享受。作為壹個獨立的應用，服務獨立部署，接口清晰，易於做自動化測試和部署，服務無狀態，易於做橫向擴展；通過容器虛擬化技術，實現了故障隔離和資源的高效利用。
缺點:復雜的系統依賴給開發/測試/部署帶來不便，分布式數據壹致性和分布式事務支持困難，壹般通過最終壹致性簡化解決。
單片應用
系統只有壹個應用，打包成壹個應用；部署在機器上；將數據存儲在數據庫中。
單片應用采用分層架構，壹般包括表示層、業務層、數據訪問層和數據庫層。表示層負責用戶體驗，業務層負責業務邏輯，數據訪問層負責DB層的數據訪問。
優點:開發、編譯、調試壹條龍，壹個應用包含所有功能點，易於測試和部署。
缺點:隨著系統越來越大，代碼復雜度高，維護困難，應用擴展水平低，業務和模塊職責區分不清。
軟件體系結構
I .微服務架構
微服務架構是面向服務架構(簡稱SOA)的升級。
每個軍種都是獨立部署的單位。這些單元是分布式的，彼此解耦，通過遠程通信協議(比如REST和SOAP)連接。
微服務架構可以分為三種實現模式。
RESTful API模式:通過API提供服務，雲服務屬於這壹類。
RESTful應用模式:通過傳統的網絡協議或應用協議提供服務，通常後跟壹個多功能應用，這在企業中很常見。
集中式消息模式:消息代理可以實現消息排隊、負載均衡、統壹日誌和異常處理，但缺點是會出現單點故障，消息代理可能會集群化。
優勢
良好的可擴展性和服務間的低耦合性。
易於部署，軟件從單個可部署單元被分成多個服務，每個服務是壹個可部署單元。
易於開發，每個組件可以不斷集成開發，實時部署和不間斷升級。
易於測試，可以單獨測試每個服務。
劣勢
由於強調相互獨立性和低耦合性，服務可能會被細分得非常細。這就造成系統依賴大量的微服務，變得淩亂繁瑣，性能會很差。
壹旦服務需要通信(即壹個服務需要另壹個服務)，整個架構就會變得復雜。典型的例子是壹些常見的實用程序類。壹種解決方案是將它們復制到每個服務中，並交換冗余以簡化架構。
分布式的本質使得這種架構很難實現原子操作，事務回滾會更加困難。
第二，事件驅動架構
事件是軟件在狀態改變時發出的通知。
事件驅動架構是壹種通過事件進行通信的軟件架構。它分為四個部分。
事件隊列:接收事件的入口。
事件中介器:將不同的事件分發到不同的業務邏輯單元。
事件通道:分發服務器和處理器之間的通信通道。
事件處理器:實現業務邏輯，處理後發出壹個事件，觸發下壹個操作。
對於簡單的項目，可以將事件隊列、分發器和事件通道合二為壹，整個軟件分為事件代理和事件處理程序兩部分。
優勢
分布式異步架構，事件處理器之間高度解耦，軟件擴展性好；適用性廣，可用於各種類型的項目；性能好，由於事件的異步性，軟件不容易阻塞；事件處理程序可以獨立加載和卸載，並且易於部署。
劣勢
涉及異步編程(遠程通信、響應丟失等。)，開發相對復雜，難以支持原子操作，因為事件傳遞會涉及多個處理器，分布式、異步的特性很難回滾，這使得這種架構很難測試。
第三，分層架構。
分層架構是最常見的軟件架構，也是事實上的標準架構。如果不知道用什麽架構，就用吧。
這種架構將軟件分成幾個橫向層，每壹層都有明確的角色和分工，不需要知道其他層的細節。各層通過接口相互通信。
雖然沒有明確的協議規定軟件必須分為多少層，但四層結構是最常見的。
呈現:用戶界面，負責視覺和用戶交互。
業務層:實現業務邏輯。
持久層:提供數據，SQL語句放在這壹層。
數據庫:保存數據。
壹些軟件在邏輯層和持久層之間增加了壹個服務層，為不同的業務邏輯需求提供壹些通用接口。
用戶的請求會依次通過這四層進行處理，任何壹層都不能跳過。
優勢
1，結構簡單，易於理解和開發。
2.不同技能的程序員可以分工負責不同的層，這自然適合大多數軟件公司的組織結構。
3.每壹層都可以獨立測試，其他層的接口通過仿真解決。
劣勢
1.壹旦環境發生變化，調整代碼或添加功能通常會很麻煩，也很耗時。
2、部署麻煩，即使只修改了很小的地方，也往往需要重新部署整個軟件，不容易進行連續發布。
當軟件升級時，整個服務可能需要暫停。
3.擴展性差。當用戶請求數量大大增加時，必須依次擴展每壹層。因為每壹層都是內部耦合的，所以會很難擴展。
五、微核構築。
微內核架構(Microkernel architecture)又稱“插件架構”，是指軟件的內核相對較小，主要功能和業務邏輯都是由插件實現的。
核心通常只包含系統的最小功能。插件之間是相互獨立的，插件之間的通信應該減少到最低限度，以避免相互依賴的問題。
優勢
1，擴展性好，需要什麽功能，開發個插件就行。
2.這些功能是隔離的，插件可以獨立加載和卸載，這使得部署更加容易。
3、高度定制化，適應不同開發需求。
4、可以逐步開發，逐步增加功能。
劣勢
1，擴展性差，內核通常是壹個獨立的單元，不容易做成分布式。
2.開發難度相對較大，因為涉及到插件與內核的通信以及內部插件註冊機制。
動詞 （verb的縮寫）雲架構。
雲架構主要解決可擴展性和並發性問題，是最容易擴展的架構。
其可擴展性高的主要原因是不使用中央數據庫，而是將所有數據復制到內存中，成為可復制的內存數據單元。然後，將業務處理能力封裝到處理單元中。當訪問次數增加時，將建立新的處理單元；當訪問次數減少時，處理單元關閉。因為沒有了中心數據庫，擴展性的最大瓶頸消失了。因為每個處理單元的數據都在內存中，所以最好將數據持久化。
該模型主要分為兩部分:處理單元和虛擬化中間件。
處理單元:實現業務邏輯
虛擬中間件:負責通信、維護會話、數據復制、分布式處理和處理單元的部署。