微服務架構設計實踐

目 次

1 序言

2 微服務

3 軟件架構設計思想

4 微服務架構設計實踐

4.1 項目概述

4.2 架構準備階段

4.3 概念架構階段

4.4 細化架構階段

4.4.1 業(yè)務架構

4.4.2 數(shù)據(jù)架構

4.4.3 應用架構

4.4.4 技術架構

4.4.5 物理架構

4.4.6 開發(fā)架構

1 序言

最近，在軟件架構設計領域，微服務非?；?。

一提到軟件開發(fā)、架構設計，如果不提微服務，不說說微服務的架構風格，那就落伍了，OUT了。

當然了，支持微服務的技術也是層出不窮，如微服務1.0中比較有名的來自Spring家族的Spring Cloud，以及國內在開源領域的翹楚阿里系中的Dubbo。其中，Spring Cloud提供了完整的微服務解決方案，為開發(fā)者提供了快速構建分布式系統(tǒng)的通用模型的工具，包括配置管理、服務發(fā)現(xiàn)、熔斷器、智能路由、微代理、控制總線、一次性令牌、全局鎖、領導選舉、分布式會話、集群狀態(tài)等。而Dubbo是一個分布式服務框架，致力于提供高性能和透明化的RPC遠程服務調用方案，以及服務治理方案。

隨著微服務的持續(xù)火熱，微服務2.0中的ServiceMesh也火起來了。Service Mesh，即“服務網(wǎng)格”，作為服務間通信的基礎設施層，Service Mesh可以被看作是微服務間的TCP/IP，負責服務之間的網(wǎng)絡調用、限流、熔斷和監(jiān)控。對于編寫服務的開發(fā)人員來說，一般無須關心TCP/IP這一層（比如通過 HTTP 協(xié)議的 RESTful 應用），同樣使用Service Mesh也就無須關心服務之間的那些原來是通過應用程序或者其他框架實現(xiàn)的事情，比如Spring Cloud、OSS，現(xiàn)在只要交給Service Mesh就可以了。

其實，上述說了那么多，介紹了那么多，基本都是集中在概念層面，在理論的層次上，以及支持微服務的開發(fā)技術、開發(fā)框架上，缺少這些概念、理論、技術和框架在實際項目中具體地應用。

對于大多數(shù)開發(fā)人員、架構師來說，除了理解微服務相關的概念，熟悉微服務相關的技術和框架，更關心如何在實際的項目中，應用這些概念、技術和框架。而這些，正是現(xiàn)在所欠缺的。

筆者從事軟件開發(fā)多年，參與和指導過多個項目的架構設計，經(jīng)歷過單體架構、分布式架構、SOA架構，對軟件架構的發(fā)展歷史有一定的了解。

同時，在架構設計過程中，筆者也拜讀了多位架構大師的著作，如溫昱老師的《軟件架構設計》、《一級架構師》，Peter Eeles和Peter Cripps的《軟件架構設計的過程》等，以及各位技術大咖們在互聯(lián)網(wǎng)上分享的各類架構相關的文檔，使我受益匪淺。在此，我衷心的對這些前輩們表示由衷的感謝，謝謝你們對于知識的分享，以及無私奉獻的精神。

最近，筆者有幸參與了某銀行的一個采用微服務架構風格的項目，實踐了一下微服務架構。

更確切地說，該項目是分布式服務架構向微服務架構的演進，使用更細粒度的服務和一組設計準則來考慮大規(guī)模的、復雜的系統(tǒng)架構設計，并非一個純粹的微服務架構風格的項目。

秉著知識共享的精神，筆者寫了這篇“微服務架構設計實踐”的文章，一方面是對自己在架構設計方面的一個階段性總結，另一方面是希望給其他剛剛從事軟件架構設計的人員一個真實的、具體的軟件架構過程的實踐參考，為他們提供一個完整的實踐案例。

