这个项目很早前就听说要做了，一直拖拖拖，我实在很想做这个东西，周一就跟TL说，然后就简单谈了一下，确定了架构和分工，于是就开始了。
这个东西功能说起来有点像图床，但使用场景又几乎完全不一样。它有相对比较稳定的并发连接数，目前估计大概5000左右吧，最多不超过10000个，并且每个连接都会以比较固定的时间间隔上传图片，长至10秒，短至1秒。每个图片大小目前没有真正确定，估计在10KB~100KB之间。我们简单的估计就算它每秒有400MB上传流量。另外，还会有一部分客户端会请求下载某个或某一批图片，一批图片可能体积总共在20MB。
CTO和TL老早就定下基调，要使用长链接，这样每次上传不用重新建立连接，于是选了websocket。现在我想想，觉得似乎把问题复杂化了：客户端也是C++写的本地应用，又不是web，完全没必要用websocket嘛，直接用socket开销又小，又容易维护。
在项目开始之前，我还读了不少书和文章，关于大规模服务器开发和部署的。我找来了twemproxy打算做memcache的集群，找来了MongoDB打算做能应付随时可能变化的图片的meta data存储和索引，参考不少文章和案例来设计本地文件系统的存储。结果几乎全都用不上。开始写服务器两天后跟TL谈起后续的技术方案选型和落实时，CTO说了他的想法，memcache顶多有一台，甚至可能就跟服务器程序在同一机器上，本地数据库不需要了，因为meta data在图片文件中是自包含的，本地文件系统的存储也不用考虑了，直接用Amazon S3服务，把它mount到文件系统中，当一个普通目录使用，S3能处理好所有的存储，索引，性能等问题。所以现在这个thumbnail server实际上就是一个Amazon S3 proxy定制版。
做着做着，又觉得这事情很无聊了。
话说，公司一直在招架构师，昨天有个人来面试，第一面让我去。我就问TL和HR了，这人招进来你们打算让他干什么的，看他笔试C++的题，选择题做对的不到一半。如果你们是要他进来写代码的，我就问C++的问题，要他做架构的，我就问架构设计方面的问题了。后来我还是当面架构师一样地去面了，这人要求年薪30万以上，跟职位倒是也算挂钩。聊了大半个小时，感觉这人倒是真正做过一些项目，但也就跟我们公司里的情况一样，野路子，自己摸索，没有比较系统的方法，没有比较成熟的方案。
然后我再一次对公司深深地绝望了，居然宁可花那么多钱去外面招不怎么靠谱的人，也不愿意提拔老员工。叹气。
支付宝扫一扫
微信扫一扫