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

美团点评的前世今生:

网站由人人网(原校内网)、饭否等网站的创始人王兴于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,学到本事,以后能在上海立足!!!!

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章