饿了么分布式服务治理及优化经验

资源利用率低的问题.很多团队一碰到性能下降,就希望扩容,这会导致很多时候机器利用率只有 10%(更新一下数据,其实很多服务器的利用率不足1%).我们正在积极准备上容器化方案来解决这个问题.

服务依赖不清晰

大的系统中,服务依赖的调用链相当复杂,一个业务下去到底调用了哪些服务比较难说清.我们已经在做一个泳道规划.泳道这件事情有多种说法,有的人喜欢所有的服务都做一个大池子,只要保证它的足够容量就可以了,但是我更倾向小集群的思路,因为隔离起来就会更安全.

我们现在还没有做到按用户来区分泳道,目前只是按流量来切,50% 随机,部署的东西都一样.我们想通过泳道把这些流量隔离,VIP 客户可以把他放最重要的泳道里面,一些不那么重要的城市,可以放到另一个集群,如果不得已降级,只能牺牲这些次重要的用户.

服务治理的方向

有痛点就要努力,要么放弃,要么努力,这是我们努力的方向,前面讲了一下智能流控系统,超时推荐我们也做,大数据和智能化才是将来.有些监控数据只是落在磁盘上不用那就是浪费,是不是能把它利用起来?

然后我们也在做 Cache、数据库、Queue 等服务化.

Trace 系统我们也在做,拓扑图画出来,帮助大家了解是怎么回事,我们可以做链路染色,帮你了解问题的根源在哪里,我们也可以做依赖度的分析.我们说依赖分两种,强依赖和弱依赖.弱依赖要处理它,有一个异常出来的时候要把它干掉,不能把这个异常跑到最上面去,那整个服务就都挂掉了,但是大家并不知道到底它是弱依赖还是强依赖,这需要分析,我们去统计一下,它是一个强依赖还是弱依赖.然后弱依赖就可以做一些改进,比如做一些异步调用,节省整个服务的调用时间,优化用户体验.

容量预警我们通过做一些大数据的分析,所有的指标跟订单量这些关联,做一个相似度的分析,当这些指标偏离的时候,我们是不是可以认为它的容量有问题,当然这是努力的方向.

容器方面我们也在做,系统叫 APPOS,有的服务 CPU 只用了10%,但是我们规定了一台服务器只能装一个服务怎么办,那就上容器吧.

Q&A

提问：想问一下报警阈值设定,上面提到的方法是根据趋势来设计报警,这个趋势其实您能做到多少准确?能控制在什么情况下?

兰建刚：准确度的确是个问题,我们用了一个算法叫 3-sigma,准确度还不是特别确定,因为这个东西真的是服务治理里面最大的难题,报警分级怎么分?这是很大的学问,我们现在整个报警系统里面报警通道每天上千个报警,很多都不看的,因为觉得这个报警没什么意义.这是一个实际当中要去调整的问题.

提问：报警存在误报的情况?

兰建刚：对,你要知道我们的业务有两个明显的尖峰,十二点和下午四五点的时候都是订餐的高峰,之后则所有的指标都会有下降趋势的时候,如果你曲线偏离的很厉害就会引发报警.

多指标聚合是我们正在做的,发生一个指标报警的时候可能是一个小问题,但是这个问题会触发一个 CEP 的流程,比如“是不是 CPU 飙高的同时响应时间会抖动?”,我们可以定义这样整个一套规则,去做报警来提高准确度.

提问：刚才您提到用 Go 写的一个东西,为什么选择使用 Go 因为 Go 是自己的垃圾回收机制?而且我想了解一下您认为 Go 它是比较适合什么样的系统?

兰建刚：当然是底层的基础服务了,我们不建议用 Go 写业务.为什么我们选 Go 做工具,是因为我前面提到,公司原来一些工具是搭在 Python 上,有一帮 Python 工程师,让他去写 Java 他是绝对不干的,但是让他去写 Go 语言是没有问题的,Python 其实不适合写底层框架,因为它是个动态语言,工程化方面也会差一点.

提问：刚刚看到您提到超时配置推荐,这块是和你们的应用场景有关系,还是说和你们遇到的故障?

兰建刚：就是因为遇到故障了,因为很多超时配得很乱,有的同学直接配 3 秒超时(这是配置模版里的一个例子,很多同学就拿去直接用了),那还不如不配,有些情况很多服务就是 10ms 就正常返回了.只要保证这件事情对绝大部分的服务来说,是有利可图的,那我们就去做这件事情.

讲师演讲PPT下载地址：http://pan.baidu.com/s/1nvnOEBf

文章出处：高可用架构

（编辑：辽源站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!