架構的規劃誰
架構就是對系統中的實體以及實體之間的關系所進行的抽象描述，是決策。
系統架構是結構和規劃，是對物/信息的功能與形式元素之間的對應情況所做的分配，是對元素之間的關系以及元素同周邊環境之間的關系所做的定義。
- 架設計構是個復雜的任務，也是個很大的話題，有了架構之后，就需要讓干系人理解、遵循相關決策。
架構圖的設計
系統架構圖是為了抽象地表示軟件系統的整體輪廓和各個組件之間的相互關系和約束邊界，以及軟件系統的物理部署和軟件系統的演進方向的整體視圖
架構類型
單體架構、分布式架構、SOA架構、微服務架構、微內核架構和事件驅動架構、無服務架構。
分布式架構
分布式應用架構中，相互獨立，代碼獨立開發，獨立部署，通過API接口互相通信。通訊協議一般使用HTTP/RPC，數據格式是JSON(是一種輕量級的數據交換格式)，應用集成方式比較簡化。
優點: 應用內部高內聚，獨立開發、測試和部署，應用之間松耦合，業務邊界清晰，業務依賴明確，支持大項目并行開發。
- 缺點: API接口需求變化，應用就需要重新部署，通信可靠性和數據的封裝性相對于進程內調用比較差。
SOA架構
SOA也是分布式應用架構一種。
SOA架構提供配套的服務治理，包括服務注冊、服務路由、服務授權、服務降級、服務監控等等。
SOA架構既體現業務的拆分，又體現業務的整合，更多地從業務整體上考慮系統拆分。
優點：以服務層為主，聚焦核心業務，同時以提供整個系統共享，服務作為獨立的應用，獨立部署，接口清晰，很容易做自動化測試和部署，服務是無狀態的，很容易做水平擴展；通過容器虛擬化技術，實現故障隔離和資源高效利用。
- 缺點：系統依賴復雜，給開發/測試/部署帶來不便，分布式數據一致性和分布式事務支持困難，一般通過最終一致性簡化解決。
單體式應用
系統只有一個應用、打包成一個應用；部署在一臺機器；在一個DB里存儲數據，單體式應用采用分層架構，一般為表示層、業務層、數據訪問層、DB層，表示層負責用戶體驗，業務層負責業務邏輯，數據訪問層負責DB層的數據存取
優點：開發、編譯、調試一站式、一個應用程序包含所有功能點，容易測試和部署
- 缺點：系統逐漸龐大時，代碼復雜度高，難以維護，應用擴展水平低，業務和模塊職責區分不清晰。
微服務架構
微服務架構（microservices architecture）是服務導向架構（service-oriented architecture，縮寫 SOA）的升級。
- 每一個服務就是一個獨立的部署單元（separately deployed unit）。這些單元都是分布式的，互相解耦，通過遠程通信協議（比如REST、SOAP）聯系。
微服務架構分成三種實現模式。
RESTful API 模式：服務通過 API 提供，云服務就屬于這一類
RESTful 應用模式：服務通過傳統的網絡協議或者應用協議提供，背后通常是一個多功能的應用程序，常見于企業內部
集中消息模式：采用消息代理（message broker），可以實現消息隊列、負載均衡、統一日志和異常處理。缺點：是會出現單點失敗，消息代理可能要做成集群。
優點：擴展性好，各個服務之間低耦合
容易部署，軟件從單一可部署單元，被拆成了多個服務，每個服務都是可部署單元
容易開發，每個組件都可以進行持續集成式的開發，可以做到實時部署，不間斷地升級
- 易于測試，可以多帶帶測試每一個服務
缺點
由于強調互相獨立和低耦合，服務可能會拆分得很細。這導致系統依賴大量的微服務，變得很凌亂和笨重，性能也會不佳。
一旦服務之間需要通信（即一個服務要用到另一個服務），整個架構就會變得復雜。典型的例子就是一些通用的 Utility 類，一種解決方案是把它們拷貝到每一個服務中去，用冗余換取架構的簡單性。
- 分布式的本質使得這種架構很難實現原子性操作，交易回滾會比較困難。
事件驅動架構
事件（event）是狀態發生變化時，軟件發出的通知。
- 事件驅動架構（event-driven architecture）就是通過事件進行通信的軟件架構。
事件驅動架構的四個部分
事件隊列（event queue）：接收事件的入口。
分發器（event mediator）：將不同的事件分發到不同的業務邏輯單元。
事件通道（event channel）：分發器與處理器之間的聯系渠道。
- 事件處理器（event processor）：實現業務邏輯，處理完成后會發出事件，觸發下一步操作
對于簡單的項目，事件隊列、分發器和事件通道，可以合為一體，整個軟件就分成事件代理和事件處理器兩部分。
事件驅動架構的優缺點
優點
分布式的異步架構，事件處理器之間高度解耦，軟件的擴展性好；適用性廣，各種類型的項目都可以用；性能較好，因為事件的異步本質，軟件不易產生堵塞；事件處理器可以獨立地加載和卸載，容易部署
缺點
涉及異步編程（要考慮遠程通信、失去響應等情況），開發相對復雜難以支持原子性操作，因為事件通過會涉及多個處理器，很難回滾分布式和異步特性導致這個架構較難測試。
分層架構
分層架構（layered architecture）是最常見的軟件架構，也是事實上的標準架構。如果你不知道要用什么架構，那就用它。
這種架構將軟件分成若干個水平層，每一層都有清晰的角色和分工，不需要知道其他層的細節。層與層之間通過接口通信。
雖然沒有明確約定，軟件一定要分成多少層，但是四層的結構最常見。
表現層（presentation）：用戶界面，負責視覺和用戶互動。
業務層（business）：實現業務邏輯。
持久層（persistence）：提供數據，SQL 語句就放在這一層。
- 數據庫（database） ：保存數據。
有的軟件在邏輯層和持久層之間，加了一個服務層（service），提供不同業務邏輯需要的一些通用接口。
用戶的請求將依次通過這四層的處理，不能跳過其中任何一層。
分層架構
優點
結構簡單，容易理解和開發。
不同技能的程序員可以分工，負責不同的層，天然適合大多數軟件公司的組織架構
- 每一層都可以獨立測試，其他層的接口通過模擬解決
缺點
一旦環境變化，需要代碼調整或增加功能時，通常比較麻煩和費時
部署比較麻煩，即使只修改一個小地方，往往需要整個軟件重新部署，不容易做持續發布，軟件升級時，可能需要整個服務暫停
- 擴展性差。用戶請求大量增加時，必須依次擴展每一層，由于每一層內部是耦合的，擴展會很困難。
微核架構。
微核架構（microkernel architecture）又稱為"插件架構"（plug-in architecture），指的是軟件的內核相對較小，主要功能和業務邏輯都通過插件實現。
內核（core）通常只包含系統運行的最小功能。插件則是互相獨立的，插件之間的通信，應該減少到最低，避免出現互相依賴的問題。
優點
良好的功能延伸性（extensibility），需要什么功能，開發一個插件即可
功能之間是隔離的，插件可以獨立的加載和卸載，使得它比較容易部署，
可定制性高，適應不同的開發需要
- 可以漸進式地開發，逐步增加功能
缺點
擴展性（scalability）差，內核通常是一個獨立單元，不容易做成分布式
- 開發難度相對較高，因為涉及到插件與內核的通信，以及內部的插件登記機制。
云架構。
云結構（cloud architecture）主要解決擴展性和并發的問題，是最容易擴展的架構。
它的高擴展性，主要原因是沒使用中央數據庫，而是把數據都復制到內存中，變成可復制的內存數據單元。然后，業務處理能力封裝成一個個處理單元（prcessing unit）。訪問量增加，就新建處理單元；訪問量減少，就關閉處理單元。由于沒有中央數據庫，所以擴展性的最大瓶頸消失了。由于每個處理單元的數據都在內存里，最好要進行數據持久化。
這個模式主要分成兩部分：處理單元（processing unit）和虛擬中間件（virtualized middleware）。
處理單元：實現業務邏輯
虛擬中間件：負責通信、保持sessions、數據復制、分布式處理、處理單元的部署。
