系統架構之感想
時下軟件界，架構界吹起了微服務之風，軟件從傳統的CS到BS，從單體到多服務器，再到現在的微服務；很多夥伴們也跟着技術潮流越來越多的在關注和學些或使用微服務解決項目中遇到的很多問題。本人也在軟件行業20來年了，所謂活到老學到老，從軟件開發，到軟件設計，到軟件架構，種種心路歷歷在目。不過現在我要說的並不是我自己的從業經歷，而是我最近在架構方面的學習和領悟所感分享給大家。
架構定義：
軟件架構是一個用於指導系統實現的草圖，草圖包括架構圖和設計文檔，草圖越詳細對系統實現的指導意義就越重要，且貫穿於軟件的整個生命週期。
軟件生命週期中架構設計的體現：
設計期：架構設計是重中之重。需求導向，架構先行。具體工作包括：系統拆分，技術選型，技術驗證，接口規範，集成方式，技術規範，部署方案，運維方案等等。
實現期：確保各項技術規範和技術指標的執行落地，保障高質量的代碼；指導研發任意和解決各類技術問題，提高研發團隊效率；制定測試的技術性方案，包括自動化、性能、安全等方面；配合準備部署環境，運維實施方案落地。
運行期：發佈上線相關基礎工作，包括是否使用持續集成，自動化發佈等技術；運維基礎性工作，自動化運維、監控等相關技術。
架構的目標和方法：
目標：可控性與拆分；複用性與抽象；非功能性需求九維目標：高性能，可靠性，穩定性，可用性，安全性，靈活性，易用性，可擴展性，可維護性。
方法：4+1視圖模型。用例視圖或叫場景視圖（用例圖）；邏輯視圖（類圖，交互圖，時序圖）；開發視圖（組件圖和包圖）；進程視圖（活動圖）；物理視圖（部署視圖）
架構風格發展：
單體架構：整個系統的所有功能單元部署到同一個進程中。可以分爲：
簡單單體模式：代碼層面沒有拆分，所有業務邏輯都在一個項目中。
MVC模式：按職責劃分爲模型（Model）視圖（View）控制器（Controller）
前後端分離：前端邏輯和後端邏輯獨立編寫。
組件模式：系統每一個模塊拆分爲一個子項目。
類庫模式：把被依賴系統作爲組件庫，打包到當前系統使用
分佈式架構：
面向服務架構（Service Oriented Architecture）：通過講業務系統服務化將不同模塊解耦；落地方式分爲：分佈式服務化（Dubbo），集中式管理化（OpenESB）；兩大基石：RPC（RR請求響應模式，OneWay單向調用模式，Futrue異步模式，Callback回調模式）和MQ（點對點和發佈訂閱模式）。
微服務架構（Micro Services Architecture）：由一些獨立的服務共同組成系統；每個服務單獨部署、獨立運行在自己的進程中；每個服務是獨立的業務；分佈式管理。
SOA和MSA的區別：微服務是一種經過良好架構設計的SOA解決方案，是面向服務的交付方案；微服務更趨向於以自治的方式長生價值；微服務與敏捷開發思想高度結合在一起，服務的定義更加清晰，同時減少了企業ESB開發的複雜性；微服務是SOA思想的一種提煉；SOA是重ESB，微服務是輕網關。
微服務面臨的問題：防止雪崩（請求壓力大限流）；功能降級（故障時有容錯手段保障整體應用）；冪等（多次下同一訂單結果永遠同一個）；緩存（變化小讀取量大的數據）；超時；熔斷（下游失敗產生一定概率後熔斷開啓直接返回失敗）；服務隔離（上游能隔離故障）；可伸縮（根據業務場景擴容和縮容）；數據庫拆分（獨立服務提供單獨的數據庫）；可擴展（小改動代碼增加新功能）。
微服務領域驅動設計
引入原因
微服務架構包含2個維度：技術維度和業務維度。技術維度交給基礎架構設計者和微服務框架保障；業務維度的關注點是領域驅動設計所擅長的。
定義
領域驅動設計是一種方法論，建立以領域爲核心驅動力的設計體系。將要解決的業務概念和業務規則轉換爲軟件體系中的類型及類型的屬性和行爲，通過合理運用面向對象的封裝、繼承、多態等設計要素，降低系統業務複雜性，且更具擴展性。
概覽
設計階段
戰略設計階段：從問題域和架構2方面考慮。
問題域：核心領域、子領域；限界上下文、上下文映射。
結構方面：分層架構、六邊形架構、CQRS（Command Query Resonsibility Seperation）模式
戰術設計階段：對每個限界上下文進行設計，用領域模型表達複雜的領域知識，模型要素包括：實體、值對象、聚合、領域服務、領域事件、工廠、資源庫、應用服務。
設計過程
戰略設計界定邊界和粒度；戰術設計驗證模型有效性、完整和一致性；兩者形成一種演進式的迭代設計過程。
