文章目錄
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框架負責屏蔽底層的傳輸方式、序列化方式和通信細節。開發人員在使用的時候只需要瞭解誰在什麼位置提供了什麼樣的遠程服務接口即可，並不需要關心底層通信細節和調用過程。
區別與聯繫
| 比較項 | RESTful | RPC |
|---|---|---|
| 通訊協議 | HTTP | 一般使用TCP |
| 性能 | 略低 | 較高 |
| 靈活度 | 高 | 較高 |
| 應用 | 微服務架構 | SOA架構 |
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的開發便利性巧妙地簡化了分佈式系統基礎設施的開發，如服務發現註冊、配置中心、消息總線、負載均衡、斷路器、數據監控等，都可以用Spring Boot的開發風格做到一鍵啓動和部署。
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、Spring CloudGateway， 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: 覆蓋全球的短信服務，友好、高效、智能的互聯化通訊能力，幫助企業迅速搭建客戶觸達通道。
文章持續更新，可以微信搜索「 碼農清風 」第一時間閱讀，關注後回覆引導關鍵詞有我準備的一線大廠面試資料和學習筆記，安利一個後端面試指南：https://github.com/ThinkingHan/Java-review-gudie，有大廠面試完整考點，歡迎Star。
