芒果网总结

在芒果网这一站的工作差不多要到结尾了，简单作个总结。

在芒果网没有解决的大问题：

平台级问题：

大订单概念
目前芒果网订单，都是各业务线使用自己的订单，没有统一的大订单的要概念。
这样存在系统限制业务多样性发展的因素。比如，买机票的时候，可以同时看酒店，看好了，一起购买。
但目前的系统结构，要做这么一件事，必须这么来：先买机票，完了再买酒店，不能同时买。
要把现有系统改造成支持上面的大订单的概念，我们需要改造系统流程的两个主要点：
1.增加大订单环节，方便用户选用不同业务线的产品，如果，推荐系统建成，这个受益会更大。
2.增加订单拆分环节，把大订单里的小订项，按业务线分类拆分成业务线的子订单。

由于人员配置和各方面因素的问题，这个计划一直没有实施。mark一下。

系统问题：

芒果网的最前期的老系统，有很多是flex做的项目，老员工早已离职，缺少文档，且由于近年来，flex技术已经没落，很难招到合适的人。所以，这类系统基本属于改不动，也难以维护。只能看看小问题。   这类项目，急需改造成javaEE项目。

在芒果网解决过的关键项：

加入芒果网，首先进入的是芒果网的核心业务线，机票业务。

当然，进来的首要任务，是先要熟悉系统。由于人员流动和交接不规范，基本没有成形的文档留下来，所以，前面三个月基本都是天天自己干到晚上10点，不干别的，只是看代码，从代码级别弄清系统运作的流程。梳理出流程后，就开始琢磨如何改善系统。

先跟业务部门了解，系统在使用中的痛点：

1.运价系统不稳定，经常出现运价下不出来，需要大量的人工在运营系统去抽查运价是否缺失。

背景知识：机票的价格信息，都是从中国航信的系统中拉取文本（这里称为下载），再解析成芒果网机票系统可以使用的价格结构）

2.查询流量费用高。

背景知识：机票最终在网站上展示给客人购买，主要有两个主要的条件：有价格，有可用的座位。

价格，就是上面运价系统中下载出来的；

航线（深圳到上海是一条航线）的航班（航班，是航空公司在航线上运营的航班，如深航，ZH9505）要还有可以售卖的座位。

以上说的价格下载和可用的座位信息，都是需要从中国航信的系统获取，每一次调用中国航信的系统，是要收流量费用的。

3.app机票查询慢

4.依赖的小太阳服务有时候会死

航信系统：由各航空公司组成的控股公司，各航空公司会把航线上航班的舱位价格信息和座位预定信息，发布到航信系统，机票代理人都需要从航信系统里查询机票相关信息

 芒果网在航信系统，申请了各个分公司需要使用的配置（如，成都，武汉，北京，上海，广州，南京，深圳等），这些配置用于在航信系统中查询数据时使用，且每个配置，每个月的查询量不能超过13万次，超过这个次数的，需要收取高额的超流量费用。

5.订单积分显示不正确

其他问题待列！

总结未完待续！！

针对以上的问题，深入系统，分析问题：

1.运价系统不稳定，经过跟踪分析，主要问题有两个：

   一是，不定时出现下载的线程卡死，表相是运价组的运营人员，发现运价不下了。  --最后的分析结果提,quartz1.6.0以前的版本，有这个bug，后面升级为1.6.2，没出现同样的问题了。

   二是，看到一些程序退出生成的dump文件，内存不够。但，奇怪的时候，这个东东，不是经常出现。后面定位到，从dump文件分析出，出问题的大概代码块。但当时并没有发现问题的所在，因为，这个在测试环境，没有出现过。因为，下载运价，是需要耗费航信流量费的，所以，运价下载的测试环境基本只是做个功能性的测试。

  后面发现这个梗，是在快过年的时候，各大航空公司纷纷发布大量特价信息，有少数几个航司发布的特别多。到半夜，运价下载就是下不出来，特价发得多的航司运价。

 魔咒，，，其实也简单，有现场的时候，好分析，就是下运价的时候，程序会把每次下运价的过程，按航司记录下来，，如果航司这次发布的特价特别多，这些下载日志就会很大，在还没有保存到数据库之前，这些下载日志一直hold在了内存，直到内存撑爆了。老技术员工说，他们常用的办法就是把jvm的堆内存加大，有时候管用。

    看到问题后，出解决方案，既然代码里，注释旁白是日志，是不是可以，不存呢，从平常的业务接触看，从来没用过这个数据。本想着，自己做决定，直接注释掉相关的代码 ，后面想着，还是去找业务部门问一下， 可能写这个的时候，有什么特殊的原因或背景。果不其然，业务部门的员工说，这个数据是有用的，在系统记录的运价和航空公司结算时用的运价，不相同的时候，这是个争论的依据，显然，这个不能就这么注释了（虽然，10个年头了，这个数据也没用过一次）。

  解决也很简单，关键点就是把日志分得更细来存，原来按航司存，改完后，按更细粒度的舱位存（这个是和业务人员商量的结果，同意可以不看完整的日志，只看单个舱位的日志）。减少单次的内存占用。然后，内存也比来缩小两倍（芒果网各个业务线的应用服务加起来有300+，服务器资源还是很紧张的啦）。

