微服务太多怎么办？简单聊聊微服务治理

在分布式架构中，服务间的依赖非常常见，一个业务调用通常依赖多个基础服务。如下图， 对于同步调用，当会员服务不可用时，订单服务请求线程被阻塞，当有大批量请求调用会员服务时， 最终可能导致整个会员服务资源耗尽，无法继续对外提供服务。并且这种不可用可能沿请求调用链向上传递，从而引发服务间的雪崩效应。

在微服务的演进过程中，为了最大化利用微服务的优势，保障系统的高可用性，需要通过一些服务支撑组件来协助服务间有效的协作，这便是服务治理的范畴。

服务注册与发现

服务化可以降低各系统间的高度耦合，使系统更易于维护和水平扩展，可以通过流控、隔离、降级等手段保障系统的可用性，以下是有货的服务化设计。

对于微服务的治理而言，核心就是服务的注册和发现。所以选择哪个组件，很大程度上要看它对于服务注册与发现的解决方案。在这个领域，开源架构很多，最常见的是Zookeeper和Eureka。采用Zookeeper做为注册中心时，由于Zookeeper CP(一致性和分区容错性)的设计方式，需要做高可用的补充，一般采用在调用端缓存服务提供者信息。

负载均衡

将负载均衡的功能以库的形式集成到服务消费中。服务消费者需要访问某服务时，需要通过内置的负载均衡组件向服务注册中心查询，得到可用的服务提供者列表，然后按照某种负载均衡策略选择一个目标服务地址，最后向目标服务发起请求。

• 随机策略：
  从可用的服务节点随机选取一个节点调用。
• 轮询策略：
  对可用的服务节点列表按顺序依次调用。
• 加权轮询策略：
  按照固定的权重，对可用服务节点进行轮询。
• 最小活跃数策略：
  对各可用服务节点的请求数计数，选择连接数小的节点调用。
• 本地优先策略：
  服务的调用者和提供者有可能被部署在同一台机器上，可通过本地调用减少网络调用中性能损耗。

服务调用客户端

服务调用客户端为服务提供了透明化和高效的RPC远程调用，将服务的注册与发现，服务调用的负载均衡以及服务的隔离和容错等服务治理策略内嵌其中，并提供服务监控和治理能力。本文采用hystrix命令模式封装REST调用，将服务的隔离、超时、限流、降级、负载均衡等策略持久化到Zookeeper上，以服务发现的方式发现服务的治理策略，并将策略应用到服务调用中，将服务的成功和失败通过Spring异步事件通知上报到influxDB中。

服务治理

服务监控

Hystrix Dashboard

Hystrix Dashboard主要用来实时监控Hystrix的各项指标信息。通过Hystrix Dashboard反馈的实时信息，可以帮助我们快速发现系统中存在的问题。

集群环境监控可使用Netflix提供的turbine进行监控。通过maven公服https://search.maven.org下载并部署war包turbine-web，修改集群节点配置，将turbine地址 http://localhost{port}/turbine.stream?cluster=default 添加监控到hystrix dashboard

turbine.aggregator.clusterConfig=default
turbine.instanceUrlSuffix=:8080/gateway/hystrix.stream
turbine.ConfigPropertyBasedDiscovery.default.instances=10.66.70.1,10.66.70.2,10.66.70.3

Hystrix Dashboard通过颜色的变化代表了实例的健康程度，它的健康程度从 绿色 > 黄色 > 橙色 > 红色 递减； 该实心圆除了颜色的变化之外，它的大小也会根据实例的请求流量发生变化，流量越大实心圆就越大，所以通过该实心圆的展示，就可以在大量实例中快速的发现故障实例和高压力实例。

grafana监控

通过Spring拦截器记录服务的调用日志，并采集日志分析上报到influxDB中，通过grafana将服务调用信息近实时可视化。

服务发现客户端采集服务调用的成功及失败请求经Spring异步事件上报到influxdb，由grafana将监控数据可视化，并推送服务异常的告警信息。

服务治理

服务调用客户端的服务发现与治理的类UML图如下：

服务治理平台管理各服务的资源组，并把核心业务独立出单独的资源组进行管理。监控各服务调用的压力、平均耗时、错误数、调用趋势等信息，并可以对单个服务的超时、限流、降级、资源池、负载均衡策略进行都动态调整。

资源隔离

对服务调用实行线程池隔离，避免不同的服务失败导致线程被耗尽产生故障传播，对于部分核心流程如登录、注册、商品信息、下单支付等可在原线程隔离基础上再隔离出单独的线程池，保障核心业务不受影响。

熔断

可对不同的接口请求应用不同的超时策略，超时后直接熔断走服务降级逻辑，避免服务被拖垮。依赖服务异常次数超限后直接熔断，通过hystrix定时检查服务是否恢复。

降级

在服务调用失败、超时、熔断器开路、线程池或信号量容量超额，服务执行后备逻辑，支持服务的failfast和failsafe等容错。

限流

基于网关的服务限流措施，可结合Nginx限流使用，避免流量高峰期的系统过载过高，影响核心业务的运行。

负载均衡策略

可对不同的服务应用不同的负载均衡策略，可选择轮询、加权轮询、随机、本地优先和最小活跃数等策略。

Service Mesh

Service Mesh（服务网格） 是一个基础设施层，用于处理服务间通信。Service Mesh 实际上就是处于 TCP/IP 之上的一个抽象层。在实际应用当中，Service Mesh 通常是由一系列轻量级的网络代理组成的，它们与应用程序部署在一起，但应用程序不需要知道它们的存在。Service Mesh 是一种新的服务治理思想，它是把对服务的治理由应用层下沉到基础服务层。

Service Mesh作为一个独立的代理进程部署在每一台主机上，主机上的多个服务消费者（Consumer）应用可以共用这个代理来实现服务发现和负载均衡。

Service Mesh将负责服务发现、负载均衡、熔断限流等相关逻辑从原有的消费客户端进程拆分到单独的代理进程中，由这个独立部署的代理来负责服务发现、路由分流（负载均衡）、熔断限流、安全控制、监控等功能。

Service mesh 有如下几个特点：

• 应用程序间通讯的中间层
• 轻量级网络代理
• 应用程序无感知
• 解耦应用程序的重试、超时、监控、追踪和服务发现

目前Service Mesh的开源解决方案有：Buoyant 公司推出的 Linkerd 和 google、IBM 等厂商牵头的 Istio。Linkerd 更加成熟稳定些，Istio 功能更加丰富、设计上更为强大，社区相对也更加强大一些。

本文转载于博客园，原文：https://www.cnblogs.com/qingfengEthan/p/12633149.html