前言
我们常常会说服务化，服务化，也说了一大堆服务化的好处。
一下子让我们觉得服务化是一个很高大上的东西，然后吹牛的人有讲了很多看上去非常NB的大道理。
对于一些新手来说，一下子觉得服务化后，我的架构就是万能的了。
但是对于这些没有了解过架构演变过程的新手来说，服务化其实也是一个大坑。
因为业务解耦的需要，服务化诞生了，但是因为服务化而出现的代码冗余会导致服务维护难度的成倍上升。
灾难的发生
有一天，服务A挂了，服务B和服务C都需要服务A的支持，但是服务B、C并不知道A挂了，导致服务B、C的请求阻塞越来越严重，最后都挂了。
经过这次的教训，服务B和服务C的团队都学聪明了，然后制定了一个方案。
周期性对服务A进行健康检查，例如：一分钟check一次
发现服务不可用时，则将服务设为不可用状态，如果健康检查通过，则又将状态变为可用
服务不可用时，发送警报
发现服务不可用时，不在等待，直接抛出异常
随着业务的不断扩大，服务D，服务E相继出现。他们也都需要服务A的支持。
这个时候，服务A改了个端口。就需要通知所有调用他的服务，哪些调用了服务A呢？不知道，那就只有都通知了。
慢慢的，服务A被使用的范围越来越广，服务A换了个端口，B/C/D/E全部跟着改，服务A换了台服务器，B/C/D/E跟着改。
服务A的团队终于承受不下去了，不行，我们要开会像个解决方案了。
现在很多人都在用服务A，我们要能够解决服务A地址变化了，能通知到所有服务消费者。
之前B、C服务对服务A做的管理，其实很公用，我们其他服务都可以使用。
我想在调用服务的时候读写能够分离，读用XX.XX.XX.1，写用XX.XX.XX.2，恩，那就来个路由吧。
服务治理
根据我们开会时候提出的问题，我们整理出了服务治理的方案。
我们服务治理中心，需要一个注册中心，统计都有哪些人提供了哪些服务，然后消费者，在启动服务的时候，像注册中心发送请求，我们需要哪些服务，注册中心推送提供者的服务信息。
我们服务治理中心，需要一个监控中心，统计各个服务提供的次数、服务响应的时间、服务的健康状态。
服务提供者和服务消费者之间通信，我们就别走 http 了，我们改成自定义协议，自己封装一套
rpc 协议才是我们的良药，这样我们就像在使用本地方法一样调用远程的方法了，最好是服务提供者和服务消费者之间使用长连接，减少每次请求连接的时间消耗和网络I/O。这个rpc协议也由我们服务治理还给大家指定吧。
OK，经过治理，我们的服务终于能够有序的维护及增长了。