這篇文章講述了架構設計的思維是怎樣的，對我這學期的軟體體系架構有了乙個概括的描述。乙個經典的架構設計過程模型，沿用了rup中迭代增量的思想，由分析、描述、選擇、構造和組合5個階段組成，如圖：
這個過程模型看似很流暢，但是，架構師在設計時很難把握他的正確性和精準性，而且用它架構的系統是否對後續設計開發形成一種原則上的指導是很難說的。但是對於架構師來說有些思路可以進行參考，大致將架構思維可以分為：分解、整合、分離、復用、分層、模式、抽象、結構化、迭代、勿做過度設計這幾部分，按照這個思維方式來設計系統架構。作者先介紹了分解的架構方法。
架構分解的作用：架構分解是架構師接到需求到完成架構設計中最關鍵的一步，分解可以幫助架構師了解需求中未呈現出來的隱性需求要素，分解也是架構師解決非功能層面需求的重要手段，架構要解決高效能、高可用、伸縮性、可擴充套件性等問題，
分解的原則
（1）業務原則
單一責任原則：對於乙個微服務而言，具有有限的業務範圍，可以幫助我們滿足服務開發和交付的敏捷性；
適當的邊界：關注微服務的功能範圍，乙個服務的大小應該等於滿足某個特定業務能力所需要的大小；
業務分層： 從整體規劃上把業務分層，形成單向依賴，避免微服務之間的網狀依賴關係；
顆粒度遞增：設計初期先把業務劃分到盡可能細，然後依據其它原則合併到適當顆粒度；
非唯一依賴：至少被2個以上其它微服務依賴的功能模組，才有必要獨立成乙個微服務。
（2）技術原則
部署獨立性：能獨立於其它微服務部署，乙個微服務故障不影響其它微服務；動態擴充套件：每個微服務都可以動態的進行x軸和z軸的擴充套件，並適應雲環境
領域和應用解耦：提供資料操作能力的領域服務和執行業務邏輯的應用服務解耦；
避免產生頻繁的跨庫查詢；
避免產生頻繁的分布式事務。
（3）治理原則
在業務分層的基礎上，根據業務細分規則，對微服務分組；
各個分組之間通過api閘道器整合；
通過api閘道器實現級輕量級訊息路由，鑑權；
執行時管理，如服務降級，限流，監控等可在api閘道器實現，讓微服務功能純粹；
避免通過資料庫整合；
避免部署多個版本來相容。
3.架構分解
架構分解過程如下圖所示，是乙個迭代的模型。通過這個迭代的分解，從無到有、從粗到細、從模糊到清晰，一步步精（細）化、豐富架構。迭代的過程也是乙個否定之否定的過程，隨著分解的逐步推進或系統的架構演化，後面的分解除了會識別出隱性需求，也可能會對先前識別出的架構作出調整。
4.分解維度
架構分解就是從多個維度多層次對系統進行分解，識別出架構元素，逐步精化、豐富系統架構的過程。從上面可以總結出，緯度大致有，業務緯度、業務功能緯度、技術緯度，涉眾緯度。
5.分解力度
多維度多層次分解到什麼粒度才停止？這個沒有統一的標準，通常要能進行並行開發，能指導後續的詳細設計。需要根據具體的產品或專案來定，有的到模組級別就行，對關鍵的部分，可以到類級別。
6.分解時機
架構分解的時機通常就是架構改造演化的時機。當架構出現腐化和臭味，已經難以滿足關鍵涉眾的關鍵需求，例如使用者的響應速度越來越慢已經接近臨界值，並且根據預見，響應速度還有可能繼續較低；開發人員越來越難以維護，這個時候可以考慮進行架構演化，對架構進行改造。當然如果能提前預見系統的問題，經過慎重評估後，在問題發生之前，提前一段時間進行架構演化也是可以的。
分解作為架構設計中關鍵的步驟，這片問斬更是我了解的架構分解的作用，原則，維度，分解時機。讓我感覺到系統架構還是比較難的，並且需要長時間的時間類積累這些經驗並且把他們應用在專案之中。
讀《架構漫談一》有感
架構漫談 一 什麼是架構？1.我的目的 我看架構漫談的目的是通過架構幫助我解決如何看懂一本書，如何看懂乙個概念並非是通過它來解決如何設計軟體架構 企業架構 架構等 這些問題，但通過看這篇文章也讓我得到了除了我的目的之外的一些知識，進一步擴張了我的思維方式，讓我從更抽象更高的層次去考慮如何解決自己不僅...
架構設計有感
架構是乙個很直覺化的概念，理解的反差會讓設計變得大相徑庭。架構設計者 不一定是架構師 對系統的把握 認知和控制力會極大的影響系統開發的走勢。需求分析，功能分拆，技術選型，人員控制，規模 進度和質量控制等都是架構設計者的任務，穩定安全，高效 可擴充套件 可維護 優秀的使用者體驗是架構設計的基本目標。不...
寫架構設計文件有感
前段時間寫了篇架構設計文件，一直想就這件事聊點什麼，結果一拖就拖到現在了。算起來這是我第二次寫架構設計文件了。一路摸爬滾打，算是有一點點領悟，也不知道對不對，就隨便說說。很多人覺得架構文件沒有什麼寫的，或者說不知道要怎麼寫。其實我覺得這是因為自己對架構 或者對業務需求並不是那麼理解。如果真的理解了，...