SpingCloud Alibaba實戰(1:微服務與SpringCloud Alibaba)

三分惡發表於2021-04-06

1、什麼是微服務?

微服務可謂是這幾年比較熱門的技術,從2017開始逐漸爆火,逐漸大大小小的公司紛紛將微服務技術引入並在實際業務中落地。

微服務的概念最早是在2014年由Martin Fowler和James Lewis共同提出:微服務是由單一應用程式構成的小服務,擁有自己的程式與輕量化處理,服務依業務功能設計,以全自動的方式部署,與其他服務使用HTTP API通訊。同時,服務會使用最小規模的集中管理 (例如Docker)技術,服務可以用不同的程式語言與資料庫等。

1.1、單體應用之痛

為什麼要用微服務?微服務真的那麼好嗎?

在認識這些之前,得了解單體架構的弊端。

以MVC架構為例,業務通常是通過部署一個WAR包到Tomcat中,然後啟動Tomcat,監聽某個埠即可對外提供服務。早期在業務規模不大、開發團隊人員規模較小的時候,採用單體應用架構,團隊的開發和運維成本都可控。

然而隨著業務規模的不斷擴大,團隊開發人員的不斷擴張,單體應用架構就會開始出現問題。大致有以下幾個方面:

  • 部署效率低下
  • 團隊協作開發成本高
  • 系統高可用性差
  • 線上釋出變慢

1.2、面向服務(SOA)

面向服務就是把傳統的單機應用中通過JAR包依賴產生的本地方法呼叫,改造成通過RPC介面產生的遠端方法呼叫。

1.3、微服務

微服務可以理解為面向服務的進一步發展。

在SOA的基礎上,微服務主要有了以下的發展:

  • 服務拆分粒度更細。微服務可以說是更細維度的服務化,小到一個子模組,只要該模組依賴的資源與其他模組都沒有關係,那麼就可以拆分為一個微服務。
  • 服務獨立部署。每個微服務都嚴格遵循獨立打包部署的準則,互不影響。比如一臺物理機上可以部署多個Docker例項,每個Docker例項可以部署一個微服務的程式碼。
  • 服務獨立維護。每個微服務都可以交由一個小團隊甚至個人來開發、測試、釋出和運維,並對整個生命週期負責。
  • 服務治理能力要求高。因為拆分為微服務之後,服務的數量變多,因此需要有統一的服務治理平臺,來對各個服務進行管理。

總結來說,微服務架構是將複雜臃腫的單體應用進行細粒度的服務化拆分,每個拆分出來的服務各自獨立打包部署,並交由小團隊進行開發和運維,從而極大地提高了應用交付的效率,並被各大網際網路公司所普遍採用。

這裡附上一張架構演進簡略示意圖:

微服務架構演進略圖

2、微服務如何拆分

2.1、微服務拆分的兩種方式

微服務拆分具體該如何實施呢?

一個最有效的手段就是將不同的功能模組服務化,獨立部署和運維。以社交App為例,可以認為首頁資訊流是一個服務,評論是一個服務,訊息通知是一個服務,個人主頁也是一個服務。

這種服務化拆分方式是縱向拆分,是從業務維度進行拆分。標準是按照業務的關聯程度來決定,關聯比較密切的業務適合拆分為一個微服務,而功能相對比較獨立的業務適合單獨拆分為一個微服務。

還有一種服務化拆分方式是橫向拆分,是從公共且獨立功能維度拆分。標準是按照是否有公共的被多個其他服務呼叫,且依賴的資源獨立不與其他業務耦合。

仍然社交App舉例,無論是首頁資訊流、評論、訊息箱還是個人主頁,都需要顯示使用者的暱稱。假如使用者的暱稱功能有產品需求的變更,你需要上線幾乎所有的服務,這個成本就有點高了。顯而易見,如果我把使用者的暱稱功能單獨部署成一個獨立的服務,那麼有什麼變更我只需要上線這個服務即可,其他服務不受影響,開發和上線成本就大大降低了。

2.2、微服務拆分需要解決的問題

