SimpleRpc-系统边界以及整体架构

系统边界


什么是系统边界?系统边界就是在系统设计之初,对系统所要实现的功能进行界定,不乱添加,不多添加。这么做的好处就是,系统简单明了,主旨明确,方便开发和用户使用。举个例子,一个自动售货机的本职工作是自动售货,用户投入零钱,选择商品,出货,找零,功能简单明了。但是,工程师非要再给售货机添加一个播放音乐的功能,原因是能够提升用户感受,用户在买东西的时候听音乐会心情舒畅,这明显就是乱加功能。更麻烦的是,有一天播放音乐的功能出了故障,由于售货过程依赖音乐播放功能,售货也跟着不能用了,这会更糟糕。如果买东西和播放音乐是独立的,那么即使音乐播放不成功,也不影响用户购买,而现在用户只能眼巴巴看着售货机不断的骂售货机的设计者是个傻X。

那么SimpleRpc的功能边界是什么呢?SimpleRpc只提供一个跨网络RPC框架,用户代码在固定的锚点插入,来完成这个RPC调用。

  1. 这个RPC不保证数据安全。有些rpc会使用ssl进行数据加密,但是SimpleRpc不考虑这种问题,因为服务调用在同一个机房内进行,不会涉及到外网数据传输,故不考虑数据加密。
  2. SimpleRpc不支持服务发现机制。有些Rpc会顺带实现服务注册以及发现功能,比如GRPC。但是我们的服务就是展示一个简单的RPC调用,其它功能忽略。
  3. SimpleRpc只有C++语言代码,暂时不支持其它语言。因为,这个框架只是学习交流的目的,不推荐用在生产环境。
  4. SimpleRpc不需要IDL(接口描述语言)文件。因为我们就是要略去IDL转换成代码这个繁琐的步骤,我们隐含默认服务端提供固定的计算服务,要求客户端和服务端配套使用。
  5. SimpleRpc不提供数据的序列化和反序列化功能,我们只专注于RPC调用框架实现,序列化和反序列化可以使用第三方开源软件protobuf完成。

整体架构


SimpleRpc-系统边界以及整体架构

客户端请求以及服务端响应的整个流程:

  1. 客户端序列化请求数据后,通过socket发送给服务器。
  2. 服务端网络事件监听响应器捕捉到socket上的读事件(由于客户端发送了数据,服务端socket上会有读信号返回,告诉服务端可读)。
  3. 服务端响应器把读事件放到事件队列中。
  4. 服务端工作线程从队列中获取事件。
  5. 服务端工作线程通过事件绑定的端口读取客户端请求,进行反序列化,调用用户层面的请求处理代码(例如做加法)。
  6. 服务端工作线程把用户层面的处理生成的响应数据序列化成字节流,通过socket发送回客户端。
  7. 客户端网络事件监听响应器捕捉到socket上的读事件(由于服务端发送了响应数据,客户端socket上会有读信号返回,告诉客户端可读)。
  8. 利用客户端响应器线程读取网络数据,反序列化,并把响应返回给用户层面代码。

从这个模型中可以看到,客户端与服务端都是用网络事件监听响应器获取网络事件,不同的地方是服务端采用工作线程反序列化、计算,而客户端使用反应器线程做数反序列化。

上一篇:压力测试工具 ab


下一篇:(转)I 帧和 IDR 帧的区别