前言：

首先，最想說的是，當你要學習一套最新的技術時，官網的英文文件是學習的最佳渠道。因為網上流傳的多數資料是官網翻譯而來，很多描述的重點也都偏向於作者自身碰到的問題，這樣就很容易讓你理解和操作出現偏差，最開始我就進入了這樣誤區。官網的技術導讀真的描述的很詳細，雖然對於我們看英文很費勁，但如果英文不是很差，請選擇沉下心去讀，你一定能收穫好多。我的學習是先從Spring boot開始的，然後接觸到微服務架構，當然，這一切最大的啟迪還是感謝我的一個老師，是他給我指明瞭新的道路，讓我眼前一亮，再次感謝。

Spring 頂級框架

談及微服務，作為當前主流的企業框架Spring，它提供了一整套相關的頂級專案，能讓開發者快速的上手實現自己的應用，今天就介紹下Spring旗下各個頂級專案：

Spring IO platform:用於系統部署，是可整合的，構建現代化應用的版本平臺，具體來說當你使用maven dependency引入spring jar包時它就在工作了。

Spring Boot:旨在簡化建立產品級的 Spring 應用和服務，簡化了配置檔案，使用嵌入式web伺服器，含有諸多開箱即用微服務功能，可以和spring cloud聯合部署。

Spring Framework:即通常所說的spring 框架，是一個開源的Java/Java EE全功能棧應用程式框架，其它spring專案如spring boot也依賴於此框架。

Spring Cloud：微服務工具包，為開發者提供了在分散式系統的配置管理、服務發現、斷路器、智慧路由、微代理、控制匯流排等開發工具包。

Spring XD：是一種執行時環境（伺服器軟體，非開發框架），組合spring技術，如spring batch、spring boot、spring data，採集大資料並處理。

Spring Data：是一個資料訪問及操作的工具包，封裝了很多種資料及資料庫的訪問相關技術，包括：jdbc、Redis、MongoDB、Neo4j等。

Spring Batch：批處理框架，或說是批量任務執行管理器，功能包括任務排程、日誌記錄/跟蹤等。

Spring Security：是一個能夠為基於Spring的企業應用系統提供宣告式的安全訪問控制解決方案的安全框架。

Spring Integration：面向企業應用整合（EAI/ESB）的程式設計框架，支援的通訊方式包括HTTP、FTP、TCP/UDP、JMS、RabbitMQ、Email等。

Spring Social：一組工具包，一組連線社交服務API，如Twitter、Facebook、LinkedIn、GitHub等，有幾十個。

Spring AMQP：訊息佇列操作的工具包，主要是封裝了RabbitMQ的操作。

Spring HATEOAS：是一個用於支援實現超文字驅動的 REST Web 服務的開發庫。

Spring Mobile：是Spring MVC的擴充套件，用來簡化手機上的Web應用開發。

Spring for Android：是Spring框架的一個擴充套件，其主要目的在乎簡化Android本地應用的開發，提供RestTemplate來訪問Rest服務。

Spring Web Flow：目標是成為管理Web應用頁面流程的最佳方案，將頁面跳轉流程單獨管理，並可配置。

Spring LDAP：是一個用於操作LDAP的Java工具包，基於Spring的JdbcTemplate模式，簡化LDAP訪問。

Spring Session：session管理的開發工具包，讓你可以把session儲存到redis等，進行叢集化session管理。

Spring Web Services：是基於Spring的Web服務框架，提供SOAP服務開發，允許通過多種方式建立Web服務。

Spring Shell：提供互動式的Shell可讓你使用簡單的基於Spring的程式設計模型來開發命令，比如Spring Roo命令。

Spring Roo：是一種Spring開發的輔助工具，使用命令列操作來生成自動化專案，操作非常類似於Rails。

Spring Scala：為Scala語言程式設計提供的spring框架的封裝（新的程式語言，Java平臺的Scala於2003年底/2004年初發布）。

