系統架構分析與設計方法論

 

 

 

1      什麼是架構

三要素：

一、  構件

二、  構件之間的關係

三、  構件與環境之間的關係

 

 

 

2      軟件架構原則

2.1      全面解耦原則

對業務進行抽象建模，業務數據與業務邏輯解耦，軟件和硬件解耦，平臺和產品解耦，系統各部件間解耦

• 什麼是系統的耦合性耦合性(Coupling)，也叫耦合度，是對系統模塊間依賴或關聯程度的度量。耦合的強弱取決與模塊間接口的複雜性、調用模塊的方式以及經過界面傳送數據的多少。模塊間依賴或聯繫越多，其耦合性越強，同時代表其獨立性越差。
• 系統耦合性的評估標準（耦合性依次從強到弱）
• （1）內容耦合: 當一個模塊直接修改或操做另外一個模塊的數據,或者直接轉入另外一個模塊時，就發生了內容耦合。此時，被修改的模塊徹底依賴於修改它的模塊。
• （2）公共耦合: 若一組模塊都訪問同一個公共數據環境，則它們之間的耦合就稱爲公共耦合。公共的數據環境能夠是全局數據結構、共享的通訊區、內存的公共覆蓋區等。
• （3）外部耦合: 一組模塊都訪問同一全局簡單變量而不是同一全局數據結構，並且不是經過參數表傳遞該全局變量的信息，則稱之爲外部耦合。
• （4）控制耦合: 一個模塊在界面上傳遞一個信號（如開關值、標誌量等）控制另外一個模塊，接收信號的模塊的動做根據信號值進行調整，稱爲控制耦合。
• （5）標記耦合: 模塊間經過參數傳遞複雜的內部數據結構，稱爲標記耦合。此數據結構的變化將使相關的模塊發生變化。
• （6）數據耦合: 模塊間經過參數傳遞基本類型的數據，稱爲數據耦合。
• （7）非直接耦合: 模塊間沒有信息傳遞時，屬於非直接耦合。
• 若是模塊間必須存在耦合，就儘可能使用數據耦合，少用控制耦合，限制公共耦合的範圍，堅定避免使用內容耦合。

 

2.2      服務化/組件化原則

以服務、數據爲中心，構建服務化、組件化架構，具有靈活、按需組合的能力

 

• 樂高式微服務組合，更適合快速變化業務
• 更小粒度擴縮，提高資源效率
• 良好的解耦顯著提高敏捷性
• 各微服務之間獨立開發、獨立發佈、獨立部署

 

2.3      接口隔離及服務自治原則

經過接口隱藏服務/組件的實現細節，服務/組件間只能經過接口進行交互，接口契約化、標準化，跨版本兼容；服務、組件可獨立發展、獨立發佈、獨立升級；服務自治，可視、可管、可控、可測、可維、故障自愈。

 

服務註冊

微服務A（Pod1,2,…） 經過K8s Service訪問到Service Center並進行註冊

微服務A訂閱微服務B~n，Service Center將現有微服務B~n的訪問列表返回給微服務A

服務動態調整自適應某個微服務有新的POD註冊上去以後，Service Center會主動推送給關聯微服務

服務訪問

A須要訪問B時，能夠直接根據 IP+Port訪問

服務註銷

微服務的Pod到Service Center註銷，並通知到關聯的微服務

 

2.4      彈性伸縮原則

構建全分佈式雲化架構，或借鑑雲化架構思想，每一個服務具有橫向擴展能力，支持按需使用、自動彈性伸縮，可動態替換、靈活部署，支撐高性能、高吞吐量、高併發、高可用業務場景

 

2.5      用戶體驗和自動化運維原則

 

面向業務獲取和使用場景，構建實時、按需、在線、自助、社區化、方便易用的用戶體驗；支持遠程、自動、智能、安全、高效地完成網規/網設、安裝、部署、調測、驗收、擴縮容、軟件升級、打補丁、平常維護、問題處理

 

2.6      開放生態原則

面向生態場景，按需開放平臺設施、中間件、數據、業務邏輯、UI等能力，構建開放生態，支持分層、遠程、自動、自助、簡單高效地完成定製、集成、第三方應用開發

 

2.7      高效開發原則

建立支持迭代、增量、持續交付的架構，支持部件獨立開發、自動化編譯構建、測試、集成驗證，並易於高效修改和持續優化；支持開發組織小型化、扁平化，支持小團隊獨立高效並行開發

 

2.8      安全可靠環保原則

