乾貨：軟件架構詳解

什麼是架構

計算機科學和程序設計的飛速發展，使得軟件設計應用到從航空航天到平常生活的方方面面。單我的開發一段小程序的作法早就過期，大範圍協做的工程化時代隨即到來。

隨着大範圍協做的效率問題和軟件複雜度的爆炸式增加，管理和技術方面的各類不肯定性也爆發性增長，致使軟件開發的質量沒法獲得有效保證，週期和成本沒法獲得有效控制。

人們一直在尋求找到這些問題的解決辦法。然而 Fred Brooks 在 1975 年出版的軟件工程聖經《人月神話》中說，沒有（能解決全部問題的）銀彈（There is no silver bullet）。

自此，人們發展了項目研發過程管理來控制管理活動的不肯定性，同時也發展了軟件架構設計方法來控制技術方面的不肯定性。

進而在實踐中不斷的總結和改進，用於有效指導和最大程度的保障軟件開發的質量、週期和成本。

架構的定義

架構（Architecture）一詞源於建築領域，其自己就是建築的意思，也是體系結構的意思。維基百科英文版裏對 Architecture 的解釋是：規劃、設計和建造建築物的過程及產物。

鑑於軟件工程與建築工程同樣是一項系統的工程性工做，引入到計算機領域後，軟件架構就成爲了描述軟件規劃設計技術的專有名詞。

特別地，軟件架構師一詞在英文裏，和建築師也是同一個詞（Architect）。

維基百科裏對軟件架構的定義：

軟件架構是有關軟件總體結構與組件的抽象描述，用於指導大型軟件系統各個方面的設計。

軟件架構師定義和設計軟件的模塊化，模塊之間的交互，用戶界面風格，對外接口方法，創新的設計特性，以及高層事物的對象操做、邏輯和流程。軟件架構是一個系統的草圖。

軟件架構描述的對象是直接構成系統的抽象組件。各個組件之間的鏈接則明確和相對細緻地描述組件之間的通信。

在實現階段，這些抽象組件被細化爲實際的組件，好比具體某個類或者對象。在面向對象領域中，組件之間的鏈接一般用接口來實現。

比較公認的軟件架構定義是在 2000 年的 ANSI/IEEE 1471 標準中定義的：

1. 架構過程：在系統整個生命週期中構思、定義、表達、記錄、交流，驗證合適實現，維護和改進架構的過程，也就是設計過程。

2. 架構：一個系統體如今其環境中的元素、關係的基本概念或屬性，以及其設計和進化原則。

3. 架構描述：表達一個架構的工做產出物（一般指的是各類架構圖和設計文檔）。

4. 架構視圖：經過系統的某些關注點的視角，表達一個系統的工做產出物（例如部署視圖、開發視圖等）。

5. 系統：包含了一個或多個進程、硬件、軟件、工具與能夠知足需求的人的集合。

6. 環境：決定了開發、操做、策略和其餘影響系統的設置和條件。

在 UML 中，架構則被認爲是系統的組織結構和相關行爲。架構可被分解爲經過接口互聯部分的關係，以及相互做用。

經過接口相互做用的部分包括類、組件和子系統。這樣就能夠經過 UML 的各類架構圖來描述這些對象和關係，從而表達清楚一個系統的架構。

總結

軟件架構是一個用於指導系統實現的草圖，這個草圖越詳細對於系統實現的指導意義越重大，貫穿於軟件的整個生命週期。

在建築領域，大樓還沒有建造前，就已經存在於建築師的腦海裏；一樣地，系統開始編寫第一行代碼以前，就已經存在於軟件架構師的內心。

幾個相關概念

模式（Pattern）

UML 中給出的解釋更通俗易懂：模式是對於廣泛問題的廣泛解決方案。

咱們能夠把一類問題的共性抽象出來，這樣就能夠用一樣的處理辦法去解決這些問題，從而造成模式，因此模式是一些經驗的總結。

類庫（Library）

類庫是一組可複用的功能或工具的集合，應用系統經過調用它們從而達到複用功能的目的。

