网络通讯服务器的架构选择

一个网友问我：他有几百个客户端并发访问的请求，想选择boost::asio的现成异步通讯框架，感觉怎么样。

对C++开发人员来说，很多人应该不止一次面对这个问题，甚至是工作了七八年的人。

我发现一个现象：当一个C++开发人员，面对一个服务器开发需求时，常常不自觉去想寻找一个高效的网络通讯库，而且考虑的比其它方面更早。

效率，是C/C++开发人员引以自傲的一个方面，即便嘴里不说，潜意识里会有这个想法。

这一潜意识让他们在面对服务器开发时，会不自觉去想要得到一个最好的网络通讯框架，不管是否存在，是否有必要。

你现在面对的这个实际需求，是否真的需要一个你心里想要的那个高效的网络通讯框架？

你的业务流程是什么？动手在纸上画一画，再复杂用UML图设计一下，难道除了网络通讯，就没有其它方面更耗时？更值得关注？

真正的平均客户端连接并发是多少？频率有多高？

你准备投入多少台服务器，每台服务器的CPU速度、内存大小、磁盘转速和采用什么阵列、网卡是100M还是真1000M、网络上交换机和路由器是怎么部署的，客户端和服务器之间通讯的距离是有什么特点，等等？

你们有多少开发人员和测试人员，这个项目客户给你多长时间完成，你准备什么质量程度给他交货？

我们把思路收回来，就考虑网络通讯框架：

业务模型到底适合采用TCP还是UDP？采用长连接还是短连接？采用异步还是同步？采用阻塞还是非阻塞？

是手工写个简单的好，还是采用现成的网络通讯框架？

采用现成的网络通讯框架： 选择boost::asio？选择ACE？选择MFC自带的异步类？。。。。。。

你熟悉这些框架吗？他们有多大？你是不是这次只用到那1/1000之一的部分？为了这个小功能，你到底愿意搞那么一个庞然大物吗？

最后，你这个子系统，一定要用C/C++来实现最合适吗？你还会其它开发语言吗？

从各个方面多问问自己，然后自己试着回答，说不定你先前的疑问就不存在了。