算是总结2016，想一想2017

 

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

    想一想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，团队会愈来愈大，管理的目标我很清晰，技术的方向我也很明确。有信心带你们走得更远，只但愿在产品方向能有一个好一点的转变。