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

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

文章插图

在微服务的演进过程中，为了最大化利用微服务的优势，保障系统的高可用性，需要通过一些服务支撑组件来协助服务间有效的协作，这便是服务治理的范畴。
服务注册与发现服务化可以降低各系统间的高度耦合，使系统更易于维护和水平扩展，可以通过流控、隔离、降级等手段保障系统的可用性，以下是有货的服务化设计。

文章插图

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

文章插图

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

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

服务调用客户端服务调用客户端为服务提供了透明化和高效的RPC远程调用，将服务的注册与发现，服务调用的负载均衡以及服务的隔离和容错等服务治理策略内嵌其中，并提供服务监控和治理能力。本文采用hystrix命令模式封装REST调用，将服务的隔离、超时、限流、降级、负载均衡等策略持久化到Zookeeper上，以服务发现的方式发现服务的治理策略，并将策略应用到服务调用中，将服务的成功和失败通过Spring异步事件通知上报到influxDB中。
服务治理服务监控Hystrix DashboardHystrix 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=defaultturbine.instanceUrlSuffix=:8080/gateway/hystrix.streamturbine.ConfigPropertyBasedDiscovery.default.instances=10.66.70.1,10.66.70.2,10.66.70.3

文章插图

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