1.什麼是微服務
微服務架構風格：是一類将單一應用程式作為由衆多小型服務構成之套件加以開發的方式，其中各項服務都擁有自己的程序并利用輕量化機制（通常為HTTP源API）實作通信。這些服務圍繞業務功能建立而成，且憑借自動化部署機制實作獨立部署。這些服務比對一套最低限度的中央式管理機制，且各服務可通過不同程式設計語言編寫而成并使用不同的資料存儲技術
2.微服務的目
有效的拆分應用，實作靈活開發和部署
3.微服務的優點
- 開發簡單
- 技術棧靈活
- 服務獨立無依賴
- 獨立部署、按需擴充
- 可用性高
4.微服務的缺點
- 多服務運維難度
- 系統部署依賴
- 服務間通信成本
- 資料一緻性
- 系統內建測試
- 重複工作
- 性能監控
5.用戶端如何通路這些服務？
原來的Monolithic方式開發，所有的服務都是本地的，UI可以直接調用，現在按功能拆分成獨立的服務，跑在獨立的一般都在獨立的虛拟機上的 Java程序了。用戶端UI如何通路他的？背景有N個服務，前台就需要記住管理N個服務，一個服務下線/更新/更新，前台就要重新部署，這明顯不服務我們 拆分的理念，特别目前台是移動應用的時候，通常業務變化的節奏更快。另外，N個小服務的調用也是一個不小的網絡開銷。還有一般微服務在系統内部，通常是無 狀态的，使用者登入資訊和權限管理最好有一個統一的地方維護管理（OAuth）。
是以，一般在背景N個服務和UI之間一般會一個代理或者叫API Gateway，他的作用包括
- 提供統一服務入口，讓微服務對前台透明
- 聚合背景的服務，節省流量，提升性能
- 提供安全，過濾，流控等API管理功能
我的了解其實這個API Gateway可以有很多廣義的實作辦法，可以是一個軟硬一體的盒子，也可以是一個簡單的MVC架構，甚至是一個Node.js的服務端。他們最重要的作 用是為前台（通常是移動應用）提供背景服務的聚合，提供一個統一的服務出口，解除他們之間的耦合，不過API Gateway也有可能成為單點故障點或者性能的瓶頸。
一般用過Taobao Open Platform的就能很容易的體會，TAO就是這個API Gateway。
6. 服務之間如何通信？
因為所有的微服務都是獨立的Java程序跑在獨立的虛拟機上，是以服務間的通行就是IPC（inter process communication），已經有很多成熟的方案。現在基本最通用的有兩種方式。這幾種方式，展開來講都可以寫本書，而且大家一般都比較熟悉細節了， 就不展開講了。
- 同步調用
- REST（JAX-RS，Spring Boot）
- RPC（Thrift, Dubbo）
- 異步消息調用(Kafka, Notify, MetaQ)
一般同步調用比較簡單，一緻性強，但是容易出調用問題，性能體驗上也會差些，特别是調用層次多的時候。RESTful和RPC的比較也是一個很有意 思的話題。一般REST基于HTTP，更容易實作，更容易被接受，服務端實作技術也更靈活些，各個語言都能支援，同時能跨用戶端，對用戶端沒有特殊的要 求，隻要封裝了HTTP的SDK就能調用，是以相對使用的廣一些。RPC也有自己的優點，傳輸協定更高效，安全更可控，特别在一個公司内部，如果有統一個 的開發規範和統一的服務架構時，他的開發效率優勢更明顯些。就看各自的技術積累實際條件，自己的選擇了。
而異步消息的方式在分布式系統中有特别廣泛的應用，他既能減低調用服務之間的耦合，又能成為調用之間的緩沖，確定消息積壓不會沖垮被調用方，同時能 保證調用方的服務體驗，繼續幹自己該幹的活，不至于被背景性能拖慢。不過需要付出的代價是一緻性的減弱，需要接受資料最終一緻性；還有就是背景服務一般要 實作幂等性，因為消息發送出于性能的考慮一般會有重複（保證消息的被收到且僅收到一次對性能是很大的考驗）；最後就是必須引入一個獨立的broker，如 果公司内部沒有技術積累，對broker分布式管理也是一個很大的挑戰。
7.這麼多服務，怎麼找?
在微服務架構中，一般每一個服務都是有多個拷貝，來做負載均衡。一個服務随時可能下線，也可能應對臨時通路壓力增加新的服務節點。服務之間如何互相 感覺？服務如何管理？這就是服務發現的問題了。一般有兩類做法，也各有優缺點。基本都是通過zookeeper等類似技術做服務注冊資訊的分布式管理。當 服務上線時，服務提供者将自己的服務資訊注冊到ZK（或類似架構），并通過心跳維持長連結，實時更新連結資訊。服務調用者通過ZK尋址，根據可定制算法， 找到一個服務，還可以将服務資訊緩存在本地以提高性能。當服務下線時，ZK會發通知給服務用戶端。
- 用戶端做：優點是架構簡單，擴充靈活，隻對服務注冊器依賴。缺點是用戶端要維護所有調用服務的位址，有技術難度，一般大公司都有成熟的内部架構支援，比如Dubbo。
- 服務端做：優點是簡單，所有服務對于前台調用方透明，一般在小公司在雲服務上部署的應用采用的比較多。
8.這麼多服務，服務挂了怎麼辦？
前面提到，Monolithic方式開發一個很大的風險是，把所有雞蛋放在一個籃子裡，一榮俱榮，一損俱損。而分布式最大的特性就是網絡是不可靠 的。通過微服務拆分能降低這個風險，不過如果沒有特别的保障，結局肯定是噩夢。我們剛遇到一個線上故障就是一個很不起眼的SQL計數功能，在通路量上升 時，導緻資料庫load彪高，影響了所在應用的性能，進而影響所有調用這個應用服務的前台應用。是以當我們的系統是由一系列的服務調用鍊組成的時候，我們 必須確定任一環節出問題都不至于影響整體鍊路。相應的手段有很多：
- 重試機制
- 限流
- 熔斷機制
- 負載均衡
- 降級（本地緩存）
這些方法基本上都很明确通用，就不詳細說明了。比如Netflix的Hystrix：https://github.com/Netflix/Hystrix
9.WHY - 微服務的應用
這裡有一個圖非常好的總結微服務架構需要考慮的問題，包括
- API Gateway
- 服務間調用
- 服務發現
- 服務容錯
- 服務部署
- 資料調用
來源：http://www.cnblogs.com/brant/p/6021403.html