如何使用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 类：

（编辑：湖南网）

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