饿了么的架构设计及演进之路(转)

一个产业的模型,快速地将它产生出来。“快”是第一位的,不需要花太多精力在架构设计上。在网站进入扩张期才需要对架构投入更多的精力来承载网站在爆发时的流量。饿了么成立已经8年,现在日订单量突破900万,我们也有了较为完善的网站架构。

  • 每周只有两天可以发布;
  • 周末是绝对不可以发布的;
  • 业务的高峰期绝对不允许发布;
  • 等等……

我们发现,发布的最大问题在于发布上去之后没有简单可执行的回退操作。回退操作到底是谁来执行,是发布人员就可以执行,还是需要专人来执行?如果是发布人员的话,发布人员并非24小时在线工作,出了问题找不到人怎么办?如果是有专人来执行回退,而又没有简单、统一的回退操作,那这个人需要熟悉发布人员的代码,这基本上不可行。 所以我们就需要有发布系统,发布系统定义了统一的回退操作,所有服务必须遵循发布系统的定义回退操作。 在饿了么对接发布系统是对所有人的强制要求,所有的系统必须全部接入发布系统。发布系统的框架很重要,这个东西其实对于公司是很重要的一件事情,需要放到第一优先级的队列里面去考虑。 四、服务框架 紧接着就是饿了么的服务框架,把一个大的Repo拆分成一个小的Repo,把一个大的服务拆成一个小的服务,让我们的服务尽量独立出去,这需要一套分布式服务框架来支撑。 分布式服务框架包含的服务注册、发现、负载均衡、路由、流控、熔断、降级等功能,这里就不一一展开了。前面已经提及,饿了么是多语言的生态,有 Python的,也有Java的,我们的服务化框架对应也是多语言的。这对我们后来一些中间件的选型是有影响的,比如说DAL层。 五、DAL数据访问层 当业务量越来越大的时候,数据库会变成一个瓶颈。 前期可以通过提升硬件的方式来提升数据库的性能。比如:

  • 升级到一个有更多CPU的机器;
  • 把硬盘改成 SSD 的或者更高级一点的。

但硬件提升终归是有一个容量限制的。而且很多做业务的小伙伴,写代码的时候都直接操作数据库,发生过很多次服务一上线数据库就被打爆的情形。数据库被打爆掉了之后,除非等待数据库恢复,没有任何其它机会可以恢复业务。 如果数据库里面数据是正常的,业务其实都可以补偿出来。所以我们做DAL服务层的时候,第一件事情是限流,其它的东西可以放一放。然后做连接复用,我们Python框架用的多进程单线程加协程的模型。 多进程之间其实是不可以共享一个连接的。比如:一台机器上部署了10个 Python进程,每个进程10个数据库连接。再扩展到10台机器上,就有1000个数据库连接。对数据库来说,连接是一个很昂贵的东西,我们DAL层要做一个连接复用。 这个连接复用讲的不是服务本身的连接复用,而是说DAL层上的连接复用,就是服务有1000个连接到DAL层,经过连接复用后对数据库可能只是保持着十几个连接。一旦发现某个数据库请求是一个事务的话,那么DAL就帮你保留这个连接的对应关系。当这个事务结束之后,就把数据库的连接,放回到共用池里面去,供其他人使用。 然后做冒烟和熔断。数据库也可以熔断的。当数据库发生冒烟时,我们会杀掉一些数据库的请求,保证数据库不至于崩溃。 六、服务治理 服务框架之后,涉及服务治理的问题。服务治理其实是一个很大的概念。首先是埋点,你要埋很多的监控点。 比如有一个请求,请求成功了或者失败了,请求的响应时间是多少,把所有的监控指标放到监控系统上面去。我们有一个很大的监控屏幕,上面有很多的监控指标。有专门小组72小时去盯着这个屏幕,如果有任何曲线波动了,就找人去解决。另外是报警系统,一个监控屏幕展示的东西总是有限的,只能放那些很重要的关键指标。这个时候就需要有报警系统。 罗马不是一天建成的,基础架构更是一个演进的过程。我们的资源和时间总是有限的,作为架构师和 CTO 来说,如何在这种有限的资源下,产出更重要的东西? 我们做了很多系统,觉得自己做得很不错了,但实则不是,我感觉我们又回到了石器时代,因为问题越来越多,需求也越来越多,总感觉你的系统里还缺点什么东西,想做的功能也一大堆。 比如对于流控系统,现在我们还是需要用户去配一个并发数,那么这个并发数,是不是根本不需要用户去配?是不是可以基于我们服务本身的一个状态自动去控制并发数? 然后是升级方式,SDK升级是个很痛苦的事情。比如说我们服务框架2.0发布的时候是去年12月份,到现在还有人用的是1.0。是不是可以做到SDK的无损感升级,我们自己来控制升级的时间和节奏。 还有,我们现在的监控只支持同一个服务上的汇聚,是不分集群、不分机器的,那是不是以后的指标可以分集群、分机器?举一个最简单的例子,比如一个服务上有10台机器,那么可能只是某一个机器上出了问题,但它所有的指标都会平均分摊到其它的9台机器上去。你只是看到了整个服务延时增加了,但有可能只是某一台机器拖慢了整个服务集群。但我们现在还做不到更多维度的监控。 还有智能化的报警,这个报警,就是要快、全、准,我们现在做到更快了,做到更全了,怎么才能做到更准?每天的报警量高峰时间一分钟一千多个报警发出去。所有的一千报警都是有用的吗?报警多了之后,就相当于没有报警。大家都疲劳了,就不去看了。我怎么能够把这个报警更准确地区分出来?还有更智能化的链路分析?以后是不是我们的监控不要放监控指标,而是放链路分析,这样就能够很清晰地知道,这个问题对应的是哪一个结点上出了问题。 这些问题涉及我们做事的一个原则:东西够用就好,但是要能够未雨绸缪,做一定的超前规划。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏大数据和云计算技术

