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提供。
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總體結構圖：
和SpringCloud Netflix的主要區別：
Spring Cloud Alibaba 各版本相容表:
好了微服務和SpringCloub Alibaba的簡介到此結束！
參考
【1】：小專欄：SpringCloudAlibaba微服務實戰
【2】：Java日知錄 SpringCloud Alibaba微服務實戰
【3】：極客時間 從0開始學微服務 微博服務化專家的一線實戰經驗
【4】：微服務技術選型之路