rpc

bbossgroups是国内首款集AOP、MVC、持久化、JSP标签库、分布式RPC服务、分布式事件框架于一身的企业级JavaEE开发框架，在Apache License Version 2.0 许可协议下开源。 官网地址： http://www.bbossgroups.com/ 官方博客： http://yin-bp.iteye.com/ bbossgroups包含哪些组件？主要功能？ bbossgroups包含bboss mvc、bboss ioc、bboss持久层、bboss标签库、bboss rpc、bboss 工具包、bboss event七大部分，主要功能和特色如下： aop/ioc 是整个bboss的基石，提供多种组件管理ioc容器类型，提供依赖注入（支持循环依赖注入、构造函数注入、属性注入）、组件生命周期管理、工厂模式、声明式事务配置等等。 rpc 丰富的通讯协议栈（http/netty/mina/jms/webservice/rmi/jgroups/restful)，通过restful可以轻松实现服务路由功能，服务调用安全高效，提供可插拔的安全认证和rpc方法权限检测机制，可以通过rpc框架方便地获取bboss ioc中配置的组件的远程调用代理从而实现rpc调用。 distribute event framework （基于bboss rpc框架，分布式事件框架

Finagle是Twitter基于Netty开发的支持容错的、协议无关的RPC框架，该框架支撑了Twitter的核心服务。来自Twitter的软件工程师Jeff Smick撰文详细描述了该框架的工作原理和使用方式。 在Jeff Smick的博客文章中，介绍了Twitter的架构演进历程。Twitter面向服务的架构是由一个庞大的Ruby on Rails应用转化而来的。为了适应这种架构的变化，需要有一个高性能的、支持容错的、协议无关且异步的RPC框架。在面向服务的架构之中，服务会将大多数的时间花费在等待上游服务的响应上，因此使用异步的库能够让服务并发地处理请求，从而充分发挥硬件的潜能。Finagle构建在Netty之上，并不是直接在原生NIO之上构建的，这是因为Netty已经解决了许多Twitter所遇到的问题并提供了干净整洁的API。 Twitter构建在多个开源协议之上，包括HTTP、Thrift、Memcached、MySQL以及Redis。因此，网络栈需要足够灵活，以保证能与这些协议进行交流并且还要具有足够的可扩展性以支持添加新的协议。Netty本身没有与任何特定的协议绑定，对其添加协议支持非常简单，只需创建对应的事件处理器（event handler）即可。这种可扩展性产生了众多社区驱动的协议实现，包括SPDY、PostrgreSQL、WebSockets

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的过程是这样的：

NFS，全名叫Network File System，中文叫网络文件系统，是Linux、UNIX系统的分布式文件系统的一个组成部分，可实现在不同网络上共享远程文件系统。 NFS由Sun公司开发，目前已经成为文件服务的一种标准之一（RFC1904，RFC1813）。 其最大的功能就是可以通过网络，让不同操作系统的计算机可以共享数据，所以可以把NFS看做是一个文件服务器。NFS缺点是其读写性能比本地硬盘要差一些。 一、NFS服务常见故障排查： NFS服务出现了故障，主要从以下几个方面检查原因： （1）检查NFS客户机和服务器的负荷是否太高，Server和Client之间的网络是否正常； （2）检查/etc/exports文件的正确性； （3）必要时重启NFS和rpcbind服务； （4）运行下列命令重新启动rpcbind和NFS: /etc/init.d/nfs restart/etc/init.d/rpcbind restart chkconfig nfs onchkconfig rpcbind on 注意：在RHEL/CentOS 6.x里面，portmap服务改名为rpcbind服务了；顺便说一下，rpcbind服务也是图形界面的关键基础服务，不启动此服务，不能启动图形桌面。 （5） 检查Client上的mount命令或/etc/fstab的语法是否正确; （6）

