分布式调用框架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 这些可选的机器。而“注册中心”就是这么个角色。
一、RSF注册中心的目标
1.为RSF提供服务发布和订阅
这个目标指的是注册中心要负责维护一个列表，这个列表上要列出所有在线的RSF应用。并且列出这些应用上的RSF服务。通过这个列表可以为RSF客户端提供查询从而完成中间人的角色。
2.提供连接终端的管理
该功能是用来管理哪些应用可以连接到注册中心那些应用不可以连接到注册中心。在应用级别的角度保障整个RSF集群的安全可靠。同时也负责维护一些应用信息方便开发者查阅和追中数据。
二、考虑的纬度和模块划分
为了达到这些目标注册中心需要通过三个纬度共计四个模块去实现。三个纬度（应用纬度、服务纬度、终端），四个模块（应用管理、服务发现、监控中心、终端管理）先说纬度。
----纬度----
任何一个RSF客户端都具有以下几个特点。
- RSF服务由某一个应用程序提供。
- RSF调用是通过暴露服务接口来提供。
- 远端两个程序在进行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段是否允许访问注册中心。
三、RSF目前情况
功能盘点：http://my.oschina.net/u/1166271/blog/386376
性能报告：http://my.oschina.net/u/1166271/blog/413778
四、技术实现方案
TRD-1.应用管理