分佈式架構設計筆記

主流架構模型-SOA 架構和微服務架構

SOA 所解決的核心問題

• 系統集成
  • 站在系統的角度，解決企業系統間的通訊問題，把原先散亂、無規劃的系統間的網狀結構，梳理成規整、可治理的系統間星形結構，這一步每每須要引入一些產品，好比ESB、以及技術規範、服務管理規範；
  • 這一步解決的核心問題是【有序】
• 系統的服務化
  • 站在功能的角度，把業務邏輯抽象成可複用、可組裝的服務，經過服務的編排實現業務的快速再生，
  • 目的：把原先固有的業務功能轉變爲通用的業務服務，實現業務邏輯的快速複用；
  • 這一步解決的核心問題是【複用】
• 業務的服務化
  • 站在企業的角度，把企業職能抽象成可複用、可組裝的服務；
  • 把原先職能化的企業架構轉變爲服務化的企業架構，進一步提高企業的對外服務能力；
  • 「前面兩步都是從技術層面來解決系統調用、系統功能複用的問題」。
  • 第三步，則是以業務驅動把一個業務單元封裝成一項服務。
  • 這一步解決的核心問題是【高效】

微服務架構

• 微服務架構其實和SOA 架構相似,微服務是在SOA 上作的昇華，
• 微服務架構強調的一個重點是「業務須要完全的組件化和服務化」，
• 原有的單個業務系統會拆分爲多個能夠獨立開發、設計、運行的小應用。
• 這些小應用之間經過服務完成交互和集成。
  • 組件表示一個能夠獨立更換和升級的單元，就像PC 中的CPU、內存、顯卡、硬盤同樣，獨立且能夠更換升級而不影響其餘單元。
  • 若是咱們把PC 做爲組件以服務的方式構建，那麼這臺PC 只須要維護主板和一些必要的外部設備。
  • CPU、內存、硬盤都是以組件方式提供服務，PC 須要調用CPU 作計算處理，只須要知道CPU 這個組件的地址便可。

微服務的特徵

• 經過服務實現組件化
• 按業務能力來劃分服務和開發團隊
• 去中心化
• 基礎設施自動化（devops、自動化部署）

SOA 和微服務架構的差異

• 微服務再也不強調傳統SOA 架構裏面比較重的ESB 企業服務總線，同時SOA 的思想進入到單個業務系統內部實現真正的組件化。
• Docker 容器技術的出現，爲微服務提供了更便利的條件，好比更小的部署單元，每一個服務能夠經過相似Node或者Spring Boot 等技術跑在本身的進程中。
• SOA 注重的是系統集成方面，而微服務關注的是徹底分離

領域驅動設計的概念

• 領域驅動設計（DDD,Domain-Driven Design）
• 在開發前，一般須要進行大量的業務知識梳理，而後纔到軟件設計的層面，最後纔是開發。
• 在業務知識梳理的過程當中，咱們必然會造成某個領域知識，根據領域知識來一步步驅動軟件設計，就是領域驅動設計的基本概念。

爲何須要DDD？

• 業務初期，功能大都很是簡單，普通的CRUD 就能知足，此時系統是清晰的。
• 隨着產品不斷迭代和演化，業務邏輯變得愈來愈複雜，咱們的系統也愈來愈冗雜。
• 各個模塊之間彼此關聯，甚至到後期連做者都很難說清模塊的具體功能意圖是啥。
• 致使在修改一個功能時，要追溯到這個功能須要的修改點就須要很長時間，更別提修改帶來的不可預知的影響面。

• 絕大部分公司都是這樣一個狀態，而後通常的解決方案是不斷的重構系統，讓系統的設計隨着業務成長也進行不斷的演進。

分佈式一致性問題

• 是指在分佈式環境中引入數據複製機制以後，不一樣數據節點之間 可能出現的，並沒有法依靠計算機應用程序自身解決的數據不一致的狀況。

什麼是分佈式架構下的高可用設計

• 避免單點故障
  • 負載均衡技術（failover/選址/硬件負載/軟件負載/ 去中心化的軟件負載（ gossip(rediscluster)））
  • 熱備（linux HA）
  • 多機房（同城災備、異地災備）
• 應用的高可用性
  • 故障監控（系統監控（cpu、內存）/鏈路監控/日誌監控） 自動預警。
  • 應用的容錯設計、（服務降級、限流）自我保護能力
  • 數據量（數據分片、讀寫分離）
• 分佈式架構下的可伸縮設計
  • 垂直伸縮 提高硬件能力
  • 水平伸縮 增長服務器
• 加速靜態內容訪問速度的CDN
  • CDN 是Content Delivery Network 的縮寫，表示的是內容分發網絡。
  • CDN 的做用是把用戶須要的內容分發到離用戶最近的地方，這樣能夠是用戶可以快速獲取所須要的內容。
  • CDN 其實就是一種網絡緩存技術，可以把一些相對穩定的資源放到距離最終用戶較近的地方，
    • 一方面能夠節省整個廣域網的帶寬消耗，
    • 另一方面能夠提高用戶的訪問速度，改進用戶體驗。
    • 咱們通常會把靜態的文件（圖片、腳本、靜態頁面）放到CDN 中

1. 當用戶點擊網站頁面上的內容URL，通過本地DNS 系統解析，DNS系統會最終將域名的解析權交給CNAME 指向的CDN 專用DNS 服務器。
2. CDN 的DNS 服務器將CDN 的全局負載均衡設備IP 地址返回用戶。
3. 用戶向CDN 的全局負載均衡設備發起內容URL 訪問請求。
4. CDN全局負載均衡設備根據用戶IP 地址，以及用戶請求的內容URL，選擇一臺用戶所屬區域的區域負載均衡設備，告訴用戶向這臺設備發起請求。
5. 區域負載均衡設備會爲用戶選擇一臺合適的緩存服務器提供服務，
6. 區域負載均衡設備把服務器的IP 地址返回給用戶用戶向緩存服務器發起請求，緩存服務器響應用戶請求，將用戶所需內容傳送到用戶終端。

什麼狀況下用CDN

• 最適合的是那些不會常常變化的內容，
  • 好比圖片，JS 文件，CSS 文件，圖片文件包括程序模板中的，CSS 文件中用到的背景圖片，
  • 還有就是做爲網站內容組成部分的那些圖片，均可以；
• 灰度發佈
  • 也就是會對新應用進行分批發布，逐步擴大新應用在整個及羣衆的比例直到最後所有完成。
  • 灰度發佈是針對新引用在用戶體驗方面徹底無感知。
• 灰度發佈系統的做用在於，
  • 能夠根據本身的配置，來將用戶的流量導到新上線的系統上，來快速驗證新的功能修改，
  • 而一旦出問題，也能夠立刻的恢復，簡單的說，就是一套A/BTest 系統．