自从微服务架构开始变得火热以后,越来越多的系统被拆解成了很多个细胞一样的微服务。设想一下,如果你的系统有100个微服务构成,要对这100个微服务进行管理,这绝对是一个不小的挑战。所以紧接着又出现了一堆让人头晕眼花的概念:服务注册发现,请求链路追踪,服务熔断,服务限流,服务管控配置,服务预警。还有就是一抓一大把的开源工具:Eurake,Zuul,Ribbon,hystrix,zipkin,dubbo,Sleuth,Elastic Search,grafna,Promethues。
这样,当我们在说服务治理时,是不是把这些概念和工具都用上了就能够很好的治理这100多个微服务了?稍微用Google或者baidu搜索一下“服务治理”这个关键字,就很容易发现其实整个社区对服务治理都没有形成一个共识,有人理解的服务治理是基于dubbo的服务注册和服务发现,有人理解的服务治理是一整套从请求网关,服务配置中心到日志中心架构体系。
所以这篇文章我想从现在的现象出发,分析这些概念和这些工具究竟是在解决什么问题,然后再尝试做一个简单的归纳和抽象,看看一个服务治理体系究竟应该解决哪些问题,而为了解决这些问题应该具备哪些能力。
服务治理的那些药
如果我们把服务治理类比成是在给一个人治病,那么上面提到的那些概念和工具,很明显就是治病的药了。既然有了这么多药了,那么不妨让我们先从这些药下手,看看这些流行的药都能是为了解决什么问题的,然后再看看这些问题之间存在什么关联。
让我们从Netflix全家桶开始,很多微服务架构都是基于这套全家桶的。作为一个视频流媒体行业的公司,能够自主开发并向社