如何使用Spring Cloud构建微服务架构？

　　@Target(ElementType.TYPE) @Retention(RetentionPolicy.RUNTIME) @Documented @Inherited @SpringBootApplication @EnableDiscoveryClient @EnableCircuitBreaker public @interface SpringCloudApplication {}

　　接下来，需要引入一个新的服务类来封装 Hystrix 提供的断路器保护功能，主要是定义当故障发生时需要执行的回调逻辑，即代码中指定的 fallbackMethod：

　　@Service public class ConsumerService { @Autowired RestTemplate restTemplate; @HystrixCommand(fallbackMethod = "consumerFallback") public String consume() { return restTemplate.getForEntity("http://demo-service/demo", String.class).getBody(); } public String consumerFallback() { return "error"; } } @RestController public class ConsumerController { @Autowired ConsumerService consumerService; @RequestMapping(value = "/demo-consumer", method = RequestMethod.Get) public String helloConsumer() { return consumerService.consume(); } }

　　服务监控

　　微服务架构将服务的粒度分解的足够细，这使得它在保证服务足够灵活、足够独立的优势下，也带来了管理和监控上的挑战，服务与服务之间的依赖也变得越来越复杂。因此，对服务健康度和运行指标的监控就变得非常重要。

　　Hystrix 提供了 Dashboard 用以监控 Hystrix 的各项指标信息。为了监控整个系统的微服务，我们需要为 Hystrix Dashboard 建立一个 Spring Boot 微服务。

　　在该服务项目的 pom 文件中，添加如下依赖：

　　<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-hystrix</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-hystrix-dashboard</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-actuator</artifactId> </dependency>

　　服务的 Application 类需要添加 @EnableHystrixDashboard，以启用 Hystrix Dashboard 功能。

　　同时，可能需要根据实际情况修改 application.properties 配置文件，例如选择可用的端口号等。

　　如果要实现对集群的监控，则需要加入 Turbine。

　　API 网关

　　理论上，客户端可以直接向每个微服务直接发送请求。但是这种方式是存在挑战和限制的，调用者需要知道所有端点的地址，分别对每一段信息执行 http 请求，然后将结果合并到客户端。

　　一般而言，针对微服务架构模式的系统，采用的都是前后端分离的架构。为了明显地隔离开前端与后端的边界，我们通常可以专门为前端的消费者定义更加粗粒度的 Open Service。

　　这些 Open Service 是对外的 RESTful API 服务，可以通过 F5、Nginx 等网络设备或工具软件实现对各个微服务的路由与负载均衡，并公开给外部的客户端调用(注意，内部微服务之间的调用并不需要通过 Open Service)。

　　这种对外公开的 Open Service 通常又被称为边缘服务(edge service)。

　　如果这些 Open Service 需要我们自己去开发实现并进行服务的运维，在系统规模不断增大的情况下，会变得越来越困难。

　　例如，当增加了新的微服务又或者 IP 地址发生变动时，都需要运维人员手工维护这些路由规则与服务实例列表。

　　又例如针对所有垂直分隔的微服务，不可避免存在重用的横切关注点，例如用户身份认证、授权或签名校验等机制。

　　我们不能在所有微服务中都去添加这些相同的功能，因为这会造成横切关注点的冗余。

　　解决的办法是引入 API 网关(API Gateway)。它是系统的单个入口点，用于通过将请求路由到适当的后端服务或者通过调用多个后端服务并聚合结果来处理请求。

　　此外，它还可以用于认证、insights、压力测试、金丝雀测试(canary testing)、服务迁移、静态响应处理和主动变换管理。

　　Spring Cloud 为 API 网关提供的解决方案就是 Spring Cloud Zuul，它是对 Netflix Zuul 的包装。

　　路由规则与服务实例维护

　　Zuul 解决路由规则与服务实例维护的方法是通过 Spring Cloud Eureka。

　　API Gateway 自身就是一个 Spring Boot 服务，该服务自身被注册为 Eureka 服务治理下的应用，同时它会从 Eureka 中获得所有其他微服务的实例信息。

　　这样的设计符合 DRY 原则，因为 Eureka 已经维护了一套服务实例信息，Zuul 直接重用了这些信息，无需人工介入。

　　对于路由规则，Zuul 默认会将服务名作为 ContextPath 创建路由映射，基本上这种路由映射机制就可以满足微服务架构的路由需求。

　　倘若需要一些特殊的配置，Zuul 也允许我们自定义路由规则，可以通过在 API 网关的 Application 类中创建 PatternServiceRouteMapper 来定义自己的规则。

　　横切关注点

　　诸如授权认证、签名校验等业务逻辑本身与微服务应用所要处理的业务逻辑没有直接关系，我们将这些可能横跨多个微服务的功能称为“横切关注点”。这些横切关注点往往会作为“装饰”功能在服务方法的前后被调用。

　　Spring Cloud Zuul 提供了一套过滤器机制，允许开发者创建各种过滤器，并指定哪些规则的请求需要执行哪个过滤器。

　　自定义的过滤器继承自 ZuulFilter 类。例如我们要求客户端发过来的请求在路由之前需要先验证请求中是否包含 accessToken 参数。

　　如果有就进行路由，否则就拒绝，并返回 401 Unauthorized 错误，则可以定义 AccessFilter 类：

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!