對于架構設計人們已經提出了許多方法，分類為：工件驅動的方法；用例驅動的法；模式驅動的方法；領域驅動的方法。一個經典的架構設計過程模型，沿用了RUP中迭代增量的思想，由分析、描述、選擇、構造和組合5個階段組成。

依據需求規格說明書分析出功能需求和架構需求，通過用例和場景的描述，把需求分為關鍵的，次要的和可選的3類。關鍵需求決定架構，結合軟件架構風格和通用知識選擇最關鍵、影響最大的子系統分析設計并產生構件。組合就是定義構件接口，構件作為一個封閉的功能實體，對外提供交互接口，并通過連接件將構件連接起來形成最終的軟件架構描述。5個階段是不斷迭代的過程，在每一次迭代中，都選取并實現一組用例和場景來確認并完善架構。

這個過程模型看似很流暢，但是，架構師在設計時很難把握他的正確性和精準性，而且用它架構的系統是否對后續設計開發形成一種原則上的指導是很難說的。但是對于架構師來說有些思路可以進行參考，大致將架構思維可以分為：分解、集成、分離、復用、分層、模式、抽象、結構化、迭代、勿做過度設計這幾部分，按照這個思維方式來設計系統架構。

分而治之是一種處理復雜問題的通用方法，在系統架構中也是一種很重要的手段，例如多層架構、OSI?七層模型都體現了分而治之思想。在架構設計過程中，通過將關注點分離對架構進行多層次分解，將系統層層分解為多個架構元素，進而識別架構元素。同時保證分解后的各個部分還能夠高內聚，松耦合，最終又集成為一個完整的整體。分解核心是定義問題，因此架構首先仍然需要理解清楚需求。

分解的作用：

?? ???1、應用層：按照功能或者微服務進行分解，將系統劃分未若干子系統， 低耦合存在，在業務角度可以將單個應用獨立為應用單元（應用單元是無狀態的），這樣可以靈活地進行伸縮。

?? ???2、數據層：對數據庫進行垂直拆分按照子系統緯度進行分庫和水平拆分按照業務緯度進行分表；但是進行分庫分表中要避免分布式事務，實在無法避免可利用消息系統來進行規避。

?? ???3、代碼結構層：代碼層一般分為三層，從下至上分別為：數據訪問層、業務邏輯層（又或稱為領域層）、表示層。這也是Java?Web中重要的三層架構中的三個層次。區分層次的目的即為了“高內聚低耦合”的思想。

?????? 分解的原則：

?????? 業務原則：

??? 單一責任原則：對于一個微服務而言，具有有限的業務范圍，可以幫助我們滿足服務開發和交付的敏捷性；

適當的邊界：關注微服務的功能范圍，一個服務的大小應該等于滿足某個特定業務能力所需要的大小；

業務分層：?從整體規劃上把業務分層，形成單向依賴，避免微服務之間的網狀依賴關系；

顆粒度遞增：設計初期先把業務劃分到盡可能細，然后依據其它原則合并到適當顆粒度；

非唯一依賴：至少被2個以上其它微服務依賴的功能模塊，才有必要獨立成一個微服務。

技術原則：

部署獨立性：能獨立于其它微服務部署，一個微服務故障不影響其它微服務；

動態擴展：每個微服務都可以動態的進行x軸和z軸的擴展，并適應云環境下的自動化部署；（?參考這里?）

領域和應用解耦：提供數據操作能力的領域服務和執行業務邏輯的應用服務解耦；

避免產生頻繁的跨庫查詢；

避免產生頻繁的分布式事務。

治理原則：

在業務分層的基礎上，根據業務細分規則，對微服務分組；

各個分組之間通過API網關集成；

通過API網關實現級輕量級消息路由，鑒權；

運行時管理，如服務降級，限流，監控等可在API網關實現，讓微服務功能純粹；

避免通過數據庫集成；

避免部署多個版本來兼容。

轉載于:https://www.cnblogs.com/DaisyYuanyq/p/11056077.html

總結

以上是生活随笔為你收集整理的云时代架构阅读笔记十五——架构设计思维（一）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。