前段时间一气呵成，把公司的陈旧代码完全替换掉了。这其间主要用到了Boost Asio，以及其他Boost库的组件（thread，bind等）。这次开发，让我收获颇多。

      首先，是技术上的成长。刚入公司时，负责维护的是很陈旧的代码，不过由于当时自己的视野局限，并没有认为其到底有多陈旧。后期随着技术的成长，以及视野的开阔，便有了重构系统的决定。既然说到陈旧，那么这里就简单说一下旧系统的旧在何处：

      1）多线程多连接的服务端。

      2）多线程多连接的客户端。第1）点和第2）点的缺点是显而易见的，线程和连接绑定的做法不仅会带来扩展问题，而且也会造成性能缺失。在旧系统中，线程数已经达到了300多个，而实际上线上运行的系统最多只有12个核心，线程数远远大于CPU核心数，这导致了：线程大多时候都在空跑；不必要的上下文切换。

      3）客户端和服务端采用父子进程。父子进程通信机制原本是没有错的，但是从系统的业务逻辑来看，采用父子进程通信没有必要。改用一个进程，不仅减少了不必要的任务数据拷贝（线程可以共享数据结构），而且便于前期开发以及后期维护。

      4）还有一些不必要的任务拷贝，多余的日志打印等等，这里就不再详细描述了。

      ”

      你站在桥上看风景，

      看风景人在楼上看你。

      明月装饰了你的窗子，

      你装饰了别人的梦。

     “

      借这首诗，只是想说，既然旧系统有问题，那肯定不止我一个人发现了。是的，我们优秀的研发人员实际上已经开发了好的替代产品。这个好的替代产品，采用以下设计：

      1）采用epoll来处理网络事件，但不支持纯流数据的接收和发送，只提供了http客户端的封装。

      2）采用Round-Robin算法来处理所有的事件：将大任务细分为小任务，并且支持FIFO。但是实际运行时，发现他们采用的Round-Robin算法不是特别完善，比如曾经的测试：持续不断地给程序发送大批量任务，结果导致任务反馈卡住了。

      3）部门间沟通困难。由于公司太大了，部门间的沟通变得异常艰难，这首先表现在部门之间的代码无法共享。这就导致，我们希望定制日志文件大小，希望支持socket流的客户端（并且随之支持protobuf）的希望持续落空。

      在种种限制和不足里，我最终决定开发新的替代产品。

谈谈Boost网络编程（1）——旧系统的问题