【51CTO.com快譯】近年來，憑借著其架構中的各項優勢，微服務體系架構已經成為了應用程序開發的首選項。但是不可否認的是，每一種架構都有自身的短板，微服務架構也不例外。例如：在微服務架構中，我們可以部署許多被獨立開發出來的服務，以提供在某些特定場景下的功能。不過，它們需要通過不同的API或事件，來實現彼此之間的通信。有時，它們甚至需要與某些外部系統進行通信，以實現完整的系統功能。

雖然我們在開發的過程中，需要最小化某個微服務對于其他微服務的直接依賴性。但是在某些情況下，這是不可避免的。因此，我們需要在開發和部署微服務時，全面考慮并管理好諸如：服務發現(Service Discovery)、斷路器(Circuit Breaker)、分布式跟蹤(Distributed Tracing)、路由、連接器(Connector)，配置(Configurations)等關系。

首先，我為您準備了如下關系圖。它向您展示了如何使用Spring Boot去構建微服務，以及如何使用Spring Cloud去部署和管理微服務。

如上圖所示，我用到了Spring Cloud所提供的各種產品。下面我將解釋每個組件能夠解決的實際問題。

• Spring Cloud Gateway — 如下圖所示，那些所有來自互聯網(Web或OpenAPI)的、對于微服務的調用，都應當經由Gateway，以處理路由和交互(Cross-Cutting)之類的問題，其中包括：安全性、監控、以及魯棒性等方面。有關如何使用Spring Cloud來構建Gateway的內容，請訪問https://spring.io/projects/spring-cloud-gateway。

• 配置服務器(Config Server) – 如下圖所示，微服務往往自帶有許多配置，而這些配置對于系統整合測試(System Integrate Test，SIT)、用戶驗收測試(User Acceptance Test，UAT)、以及生產環境(PROD)都有所不同。因此，無論是在應用的外部，還是在其內部中心位置，這些配置都應該可以被直接管理和維護。此外，如果配置中有任何需要更改的地方，其應用代碼也不應被迫做相應的修改。Spring Cloud Config就能夠為分布式系統中的各種外部配置，提供服務器端和客戶端的支持。使用Config Server，您可以在中心位置管理所有當前環境中應用程序的外部屬性。如果您想了解更多有關如何使用Spring Cloud，來輕松創建Config Server的詳細內容，請參見--https://spring.io/projects/spring-cloud-config。

• 服務注冊表(Service Registry) - 各類用戶或服務需要使用不同類型的客戶端或服務器端發現，來確定向它們發送請求的服務實例的具體位置。可是，問題在于：這些服務的客戶該如何知道那些對于每個環境都不盡相同的，可用的服務實例呢?業界常用的解決方案是實施Service Registry。它是針對各種可用服務、及其實例與位置的數據庫。畢竟各類服務實例在啟動的時候，都已經在服務注冊表中注冊過了。在此，Eureka Server能夠幫助我們創建對應的Service Registry服務器，并將所有其他的服務都注冊上去。如果您想創建并啟用自己的注冊表服務器，請使用spring-cloud-starter-netflix-eureka-server依賴項，以及@EnableEurekaServer。
• Eureka Discovery Client – 不同的服務之間需要互相調用。如今，大多數微服務都是部署在虛擬機或容器化的環境之中，而且服務實例的數量、及其位置也是經常動態變化的。因此，我們需要實現一種機制，以使得服務客戶端能夠對那些動態更改的服務實例集發出請求。在此，Eureka Discovery Client正好派上用場。它可以幫助我們從Eureka服務注冊表中獲取已注冊的相關服務。據此，Spring Cloud能夠很容易地實現服務發現。如下圖所示，只要Spring Cloud Netflix和Eureka Core在類路徑(classpath)上，任何使用@EnableEurekaClient的Spring Boot應用，都會嘗試著用http://localhost:8761(其默認值為eureka.client.serviceUrl.defaultZone)與Eureka服務器聯系。

• Zipkin Server - 在分布式系統中，僅了解一個實例的狀態是遠遠不夠的。我們往往需要匯總服務中所有實例的矩陣、日志和跟蹤信息，以洞察到那些特定事務所采用的路徑。在此，我們需要用到分布式跟蹤(也稱為請求跟蹤，請參見--https://opensource.com/article/18/9/distributed-tracing-microservices-world)。它通過遵循一系列系統內部的整體操作，以查明發生故障的原因，以及性能欠佳的根源。作為一個分布式跟蹤系統，Zipkin(https://zipkin.io/)的功能主要包括數據的收集和查找。也就是說，它能夠協助收集服務架構中與延遲問題有關的各種時序數據(timing data)。因此，Spring Cloud在其整體方案中添加了zipkin，并據此推出了Spring Cloud Sleuth(https://spring.io/projects/spring-cloud-sleuth#overview)，為分布式跟蹤提供了Spring Boot的自動化配置。
• 斷路器(Circuit Breaker，Hystrix) — 在微服務架構中，如果某個服務不可用，那么當另一個服務同步調用它時，就可能會花費過多時間去等到響應，同時讓會調用方消耗各種線程之類的資源。顯然，如果資源被耗盡，調用服務將無法處理其他類型的請求。因此，為了防止此類網絡或服務的故障，波及到其他服務，我們需要使用斷路器模式，來構建具有容錯和魯棒性的系統，以保證當關鍵服務不可用、或出現高延遲時，該系統仍可正常運行。在Spring Cloud體系中，我們可以通過Hystrix(https://spring.io/projects/spring-cloud-circuitbreaker)來實現該目的。如果您想具體了解如何在Spring boot應用中使用Hystrix，請參見教程--https://dzone.com/articles/microservices-part-4-spring-cloud-circuit-breaker。此外，Spring Cloud還提供了一個不錯的儀表板，來監視Hystrix的各種命令狀態。您可以使用@EnableHystrixDashboard，這個主入口類，并通過Hystrix Dashboard Starter來創建一個Spring Boot應用程序。

Spring Feign Client - 在微服務架構中，服務與服務之間的通信可謂“家常便飯”，而您往往需要使用某種機制來調用(invoke)另一個服務。作為一種聲明性的Rest Client，Spring Feign Client能夠創建一個用JAX-RS或Spring MVC注釋所修飾的接口。如下圖所示，此類的動態實現非常容易被使用。

至此，想必您已經能夠通過上述介紹，了解了如何使用Spring Boot和Cloud來實現微服務的相關知識與流程。如果您感興趣的話，可以自己動手嘗試著編寫一套簡單的服務例子。

【原標題】Microservices Implementation using (Spring Boot and Cloud) (作者: Nitesh Gupta )

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】