軟體架構（software architecture）就是軟體的基本結構。

合適的架構是軟體成功的最重要因素之一。大型軟體公司通常有專門的架構師職位（architect），只有資深程式設計師（現在流行全棧工程師和Devops架構師）才可以擔任。

百科釋義：架構 https://baike.baidu.com/item/%E6%9E%B6%E6%9E%84/13004195

架構可細分為業務架構、應用架構和技術架構。業務架構是戰略，應用架構是戰術，技術架構是裝備。

業務架構,功能架構,系統架構,技術架構，應用架構都是什麼關係？

首先講的是“業務架構,功能架構,系統架構,技術架構，應用架構”裡面是有重疊的，其中功能架構 可以是業務架構部分、也可以是應用架構部分，系統架構和技術架構是重疊的，可以把這兩個名稱叫一個名稱就行。我的個人理解是：

 業務（邏輯）架構：使用一套方法論對產品（專案）所涉及到的需求的業務進行業務邊界劃分，簡單的講就是根據一套邏輯思路進行業務的拆分，總體原則是對業務進行業務邊界的劃分，比如做一個企業訂購服務網站，你需要把商品類目、商品、訂單、訂單服務、支付、退款很清晰的劃分出來，而業務架構不需要考慮諸如我用什麼技術開發、我的併發大怎麼辦、我選擇什麼樣的硬體等等。 

應用架構：應用是介於業務語言與技術語言之間，是對整個系統實現的總體上的架構，他需要指出系統的層次、系統開發的原則、系統各個層次的應用服務，例如，上述系統中可以分為、資料層（資源層）、資料服務層、中間構建服務層、業務邏輯層、表現層，並寫明每個層次應用服務。 

資料（持久化）架構：對儲存資料（資源）的架構方法論，其架構原則同應用架構大同小異，即考慮到各個系統應用場景、不同時間段的應用場景對資料進行諸如資料異構、讀寫分離、資料庫或NOSQL的策略、快取的使用、分散式資料（資料庫）策略等等。 

技術架構：我的理解是對上述架構中提出的功能（或服務）進行技術方案的實現。包括軟體系統實現、作業系統選擇、執行時設計。技術架構設計面較廣，專業性較強。

 應用架構型別：單體式、分散式、SOA架構

應用架構

    分有兩種方式，

      一種是水平分，從功能型別劃分，比如把系統分為web前端/中間服務/後臺任務，這是面向業務深度的劃分。

      一種是垂直分，以業務型別劃分，比如ERP系統可以劃分為三個獨立的應用，這是面向業務廣度的劃分

     各個應用之間相互協作，主要體現在應用之間的相互通訊機制和資料格式，通訊機制可以同步、非同步訊息、共享訪問等，資料格式是以文字、XML、JSON、二進位制等。

單體式應用

    系統只有一個應用、打包成一個應用；部署在一臺機器；在一個DB裡儲存資料.

    優點：開發、編譯、除錯一站式、一個應用程式包含所有功能點，容易測試和部署

     缺點：系統逐漸龐大時，程式碼複雜度高，難以維護，應用擴充套件水平低，業務和模組職責區分不清晰。

分散式架構

    優點: 應用內部高內聚，獨立開發、測試和部署，應用之間鬆耦合，業務邊界清晰，業務依賴明確，支援大專案並行開發。

    缺點: API介面需求變化，應用就需要重新部署，通訊可靠性和資料的封裝性相對於程式內呼叫比較差。

SOA架構[現在也流程SAAS服務模式架構也稱雲架構]

      SOA架構提供配套的服務治理，包括服務註冊、服務路由、服務授權、服務降級、服務監控等等，

       SOA架構既體現業務的分，又體現業務的合，更多地從業務整體上考慮系統拆分

      優點：以服務層為主，聚焦核心業務，同時以提供整個系統共享，服務作為獨立的應用，獨立部署，介面清晰，很容易做自動化測試和部署，服務是無狀態的，很容易做水平擴充套件；通過容器虛擬化技術，實現故障隔離和資源高效利用。

      缺點：系統依賴複雜，給開發/測試/部署帶來不便，分散式資料一致性和分散式事務支援困難，一般通過最終一致性簡化解決

緣起