2.查询流量费用高。

   这个问题，首先想到的是利用缓存，但为什么芒果网这么多年，都没有在这块用上呢？经了解，其实以前是有缓存的，后面去掉了。为啥去掉了，问了一圈仅有的几个老员工，得到的信息是，机票以前用缓存的时候，价格经常不准，被客人投诉。看上去，是个棘手的问题。

   要解决这个问题，还得深入系统和业务去了解细节，看看有什么可以优化，那改进的地方。中间各多的苦难学习业务就不说了。说结果：经过和业务运营的妹子聊过，为什么运价不准呢，机票价格有变得那么快吗？聊完的结论是，其实也没会变得很快啦，只是以前有段时间，某些航线变得快，呼叫中心接到客人投诉，压力巨大，就把缓存这环节去掉了。有这个说法，心里就估摸有底了。大概以前的兄弟，对缓存一刀切了，实际需要区别对待。

   细节就不说了，后面把缓存按航司，航线，舱位，做成有规则，可配置的缓存（nginx+lua_+memcahced+redis),问题基本就解决了。

   缓存用上了，但，还有一个优化点可以提一下：除了网站，app，h5的自有渠道，还有对接了京东商城，其实芒果网自有渠道的查询量不大，加起来还没有京东的多。这做了个小小的优化，就是把京东查询预热的缓存，和自有渠道共用，一个月可以节省好几万块大洋的航信查询的流量费用。典型的小动作，大收益。

3.app机票查询慢

   这个问题比较明显，但一直没有先做。因为，流量不大。主要的精力要花在了运价上和保证京东商城，农行商城等大流量的合作渠道上。但，自有的app，以后还是芒果网以后主要的发展途径。

   看代码，问题就明显，app后台接入层逻辑里，有调用非常多的后台微服务接口，且都是串行调用的！！

   当然，这个改成并行的工作就交给机票组的其他同学去做了，我只说了个大概的思路，把能并行调用的，都改成并行。最后反馈的结果是，app跟之前比，飞起来了。

4.小太阳服务

小太阳服务，是芒果网早年就外购进来的系统，负责和航信系统的中转。芒果网机票的预定和退票流程都依赖这个服务。这个服务研究不进去，因为只有最后的exe成品，看不到里面的东西。中间，也有联系过小太阳的公司，他们明确说，这个系统他们已经不再维护，且是给钱也不维护了。温馨提示，这个玩意有bug。

由于2016年公司引进民营资本，需要大力发展业务。所以，决定找供应商换掉这个东西。

我们做评估，换掉这套系统的代价。代价很大，大到机票的所有后台服务和系统都要改。由于差不多都是新人，老人都走了，没啥文档留下来，且很多地方，都是写死的，只能大概搜索的评估。

为了快速响应业务的需求，我们决定先从最核心的机票运价下载开始。熟悉运价系统，然后改造它的底层，同时重新梳理业务流程，让改造的系统更适合当前的业务及未来业务扩展再带来的变化。最后，改造其他的环节服务。