Spring BlazeDS Integration：一個開發RIA工具包，可以整合Adobe Flex、BlazeDS、Spring以及Java技術建立RIA。

Spring Loaded：用於實現java程式和web應用的熱部署的開源工具。

Spring REST Shell：可以呼叫Rest服務的命令列工具，敲命令列操作Rest服務。

Spring cloud子專案

目前來說spring主要集中於spring boot（用於開發微服務）和spring cloud相關框架的開發，我們從幾張圖著手理解，然後再具體介紹：

spring cloud子專案包括：

Spring Cloud Config：配置管理開發工具包，可以讓你把配置放到遠端伺服器，目前支援本地儲存、Git以及Subversion。

Spring Cloud Bus：事件、訊息匯流排，用於在叢集（例如，配置變化事件）中傳播狀態變化，可與Spring Cloud Config聯合實現熱部署。

Spring Cloud Netflix：針對多種Netflix元件提供的開發工具包，其中包括Eureka、Hystrix、Zuul、Archaius等。

Netflix Eureka：雲端負載均衡，一個基於 REST 的服務，用於定位服務，以實現雲端的負載均衡和中間層伺服器的故障轉移。

Netflix Hystrix：容錯管理工具，旨在通過控制服務和第三方庫的節點,從而對延遲和故障提供更強大的容錯能力。

Netflix Zuul：邊緣服務工具，是提供動態路由，監控，彈性，安全等的邊緣服務。

Netflix Archaius：配置管理API，包含一系列配置管理API，提供動態型別化屬性、執行緒安全配置操作、輪詢框架、回撥機制等功能。

Spring Cloud for Cloud Foundry：通過Oauth2協議繫結服務到CloudFoundry，CloudFoundry是VMware推出的開源PaaS雲平臺。

Spring Cloud Sleuth：日誌收集工具包，封裝了Dapper,Zipkin和HTrace操作。

Spring Cloud Data Flow：大資料操作工具，通過命令列方式運算元據流。

Spring Cloud Security：安全工具包，為你的應用程式新增安全控制，主要是指OAuth2。

Spring Cloud Consul：封裝了Consul操作，consul是一個服務發現與配置工具，與Docker容器可以無縫整合。

Spring Cloud Zookeeper：操作Zookeeper的工具包，用於使用zookeeper方式的服務註冊和發現。

Spring Cloud Stream：資料流操作開發包，封裝了與Redis,Rabbit、Kafka等傳送接收訊息。

Spring Cloud CLI：基於 Spring Boot CLI，可以讓你以命令列方式快速建立雲元件。

WHAT - 什麼是微服務

微服務簡介

微服務的流行，Martin功不可沒，這老頭也是個奇人，特別擅長抽象歸納和製造概念，我覺的這就是最牛逼的markting啊，感覺這也是目前國人欠缺的能力。

Martin Fowler是國際著名的OO專家，敏捷開發方法的創始人之一，現為ThoughtWorks公司的首席科學家.福勒（Martin Fowler），在物件導向分析設計、UML、模式、軟體開發方法學、XP、重構等方面，都是世界頂級的專家，現為Thought Works公司的首席科學家。Thought Works是一家從事企業應用開發和整合的公司。早在20世紀80年代，Fowler就是使用物件技術構建多層企業應用的倡導者，他著有幾本經典書籍： 《企業應用架構模式》、《UML精粹》和《重構》等。—— 百度百科

先來看看傳統的web開發方式，通過對比比較容易理解什麼是Microservice Architecture。和Microservice相對應的，這種方式一般被稱為Monolithic（比較難傳神的翻譯）。所有的功能打包在一個 WAR包裡，基本沒有外部依賴（除了容器），部署在一個JEE容器（Tomcat，JBoss，WebLogic）裡，包含了 DO/DAO，Service，UI等所有邏輯。

Monolithic比較適合小專案，優點是：

2、基本不會重複開發

3、功能都在本地，沒有分散式的管理開銷和呼叫開銷

