微服務介紹1.1 系統架構演變

隨著網際網路的發展，網站應用的規模也在不斷的擴大，進而導致系統架構也在不斷的進行變化。從互聯

網早起到現在，系統架構大體經歷了下面幾個過程: 單體應用架構--->垂直應用架構--->分散式架構---

>SOA架構--->微服務架構，當然還有悄然興起的Service Mesh(服務網格化)。接下來我們就來了解一下

每種系統架構是什麼樣子的， 以及各有什麼優缺點。

1.1.1 單體應用架構

網際網路早期，一般的網站應用流量較小，只需一個應用，將所有功能程式碼都部署在一起就可以，這樣可

以減少開發、部署和維護的成本。

比如說一個電商系統，裡面會包含很多使用者管理，商品管理，訂單管理，物流管理等等很多模組，我們

會把它們做成一個web專案，然後部署到一臺tomcat伺服器上。

優點：

專案架構簡單，小型專案的話， 開發成本低專案部署在一個節點上， 維護方便

缺點：

全部功能整合在一個工程中，對於大型專案來講不易開發和維護專案模組之間緊密耦合，單點容錯率低無法針對不同模組進行針對性最佳化和水平擴充套件

1.1.2垂直應用架構

隨著訪問量的逐漸增大，單一應用只能依靠增加節點來應對，但是這時候會發現並不是所有的模組都會

有比較大的訪問量。

還是以上面的電商為例子， 使用者訪問量的增加可能影響的只是使用者和訂單模組， 但是對訊息模組

的影響就比較小. 那麼此時我們希望只多增加幾個訂單模組， 而不增加訊息模組. 此時單體應用就做不

到了， 垂直應用就應運而生了。

所謂的垂直應用架構，就是將原來的一個應用拆成互不相干的幾個應用，以提升效率。比如我們可

以將上面電商的單體應用拆分成:

電商系統(使用者管理 商品管理 訂單管理)後臺系統(使用者管理 訂單管理 客戶管理)CMS系統(廣告管理 營銷管理)

這樣拆分完畢之後，一旦使用者訪問量變大，只需要增加電商系統的節點就可以了，而無需增加後臺和CMS的節點。

1.1.3 分散式架構

當垂直應用越來越多，重複的業務程式碼就會越來越多。這時候，我們就思考可不可以將重複的程式碼抽取

出來，做成統一的業務層作為獨立的服務，然後由前端控制層呼叫不同的業務層服務呢？這就產生了新

的分散式系統架構。它將把工程拆分成表現層和服務層兩個部分，服務層中包含業務邏輯。表現層只需

要處理和頁面的互動，業務邏輯都是呼叫服務層的服務來實現。

優點：

抽取公共的功能為服務層，提高程式碼複用性

缺點：

系統間耦合度變高，呼叫關係錯綜複雜，難以維護

1.1.4 SOA架構

在分散式架構下，當服務越來越多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增加一個排程中心對叢集進行實時管理。此時，用於資源排程和治理中心(SOA Service OrientedArchitecture，面向服務的架構)是關鍵。

優點:

使用註冊中心解決了服務間呼叫關係的自動調節

缺點:

服務間會有依賴關係，一旦某個環節出錯會影響較大( 服務雪崩 )服務關心複雜，運維、測試部署困難

1.1.5 微服務架構

微服務架構在某種程度上是面向服務的架構SOA繼續發展的下一步，它更加強調服務的"徹底拆分"。

優點：

服務原子化拆分，獨立打包、部署和升級，保證每個微服務清晰的任務劃分，利於擴充套件

微服務之間採用Restful等輕量級http協議相互呼叫

缺點：

分散式系統開發的技術成本高（容錯、分散式事務等）

1.2 微服務架構介紹

微服務架構， 簡單的說就是將單體應用進一步拆分，拆分成更小的服務，每個服務都是一個可以獨立執行的專案。

1.2.1 微服務架構的常見問題

一旦採用微服務系統架構，就勢必會遇到這樣幾個問題：