一直以來，在軟體行業，對於什麼是架構，都有很多的爭論，每個人都有自己的理解。甚至於很多架構師一說架構，就開始談論什麼應用架構、硬體架構、資料架構等等。我曾經也到處尋找過架構的定義，請教過很多人，結果發現，沒有大家都認可的定義。套用一句關於big data流行的笑話，放在架構上也適用：

Architecture is like teenage sex，everybody talks about it，nobody really knows what is it。

事實上，架構在軟體發明時的N多年以前，就已經存在了，這個詞最早是跟隨著建築出現的。所以，我覺得有必要從源頭開始，把架構這個概念先討論清楚，只有這樣，軟體行業架構的討論才有意義。

什麼是架構？

架構的英文是Architecture，在Wikipedia上，架構是這樣定義的：

Architecture (Latin architectura, from the Greek ἀρχιτέκτων arkhitekton"architect", from ἀρχι- "chief" and τέκτων "builder") is both the process and the product of planning, designing, and constructing buildings and other physical structures。

從這個定義上看，架構好像是一個過程，也不是很清晰。為了講清楚這個問題，我們先來看看為什麼會產生架構。

為什麼會產生架構？

想象一下，在最早期，每個人都完全獨立生活，衣、食、住、行等等全部都自己搞定，整個人類都是獨立的個體，不相往來。為了解決人類的延續的問題，自然而然就有男女群居出現，這個時候就出現了分工了，男性和女性所做的事情就會有一定的分工，可是人每天生活的基本需求沒有發生變化，還是衣食住行等生活必須品。

但是一旦多人分工配合作為生存的整體，力量就顯得強大多了，所以也自然的形成了族群：有些人種田厲害，有些人制作工具厲害，有些地方適合產出糧食，有些地方適合產出棉花等，就自然形成了人的分群，地域的分群。當分工發生後，實際上每個人的生產力都得到了提高，因為做的都是每個人擅長的事情。

整個人群的生產力和抵抗環境的能力都得到了增強。為什麼呢？因為每個人的能力和時間都是有限的，並且因為人的結構的限制，人同時只能專心做好一件事情，這樣不得已就導致了分工的產生。既然分工發生了，原來由一個人幹生存所必需的所有的事情，就變成了很多不同分工的角色合作完成這些事情，這些人必須要通過某些機制合在一起，讓每個人完成生存所必需的事情，這實際上也導致了交易的發生（交易這部分就不在這裡展開了，有機會再討論）。

在每個人都必須自己完成所有生活必須品的生產的時候，是沒有架構的（當然在個人來講，同一時刻只能做有限的事情，在時間上還是可能會產生架構的）。一旦產生的分工，就把所有的事情，切分成由不同角色的人來完成，最後再通過交易，使得每個個體都擁有生活必須品，而不需要每個個體做所有的事情，只需要每個個體做好自己擅長的事情，並具備一定的交易能力即可。

這實際上就形成了社會的架構。那麼怎麼定義架構呢？以上面這個例子為例，把一個整體（完成人類生存的所有工作）切分成不同的部分（分工），由不同角色來完成這些分工，並通過建立不同部分相互溝通的機制，使得這些部分能夠有機的結合為一個整體，並完成這個整體所需要的所有活動，這就是架構。由以上的例子，也可以歸納出架構產生的動力：

1. 必須由人執行的工作（不需要人介入，就意味著不需要改造，也就不需要架構了）

2. 每個人的能力有限（每個人都有自己的強項，個人的產出受限於最短板，並且由於人的結構限制，同時只能專注於做好一件事情，比如雖然有兩隻眼睛，但是隻能同時專注於一件事物，有兩隻手，無法同時做不同的事情。ps. 雖然有少部分人可以左手畫圓右手畫框，但是不是普遍現象）

3. 每個人的時間有限（為了減少時間的投入，必然會導致把工作分解出去，給擅長於這些工作的角色來完成，見2，從而縮短時間）

4. 人對目標系統有更高的要求（如果滿足於現狀，也就不需要進行架構了）

5. 目標系統的複雜性使得單個人完成這個系統，滿足條件2，3（如果個人就可以完成系統的提高，也不需要別的人參與，也就不需要架構的涉及，只是工匠，並且一般這個工作對時間的要求也不迫切。當足夠熟練之後，也會有一定的架構思考，但考慮更多的是如何提高質量，提高個人的時間效率）

