以一个从业19年的it技术人员视角看，有时候感觉到现在的程序员挺幸福的，各种开源产品，多种开发框架，所谓的架构设计更多的是选择/选型；再想想曾经的单片机，受限内存，低频cpu，编程语言以汇编为主，到后来c/c++......日渐苍白的头发，天知道我们经历了什么！
技术发展的步伐伴随着我们这代人的成长，见证着程序猿们为了变“懒”开始契而不舍的追求“复用”，从一开始的源码级复用，到工程/模块复用，再到二进制复用，直到今天的服务化复用，我们经历着从编码规范，到分层架构，再到动态库，进而追随MS发展出的com/dcom，直到SOA及各种openRPC、微服务......一晃已是不惑之年！
什么是技术？在我看来所谓的技术其实是利用趁手的工具解决问题的能力，而经验是在你看多了失败后，从直接或间接的教训中收获的；经验可在很大层度上避免犯错，而解决问题的能力是要求总能找到最佳解决方案。时间沉淀下来的是：没吃过猪肉，但见过各种猪各种跑法；收获总是负面的，很多时候你会觉得，所谓流行或牛逼的技术，其实大多都是新瓶装老酒。
之前有朋友热衷高并发服务器架构设计，其实这是个伪命题，实际情况是：并发能力90%以上的场景是取决于业务的，更多的因该考虑scale out，再明确点就是需要考虑业务逻辑及数据访问的scale out，这也是很多互联网大厂解决方案的核心所在。对于另外10%的情况如果从纯技术架构上探讨高并发框架，应该考虑的事情包括但不限于：
1. 需要实现一个AIO框架，如果需要跨平台至少需要考虑适配 iocp/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满负。已用于商用。
