先说下整个事件的背景和经历。
去年我们公司打算做一套商城系统，类似淘宝这样的，卖自营商品和商家入驻，我们之前没有这类工作的经历，所以找了一家在国内还算知名的公司外包给他们。项目规模算是挺大的，合同金额有7位数，谈妥之后大概在去年11月正式开工

lz我自己的公司是在甲方这边的一个小小的开发人员，我们公司现在有自己的会员体系和会员积分，储值卡这些核心数据。所以整个开发模式，我负责开发接口提供给乙方外包公司（后面我就称呼他们为乙方，我自己为甲方），他们开发商城功能，但是会员信息和储值账户积分这些东西走我开发的接口，通过https调用。

开发过程及其坎坷，先不细说，以后再逐个拎出来一个个说。时间直接跳到今年7月初，决定上线了，全国开放使用。重头戏来了，之前什么压测乱七八糟的他们也做了（他们自己内部测试，我们没参与，只给了我们甲方几份测试报告，在我领导那，我也没看过），然后上线当天，服务器就炸了，大面积宕机。。。补充下，项目是前后端分离，前端vue，后端springboot微服务。

然后排查下问题，这也是我第一次觉得一家如此大的公司能做出这么不靠谱的事（当然之后我觉得我错了，他们还有更不靠谱的在后面，后续慢慢说）。这次宕机的原因是，前后端分离的项目，他们居然把前端项目放在了云服务器上而不是cdn上，我们的云服务器就10M带宽，一个前端项目打包完有4M多，所以你懂的，放上生产环境，访问量一上来，带宽全部耗光。。。而且，我们公司有cdn的，并且提供了，他们把部分图片放cdn上，却把前端项目放在公网服务器上，真的不知道怎么想的

然后就修复啊，调整项目重新部署啊，勉强算成功上线了。好吧，后面才是噩梦开始。半个月之后，因为我们公司做了一次推广，某一天访问量激增，好吧，又爆炸了。

这次问题更严重些，其他一些东西还好处理，主要问题在一个下单逻辑。这个功能是这样的，下单先调用我开发的预下单接口创建好订单，他们那边再进行支付操作，然后支付成功再调我开发的完成订单接口。那次出现全国大面积的问题就是，客户预下单，付款成功了，然后要调用订单完成接口失败了，客户那边看到的结果就是钱付了，但是商品没发放（虚拟商品）。。。然后那天我们客服电话被打爆了，我第一次加班。。。

排查原因，发现是他们调我开发的完成订单接口失败，又是带宽耗光了所以调不通。。。这次不是前端了，居然是他们调用接口的出方向和入方向都走公网（10M的那个），所以访问量一上来，又没了。。。而这个情况我开发的时候已经想到了，所以把我们甲方的核心服务也部署了一套跟他们同一个区域的云服务器上，走内网无线带宽能放问的。然而，他们居然忘了。。。

好吧，再改改配置，重启下项目修复呗，然后我们给乙方擦屁股去补那些支付未完成订单的数据，一笔笔手动补。。。再说句题外话，这种重要接口我来开发的话，如果调用失败了，我会进行重试的，这应该是开发的常识，反正他们压根就没考虑。而且如果失败次数过多，应该要退款操作或者记录，进行通知，参考mq发消息失败的重试机制和最大重试次数失败的处理情况就是了，反正他们没这么做，给我们造成一堆麻烦。。。

再往后到7月底，项目快结项了，所以我拿到了源码。然后有些功能我接手开发，就参与到这个项目中了。然后就遇到了3个可以毁了我整个职业生涯价值观的东西。

第一个，直接简洁明了的说，没有事务，没有事务，没有事务。。。重要的事情说三遍。大概10个左右微服务，全部没有配置事务，真的是毁三观。然后我以为我误解了，直接问他们技术经理，真的是技术经理哦，他居然说事务这个东西他没怎么接触过，需要一起学习下。这是原话。。。我下次找找聊天记录截图出来。天，真的是无语了，一个工作年限至少5年甚至10年的技术经理居然没用过事务，我很难想象他们以前项目的客户是不是纯小白。。。反正这事我直接跟我领导沟通了，他们自己处理，貌似现在也没解决。我就是把我有开发功能的几个服务补上事务配置就是了，其他的我管不了，我只是个小小的开发人员而已。

第二个，没有token认证，没有token认证，没有token认证，还是要说三遍。。。也不是完全没有token，他们后端确实需要传token才能访问，但是后端的逻辑居然是 非 空 判 断 。。。我还以为自己误解了，随便拿一个接口用postman测试下，token参数我填个1，居然调通了。。。我的天，这项目等于裸奔。然后我就想他们怎么获取当前登录用户的信息，所以找了下，才发现前端跟后端真是绝配。。。前端居然把完整的用户信息，用明文的方式保存localstorage上。设置怕别人看不到，居然在每个页面加载完把完整的用户信息给console.log打印出来。。。。然后后端需要登录用户信息的地方，居然是把用户主键作为参数传递到后端，搞定了。。。这系统真是比裸奔还裸奔，我都不需要登录，我只要知道别人的会员主键，我就可以随意用别人的会员里面的东西了，包括钱和积分。。。真是可怕。。。

第三个，相比前两个安全问题，这个算好多了。就是这个项目有用到redis，目前哪些地方有用到还没完全整理出来，但我发现的一个，手机验证码存在redis，这个很合理。不合理的是，redis不设置时效，也不删除。。。简单地说，他们直接把redis当数据库用了，把内存当硬盘用了，这样玩下去，迟早有一天redis满了，那就呵呵了。。。而且，他们用redis还是用最原始的jedis工具，那么多好用的redis客户端为啥不用呢，反正我开发的时候，又整合了下redistemplate工具，分分钟就能愉快的用redis开发，不香吗

有人看吗，先睡觉了，明天再继续。。。

dd