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

线程池配置：刚才说最重要的是限流,你不可能无限制的接受请求,不可能一百个并发你就接收一百个并发,并发到底怎么配?又是很复杂的事情.我经常看我们线程池的配置,这个东西要经过严格的性能测试,做很多调整才能调出来.在做性能测试的时候,其实有条曲线的,有个最高点的,我们在想在实时的过程中计算出这个最高点,但发现这个东西其实挺难的.

我们便用了另外一种方法,每个线程池用一个排列队列,当我发现它在涨的时候我就适当把那个线程池扩大一点,同时我们监测其他指标.如果发现在我扩大并发量的时候这些指标产生了报警,那我就把这个线程调整的操作直接拒绝掉,就保持原来那个大小.如果这些指标证明是没有问题的,那我就把它再扩大一点.

Cache,DB,Queue 的手工配置问题.还有一个是服务治理,Redis、数据库等配置还都是手工的,我们也不知道我们线上有 Redis,怎么办?我们正在做基础服务的服务化,业务其实不需要关心到底连到哪个 Redis,你上线的时候你告诉我你需要多大的容量,填个工单过来,运维帮你配好了,然后通过一些自动化的方式你把这些拿到初始化 SDK 就可以了.

故障定位

还有一个比较痛的问题就是排查问题很难.首先故障定位困难,每次我们出了事情之后,大家各自查各自的,比较低效.问题排查其实是有方法可以做,需要把它自动化,我们现在还缺这个东西,调用链分析是需要考虑去做.

性能退化

我们现在的业务增长量非常恐怖,去年我们是以 5 倍的速度增长了,但其实这个 5 – 10 倍要看你的基数,当基数很大,扩一倍量也是非常多,评估线上到底要布多少台机器是一件很复杂的事情.

我们成立一支性能测试团队,做全链路的压测.基于全链路压测的结果来评估整个系统的容量.这个全链路只能在线上做,也不能在白天压,只能在晚上低峰期的时候做.所以性能测试也是一个比较挑战的工作,不仅仅是智力上,也是身体上的一种考验.

全链路压测试一些服务有时候出现性能下降,比如 QPS 从 500 下降到了 400,但大家并不知道最直接的原因.上次毕洪宇老师也帮我们出了主意,比如把全链路指标拉出来做一下对比,看看哪些指标有变化,可能就是罪魁祸首.

容量评估的方法

容量评估方面容易出现温水煮青蛙的事情,今天流量增长一点没问题,明天再增长一点也没有问题,连续几天然后服务就挂了.这个时候怎么办?只能用最苦逼的方法,找个性能测试团队进行压测.有没有更智能化的方法?我们也正在探寻这条道路.

资源利用率低

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

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