例如，Windows 應用開發裏的各類靜態或動態連接庫 DLL 文件，Java 開發中項目裏依賴的或者 Maven 中央庫裏的各類 jar 包，都是 Library，好比 Apache Commons IO、HttpClient，Log4j 等。

框架（Framework）

框架是基於一組類庫或工具，在特定領域裏根據必定的規則組合成的、開放性的應用骨架。

好比 SSM/SSH 框架，更大範圍來講 Dotnet Framework、JDK 都算是一種框架。

關於框架與架構的關係，Vasyl Boroviak 曾在 Stack Overflow 網站上經過兩張圖作了形象的對比，以下所示。

• 框架：

• 架構：

模塊（Module）

模塊是業務或系統的安裝特定維度的一種切分，同時也能夠看作是各類功能按照某種分類聚合的一種形式。

例如咱們的一個電商系統，能夠從業務上劃分爲用戶模塊、商品模塊、訂單模塊、支付模塊、物流模塊、售後模塊等。

另外一方面，咱們也能夠說用戶模塊聚合了用戶註冊、用戶驗證等業務功能。

組件（Component）

組件是一組能夠複用的業務功能的集合，包含一些對象及其行爲。

組件能夠直接被用作業務系統的組成部分，粒度通常小於模塊，也是一種功能的聚合形式。好比日誌組件、權限組件等。

服務（Service）

服務是一組對外提供業務處理能力的功能，服務須要使用明確的接口方式（好比 WebService 或 Rest 等）。

服務描述裏應該包括約束和策略（好比參數、返回值，使用什麼通信協議和數據格式等）。

平臺（Platform）

平臺通常來講，是一個領域或方向上的生態系統，是不少解決方案的集大成者，提供了不少的服務、接口、規範、標準、功能、工具等。

例如 J2EE 平臺，包含了企業級應用開發裏的各類基於 Java 語言和 JVM 虛擬機運行時的技術能力。

知乎社區編程領域優秀問題回答者 ze ran 說：

庫是工具箱。

框架是一套通用的解決方案。

架構是高度抽象的需求，是系統中的不變量。

平臺是全部可能作的事的集合。

從軟件的生命週期看架構設計

設計期

在設計期，軟件做爲一個成品還不存在，因此咱們能夠稱之爲概念形態。

此時架構師、產品經理或需求分析師等人員利用本身的經驗能力，對系統的業務需求進行分析、拆解、抽象，造成業務文檔和技術文檔，以及技術驗證代碼等。

這個階段，架構設計工做是重中之重，其中包括：

• 系統分拆：如何把系統拆解爲不一樣的子系統、模塊、業務單元；

• 技術選型：使用什麼樣的基礎技術框架或腳手架；

• 技術驗證：肯定核心技術難點如何解決，檢驗可否知足指望指標；

• 接口規範：系統的內部不一樣部分以何種形式肯定接口契約和數據通訊；

• 集成方式：系統與外部其餘業務系統如何進行集成；

• 技術規範：如何規範開發、測試、部署和運維的技術標準性；

• 部署方案：系統如何進行物理部署，須要多少機器、什麼配置，對網絡有什麼要求；

• 運維方案：系統如何進行技術性運維，如何平常監控、預警報警；

• ……

這個階段總結一下就是：業務爲要，架構先行（包括業務架構和技術架構）。

實現期

這個階段主要是編碼與測試，準備部署上線，是軟件從代碼到最終的生產系統的過程，咱們能夠稱之爲代碼形態。此階段須要考慮的技術類工做包括：

• 確保各項技術規範和技術指標的執行落地，保障高質量的代碼；

• 指導研發人員和解決各種技術問題，提高研發團隊效率；

• 制定測試的技術性方案和基準，自動化、性能、安全等；

• 配合準備部署環境，運維實施方案落地等。

運行期

這個階段系統上線、驗收經過，已經初步穩定，而後進入維護階段，成爲了設計期架構設計草圖的一個可用實例，咱們能夠稱之爲實例形態。此時須要考慮：

• 發佈上線相關基礎性工做，包括是否使用持續集成（CI)、自動化發佈等技術；

• 運維基礎性工做，自動化運維，監控等相關技術。

