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完成。

整体架构

---

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

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

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