毕业后加入了一家大型的互联网公司的音视频产品部门做后台开拓，实在我本身是学习自动化的，研究生的方向嵌入式系统，对互联网可是一知半解，因此能进入这样一个大公司还是很幸运的。
刚开始事情的半年该当是在上份事情最快乐的光阴，那时候我们十来个人被抽调出来做好友系统，由Z组长卖力。从产品到开拓，大部分都是新入职员工，pm给画了一个大饼，大家都满怀憧憬。闲话少说，先先容一下刚开始打仗后台开拓用到的做事器框架。
第一个打仗的叫udpserver。顾名思义，便是只支持udp的做事框架。由于我们部门是做音视频产品的，音视频数据对实时性哀求很高，因此常用udp传输数据。Udp server是同步多进程模型，包含1个Interface进程和多个Worker进程。
Iterface进程卖力吸收来自外部的要求，做一些合法性校验和格式转换后，转发给后真个Worker进程。Worker进程监听不同的端口收包，并处理业务逻辑。Worker进程的回包直接发给客户端。
此处有几个点值得关注：
首先，Worker进程监听的是不同端口。
监听相同的端口显然是更常见的做法，而监听相同的端口也须要把稳一点，即监听的端口socket必须是从父进程中继续得到的，而非Worker自己创建的socket。由于对付前者内核才能担保调度的均匀性，而后者是没有这种效果的，内核只会把要求包扔给同一个Worker。
这里之以是利用监听不同端口的方案，是为了担保调度的可控性，要求包发往哪个Worker是有预期的，可以做更个性化的调度策略，问题定位也方便得多。Udp server默认是利用轮询的调度办法。
第二点是，Worker进程回包是直接返回给客户真个。
另一种常见做法是通过Interface进程回包，缺陷是Interface会成为瓶颈。而Worker直接回包的缺陷是向外部暴露Worker，不过这个问题并不十分严重。相较之下，我们更希望得到性能的提升。为了给客户端回包，Interface会把客户真个ip和端口封装到要求包发给Worker。
框架虽大略，但是性能非常精良，作为echosvr性能可达30w+ QPS。但是这个框架不支持TCP，因此只能作为内部的做事框架利用。
由于良久没用这个框架了，以上所述可能有不准确或者不充分的地方，望不吝见教。