在寫這篇文章的過程中，在介紹微服務、軟件架構設計思想的概念、方法論時，引用了各位大師、技術大咖們關于微服務、架構設計的文章中的內容，在此衷心地表示感謝。對于引用的內容，筆者并非簡單地摘抄，而是結合筆者的理解和實踐，做了適當?shù)恼{整。如果存在不適、錯誤的地方，希望各位及時地指出，我將積極的采納和修改。

2 微服務

2.1 微服務的定義

微服務是一個獨立、可部署的服務，它只專注做一件事情并且做好，而這個事情通?？梢允菢I(yè)務能力，或者提供業(yè)務價值的最小單元服務。

微服務的描述具有一般服務描述所遵循的內容：

1.使用明確的接口方式，如：WebService、Rest。

2.描述里應該包括約束和策略，如：參數(shù)、返回值，以及使用什么通訊協(xié)議和數(shù)據(jù)格式等。

微服務中“微”是其獨特個性的體現(xiàn)，“微”表示“接口粒度細”。

簡而言之，微服務的特征歸結為：

1.職責單一，相對獨立。

2.接口粒度細。

3.輕量級通訊協(xié)議。

4.服務之間松耦合。

2.2 微服務架構的定義

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

微服務架構風格指將復雜系統(tǒng)切分為幾十甚至上百個小服務，每個服務負責實現(xiàn)一個獨立的業(yè)務邏輯。系統(tǒng)中的各個服務通常是獨立部署，彼此之間是松耦合的。

每個服務都運行在自己的進程中，一般采用Rest API風格的輕量級通訊協(xié)議進行相互通信。

這些服務圍繞業(yè)務功能進行構建，通過全自動化的部署方式來進行獨立部署。

這些服務可以使用不同的語言來編寫，也可以使用不同的數(shù)據(jù)存儲技術，并且基于最低限度的集中管理。

2.3 微服務架構的特征

Martin Fowler 認為，微服務架構具有如下 9 個特性：

1.組件以服務的形式提供。

2.圍繞業(yè)務功能進行組織。

3.產(chǎn)品而不是項目。

4.強化終端與弱化管道。

5.“去中心化” 地治理技術。

6.“去中心化” 地管理數(shù)據(jù)。

7.“基礎設施” 自動化。

8.“容錯” 設計。

9.“演進式” 設計。

2.4 微服務架構的優(yōu)缺點

微服務架構的優(yōu)點在于：

1.更加徹底的組件化，系統(tǒng)內部各個組件之間解耦的比較干脆，單個系統(tǒng)的規(guī)模小很多。

2.可以組建每個服務獨立的維護團隊，利于各自團隊獨立的開發(fā)和維護。

3.每個微服務獨立部署，只要服務間的接口穩(wěn)定，各系統(tǒng)可以相互之間互不干擾的獨立發(fā)展。

4.微服務架構使得每個服務本身可以獨立的擴展，性能出現(xiàn)瓶頸，優(yōu)化或增加這個服務的配置即可。

微服務架構的缺點在于：

1.微服務強調了服務大小，但實際上，業(yè)界并沒有給出一個明確的、統(tǒng)一的標準。業(yè)務邏輯應該按照什么規(guī)則劃分為微服務，這本身就是一個經(jīng)驗工程。但要記住，微服務是達到目的的手段，而不是目標。微服務的目標是充分分解應用程序，以促進敏捷開發(fā)和持續(xù)集成部署。

2.它的分布式特點帶來的復雜性。開發(fā)人員需要基于RPC或者消息實現(xiàn)微服務之間的調用和通信，而這就使得服務之間的發(fā)現(xiàn)、服務調用鏈的跟蹤和質量問題變得的相當棘手。

微服務架構所面臨的挑戰(zhàn)：

1.分區(qū)的數(shù)據(jù)庫體系和分布式事務。在微服務架構下，不同服務可能擁有不同的數(shù)據(jù)庫。CAP原理的約束，使得我們不得不放棄傳統(tǒng)的強一致性，而轉而追求最終一致性，這個對開發(fā)人員來說是一個挑戰(zhàn)。

2.對測試帶來了很大的挑戰(zhàn)。對微服務進行測試，需要啟動它依賴的所有其他服務，這種復雜性不可低估。

3.對跨多個服務的更改帶來的挑戰(zhàn)。在微服務架構中，若有A、B、C三個服務需要更改，A依賴B，B依賴C。此時，我們需要仔細規(guī)劃和協(xié)調每個服務的變更部署，可能需要先更新C，然后更新B，最后更新A。

4.部署基于微服務的應用也要復雜得多。微服務由不同的大量服務構成，每種服務擁有自己的配置、應用實例數(shù)量以及基礎服務地址，這里就需要不同的配置、部署、擴展和監(jiān)控組件。此外，我們還需要服務發(fā)現(xiàn)機制，以便服務可以發(fā)現(xiàn)與其通信的其他服務的地址。因此，成功部署微服務應用需要開發(fā)人員有更好地部署策略和高度自動化的水平。

基于上述的微服務存在的優(yōu)缺點，以及微服務架構設計過程中面臨的挑戰(zhàn)，建議在軟件架構設計時，不要從一開始就以微服務架構作為系統(tǒng)設計的起點。相反地，要用一個單個系統(tǒng)作為起點，并保持其模塊化。當這個系統(tǒng)出現(xiàn)了問題后，再將其分解為微服務。

3 軟件架構設計思想

3.1 軟件架構定義

對于軟件架構的定義，仁者見仁，智者見智。目前，業(yè)界比較流行的兩大流派是組成派和決策派，這兩派的概念相輔相成，具體如下：

組成派：軟件架構 = 組件 + 交互。

決策派：軟件架構 = 重要決策集。

上述兩大流派的描述過于抽象，不利于理解，本人更喜歡下述關于軟件架構的描述，通俗易懂，即：

軟件架構是軟件整體結構與組件的抽象描述，用于指導大型軟件系統(tǒng)各個方面的設計。軟件架構描述的對象是直接構成系統(tǒng)的抽象組件，各個組件之間的連接則明確和相對細致地描述組件之間的通訊。在實現(xiàn)階段，這些抽象組件被細化為實際的組件，比如具體某個類或者對象。在面向對象領域中，組件之間的連接通常用接口來實現(xiàn)。

軟件架構是一個用于指導系統(tǒng)實現(xiàn)的草圖，這個草圖越詳細對于系統(tǒng)實現(xiàn)的指導意義越重大，貫穿于軟件的整個生命周期。

3.2 軟件架構本質

架構的本質就是對系統(tǒng)進行有序化重構，不斷減少系統(tǒng)無序的程度，使系統(tǒng)不斷進化。

架構從無序到有序的基本實現(xiàn)手段是分和合，即先把系統(tǒng)打散，然后重新組合。

分的過程是把系統(tǒng)拆分為各個子系統(tǒng)、模塊、組件。拆分的時候，首先要解決每個組件的定位問題，然后才能劃分彼此的邊界，實現(xiàn)合理的拆分。合的過程就是根據(jù)最終要求，把各個分離的組件有機整合在一起。

分的結果使開發(fā)人員能夠做到業(yè)務聚焦、技能聚焦，實現(xiàn)開發(fā)敏捷；

合的結果使系統(tǒng)變得柔性，可以因需而變，實現(xiàn)業(yè)務敏捷。

相對來說，第一步的拆分更難。

3.3 軟件架構過程

在此次軟件架構設計過程中，采用了溫昱老師在《軟件架構設計》一書中提及的ADMEMS方法體系。

ADMEMS方法通過3個階段和一個貫穿環(huán)節(jié)，來覆蓋“需求進，架構出”的完整架構設計過程。

3.3.1 PA階段

架構準備階段是架構設計的第一個階段，此階段的工作目標是：理解需求，建立需求大局觀，確定架構設計方向等。

功能需求、質量屬性和約束共同決定了架構，對這3類需求的把握是否到位、設計決策是否對路，是軟件架構設計的關鍵所在。

如果可能的話，架構師應該盡早的參與需求分析工作，對需求進行大局的梳理，而不能被動地等待《軟件需求規(guī)格說明書》的完成。

只要滿足以下3個條件，架構師就可以開始架構設計工作：

1.明確的業(yè)務需求：甲、乙雙方對系統(tǒng)的目標達成共識，《愿景文檔》通過了正式評審，并且明確了投資、工期標準、整合等約束條件。

2.全面的用戶需求：系統(tǒng)范圍明確，即系統(tǒng)能幫用戶干什么，不能干什么。

3.典型的行為需求：核心功能的《用例規(guī)約》已定義。

在架構準備階段，通過對軟件需求的詳細分析，抽取出確定概念性架構所需要的關鍵需求。

此階段的輸入是軟件需求（即上述的三部分：明確的業(yè)務需求、全面的用戶需求、典型的行為需求），成果物是確定的關鍵需求，包括關鍵功能、關鍵質量屬性和關鍵約束影響，作為下一個階段的輸入。

3.3.2 CA階段

概念架構是對系統(tǒng)設計的最初構想，對大型系統(tǒng)的成功非常關鍵。

概念性架構定義了系統(tǒng)的高層組件，籠統(tǒng)地界定了高層組件的職責，以及它們之間的關系。

概念性架構主要是對系統(tǒng)進行適當?shù)姆纸?，而不陷入細?jié)。