有人可能會挑戰說，如果一個人對目標系統進行分解，比如某人建一棟房子，自己採購材料，自己搭建，難道也不算架構嘛？如果對於時間不敏感的話，是會出現這個情況的，但是在這種情況下，並不必然導致架構的發生。如果有足夠的自覺，以及足夠的熟練的話，也會產生架構的思考，因為這樣對於提高生產力是有幫助的，可以縮短建造的時間，並會提高房子的質量。事實上建築的架構就是在長期進行這些活動後，積累下來的實踐。

當這5個條件同時成立，一定會產生架構。從這個層面上來說，架構是人類發展過程中，由懵懵懂懂的，被動的去認識這個世界，變成主動的去認識，並以更高的效率去改造這個世界的方法。以下我們再拿建築來舉例加強一下理解。

最開始人類是住在山洞裡，住在樹上的，主要是為了躲避其他猛獸的攻擊，以及減少自然環境的變化，對人類生存的挑戰。為了完成這些目標，人類開始學會在平地上用樹木和樹葉來建立隔離空間的設施，這就是建築的開始。但是完全隔離也有很多壞處，慢慢就產生了門窗等設施。

建築的本質就是從自然環境中，劃出一塊獨佔的空間，但是仍然能夠通過門窗等和自然環境保持溝通。這個時候架構就已經開始了。對地球上的空間進行切分，並通過門窗，地基等，保持和地球以及空間的有機的溝通。當人類開始學會用火之後，茅棚裡面自然而然慢慢就會被切分為兩部分，一部分用來燒飯，一部分用來生活。當人的排洩慢慢移入到室內後，洗手間也就慢慢的出現了。這就是建築內部的空間切分。

這個時候人們對建築的需求也就慢慢的越來越多，空間的切分也會變成很多種，組合的方式也會有很多種，比如每個人住的房子，群居所產生的宗教性質的房子，集體活動的房子等等。這個時候人們就開始有意識的去設計房子，架構師就慢慢的出現了。一切都是為了滿足人的越來越高的需求，提升質量，減少時間，更有效率的切分空間，並且讓空間之間更加有機的進行溝通。這就是建築的架構以及建築的架構的演變

總結一下，什麼是架構，就是：

1. 根據要解決的問題，對目標系統的邊界進行界定。
2. 並對目標系統按某個原則的進行切分。切分的原則，要便於不同的角色，對切分出來的部分，並行或序列開展工作，一般並行才能減少時間。

3. 並對這些切分出來的部分，設立溝通機制。

4. 根據3，使得這些部分之間能夠進行有機的聯絡，合併組裝成為一個整體，完成目標系統的所有工作。

同樣這個思考可以展開到其他的行業，比如企業的架構，國家的架構，組織架構，音樂架構，色彩架構，軟體架構等等。套用三國演義的一句話，合久必分，分久必合。架構實際上就是指人們根據自己對世界的認識，為解決某個問題，主動地、有目的地去識別問題，並進行分解、合併，解決這個問題的實踐活動。架構的產出物，自然就是對問題的分析，以及解決問題的方案：包括拆分的原則以及理由，溝通合併的原則以及理由，以及拆分，拆分出來的各個部分和合並所對應的角色和所需要的核心能力等。

一、分層架構

分層架構（layered architecture）是最常見的軟體架構，也是事實上的標準架構。如果你不知道要用什麼架構，那就用它。

這種架構將軟體分成若干個水平層，每一層都有清晰的角色和分工，不需要知道其他層的細節。層與層之間通過介面通訊。

雖然沒有明確約定，軟體一定要分成多少層，但是四層的結構最常見。

• 表現層（presentation）：使用者介面，負責視覺和使用者互動
• 業務層（business）：實現業務邏輯
• 持久層（persistence）：提供資料，SQL 語句就放在這一層
• 資料庫（database） ：儲存資料

有的軟體在邏輯層和持久層之間，加了一個服務層（service），提供不同業務邏輯需要的一些通用介面。

使用者的請求將依次通過這四層的處理，不能跳過其中任何一層。

優點

