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