找到供应商后，面临我们只直接拿供应商现成的成品运价，还是只拿航信查询的中转接口，我们自己来解析，航信的返回数据，适配到我们的运价库。根据当时的业务情况（公司要加大业务的力度，航司发布不定期会出现发布不标准的运价 ），我们选取了后者，这样，虽然工作量大点，但对后期业务发展需要的价格规则，有更大的灵活性，也能应对航司发布的各种变态的不规范的运价数据(不标准的淡旺季运价等)。

多么痛的领悟：前期欠下的技术负债，越早偿还（重构），后面的代价越小。由于技术部对这块工作量评估的结果很大，导致业务只能在系统的问题现状态下束缚的发展。

5.订单积分显示不正确

   支付服务回调机票后台服务，有问题，导致机票后台更新订单对应的支付信息不正确。

    有两个原因：

1.机票系统存在多套流程，多套流程分别由前辈的架构师的推动，但都没有最后完成，导致多套流程并存，中间跨系统流程支付（比如，在呼叫中心下单，扣的积分没有通过支付的收银台，网站查这个单，就看不到积分的明细），积分信息的环节对不起来。

2.支付存在，重复通知业务系统的情况。

   第二个问题在芒果网系统中具有普遍性，需要做一个范例（简单用memcached，业务系统都有用memcached，做分布式锁，对重复的通知，不作实际的逻辑处理，做接口的幂等性），推广到其他业务线。 

其他完成的项：

标准化机票对外商家openapi（对接中信银行商城时做标准化）：

ejb改dubbo：ejb部署在was，was证书过期，经常出梗，改成dubbo，改造过程比较简单顺畅。业务线使用也容易。

应用代码层面做了限流：

保险平台的建设：业务线都有对接保险产品的需求，独立出来有利于业务线使用保险产品和丰富接进来的保险供应商（平安财险，农银人寿保险等），保险可以作为重点获利产品，分成比较高

其他未完成的事（不急需，只是做个规划，有时间再做）：

分布式配置中心，自动扩容，熔断，监控，全链接路调用监控等微服务配套设施

风控系统（急需建设），芒果网面临大量的恶意请求，攻击，需要梳理出恶意特征点（区分机器，人为，违反正常业务特征等方面的变量因素），通过规则引擎计算评分，在系统中逐步的实施和验证。通过日志分析，可发现，业务起色越大，被人盯上的机会越大。在以后的工作中，系统架构，规划需要有这方面的考虑。

关于管理研发团队的

有一部分日常的团队管理工作，稍作总结。

技术团队的管理，重要两方面：1.人员稳定   2.人员技术能力培养

绩效考核可以说是保持人员稳定的手段。但绩效考核指标的确定，却是一门说不清楚的艺术。人多和人少，完全两样。

人少的时候，活多人少是常态，需要抱团取暖，重在人的沟通和交流，可以完全不用绩效考核体系，也可以有绩效考核体系，不过，最好能有一个，以指导团队，提倡什么，反对什么，这有利于建设一个健康的团队，多劳多得是最后关于奖惩落地的大原则。

多的时候，不太可能都能去沟通交流。这时，需要有管理体系，就和原来毛爷爷时代，作战部队需要在每个层级都要设指挥员一样，当然，解放军的特点是，一个作战单位，通常都会有军事主官和副官以及政委。大的技术团队，也可以参照这个体系。按业务线画分作战单位，设主管，主管除了管理业务和技术外，还要做好政委的工作，让团队成员保持稳定。  

技术总管，要把控维持稳定人员的措施，准确的往下传达和落实，也需要对下面直接主管的稳定性负责。

另外，技术团队，应该具有学习型的特征，不断通过学习，增强技术能力，对个人，团队，和公司的发展，都是有利的。

培养感情，培养情怀，感受工作中的快乐

在芒果感受到一个年久失修的系统，在后面维护起来，是多么的痛苦，基本说不上，技术反过来驱动业务的发展。所以，系统该修修的时候（业务方要增加业务或改变业务，在而代码改起来麻烦的时候，各种原则模式，就可以用起来了；或者随着对业务的学习和了解的深入，需要调整和完善原有的设计），就要修修（不然，逻辑越加越多，没有条理，把原作者叫过来，都未必看得懂，以前这是要干啥了），不能拖太久，后果会很身严重。

身体也一样，刚做完体检，肥胖指数28，做梦都想念那个历史版本中瘦不垃圾的偶，，，杯具的程序猿！！！