它的缺點也非常明顯，特別對於網際網路公司來說（不一一列舉了）：

1、開發效率低：所有的開發在一個專案改程式碼，遞交程式碼相互等待，程式碼衝突不斷

2、程式碼維護難：程式碼功能耦合在一起，新人不知道何從下手

3、部署不靈活：構建時間長，任何小修改必須重新構建整個專案，這個過程往往很長

4、穩定性不高：一個微不足道的小問題，可以導致整個應用掛掉

5、擴充套件性不夠：無法滿足高併發情況下的業務需求

所以，現在主流的設計一般會採用Microservice Architecture，就是基於微服務的架構。簡單來說，微服務的目的是有效的拆分應用，實現敏捷開發和部署。

用《The art of scalability》一書裡提到的scale cube比較容易理解如何拆分。你看，我們叫分庫分表，別人總結成了scale cube，這就是抽象的能力啊，把複雜的東西用最簡單的概念解釋和總結。X軸代表執行多個負載均衡器之後執行的例項，Y軸代表將應用進一步分解為微服務 （分庫），資料量大時，還可以用Z軸將服務按資料分割槽（分表）

微服務的具體特徵

先看看最官方的定義吧

The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are **built around business capabilities** and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services , which may be written in different programming languages and use different data storage technologies.

-- James Lewis and Martin Fowler

把Martin老頭的定義大概的翻譯一下就是下面幾條，這個定義還是太抽象是不是，那就對了，就是要務虛，都說明白了誰還找他付費諮詢啊，這麼貴。

1. 一些列的獨立的服務共同組成系統

2. 單獨部署，跑在自己的程式裡

3. 每個服務為獨立的業務開發

4. 分散式的管理

Martin自己也說了，每個人對微服務都可以有自己的理解，不過大概的標準還是有一些的。

1、分散式服務組成的系統

2、按照業務而不是技術來劃分組織

3、做有生命的產品而不是專案

4、Smart endpoints and dumb pipes（我的理解是強服務個體和弱通訊）

5、自動化運維（DevOps）

6、容錯

7、快速演化

SOA vs Microservice

除了Smart endpoints and dumb pipes都很容易理解對嗎？相信很多人都會問一個問題，這是不是就是SOA換了個概念，掛羊頭賣狗肉啊，有說法把Microservice叫成 Lightway SOA。也有很多傳統磚家跳出來說Microservice就是SOA。其實Martin也沒否認SOA和Microservice的關係。

我個人理解，Microservice是SOA的傳承，但一個最本質的區別就在於Smart endpoints and dumb pipes，或者說是真正的分散式的、去中心化的。Smart endpoints and dumb pipes本質就是去ESB，把所有的“思考”邏輯包括路由、訊息解析等放在服務內部（Smart endpoints），去掉一個大一統的ESB，服務間輕（dumb pipes）通訊，是比SOA更徹底的拆分。

在此我向大家推薦一個架構學習交流群。交流學習群號：575745314 裡面會分享一些資深架構師錄製的視訊錄影：有Spring，MyBatis，Netty原始碼分析，高併發、高效能、分散式、微服務架構的原理，JVM效能優化、分散式架構等這些成為架構師必備的知識體系。還能領取免費的學習資源，目前受益良多

HOW - 怎麼具體實踐微服務

聽上去好像都不錯，具體怎麼落地啊？這需要回答下面幾個問題：

1、客戶端如何訪問這些服務？

2、服務之間如何通訊？

3、這麼多服務，怎麼找?

4、服務掛了怎麼辦？

5、客戶端如何訪問這些服務？

原來的Monolithic方式開發，所有的服務都是本地的，UI可以直接呼叫，現在按功能拆分成獨立的服務，跑在獨立的一般都在獨立的虛擬機器上的 Java程式了。客戶端UI如何訪問他的？後臺有N個服務，前臺就需要記住管理N個服務，一個服務下線/更新/升級，前臺就要重新部署，這明顯不服務我們 拆分的理念，特別當前臺是移動應用的時候，通常業務變化的節奏更快。另外，N個小服務的呼叫也是一個不小的網路開銷。還有一般微服務在系統內部，通常是無 狀態的，使用者登入資訊和許可權管理最好有一個統一的地方維護管理（OAuth）。

