微服務(wù)架構(gòu)設(shè)計實踐

目 次

1 序言

2 微服務(wù)

3 軟件架構(gòu)設(shè)計思想

4 微服務(wù)架構(gòu)設(shè)計實踐

4.1 項目概述

4.2 架構(gòu)準備階段

4.3 概念架構(gòu)階段

4.4 細化架構(gòu)階段

4.4.1 業(yè)務(wù)架構(gòu)

4.4.2 數(shù)據(jù)架構(gòu)

4.4.3 應(yīng)用架構(gòu)

4.4.4 技術(shù)架構(gòu)

4.4.5 物理架構(gòu)

4.4.6 開發(fā)架構(gòu)

1 序言

最近薇芝，在軟件架構(gòu)設(shè)計領(lǐng)域妈拌，微服務(wù)非称妓。火书聚。

一提到軟件開發(fā)、架構(gòu)設(shè)計低缩，如果不提微服務(wù)堪旧，不說說微服務(wù)的架構(gòu)風(fēng)格，那就落伍了才睹，OUT了徘跪。

當然了，支持微服務(wù)的技術(shù)也是層出不窮琅攘，如微服務(wù)1.0中比較有名的來自Spring家族的Spring Cloud垮庐，以及國內(nèi)在開源領(lǐng)域的翹楚阿里系中的Dubbo。其中坞琴，Spring Cloud提供了完整的微服務(wù)解決方案哨查，為開發(fā)者提供了快速構(gòu)建分布式系統(tǒng)的通用模型的工具，包括配置管理剧辐、服務(wù)發(fā)現(xiàn)寒亥、熔斷器、智能路由荧关、微代理溉奕、控制總線、一次性令牌忍啤、全局鎖腐宋、領(lǐng)導(dǎo)選舉、分布式會話檀轨、集群狀態(tài)等胸竞。而Dubbo是一個分布式服務(wù)框架，致力于提供高性能和透明化的RPC遠程服務(wù)調(diào)用方案参萄，以及服務(wù)治理方案卫枝。

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

其實讹语，上述說了那么多，介紹了那么多蜂科，基本都是集中在概念層面顽决，在理論的層次上，以及支持微服務(wù)的開發(fā)技術(shù)导匣、開發(fā)框架上才菠，缺少這些概念、理論逐抑、技術(shù)和框架在實際項目中具體地應(yīng)用鸠儿。

對于大多數(shù)開發(fā)人員、架構(gòu)師來說厕氨，除了理解微服務(wù)相關(guān)的概念进每，熟悉微服務(wù)相關(guān)的技術(shù)和框架，更關(guān)心如何在實際的項目中命斧，應(yīng)用這些概念田晚、技術(shù)和框架。而這些国葬，正是現(xiàn)在所欠缺的贤徒。

筆者從事軟件開發(fā)多年，參與和指導(dǎo)過多個項目的架構(gòu)設(shè)計汇四，經(jīng)歷過單體架構(gòu)接奈、分布式架構(gòu)、SOA架構(gòu)通孽，對軟件架構(gòu)的發(fā)展歷史有一定的了解序宦。

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

最近城菊，筆者有幸參與了某銀行的一個采用微服務(wù)架構(gòu)風(fēng)格的項目备燃，實踐了一下微服務(wù)架構(gòu)碉克。

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

秉著知識共享的精神撕贞，筆者寫了這篇“微服務(wù)架構(gòu)設(shè)計實踐”的文章，一方面是對自己在架構(gòu)設(shè)計方面的一個階段性總結(jié)测垛，另一方面是希望給其他剛剛從事軟件架構(gòu)設(shè)計的人員一個真實的捏膨、具體的軟件架構(gòu)過程的實踐參考，為他們提供一個完整的實踐案例食侮。

