1. 客戶端如何訪問這些服務？（API Gateway）

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

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

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

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

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

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

2. 服務之間如何通訊？（服務呼叫）

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

• REST（JAX-RS，Spring Boot）

• RPC（Thrift, Dubbo）

• 非同步訊息呼叫(Kafka, Notify)

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

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

3. 這麼多服務怎麼查詢？（服務發現）

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

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

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

4. 服務掛了怎麼辦？

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

• 重試機制

• 限流

• 熔斷機制

• 負載均衡

• 降級（本地快取） 這些方法基本上都很明確通用，就不詳細說明了。比如Netflix的Hystrix：https://github.com/Netflix/Hystrix

5. 微服務需要考慮的問題

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

• API Gateway

• 服務間呼叫

• 服務發現

• 服務容錯

• 服務部署

• 資料呼叫