所以，一般在後臺N個服務和UI之間一般會一個代理或者叫API Gateway，他的作用包括

1、提供統一服務入口，讓微服務對前臺透明

2、聚合後臺的服務，節省流量，提升效能

3、提供安全，過濾，流控等API管理功能

我的理解其實這個API Gateway可以有很多廣義的實現辦法，可以是一個軟硬一體的盒子，也可以是一個簡單的MVC框架，甚至是一個Node.js的服務端。他們最重要的作 用是為前臺（通常是移動應用）提供後臺服務的聚合，提供一個統一的服務出口，解除他們之間的耦合，不過API Gateway也有可能成為單點故障點或者效能的瓶頸。

一般用過Taobao Open Platform的就能很容易的體會，TAO就是這個API Gateway。

服務之間如何通訊？

因為所有的微服務都是獨立的Java程式跑在獨立的虛擬機器上，所以服務間的通行就是IPC（inter process communication），已經有很多成熟的方案。現在基本最通用的有兩種方式。這幾種方式，展開來講都可以寫本書，而且大家一般都比較熟悉細節了， 就不展開講了。

1、同步呼叫

2、REST（JAX-RS，Spring Boot）

3、RPC（Thrift, Dubbo）

4、非同步訊息呼叫(Kafka, Notify, MetaQ)

一般同步呼叫比較簡單，一致性強，但是容易出呼叫問題，效能體驗上也會差些，特別是呼叫層次多的時候。RESTful和RPC的比較也是一個很有意 思的話題。一般REST基於HTTP，更容易實現，更容易被接受，服務端實現技術也更靈活些，各個語言都能支援，同時能跨客戶端，對客戶端沒有特殊的要 求，只要封裝了HTTP的SDK就能呼叫，所以相對使用的廣一些。RPC也有自己的優點，傳輸協議更高效，安全更可控，特別在一個公司內部，如果有統一個 的開發規範和統一的服務框架時，他的開發效率優勢更明顯些。就看各自的技術積累實際條件，自己的選擇了。

而非同步訊息的方式在分散式系統中有特別廣泛的應用，他既能減低呼叫服務之間的耦合，又能成為呼叫之間的緩衝，確保訊息積壓不會沖垮被呼叫方，同時能 保證呼叫方的服務體驗，繼續幹自己該乾的活，不至於被後臺效能拖慢。不過需要付出的代價是一致性的減弱，需要接受資料最終一致性；還有就是後臺服務一般要 實現冪等性，因為訊息傳送出於效能的考慮一般會有重複（保證訊息的被收到且僅收到一次對效能是很大的考驗）；最後就是必須引入一個獨立的broker，如 果公司內部沒有技術積累，對broker分散式管理也是一個很大的挑戰。

這麼多服務，怎麼找?

在微服務架構中，一般每一個服務都是有多個拷貝，來做負載均衡。一個服務隨時可能下線，也可能應對臨時訪問壓力增加新的服務節點。服務之間如何相互 感知？服務如何管理？這就是服務發現的問題了。一般有兩類做法，也各有優缺點。基本都是通過zookeeper等類似技術做服務註冊資訊的分散式管理。當 服務上線時，服務提供者將自己的服務資訊註冊到ZK（或類似框架），並通過心跳維持長連結，實時更新連結資訊。服務呼叫者通過ZK定址，根據可定製演算法， 找到一個服務，還可以將服務資訊快取在本地以提高效能。當服務下線時，ZK會發通知給服務客戶端。

1、客戶端做：優點是架構簡單，擴充套件靈活，只對服務註冊器依賴。缺點是客戶端要維護所有呼叫服務的地址，有技術難度，一般大公司都有成熟的內部框架支援，比如Dubbo。