這麼多小服務，如何管理他們？(服務治理 註冊中心[服務註冊 發現 剔除])這麼多小服務，他們之間如何通訊？(restful rpc)這麼多小服務，客戶端怎麼訪問他們？(閘道器)這麼多小服務，一旦出現問題了，應該如何自處理？(容錯)這麼多小服務，一旦出現問題了，應該如何排錯? (鏈路追蹤)

對於上面的問題，是任何一個微服務設計者都不能繞過去的，因此大部分的微服務產品都針對每一個問

題提供了相應的元件來解決它們。

1.2.2 微服務架構的常見概念

1.2.2.1 服務治理

服務治理就是進行服務的自動化管理，其核心是服務的自動註冊與發現。

服務註冊：服務例項將自身服務資訊註冊到註冊中心。

服務發現：服務例項透過註冊中心，獲取到註冊到其中的服務例項的資訊，透過這些資訊去請求它們提供的服務。

服務剔除：服務註冊中心將出問題的服務自動剔除到可用列表之外，使其不會被呼叫到。

1.2.2.2 服務呼叫

在微服務架構中，通常存在多個服務之間的遠端呼叫的需求。目前主流的遠端呼叫技術有基於HTTP的RESTful介面以及基於TCP的RPC協議。

REST(Representational State Transfer)：這是一種HTTP呼叫的格式，更標準，更通用，無論哪種語言都支援http協議RPC（Remote Promote Call）：一種程序間通訊方式。允許像呼叫本地服務一樣呼叫遠端服務。RPC框架的主要目標就是讓遠端服務呼叫更簡單、透明。RPC框架負責遮蔽底層的傳輸方式、序列化方式和通訊細節。開發人員在使用的時候只需要瞭解誰在什麼位置提供了什麼樣的遠端服務介面即可，並不需要關心底層通訊細節和呼叫過程。

區別與聯絡

1.2.2.3 服務閘道器

隨著微服務的不斷增多，不同的微服務一般會有不同的網路地址，而外部客戶端可能需要呼叫多個服務的接口才能完成一個業務需求，如果讓客戶端直接與各個微服務通訊可能出現：

客戶端需要呼叫不同的url地址，增加難度在一定的場景下，存在跨域請求的問題每個微服務都需要進行單獨的身份認證

針對這些問題，API閘道器順勢而生。

API閘道器直面意思是將所有API呼叫統一接入到API閘道器層，由閘道器層統一接入和輸出。一個閘道器的基本功能有：統一接入、安全防護、協議適配、流量管控、長短連結支援、容錯能力。有了閘道器之後，各個API服務提供團隊可以專注於自己的的業務邏輯處理，而API閘道器更專注於安全、流量、路由等問題。

1.2.2.4 服務容錯

在微服務當中，一個請求經常會涉及到呼叫幾個服務，如果其中某個服務不可用，沒有做服務容錯的話，極有可能會造成一連串的服務不可用，這就是雪崩效應。我們沒法預防雪崩效應的發生，只能儘可能去做好容錯。服務容錯的三個核心思想是：

不被外界環境影響不被上游請求壓垮不被下游響應拖垮

1.2.2.5 鏈路追蹤

隨著微服務架構的流行，服務按照不同的維度進行拆分，一次請求往往需要涉及到多個服務。網際網路應用構建在不同的軟體模組集上，這些軟體模組，有可能是由不同的團隊開發、可能使用不同的程式語言來實現、有可能布在了幾千臺伺服器，橫跨多個不同的資料中心。因此，就需要對一次請求涉及的多個服務鏈路進行日誌記錄，效能監控即鏈路追蹤

1.2.3 微服務架構的常見解決方案

1.2.3.1 ServiceComb

Apache ServiceComb，前身是華為雲的微服務引擎 CSE (Cloud Service Engine) 雲服務，是全球首個Apache微服務頂級專案。它提供了一站式的微服務開源解決方案，致力於幫助企業、使用者和開發者將企業應用輕鬆微服務化上雲，並實現對微服務應用的高效運維管理。

1.2.3.2 SpringCloud

