一、微服務簡介
微服務是最近的一兩年的時間裡是很火的一個概念。感覺不學習一下都快跟不上時代的步伐了，下邊做一下簡單的總結和介紹。
何為微服務？簡而言之，微服務架構風格這種開發方法，是以開發一組小型服務的方式來開發一個獨立的應用系統的。其中每個小型服務都運作在自己的程序中，并經常采用HTTP資源API這樣輕量的機制來互相通信。這些服務圍繞業務功能進行建構，并能通過全自動的部署機制來進行獨立部署。這些微服務可以使用不同的語言來編寫，并且可以使用不同的資料存儲技術。對這些微服務我們僅做最低限度的集中管理。
一個微服務一般完成某個特定的功能，比如下單管理、客戶管理等等。每一個微服務都是微型六角形應用，都有自己的業務邏輯和擴充卡。一些微服務還會釋出API給其它微服務和應用用戶端使用。其它微服務完成一個Web UI，運作時，每一個執行個體可能是一個雲VM或者是Docker容器。
比如，一個前面描述系統可能的分解如下：
總的來說，微服務的主旨是将一個原本獨立的系統拆分成多個小型服務，這些小型服務都在各自獨立的程序中運作，服務之間通過基于HTTP的RESTful API進行通信協作，并且每個服務都維護着自身的資料存儲、業務開發、自動化測試以及獨立部署機制。
二、微服務的特征
1、每個微服務可獨立運作在自己的程序裡；
2、一系列獨立運作的微服務共同建構起了整個系統；
3、每個服務為獨立的業務開發，一個微服務一般完成某個特定的功能，比如：訂單管理、使用者管理等；
4、微服務之間通過一些輕量的通信機制進行通信，例如通過REST API或者RPC的方式進行調用。
擴充閱讀：深度剖析微服務架構的九大特征: http://developer.51cto.com/art/201608/516401.htm
三、微服務的優缺點
1、易于開發和維護
2、啟動較快
3、局部修改容易部署
4、技術棧不受限
5、按需伸縮
6、DevOps
擴充閱讀：微服務架構的優勢與不足 ：http://dockone.io/article/394
四、常見微服務架構
1、服務治理架構
（1）Dubbo（http://dubbo.io/）、Dubbox（當當網對Dubbo的擴充）
擴充閱讀：Dubbo詳細介紹與安裝使用過
最近的好消息是Dubbo已近重新開始進行運維啦！
（2）Netflix的Eureka、Apache的Consul等。
Spring Cloud Eureka是對Netflix的Eureka的進一步封裝。
2、分布式配置管理
（1）百度的Disconf
（2）360的QConf
（3）Spring Cloud元件中的Config
（3）淘寶的Diamond
3、批量任務架構
（1）Spring Cloud元件中的Task
（2）LTS
4、服務追蹤架構
。。。
五、Spring Cloud全家桶元件
在介紹Spring Cloud 全家桶之前，首先要介紹一下Netflix ，Netflix 是一個很偉大的公司，在Spring Cloud項目中占着重要的作用，Netflix 公司提供了包括Eureka、Hystrix、Zuul、Archaius等在内的很多元件，在微服務架構中至關重要，Spring在Netflix 的基礎上，封裝了一系列的元件，命名為：Spring Cloud Eureka、Spring Cloud Hystrix、Spring Cloud Zuul等，下邊對各個元件進行分别得介紹：
（1）Spring Cloud Eureka
我們使用微服務，微服務的本質還是各種API接口的調用，那麼我們怎麼産生這些接口、産生了這些接口之後如何進行調用那？如何進行管理哪？
答案就是Spring Cloud Eureka，我們可以将自己定義的API 接口注冊到Spring Cloud Eureka上，Eureka負責服務的注冊于發現，如果學習過Zookeeper的話，就可以很好的了解，Eureka的角色和 Zookeeper的角色差不多，都是服務的注冊和發現，構成Eureka體系的包括：服務注冊中心、服務提供者、服務消費者。
上圖中描述了（圖檔來源于網絡）：
1、兩台Eureka服務注冊中心構成的服務注冊中心的主從複制叢集；
2、然後服務提供者向注冊中心進行注冊、續約、下線服務等；
3、服務消費者向Eureka注冊中心拉去服務清單并維護在本地（這也是用戶端發現模式的機制展現！）；
4、然後服務消費者根據從Eureka服務注冊中心擷取的服務清單選取一個服務提供者進行消費服務。
（2）Spring Cloud Ribbon
在上Spring Cloud Eureka描述了服務如何進行注冊，注冊到哪裡，服務消費者如何擷取服務生産者的服務資訊，但是Eureka隻是維護了服務生産者、注冊中心、服務消費者三者之間的關系，真正的服務消費者調用服務生産者提供的資料是通過Spring Cloud Ribbon來實作的。
在（1）中提到了服務消費者是将服務從注冊中心擷取服務生産者的服務清單并維護在本地的，這種用戶端發現模式的方式是服務消費者選擇合适的節點進行通路服務生産者提供的資料，這種選擇合适節點的過程就是Spring Cloud Ribbon完成的。
Spring Cloud Ribbon用戶端負載均衡器由此而來。
（3）Spring Cloud Feign
上述（1）、（2）中我們已經使用最簡單的方式實作了服務的注冊發現和服務的調用操作，如果具體的使用Ribbon調用服務的話，你就可以感受到使用Ribbon的方式還是有一些複雜，是以Spring Cloud Feign應運而生。
Spring Cloud Feign 是一個聲明web服務用戶端，這使得編寫Web服務用戶端更容易，使用Feign 建立一個接口并對它進行注解，它具有可插拔的注解支援包括Feign注解與JAX-RS注解，Feign還支援可插拔的編碼器與解碼器，Spring Cloud 增加了對 Spring MVC的注解，Spring Web 預設使用了HttpMessageConverters, Spring Cloud 內建 Ribbon 和 Eureka 提供的負載均衡的HTTP用戶端 Feign。
簡單的可以了解為：Spring Cloud Feign 的出現使得Eureka和Ribbon的使用更為簡單。
（4）Spring Cloud Hystrix
我們在（1）、（2）、（3）中知道了使用Eureka進行服務的注冊和發現，使用Ribbon實作服務的負載均衡調用，還知道了使用Feign可以簡化我們的編碼。但是，這些還不足以實作一個高可用的微服務架構。
例如：當有一個服務出現了故障，而服務的調用方不知道服務出現故障，若此時調用放的請求不斷的增加，最後就會等待出現故障的依賴方 相應形成任務的積壓，最終導緻自身服務的癱瘓。
Spring Cloud Hystrix正是為了解決這種情況的，防止對某一故障服務持續進行通路。Hystrix的含義是：斷路器，斷路器本身是一種開關裝置，用于我們家庭的電路保護，防止電流的過載，當線路中有電器發生短路的時候，斷路器能夠及時切換故障的電器，防止發生過載、發熱甚至起火等嚴重後果。
（5）Spring Cloud Config
對于微服務還不是很多的時候，各種服務的配置管理起來還相對簡單，但是當成百上千的微服務節點起來的時候，服務配置的管理變得會複雜起來。
分布式系統中，由于服務數量巨多，為了友善服務配置檔案統一管理，實時更新，是以需要分布式配置中心元件。在Spring Cloud中，有分布式配置中心元件Spring Cloud Config ，它支援配置服務放在配置服務的記憶體中（即本地），也支援放在遠端Git倉庫中。在Cpring Cloud Config 元件中，分兩個角色，一是Config Server，二是Config Client。
Config Server用于配置屬性的存儲，存儲的位置可以為Git倉庫、SVN倉庫、本地檔案等，Config Client用于服務屬性的讀取。
（6）Spring Cloud Zuul
我們使用Spring Cloud Netflix中的Eureka實作了服務注冊中心以及服務注冊與發現；而服務間通過Ribbon或Feign實作服務的消費以及均衡負載；通過Spring Cloud Config實作了應用多環境的外部化配置以及版本管理。為了使得服務叢集更為健壯，使用Hystrix的融斷機制來避免在微服務架構中個别服務出現異常時引起的故障蔓延。
先來說說這樣架構需要做的一些事兒以及存在的不足：
1、首先，破壞了服務無狀态特點。為了保證對外服務的安全性，我們需要實作對服務通路的權限控制，而開放服務的權限控制機制将會貫穿并污染整個開放服務的業務邏輯，這會帶來的最直接問題是，破壞了服務叢集中REST API無狀态的特點。從具體開發和測試的角度來說，在工作中除了要考慮實際的業務邏輯之外，還需要額外可續對接口通路的控制處理。
2、其次，無法直接複用既有接口。當我們需要對一個即有的叢集内通路接口，實作外部服務通路時，我們不得不通過在原有接口上增加校驗邏輯，或增加一個代理調用來實作權限控制，無法直接複用原有的接口。
面對類似上面的問題，我們要如何解決呢？下面進入本文的正題：服務網關！
為了解決上面這些問題，我們需要将權限控制這樣的東西從我們的服務單元中抽離出去，而最适合這些邏輯的地方就是處于對外通路最前端的地方，我們需要一個更強大一些的均衡負載器，它就是本文将來介紹的：服務網關。
服務網關是微服務架構中一個不可或缺的部分。通過服務網關統一向外系統提供REST API的過程中，除了具備服務路由、均衡負載功能之外，它還具備了權限控制等功能。Spring Cloud Netflix中的Zuul就擔任了這樣的一個角色，為微服務架構提供了前門保護的作用，同時将權限控制這些較重的非業務邏輯内容遷移到服務路由層面，使得服務叢集主體能夠具備更高的可複用性和可測試性。
（7）Spring Cloud Bus
在（5）Spring Cloud Config中，我們知道的配置檔案可以通過Config Server存儲到Git等地方，通過Config Client進行讀取，但是我們的配置檔案不可能是一直不變的，當我們的配置檔案放生變化的時候如何進行更新哪？
一種最簡單的方式重新一下Config Client進行重新擷取，但Spring Cloud絕對不會讓你這樣做的，Spring Cloud Bus正是提供一種操作使得我們在不關閉服務的情況下更新我們的配置。
Spring Cloud Bus官方意義：消息總線。
當然動态更新服務配置隻是消息總線的一個用處，還有很多其他用處。
六、總結
Spring Cloud 的元件還不止這些，通過上邊的口水話的介紹，應該可以大緻有一定的了解，但是每一個元件的功能遠不止上述介紹的那些，每一個元件還有很多其他的功能點，這裡的介紹希望能夠帶大家入個門，不要對微服務這個這麼大的概念有所畏懼。