• 構建最小權限、縱深防護、最小公共化、權限分離、不輕信、開放設計、徹底仲裁、失效安全、保護薄弱環節、安全機制經濟性、用戶接受度以及增強隱私保護的安全體系，確保系統、網絡和數據的機密性、完整性、可用性、可追溯；以業務系統零故障爲導向，按需構築分層分級的可靠性，經過故障的預測、預防、快速恢復，避免故障的發生；系統資源使用效率最大化，實現節能、節地、節材、環保

 

2.9      柔性供應制造原則

• 模塊化設計，模塊/物料歸一化、標準化，支持自動化、數字化、智能化、隨需應變的柔性製造

 

2.10   持續演進原則

• 架構並不是一蹴而就，須要有效地管理架構需求，持續構建和發展架構，適應業務需求變化，適時引入業界最佳實踐，及時重構，確保架構生命力和競爭力
• 因爲影響架構設計的各個質量屬性之間存在必定的聯繫和衝突，好比：高的性能需求會致使成本的上升，高的可靠性要求也會致使成本的上升，擴展性的提升可能會犧牲必定的性能，而可移植性好則會提高架構的可重用性等等。所以架構設計時必須對各個質量屬性的進行權衡，而權衡的依據就是架構設計的商業目標，包括：目標市場、架構的應用範圍、上市時間、成本和收益、生命週期、與老系統的集成、關鍵需求（質量屬性需求）、開發過程和約束等，只有肯定了商業目標才能肯定架構設計的方向並對各個相互衝突的質量屬性進行仲裁和權衡。
• 重用分爲幾個層次：架構重用、組件重用、設計重用、代碼重用。領域架構設計強調的是領域內架構的重用和基於架構的組件重用。架構重用包括：邏輯架構重用和物理架構重用，在可能的狀況下要儘可能擴大重用的範圍，特別是物理架構的重用，將帶來巨大的價值。
• 產品進行系統設計和實現時必須遵循重用原則，產品應用開發時，若是已有領域架構和平臺，則其系統設計必須符合領域架構，並應用平臺組件開發；若是無領域架構和平臺，則須要考慮如何構建領域架構和平臺爲後續相似產品的重用和共享作好準備。
• 目前大型通訊系統，其需求和規模是很是大的，它的實現通常都要分期分步進行，架構設計要可以支持平臺和產品分階段/增量式實現和交付的要求，具備較強的可修改性和可擴展性。分階段交付的版本之間要保持兼容性。

2.11   商業目標原則

2.12   重用原則

2.13   支持分階段交付原則

 

3      架構分析方法

3.1      領域需求

要點：

一、  收集需求

• 保證全面——儘可能收集；
• 識別重點；
• 深刻理解，瞭解客戶背後的聲音。

二、  定義環境與系統邊界

• 劃分系統邊界；
• 明確與已有系統的關係；
• 劃分大的解決方案下的多個系統之間的邊界。

 

三、  描述需求

四、   

3.2      領域分析的關鍵要點

建立領域分析模型

肯定分析模型的職責和接口

 

3.3      邏輯架構設計

3.3.1        邏輯架構的要點：

一、  需求包含：功能性需求+非功能性需求

二、  分層定義子系統

三、  定義可重用架構（公共機制、設計框架）

四、  關鍵流程演繹（模塊交互順序和操做、識別關鍵技術）

 

3.3.2        邏輯架構構件塊：DM（Deployable Module）

• DM -  Deployable Module
  • DM內部緊耦合，DM之間鬆耦合
  • DM具備明肯定義的接口和規格
  • DM是與實現無關的
  • DM是與物理位置無關的，能夠靈活部署的
• DM是構成設計階段設計模型的重要模型元素，因此DM也能夠稱爲設計模塊（Design Module）。做爲領域架構的基本組成單元，DM不只要可以知足部署的需求，還要
  • 實現架構層次的質量屬性
  • 達到架構重用的目的
  • 符合架構管理的要求
  • 能順利進入下一道工序: IM設計

 

TIPS：DM本質就是一個功能模塊，上述特徵決定它又不一樣於通常意義上的功能模塊。DM的規模也不是固定的，規模取決於須要，這包括架構描述的須要，質量屬性設計的須要，下一步設計和開發工做的須要，部署的須要，甚至架構管理的須要。

 

3.3.3        邏輯架構設計的通常方法

• 自頂向下，分而治之
  • 分平面：按制平面、管理平面、用戶平面/轉發平面/數據平面
  • 分層：層次模型、洋蔥模型
  • 分子系統
• 自底向上，抽象封裝
  • 從分析模型出發，或從現有產品模塊劃分的狀況出發，將小的功能塊（或對象）分組打包
• 通常狀況下是二者相結合
  • 經過自底向上的方法獲得DM
  • 將DM對應到合適的層或子系統

 

3.4      實現分析

3.5      物理架構實現