Spring Cloud是一系列框架的集合。它利用Spring Boot的開發便利性巧妙地簡化了分散式系統基礎設施的開發，如服務發現註冊、配置中心、訊息匯流排、負載均衡、斷路器、資料監控等，都可以用SpringBoot的開發風格做到一鍵啟動和部署。

Spring Cloud並沒有重複製造輪子，它只是將目前各家公司開發的比較成熟、經得起實際考驗的服務框架組合起來，透過Spring Boot風格進行再封裝遮蔽掉了複雜的配置和實現原理，最終給開發者留出了一套簡單易懂、易部署和易維護的分散式系統開發工具包。

1.2.3.3 SpringCloud Alibaba

Spring Cloud Alibaba 致力於提供微服務開發的一站式解決方案。此專案包含開發分散式應用微服務的必需元件，方便開發者透過 Spring Cloud 程式設計模型輕鬆使用這些元件來開發分散式應用服務。

1.3 SpringCloud Alibaba介紹

Spring Cloud Alibaba 致力於提供微服務開發的一站式解決方案。此專案包含開發分散式應用微服務的必需元件，方便開發者透過 Spring Cloud 程式設計模型輕鬆使用這些元件來開發分散式應用服務。依託Spring Cloud Alibaba，您只需要新增一些註解和少量配置，就可以將 Spring Cloud 應用接入阿里微服務解決方案，透過阿里中介軟體來迅速搭建分散式應用系統。

1.3.1 主要功能

服務限流降級：預設支援 WebServlet、WebFlux， OpenFeign、RestTemplate、SpringCloudGateway， Zuul， Dubbo 和 RocketMQ 限流降級功能的接入，可以在執行時透過控制檯實時修改限流降級規則，還支援檢視限流降級 Metrics 監控。服務註冊與發現：適配 Spring Cloud 服務註冊與發現標準，預設集成了 Ribbon 的支援。分散式配置管理：支援分散式系統中的外部化配置，配置更改時自動重新整理。訊息驅動能力：基於 Spring Cloud Stream 為微服務應用構建訊息驅動能力。分散式事務：使用 @GlobalTransactional 註解， 高效並且對業務零侵入地解決分散式事務問題。阿里雲物件儲存：阿里雲提供的海量、安全、低成本、高可靠的雲端儲存服務。支援在任何應用、任何時間、任何地點儲存和訪問任意型別的資料。分散式任務排程：提供秒級、精準、高可靠、高可用的定時（基於 Cron 表示式）任務排程服務。同時提供分散式的任務執行模型，如網格任務。網格任務支援海量子任務均勻分配到所有Worker（schedulerx-client）上執行。阿里雲簡訊服務：覆蓋全球的簡訊服務，友好、高效、智慧的互聯化通訊能力，幫助企業迅速搭建客戶觸達通道。

1.3.2 元件

Sentinel：把流量作為切入點，從流量控制、熔斷降級、系統負載保護等多個維度保護服務的穩定性。Nacos：一個更易於構建雲原生應用的動態服務發現、配置管理和服務管理平臺。RocketMQ：一款開源的分散式訊息系統，基於高可用分散式叢集技術，提供低延時的、高可靠的訊息釋出與訂閱服務。Dubbo：Apache Dubbo™ 是一款高效能 Java RPC 框架。Seata：阿里巴巴開源產品，一個易於使用的高效能微服務分散式事務解決方案。Alibaba Cloud ACM：一款在分散式架構環境中對應用配置進行集中管理和推送的應用配置中心產品。Alibaba Cloud OSS: 阿里雲物件儲存服務（Object Storage Service，簡稱 OSS），是阿里雲提供的海量、安全、低成本、高可靠的雲端儲存服務。您可以在任何應用、任何時間、任何地點儲存和訪問任意型別的資料。Alibaba Cloud SchedulerX: 阿里中介軟體團隊開發的一款分散式任務排程產品，提供秒級、精準、高可靠、高可用的定時（基於 Cron 表示式）任務排程服務。Alibaba Cloud SMS: 覆蓋全球的簡訊服務，友好、高效、智慧的互聯化通訊能力，幫助企業迅速搭建客戶觸達通道。