基于Spring Cloud和Netflix OSS 构建微服务-Part 1

前一篇文章《微服务操作模型》中,我们定义了微服务使用的操作模型。这篇文章中,我们将开始使用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<List<Recommendation>> 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)

 

posted @ 2017-03-13 19:14 Rickie 阅读(...) 评论(...) 编辑 收藏