微服務架構設計實踐
目 次
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 開發架構
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於2023年首次提出的rup的4+1檢視方法，涉及檢視分別為邏輯架構檢視、執行架構檢視、開發架構檢視、資料架構檢視、物理架構檢視。
另一種在架構設計中經常使用的多檢視方法是聯邦企業架構框架（federal enterprise architecture framework），涉及檢視分別為：業務架構檢視、資料架構檢視、應用架構檢視、技術架構檢視。
本人所使用的檢視方法是以rup的4+1檢視方法和聯邦企業架構框架為基礎，基於本人在架構設計方面的實踐經驗，總結出常用的6中架構檢視，涉及檢視為：業務架構檢視、資料架構檢視、應用架構檢視、技術架構檢視、物理架構檢視、開發架構檢視。
為了理論與實踐相結合，對於每種檢視的介紹放到架構設計實踐的細化架構階段，結合實際的專案，詳細描述每種檢視。
3.5 架構之間的關係
從根本上講，架構設計毫無疑問是需求驅動的。所以，軟體需求是整個軟體架構設計過程的前提條件。
在架構設計過程中，不同的架構檢視之間並不是孤立存在的，它們之間存在著依賴關係，並且這些依賴關係也決定了這些架構檢視的設計順序，具體如下：
1.第一步，根據使用者需求確定業務架構。
2.第二步，根據業務架構，分析、定義資料架構。
3.第三步，根據資料架構，並結合功能需求定義應用架構。
4.第四步，根據資料架構與應用架構來設計技術架構。
5.第五步，根據資料架構、應用架構和技術架構，來設計開發架構。
微服務軟體架構設計
在軟體內部經過綜合各種因素考量 權衡，選擇特定的技術，將系統劃分為不同的部分並使用這些部分相互分工，彼此協作，為使用者提供需要的價值 軟體架構進化考慮的因素 傳統架構 單體架構 概念優勢 挑戰微服務架構 定義使用一套小服務來開發單個應用的方式，每個服務執行在單獨的程序，一般採用輕量級的通訊機制互聯，...
微服務架構設計實踐系列之一 序言
微服務架構設計實踐 目 次 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...
微服務架構設計模式綜述
隨著微服務的大量應用，在實踐中也會遇到很多之前單體架構所沒有的問題，微服務架構設計模式也應運而生。架構方面的權威chris richardson先生從多個角度歸納了42個設計模式，我將其歸納整理如下表，以饗讀者。後面會陸續出關於微服務架構設計模式的文章，更加深入的闡述richardson先生關於微服...