2021-07-23项目经理日记

项目经理日记

老家河南，前两天的暴雨袭击了省会郑州，造成了重大的人员生命和财产损失，让人悲痛至极，同时也看到人民军队迅速出动、各地消防千里驰援、全国民众踊跃捐款，让人感动之至。
据新闻报道，郑州当天的雨量是历史极值的三倍之多，大量的雨水短时间内流入到了河道、下水道、地铁地道、车库等，形成雨水积压，使之变成了最危险的境地。
很多的业务系统，在进行活动推广时，也会面临短时大流量冲击的问题。在一个极具诱惑力优惠或福利活动开展时，相当大的一个用户量级会短时间挤兑业务系统，导致服务器资源和数据库连接池瞬间爆满，进而导致系统无法正常提供服务，这就好比一群人同时挤在了一个狭窄的过道里，其结果只能是谁也进不去、谁也出不来。郑州的河道、地道、地库也像一个个容器，容器爆满了，容器里的服务也就失效了。
从事互联网项目的技术人员，大多都知道，系统在面临高流量、大并发用户访问时，该做些什么，接下来我也说几点，希望能够为今后的城市治理和规范提供些借鉴意义。
第一，提前预防。预防永远都是解决问题最好的手段，尽管很多时候也不知道提前预防些什么，但起码有一点很关键，就是让人有了心里预期。有次，业务条线就在半夜零点开展了一项产品促销活动，性价比非常高，活动开展几分钟，承担促销活动的业务系统就被拖垮了，结果不但没有达到活动的预期效果，反而招致了大量用户投诉。公司高层彻查此事，发现技术部门压根就没把此次活动当回事儿，高层动怒，直接撸掉一干人等。后续类似的活动开展，技术条线都会提前预防，并拿出像模像样的预防方案，比如和业务部门密切沟通、提前预估量级、链路保障、网络拓宽、服务器扩容、系统巡检，总之能使的手段全部上去，还有最后的定海神针的大招:安排人员现场值守，发现堵塞，马上重启服务。小题大做不是贬义词，是救命词。城市洪涝也是同样道理，首先在预防，比如加强和天气预报部门的沟通，就算不能准确预知是千年一遇暴雨，就按照常规暴雨或特大雨处置，政府小题大做一番，让群众心里有预期，城市职能部门该巡检的巡检，该演练的演练，把手段都使上去。
第二，权利下放。随着系统架构的演进，时下较为流行的微服务化、分布式架构受到很多的青睐，究其原因，就是去中心化，微服务架构的权利中心，不再像以往单体式项目过于集中。现如今我们所看到的一个互联网页面，页面上的各个功能模块在后台大多是单独部署、具有单独策略的实体，这些实体具有独立的伺机处事权。比如每年年尾，我们手机上的12306就会热闹起来了，前几年印象最深刻的就是，在抢票大战的时候，我们甚至连系统都登录不进去，好不容易登录进去，查询车票的页面也一直卡着不动，现在呢，你再看下12306的系统，无论怎样的业务高峰，我们的系统登录很流畅，车票的查询和预订也已经分离，纵使预订车票的时候需要长时间排队，但是车票查询已经不会受到影响，只有这样，才可以不会因为一个点而影响整体。试想一下呢，郑州的地铁运营单位，作为大城市这个整体中的一个实体，如果具有随时叫停地铁运营的权利，是不是会更好一点呢？
第三，时空拆借。互联网上的策略，诸如削峰填谷、熔断限流、消息队列、缓存、负载等等，无非就是时间和空间的互相拆借，拿着空间换时间。用户在页面上完成一件事，是有一条线路的，首先访问的前端的静态页面，静态页面通过请求后台程序，程序通过连接数据库拿到数据，然后再原路返回到页面，呈现给用户面前。如果大量的用户同时进到了静态页面这个前置层，那么关键点就是后台程序和数据库，容易形成瓶颈。常用的解决策略就是增加后台程序的服务器资源和数据库资源，就是把瓶子扩大，让更多的请求和数据进来。上海这边我们会看到，每个街道和社区都会有相应的河道配置，这个河道就是大雨来袭后的资源扩充，如果北方城市不具备天然河道，不妨多用挖掘机开辟几条大的河流，平时是景观河道，涝时则是救命稻草。