微服務架構設計實踐
微服務架構設計實踐
目 次
1 序言
2 微服務3 軟體架構設計思想4 微服務架構設計實踐
4.1 項目概述4.2 架構準備階段4.3 概念架構階段4.4 細化架構階段4.4.1 業務架構4.4.2 數據架構4.4.3 應用架構4.4.4 技術架構4.4.5 物理架構4.4.6 開發架構
1 序言
最近，在軟體架構設計領域，微服務非常火。
一提到軟體開發、架構設計，如果不提微服務，不說說微服務的架構風格，那就落伍了，OUT了。
當然了，支持微服務的技術也是層出不窮，如微服務1.0中比較有名的來自Spring家族的Spring Cloud，以及國內在開源領域的翹楚阿里系中的Dubbo。其中，Spring Cloud提供了完整的微服務解決方案，為開發者提供了快速構建分散式系統的通用模型的工具，包括配置管理、服務發現、熔斷器、智能路由、微代理、控制匯流排、一次性令牌、全局鎖、領導選舉、分散式會話、集羣狀態等。而Dubbo是一個分散式服務框架，致力於提供高性能和透明化的RPC遠程服務調用方案，以及服務治理方案。
隨著微服務的持續火熱，微服務2.0中的ServiceMesh也火起來了。Service Mesh，即「服務網格」，作為服務間通信的基礎設施層，Service Mesh可以被看作是微服務間的TCP/IP，負責服務之間的網路調用、限流、熔斷和監控。對於編寫服務的開發人員來說，一般無須關心TCP/IP這一層（比如通過 HTTP 協議的 RESTful 應用），同樣使用Service Mesh也就無須關心服務之間的那些原來是通過應用程序或者其他框架實現的事情，比如Spring Cloud、OSS，現在只要交給Service Mesh就可以了。
其實，上述說了那麼多，介紹了那麼多，基本都是集中在概念層面，在理論的層次上，以及支持微服務的開發技術、開發框架上，缺少這些概念、理論、技術和框架在實際項目中具體地應用。
對於大多數開發人員、架構師來說，除了理解微服務相關的概念，熟悉微服務相關的技術和框架，更關心如何在實際的項目中，應用這些概念、技術和框架。而這些，正是現在所欠缺的。
筆者從事軟體開發多年，參與和指導過多個項目的架構設計，經歷過單體架構、分散式架構、SOA架構，對軟體架構的發展歷史有一定的瞭解。
同時，在架構設計過程中，筆者也拜讀了多位架構大師的著作，如溫昱老師的《軟體架構設計》、《一級架構師》，Peter Eeles和Peter Cripps的《軟體架構設計的過程》等，以及各位技術大咖們在互聯網上分享的各類架構相關的文檔，使我受益匪淺。在此，我衷心的對這些前輩們表示由衷的感謝，謝謝你們對於知識的分享，以及無私奉獻的精神。
最近，筆者有幸參與了某銀行的一個採用微服務架構風格的項目，實踐了一下微服務架構。
更確切地說，該項目是分散式服務架構向微服務架構的演進，使用更細粒度的服務和一組設計準則來考慮大規模的、複雜的系統架構設計，並非一個純粹的微服務架構風格的項目。
秉著知識共享的精神，筆者寫了這篇「微服務架構設計實踐」的文章，一方面是對自己在架構設計方面的一個階段性總結，另一方面是希望給其他剛剛從事軟體架構設計的人員一個真實的、具體的軟體架構過程的實踐參考，為他們提供一個完整的實踐案例。
在寫這篇文章的過程中，在介紹微服務、軟體架構設計思想的概念、方法論時，引用了各位大師、技術大咖們關於微服務、架構設計的文章中的內容，在此衷心地表示感謝。對於引用的內容，筆者並非簡單地摘抄，而是結合筆者的理解和實踐，做了適當的調整。如果存在不適、錯誤的地方，希望各位及時地指出，我將積極的採納和修改。
2 微服務
2.1 微服務的定義
微服務是一個獨立、可部署的服務，它只專註做一件事情並且做好，而這個事情通常可以是業務能力，或者提供業務價值的最小單元服務。
微服務的描述具有一般服務描述所遵循的內容：
1.使用明確的介面方式，如：WebService、Rest。
2.描述裏應該包括約束和策略，如：參數、返回值，以及使用什麼通訊協議和數據格式等。
微服務中「微」是其獨特個性的體現，「微」表示「介面粒度細」。
簡而言之，微服務的特徵歸結為：
1.職責單一，相對獨立。
2.介面粒度細。
3.輕量級通訊協議。
4.服務之間松耦合。
2.2 微服務架構的定義
James Lewis 和 Martin Fowler 給微服務架構的定義如下：
微服務架構風格指將複雜系統切分為幾十甚至上百個小服務，每個服務負責實現一個獨立的業務邏輯。系統中的各個服務通常是獨立部署，彼此之間是松耦合的。
每個服務都運行在自己的進程中，一般採用Rest API風格的輕量級通訊協議進行相互通信。
這些服務圍繞業務功能進行構建，通過全自動化的部署方式來進行獨立部署。
這些服務可以使用不同的語言來編寫，也可以使用不同的數據存儲技術，並且基於最低限度的集中管理。
2.3 微服務架構的特徵
Martin Fowler 認為，微服務架構具有如下 9 個特性：
1.組件以服務的形式提供。
2.圍繞業務功能進行組織。
3.產品而不是項目。
4.強化終端與弱化管道。
5.「去中心化」 地治理技術。
6.「去中心化」 地管理數據。
7.「基礎設施」 自動化。
8.「容錯」 設計。
9.「演進式」 設計。
2.4 微服務架構的優缺點
微服務架構的優點在於：
1.更加徹底的組件化，系統內部各個組件之間解耦的比較乾脆，單個系統的規模小很多。
2.可以組建每個服務獨立的維護團隊，利於各自團隊獨立的開發和維護。
3.每個微服務獨立部署，只要服務間的介面穩定，各系統可以相互之間互不幹擾的獨立發展。
4.微服務架構使得每個服務本身可以獨立的擴展，性能出現瓶頸，優化或增加這個服務的配置即可。
微服務架構的缺點在於：
1.微服務強調了服務大小，但實際上，業界並沒有給出一個明確的、統一的標準。業務邏輯應該按照什麼規則劃分為微服務，這本身就是一個經驗工程。但要記住，微服務是達到目的的手段，而不是目標。微服務的目標是充分分解應用程序，以促進敏捷開發和持續集成部署。
2.它的分散式特點帶來的複雜性。開發人員需要基於RPC或者消息實現微服務之間的調用和通信，而這就使得服務之間的發現、服務調用鏈的跟蹤和質量問題變得的相當棘手。
微服務架構所面臨的挑戰：
1.分區的資料庫體系和分散式事務。在微服務架構下，不同服務可能擁有不同的資料庫。CAP原理的約束，使得我們不得不放棄傳統的強一致性，而轉而追求最終一致性，這個對開發人員來說是一個挑戰。
2.對測試帶來了很大的挑戰。對微服務進行測試，需要啟動它依賴的所有其他服務，這種複雜性不可低估。
3.對跨多個服務的更改帶來的挑戰。在微服務架構中，若有A、B、C三個服務需要更改，A依賴B，B依賴C。此時，我們需要仔細規劃和協調每個服務的變更部署，可能需要先更新C，然後更新B，最後更新A。
4.部署基於微服務的應用也要複雜得多。微服務由不同的大量服務構成，每種服務擁有自己的配置、應用實例數量以及基礎服務地址，這裡就需要不同的配置、部署、擴展和監控組件。此外，我們還需要服務發現機制，以便服務可以發現與其通信的其他服務的地址。因此，成功部署微服務應用需要開發人員有更好地部署策略和高度自動化的水平。
基於上述的微服務存在的優缺點，以及微服務架構設計過程中面臨的挑戰，建議在軟體架構設計時，不要從一開始就以微服務架構作為系統設計的起點。相反地，要用一個單個系統作為起點，並保持其模塊化。當這個系統出現了問題後，再將其分解為微服務。
3 軟體架構設計思想
3.1 軟體架構定義
對於軟體架構的定義，仁者見仁，智者見智。目前，業界比較流行的兩大流派是組成派和決策派，這兩派的概念相輔相成，具體如下：
組成派：軟體架構 = 組件 + 交互。
決策派：軟體架構 = 重要決策集。
上述兩大流派的描述過於抽象，不利於理解，本人更喜歡下述關於軟體架構的描述，通俗易懂，即：
軟體架構是軟體整體結構與組件的抽象描述，用於指導大型軟體系統各個方面的設計。軟體架構描述的對象是直接構成系統的抽象組件，各個組件之間的連接則明確和相對細緻地描述組件之間的通訊。在實現階段，這些抽象組件被細化為實際的組件，比如具體某個類或者對象。在面向對象領域中，組件之間的連接通常用介面來實現。
軟體架構是一個用於指導系統實現的草圖，這個草圖越詳細對於系統實現的指導意義越重大，貫穿於軟體的整個生命週期。
3.2 軟體架構本質
架構的本質就是對系統進行有序化重構，不斷減少系統無序的程度，使系統不斷進化。
架構從無序到有序的基本實現手段是分和合，即先把系統打散，然後重新組合。
分的過程是把系統拆分為各個子系統、模塊、組件。拆分的時候，首先要解決每個組件的定位問題，然後才能劃分彼此的邊界，實現合理的拆分。合的過程就是根據最終要求，把各個分離的組件有機整合在一起。
分的結果使開發人員能夠做到業務聚焦、技能聚焦，實現開發敏捷；
合的結果使系統變得柔性，可以因需而變，實現業務敏捷。
相對來說，第一步的拆分更難。
3.3 軟體架構過程
在此次軟體架構設計過程中，採用了溫昱老師在《軟體架構設計》一書中提及的ADMEMS方法體系。
ADMEMS方法通過3個階段和一個貫穿環節，來覆蓋「需求進，架構出」的完整架構設計過程。
3.3.1 PA階段
架構準備階段是架構設計的第一個階段，此階段的工作目標是：理解需求，建立需求大局觀，確定架構設計方向等。
功能需求、質量屬性和約束共同決定了架構，對這3類需求的把握是否到位、設計決策是否對路，是軟體架構設計的關鍵所在。
如果可能的話，架構師應該儘早的參與需求分析工作，對需求進行大局的梳理，而不能被動地等待《軟體需求規格說明書》的完成。
只要滿足以下3個條件，架構師就可以開始架構設計工作：
1.明確的業務需求：甲、乙雙方對系統的目標達成共識，《願景文檔》通過了正式評審，並且明確了投資、工期標準、整合等約束條件。
2.全面的用戶需求：系統範圍明確，即系統能幫用戶幹什麼，不能幹什麼。
3.典型的行為需求：核心功能的《用例規約》已定義。
在架構準備階段，通過對軟體需求的詳細分析，抽取出確定概念性架構所需要的關鍵需求。
此階段的輸入是軟體需求（即上述的三部分：明確的業務需求、全面的用戶需求、典型的行為需求），成果物是確定的關鍵需求，包括關鍵功能、關鍵質量屬性和關鍵約束影響，作為下一個階段的輸入。
3.3.2 CA階段
概念架構是對系統設計的最初構想，對大型系統的成功非常關鍵。
概念性架構定義了系統的高層組件，籠統地界定了高層組件的職責，以及它們之間的關係。
概念性架構主要是對系統進行適當的分解，而不陷入細節。
概念性架構規定了每個組件的非正式規約及架構圖，但不涉及介面細節。
在進行概念架構設計時，必須牢牢抓住重大需求、特色需求、高風險需求，有針對性地確定解決方案。
關鍵需求塑造概念架構。反過來，概念架構體現關鍵需求。
此階段的輸入是關鍵需求，包括關鍵功能、關鍵質量屬性和關鍵約束影響，成果物是針對關鍵問題的解決策略，和以高層抽象組件方式描述的整個系統的組成草圖，可以用在《軟體方案建議書》。此成果物作為下一個階段的輸入。
3.3.3 RA階段
從概念架構到細化架構，先設計概念架構，構思關鍵問題的解決策略；再進行細化架構的設計，以保證為開發提供足夠的指導和限制。
在細化架構階段，整體設計思路為以分而治之為核心思想的多視圖方法。
此階段的輸入是關鍵問題的解決策略，和以高層抽象組件方式描述的整個系統的組成草圖，成果物是描述系統的各種視圖，這些視圖從不同的角度，不同的關注點，描述了抽象的、完整的系統解決方案。
3.4 軟體架構視圖
多視圖方法是業界廣泛認可的一種架構設計思路。
一種優秀的多視圖方法，應該能夠比較完善地覆蓋架構設計的各項工作內容，並且將每項工作內容明確地、有理有據地、一目瞭然地劃歸到不同的架構視圖中去。
在多視圖方法中，每個視圖都從一個思維角度聚焦一組技術關注點，都從特定角度規劃系統的拆分和組合，都是架構的一種體現。
多視圖方法種類繁多，其中影響最大的當屬由Philippe Kruchten於1995年首次提出的RUP的4+1視圖方法，涉及視圖分別為邏輯架構視圖、運行架構視圖、開發架構視圖、數據架構視圖、物理架構視圖。
另一種在架構設計中經常使用的多視圖方法是聯邦企業架構框架（Federal Enterprise Architecture Framework），涉及視圖分別為：業務架構視圖、數據架構視圖、應用架構視圖、技術架構視圖。
本人所使用的視圖方法是以RUP的4+1視圖方法和聯邦企業架構框架為基礎，基於本人在架構設計方面的實踐經驗，總結出常用的6中架構視圖，涉及視圖為：業務架構視圖、數據架構視圖、應用架構視圖、技術架構視圖、物理架構視圖、開發架構視圖。
為了理論與實踐相結合，對於每種視圖的介紹放到架構設計實踐的細化架構階段，結合實際的項目，詳細描述每種視圖。
3.5 架構之間的關係
從根本上講，架構設計毫無疑問是需求驅動的。所以，軟體需求是整個軟體架構設計過程的前提條件。
在架構設計過程中，不同的架構視圖之間並不是孤立存在的，它們之間存在著依賴關係，並且這些依賴關係也決定了這些架構視圖的設計順序，具體如下：
1.第一步，根據用戶需求確定業務架構。
2.第二步，根據業務架構，分析、定義數據架構。
3.第三步，根據數據架構，並結合功能需求定義應用架構。
4.第四步，根據數據架構與應用架構來設計技術架構。
5.第五步，根據數據架構、應用架構和技術架構，來設計開發架構。
4 微服務架構設計實踐
4.1 項目概述
為了支持分行特色業務在某銀行科技總體架構下高效、規範實施，總行構建了分行特色業務雲平臺，旨在為分行應用提供全面、易用、統一、安全可靠的服務能力，包括業務能力和技術能力，降低對於總行產品模塊的接入難度，整體控制接入風險，同時整合、集成總行服務能力。
分行特色業務雲平臺是一套以總分協同、共享服務體系架構的分行特色業務開發平臺。該平臺基於行方自主研發的Tesla基礎技術框架，實現全分行統一、規範技術支撐架構，為分行應用提供全面、易用、安全可靠的服務。以此為基石，更深、更廣泛的發揮全分行科技人員開發能力和對業務支持響應能力。
此次設計的分行特色業務雲平臺以Tesla平臺作為技術載體，採用分散式服務框架理論作為設計依據，在此基礎上，構建JAVA版特色業務分平臺（JCAP-Java Cloud Application Platform）、服務融合中心（SCC-Service Convergence Center）。
服務融合中心在本次分行特色業務平臺的定位是對分行特色業務提供各種總行後臺模塊的服務能力，並且對分行特色業務的接入做到統一管理和差異化控制功能。
後續的會為大家慢慢補上，努力學習，做一名棟樑之才。
想了解可以私信我！
1 SpringBoot+ 高並發消息處理 EDM?項目 實戰
2 SpringBoot ELK?分散式 數據分析
3 Netty?高 並發 UTS?項目實戰
4 SpringCloud?微服務+NoSQL+ 負載均衡平臺設計
推薦閱讀：
