互联网应用系统的架构设计及演进之路Word格式.docx
《互联网应用系统的架构设计及演进之路Word格式.docx》由会员分享,可在线阅读,更多相关《互联网应用系统的架构设计及演进之路Word格式.docx(5页珍藏版)》请在冰豆网上搜索。
彼此之间的工作都互相了解,往往是通过“吼”的方式就把问题解决了。
但是随着人员的增加,这种方式显然是不行的,不可能一个人更新了代码再把其他人的所有代码重新上线一遍吧?
于是就要考虑分工协作的问题。
2.快速扩展
以前订单量可能从1k到1w,虽然增长了10倍,但是总量并不是很高,对于一个网站的压力来说,也不是那么大。
真的订单量从10w到100w,从100w到200w的时候,可能也只是扩大了10倍,但是对整个网站的架构上来说是一个巨大的挑战。
我们的背景就是2014年的100万突破现在900万,技术团队由刚开始的30多个人,到现在已经是超过900人的团队。
这时候分工协作就是个巨大的挑战。
服务的分分合合,团队的分分合合,这都需要一套框架体系来支撑,这也是SOA框架的一个作用。
看一下我们的现状,中间是我们整个架构的体系,右侧是和服务化相关的一些基础,包括基础的组件或者服务。
先说语言,我们原来的网站是在PHP上的,然后慢慢转型。
创始人都是大学生创业,那么理所当然Python是一个很好的首选。
到现在Python也是很好的选择,但是我们为什么要扩展到Java和Go呢?
Python很多人都会写,但是真正能把他做的很好的人并不多。
随着业务的发展,需要更多的开发人员。
考虑到Java成熟的生态环境,以及新兴的Go生态,我们最终选择了Python、Java、Go多语言共存的一个生态。
WebAPI主要做一些HTTPS卸载、限流,还有安全校验等一些通用的和业务逻辑无关的操作。
ServiceOrchestrator是服务编排层,通过配置的方式实现内外网的协议转换、服务的聚合裁剪。
架构图右边是一些围绕这些服务化框架的辅助系统,比如说用于定期执行一个任务的Job系统。
我们有将近快1000个服务,这些系统怎么监控?
所以必须有一套监控系统。
刚开始只有30多个人的时候,我们更擅长的是跑到机器上去搜一下Log,那么900多人的时候,你不可能都到机器上去搜一遍Log,就需要有个集中式的日志系统。
其他的系统就不一一赘述了。
罗马不是一天建成的,基础架构是个演进的过程。
我们精力有限,那先做什么呢?
服务拆分
当网站变大了,原来的架构跟不上发展的节奏了。
我们要做的第一件事情就是:
把大Repo拆成一个小Repo,把大服务拆成小服务,把我们的集中基础服务,拆分到不同的物理机器上去。
光是服务拆分用了一年多的时间才做完,这是一个比较漫长的过程。
这个过程中,首先要对API做一个很好的定义。
因为一旦你的API上线之后,再做一些修改的成本是相当大的。
会有很多人依赖于你的API,很多时候你也并不知道有谁依赖于你的API,这是一个很大的问题。
然后再把一些基础服务抽象出来。
很多原来的服务其实是耦合在原来的业务代码里面的。
比如说支付业务,业务很单一的时候,紧耦合的代码没有关系,但是扩展出越来越多业务都需要支付服务的时候,你每一个业务(比如说支付的功能)都要去做一个吗?
所以我们要把这些基础服务抽离出来。
比如说支付服务、短信服务、推送服务等。
拆服务看似很简单、没什么价值,但这恰恰是我们刚开始就要做的事情。
其实在这个时期,前面所有的那些架构都可以往后拖,因为不做架构调整其实不会死人,但是拆服务你不做的话,真的会死人的。
服务拆分必定是一个漫长的过程,这实际上是一个很痛苦的过程,也是需要很多配套系统的系统工程。
发布系统
发布是最大的不稳定因素。
很多公司对发布的时间窗口有严格的限定,比如说
每周只有两天可以发布;
周末是绝对不可以发布的;
业务的高峰期绝对不允许发布;
我们发现,发布的最大问题在于发布上去之后没有简单可执行的回退操作。
回退操作到底是谁来执行,是发布人员就可以执行,还是需要专人来执行?
如果是发布人员的话,发布人员并非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台机器上去。
你只是看到了整个服务延时增加了,但有可能只是某一台机器拖慢了整个服务集群。
但是我们现在还做不到更多维度的监控。
还有智能化的报警,这个报警,就是快、全、准,我们现在做到更快了,做到更全了,怎么才能做到更准?
每天的报警量高峰时间一分钟一千多个报警发出去。
所有的一千报警都是有用的吗?
报警多了之后,就相当于没有报警。
大家都疲劳了,就不去看了。
我怎么能够把这个报警更准确地区分出来?
还有更智能化的
10
链路分析?
以后是不是我们的监控不要放监控指标,而是放链路分析,这样就能够很清晰的知道,这个问题对应的是哪一个结点上出了问题。
11