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

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

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

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

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

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

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

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

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

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

簡單來說，這些架構面向的人群不同。 
業務架構、功能架構面向業務人員，業務用來告訴業務人員我們要做的系統或系統群為哪些業務提供了系統支撐，功能架構用於描述細分業務下提供了哪些功能，注意這裡的功能和技術人員的功能的定義是有偏差的。 應用架構是介於技術和業務之間的一個管理層面的中間產物，簡單點講某個業務的功能可能分佈在不同的應用中，某個應用可能由多個系統協作來完成。一般企業以應用為管理單元。 系統架構用於描述系統定位與整合關係，是用來圈定單個系統的功能範圍的。關注系統架構的一般是科技條線的中層，通常會按照系統架構制定專案計劃。 技術架構的邊界比較模糊，對不同受眾描述的詳細程度不同，科技條線自上而下都是比較關注技術架構的，但是各層關注的點不同，高層可能關心的是對系統或系統群使用的技術選型，對整體的把握，要保證不會因為選型引起其他的風險，舉個例子，如果在高效能儲存方面選擇redis的話，就要儘量保證網路的封閉性，避免公網訪問；選擇以cobol語言實現的各類產品時要考慮市場上開發人員數量少，承擔更高的迭代成本等。

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

應用架構

    分有兩種方式，

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

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

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

單體式應用

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

    單體式應用採用分層架構，一般為表示層、業務層、資料訪問層、DB層，表示層負責使用者體驗，業務層負責業務邏輯，資料訪問層負責DB層的資料存取

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

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

分散式架構

    分散式應用架構中，相互獨立，程式碼獨立開發，獨立部署，通過API介面互相通訊。通訊協議一般使用HTTP，資料格式是JSON，應用整合方式比較簡化。

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

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

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

      SOA也是分散式應用架構一種，

      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