|
|
51CTO旗下网站
|
|
移动端

如何用Spring Boot和Cloud实现微服务

本文将向您介绍如何使用Spring Boot和Cloud来实现微服务的基本部署和相互通信。

作者:陈峻译来源:51CTO|2020-06-30 07:58

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

【编辑推荐】

  1. Spring Boot默认的指标数据从哪来的?
  2. Spring vs Spring Boot:3大核心区别
  3. ZooKeeper、Eureka、Consul 、Nacos微服务注册中心对比
  4. 阿里云发布Spring Boot新脚手架,嗯!真香!
  5. 微服务架构框架?这里为你汇总了15种
【责任编辑:武晓燕 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

订阅专栏+更多

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊

51CTO服务号

51CTO官微