理解服务治理

为什么不是服务管理，而是服务治理？

治理意味着建立和执行工作组为了一起工作而一致同意的工作指南。

治理重在建立决策，而管理重在贯彻执行决策。

怎么理解服务治理？

服务治理发展过程：开始是单体服务，随着业务和访问量增大，架构发生变化，垂直划分，达到解耦和的目的。但是随着应用的进一步增加，也就是引入SOA，出现了服务相互调用的情况，这个时候可以使用简单的RMI或RPC，通过配置服务的URL地址进行调用。嗯还不错。

但是业务进一步增加，配置URL对于地址的管理变得复杂，很乱，不好梳理。这时，迫切需要一个注册中心，动态的注册和发现服务，URL地址神马的都不用我来管了。消费者，只需要获取提供者的地址列表，就可以实现软负载均衡和failover。

这就是服务治理概念出现的背景。

服务治理是主要针对分布式服务框架，微服务，处理服务调用之间的关系，服务发布和发现（谁是提供者，谁是消费者，要注册到哪里），出了故障谁调用谁，服务的参数都有哪些约束（尤其是dubbo.xml配置），如何保证服务的质量？如何服务降级和熔断？怎么让服务受到监控，提高机器的利用率？

服务治理的工具还有哪些？

Dubbo：主要介绍

Spring Cloud Eureka：暂不介绍

Dubbo是什么？

一想Dubbo是什么，首先想到的就是Dubbo的架构图，包括注册中心、提供者、消费者、监控中心，然后就是他们之间的关系。

通过web容器将服务提供者启动，将服务注册到zookeeper上；

服务消费者在启动后也会把自己注册到zookeeper上；

如果注册中心检测到提供者有什么变化，会通知消费者；

消费者从注册中心获取到的提供者地址列表，采用软负载均衡算法，选择一个提供者调用，这样做的好处是，一个提供者调用失败，就可以选择另外一个；

服务提供者和消费者，在内存中累计调用次数和调用时间，会以心跳的方式，发送给监控中心；

zookeeper是什么？

ZooKeeper 是一个开源的分布式协调服务，由雅虎创建，是 Google Chubby 的开源实现。分布式应用程序可以基于 ZooKeeper 实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、配置维护，名字服务、分布式同步、分布式锁和分布式队列等功能。

为什么选择zookeeper作为dubbo的注册中心？

因为zookeeper是树形结构，里面都是一个个的ZNode组成，而且是运行在内存中的，性能会非常高

一般在线上都会搭建一各zookeeper集群，保证高可用的同时，就是能够稳定提供发布订阅功能。

总结：系统开始由单体系统到编程面向服务（SOA）成为分布式系统之后，为了让服务调用更清晰，不需要人员再写URL，并且费劲儿的梳理，使用Dubbo+zk这样的服务治理工具是非常必要的。了解它内部都有什么，有助于以后出现问题有排查思路。

里面都是个人理解Dubbo，更官方的说法，去看官网

参考摘自：https://javatar.iteye.com/blog/517767