魔都记--来美团点评公司快两年的总结

美团点评的前世今生：

网站由人人网（原校内网）、饭否等网站的创始人王兴于2010年1月建立，2010年3月4日正式上线。2010年3月4日，美团团队正式上线。2013年11月，美团外卖上线。2015年10月8日，美团网与大众点评网合并，新公司实施联合CEO制度，两家公司在人员架构上保持不变，并将保留各自的品牌和业务独立运营[2]。2016年1月，该新公司已完成首次融资，融资额超33亿美元，融资后新公司估值超过180亿美元。[3]2016年9月，美团收购钱袋宝，获得第三方支付牌照。2017年2月14日，美团打车在南京试点上线。2018年4月4日，美团以价值16亿美元的公司股分外加11亿美元现金，另承担摩拜10亿美元债务，收购摩拜单车，当中3.2亿美元作用注资摩拜，而摩拜A轮及B轮投资者和创办团队将收取7.5亿美元退出公司，有指收购总值达37亿美元。

2018年9月19日美团点评公布招股结果，发售价定为69港元，招股价范围则介乎60至72港元；净筹325.55亿港元。股份于20日在香港联交所主板买卖，收市报72.65元，比招股价69元高出5.3%，最高报74元，最低造72元，全日成交达1.16亿股，涉资84.39亿港元。

2019年6月13日，美团正式宣布更改标志，同时使用新的标准色，由此前的蓝色改为黄色，又称“美团黄”。线下的所有触点和交互入口也将变为黄色，其中包括被收购的摩拜单车。

2019年10月在北京召开以“新职业·新技能·新发展”主题的职校发布会，宣布“美团大学”正式成立。美团大学下设八大学院，美酒学院、袋鼠学院、美业学院、餐饮学院、婚礼学院、闪购商学院、配送学院、客服学院等多个生活服务品类。

                                                                            

 

美团点评与我：

17年，我研究生三年级，在南京面试了美团公司。很幸运，当天面试完，自我感觉良好。面试的也很流畅，感觉没啥大问题，十一过后，就来了电话，我就顺理成章的来了美团。其实当时也有其他选择，因为当时也不知道哪家更好，所以就没有变，对于我，我感觉我自己到哪其实都是差不多。毕竟是抱着来大公司取经的想法。工资相差不大的情况下，没有想改的欲望。

18年5.8号，我来到美团正式入职。记得当时刚刚来到上海，东西放在同学那，自己一个人在上海找房子。也算很幸运，遇到我之前的室友。我们快住了两年了。今年他要和他女朋友结婚了。所以我就和他分开了。别人打算过二人世界了，我这个电灯泡是时候退场了。

5.8刚刚来到美团，其实啥也不是很懂，就在那捣鼓Java环境，看看代码，熟悉下苹果电脑。之前我一直用的window电脑，当时拿到苹果电脑，还是非常幸福的。确实，对于写代码来说，苹果电脑确实比window的电脑要灵活、方便的多。特别是触摸板，确实做的非常好。对于将要入程序员这一行的同学，如果有条件，我还是非常建议入手一个。

我们小组的日常任务是做运营类相关平台和提供审核方面的服务。整体来说一个对集团内提供服务，一个是搭建运营类平台给相关运营同学使用。我当时接手的是一个非常老的项目，前后端居然是一体的。当时我即要写前端也要写后台。而且由于代码非常古老，做了各种各样的特殊逻辑。当时还用ngnix做代理，搭建环境，启动调试都非常麻烦。不过还好，由于是运营同学使用，也不要求显示什么特殊效果，只要有个表格显示就好。做这个项目时候，我还懵懵懂懂，觉得什么人写的，怎么这么坑爹。后来才知道，这个老系统快十年了，目前小组内部正在打算重构、迁移功能。对于新手，我觉得这种老项目还是不太时候，新手写只会把项目越写越无法维护。

