算是总结2016，想想2017

Posted 2020-08-29 diamondiamon

 

    今天，就今天闲得蛋痛，独自坐在咖啡厅上看看一些技术文章。有感而发，也写写这一年的总结。

    想想2016这一年，真操蛋的忙。不过有时觉得忙点还好，最起码日子过得充实。这一年开始由0到1开发一个新的项目。从想法到实现，这中间经历过很短的一个时间。

一开始是由自己把老板的想法简单地做了出来，说是简单，其实也有了核心的功能了。整个阶段大概花了一周时间。也就是咱们项目的第一版。也是年前完成的。

ok，这项目也好好地过完了新年，年后的安排可以full full的了。各种各样的功能都想要。有时老板头脑一热，说，这个功能好像不错，人家做这功能感觉挺好的。这个能不能快速实现？

可以，就这样，所有的迭代就变为一周一个版本，慢慢地把功能做上去了。每周都累成狗。这里想总结一下，很多事情，特别是创业公司，有一个好一点的idea就要快速实现，也是为了迎接市场的需要。

但是迭代得太快，维护就跟不上了，做出来的质量差强人意，也就过了半年了。到6月，用户量暴涨，很快从百万能涨到千百级了。可是之前都没做过这种数据量级的服务，很快服务器就撑不住了。因为用户的基数大起了，数据自然会暴涨。

当初还是单台服务器，很多写法都是依赖了服务器的内存，数据很难做到共享，这就成了改为均衡的一个阻碍。但是均衡是势在必行的了，只有想办法去改动。第一个做法就是把单台服务器要共享的数据提取出来。举个例子，用户登录信息当初是存Session的

这一个要做到多台服务器上共享才能使得用户在访问不同的服务器时不用再次登录。Session共享的方案也有不少。我们后来用了Redis来做数据共享，多台服务器的登录信息都统一存在Redis上。把用户的标识（如生成一个SessionId）存在Cookies上，用户拿着

这个标识来向Redis服务器换取登录信息。这种方案就可以解决了均衡的问题。

      OK，均衡做上去。用户访问的分流上也有效果了，但服务器还是卡。特别是每天的早上7：00-12：00。很容易就卡成白屏，基本上不能使用。服务器的性能绝对是可以支撑起这些访问量以及并发量的。想到这里，就不能再礸牛角尖了，可能还有其他地方有问题

导致的。现在想想当初也是死想着某个问题导致的，所以花了很长时间去证明了，页面打开慢并不是一个问题导致，你解决了一个问题，并不能对页面的优化起到很大的作用。可能同时有多个问题导致你的服务访问缓慢，页面打开卡顿。咱们用的是windows服务器，在

iis上花了很长时间去看哪里出问题，看看能不能iis上得出一些问题的来源。结果发现也像园主当初遇到的一些情况一样，有黑色1秒的情况，其资料可参考一下这个：

云计算之路-阿里云上：“黑色30秒”走了，“黑色1秒”来了，真相也许大白了

我了解到，系统的某些资源是被占用了，长时间未得到释放或是该资源执行的时间比较长，导致外面很多请求被阻塞在外，无法进来，服务器也就塞车了。资源出不去，请求进不来，打开页面只会是白屏。

    其实解决一个问题，时间往往是花在找问题上。问题定位好了，方案就会浮出水面了。很多资源是在数据库层面上阻塞了，因为数据量大起来了，一个表又查又插的，加上这个表的数据量已经在亿级了，索引曾经加过，但没有针对性地去做过优化。

其实索引并不是看哪个查得多就加在哪一列上，而是针对现有的查询方式以及使用情况加上去的，索引加上去，对于某部分的查询起到了一个很大的帮助，但到了1.5亿的数据量，查询又到了一个瓶颈。其实回到数据的最原始做法，把数据做小，查询才不会有问题。

举个例子，你能在移动服务服务厅上查几个月的数据吗？细心看看京东的订单，它也不提供一个日期控件让你挑哪天到哪天的订单信息。它会提供一个月内的订单，三个月内或一年内。其实这些数据也有可能不在原始表，会在一个"热"表上。“冷”表，"热"表，"原始"表

