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的簡介到此結束！