饿了么：日订单量超900万的架构设计及演进之路(2)

但硬件提升终归是有一个容量限制的.而且很多做业务的小伙伴,写代码的时候都直接操作数据库,发生过很多次服务一上线数据库就被打爆的情形.数据库被打爆掉了之后,除非等待数据库恢复,没有任何其它机会可以恢复业务.

如果数据库里面数据是正常的,业务其实都可以补偿出来.所以我们做DAL服务层的时候,第一件事情是限流,其它的东西可以放一放.然后做连接复用,我们Python框架用的多进程单线程加协程的模型.

多进程之间其实是不可以共享一个连接的.比如：一台机器上部署了10个 Python进程,每个进程10个数据库连接.再扩展到10台机器上,就有1000个数据库连接.对数据库来说,连接是一个很昂贵的东西,我们DAL层要做一个连接复用.

这个连接复用讲的不是服务本身的连接复用,而是说DAL层上的连接复用,就是服务有1000个连接到DAL层,经过连接复用后对数据库可能只是保持着十几个连接.一旦发现某个数据库请求是一个事务的话,那么DAL就帮你保留这个连接的对应关系.当这个事务结束之后,就把数据库的连接,放回到共用池里面去,供其他人使用.

然后做冒烟和熔断.数据库也可以熔断的.当数据库发生冒烟时,我们会杀掉一些数据库的请求,保证数据库不至于崩溃.

六、服务治理

服务框架之后,涉及服务治理的问题.服务治理其实是一个很大的概念.首先是埋点,你要埋很多的监控点.

比如有一个请求,请求成功了或者失败了,请求的响应时间是多少,把所有的监控指标放到监控系统上面去.我们有一个很大的监控屏幕,上面有很多的监控指标.有专门小组72小时去盯着这个屏幕,如果有任何曲线波动了,就找人去解决.另外是报警系统,一个监控屏幕展示的东西总是有限的,只能放那些很重要的关键指标.这个时候就需要有报警系统.

罗马不是一天建成的,基础架构更是一个演进的过程.我们的资源和时间总是有限的,作为架构师和 CTO 来说,如何在这种有限的资源下,产出更重要的东西?

我们做了很多系统,觉得自己做得很不错了,但实则不是,我感觉我们又回到了石器时代,因为问题越来越多,需求也越来越多,总感觉你的系统里还缺点什么东西,想做的功能也一大堆.

比如对于流控系统,现在我们还是需要用户去配一个并发数,那么这个并发数,是不是根本不需要用户去配?是不是可以基于我们服务本身的一个状态自动去控制并发数?

然后是升级方式,SDK升级是个很痛苦的事情.比如说我们服务框架2.0发布的时候是去年12月份,到现在还有人用的是1.0.是不是可以做到SDK的无损感升级,我们自己来控制升级的时间和节奏.

还有,我们现在的监控只支持同一个服务上的汇聚,是不分集群、不分机器的,那是不是以后的指标可以分集群、分机器?举一个最简单的例子,比如一个服务上有10台机器,那么可能只是某一个机器上出了问题,但它所有的指标都会平均分摊到其它的9台机器上去.你只是看到了整个服务延时增加了,但有可能只是某一台机器拖慢了整个服务集群.但我们现在还做不到更多维度的监控.

还有智能化的报警,这个报警,就是要快、全、准,我们现在做到更快了,做到更全了,怎么才能做到更准?每天的报警量高峰时间一分钟一千多个报警发出去.所有的一千报警都是有用的吗?报警多了之后,就相当于没有报警.大家都疲劳了,就不去看了.我怎么能够把这个报警更准确地区分出来?还有更智能化的链路分析?以后是不是我们的监控不要放监控指标,而是放链路分析,这样就能够很清晰地知道,这个问题对应的是哪一个结点上出了问题.

这些问题涉及我们做事的一个原则：东西够用就好,但是要能够未雨绸缪,做一定的超前规划.

文章来自微信公众号：DBAplus社群

（编辑：ASP站长网）