架構的形式與特色

設計文檔和代碼

咱們通常說的架構既包括架構的設計過程，也包括設計的產出物，通常能夠包括各種設計文檔、設計圖，也能夠包括一些技術驗證代碼、Demo 或者其餘相關程序。

文檔的目的在於準確記錄咱們的思惟產物，在軟件還沒有實現時，做爲指導藍圖，儘可能精確的描述清楚軟件。

在軟件的實現過程當中，可能隨時隨着咱們的深刻研究，根據具體狀況對文檔作出局部的一些調整和修改。

文檔做爲結項或交接的一部分，也是整個軟件項目的產出物的一部分，成爲公司 IT 資產的有機組成部分。

架構服務於業務

正如 19 世紀的偉大建築師路易斯•沙利文（Louis Sullivan）倡導的建築設計著名格言：「功能決定形式（Form follows function）」。

軟件架構首先是要服務於業務功能的。

架構影響研發團隊的組織形式

業務拆分的方法和技術框架的選擇必然會影響到研發團隊的組織形式。

業務拆分的越細緻，越有利於咱們更好的對項目的各項指標量化計算，更精確的估計工時和成本，從而指導咱們每一個小組應該分配多少資源，使用什麼樣的協同和任務確認形式。

而且隨着項目的推動，計劃與實際狀況之間的匹配程度也隨時能夠進一步精確調整，進而影響到咱們應該對每一塊任務的投入資源進行動態調整。

架構存在於每個系統

每個已經實現並運行的系統，都是特定架構設計的載體。

有些系統對應的架構，有詳細的設計文檔來描述；有些系統的設計文檔，殘缺不全，甚至還由於在系統的發展變化的同時，文檔沒有更新，致使設計文檔與實際系統不符。

有些系統乾脆就沒有設計文檔。

可是這些系統，都是基於必定的架構來建立的。

每種架構都有特定的架構風格

每種架構方式，每一個具體系統內所體現的架構設計，都是能夠被工程師們理解，進而提煉出來一些架構思想和設計原則，這些思想和原則就是這種架構方式的風格。

依據這些風格，咱們能夠將各類架構方式，進行分門別類，從而進一步討論每種架構風格的特色。

架構須要不斷的發展演進

隨着計算機軟硬件的不斷髮展，軟件架構思想也在不斷的發展變化。

另外一方面，軟件爲其提供業務處理和服務能力的每一個具體行業領域也在不斷髮展變化，業務處理流程、參與角色、業務形式不斷的推陳出新。

這就要求咱們在系統架構設計時，保持終身學習的精神，持續吸取新思想新知識，保持貼近一線業務羣體，隨時因地制宜，調整架構設計，採起最適合當下場景的解決方案。

架構的目標與方法

明確軟件系統架構的一些通用目標，可使咱們更明確如何考慮架構的方向；而瞭解架構的方法和方法論，則讓咱們能夠知道從哪些角度能夠比較全面的描述清楚一個系統的架構設計。

可控性與拆分

對於複雜問題的簡化處理，一個簡單辦法就是分而治之。

按必定的粒度把目標問題進行分解，能夠很是有效的提高目標的可控性，使得目標變得更加能夠量化、進而優化。

系統按照合適的粒度拆分紅不一樣模塊的過程，咱們通常稱爲模塊化。模塊化也是軟件工程化的基礎。

在這個基礎上纔可以實現分工合做。

複用性與抽象

複用性一直是軟件設計領域的一個很重要的指標。

複用的一個關鍵是咱們對於現有具體問題的抽象，找到各類不一樣問題中存在的不變性，進而做爲一種通用結構來統一處理。

拆成是把總體變成不少局部，再對局部分開對待和研究其性質。

反過來，咱們按照高內聚的指導思想把一些緊密聯繫的功能聚合後，打包成一個能夠總體複用的部分，這就是組件，這個過程就是組件化。

經過組件化，咱們能夠獲得抽象再組合出來不少業務組件。這樣，在更大粒度上實現了功能的複用。

非功能性需求九維目標

（1）高性能

