作者: Alexsandro Souza​

幾乎每個人都在關注微服務架構，我們也不例外。作為一個與時俱進的程式設計師，我一直在努力瞭解這一架構，希望尋找一種通過Spring在Java中實現微服務架構的方法。

我們公司雖然很棒，但技術堆疊略顯過時，至今還沒有使用Java 8或微服務，因此我需要從外部瞭解更多關於微服務架構的經驗和方法。我決定通過建立一個“to-do system”專案來梳理經驗以供將來參考。

概覽

本文的目標是為不同的微服務提供原始碼walkthrough，因此我不打算深入概念和工具，而是提出一個包含用於開發微服務的模式、工具、技術的應用示例。

“to-do system”將由8個應用組成：

• Reminder
• User
• Service Discovery System
• Mailer
• OAuth Server
• System Integration Test
• API Gateway
• Web Application Client

系統如何工作

上圖未系統與微服務的互動。使用者訪問Angular2編寫的應用，該應用連結OAuth Authorization server，通過OAuth Authorization server分配使用者和許可權。此server將返回一個Jason Web Token，其中包含有關客戶端及其許可權的資訊以及格式的範圍。當用戶認證通過並擁有token之後，Web應用可以與API Gateway通訊。API Gateway將利用JWT驗證請求是否來自授權server，而後呼叫微服務並構建響應。

OAuth server通過User service獲取使用者權鑑細節，API Gateway從OAuth server獲取使用者資訊。

Reminder service是安置ToDo功能的地方，ToDo服務按計劃檢查reminders並通過電子郵件通知使用者，電子郵件由Mail service傳送，該事件由使用Kafka的事件提醒服務觸發。

System Integration Test是負責聯絡Reminder Service endpoints的Java應用。

連線微服務

在微服務架構中，我們需要處理許多在不同IP和埠上執行的微服務。因此有必要找到一種無需硬編碼的方式來管理每個地址。

Netflix Eureka是一種很好的解決方案，作為客戶端服務發現，Eureka允許服務自動查詢和相互通訊。我們有必要理解eureka的工作原理，一邊瞭解REST服務在不同微服務之間的通訊。利用eureka來管理服務執行位置，我們可以新增instance，並通過負載均衡實現在微服務之間分配incoming application traffic。】

在我們的系統中，使用Netflix Ribbon作為客戶端負載均衡器，實現容錯並通過冗餘增加可靠性和可用性。我們使用Netflix Feign編寫宣告性REST客戶端，並整合Ribbon和Eureka來提供負載平衡HTTP客戶端。

我們正在使用Netflix Hystrix斷路器將我們的應用程式與依賴性故障隔離開來。它有助於阻止cascading failure，並允許我們快速恢復或新增fallbacks。Hystrix為每個依賴關係提供一個thread-pool。當thread-pool耗盡，hystrix將拒絕請求。Hystrix同時提供斷路器功能，可以停止對依賴關係的所有請求，在請求失敗、拒絕或超時時，還可以實現備用邏輯。

Authentication

對於任何系統來說，安全性都是非常重要的，微服務架構也一樣。我們通過OAuth2來保持微服務的安全性。OAuth2作為一項知名Authorization，早已廣泛應用於Google，Facebook和Github。

在我們的這個專案中，同時還應用了Spring Security，並在安全問題上增加了一個元素：JSON Web Token（JWT）。

如果我們僅使用OAuth，我們將需要一個OAuth授權伺服器來驗證使用者，生成令牌並充當資源伺服器的endpoints，詢問該令牌是否有效以及授權的許可權。與Authorization Server相比，這需要兩倍的請求。而JWT提供了一種在access token中傳輸許可權和使用者資料的簡單方法。一旦所有資料都已經存在於token string中，資源伺服器就不需要再請求令牌檢查。所有資訊都被序列化為JSON，用base64編碼，最後用私有RSA金鑰簽名。它假設所有資源伺服器都將有一個公鑰，以檢查令牌是否為適當的私鑰簽名，並對令牌進行反序列化以獲取資訊。

REST

在我們的系統中，我們有兩種互動方式：同步和非同步。對於非同步風格，我們使用分散式事件與Kafka，遵循模型釋出/訂閱。對於同步，我們有支援JSON和XML的REST風格。

對於RESTful，有四個成熟級別。我們的微服務處於2級，為了簡單起見，我決定不使用HATEOAS設計模式實現超媒體控制元件。

因為我們正在使用Spring Cloud，所以我們要“out-of-box“一些可擴充套件性模式，把它們放在HTTP連線中，如斷路器、bulkhead、負載均衡、連線池、超時和重試。

分散式事件

如上所述，我們通過使用Kafka將Reminder服務和Mailer服務之間的通訊非同步地與其他微服務進行通訊。在Reminder中，我們有一個計劃任務來檢查提醒時間併發布RemainderFound事件。Mailer服務中將會有一個訂閱的事件，它將開始向用戶傳送電子郵件的過程。我邀請您看看我們如何進行這種整合，以及我如何在Kafka事件模組中寫入傳送到Kafka的資料的序列化/反序列化。

Event sourcing及CQRS

一體化應用通暢具有單個關係資料庫。我們可以使用ACID transaction。因此，如果出現問題，我們的應用程式可以簡單地開始一個transaction、更改多個行並提交transaction。但處理微服務架構中的資料訪問要複雜得多，這是因為資料分佈在不同的資料庫中。跨多個服務實施業務transactions是一個很大的挑戰。

在我們的“To-Do system“中，我們正在使用事件來處理跨多個服務的業務事務。您可以檢視在Mailer服務中應用的CQRS實施事件採購。您可以看到如何分離讀和寫，使我們能夠輕鬆地縮放每個部分。我們使用關係資料庫作為事件儲存，然後使用Kafka分發事件。我們將需要使這兩個動作為Atomic並避免儲存事件，這樣就不會發布最終的JVM崩潰。我不使用Kafka作為事件儲存，因為從關係資料庫構建聚合更簡單。我們正在努力使事情變得容易！

下一步

在To-Do-System已經包含許多微服務架構涉及到的方方面面，另一方面也仍然存在諸多挑戰。我們未來計劃在此專案基礎上增加更多東西，例如Spring雲配置、Docker容器、與Jenkins的持續整合、Spring Sleuth分散式跟蹤、ELK日誌管理等等。

推薦閱讀