2、服務端做：優點是簡單，所有服務對於前臺呼叫方透明，一般在小公司在雲服務上部署的應用採用的比較多。

這麼多服務，服務掛了怎麼辦？

前面提到，Monolithic方式開發一個很大的風險是，把所有雞蛋放在一個籃子裡，一榮俱榮，一損俱損。而分散式最大的特性就是網路是不可靠 的。通過微服務拆分能降低這個風險，不過如果沒有特別的保障，結局肯定是噩夢。我們剛遇到一個線上故障就是一個很不起眼的SQL計數功能，在訪問量上升 時，導致資料庫load彪高，影響了所在應用的效能，從而影響所有呼叫這個應用服務的前臺應用。所以當我們的系統是由一系列的服務呼叫鏈組成的時候，我們 必須確保任一環節出問題都不至於影響整體鏈路。相應的手段有很多：

1、重試機制

2、限流

3、熔斷機制

4、負載均衡

5、降級（本地快取）

這些方法基本上都很明確通用，就不詳細說明了。

WHY - 微服務的應用

這裡有一個圖非常好的總結微服務架構需要考慮的問題，包括

1、API Gateway

2、服務間呼叫

3、服務發現

4、服務容錯

5、服務部署

6、資料呼叫

微服務的優點和缺點（或者說挑戰）一樣明顯。

1、優點

2、開發簡單

3、技術棧靈活

4、服務獨立無依賴

5、獨立按需擴充套件

6、可用性高

7、缺點（挑戰）

8、多服務運維難度

9、系統部署依賴

10、服務間通訊成本

11、資料一致性

12、系統整合測試

13、重複工作

14、效能監控

沒有最好的，只有適合自己的。

1、對於大的網際網路公司，微服務架構是血液，是習慣，每家公司都有自己的套路和架構，細節有不同，但是核心理念是通的。

2、對於一般的公司而言，實踐微服務有非常大的技術挑戰，於是乎才有了這麼多IT供應商考慮這裡的商機。微服務比較適合未來有一定的擴充套件複雜度，且有 很大使用者增量預期的應用，說人話就是新興的網際網路公司。創業初期，不可能買大量的機器或者很貴的機器，但是又必須考慮應對成功後的巨量的使用者，微服務架構 成了最好的選擇。

So What - 思考

看到上面的圖，不是不覺得特別的熟悉？其實我們N年前就用的滾瓜爛熟了好不好？褲子都拖了。

其實本來所謂的微服務就是對網際網路在應用技術的一個總結歸納，IT廠商鼓吹所有概念無非是為了生意（business），SOA是，Cloud是，Microservice也是。下面玩笑很有意思的概括了這個情況（我加了第一條線，原圖見這裡）

所以微服對我們的思考我覺得更多的是思維上的，對已微服務架構，技術上不是問題，意識比工具重要。

1、按照業務 或者客戶需求組織資源（這是最難的）

2、做有生命的產品，而不是專案

3、頭狼戰隊，全棧化

4、後臺服務貫徹Single Responsibility Principle

5、VM->Docker （to PE）

6、DevOps (to PE)

在此我向大家推薦一個架構學習交流群。交流學習群號：575745314 裡面會分享一些資深架構師錄製的視訊錄影：有Spring，MyBatis，Netty原始碼分析，高併發、高效能、分散式、微服務架構的原理，JVM效能優化、分散式架構等這些成為架構師必備的知識體系。還能領取免費的學習資源，目前受益良多

同時，對於開發同學，有這麼多的中介軟體和強大的PE支援固然是好事，我們也需要深入去了解這些中介軟體背後的原理，知其然知其所以然，設想下，如果我們是一個小公司的CTO，離開的阿里的大環境，在有限的技術資源如何通過開源技術實施微服務？

最後，一般提到微服務都離不開DevOps和Docker，理解微服務架構是核心，devops和docker是工具，是手段。下次在抽時間再學習整理下。