大数据和云计算技术周报(第59期)

“大数据” 三个字其实是个marketing语言,从技术角度看,包含范围很广,计算、存储、网络都涉及,知识点广、学习难度高。

1202
来自专栏developerHaoz 的安卓之旅

如何有效报告 bug

这也是「技术支持」被视为一个可怕工作的原因。然而,并不是所有的 bug 报告都是让人不愉快的。我一直在没赚钱的时候维护开源软件,有时候会收到一些非常清晰的、有帮...

1052
来自专栏北京马哥教育

Python爱好者必看11个常用站点

学习一门编程语言,除了语法,最重要的是学习解决问题。很多时候单凭自己的能力确实无法做到完美解决,所以无论是搜索引擎、社区、文档还是博客,都是我们解决问题的利器。...

3394
来自专栏云计算

你需要了解的37个现代数据中心术语

让我们深入研究一下最重要的现代数据中心术语中37个术语和定义的汇编清单。

5106
来自专栏java一日一条

软件开发中最顶级的 17 个平台和工具

当你在决定使用哪些软件或平台来完成日常工作时,会存在很多选择。所以,我决定写一个我们在开发部门常用的软件开发工具列表,希望能对其他所有人都有所帮助。

1813
来自专栏即时通讯技术

达达O2O后台架构演进实践:从0到4000高并发请求背后的努力

达达创立于2014年5月,业务覆盖全国37个城市,拥有130万注册众包配送员,日均配送百万单,是全国领先的最后三公里物流配送平台。 达达的业务模式与滴滴以及Ub...

2083
来自专栏数据库新发现

好消息---Gmail增加免费POP3支持

Google网页数扩至80亿 增加免费POP3支持 (2004.11.12)   来自:ZDNET    在发布到Google公司blo...

1254
来自专栏CSDN技术头条

小故事:架构师需要做什么?

作者:Robert C. Martin 原文:A Little Architecture 译者:孙薇 责编:钱曙光 本文是一篇模仿问答的小故事,作者用幽默的风格...

2336
来自专栏华章科技

不懂这37个数据中心术语,怎么混数据圈饭局!

在今天的IT行业佼佼者中,“现代数据中心”这个概念得到了越来越多的重视。当然,它受到如此多的关注也是理所应当的。云计算,闪存存储,软件网络,容器以及大量的编排和...

992
来自专栏云计算D1net

云中的连续监测

云计算服务可以动态分配、使用和取消分配资源,以满足高峰需求。几乎任何系统都需要比其他系统更多的资源,而云计算允许计算、存储和网络资源随着这种需求而扩展。

1160

扫码关注云+社区