在寫這篇文章的過程中号涯，在介紹微服務(wù)、軟件架構(gòu)設(shè)計思想的概念锯七、方法論時链快，引用了各位大師、技術(shù)大咖們關(guān)于微服務(wù)眉尸、架構(gòu)設(shè)計的文章中的內(nèi)容域蜗，在此衷心地表示感謝。對于引用的內(nèi)容噪猾，筆者并非簡單地摘抄霉祸，而是結(jié)合筆者的理解和實踐，做了適當?shù)恼{(diào)整袱蜡。如果存在不適丝蹭、錯誤的地方，希望各位及時地指出戒劫，我將積極的采納和修改半夷。

2 微服務(wù)

2.1 微服務(wù)的定義

微服務(wù)是一個獨立、可部署的服務(wù)迅细，它只專注做一件事情并且做好巫橄，而這個事情通常可以是業(yè)務(wù)能力茵典，或者提供業(yè)務(wù)價值的最小單元服務(wù)湘换。

微服務(wù)的描述具有一般服務(wù)描述所遵循的內(nèi)容：

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

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

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

簡而言之岸夯，微服務(wù)的特征歸結(jié)為：

1.職責(zé)單一，相對獨立们妥。

2.接口粒度細猜扮。

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

4.服務(wù)之間松耦合监婶。

2.2 微服務(wù)架構(gòu)的定義

James Lewis 和 Martin Fowler 給微服務(wù)架構(gòu)的定義如下：

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

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

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

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

2.3 微服務(wù)架構(gòu)的特征

Martin Fowler 認為雷绢，微服務(wù)架構(gòu)具有如下 9 個特性：

1.組件以服務(wù)的形式提供泛烙。

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

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

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

5.“去中心化” 地治理技術(shù)。

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

7.“基礎(chǔ)設(shè)施” 自動化鹉究。

8.“容錯” 設(shè)計。

9.“演進式” 設(shè)計踪宠。

2.4 微服務(wù)架構(gòu)的優(yōu)缺點

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

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

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

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

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

微服務(wù)架構(gòu)的缺點在于：

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

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

微服務(wù)架構(gòu)所面臨的挑戰(zhàn)：

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

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

3.對跨多個服務(wù)的更改帶來的挑戰(zhàn)。在微服務(wù)架構(gòu)中吟策，若有A儒士、B、C三個服務(wù)需要更改踊挠，A依賴B乍桂，B依賴C冲杀。此時，我們需要仔細規(guī)劃和協(xié)調(diào)每個服務(wù)的變更部署睹酌，可能需要先更新C权谁，然后更新B，最后更新A憋沿。

4.部署基于微服務(wù)的應(yīng)用也要復(fù)雜得多旺芽。微服務(wù)由不同的大量服務(wù)構(gòu)成，每種服務(wù)擁有自己的配置辐啄、應(yīng)用實例數(shù)量以及基礎(chǔ)服務(wù)地址采章，這里就需要不同的配置、部署壶辜、擴展和監(jiān)控組件悯舟。此外，我們還需要服務(wù)發(fā)現(xiàn)機制砸民，以便服務(wù)可以發(fā)現(xiàn)與其通信的其他服務(wù)的地址抵怎。因此，成功部署微服務(wù)應(yīng)用需要開發(fā)人員有更好地部署策略和高度自動化的水平岭参。

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

3 軟件架構(gòu)設(shè)計思想

3.1 軟件架構(gòu)定義

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

組成派：軟件架構(gòu) = 組件 + 交互中鼠。

決策派：軟件架構(gòu) = 重要決策集。

上述兩大流派的描述過于抽象沿癞，不利于理解援雇，本人更喜歡下述關(guān)于軟件架構(gòu)的描述，通俗易懂椎扬，即：

軟件架構(gòu)是軟件整體結(jié)構(gòu)與組件的抽象描述惫搏，用于指導(dǎo)大型軟件系統(tǒng)各個方面的設(shè)計具温。軟件架構(gòu)描述的對象是直接構(gòu)成系統(tǒng)的抽象組件，各個組件之間的連接則明確和相對細致地描述組件之間的通訊筐赔。在實現(xiàn)階段铣猩，這些抽象組件被細化為實際的組件，比如具體某個類或者對象茴丰。在面向?qū)ο箢I(lǐng)域中达皿，組件之間的連接通常用接口來實現(xiàn)。

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

3.2 軟件架構(gòu)本質(zhì)

架構(gòu)的本質(zhì)就是對系統(tǒng)進行有序化重構(gòu)汰规，不斷減少系統(tǒng)無序的程度汤功，使系統(tǒng)不斷進化。

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

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

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

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

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

3.3 軟件架構(gòu)過程

在此次軟件架構(gòu)設(shè)計過程中姨伟，采用了溫昱老師在《軟件架構(gòu)設(shè)計》一書中提及的ADMEMS方法體系惩琉。

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

3.3.1 PA階段

架構(gòu)準備階段是架構(gòu)設(shè)計的第一個階段良蒸，此階段的工作目標是：理解需求，建立需求大局觀伍玖，確定架構(gòu)設(shè)計方向等诚啃。

功能需求、質(zhì)量屬性和約束共同決定了架構(gòu)私沮，對這3類需求的把握是否到位始赎、設(shè)計決策是否對路，是軟件架構(gòu)設(shè)計的關(guān)鍵所在仔燕。

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

只要滿足以下3個條件，架構(gòu)師就可以開始架構(gòu)設(shè)計工作：

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

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

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

