写给程序员---技术感悟及有关高并发服务器框架设计

以一个从业19年的it技术人员视角看,有时候感觉到现在的程序员挺幸福的,各种开源产品,多种开发框架,所谓的架构设计更多的是选择/选型;再想想曾经的单片机,受限内存,低频cpu,编程语言以汇编为主,到后来c/c++......日渐苍白的头发,天知道我们经历了什么!

  技术发展的步伐伴随着我们这代人的成长,见证着程序猿们为了变“懒”开始契而不舍的追求“复用”,从一开始的源码级复用,到工程/模块复用,再到二进制复用,直到今天的服务化复用,我们经历着从编码规范,到分层架构,再到动态库,进而追随MS发展出的com/dcom,直到SOA及各种openRPC、微服务......一晃已是不惑之年!

  什么是技术?在我看来所谓的技术其实是利用趁手的工具解决问题的能力,而经验是在你看多了失败后,从直接或间接的教训中收获的;经验可在很大层度上避免犯错,而解决问题的能力是要求总能找到最佳解决方案。时间沉淀下来的是:没吃过猪肉,但见过各种猪各种跑法;收获总是负面的,很多时候你会觉得,所谓流行或牛逼的技术,其实大多都是新瓶装老酒。

  之前有朋友热衷高并发服务器架构设计,其实这是个伪命题,实际情况是:并发能力90%以上的场景是取决于业务的,更多的因该考虑scale out,再明确点就是需要考虑业务逻辑及数据访问的scale out,这也是很多互联网大厂解决方案的核心所在。对于另外10%的情况如果从纯技术架构上探讨高并发框架,应该考虑的事情包括但不限于:

  1. 需要实现一个AIO框架,如果需要跨平台至少需要考虑适配select/poll/epoll/kqueue/port等平台相关实现方案,需要抽象出操作接口及事件接口。


  2. 需要实现一个高效的thread-pool,需要尽可能降低线程切换概率(满负荷情况下),因此你可能需要一个lock-free队列/或链表,精心设计机制,避免线程饥饿或任务延迟


  3. 需要设计高效的事件处理机制,事件队列建议使用lock-free实现;有必要使用thread-pool进行任务分发,另外最好考虑一下IO线程和任务处理线程的隔离,防止io检测不及时;协议解析归到哪类线程(IO/业务),也需要慎重考虑。最好的办法是让线程池保留对应数量的“紧急任务”线程,然后让IO/业务按规则共享池内线程。


  4. 框架的对外编程接口需要规范。建议封装良好,屏蔽socket句柄,让外部使用者仅仅操作数据。至少需要暴露操作接口和事件接口。

  曾经大致按照这个思路实现过一个网络框架,性能还行,http小报文(64B)QPS高于nginx约30%(nginx约85万/s,自研框架约110万/s),测试环境24C/64G,双千兆网卡,并发连接数2048,CPU满负。已用于商用。

你可能感兴趣的:(写给程序员---技术感悟及有关高并发服务器框架设计)