RGC（微服务体系）

1.如果没有微服务体系就要重新开发这些模块。不止如此在开发时每个部门还有很多注意事项，不如数据库那个字段不能更改，还有要熟悉不同部门的业务。解决办法就是利用微服务体系将模块独立出去（和工具类不同，工具类是将代码合成）减少开发时间，相同的功能模块直接应用，开发效率提升。

2.大公司内部系统很多，每个系统有功能相同的模块（登陆退出，短信功能，系统大部分功能模块相同）比如一个系统要100个功能模块，两百个系统可能也只需要120个模块。

3.大公司才有微服务体系，小公司不会性价比不值，重复率小 。

4.dubbo、spring cloud：dubbo速度快，功能模块少，spring cloud功能全，速度慢（

传输协议影响速度：前者java基础自定义tcp将多余的协议砍掉，后者HTTP协议）

5中央管理系统，中央展示平台（记录生产者 部门 ip 功能），消费者（调用方，需要到中央管理平台注册，注册信息部门团队，干什么，调用那个功能模块，每分钟调用量最高，存贮着生产者ip），生产者（功能模块，对消费者申请调用量对服务器经行扩展），

如果某一个消费者调用量很大，生产者崩溃，每分钟调用量最高限制防止崩溃，

6生查找的轮询功能表示自己还活着（如果每个机器十次二十次没有发送表示已经坏掉了）当然也可以新增生产者

7访问

访问是生产者直接访问到生产者，但是没一段时间回去中央管理中心去更新数。消费者（即能更新消费者变化，报备自己活着）

8

几秒生产者轮询和几秒消费者访问中央处理器的时间查问题，如果有一个正在调用的生产者服务器宕机。如果不做处理，就会出现问题.

我们在消费者调用生产者的请求的时候用try catch处理，一次失败可能是网络的原因等，我们在try请求一次，在失败catch将请求打到其他两台服务器上，在未恢复之前，以后请求也不会在请求坏掉的生产者。

假如消费者有三百个次请求，原来每个生产者会分配一百次，现在出问题会解决后只有两个生产者每个解决一百五十个情求。

然后消费者本地ip更改，同时向中央管理平台警告，中央管理平台查询（连环调用）生产者，如果没有相应