分布式调用框架RSF-注册中心设计

    RSF 一直以来都是源码形式存在并未发布任何一版，其主要缘由仍是对于注册中心这一块一直以来都没有想清楚。如今想的也差很少了拿出来跟你们晒晒也欢迎各位大牛前来拍砖。

    首先要介绍一下什么是 RSF 以及这货是怎么来的。

    RSF全名是 Remote Service Framework，翻译过来就是分布式服务调用框架。也就是一个 分布式RPC。这里是RSF的源码地址：http://git.oschina.net/zycgit/rsf。

    这货是我在学习淘宝HSF框架时学习总结而来的，在编写它的时候一方面是学习总结，另外一方面是为 Hasor 框架丰富更多的插件。可是RSF的注册中心则更多的融入了我我的的一些思考。

    Hasor框架源码：http://git.oschina.net/zycgit/hasor（介绍：http://www.oschina.net/p/hasor）

    交代完出身那么就来讲说这个注册中心是个什么东西。

    首先抛开分布式不讲，但提一提RPC调用。RPC 本质上就是在 A 机器上去调用 B 机器上的一个服务方法。可是在分布式下，A机器去调用远程方法的时候会发现不光有一台 B 机器。它会发现有 B、C、D、E...好多台机器均可以去调用。

    那么如今问题来了，谁来告诉A，有 B、C、D、E 这么多台机器能够去用呢？要么 A 本身知道有这么多台机器，要么有一个中间人告诉 A 有 B、C、D、E 这些可选的机器。而“注册中心”就是这么个角色。

1、RSF注册中心的目标

1.为RSF提供服务发布和订阅

    这个目标指的是注册中心要负责维护一个列表，这个列表上要列出全部在线的RSF应用。而且列出这些应用上的RSF服务。经过这个列表能够为RSF客户端提供查询从而完成中间人的角色。

2.提供链接终端的管理

    该功能是用来管理哪些应用能够链接到注册中心那些应用不能够链接到注册中心。在应用级别的角度保障整个RSF集群的安全可靠。同时也负责维护一些应用信息方便开发者查阅和追中数据。

2、考虑的纬度和模块划分

    为了达到这些目标注册中心须要经过三个纬度共计四个模块去实现。三个纬度（应用纬度、服务纬度、终端），四个模块（应用管理、服务发现、监控中心、终端管理）先说纬度。

----纬度----

    任何一个RSF客户端都具备如下几个特色。

1. RSF服务由某一个应用程序提供。
2. RSF调用是经过暴露服务接口来提供。
3. 远端两个程序在进行RSF数据交换时必须经过TCP/IP。

    根据这三个特色总结出的三个纬度。RSF注册中心在这三个纬度上分别提供不一样的功能支持。

    应用纬度：应用这个纬度表示的比较笼统。它能够是业务的也能够是project的。从业务纬度上去讲应用的话，一个应用会包含多个项目。可是不管是几个项目，服务接口的定义应该是惟一的。这也就是RSF注册中心在界定应用的重要依据。

    RSF能够把不一样的接口组织到一块儿称之为一个应用。例如在电商架构中搜索、库存、商品展现、订单等等都被拆成独立的应用，可是都提供了不一样的接口。若是公司想发展一些其它特殊业务则能够新起一个应用。如何使用应用则全看您如何定义它。

    应用的另外一项，重要功能是用于标记owner和接口人，当公司逐渐变大，业务逐渐复杂须要更多的人参与以后，应用的人员标记会很方便找到你的依赖方。从而达到节约沟通成本的做用。

    服务纬度：在服务纬度下，注册中心要提供基于服务（分组、名称、版本）三个纬度的查询支持。此外服务纬度中还要负责维护客户端在线状态列表，并实时的把不在线的机器从列表中踢出。为此注册中心还要设计一个心跳机制来保证机器的存活。

    终端纬度：终端指的是一个实际物理链接，每一个终端都表明了一个实际的RSF客户端应用程序。终端的管理更可能是安全方面的，例如是否容许某个终端的加入，同时终端管理也能够用来作注册中心上的流控规则。比方说在服务不中止的状况下将其下线，若是单靠规则推送风险会比较大。由于规则的推送每每会影响更多的机器，而终端下线则只是模拟发送一条消息告诉集群“某台Server挂了，你们先不要去调用它了”而已。

    说完纬度再说功能模块就会清晰不少，RSF注册中心的四个模块中有三个都是针对纬度。只有监控被特殊单独列为一个模块。下面开始介绍模块的功能和做用。

----模块----

• 应用注册

    提供一个页面让开发者能够建立一个RSF应用分组，而且能够设置应用（Code、应用名称、owner、接口人、应用分组）等信息以备未来查阅，同时还要提供相关的更新、删除操做功能。其中Code是应用的惟一识别码，为了安全起见只容许使用（数字、字母和下划线），应用分组数据是一个树形结构。

    在应用下面还包含了服务列表的管理，服务列表包含了（新增、删除、修改）三个功能，经过服务管理能够预先定义服务而且能够给服务配置路由策略。服务至少要包含（分组、名称、版本、owner、接口人）信息。

