【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】