这些都拥有着同样的表结构，只是存的数据有所不一样。我说说当初的做法。因为原始表已经过亿了，服务器的性能再好也不能在它上面做很杂的查询了。因为会有"冷"，"热"表的词语出来。先说"热"表，"热"表是指用户经常要访问的数据，但不一定是由建帐到现在的数据，我们的业务上有一个页面叫我的收入，能看到我的帐号上的所有进出记录，包括奖励记录，一个活跃的用户一天都有可能起过一万条记录。千万的用户，活跃的用户也有百来万，所以这表相当大。但好在"我的收入"这个页面是做在微信上，在手机浏览，所以是往上拉再加载下一页，不会让用户自己输入一个页码跳到某一页上。所以热表只存着某个用户的前500条记录，当用户加载完这500条数据，再向"冷"表请求500条数据，然后再做一个定时任务，把每个用户超过500条的数据删除，这样一来就可以保证"热"表的数据量不会过大。

热表的数据保持在1亿以下，查询是不会有太大压力的。而"冷"表比热表存的数据要多一些，可以异步的方式去向"原始"表请求新的数据回来存储，"原始"表也可以分表去做存储。想想这方法在实现起来比较麻烦，也比较臃肿，但起码在性能上起了一个很大的作用，资源很快地得么释放，服务器的"高烧"也慢慢退下来了。但仍然会有些时候产生卡顿，因为还有些情况不是这个问题导致的，是因为某个流程很复杂，需要比较的数据很多，整个逻辑执行下来所花的时间不少，也要求逻辑严谨。比如提现。

    提现问题应该很多同行都遇到的，包括支付也是一样的问题。提现我们是直接发红包的，在高并发的情况下，如果余额未被扣除，但红包已经发下去了，用户再一次提现，估计公司有多少钱都不够发，加上这些损失是要算在开发者头上的。这些流程又占时间，逻辑又