概念性架構規(guī)定了每個組件的非正式規(guī)約及架構圖，但不涉及接口細節(jié)。

在進行概念架構設計時，必須牢牢抓住重大需求、特色需求、高風險需求，有針對性地確定解決方案。

關鍵需求塑造概念架構。反過來，概念架構體現(xiàn)關鍵需求。

此階段的輸入是關鍵需求，包括關鍵功能、關鍵質量屬性和關鍵約束影響，成果物是針對關鍵問題的解決策略，和以高層抽象組件方式描述的整個系統(tǒng)的組成草圖，可以用在《軟件方案建議書》。此成果物作為下一個階段的輸入。

3.3.3 RA階段

從概念架構到細化架構，先設計概念架構，構思關鍵問題的解決策略；再進行細化架構的設計，以保證為開發(fā)提供足夠的指導和限制。

在細化架構階段，整體設計思路為以分而治之為核心思想的多視圖方法。

此階段的輸入是關鍵問題的解決策略，和以高層抽象組件方式描述的整個系統(tǒng)的組成草圖，成果物是描述系統(tǒng)的各種視圖，這些視圖從不同的角度，不同的關注點，描述了抽象的、完整的系統(tǒng)解決方案。

3.4 軟件架構視圖

多視圖方法是業(yè)界廣泛認可的一種架構設計思路。

