我的天，你们公司的“微服务”简直就是反人类…
|
①服务注册与发现 目前 Spring Cloud 支持的服务注册组件有： Consul Eureka Consul 不是 Spring 官方的项目，需要单独部署，Eureka 被 Spring 官方收录，本身属于 Spring Cloud 体系中。 下面列出可以被用作注册中心的组件，他们的特性对比：
Consul 官网中介绍了 Consul 的以下几个核心功能： 服务发现(Service Discovery)：提供 HTTP 与DNS 两种方式。 健康检查(Health Checking)：提供多种健康检查方式，比如 HTTP 状态码、内存使用情况、硬盘等等。 键值存储(KV Store)：可以作为服务配置中心使用，类似 Spring Cloud Config。 加密服务通信(Secure Service Communication)。 多数据中心(Multi Datacenter)：Consul 通过 WAN 的 Gossip 协议，完成跨数据中心的同步。 Consul 需要单独部署，而不是与 Spring 集成的组件。 Eureka 是 Spring Cloud NetFlix 默认的服务发现框架，但目前 2.0 版本已闭源，只剩下 1.9 版本的处于维护状态。 Eureka 使用尽力而为同步的方式提供弱一致的服务列表。当一个服务注册时，Eureka 会尝试将其同步到其他节点上，但不提供一致性的保证。 因此，Eureka 可以提供过时的或是已不存在的服务列表(在服务发现场景下，返回旧的总比什么也不返回好)。 如果在 15 分钟内超过 85% 的客户端节点都没有正常的心跳，那么 Eureka 就会认为客户端与注册中心出现了网络故障(出现网络分区)，进入自我保护机制。 此时： Eureka Server 会保护服务注册表中的信息，不再删除服务。这是由于如果出现网络分区导致其他微服务和该 Eureka Server 无法通信，Eureka Server 就会判定这些微服务失效，但很可能这些微服务都是健康的。 Eureka Server 仍能接受新服务的注册和查询请求，但这些数据不会被同步到其他节点。 当网络恢复时，这个 Eureka Server 节点的数据会被同步到其他节点中。 优点：Eureka Server 可以很好的应对因网络故障导致部分节点失联的情况，而不会像 ZK 那样如果有一半不可用的情况会导致整个集群不可用。 ②服务网关 微服务的拆分导致服务分散，如果一个大的业务要对外提供输出，每个服务单独对外提供调用对接入方不友好并且调用也会很复杂。 所以出现了网关，网关主要实现请求的路由转发，负载均衡，统一校验，请求过滤等功能。 目前社区主流的网关有三个： Zuul Kong Spring Cloud GateWay Zuul：是 Netflix 公司的开源项目，Spring Cloud 在 Netflix 项目中也已经集成了 Zuul，依赖名叫：spring-cloud-starter-netflix-zuul。 Zuul 构建于 Servlet 2.5，兼容 3.x，使用的是阻塞式的 API，不支持长连接，比如 Websockets。 我们现在说的 Zuul 指 Zuul 1.x，Netflix 最新的 Zuul 2.x一直跳票，所以 Spring Cloud 在 Zuul 2.x 没有出的时候依靠社区的力量发展出了新的网关组件：Spring Cloud Gateway。 Zuul 的核心功能就是基于 Servlet 提供了一系列的过滤器： 身份认证与安全：识别每个资源的验证要求，并拒绝那些与要求不符的请求。 审查与监控：在边缘位置追踪有意义的数据和统计结果，从而带来精确的生产视图。 动态路由：动态地将请求路由到不同的后端集群。 压力测试：逐渐增加指向集群的流量，以了解性能。 负载分配：为每一种负载类型分配对应容量，并启用超出限定值的请求。 静态响应处理：在边缘位置直接建立部分响应，从而避免其转发到内部集群。 Spring Cloud Gateway：构建于 Spring 5+，基于 Spring Boot 2.x 响应式的、非阻塞式的 API。 同时，它支持 Websockets，和 Spring 框架紧密集成，开发体验相对来说十分不错。 Spring Cloud Gateway 是基于 WebFlux 框架实现的，而 WebFlux 框架底层则使用了高性能的 Reactor 模式通信框架 Netty。 总体来说，Spring Cloud Gateway 与 Zuul 功能差别不大，最大的出入是在底层性能的提升上。 Zuul 本身是基于 Servlet 容器来实现的过滤，Servlet 采用的是单实例多线程的处理方案，Servlet 会为每一个 Request 分配一个线程。 如果当前线程比较耗时那么会一直等到线程处理完毕才会返回。所以说 Zuul 是基于 Servlet 之上的一个阻塞式处理模型。 同步阻塞模型对于网关这种比较在意响应耗时和调用频繁的组件来说，必然会引发一些性能问题，所以 Zuul 2 已经做出了改良，从 Zuul 2 开始已经使用 Netty。 但是不幸的是 Spring 官方已经对它的更新频率感到失望，所以纵然更新了也没有被选用。 Spring Cloud Gateway 底层基于 Webflux。Webflux 模式替换了旧的 Servlet 线程模型。 用少量的线程处理 request 和 response io 操作，这些线程称为 Loop 线程。 Webflux 的 Loop 线程，正好就是著名的 Reactor 模式 IO 处理模型的 Reactor 线程，如果使用的是高性能的通信框架 Netty，这就是 Netty 的 EventLoop 线程。 所以整体来看，Spring Cloud Gateway 的性能要比目前在用的 Zuul 高。但是 Webflux 的编程方式可能大家不是很能接收。 ③服务降级 降级限流在微服务中属于银弹，一般不用，一旦用上那就是拯救宇宙般存在。 目前业界通用的降级限流工具主要有三款： Hystrix Sentinel Resilience4j Hystrix 的关注点在于以隔离和熔断为主的容错机制，超时或被熔断的调用将会快速失败，并可以提供 Fallback 机制。 Hystrix 是元老级别的存在，但是在 2018 年 11 月 Netflix 官方宣布停止更新(就是这么不靠谱，说跳票就跳票)。虽然停止更新，但是社区又推出了新的替代工具：Resilience4j。 Resilience4j 的模块化做的比较好，将每个功能点(如熔断、限速器、自动重试)都拆成了单独的模块。 这样整体结构很清晰，用户也只需要引入相应功能的依赖即可;另外 Resilience4j 是针对 Java 8 和函数式编程设计的，API 比较简洁优雅。 同时与 Hystrix 相比，Resilience4j 增加了简单的限速器和自动重试特性，使用场景更加丰富。 相比 Hystrix ， Resilience4j 的优势在于： 针对 Java 8 和函数式编程设计，提供函数式和响应式风格的 API。 增加了 rate limiting 和 automatic retrying 两个模块。其中 rate limiting 引入了简单的速率控制实现，补充了流量控制这一块的功能。 而 automatic retrying 则是封装了自动重试的逻辑，简化了异常恢复的流程。 Resilience4j 属于一个新兴项目，社区也在蓬勃发展。总的来说，Resilience4j 是比较轻量的库，在较小较新的项目中使用还是比较方便的。 但是 Resilience4j 只包含限流降级的基本场景，对于非常复杂的企业级服务架构可能无法很好地 cover 住。 同时 Resilience4j 缺乏生产级别的配套设施(如提供规则管理和实时监控能力的控制台)。 Sentinel 是一款面向分布式服务架构的轻量级流量控制组件，主要以流量为切入点，从流量控制、熔断降级、系统自适应保护等多个维度来帮助用户保障服务的稳定性。 Sentinel 的核心思想：根据对应资源配置的规则来为资源执行相应的流控/降级/系统保护策略。在 Sentinel 中资源定义和规则配置是分离的。 用户先通过 Sentinel API 给对应的业务逻辑定义资源，然后可以在需要的时候动态配置规则。 整体功能对比： （编辑：源码网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
