Dubbo的一些思考

总览
众所周知，dubbo是一个分布式RPC框架，主要解决服务间互相调用的问题。调用其实类似接口调用，如果想要调用不同服务器上的接口可以使用HTTP直接调用的方法，但是这种方法的开销很大，并且不好处理远程调用中出现的各种问题（超时重试、负载均衡等等），也不方便监控服务端的存活情况，接口调用的次数等等。而dubbo有着自己的监控中心来监控服务端和消费端之间交互的次数、注册中心来引导消费端均衡、高可用的调用服务端的服务。并且支持多种网络编码方式，在特定的使用场景可以灵活配置为更适合的网络编码方式。dubbo可以看作是分布式开发连接各个模块的纽带。
使用dubbo的好处
要使用dubbo，首先要对项目进行拆分，一个项目当达到一定量级后，单一系统所承载的并发量、维护成本、开发成本都会成倍上升。即使有很小的改动，部署时也需要重新部署全部代码，这时候就有可能引发各种各样的开发冲突问题。而拆分后的系统，每次只需要重新部署改动的那一个模块的代码，并且只要保持接口不变，其他模块就不会收到影响。
如何进行系统拆分
其实这就有点像业务方面的拆分，先按照模块拆，然后按照模块中的功能拆…以此类推。拆分到单个模块可以很方便的进行开发维护即可。拆分并不是越细越好，而是为了系统能维持在一个开发和维护同时高效的情况下。
拆分后为什么要用dubbo
使用SpringMVC的http直接调用其实也可以，但是远程调用中会发生超时、这时候dubbo有自己的容错机制来对应，而http就需要开发人员手动去处理，很不方便。或者说，消费端和服务端都有多个，怎么能让消费端的请求均衡的落在各个服务端上，这些问题dubbo都有对应的负载均衡机制去解决，而http则没有。dubbo也是一种工具，集成了一些功能来解决一些问题。