一、基础知识 1、分布式基础理论 1.1）、什么是分布式系统？ 《分布式系统原理与范型》定义： “分布式系统是若干独立计算机的集合，这些计算机对于用户来说就像单个相关系统” 分布式系统（distributed system）是建立在网络之上的软件系统。 随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，亟需 一个治理系统 确保架构有条不紊的演进。 1.2）、发展演变 单一应用架构 当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架(ORM)是关键。 适用于小型网站，小型管理系统，将所有功能都部署到一个功能里，简单易用。 缺点： 1、性能扩展比较难 2、协同开发问题 3、不利于升级维护 垂直应用架构 当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。此时，用于加速前端页面开发的Web框架(MVC)是关键。 通过切分业务来实现各个模块独立部署，降低了维护和部署的难度，团队各司其职更易管理，性能扩展也更方便，更有针对性。 缺点： 公用模块无法重复利用，开发性的浪费 分布式服务架构 当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心

有了Client 和Server，很自然就能RPC 啦。下面轮到RPC.java 啦。 一般来说，分布式对象一般都会要求根据接口生成存根和框架。如CORBA，可以通过IDL，生成存根和框架。但是，在 org.apache.hadoop.rpc，我们就不需要这样的步骤了。上类图。 为了分析Invoker，我们需要介绍一些Java 反射实现Dynamic Proxy 的背景。 Dynamic Proxy 是由两个class 实现的：java.lang.reflect.Proxy 和java.lang.reflect.InvocationHandler，后者是一个 接口。所谓Dynamic Proxy 是这样一种class：它是在运行时生成的class，在生成它时你必须提供一组interface 给它，然后 该class 就宣称它实现了这些interface。 这个Dynamic Proxy 其实就是一个典型的Proxy 模式，它不会替你作实质性的工作，在生成它的实例时你必须提供一个handler， 由它接管实际的工作。这个handler，在Hadoop 的RPC 中，就是Invoker 对象。 我们可以简单地理解：就是你可以通过一个接口来生成一个类，这个类上的所有方法调用，都会传递到你生成类时传递的 InvocationHandler 实现中。 在Hadoop 的RPC 中

Hbase的RPC主要由HBaseRPC、RpcEngine、HBaseClient、HBaseServer、VersionedProtocol 5个概念组成。 1、HBaseRPC是hbase RPC的实现类，核心方法： 　　1）、RpcEngine getProtocolEngine()：返回RpcEngine对象 　　2）、<T extends VersionedProtocol> T waitForProxy()：调用RpcEngine的getProxy()方法，返回一个远程代理对象，比如：第一次访问HRegionServer时需要执行该方法，设置代理后，会缓存该对象到HConnectionImplementation中。 2、RpcEngine接口 ，其实现类：WritableRpcEngine，核心方法： 　　1）、VersionedProtocol getProxy()：返回代理对象，HRegionServer和HMaster均是VersionedProtocol的实现类，即返回的对象可代理执行HRegionServer和HMaster的方法； 　　2）、Object[] call()：调用程序接口，最终是经过HBaseClient的内部类Connection通过socket方式完成； 　　3）、RpcServer getServer()

通俗来讲RPC（Remote Procedure Call）就是调用远程的过程或者方法，既然涉及到远程，必然会有C/S架构，即client和server。下面首先来看一下Client端的实现。 为实现远程方法调用，最重要的就是跟远程服务器进行连接，然后不断的传输客户端想要调用的方法，包括方法的参数等。为此Client有两个最重要的变量与之一一对应，Connection和Call。其中，Connection代表与远程服务器之间的连接；Call是一个方法调用的抽象。Connection有一个队列，保存所有需要到该Connection对应的服务器进行调用的方法。因为一个Client可能同时需要到多个服务器进行方法调用，如HDFS一次文件操作，不但需要跟NameNode进行通信，还需要与DataNode进行通信；因此，Client会包含一个Connection的队列。为了区分不同的Connection，Client定义了另外一个Class ConnectionId来标识不同的连接。 下面我看一下Call的实现，Call具体是比较简单的，如下代码： private class Call { int id; // call id Writable param; // parameter Writable value; // value, null if error IOException