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

我们也在做 trace,前两天终于把拓扑图给画出来,把一个业务所有的调用展示成一个调用树,这样就可以很好的分析业务.我们现在是一个近千人公司,业务系统极度复杂,很少有工程师能清晰说出一个业务到底调用了哪些服务,通过这种 trace 方式来做辅助分析就很有用了.

光展示,我们觉得它的价值还没有利用到极致,可以把所有的调用关系和报警结合在一起.大家分析问题的时候,会发现如果某个点上发生的错误一直往上报,从而导致整条链路失败,那这个点就是 root cause,把它修复就可以问题解决了.我们做 trace 的思路是一样的,在调用链上进行着色,辅助找到问题的 root cause,也就是最初发生问题的那个点.

服务治理的经验

我们最重要的经验是做好保护与自我保护.

“不能被烂用的框架不是好框架”,这个是我们 CTO 经常说的一句话.原因是什么?比如我们那个监控的 SDK 曾经被业务错误的使用,每发一次报警就启一个新线程,最后整个进程因为开了太多的线程挂掉了.峰哥(CTO)说你无法预测每个开发者会怎么使用你的框架,即使框架被滥用了,最坏的情况,也需要保证能够活的下去.

所以后面写的东西都严格要求自我状态的检查,比如秒杀的时候,所有的监控系统,链路跟踪系统都是可以降级的,不能因为这些东西导致整个系统崩溃.

框架由于在底层,出了问题最容易被怀疑.比如一个 SDK,使用方说为什么占用了整个集群上 8% 的 CPU?跑过去一看,整个机器的 CPU 才 12%.某种程度做框架其实有无助的时候,容易被质疑及谴责,所以做好自我状态检查是很必要的.

定期线上扫描

为了避免滥用的问题,我们会定期线上扫描.比如一些日志本来就是可以降级可以丢的,但如果开发用了写文件的同步方式,那性能就会变慢,通过扫描发现这些问题,改成异步日志服务性能就会更好.

限流、熔断、降级

这个强调多少遍都不过分,因为确实很重要.服务不行的时候一定要熔断.限流是一个保护自己最大的利器,原来我们前端是用 PHP 做的,没有自我保护机制,不管有多少连接都会接收,如果后端处理不过来,前端流量又很大的时候肯定就挂了.所以我们做任何框架都会有限流措施.

有个小插曲,我们上 DAL (数据库中间件)第一版的时候,有次一个业务怎么指标突然降了 50%,然后大家去查,原来 DAL 做了限流,你不能做限流,你把它给我打开,听你们的我打开了,打开了然后数据库的 QPS 瞬间飙到两万,业务部门就慌了,赶紧邀请我们再给他限制住.这是我觉得 DAL 做的最好的一个功能.

连接复用

还有连接复用,有些工程师并不能特别理解,如果不用连接池,来一个请求就发一个连接怎么样?这样就会导致后端资源连接过多.对一些基础服务来说,比如 Redis,连接是个昂贵的消耗.所以我们一些中间件的服务都实现了连接复用的功能.

代码发布

上线发布是很危险的一件事情,绝大部分的事故都是由发布引起的,所以发布需要跟很多系统结合起来,所以我们做了整套流程.在每次发布的时候,一个发布事件开始,到我们这个监控系统以及调用链上,调用链就开始分析了,发布后把它的所有指标比一比,到底哪些指标发生了改变,这些指标如果有异常,就发报警,所有发布都会打到监控的主屏上面去,如果出了什么问题,这些事情优先回滚,如果可以回滚,我们肯定第一时间就把问题解决掉了.

服务治理的痛点

配置复杂

超时配置：超时配多少是合适的?100ms?300ms?极端情况有些业务配到 3 秒的.阈值怎么配和超时怎么配其实是同一个概念,并不是所有的程序员都知道超时设成多少合适.那怎么办?峰哥(CTO)想了一个办法,你的监控系统,你的调用链分析系统,你的日志系统,基础监控系统每天产生多少数据?这些数据到底有没有用?是否可以从这些数据里面挖掘出一些东西,比如这种超时的配置,是可以基于它历史的超时配置、所有请求的响应时间去做的.

这件事情正在进行中,但落地有点麻烦,比如说我们请求大概每天有三千万的调用量,你只有很小的一个比例它会超时,但是绝对量是很大的,你设置一个超时值,它可能有三万个请求都失败了.现在一直在优化这个东西,希望下次大家来我们这里的时候,能给大家详细介绍一下这个超时到底怎么做.

（编辑：网站开发网_盐城站长网 ）

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