在架構(gòu)準備階段癣疟，通過對軟件需求的詳細分析，抽取出確定概念性架構(gòu)所需要的關(guān)鍵需求潮酒。

此階段的輸入是軟件需求（即上述的三部分：明確的業(yè)務(wù)需求睛挚、全面的用戶需求、典型的行為需求）急黎，成果物是確定的關(guān)鍵需求扎狱，包括關(guān)鍵功能、關(guān)鍵質(zhì)量屬性和關(guān)鍵約束影響叁熔，作為下一個階段的輸入委乌。

3.3.2 CA階段

概念架構(gòu)是對系統(tǒng)設(shè)計的最初構(gòu)想，對大型系統(tǒng)的成功非常關(guān)鍵荣回。

概念性架構(gòu)定義了系統(tǒng)的高層組件遭贸，籠統(tǒng)地界定了高層組件的職責(zé)，以及它們之間的關(guān)系心软。

概念性架構(gòu)主要是對系統(tǒng)進行適當?shù)姆纸夂敬担幌萑爰毠?jié)著蛙。

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

在進行概念架構(gòu)設(shè)計時踏堡，必須牢牢抓住重大需求、特色需求咒劲、高風(fēng)險需求顷蟆，有針對性地確定解決方案。

關(guān)鍵需求塑造概念架構(gòu)腐魂。反過來帐偎，概念架構(gòu)體現(xiàn)關(guān)鍵需求。

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

3.3.3 RA階段

從概念架構(gòu)到細化架構(gòu)迅脐，先設(shè)計概念架構(gòu)，構(gòu)思關(guān)鍵問題的解決策略擂红；再進行細化架構(gòu)的設(shè)計仪际，以保證為開發(fā)提供足夠的指導(dǎo)和限制。

在細化架構(gòu)階段昵骤，整體設(shè)計思路為以分而治之為核心思想的多視圖方法。

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

3.4 軟件架構(gòu)視圖

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

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

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

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

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

本人所使用的視圖方法是以RUP的4+1視圖方法和聯(lián)邦企業(yè)架構(gòu)框架為基礎(chǔ)彻况，基于本人在架構(gòu)設(shè)計方面的實踐經(jīng)驗，總結(jié)出常用的6中架構(gòu)視圖舅踪，涉及視圖為：業(yè)務(wù)架構(gòu)視圖纽甘、數(shù)據(jù)架構(gòu)視圖、應(yīng)用架構(gòu)視圖抽碌、技術(shù)架構(gòu)視圖悍赢、物理架構(gòu)視圖、開發(fā)架構(gòu)視圖货徙。

為了理論與實踐相結(jié)合左权，對于每種視圖的介紹放到架構(gòu)設(shè)計實踐的細化架構(gòu)階段，結(jié)合實際的項目痴颊，詳細描述每種視圖赏迟。

3.5 架構(gòu)之間的關(guān)系

從根本上講，架構(gòu)設(shè)計毫無疑問是需求驅(qū)動的蠢棱。所以锌杀，軟件需求是整個軟件架構(gòu)設(shè)計過程的前提條件。

在架構(gòu)設(shè)計過程中泻仙，不同的架構(gòu)視圖之間并不是孤立存在的糕再，它們之間存在著依賴關(guān)系，并且這些依賴關(guān)系也決定了這些架構(gòu)視圖的設(shè)計順序玉转，具體如下：

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

2.第二步，根據(jù)業(yè)務(wù)架構(gòu)蒿柳，分析饶套、定義數(shù)據(jù)架構(gòu)。

3.第三步垒探，根據(jù)數(shù)據(jù)架構(gòu)妓蛮，并結(jié)合功能需求定義應(yīng)用架構(gòu)。

4.第四步圾叼，根據(jù)數(shù)據(jù)架構(gòu)與應(yīng)用架構(gòu)來設(shè)計技術(shù)架構(gòu)蛤克。

5.第五步，根據(jù)數(shù)據(jù)架構(gòu)夷蚊、應(yīng)用架構(gòu)和技術(shù)架構(gòu)构挤，來設(shè)計開發(fā)架構(gòu)。

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

需要突破技術(shù)瓶頸的可以加箱歧。

2矾飞、在公司待久了，過得很安逸呀邢，

但跳槽時面試碰壁洒沦。

需要在短時間內(nèi)進修、跳槽拿高薪的可以加价淌。

3申眼、如果沒有工作經(jīng)驗，但基礎(chǔ)非常扎實蝉衣，對java工作機制括尸，

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

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

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

5. 群號：高級架構(gòu)群 Java進階群：180705916.備注好信息！送架構(gòu)視頻似嗤。

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

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

科學(xué)地建立自己的技術(shù)體系和技術(shù)認知！