逐步实现TCP服务端Step06:使用轮子

这一系列从零开始实现了一个处理简单业务(echo)的服务端,现实当中不太可能一切从头开发。所谓的服务端开发,更多地是去实现业务逻辑。务实的做法是使用成熟的“部件”快速搭建基础设施,然后专心开发业务。

一个后台系统可粗略地分为三个单元:通信单元、业务单元和存储单元。三者的作用从名字即可看出。前面的大多数篇幅,实际上都是在讨论通信单元的实现。由于不关注具体的业务,与业务单元有关的讨论几乎没有。至于存储单元,上篇讨论了dbsvrd与MySQL,其具体实现见antframe项目。

下面讨论一下,在这三个单元中,有哪些部分是可以用现成的“部件”或者说“轮子”去简化开发的。

通信单元内只有netio,目前版本的netio由两个线程构成,一个主线程和一个工作线程。单个工作线程中使用了I/O多路复用机制来探测各socket上的事件,若有事件发生,netio便会做出相应的动作。这是一种“事件驱动”式的工作方式,它与高性能通信库Libevent的设定是类似的,只不过Libevent所关心的事件,除了I/O,还有定时器和信号。可以使用Libevent来简化netio的开发。除此之外,可选的还有ACEAsio,不过此二者作为“框架”,相对比较复杂,Libevent库则更容易上手。

再看业务单元,这里的业务没什么好说的,因为并没有什么实际的业务。与业务相关的”轮子“要基于具体的业务去选择,比如某类游戏业务,可以使用相应的游戏引擎来节省开发时间。

另外,消息的编解码工作是在业务单元中完成的,对于这部分工作我们是自己实现了一套编解码的工具。这个地方,可以用google提供的Protobuf来简化开发。

还有,与通信单元连通的部分是可被替换的。这个部分实际上是在两块共享内存中分别构建的两条队列。可选的消息队列有:ZeroMQActiveMQRabbitMQKafka等。另外,也可把Redis用作消息队列。他们之间的对比和选择在后面讨论。

最后,是存储单元。这个地方包括了我们开发的dbsvrd和MySQL数据库,dbsvrd实际上还有“缓存”的功能。比如将从MySQL读到的数据放到内存中,下次再读的时候就可免去一次查询操作。涉及到缓存的功能,可基于Redis来做。


<==  index  ==>