饿了么分布式服务治理及优化经验
|
副标题[/!--empirenews.page--]
《饿了么分布式服务治理及优化经验》要点：
今天我想站在一个大的角度上,看一下饿了么最近一年多的时间,经历的技术上一些痛苦的问题与改进的过程. 为什么讲比较痛苦的事情?昨天和一位专家聊天受益很大,他说人在什么时候能够自我驱动?就是痛苦的时候.只有感到痛苦,才会有改变.当然改变有两种结果,一种是彻底放弃沉沦,另外就是一想办法自动化、智能化,把自己变成一个高手. MVP 原则我现在也很痛苦,但是还没有放弃.先讲一下 MVP 原则,MVP(Minimum Viable Product) 现在比较火,一个产品是做大而全,还是可用就行?我从去年 3 月份加入饿了么,开始组建框架和工具的团队.中间件里面很多东西都可以去做,但是我真的需要把所有的东西都做全吗还是 MVP 原则就好?这是我们思考的一个问题. MVP 的意思就是做一个最小可用的就可以,大家以前很流行说,“世界那么大,我想去看看”,其实框架很多东西看看就好,做全做好是需要长时间积累的,我们缺的恰恰是时间.我们要做的就是立足现状,解决痛点问题.现在饿了么的现状说白了比百废待兴好一点.当有太多事情可以去做的情况下,更需要抓住重点,不死人的尽量不要去踏. 服务治理的现状服务治理是一个很大的话题,它涵盖了很多内容,比如前面晓波老师介绍的 Redis 治理、姚捷老师讲的链路监控系统,都可以涵盖在里面. 编程语言先介绍语言,刚才会场一些人说他们是异构的语言,但可能还是没有饿了么这么复杂.饿了么语言主要有两种,Python 及 Java,原来整个公司语言都是以 Python 为主,可以说是上海最大的 Python 大厂.为什么不坚持用 Python?不是说 Python 语言不好,而是招不到人.在业务急速发展的时候怎么办?换 Java 语言就成了自然的选择. 在我进公司的时候,其实不仅仅是这两种语言,还有 PHP,C 语言等.基于这些现状,框架的选择点就比较少.因此做了一些妥协,SOA 的框架有两套,主要是为 Python 和 Java 做的,Python 的叫 Vespense,Java 版本的叫 Pylon,Vespense 和 Pylon 都是星际争霸里面的两种最基本的东西,没有这两种东西游戏根本打不下去. SOA 框架SOA 框架里面需要包含什么?首先必须包含 RPC,我们的 RPC 有两种：Thrift 和 JSON.Python 使用 Thrift,Java 使用 JSON.为什么 Java 框架重新选择一套 RPC 协议? 主要是觉得 Thrift 对 Java 不太友好.举个例子,用 Thrift 生成的 Java 代码在接口比较多的时候,它的一个文件就超过 20M,连 IDE 都拒绝分析这个文件.另外 JSON 是纯文本的,因为当初也没有日志系统,也没有链路跟踪系统,排查问题的时候,一种好的办法就是抓包,如果是一个二进制的协议的话那就痛苦.所以最终 Java 选择了 JSON.当然 RPC 都是对业务透明的,SOA 框架会屏蔽 RPC 细节,业务就像使用本地调用一样使用远程服务. 路由我们是基于集群做的,没有进一步细化到机器级别,因为觉得这个就足够了.此外也做了客户端的 SLB,还有熔断、降级、限流,这是保护服务的几大法宝,充分证明了这些东西拯救了我们很多次.经常看到监控群里面说,我们把什么什么服务限流了吧,把它降级了吧,那是因为这个服务可能写的不太好,把它降掉了,保住我们的主要业务.还有一些埋点,全链路跟踪等等,全部都内嵌在框架里面.这样的好处就是,增加特性只要升级一个框架就可以了. 服务发现与配置中心我们的服务发现和配置中心叫 Huskar,这是 DOTA 里面的一个英雄人物的名字,它是基于 ZooKeeper. 负载均衡负载均衡有好几种,首先有嵌在 SDK 里的软负载,拿到一个服务全部的列表,做一个轮循就可以了.这种策略有一些不足,比如一个 IDC 里面机器型号性能可能会稍微不一样,如果单纯用轮循会产生负载不均的问题.但这个问题当前还不是最紧迫的,我们可以绕过去,只要保证同一个集群里机器型号都是相同的就好. 此外也用中间层的方式,以前我们的 haproxy 用起来比较麻烦,配置复杂,而且它不能进行热加载,一个配置上去了之后需要重启一遍,因此工程师就用 Go 语言写了一个 GoProxy,基于四层,它会从服务中心把你需要的列表全部抓下来,做四层的负载均衡.他可以代理一些没有 SOA 框架支持的语言写的服务,也可以代理其他的基础组件,比如说像 Redis,数据库,它都会代理. CI / CD 灰度发布我们有 CI、CD 灰度发布的系统,叫 eless,虽然我们做了 CD 但是百废待兴,目前只有一些基本的单元测试,因为这个太耗工夫了.灰度发布也是基于发布系统做的,我们会在发布系统里面定义集群,每个集群里面的机器又分成不同的组,发布的时候按这些组来发布的,你可以先发一个组,观察没有问题后,然后再发其他的组. 监控与报警我们有自己的监控和报警系统.监控现在做的比较简单,是 statsd + graphite + grafana 的组合.现在最大的问题是监控系统不支持 tags,所有的指标汇聚到一起,一个服务的指标是汇聚在一起的,一个机器或者集群慢了,它会把这些指标分摊到其他机器或者集群上去的,所以查的时候比较困难,所以我们现在准备切成我们自己的系统. 报警系统也是自己写的.报警系统的需要是快、全、准.我们现在做的是全,逼着大家去把报警系统用起来,只看监控系统是看不过来.如果线上发生了一个故障,比如交换机发生故障,影响到某个业务,但是业务报警没有报出来,那业务要承担连带责任,因为你没有报警出来. 报警最常见的基于阈值,阈值这件事情比较痛苦,我们有很多指标,但这个阈值怎么去配,需要很有经验的人才能配好,阈值配小了,你会经常收到报警,配太大有可能出问题收不到报警,这个非常痛苦.所以一个同事提出基于趋势来配置来判断,我们在一段时间发现趋势在偏离了,就做报警. （编辑：辽源站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |