「系統架構」微服務探究之初識微服務

前言

在傳統的開發中，咱們一般是將全部的功能打包在一塊兒，而後統一部署在一個JEE容器（Tomcat，JBoss，WebLogic）裏，包含了 DO/DAO，Service，UI等全部邏輯。以下圖所示：

 

這種開發方式雖然操做簡單，代碼重用率高，沒有分佈式的管理和調用消耗，可是因爲代碼功功能耦合在一塊兒，一般是牽一髮動全身，一個微小的問題，均可能致使整個應用掛掉。這對於大型應用來講，是很不可行的。所以，有人提出能不能將每個小的服務獨立開來，分別部署維護呢？如產品服務獨立成一塊，訂單服務獨立成一塊，用戶服務也獨立成一塊。這樣，每個服務之間都不會有高耦合性，後期維護升級也更加方便。

 

是的，將每個服務獨立部署分開維護，的確能夠解決傳統開發中的高耦合性，可是咱們也要考慮在傳統的開發方式中全部的服務都是本地的，UI能夠直接調用，如今按功能拆分紅獨立的服務，跑在獨立的服務器或進程中，客戶端UI如何互相訪問呢？

後臺有N個服務，前臺就須要記住管理N個服務，一個服務下線/更新/升級，前臺就要從新部署，這明顯不服務咱們 拆分的理念，特別當前臺是移動應用的時候，一般業務變化的節奏更快。

另外，N個小服務的調用也是一個不小的網絡開銷。還有通常微服務在系統內部，一般是無狀態的，用戶登陸信息和權限管理最好有一個統一的地方維護管理（OAuth）。

所以，基於這些考慮，在上面的基礎上，有人又提出加入API網關層，用它來處理如下問題：

• ① 提供統一服務入口，讓微服務對前臺透明
• ② 聚合後臺的服務，節省流量，提高性能
• ③ 提供安全，過濾，流控等API管理功能

 

至此，一個簡單的微服務架構就誕生了。

服務之間如何通訊

將每個服務獨立部署後，確定不能像傳統開發中使用類庫嵌套的方式調用其餘服務。在微服務架構中，服務與服務之間的通訊一般有兩種方式：

• ①同步調用
• ②異步調用

其中，同步調用又包括RPC方式和REST方式。

通常同步調用比較簡單，一致性強，可是容易出現調用問題，性能體驗上也會差些，特別是調用層次多的時候。

而異步調用在分佈式系統中有特別普遍的應用，如異步消息，它既能下降調用服務之間的耦合，又能成爲調用之間的緩衝，確保消息積壓不會沖垮被調用方，同時能保證調用方的服務體驗，繼續幹本身該乾的活，不至於被後臺性能拖慢。不過須要付出的代價是一致性的減弱，須要接受數據最終一致性。還有就是後臺服務通常要實現冪等性，由於出於性能的考慮，消息的發送通常會有重複（保證消息的被收到且僅收到一次對性能是很大的考驗）。最後就是必須引入一個獨立的broker，如 果公司內部沒有技術積累，對broker分佈式管理也是一個很大的挑戰。

 

服務註冊

在微服務架構中，通常每個服務都是有多個拷貝的，每個拷貝之間採用負載均衡的方式參與業務處理。一個服務隨時可能下線，也可能爲應對臨時訪問壓力增長新的服務節點。那服務之間如何相互感知？多個服務如何管理呢？

這就設計到服務註冊了。服務註冊一般有客戶端方式和服務端方式兩種。不過其基本原理都是經過zookeeper等相似技術作服務註冊信息的分佈式管理。當服務上線時，服務提供者將本身的服務信息註冊到ZK（或相似框架），並經過心跳維持長連接，實時更新連接信息。服務調用者經過ZK尋址，根據可定製算法， 找到一個服務，還能夠將服務信息緩存在本地以提升性能。當服務下線時，ZK會發通知給服務客戶端。

 

服務異常處理

前面提到，爲避免傳統開發方式把全部雞蛋放在同一個籃子裏，一榮俱榮，一損俱損的問題，人們轉而採用服務獨立部署的方式，但獨立部署有一個很大的風險就是網絡是不可靠的，即網絡可能出現故障，若是這一塊沒有特別的保障，採用微服務架構結局確定也是噩夢。那微服務如何保證總體業務鏈路不受網絡的影響或者把受到的影響降到最低呢？關於這一方面，微服務主要採用如下幾個手段：

1. 重試機制：多試幾回
2. 限流：減小到該服務的請求
3. 熔斷機制：關閉該服務與其餘服務之間的聯繫
4. 負載均衡：將指定請求分配到指定服務
5. 降級（本地緩存）：暫時關閉某些無關服務