• 結構簡單，容易理解和開發
• 不同技能的程式設計師可以分工，負責不同的層，天然適合大多數軟體公司的組織架構
• 每一層都可以獨立測試，其他層的介面通過模擬解決

缺點

• 一旦環境變化，需要程式碼調整或增加功能時，通常比較麻煩和費時
• 部署比較麻煩，即使只修改一個小地方，往往需要整個軟體重新部署，不容易做持續釋出
• 軟體升級時，可能需要整個服務暫停
• 擴充套件性差。使用者請求大量增加時，必須依次擴充套件每一層，由於每一層內部是耦合的，擴充套件會很困難

二、事件驅動架構

事件（event）是狀態發生變化時，軟體發出的通知。

事件驅動架構（event-driven architecture）就是通過事件進行通訊的軟體架構。它分成四個部分。

• 事件佇列（event queue）：接收事件的入口
• 分發器（event mediator）：將不同的事件分發到不同的業務邏輯單元
• 事件通道（event channel）：分發器與處理器之間的聯絡渠道
• 事件處理器（event processor）：實現業務邏輯，處理完成後會發出事件，觸發下一步操作

對於簡單的專案，事件佇列、分發器和事件通道，可以合為一體，整個軟體就分成事件代理和事件處理器兩部分。

優點

• 分散式的非同步架構，事件處理器之間高度解耦，軟體的擴充套件性好
• 適用性廣，各種型別的專案都可以用
• 效能較好，因為事件的非同步本質，軟體不易產生堵塞
• 事件處理器可以獨立地載入和解除安裝，容易部署

缺點

• 涉及非同步程式設計（要考慮遠端通訊、失去響應等情況），開發相對複雜
• 難以支援原子性操作，因為事件通過會涉及多個處理器，很難回滾
• 分散式和非同步特性導致這個架構較難測試

三、微核架構

微核架構（microkernel architecture）又稱為"外掛架構"（plug-in architecture），指的是軟體的核心相對較小，主要功能和業務邏輯都通過外掛實現。

核心（core）通常只包含系統執行的最小功能。外掛則是互相獨立的，外掛之間的通訊，應該減少到最低，避免出現互相依賴的問題。

優點

• 良好的功能延伸性（extensibility），需要什麼功能，開發一個外掛即可
• 功能之間是隔離的，外掛可以獨立的載入和解除安裝，使得它比較容易部署，
• 可定製性高，適應不同的開發需要
• 可以漸進式地開發，逐步增加功能

缺點

• 擴充套件性（scalability）差，核心通常是一個獨立單元，不容易做成分散式
• 開發難度相對較高，因為涉及到外掛與核心的通訊，以及內部的外掛登記機制

四、微服務架構

微服務架構（microservices architecture）是服務導向架構（service-oriented architecture，縮寫 SOA）的升級。

每一個服務就是一個獨立的部署單元（separately deployed unit）。這些單元都是分散式的，互相解耦，通過遠端通訊協議（比如REST、SOAP）聯絡。

微服務架構分成三種實現模式。

• RESTful API 模式：服務通過 API 提供，雲服務就屬於這一類
• RESTful 應用模式：服務通過傳統的網路協議或者應用協議提供，背後通常是一個多功能的應用程式，常見於企業內部
• 集中訊息模式：採用訊息代理（message broker），可以實現訊息佇列、負載均衡、統一日誌和異常處理，缺點是會出現單點失敗，訊息代理可能要做成叢集

優點

• 擴充套件性好，各個服務之間低耦合
• 容易部署，軟體從單一可部署單元，被拆成了多個服務，每個服務都是可部署單元
• 容易開發，每個元件都可以進行持續整合式的開發，可以做到實時部署，不間斷地升級
• 易於測試，可以單獨測試每一個服務

缺點

• 由於強調互相獨立和低耦合，服務可能會拆分得很細。這導致系統依賴大量的微服務，變得很凌亂和笨重，效能也會不佳。
• 一旦服務之間需要通訊（即一個服務要用到另一個服務），整個架構就會變得複雜。典型的例子就是一些通用的 Utility 類，一種解決方案是把它們拷貝到每一個服務中去，用冗餘換取架構的簡單性。
• 分散式的本質使得這種架構很難實現原子性操作，交易回滾會比較困難。

