简单说说服务治理

一般在系统比较小或者业务初期，传统的系统就是一个单机的J2EE，分为DB层、业务层、接入层。

这种结构在较小项目或者初期能够满足绝大部分需求，但是随着业务量或者用户量的增加，发现这种原始结构以及无法满足，可能是业务层的业务逻辑过重，也可能是用户规模的扩大，导致单机已经无法满足。因此需要进行分布式拆分，一般都会想到按照业务模型，将业务层拆分成各个模块，分别部署，各个模块之间通过RPC之类的协议调用。这样好处是各个模块只关心自己的业务逻辑，同时各个模块之间也会能够起到解耦的好处。

模块提供的是服务，依赖该模块的业务通过TCP、UDP、HTTP等获取服务，随着业务规模的不断扩大，单个模块可能会遇到两种情况：1、单个模块被多个其他模块依赖；2、单个模块需要做主备或者负载均衡。这是就会遇到如下一些问题

1、模块有可能不知道被哪些模块调用，比如A模块被B、C、D依赖，有可能后期又加了E、F；更有胜者，后期C不依赖与A了;

2、模块的调用方，需要自己做负载均衡策略，比如A模块有两个节点A1、A2，如果B依赖于A，需要在自己的业务实现负载均衡；这本身对B来说显得非常多余，不能专注于自身的业务逻辑;

3、.....

基于以上原因，需要对各个服务做治理，这也是就为什么有了dubbo这类服务治理框架，它与其他RPC框架相比（例如thrift,avro)，不仅仅提供了透明的服务调用，而且还提供了服务治理，比如上述的调用统计管理、负载均衡，这样每个业务模块只需专注于自己的内部业务逻辑即可。

但是，并不是每个系统都需要这种服务治理框架，比如本身就一个单独的业务模块，且调用方也很少，这个时候，使用这种服务治理显得稍微有些笨重。

总之，服务是由于业务规模的不断扩大产生的，服务治理也是根据服务的规模不断扩张产生的，因此服务治理也只有到了一定规模才能显示出其真正作用。