一種優(yōu)秀的多視圖方法，應該能夠比較完善地覆蓋架構設計的各項工作內容，并且將每項工作內容明確地、有理有據(jù)地、一目了然地劃歸到不同的架構視圖中去。

在多視圖方法中，每個視圖都從一個思維角度聚焦一組技術關注點，都從特定角度規(guī)劃系統(tǒng)的拆分和組合，都是架構的一種體現(xiàn)。

多視圖方法種類繁多，其中影響最大的當屬由Philippe Kruchten于1995年首次提出的RUP的4+1視圖方法，涉及視圖分別為邏輯架構視圖、運行架構視圖、開發(fā)架構視圖、數(shù)據(jù)架構視圖、物理架構視圖。

另一種在架構設計中經(jīng)常使用的多視圖方法是聯(lián)邦企業(yè)架構框架（Federal Enterprise Architecture Framework），涉及視圖分別為：業(yè)務架構視圖、數(shù)據(jù)架構視圖、應用架構視圖、技術架構視圖。

本人所使用的視圖方法是以RUP的4+1視圖方法和聯(lián)邦企業(yè)架構框架為基礎，基于本人在架構設計方面的實踐經(jīng)驗，總結出常用的6中架構視圖，涉及視圖為：業(yè)務架構視圖、數(shù)據(jù)架構視圖、應用架構視圖、技術架構視圖、物理架構視圖、開發(fā)架構視圖。

為了理論與實踐相結合，對于每種視圖的介紹放到架構設計實踐的細化架構階段，結合實際的項目，詳細描述每種視圖。

3.5 架構之間的關系

從根本上講，架構設計毫無疑問是需求驅動的。所以，軟件需求是整個軟件架構設計過程的前提條件。

在架構設計過程中，不同的架構視圖之間并不是孤立存在的，它們之間存在著依賴關系，并且這些依賴關系也決定了這些架構視圖的設計順序，具體如下：

1.第一步，根據(jù)用戶需求確定業(yè)務架構。

2.第二步，根據(jù)業(yè)務架構，分析、定義數(shù)據(jù)架構。

3.第三步，根據(jù)數(shù)據(jù)架構，并結合功能需求定義應用架構。

4.第四步，根據(jù)數(shù)據(jù)架構與應用架構來設計技術架構。

5.第五步，根據(jù)數(shù)據(jù)架構、應用架構和技術架構，來設計開發(fā)架構。

1、具有1-5工作經(jīng)驗的，面對目前流行的技術不知從何下手，

需要突破技術瓶頸的可以加。

2、在公司待久了，過得很安逸，

但跳槽時面試碰壁。

需要在短時間內進修、跳槽拿高薪的可以加。

3、如果沒有工作經(jīng)驗，但基礎非常扎實，對java工作機制，

常用設計思想，常用java開發(fā)框架掌握熟練的，可以加。

4、覺得自己很牛B，一般需求都能搞定。

但是所學的知識點沒有系統(tǒng)化，很難在技術領域繼續(xù)突破的可以加。

5. 群號：高級架構群 Java進階群：180705916.備注好信息！送架構視頻。

6.阿里Java高級大牛直播講解知識點，分享知識，

多年工作經(jīng)驗的梳理和總結，帶著大家全面、

科學地建立自己的技術體系和技術認知！