服务治理

自从微服务架构开始变得火热以后，越来越多的系统被拆解成了很多个细胞一样的微服务。设想一下，如果你的系统有100个微服务构成，要对这100个微服务进行管理，这绝对是一个不小的挑战。所以紧接着又出现了一堆让人头晕眼花的概念：服务注册发现，请求链路追踪，服务熔断，服务限流，服务管控配置，服务预警。还有就是一抓一大把的开源工具：Eurake，Zuul，Ribbon，hystrix，zipkin，dubbo，Sleuth，Elastic Search，grafna，Promethues。

这样，当我们在说服务治理时，是不是把这些概念和工具都用上了就能够很好的治理这100多个微服务了？稍微用Google或者baidu搜索一下“服务治理”这个关键字，就很容易发现其实整个社区对服务治理都没有形成一个共识，有人理解的服务治理是基于dubbo的服务注册和服务发现，有人理解的服务治理是一整套从请求网关，服务配置中心到日志中心架构体系。
所以这篇文章我想从现在的现象出发，分析这些概念和这些工具究竟是在解决什么问题，然后再尝试做一个简单的归纳和抽象，看看一个服务治理体系究竟应该解决哪些问题，而为了解决这些问题应该具备哪些能力。

服务治理的那些药

如果我们把服务治理类比成是在给一个人治病，那么上面提到的那些概念和工具，很明显就是治病的药了。既然有了这么多药了，那么不妨让我们先从这些药下手，看看这些流行的药都能是为了解决什么问题的，然后再看看这些问题之间存在什么关联。

让我们从Netflix全家桶开始，很多微服务架构都是基于这套全家桶的。作为一个视频流媒体行业的公司，能够自主开发并向社区贡献了这么多工具是我们应该表示感谢和敬意的。由于现在在使用这些工具的时候都是使用Spring Cloud封装好的模块，所以下面基于Spring cloud 的工具栈来进行介绍：

• Eureka，这是一个用来注册服务的工具，通过简单的配置，在服务启动的时候就会自动注册到Eureka服务器上。
• Hystrix，这是一个用来保护服务的熔断工具，虽然最近宣布已经停止维护更新了。
• Zuul，这是一个用来对请求进行路由的服务网关工具，最近的zuul2采用了Netty实现了异步非阻塞编程模型。
• Ribbon，这是一个用来分配请求的负载均衡工具
• Feign，这是一个用来更方便调用其它服务的工具，也能进行负载均衡
• Archaius，这是一个管理配置API的工具
• Spring Cloud Config，用来对配置进行管理，可以把每个服务的配置放在远端服务器以方便进行配置修改
• Spring Cloud Sleuth，Tracing采集工具包，对Zipkin，HTrace进行了封装
• Spring Cloud Consul，封装了Consul操作，同样是用来进行服务注册发现的
• Spring Cloud Zookeeper，封装了Zookeeper，也是用来进行服务注册发现的
• Spring Cloud Gateway，给Spring MVC提供API网关功能的工具，里面也包含安全处理等特性

除了Spring Cloud和Netfix提供的这些工具以外，还有下面这些工具也经常在服务监控治理中被使用：

• Dubbo，自称是一个高性能的Java RPC框架，但是其实广泛用于服务注册发现，提供三个核心能力：面向接口的远程方法调用，智能容错和负载均衡，服务注册发现。
• logback，java日志框架，是log4j的升级版本
• ElasticSearch，虽然是一个搜索引擎和分析框架，但因为提供很好的存储和查询性能，所以经常用于日志的采集和存储
• Kibana，Elastic的可视化插件，可以配合Elastic使用可视化查询日志
• logstash，Elastic的日志分析工具
• grafna，时序性分析工具，提供漂亮的图形化界面
• Promethues，强大系统监控和报警框架，提供多维度数据模型，灵活强大的查询语句，有多种可视化图形界面
• Spring boot admin，用来管理Spring Boot应用的工具，提供可视化的用户界面
• Zipkin，分布式追踪工具，用来采集程序的延时数据
• Htrace，Apache的分布式追踪工具。
• resilience4j，用来被Hystrix指定作为熔断的替代工具。

虽然这两个长长的列表已经罗列了超过20个各种工具了，但是这20多个也仅仅是整个微服务治理生态工具链中的一小部分，你肯定还知道一些我没有列出来的工具。由于这里我们的目的并不是找出所有的药，而是想分析一下这些流行的药都有什么特点，都是治什么病的。所以就先基于这些药，看看他们的共性是什么。

如果把功能相同的进行一下归类，会发现有这样几个主要功能：

• 服务注册发现：Eurake，Dobbo，Consul，ZooKeeper
• 服务配置：Spring Cloud Config，Archaius
• 服务熔断：Hystrix，resilience4j
• 网关：Zuul，Spring Cloud Gateway
• 负载均衡：Ribbon，Feign
• 追踪工具：Sleuth，Zipkin，Htrace
• 日志采集：logback，ElasticSearch
• 监控平台：Promethues，Kibana，grafna，Spring boot admin

这样面对这些纷繁复杂的工具我们有了一个基本的划分，当然即便是这8个分类还是有点多，而且相互之间的关系也不明确，为什么会有这8个分类的原因也不清楚。下面就一起深入一下，看看这些工具之间的内在关系究竟是什么。

服务治理究竟要治的是什么？

让我们先放下微服务，像《微服务设计》那本书中说的一样，把自己想象成一个城市规划师，我们的目标不是治理微服务，而是要治理一个城市的交通，那么我们会怎么思考？

在进行城市交通规划之前首先要做的第一个事情是收集信息，要能够知道这个城市发生了什么，所以在各个路口需要安装采集探头，记录车来车往的信息。有了信息以后就需要对信息进行分析了，那么就需要可视化的图形界面，能够一眼就看出什么地方出了问题，通往哪个工厂的路坏了。发现了问题就要解决问题了，限制一下拥堵路段的流量，把去往一个公园的车辆导向到另外一个类似的公园。最后，如果把城市作为一个国家来考虑，那么每个进入这个城市的车辆都需要进行检查，看看有没有携带违禁品，最后给这些不熟悉道路的外地车规划路线。通过上面这个思考的过程，我们发现要对一个城市进行治理的时候，第一要采集信息，然后要能够对采集的信息进行监控和分析，最后根据分析的结果采取对应的治理策略。另外从整体安全的角度考虑还需要一个守门人。

因此我们也用同样的思路来思考服务治理，网关就是整个整体的守门人，日志采集，追踪工具，服务注册发现都是用来采集信息的，然后需要监控平台来展现这些采集的信息，并进行监控和分析。最后根据分析的结果采取治理策略，有的服务快撑不住了要限流，有的服务坏了要熔断，并且还能够及时的调整这些服务的配置。

下面的脑图就从这四个方面构建了一个简易的服务治理体系：
请求网关，信息采集，信息分析，治理策略

 

微服务监控治理

服务治理体系

作为对当前服务治理领域各种纷繁复杂工具的一次简单梳理，这个体系不一定是完全准确的。但是总不能每次说到服务治理的时候我们都把几十个工具拿出来看看能用哪个工具吧。我希望达到的目的是，当大家需要对微服务进行治理和监控的时候，能够用这个简易的体系做个参考，明确的知道在请求网关，信息采集，信息分析，治理策略这四个方面还缺少了什么东西。
当然，如果你发现除了这四个方面以外还缺少了什么东西，也非常欢迎提出来进行探讨，希望能够通过讨论得到一个更好的服务治理体系。

转自：https://www.jianshu.com/p/dd818114ab4b