京小东实习记

我目前对京东的后台业务理解主要是三种，一种是作为web的后端与数据库交互最后给前端显示。一种是用Spring的定时器执行定时任务，比如过滤邮件或者邮件排期发送。还有一种就是基于RPC框架，将自己的服务注册上去，让其他业务方来调用。

下面是我出于提升自己对RPC框架的认识而在闲暇时间做的一些学习任务，在这里和大家分享一下。

Dubbo是一个高性能优秀的服务框架现（已加入Apache项目中），使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和 Spring框架无缝集成。京东也有一个基于这样的框架做了定制和改进的JSF，那我们为什么要提出这样的一个RPC框架呢？

（互联网架构演变）

讲的使我们要透彻的理解一篇文章，就必须要知道作者的生平际遇。

互联网架构亦是如此，经历了 单一应用架构 、 垂直应用架构、分布式服务架构和流动计算架构 。

服务的粒度越来越细化（比如以前一个网站后端只需要一个tomcat运行一个Servlet程序，现在前端一个请求过来，后端会有很多个tomcat容器分别运行着不同的Servlet，他们之间相互调用，最后再有第一个Servlet返回给前端），服务治理的问题就越发的明显，所以优秀的架构师们就在思考可不可以有这么一个优秀的架构替我们解决服务之间的调用问题？

当然了，如果能高可用就更好了。要是有负载均衡就最好不过了。因此，我们的Dubbo框架就呱呱坠地了。

（Dubbo架构）

Provider : 暴露服务的服务提供方

Consumer : 调用远程服务的服务消费方

Registry : 服务注册与发现的注册中心

Monitor : 统计服务的调用次数和调用时间的监控中心

Container : 服务运行容器

Dubbo大体的流程是这样的：

先用容器Container（当下以Docker为代表的应用级虚拟化技术，为了容易理解可以粗糙的以为一个虚拟机）启动我们的服务Provider。

然后将其IP(192.169.0.1)注册到注册中心Registry去（通常我们会采用ZooKeeper这样的分布式应用服务协调程序）。

接着我的服务调用方Comsumer就会去注册中心去订阅Subscribe相关服务。

注册中心会以异步的方式将你消费者需要的服务的地址列表推送Notify给你。

消费者就会将整个地址列表缓存在本地，当业务需求到来时，就会使用地址列表里的地址去请求相关的服务程序 。

至于Monitor顾名思义就是监视器的含义，消费者和提供者会定时将服务的调用次数和被调用的次数发送给监视器。

Provider：

（服务接口）

（服务接口实现类）

（Provider.xml(配置文件)）

服务接口实现类 就是我们真正Provider要执行的逻辑，可能有人会问，为什么我们要写一个接口类？不写可不可以？这是一个好问题。

如果单纯的看Provider确实没有写这么一个接口的必要，但是对于Consumer来讲意义就大不相同了。

RPC(Remote Procedure Cal)远程过程调用的目的就是要即便Consumer和Provider不是运行在同一台机子上，但是对于Consumer来讲就是像调用本地方法一样去调用Provider，所以Consumer至少得有Provider的接口，这样Comsumer才能知道Provider有哪些方法，至于具体怎么做后面会解释，请稍安勿躁。

接着，解释一下 配置文件 的含义

：用于配置当前应用信息，不管该应用是提供者还是消费者

：用于配置连接注册中心相关信息

：用于配置提供服务的协议信息，协议由提供方指定，消费方被动接受

：用于暴露一个服务，定义服务的元信息，一个服务可以用多个协议暴露，一个服务也可以注册到多个注册中心

Consumer：