系統必須知足預期的性能目標，在併發用戶數（Concurrent Users）、併發事務數（Transactions per Second，TPS）、吞吐量（Throughout）等指標方面達到預估值，支撐使用人羣的正常使用操做。

（2）可靠性

業務系統直接影響到用戶的經營和管理，所以必須是可靠的。

（3） 穩定性

軟件系統必須是可以在用戶的使用週期內長期穩定運行的。這要求系統具備必定的容錯能力。

（4）可用性

可用性是指系統在指定時間內的提供服務能力的機率值。咱們通常採起集羣、分佈式等手段提高系統的可用性。

高可用性是目前系統架構設計方面的一個熱點。

（5）安全性

用戶的業務數據是具備很是高的商業價值，若是被泄露或篡改將會帶來重大損失。

安全性是軟件系統的一個重要的指標，也是架構設計的一個重要目標。

（6）靈活性

軟件系統應該具有知足不一樣特色的用戶羣和目標市場的能力，更靈活。

（7）易用性

軟件系統必須擁有較好的用戶體驗，便於用戶使用。

（8）可擴展性

業務和技術都在不斷的發展變化，軟件系統須要隨時根據變化擴展改造的能力。

（9）可維護性

軟件系統的維護包括修復現有的錯誤，以及將新的需求和改進添加到已有系統。

所以一個易於維護的系統對於用戶提出的問題或改進，能夠及時的實現高效的反饋和響應支持，同時有效下降維護成本。

基於這些目標，常常有人說：「架構是系統非功能性需求的解決辦法的集合」。

架構的不一樣風格

典型的企業級應用系統或者互聯網應用系統通常都是經過 Web 提供一組業務服務能力。

這類系統包括提供給用戶操做的、運行於瀏覽器中、具備 UI 的業務邏輯展現和輸入部分，運行於服務器端、用後端編程語言構建的業務邏輯處理部分，以及用於存儲業務數據的關係數據庫或其餘類型的存儲軟件。

根據軟件系統在運行期的表現風格和部署結構，咱們能夠粗略地將其劃分爲兩大類。

（1）整個系統的全部功能單元，總體部署到同一個進程（全部代碼能夠打包成 1 個或多個文件），咱們能夠稱之爲 「單體架構」（Monolithic Architecture）；

（2）整個系統的功能單元分散到不一樣的進程，而後由多個進程共同提供不一樣的業務能力，咱們稱之爲 「分佈式架構」（Distributed Architecture）。

再結合軟件系統在整個生命週期的特色，咱們能夠進一步區分不一樣的架構風格。

對於單體架構，咱們根據設計期和開發實現期的不一樣模式和劃分結構，能夠分爲：

• 簡單單體模式：代碼層面沒有拆分，全部的業務邏輯都在一個項目（Project）裏打包成一個二進制的編譯後文件，經過這個文件進行部署，並提供業務能力；

• MVC 模式：系統內每一個模塊的功能組件按照不一樣的職責劃分爲模型（Model）、視圖（View）、控制器（Controller）等角色，並以此來組織研發實現工做；

• 先後端分離模式：將先後端代碼耦合的設計改成前端邏輯和後端邏輯獨立編寫實現的處理模式；

• 組件模式：系統的每個模塊拆分爲一個子項目（SubProject），每一個模塊獨立編譯打包成一個組件，而後全部須要的組件一塊兒再部署到同一個容器裏；

• 類庫模式：A 系統須要複用 B 系統的某些功能，這時能夠直接把 B 系統的某些組件做爲依賴庫，打包到 A 系統來使用。

對於分佈式架構，咱們根據設計期的架構思想和運行期的不一樣結構，能夠分爲：

• 面向服務架構（Service Oriented Architecture）：以業務服務的角度和服務總線的方式（通常是 WebService 與 ESB）考慮系統架構和企業 IT 治理；

• 分佈式服務架構（Distributed Service Architecture）：基於去中心化的分佈式服務框架與技術，考慮系統架構和服務治理；

• 微服務架構（MicroServices Architecture）：微服務架構能夠看作是面向服務架構和分佈式服務架構的拓展，使用更細粒度的服務（因此叫微服務）和一組設計準則來考慮大規模的複雜系統架構設計。

