SpingCloud Alibaba實戰（1：微服務與SpringCloud Alibaba）

一、什麼是微服務？

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

微服務的概念最先是在2014年由Martin Fowler和James Lewis共同提出：微服務是由單一應用程序構成的小服務，擁有本身的進程與輕量化處理，服務依業務功能設計，以全自動的方式部署，與其餘服務使用HTTP API通信。同時，服務會使用最小規模的集中管理 （例如Docker）技術，服務能夠用不一樣的編程語言與數據庫等。

1.一、單體應用之痛

爲何要用微服務？微服務真的那麼好嗎？

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

以MVC架構爲例，業務一般是經過部署一個WAR包到Tomcat中，而後啓動Tomcat，監聽某個端口便可對外提供服務。早期在業務規模不大、開發團隊人員規模較小的時候，採用單體應用架構，團隊的開發和運維成本均可控。

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

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

1.二、面向服務（SOA）

面向服務就是把傳統的單機應用中經過JAR包依賴產生的本地方法調用，改形成經過RPC接口產生的遠程方法調用。

1.三、微服務

微服務能夠理解爲面向服務的進一步發展。

在SOA的基礎上，微服務主要有了如下的發展：

• 服務拆分粒度更細。微服務能夠說是更細維度的服務化，小到一個子模塊，只要該模塊依賴的資源與其餘模塊都沒有關係，那麼就能夠拆分爲一個微服務。
• 服務獨立部署。每一個微服務都嚴格遵循獨立打包部署的準則，互不影響。好比一臺物理機上能夠部署多個Docker實例，每一個Docker實例能夠部署一個微服務的代碼。
• 服務獨立維護。每一個微服務均可以交由一個小團隊甚至我的來開發、測試、發佈和運維，並對整個生命週期負責。
• 服務治理能力要求高。由於拆分爲微服務以後，服務的數量變多，所以須要有統一的服務治理平臺，來對各個服務進行管理。

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

這裏附上一張架構演進簡略示意圖：

二、微服務如何拆分

2.一、微服務拆分的兩種方式

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

一個最有效的手段就是將不一樣的功能模塊服務化，獨立部署和運維。以社交App爲例，能夠認爲首頁信息流是一個服務，評論是一個服務，消息通知是一個服務，我的主頁也是一個服務。

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

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

仍然社交App舉例，不管是首頁信息流、評論、消息箱仍是我的主頁，都須要顯示用戶的暱稱。假如用戶的暱稱功能有產品需求的變動，你須要上線幾乎全部的服務，這個成本就有點高了。顯而易見，若是我把用戶的暱稱功能單獨部署成一個獨立的服務，那麼有什麼變動我只須要上線這個服務便可，其餘服務不受影響，開發和上線成本就大大下降了。

2.二、微服務拆分須要解決的問題

必需要認識到，微服務架構也是有成本的，架構複雜度提高，也會帶來一些新的問題，這些微服務架構必需要解決的問題：

• 服務如何定義。對於單體應用來講，不一樣功能模塊以前相互交互時，一般是以類庫的方式來提供各個模塊的功能。對於微服務來講，每一個服務都運行在各自的進程之中，應該以何種形式向外界傳達本身的信息呢？答案就是接口，不管採用哪一種通信協議，是HTTP仍是RPC，服務之間的調用都經過接口描述來約定，約定內容包括接口名、接口參數以及接口返回值。
• 服務如何發佈和訂閱。單體應用因爲部署在同一個WAR包裏，接口之間的調用屬於進程內的調用。而拆分爲微服務獨立部署後，服務提供者該如何對外暴露本身的地址，服務調用者該如何查詢所須要調用的服務的地址呢？這個時候你就須要一個相似登記處的地方，可以記錄每一個服務提供者的地址以供服務調用者查詢，在微服務架構裏，這個地方就是註冊中心。
• 服務如何監控。一般對於一個服務，咱們最關心的是QPS（調用量）、AvgTime（平均耗時）以及P999（99.9%的請求性能在多少毫秒之內）這些指標。這時候你就須要一種通用的監控方案，可以覆蓋業務埋點、數據收集、數據處理，最後到數據展現的全鏈路功能。
• 服務如何治理。能夠想象，拆分爲微服務架構後，服務的數量變多了，依賴關係也變複雜了。好比一個服務的性能有問題時，依賴的服務都勢必會受到影響。能夠設定一個調用性能閾值，若是一段時間內一直超過這個值，那麼依賴服務的調用能夠直接返回，這就是熔斷，也是服務治理最經常使用的手段之一。
• 故障如何定位。在單體應用拆分爲微服務以後，一次用戶調用可能依賴多個服務，每一個服務又部署在不一樣的節點上，若是用戶調用出現問題，你須要有一種解決方案可以將一次用戶請求進行標記，並在多個依賴的服務系統中繼續傳遞，以便串聯全部路徑，從而進行故障定位。

三、微服務技術選型

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

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

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

Spring Cloud自己不是新的框架，它是一系列框架的有機組合，利用Spring Boot的開發便利性巧妙地簡化了分佈式系統基礎設施的開發。並不是全部組件都由Spring提供，Netflix扮演了重要的角色。

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

四、爲何要使用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整體結構圖：

和SpringCloud Netflix的主要區別：

Spring Cloud Alibaba 各版本兼容表:

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

---

參考

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

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

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

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

【5】：Spring 社區的惟一一個國產開源項目 - Spring Cloud Alibaba 畢業了