• 应用预受权

    应用受权是安全方面的考虑，当RSF客户端尝试在注册中心上登记时。若是配置的受权码不正确注册中心会拒绝这个客户端的链接，被拒绝的客户端不会获得注册中心任何信息反馈。这个功能能够防止一些恶意程序的连入和扫描，也能够在公司内部用以安全防范。

    也就是说RSF客户端在向中心注册的时候，至少须要提供应用的（Code码、受权码）两个数据。若是启用了匿名应用则能够什么都不传直接链接到中心，有关匿名应用详见下面专门的介绍。

• 应用列表（包含：应用查询、应用详情）

    这个是应用管理中一个比较重量级的模块，它包含了 list 和 detail 两个页面，其中 list 页中还要提供基于（应用名、应用Code、应用组名）查询支持。点击list页上的信息能够进入 detail 在 detail 页 owner 能够修改应用信息。信息的详细程度能够具体在实现中逐步完善。

• 匿名应用

    匿名应用是一个预留的默认选项，若是强制要求全部链接到注册中心 RSF客户端都要求有应用与其对应的话，开发和部署会比较麻烦。所以匿名应用就产生了。启用匿名应用以后，RSF客户端能够直接链接到RSF注册中心查询本身所须要的服务列表。

• 服务中心

    服务中心是一组后台服务，它是整个RSF注册中心的核心，它负责接收来自RSF客户端的请求。处理应用上线、下线、服务发布、服务订阅。同时也负责维护客户端心跳，必要时候服务中心还会更新服务在线状态。

    所以咱们能够看到服务的发布、订阅和心跳检测功能都是在这里。配置推送指的是服务路由策略的推送。

    RSF中心和RSF客户端，的通信采用长轮训（Long-Polling）方式。客户端发起一个长链接请求并同时携带上一次请求时标识ID，若是服务器端发如今这个标识ID以后曾经发生了数据变更那么就把最新的数据返回给客户端（全量数据），尚若服务器发现没有数据变化，那么持有这个链接 30 秒。在持有链接的过程当中若是有数据发生变化，注册中心要及时的反馈数据给客户端。

    每当注册中心把数据响应给客户端以后都要把链接关闭，等待下一次客户端发来请求。经过这种方式RSF客户端和服务器之间能够达到实时同步数据的目的。之因此这样设计是由于考虑到实际生产环境中服务器的上下线不会很频繁。并且这种设计很小巧切知足功能须要，同时也不须要引入 zookeeper 这样的你们伙。

    若是注册中心和RSF客户端之间采用 zookeeper 进行数据同步的话就不得不考虑，zookeeper 死掉和 zookeeper session 丢失的问题。可是若是使用长轮训这种方式，咱们在设计整个 RSF 体系的时候就会思路很是清晰，把复杂的事情简单化才是目的所在。

• 查询中心

    查询中心包含两个页面，一个是 list 页另外一个是 detail页。在 list 页里开发者能够经过（应用名、服务分组名、服务名称、客户端IP）这些信息来查询在线的RSF服务。全部符合条件的RSF服务都会被列出来，固然页面是要有分页的。点击其中一条数据就能够进入服务详情页（与应用注册中的详情页共享）在这个页面中会罗列出，这个服务的 owner，所属应用，接口人，服务名字，服务分组，服务版本，提供者列表、消费者列表等信息。

• 测试中心

    测试中心是一个附加的系统，它的优先级和监控中心同样都比较低。测试中心是为开发联调环节提供一个强有力的工具。开发者能够在使用某个接口以前经过在线的方式直接加以测试，固然开发者也可使用测试中心直接调试本身的服务程序。

    在测试中心发起API测试调用时，能够选择是否指定IP，这个对开发调试接口是十分有用的功能。

    这是一个正在构想的功能系统，主要是经过调用日志对 RSF 服务进行动态分析，关于监控中心我一直在想它和 RSF 注册中心放到一块儿是否合理？由于监控中心运行时所占有的资源毫不少，或许应该把它完全独立出去。

• 终端列表

    终端列表就是简单的罗列当前全部链接到注册中心的RSF客户端，包括器IP、端口和所属单元。固然也少不了基于IP和单元的查询功能。

• 终端详情

    终端详情里能够直接选择断开这个终端的链接，将其强制踢下线。一旦某个终端被踢下线它全部发布的服务都会被踢下线，同时终端管理里还能够选择禁止该IP的连入。

• 黑白名单

    黑白名的目的就是配置某些IP，或者某些IP段是否容许访问注册中心。

3、RSF目前状况

功能盘点：http://my.oschina.net/u/1166271/blog/386376

性能报告：http://my.oschina.net/u/1166271/blog/413778

4、技术实现方案

TRD-1.应用管理