也有人把如上的各個架構風格總結爲四個大的架構發展階段：

（1）單體架構階段

（2）垂直架構階段

（3）SOA 架構階段

（4）微服務架構階段

這種分類跟前述的方式並無多大區別。咱們接下來詳細介紹其中的一些重要架構風格。

單體架構：簡單單體模式

簡單單體模式是最簡單的架構風格，全部的代碼全都在一個項目中。這樣研發團隊的任何一我的均可以隨時修改任意的一段代碼，或者增長一些新的代碼。

開發人員也能夠只在本身的電腦上就能夠隨時開發、調試、測試整個系統的功能。

也不須要額外的一些依賴條件和準備步驟，咱們就能夠直接編譯打包整個系統代碼，建立一個能夠發佈的二進制版本。

這種方式對於一個新團隊的創立初期，須要迅速開始從 0 到 1，抓住時機實現產品最短期推向市場，能夠省去各類額外的設計，直接上手幹活，爭取了時間，於是是很是有意義的。

可是這種方式對於一個系統的長期穩定發展確實有不少壞處的。

首先，簡單單體模式的系統存在代碼嚴重耦合的問題。全部的代碼都在一塊兒，就算是按照 package 來切分了不一樣的模塊，各不一樣模塊的代碼仍是能夠直接相互引用。

這就致使了系統內的對象間依賴關係混亂，修改一處代碼，可能會影響一大片的功能沒法正常使用。

第二，簡單單體模式的系統變動對部署影響大，而且這個問題是全部的單體架構系統都存在的問題。

系統做爲一個單體部署，每次發佈的部署單元就是一個新版本的整個系統，系統內的任何業務邏輯調整都會致使整個系統的從新打包，部署、停機、再重啓，進而致使了系統的停機發布時間較長。

每次發佈上線都是生產系統的重大變動，這種部署模式大大提高了系統風險，下降了系統的可用性。

第三，簡單單體模式的系統影響開發效率。

若是一個使用 Java 的簡單單體項目代碼超過 100 萬行，那麼在一臺筆記本電腦上修改了代碼後執行自動編譯，可能須要等待十分鐘以上，而且內存可能不夠編譯過程使用，這是很是難以忍受的。

第四，簡單單體模式打包後的部署結構可能過於龐大，致使業務系統啓動很慢，進而也會影響系統的可用性。

這一條也是全部單體架構的系統都有的問題。

第五，擴展性受限，也是全部單體架構的一個問題。

若是任何一個業務存在性能問題，那麼都須要考慮多部署幾個完整的實例的集羣，或者再加上負載均衡設備，才能保證整個系統的性能能夠支撐用戶的使用。

因此，簡單單體模式比較適用於規模較小的系統，特別是須要快速推出原型實現，以質量換速度的場景。

單體架構：MVC 模式

MVC 也是一個很是常見的 3 層（3-Tier）結構架構模式，它把每一個模塊劃分爲模型層（Model Layer）、視圖層（View Layer）、控制器層（Controller Layer）等部分。

• 模型層：表明業務數據實體部分；

• 視圖層：表明前端的展現部分；

• 控制器層：表明請求分發，處理調度部分。

更通常地，咱們能夠添加數據操做層（Data Access Layer）等，造成一個 N 層（N-Tier）結構模型。

整個系統由多個模塊組成，每一個模塊又由這種不一樣的部分組成。這樣一來，咱們就把整個系統拆解成了不少粒度較小的零件。這種方式之因此流行開來，主要是由於：

• 簡單，直觀，能夠很是有效的上手，做爲 Web 系統設計的通常方法，這一點是 MVC 模式被普及的基礎條件；

• 通過上面過程的橫割豎切，咱們已經把系統拆解爲一個個的小單元，很是有利於分配開發工做，投入大量的工程師進行大規模的工程化開發，這一點很是重要，在軟件行業高速發展的今天，適合工程化的方式纔是最具備生產力的辦法；

• 不一樣的模塊和分層結構，自己就能夠做爲一個開發層面的子項目拆分結構，這樣咱們就能夠把系統拆分紅多個不一樣的子項目；