第二个项目就还可以，拿到手后不就，我就和我师傅将它的web层和service分离。我觉得这个是非常明智的。service我们新搭建服务使用java8 springMVC的框架。虽然在刚刚分离时候，我们采用只分离不重构的策略，主要是由于当时里面特殊逻辑太多，而且还比较混乱。所以尽量不要让运营同学感知到我们在分离。分离上线的流程可以说下：先双写，后用哨兵灰度，最后全切。其实大部分的转化都是这个逻辑。哨兵一定要写好，在区分流量时候要想清除。如果日志量比较大，可以采用抽样打印，比较仅仅是对比，采样。够统计相关数据就可以。服务器比较多，考虑到切换的分布式一致性问题，我们往往会使用redis。分布式问题CAP一直是比较难的问题。我们这边虽然流量高，但是有回扫机制。丢失了一部分其实也没啥，只要有记录，在回扫回来就好。比较不是要求实时的出结果。

第三个项目的话，是自己和另外一个同时搭建的。另外的一个同事他经验丰富，所以他是主ower，我作为辅助，帮助他。其实在搭建时候，其实没啥区分。主要是同事经验丰富，在一些问题考虑上设计上比较完善。而且有难点问题时候也是可以去请教。工作上多问，其实非常重要。我自认为自己不是什么厉害的大牛，很多bug，我也不知道，经常百度，问其他人。有的时候虽然看出来bug的意思，但是还是没法解决。在这次搭建项目的过程中，边界问题这个还是很有意思的问题。在设计项目时候，经常要和其他系统交互，对于项目的定位一定要把握住，不能毫无边界的开发。先确定需求是否是属于你的项目开发范围，如果放在自己项目范围内，会不会造成项目之间耦合度太高。项目间的交互应该怎么处理。为了避免项目间耦合度高，我们在调用时候，采用kafka进行交互。如果是要返回消息的话，有采用redis或者kafka获取结果。接着就是向后设计，我开发了一个发消息通知的模块。其实对于所有的发通知，就获取消息本体，消息通知人发送就好。可以将这些配置全部放到一个云上，方便更新，维护一个对应关系，在不同场景去获取就好。正是由于我采用这样的模式。后面很多关于消息的开发，其实仅仅是配置下信息。有的时候还是要为以后考虑，毕竟能少写代码就少写一些

最近在重构第二个项目，可以说是大换血，由于维护这个项目已经非常熟悉，大部分逻辑已经非常了解，加上整个调用链非常长，请求的时间已经让人难以接受。整体的重构，其实是将查询逻辑区分，分门别类，将相互不依赖的数据，采用门面模式的方式进行重构。然后每个门面起一个线程，并行查询。接着就是对于一些重复查询的逻辑进行缓存操作，减少重复逻辑。对于一些慢调用的情况，采用过滤的想法，对于某些场景其实是没有返回结果，降低慢调用的次数。最后就是对外的接口，经过打点发现，有的服务在不断重复调用同一个接口，虽然传参数是不一样的，但是建立连接，这个耗时还是非常恐怖的。所以暴露了一个批量查询接口，内部采用并发的逻辑。对于数据库的话，就是对于查询比较复杂，查询一个数据耗时比较验证的查询，建立索引查询。经过这一系列的查询优化。使得整体的rpc调用的结果快了近1/2.效果还是比较明显的。接着就是减少与前端的交互，将很多功能收口于后端，让前端按照固定逻辑开发就好。减少因为一些小功能，还需要于前端的联调。比较做的是运营类功能，简单，方便，快速迭代是最实际的。

应该马上要进入第四个项目了，项目整体来说不难，大概10个工作日，难点在于如何去对接其他系统，里面估计为了兼容之前的老逻辑，又会是一大堆特殊逻辑。前人埋下的坑，只能后面的同学越滚越大。到后面有的坑，完全没法理解。

总结：

我呢一个在上海的沪漂，每天写写代码。看看电影，有时候也会感慨下，上海的房价为什么会这么高。希望大家和我在2020这一年少写bug，学到本事，以后能在上海立足！！！！