1. 微服務架構

1.1 網際網路應用架構的演變

• 單體應用架構　　

　　　　所有的功能放在一個工程中進行編碼、編譯、打包，並且部署在一個Tomcat容器中，簡單實用

　　　　優點：高效開發，架構簡單（使用MVC架構，藉助IDEA開發除錯即可），便於測試和部署（打包成單⼀可執⾏的jar或者打成war包放到容器內啟動）

　　　　缺點： 可靠性差，某個應用Bug，例如死迴圈、記憶體溢位等， 可能會導致整個應用的崩潰；複雜型高，專案耦合性高，擴充套件能力受限

　　　　業務量上漲之後，單體應用架構進一步豐富變化，比如應用叢集部署、使用Nginx進行負載均衡、增加快取伺服器、增加檔案伺服器、資料庫叢集並做讀寫分離等，通過以上措施增強應對高併發的能力、應
對一定的複雜業務場景，但依然屬於單體應用架構。

• 垂直應用架構

　　　　對專案進行模組的垂直劃分，基於業務特性實現業務之間互不影響，減少元件之間的依賴

　　　　優點：系統拆分實現了流量分擔，解決了併發問題，可以針對不同模組進行優化和功能擴充套件，方便水平擴充套件，負載均衡，容錯率提高，系統間相互獨立

　　　　缺點：

• • 服務之間相互呼叫使得如果某個服務埠或IP地址改變，系統需要手動更改；
  • 搭建集群后實現負載均衡比較負載，如內⽹負載，在遷移機器時會影響調⽤⽅的路由，導致線上故障；
  • 服務之間呼叫方式不統一，基於 httpclient 、 webservice 的接⼝協議不統⼀；
  • 服務監控不到位，除了依靠端⼝、程序的監控，調⽤的成功率、失敗率、總耗時等等這些監控指標是沒有的

• SOA應用架構

　　　　為解決介面協議不同意、服務無法監控、服務的負載均衡，引入了阿里巴巴的Dubbo高效能輕量級的java遠端呼叫框架，與spring無縫整合，提供了三大核心功能：面向介面的遠端方法呼叫，智慧容錯和負載均衡以及服務自動註冊和發現

　　　　SOA (Service-Oriented Architecture)，即面向服務的架構。根據實際業務，把系統拆分成合適的、獨立部署的模組，模組之間相互獨立（通過Webservice/Dubbo等技術進行通訊）。

　　　　優點：分散式、鬆耦合、擴充套件靈活可重用

　　　　缺點：服務抽取粒度大、服務呼叫方和提供方耦合度較高

• 微服務應用架構

　　　　微服務架構拆分粒度更小、服務更獨立。把應用拆分成為一個個微小的服務，不同的服務可以使用不同的開發語言和儲存，服務之間往往通過Restful等輕量級通訊。

　　　　微服務架構關鍵在於微小、獨立、輕量級通訊。微服務是在 SOA 上做的昇華粒度更加細緻，微服務架構強調的⼀個重點是業務需要徹底的元件化和服務化

1.2 微服務架構體現的思想及優缺點

• 優點
  • 服務拆分粒度小，徹底的元件化和服務化使得開發耦合度低，可以獨立部署擴充套件，靈活性強，省級改造影響範圍小
    
  • 微服務小，便於特定業務功能的聚焦，解耦，開發，重用和模組的組裝
  • 微服務相對獨立，不同的微服務可以使用不同的語言開發，鬆耦合
  • 微服務架構下便於引進新技術
• 缺點
  • 分散式複雜難以管理
  • 分散式鏈路追蹤難等

1.3 微服務架構中的核心概念

• 服務註冊與服務發現
  • 服務註冊：服務提供者將所提供的服務資訊（伺服器IP和埠、服務訪問協議等）註冊/登記到註冊中心
  • 服務發現：服務消費者能夠從註冊中心獲取到較為實時的服務列表，然後根究一定的策略選擇一個服務訪問
    
• 負載均衡：將請求壓力分配到多個伺服器（應用伺服器、資料庫伺服器等），以此來提高服務的效能、可靠性

• 熔斷：短路保護，如果下游伺服器因訪問過大而響應變慢或失敗，上游服務為了保護系統整體可用性，可暫時切斷對下游服務的呼叫，犧牲區域性保障整體