• 基於 MVC 模式，又陸續發展了 ORM 等簡化數據操做層的技術與框架，以及相應的代碼生成工具等，極大的提供了軟件開發效率。

固然，MVC 模式也存在定義不夠明確，對於簡單的業務場景拆解過細緻使複雜度增長等問題，須要在實踐中不斷摸索和總結應用經驗。

基於單體架構下的 MVC 模式依然解決不了單體架構自己存在的問題，特別是對於可用性和擴展性的影響。

單體架構：先後端分離模式

傳統的 Web 系統都是 BS 結構的。

通常的 JSP 或頁面標籤 Tag 技術、後端 FreeMaker 或 Velocity 等模板技術致使 HTML/CSS/JavaScript 等前端技術與後端的處理邏輯和數據耦合到一塊兒，這種方式明顯不符合現代工程化的專業領域細分原則。

特別是隨着富網絡應用程序（Rich Internet Application，RIA）概念的興起，Ajax 和 JQuery 框架，前端 UI 組件技術的大行其道，程序員們在瀏覽器端寫了不少邏輯處理和界面處理的 JavaScript 代碼。

後來愈來愈多的業務邏輯須要在瀏覽器端實現，前端技術逐漸發展到了一個百花齊放的階段，特別是近年來基於 NodeJS 前端技術棧的成功應用，最終使前端技術成爲了一個與後端技術領域並駕齊驅的領域。

其實早在 2006 年，ExtJS 做爲當時的前端解決方案集大成者，已經實現了前端代碼邏輯和界面所有都由 JavaScript 完成，後端只提供基於 URL 的 JSON 數據接口。

這樣 Web 系統就由原來的 BS 系統，變成了提供 UI 和交互的前端 B 系統，提供數據接口的後端 S 系統，從而達到了先後端分離的目標。

自從，愈來愈多的系統採用先後端分離的模式，而且進一步影響了研發團隊的組成：前端團隊負責前端系統開發，後端團隊負責後端系統開發，兩個團隊一塊兒制定先後端系統的數據接口。

只要數據接口保持穩定不變，那麼先後端系統能夠各自獨立發展和維護。這一條準則不只僅是單體架構獨有的，全部的 Web 系統均可以按照這種方式進行設計。

先後端分離模式一直影響到如今的系統架構方法，成爲了當下的一種最佳實踐。目前最主流的三種前端開發框架（React、AngularJS、Vue），都遵循着這種設計理念。

分佈式架構：面向服務架構（SOA）

• 服務與 SOA

面向服務架構（SOA）是一種建設企業 IT 生態系統的架構指導思想。SOA 的關注點是服務。服務最基本的業務功能單元，由平臺中立性的接口契約來定義。

經過將業務系統服務化，能夠將不一樣模塊解耦，各類異構系統間能夠輕鬆實現服務調用、消息交換和資源共享。

（1）從宏觀的視角來看，不一樣於以往的孤立業務系統，SOA 強調整個企業 IT 生態環境是一個大的總體。整個 IT 生態中的全部業務服務構成了企業的核心 IT 資源。

各系統的業務拆解爲不一樣粒度和層次的模塊和服務，服務能夠組裝到更大的粒度，不一樣來源的服務能夠編排到同一個處理流程，實現很是複雜的集成場景和更加豐富的業務功能。

（2）從研發的視角來看，系統的複用能夠從之前代碼級的粒度，擴展到業務服務的粒度；可以快速應對業務需求和集成需求的變動。

（3）從管理的角度來看，SOA 從更高的層次對整個企業 IT 生態進行統一的設計與管理，對消息處理與服務調用進行監控，優化資源配置，下降系統複雜度和綜合成本，爲業務流程梳理和優化提供技術支撐。

• SOA 落地方式

SOA 的落地方式與水平，跟企業 IT 特色、服務能力和發展階段直接相關。目前常見的落地方式主要有分佈式服務化和集中式管理兩種。

（1）分佈式服務化

互聯網類型的企業，業務與技術發展快，數據基數與增量都大，併發訪問量高，系統間依賴關係複雜、調用頻繁，分佈式服務化與服務治理迫在眉睫。