必須要認識到,微服務架構也是有成本的,架構複雜度提升,也會帶來一些新的問題,這些微服務架構必須要解決的問題:

  • 服務如何定義。對於單體應用來說,不同功能模組之前相互互動時,通常是以類庫的方式來提供各個模組的功能。對於微服務來說,每個服務都執行在各自的程式之中,應該以何種形式向外界傳達自己的資訊呢?答案就是介面,無論採用哪種通訊協議,是HTTP還是RPC,服務之間的呼叫都通過介面描述來約定,約定內容包括介面名、介面引數以及介面返回值。
  • 服務如何釋出和訂閱。單體應用由於部署在同一個WAR包裡,介面之間的呼叫屬於程式內的呼叫。而拆分為微服務獨立部署後,服務提供者該如何對外暴露自己的地址,服務呼叫者該如何查詢所需要呼叫的服務的地址呢?這個時候你就需要一個類似登記處的地方,能夠記錄每個服務提供者的地址以供服務呼叫者查詢,在微服務架構裡,這個地方就是註冊中心。
  • 服務如何監控。通常對於一個服務,我們最關心的是QPS(呼叫量)、AvgTime(平均耗時)以及P999(99.9%的請求效能在多少毫秒以內)這些指標。這時候你就需要一種通用的監控方案,能夠覆蓋業務埋點、資料收集、資料處理,最後到資料展示的全鏈路功能。
  • 服務如何治理。可以想象,拆分為微服務架構後,服務的數量變多了,依賴關係也變複雜了。比如一個服務的效能有問題時,依賴的服務都勢必會受到影響。可以設定一個呼叫效能閾值,如果一段時間內一直超過這個值,那麼依賴服務的呼叫可以直接返回,這就是熔斷,也是服務治理最常用的手段之一。
  • 故障如何定位。在單體應用拆分為微服務之後,一次使用者呼叫可能依賴多個服務,每個服務又部署在不同的節點上,如果使用者呼叫出現問題,你需要有一種解決方案能夠將一次使用者請求進行標記,並在多個依賴的服務系統中繼續傳遞,以便串聯所有路徑,從而進行故障定位。

3、微服務技術選型

對於大部分公司而言,自研來解決微服務架構的一些問題,成本是很難接受的。不過,幸運的是,有不少業界開源方案可供選擇。

前幾年比較火的是阿里的Dubbo,後來一度停止維護,最近兩年又起死回生,重新煥發生機。

後來又出現了Spring體系下的微服務方案Spring Cloud,並迅速流行起來。

Spring Cloud本身不是新的框架,它是一系列框架的有機組合,利用Spring Boot的開發便利性巧妙地簡化了分散式系統基礎設施的開發。並非所有元件都由Spring提供,Netflix扮演了重要的角色。

註冊中心Eureka、熔斷器Hystrix、負載均衡元件Ribbon、閘道器Zuul等重要元件均由Netflix提供。

SpingCloud微服務架構

4、為什麼要使用SpringCloud Alibaba

SpringCloud生態已經如此完善了。什麼是SpringClou Alibaba? 為什麼要使用SpringCloud Alibaba?

來自阿里雲的說法:

Spring Cloud 本身是一套微服務規範,並不是一個拿來即可用的框架,而 Spring Cloud Alibaba 的開源為開發者們提供了這套規範的實現方式。同時,Spring Cloud Alibaba 提供的完整的微服務元件、中文文件和本地化的開源服務提高了開發者們接入微服務的速率,並降低了後續的運維難度。

簡單說,Spring Cloud Alibaba是阿里開源的一套Sping Cloud規範的實現。

那麼,第二點,為什麼要使用SpringCloud Alibaba?

因為上面提到的SpringCloud官方版,或者說SpringCloud Netflix版一些重要元件如註冊中心Euraka、Ribbon已經不再迭代更新了。

SpringCloud Alibaba恰逢其會開源孵化畢業,所以這兩年熱度迅速提升,甚至可以說是"SpringCloud2.0"。

來自阿里SpringCloud Alibaba總體結構圖:

img

和SpringCloud Netflix的主要區別:

img

Spring Cloud Alibaba 各版本相容表:

img


好了微服務和SpringCloub Alibaba的簡介到此結束!



參考

【1】:小專欄:SpringCloudAlibaba微服務實戰

【2】:Java日知錄 SpringCloud Alibaba微服務實戰

【3】:極客時間 從0開始學微服務 微博服務化專家的一線實戰經驗

【4】:微服務技術選型之路

【5】:Spring 社群的唯一一個國產開源專案 - Spring Cloud Alibaba 畢業了

相關文章