• 鏈路追蹤：對一次請求涉及的很多個服務鏈路進行日誌記錄和效能監控
• API 閘道器
  • 微服務架構下，不同的微服務往往會有不同的訪問地址，客戶端可能需要呼叫多個服務的接口才能完成一個業務需求，如果讓客戶端直接與各個微服務通訊可能出現：
    • 客戶端需要呼叫不同的url地址，增加了維護呼叫難度
    • 在一定的場景下，也存在跨域請求的問題（前後端分離就會碰到跨域問題，原本我們在後端採用Cors就能解決，現在利用閘道器，那麼就放在閘道器這層做好了）
    • 每個微服務都需要進行單獨的身份認證
  • API閘道器就可以較好的統一處理上述問題，API請求呼叫統一接入API閘道器層，由閘道器轉發請求。API閘道器更專注在安全、路由、流量等問題的處理上（微服務團隊專注於處理業務邏輯即可）
    • 統一接入（路由）
    • 安全防護（統一鑑權，負責閘道器訪問身份認證驗證，與“訪問認證中心”通訊，實際認證業務邏輯交移“訪問認證中心”處理）
    • 黑白名單（實現通過IP地址控制禁止訪問閘道器功能，控制訪問）
    • 協議適配（實現通訊協議校驗、適配轉換的功能）
    • 流量管控（限流）
    • 長短連結支援
    • 容錯能力（負載均衡）
      

2. SpringCloud簡述

2.1 SpringCloud簡述

　　Spring Cloud是一系列框架的有序集合，利用SpringBoot的開發便利性簡化了分散式系統基礎設施的開發，如服務發現與註冊、配置中心、訊息匯流排、負載均衡、熔斷器、資料監控等。

• Spring Cloud其實是一套規範，是一套用於構建微服務架構的規範，而不是一個可以拿來即用的框架（所謂規範就是應該有哪些功能元件，然後元件之間怎麼配合，共同完成什麼事情）。
• 在這個規範之下第三方的Netflix公司開發了一些元件、Spring官方開發了一些框架/元件，包括第三方的阿里巴巴開發了一套框架/元件集合Spring Cloud Alibaba，這些才是Spring Cloud規範的實現。
• Spring Cloud 規範及實現意圖要解決的問題其實就是微服務架構實施過程中存在的一些問題，如微服務架構中的服務註冊發現問題、網路問題（比如熔斷場景）、統一認證安全授權問題、負載均衡問題、鏈路追蹤等問題
  • Distributed/versioned configuration （分散式/版本化配置）
  • Service registration and discovery （服務註冊和發現）
  • Routing （智慧路由）Service-to-service calls （服務呼叫）
  • Load balancing （負載均衡）Circuit Breakers （熔斷器）
  • Global locks （全域性鎖）
  • Leadership election and cluster state （ 選舉與叢集狀態管理）
  • Distributed messaging （分散式訊息傳遞平臺）
• Spring Cloud 只是利用了Spring Boot 的特點，讓我們能夠快速的實現微服務元件開發，否則不使用Spring Boot的話，我們在使用Spring Cloud時，每一個元件的相關Jar包都需要我們自己匯入配置以及需要開發人員考慮相容性等各種情況。所以Spring Boot是我們快速把Spring Cloud微服務技術應用起來的一種方式
  

2.2 SpringCloud核心元件

Spring Cloud 是一個微服務相關規範，意圖為搭建微服務架構提供一站式服務，採用元件（框架化）機制定義一系列元件，各類元件針對性的處理微服務中的特定問題，共同構成微服務技術棧。

• 按發展可以分為第一代Spring Cloud元件和第二代SpringCloud元件

• SpringCloud中的各元件協調工作，註冊中心負責服務的註冊與發現，API閘道器負責轉發所有外來的請求，斷路器負責監控服務之間的呼叫情況，連續多次失敗進行熔斷保護，配置中心提供統一的配置資訊管理服務，實時通知各個服務獲取最新配置資訊

2.3 SpringCloud 與Dubbo的對比

• Dubbo是阿里巴巴公司開源的一個高效能優秀的服務框架，基於RPC呼叫，工作在傳輸層，TCP協議
• 對於目前使用率較高的Spring Cloud Netflix來說，它是基於HTTP的，所以效率上沒有Dubbo高
• Dubbo體系的組件不全，不能夠提供一站式解決方案，比如服務註冊與發現需要藉助於Zookeeper等實現，而SpringCloud Netflix則是真正的提供了一站式服務化解決方案，且有Spring大家族背景。