經過統一的服務化技術手段，進一步實現服務的註冊與尋址、服務調用關係查找、服務調用與消息處理監控、服務質量與服務降級等等。

現有的一些分佈式服務化技術有 Dubbo（基於 Java）、Finagle（基於 Scala）和 ICE（跨平臺）等。

（2）集中式管理

傳統企業的 IT 內部遺留系統包袱較重，資源整合很大一部分是須要打通新舊技術體系的任督二脈，因此更偏重於以 ESB 做爲基礎支撐技術。

以整合集成爲核心，將各個新舊系統的業務能力逐漸的在 ESB 容器上聚合和集成起來。

比較流行的商業 ESB 有 IBM 的 WMB 和 Oracle 的 OSB，開源 ESB 有 Mule、ServiceMix/WSO2 ESB、JBoss ESB 和 OpenESB。

一方面，集中式管理的 SOA，其優點在於管理和集成企業內部各處散落的業務服務能力，同時一個明顯的不足在於其中心化的架構方法，並不能解決各個系統本身內部的問題。

另外一方面，隨着自動化測試技術、輕量級容器技術等相關技術的發展，分佈式服務技術愈來愈像微服務架構方向發展。

分佈式架構：微服務架構（MSA）

James Lewis 和 Martin Fowler 給微服務架構的定義以下：

微服務架構風格，以實現一組微服務的方式來開發一個獨立的應用系統的方法。其中每一個小微服務都運行在本身的進程中，通常採用 HTTP 資源 API 這樣輕量的機制相互通訊。

這些微服務圍繞業務功能進行構建，經過全自動化的部署方式來進行獨立部署。這些微服務可使用不一樣的語言來編寫，也可使用不一樣的數據存儲技術，而且基於最低限度的集中管理。

同時 Martin Fowler 總結有以下 9 個特性：

• 組件以服務的形式提供

• 圍繞業務功能進行組織

• 產品而不是項目

• 強化終端與弱化管道

• 「去中心化」 地治理技術署

• 「去中心化」 地管理數據

• 「基礎設施」 自動化

• 「容錯」 設計

• 「演進式」 設計

微服務架構能夠看做是一種 SOA 的發展實現，其將 SOA 中本來可能聚合在同一個系統內的多個服務組件拆分到各自獨立的系統進程。

微服務架構的優點在於：

• 更加完全的組件化，系統內部各個組件之間解耦的比較乾脆，單個系統的規模小不少；

• 能夠組建每一個服務獨立的維護團隊，利於各自團隊獨立的開發和維護；

• 每一個微服務獨立部署，只要服務間的接口穩定，各系統能夠相互之間互不干擾的獨立發展；

• 微服務架構使得每一個服務自己能夠獨立的擴展，性能出現瓶頸，優化或增長這個服務的配置便可。

微服務架構的劣勢也很明顯，拆分的過細則要求自動化測試能力必須跟得上。一個全流程的測試跨 8~10 個系統是全部測試人員的惡魔。

問題的排查，數據的一致性保障，系統的監控等等，都會由於拆分的太細，複雜度大幅度增長。

若是代碼或設計上有一個修改涉及到多個不一樣的微服務，那麼在團隊之間協調配合成本也會增長。對舊系統的微服務架構和組件化改造也是一個比較大的問題。

在組件化上所作的任何工做的成功度，取決於軟件與組件的匹配程度。

可是合理的組件邊界應該如何肯定，這是很是困難的，演進式的處理方式是咱們以爲比較合理和靠譜的。

所以，Martin Fowler 也建議，不要一上來就以微服務架構做爲系統設計的起點。相反地，要用一個單塊系統做爲起點，並保持其模塊化。

當這個單塊系統出現了問題後，再將其分解爲微服務。

推薦一個交流學習羣：650385180裏面會分享一些資深架構師錄製的視頻錄像：有Spring，MyBatis，Netty源碼分析，高併發、高性能、分佈式、微服務架構的原理，JVM性能優化這些成爲架構師必備的知識體系。還能領取免費的學習資源，目前受益良多：