新项目Beecol的一些变化

最近的工作都在新项目 Beecol上，已经上线一个月左右了，目前第一版要做的功能已经差不多齐了；接下去会安排重点去做偏growth的feature；预计十一长假前应该也能上线。

新项目由于有Have之前打的底子，api service做得更快，并且由于Have的一些教训，在项目和代码级别做了些结构调整，让整个项目结构和部署更清晰和更容易些；其他queue和db的服务，与Have共享一套。技术上，主要做了如下的调整：

1.新项目目前完全放弃了Mongo；在Have做订单相关feature后，随着对Postgresql的熟悉，以及它本身对json的良好支持，目前Beecol的项目的后台DB完全使用了Postgresql；放弃Mongo倒不是因为目前不满足什么，最主要的问题是，aws并不提供Mongo的服务，所以Mongo需要自己搭，而为了稳健，Mongo又必须搭成cluster，这样就是3台机器；的确可以在现在量不大的时候，与API的机器混合部署，但这样势必带来运维的难度以及恢复的难度；而Postgresql由于有aws维护大部分，目前看还比较省心；不过这次依然还是踩到了golang下Postgresql的一个坑，由于没有关闭链接，导致链接打满，系统挂掉；在找了几次泄漏点以后，目前已经稳定；但aws的机器上对max connection的设置非常保守，在量上来后，可能会是瓶颈；

2.开始使用aws更多的服务；把原来的redis和postgresql都切换到了aws的服务，虽然一定有性能损失，但目前的瓶颈一定不在这儿，所以就先省点心去做其他事情了；

3.增加了短链跳转服务；这个最早是为了统计公众号出去的文章的一些点击情况，后来随着Beecol的上线，所有的item以及放在外面的PR稿子什么的，都会使用我们自己host的跳转服务；服务本身其实很简单，基本上2个小时就上线了，看上去也不会有特别的性能的问题，后来主要解决的是针对短链接的统计服务；

4.整体项目增加了landing page；这个主要是为了承接一些微信分享出去的回来的量，希望即使用户没有安装app，也能部分使用功能；landing page主要使用了react来写，因为团队里没人非常擅长前端，任何一个方案都有学习的成本，而借landing page写react的机会，看看有没有办法引入react native去app；数据的来源是和app一样的api请求返回json，所以api基本对app和web是通用的，除了几个特殊的地方；另外一个有点特别的是，静态页面文件是host在s3服务上的；一个请求进来，会带api的机器，然后api转发去s3；这样做最大的好处是部署起来更方便，不用在多台机器上部署新的landing page，主要更新s3就Ok了。这同时也为后面的部署工具带来了可能；详细的另开文章记录；

5.后台工具的挑战；因为这次的项目不是UGC项目，而是PGC项目，因此当时最急的是一套后台的工具来让运营的小伙伴进行内容输出；这个当时是和api service同步进行，在易用性不断修改，最后终于让运营的同学得到不错的效率提升；这个给我带来的启示还是，一个技术人员一定要尝试丢掉技术看普通用户的问题；

6.Beecol项目最大的技术进化的是对数据统计的重视；由于刚才说的短链服务以及前文解决的Spark读s3的问题，搭建了一个非常低使用成本和维护成本的数据分析系统，并且由于天然利用了s3和Spark，以后量起来也无非是多加机器，而不用修改现在的代码；这个数据系统应该可以撑很久；而因为这个系统的上线，简单的报表和对业务数据的监控已经开始批量上线；很容易分析出一些业务的健康程度以及用户的行为习惯；不过对app数据的分析确实跟之前做web是完全不同的，这个留着以后总结；

7.自动化；做工具造轮子总是好玩的事情，而贴着需求造就更容易有成就感。除了结合Slack的custom command做些服务器的状态check外，最近又做了个landing page的部署工具；刚才说了，landing page的静态文件是host在s3上的，s3的权限不适合直接公开，这样就意味着部署的事情就依赖在我这里，而landing page的开发目前在另一个小伙伴这里，他在本地测试完后，想部署到测试环境，必须依赖我，这里容易造成gap；另一个是，本身landing page的项目需要npm装包，node和webpack来打包，而这些东西在国内的网络环境下简直痛苦，因此最理想的事情是有一个打包机来完成这些事情。因此前两天花了半天时间折腾了下，效果如图，目前因为只在测试环境部署，因此也没有什么roll back的功能，简单好用就足够了；