分布式服务框架

1 引言 在eos中，一般我们都有client和server两个应用，server端写了服务PersonService，在client中直接可以调用，上代码： PersonService service = com.sunsharing.eos.client.ServiceContext.getBean(PersonService.class); Map map = service.exportData(batchNo,key)); 这时想起类似的两个场景： 1）随着页面的复杂，服务越来越多，部署在不同的机器上，如何简单方便的让远程服务的调用如同本地服务调用一般？ 2）甚至可以联想到前端ajax的调用，浏览器端如何调用后端所写的服务？ 上述有几点表现： 客户端与服务端分属不同空间内存区域 透明调用机制让使用者不必显式的区分本地调用和远程调用 说了这么多，其实，我只是想聊聊RPC... 2 何为RPC RPC（Remote Procedure Call Protocol），即远程过程调用。通俗的讲，两台服务器A，B，一个应用部署在A服务器上，想要调用B服务器上应用提供的函数/方法，由于不在一个内存空间，不能直接调用，需要通过网络来表达调用的语义和传达调用的数据。RPC让构建分布式计算（应用）更容易，在提供强大的远程调用能力时不损失本地调用的语义简洁性。 一个简单RPC的过程是这样的：

互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行， Dubbo 是一个分布式服务框架，在这种情况下诞生的。 现在核心业务抽取出来，作为独立的服务，使前端应用能更快速和稳定的响应。 第一：介绍Dubbo背景 大规模服务化之前，应用可能只是通过 RMI 或 Hessian 等工具，简单的暴露和引用远程服务，通过配置服务的 URL 地址进行调用，通过 F5 等硬件进行负载均衡。 (1) 当服务越来越多时，服务 URL 配置管理变得非常困难， F5 硬件负载均衡器的单点压力也越来越大。 此时需要一个服务注册中心，动态的注册和发现服务，使服务的位置透明。 并通过在消费方获取服务提供方地址列表，实现软负载均衡和 Failover ，降低对 F5 硬件负载均衡器的依赖，也能减少部分成本。 (2) 当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。 这时，需要自动画出应用间的依赖关系图，以帮助架构师理清理关系。 (3) 接着，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？ 为了解决这些问题，第一步，要将服务现在每天的调用量，响应时间，都统计出来，作为容量规划的参考指标。 其次，要可以动态调整权重，在线上