五、雲架構

雲結構（cloud architecture）主要解決擴充套件性和併發的問題，是最容易擴充套件的架構。

它的高擴充套件性，主要原因是沒使用中央資料庫，而是把資料都複製到記憶體中，變成可複製的記憶體資料單元。然後，業務處理能力封裝成一個個處理單元（prcessing unit）。訪問量增加，就新建處理單元；訪問量減少，就關閉處理單元。由於沒有中央資料庫，所以擴充套件性的最大瓶頸消失了。由於每個處理單元的資料都在記憶體裡，最好要進行資料持久化。

這個模式主要分成兩部分：處理單元（processing unit）和虛擬中介軟體（virtualized middleware）。

• 處理單元：實現業務邏輯
• 虛擬中介軟體：負責通訊、保持sessions、資料複製、分散式處理、處理單元的部署。

虛擬中介軟體又包含四個元件。

• 訊息中介軟體（Messaging Grid）：管理使用者請求和session，當一個請求進來以後，決定分配給哪一個處理單元。
• 資料中介軟體（Data Grid）：將資料複製到每一個處理單元，即資料同步。保證某個處理單元都得到同樣的資料。
• 處理中介軟體（Processing Grid）：可選，如果一個請求涉及不同型別的處理單元，該中介軟體負責協調處理單元
• 部署中介軟體（Deployment Manager）：負責處理單元的啟動和關閉，監控負載和響應時間，當負載增加，就新啟動處理單元，負載減少，就關閉處理單元。

優點

• 高負載，高擴充套件性
• 動態部署

缺點

• 實現複雜，成本較高
• 主要適合網站類應用，不合適大量資料吞吐的大型資料庫應用
• 較難測試

一、分層架構
表現層（presentation）：使用者介面，負責視覺和使用者互動
業務層（business）：實現業務邏輯
持久層（persistence）：提供資料，SQL 語句就放在這一層
資料庫（database） ：儲存資料
有的軟體在邏輯層和持久層之間，加了一個服務層（service），提供不同業務邏輯需要的一些通用介面。

二、事件驅動架構
事件佇列（event queue）：接收事件的入口
分發器（event mediator）：將不同的事件分發到不同的業務邏輯單元
事件通道（event channel）：分發器與處理器之間的聯絡渠道
事件處理器（event processor）：實現業務邏輯，處理完成後會發出事件，觸發下一步操作

三、微核架構
核心（core）通常只包含系統執行的最小功能。外掛則是互相獨立的，外掛之間的通訊，應該減少到最低，避免出現互相依賴的問題。

四、微服務架構
微服務架構（microservices architecture）是服務導向架構（service-oriented architecture，縮寫 SOA）的升級。

微服務架構分成三種實現模式。
RESTful API 模式：服務通過 API 提供，雲服務就屬於這一類
RESTful 應用模式：服務通過傳統的網路協議或者應用協議提供，背後通常是一個多功能的應用程式，常見於企業內部
集中訊息模式：採用訊息代理（message broker），可以實現訊息佇列、負載均衡、統一日誌和異常處理，缺點是會出現單點失敗，訊息代理可能要做成叢集

五、雲架構
這個模式主要分成兩部分：處理單元（processing unit）和虛擬中介軟體（virtualized middleware）。
處理單元：實現業務邏輯
虛擬中介軟體：負責通訊、保持sessions、資料複製、分散式處理、處理單元的部署。

擬中介軟體又包含四個元件。
訊息中介軟體（Messaging Grid）：管理使用者請求和session，當一個請求進來以後，決定分配給哪一個處理單元。
資料中介軟體（Data Grid）：將資料複製到每一個處理單元，即資料同步。保證某個處理單元都得到同樣的資料。
處理中介軟體（Processing Grid）：可選，如果一個請求涉及不同型別的處理單元，該中介軟體負責協調處理單元
部署中介軟體（Deployment Manager）：負責處理單元的啟動和關閉，監控負載和響應時間，當負載增加，就新啟動處理單元，負載減少，就關閉處理單元。

【案例參考】

1、分散式架構設計之電商平臺https://blog.csdn.net/why_2012_gogo/article/details/52823761

2、架構的分類 -  https://blog.csdn.net/xuwei198603/article/details/46454321