前一篇文章《微服务操作模型》中,我们定义了微服务使用的操作模型。这篇文章中,我们将开始使用Spring Cloud和Netflix OSS实现这一模型,包含核心部分:服务发现(Service Discovery)、动态路由(Dynamic Routing)、负载均衡(Load Balancing),和边缘服务器(Edge Server),其他部分在后面的文章中介绍。
我们将使用来自Spring Cloud和Netflix OSS的一些核心组件,实现在已部署的微服务交互,不必手动管理配置,如每一个微服务的端口或者手工配置路由规则等等。为了避免端口冲突,我们的微服务在启动时,将从端口段中动态获取可用的端口。为了方便访问微服务,我们将使用Edge Server提供一个微服务的访问入口点。
在简要介绍Spring Cloud和Netflix OSS组件之后,我们将描述本系列文章使用的系统,以及如何访问源代码,并编译。同时,也会简要指出源代码中的最重要部分。最后,我们将运行一些访问服务的测试代码,也会演示如何简单地创建一个新的服务实例,获取并使用负载均衡,所有这一些都不必手工配置。
1. Spring Cloud和Netflix OSS
Spring Cloud是spring.io家庭的一个新项目,包含一系列组件,可用来实现我们的操作模型。很大程度上而言,Spring Cloud 1.0 是基于Netflix OSS组件。在Spring环境中,Spring Cloud 非常友好地集成了Netflix 组件,使用了和Spring Boot相似的自动配置和惯例优于配置。
下表映射了操作模式中介绍的组件和我们将要使用的实际组件:
本文将包含Eureka、Ribbon和Zuul:
1/Netflix Eureka – Service Discover Server服务发现
Netflix Eureka允许微服务在运行时自我注册
2/Netflix Ribbon-Dynamic Routing and Load Balancer动态路由和负载均衡
Netflix Ribbon可以在服务消费方运行时查询微服务。Ribbon使用Eureka中的信息定位合适的服务实例。如果发现了多个服务实例,Ribbon将应用负载均衡来转发请求到可用的微服务实例。Ribbon 不作为一个单独的服务运行,而是嵌入在每一个服务消费方中。
3/Netflix Zuul – Edge Server边缘服务器
Zuul是我们对外部世界的守门员,禁止任一未授权的外部请求进入。Zuul在系统内部也提供了方便的进入入口点。通过使用动态分配的端口,可以避免端口冲突,以及最小化管理成本,但是也导致服务消费方更难接入。Zuul 使用Ribbon来查询可用的服务,并路由外部的请求到合适的服务实例。在本文中,我们将仅仅使用Zuul提供了便利的访问入口点,安全部分在下一篇文章中讨论。
备注:通过边缘服务器(Edge Server),可被外部访问的微服务,在系统中可称为API。
2. 系统架构
为了测试这些组件,我们需要一个可实施的业务系统。本文章的目标是开发实现如下系统:
上图包含4个业务服务(绿色文本框):
1/ 三个核心服务负责处理信息:产品、推荐和评论;
2/ 一个组合服务 product-composite,用来聚合3个核心服务的信息,组合包含评论和推荐的产品信息视图;
为了支持业务服务,我们使用了如下基础设施服务和组件(蓝色文本框):
1/ 服务发现服务器(Service Discovery Server – Netflix Eureka)
2/ 动态路由和负载均衡(Netflix Ribbon)
3/ 边缘服务器(Edge Server – Netflix Zuul)
为了强调微服务和单体应用的差异,我们将每一个服务运行在单独的微服务进程中。在一个大系统中,如此细粒度的微服务可能并不方便。相应地,一组相关的微服务可能合并为一组,保持微服务的数量在可管理的水平,但这并不是退回到巨大的单体应用。
3. 获取源代码并编译
获取源代码,并进行测试,需要已安装Java SE8和Git,接着执行如下操作:
$ git clone https://github.com/callistaenterprise/blog-microservices.git
$ cd blog-microservices
$ git checkout -b B1 M1.1
将生成如下的目录结构:
每一个组件独立编译(记住我们不再编译单体应用),因此每一个组件都有自己的build文件。我们使用Gradle编译系统,如果你没有安装Gradle,build文件将自动下载。为了简化编译过程,我们提供了一个小的shell脚本,可用来编译组件:
$ ./build-all.sh
如果在Windows环境下,你可以执行相应的bat文件 build-all.bat。
将显示6个log消息,并显示:BUILD SUCCESSFUL
4. 阅读源代码
快速看看关键的源代码,每一个微服务开发为一个独立的Spring Boot应用,并使用Undertow(一个轻量级的Servlet 3.1容器)作为web server。Spring MVC用来实现 REST-based服务,Spring RestTemplate 用来执行外部调用。如果你想更多地了解这些核心技术,你可以查看相关的文章。
这里,我们关注如何使用Spring Cloud和Netflix OSS功能。
备注:为了让源码易于理解,我们特意让实现尽量简单。
4.1 Gradle依赖
本着Spring Boot的精髓,Spring Cloud定义了一组starter 依赖,便于引入需要的特定依赖。为了在微服务中使用Eureka和Ribbon,以及方便调用其他微服务,在build文件中添加如下:
compile("org.springframework.cloud:spring-cloud-starter-eureka:1.0.0.RELEASE")
可以查看product-service/build.gradle 获取完整的例子。
为了搭建Eureka 服务器,添加如下依赖:
compile('org.springframework.cloud:spring-cloud-starter-eureka-server:1.0.0.RELEASE')
完整的例子,可以查看discovery-server/build.gradle。
4.2 基础设施服务器
基于Spring Cloud和Netflix OSS搭建基础设施服务器相当方便。例如,在一个标准的Spring Boot应用中,添加@EnableEurekaServer标注来搭建Eureka 服务器。
@SpringBootApplication
@EnableEurekaServer
public class EurekaApplication {
public static void main(String[] args) {
SpringApplication.run(EurekaApplication.class, args);
}
}
完整的实例,可以查看EurekaApplication.java代码。
搭建Zuul 服务器,可以添加@EnableZuulProxy标注。完整的实例,可以查看ZuulApplication.java代码。
通过这些简单的标注,可以搭建一个默认的服务器配置。根据需要,也可以通过特定的设置覆盖默认配置。例如,我们可以通过覆盖默认的配置,限制边缘服务器允许路由调用的微服务。默认情况下,Zuul搭建了Eureka中可以发现的每一个微服务的路由。通过如下的application.yml配置,限制了只允许访问组合服务-product service的路由。
zuul:
ignoredServices: "*"
routes:
productcomposite:
path: /productcomposite/**
查看edge-server/application.yml获取完整的例子。
4.3 业务服务
通过在Spring Boot应用中,添加@EnableDiscoveryClient标注,自动注册微服务到Eureka Server中。
@SpringBootApplication @EnableDiscoveryClient public class ProductServiceApplication { public static void main(String[] args) { SpringApplication.run(ProductServiceApplication.class, args); } }
完整的例子,可以查看ProductServiceApplication.java。
为了查询和调用微服务实例,可以使用Ribbon和Spring RestTemplate,如下所示:
@Autowired private LoadBalancerClient loadBalancer; ... public ResponseEntity> getReviews(int productId) { ServiceInstance instance = loadBalancer.choose("review"); URI uri = instance.getUri(); ... response = restTemplate.getForEntity(url, String.class);
服务消费方只需要知道服务的名字,如上述例子中的review,Ribbon(LoadBalancerClient类)将发现服务实例,并返回URI给服务消费方。
5. 启动系统
在本文中,我们将在本地开发环境中作为一个java进程来启动微服务。在接下来的文章中,我们将描述如何部署微服务到云环境和Docker容器中。
为了运行下面的一些命令,需要安装curl和jq工具。
每一个微服务使用命令 ./gradlew bootRun 来启动。
首先,启动微服务基础设施,如:
$ cd .../blog-microservices/microservices
$ cd support/discovery-server; ./gradlew bootRun
$ cd support/edge-server; ./gradlew bootRun
一旦启动了上述基础设施微服务,接着启动业务微服务:
$ cd core/product-service; ./gradlew bootRun
$ cd core/recommendation-service; ./gradlew bootRun
$ cd core/review-service; ./gradlew bootRun
$ cd composite/product-composite-service; ./gradlew bootRun
如果在Windows环境下,可以运行相应的bat文件,start-all.bat文件。
一旦微服务启动了,将自注册到服务发现服务器(Service Discovery Server - Eureka)中去,并输出如下日志:
DiscoveryClient ... - registration status: 204
在服务发现web 应用中,可以看到如下4个业务服务,和边缘服务器(Edge Server)(http://localhost:8761):
为了了解上述服务的更多信息,如使用的ip地址和端口,可使用Eureka REST API:
$ curl -s -H "Accept: application/json" http://localhost:8761/eureka/apps | jq '.applications.application[] | {service: .name, ip: .instance.ipAddr, port: .instance.port."$"}' { "service": "PRODUCT", "ip": "192.168.0.116", "port": "59745" } { "service": "REVIEW", "ip": "192.168.0.116", "port": "59178" } { "service": "RECOMMENDATION", "ip": "192.168.0.116", "port": "48014" } { "service": "PRODUCTCOMPOSITE", "ip": "192.168.0.116", "port": "51658" } { "service": "EDGESERVER", "ip": "192.168.0.116", "port": "8765" }
现在,我们已经准备好进行测试了。首先,验证可以到达我们的微服务,接着,我们创建一个新的微服务实例,并通过Ribbon在多个服务实例上实施负载均衡。
备注:在接下来的文章中,我们也会尝试失败的场景,演示电路断路器(Circuit Breaker)是如何工作的。
5.1 开始测试
通过边缘服务器来调用组合服务,边缘服务器在端口8765(查看application.yml文件)。我们通过边缘服务器,以及路径/productcomposite/** 可到达 productcomposite 服务。返回的组合响应如下:
$ curl -s localhost:8765/productcomposite/product/1 | jq . { "name": "name", "productId": 1, "recommendations": [ { "author": "Author 1", "rate": 1, "recommendationId": 1 }, ... ], "reviews": [ { "author": "Author 1", "reviewId": 1, "subject": "Subject 1" }, ... ], "weight": 123 }
如果在微服务内部,我们实际上可以直接调用微服务,不必通过边缘服务器。当然,问题是我们不知道服务运行在什么端口,因为服务是动态分配的。但是,我们可以查看调用Eureka REST API 的输出,就知道服务监听的端口了。我们可以使用如下的命令调用3个核心服务(端口号采用Eureka REST API输出的端口信息):
$ curl -s localhost:51658/product/1 | jq . $ curl -s localhost:59745/product/1 | jq . $ curl -s localhost:59178/review?productId=1 | jq . $ curl -s localhost:48014/recommendation?productId=1 | jq .
在自己的环境中,使用相应的端口号。
5.2 动态负载均衡
为了避免服务故障或者临时的网络问题,通常需要多个服务实例,通过负载均衡分发请求。因为我们使用动态分配的端口和服务发现Server,可以非常容易添加新的服务实例。例如,可以简单启动一个新的review服务,动态分配一个新的端口,并自我注册到服务发现服务器(Service Discovery Server)中。
$ cd .../blog-microservices/microservices/core/review-service
$ ./gradlew bootRun
稍等片刻,第二个服务实例出现在服务发现web应用中(http://localhost:8761):
如果你运行之前的curl命令多次(curl -s localhost:8765/productcomposite/product/1 | jq .),查看2个review实例的log日志,可以发现负载均衡在2个实例之间自动处理调用请求,不必手工配置。
6. 总结
我们已经了解到Spring Cloud和Netflix OSS 组件是如何用来简化独立部署微服务协同工作的,不必人工管理每一个微服务的端口,或者人工配置路由规则。当新的实例启动之后,它们会自动被服务发现Server监测到,并通过负载均衡来接收请求。通过使用边缘服务器(Edge Server),我们可以控制什么微服务暴露给外部消费方,建立系统的API。
7. 下一步
OK,完成测试之后。接下来还有一些问题没有回答,例如:
1/ 发生故障将如何处理,如出现一个失败的微服务;
2/ 如何阻止对API的未授权访问;
3/ 如何获知微服务内部的运行图,例如为什么订单#123456没有交付?
在接下来的文章中,我们将了解如何使用电路断路器(Circuit Breaker)来提升服务弹性,使用OAuth 2 限制外部访问等等。也将了解如何使用ELK技术栈来收集所有微服务的日志,并呈现日志信息。
原文英文链接:Building microservices with Spring Cloud and Netflix OSS, part 1
译者:Rickie(RickieChina#hotmail*com)