目錄
- 1.1 系統架構演變
- 1.1.1 單體應用架構
- 1.1.2垂直應用架構
- 1.1.3 分布式架構
- 1.1.4 SOA架構
- 1.1.5 微服務架構
- 1.2 微服務架構介紹
- 1.2.1 微服務架構的常見問題
- 1.2.2 微服務架構的常見概念
- 1.2.2.1 服務治理
- 1.2.2.2 服務呼叫
- 1.2.2.3 服務網關
- 1.2.2.4 服務容錯
- 1.2.2.5 鏈路追蹤
- 1.2.3 微服務架構的常見解決方案
- 1.2.3.1 ServiceComb
- 1.2.3.2 SpringCloud
- 1.2.3.3 SpringCloud Alibaba
- 1.3 SpringCloud Alibaba介紹
- 1.3.1 主要功能
- 1.3.2 組件
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://www.uj5u.com/houduan/275307.html
標籤:Java
上一篇:Mybatis、Mybatis Generator、Mybatis-Plus、Mybatis Plus Generator
下一篇:SpringCloud學習筆記