复杂，业务又多。如果多人进行提现了，很容易出问题，也很容易导致服务器卡顿，服务器一旦卡顿了，可能影响了其它业务也不能正常使用。如何是好？这时想到了用队列的形式去处理，其实在提现上，支付上，人们都已经接受了延迟的概念了，想想银行的转帐，也不是实时到帐的，可能要隔那么几分钟。在我们的用户看来，你只要钱到了，慢那么几分钟是没问题的，总好过不到。在.net的环境下，对比了几个队列的性能以及开发学习成本，最终选择了RabbitMQ。前文也说过，很多问题，很多功能要快速解决，所以选一个成本比较低的来处理现有的问题。其实这个消息队列工具处理起来还是挺好的，至少出现的问题比较少。不过也是相对的。我们后期把这个服务装到Linux上了，包括前文提到的Redis，这两个服务在windows上很不稳定，性能也不及在linux上好。反正在windows上很容易就会挂了，不能访问，如果没留意，就很容易一大堆数据无法提交了。但放到linux上运行了几个月，没发生这样的事。奇了怪了。

    总结到这里，很多人可能会说。SB，这些问题的解决套路都是这样的。我已经工作了7年，这些问题也是在这家公司遇到。以前的公司压根儿就不会有这么多数据，数据能达到10万已经算多的了，也没必要用到均衡，也不用队列去解决并发问题，用户量少，并发都讲不上。一些大神们，可能也是从我这样的一个阶段去经历过才总结出来的经验，一些没做过这方面的事的大神，可能知道这些解决方案，但自身没遇到这些情况，也真不知道用的时候能不能奏效，因为我总结到，不同的项目遇到的问题都不一样，解决问题的套路都一样但方案可能不一样，要针对着所遇到的问题去处理，有些在技术上的性能可能不好，但运营改改体验可能就能做一个性能好一点的功能了，这些都要沟通去想。因为开发现在可能想的不只是编代码的事了，可能要想产品，要想运营，要想运维，还要想售后维护的事。各种各样的事多着呢。所以这一年，在这样的一家创业公司上，做得好累，学到的东西也很多。

    在技术上的总结差不多了，总结一下管理的破事。

    其实过这家公司是希望多接触管理团队的事，因为在职业生涯上是向管理方向走的，并非走技术方向。我在这家公司是一名开发经理，顶上有一副总，副总比较少理会开发团队的事，他做一些高性能的接口，他是典型的走技术方向的人。所以可以这么说，团队的管理全在我这边。

    在管理上，我第一次觉得自己的情商不够，情商这词是从老板上学到的。老板是一个情商十分高的人。是我非常愿意去追随的一位领导。对比我当初毕业出来工作，领导给我的印象就是喜欢骂人，你咋这么笨，这个东西都做不好，这又做不好，那也做不好。其实心理真不好受。但现在的管理（非国企），感觉是领导上下不是人，因为这个职位要承上启下。我的团队的离职率不高，培养起来也是比较顺手，因为基本的框架与底层代码在员工入职时已经搭好的了，带着他去学习不是一件难事。在组建团队时，有一点很重要，是要看清楚每一位同事他想要什么，你能为他提供什么，很多时候站在他的角度去想一些问题，但也要导致他要站在公司的角度去看问题。需要这边的加班非常多，但怨言不多，一起走过来的队友一直都在。很多人的离职是因为压力，我把压力分为两种，一种是心理压力，一种是身体压力。心理压力大很容易让人产生厌恶，从而产生离职，身体压力产生厌恶感远远比心理的要低。在创业公司上班，加班累是一定的话，身体压力就一定会有的，这个无法避免，但心理压力就不一定。在组建团队的过程中，要让队友在团队中找到方向，找到存在感，找到自己的责任所在。同时团队的气氛必须活跃，每天上班是期望的，而不是消极的。比如大家合资去买些零食，下午吃点东西吹吹水。吹水这点可以放开点，因为工作忙的时候，大家吹水的时间不会过长，闲的时候（好吧，基本没闲的时候），碍于其他部门同事的眼光，他自己也不会太长张扬。再比如加班时选个地点可以坐久点，聚在一起吃饭，大家聊聊工作，聊聊生活，都可以。这些经费是可以向公司申请的，如果这点经费公司都不愿付，估计你这团队的组建是比较难进行的。可以自费地去组织自驾游，去周边的景点玩一下，因为大家在公司有凝聚力，组织这些活动是很容易的。不要刻意去组织，可以在吹水提起不如咱们去哪玩哪玩。其实这些活动，会在不知不觉间提升了大家的默契，对团队是有着十分大的作用的。他会觉得这是一个大家庭，一起去做一些事是很有趣的，包括加班，大家做完手头上的事会问其他人有没有其他事他可以帮忙的，这样的一个团队后期是很好管的。

    另外，团队活跃不代表做事可以随便。我这里的一个工作比较难做的是要大家随时On Call，客服或销售有问题，在群上去问问题时，会有人主动回复，并去解决问题。平时上班时间这些都不成问题，但到了周末，这会成为一个问题，因为很多人对周末还要做事很反感，反正我已经习惯了。这点是要培养大家的责任心，这个项目是你做出来的，你不处理谁处理，要换位思考，这些功能已经导致用户不能使用了，你还不处理，会给整个团队带来不好的影响，团队有荣誉感，个人承认这个团队，他也会主动去承担这些责任。有一个同事跟我说，他舍友经常笑他这些晚了还要在宿舍加班处理公司的事，他当初也很反感，觉得很累，但后来觉得这些都没事，只要把这事做好了，也对得起自己，对得起团队，对得起公司。这些概念是管理者需要向每位成员灌输的，也是管理者的工作之一。想想，在半夜打个电话叫同事回公司处理一些事，他说没问题，这种心情是无比的欣慰的。因为大家都围绕着同一个目标前进的，都有共同的方向，很多事是容易推进的。

   再说到工作量的问题，在这家公司工作量是很大的，但我不是那种什么需求，什么功能都说好，能接的人。有时也站在团队角度去想问题，尽量不能安排非常多的工作，但也要站在公司的角度去想问题，哪些是市场急需的，我们就尽自己的能力去做上去。一起成长，一起去经历才是硬道理。所以面对老板，我是会say no的，面对团队，我也会说大家配合一下，把这事给办了。这可能就是承上启下的作用。

    在管理上还有很多东西要学习，如上文说到的情商。队友因一些低级错误导致功能出现漏洞，导致给客户骂，这个时间你受气了，不是把他骂一通就算了，而是想办法与他一起去解决这事，这事解决后，要跟他分享一下这次教训与经验。让他知道这事是他的责任，他有必要要改掉这些坏毛病。责怪是不能解决问题的，问题出现了，首先不是要追究谁的责任，而是先把问题解决了，再看看后面如何去防止这些问题再次出现。

    在这家公司也有很多不好的事情，在下半年，产品越来越乱，乱到我没法控制到优先级，进度，对团队的需求改了又改，刚开完会决定这周要做的事，下一秒就变了，开始动工去做一件事，下一秒就停了。很多时候很无奈，很多时候想去纠正这些不好的事，但，始终不行，后期感觉做坏了，人浮于事。这也是一点不好的地方，于我，却找不到方向，动力去改变它，因为尝试过好多次，无法改变。这个时候不是个人要适应公司，而是明知公司的产品这样走下去出问题，自己却无法改变。这种很无奈。

    2017，团队会越来越大，管理的目标我很清晰，技术的方向我也很明确。有信心带大家走得更远，只希望在产品方向能有一个好一点的转变。