美团分布式服务通信框架及服务治理系统OCTO

Posted 编程一生

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了美团分布式服务通信框架及服务治理系统OCTO相关的知识,希望对你有一定的参考价值。

    

 一、什么是OCTO

定义:

    OCTO是美团的分布式服务通信框架及服务治理系统,属于公司级基础设施,目前尚未开源。


目标:

    为公司所有业务提供统一的服务通信框架,使业务具备良好的服务运营能力,轻松实现服务注册、服务自动发现、负载均衡、容错、灰度发布、调用数据可视化等,持续提升服务高可用性、服务运维效率。


类比:

    美团点评内部类似的框架还有pigeon(已开源,https://github.com/dianping/pigeon)。OCTO是octopus(章鱼)的缩写,pigeon是鸽子的意思,一个水里游,一个天上飞,目标大体一致。

    业界同类产品有Dubbo。OCTO的功能因为主要内部用,功能要丰富的多。


规模:

    千亿级别

    静儿的老领导17年时做过一个QCon分享,叫《OCTO:千亿规模下的服务治理挑战与实践》。里面提到了16年OCTO日调用量已经超过千亿,目前这个数字还在高速增长。


二、产生背景

阶段1 - 垂直应用阶段

    这个阶段大体相当于目前运用最广泛的「分层架构」。把业务按照领域划分(垂直拆分),将一个大应用分成几个互不相干的小应用。


阶段2 - 早期分布式阶段

    随着规模的扩大,系统之间需要进一步拆分。将相同的操作抽象出来走服务化来实现复用和整合。这时候就需要使用RPC技术,初期使用HTTP+JSON来实现分布式。


这个阶段后期问题日益显现:

- 规范化和标准化差:缺乏强schema约束、需要较多的编码、调用方的学习和沟通成本高

- 效率低:HTTP协议头比较重;内部要走CDN、nginx等服务才最终实现端到端的交互;数据传输效率低(数据传输格式是json,它是文本格式的,比方说一个数字用二进制只占1个字节,用文本实际上存的是字符串,占3个字节)。

- 运维成本高:缺乏服务自动注册发现、依赖人工运维


阶段3 - 服务治理阶段

    这个阶段使用了基于thrift的高性能的RPC框架和基于zookeeper(zk)的服务自动注册发现。引入这些技术带来的问题:

- 可用性问题:强依赖zk,使用临时节点,网络抖动会导致不稳定,正常服务被下线;zk出现大规模故障不易进行隔离。

- 未实现全生命周期自动化运维:缺乏数据采集分析、监控报警等运维机制;难以推进规范化、标准化;路由策略单一


    为了解决上述问题,OCTO应运而生。


三、服务治理系统设计特点

整体架构图如下:


特点1 - 代理模式优化服务注册发现

    整体架构图中的SG_agent(服务治理代理Service Governance Agent)是直接安放在业务(使用OCTO的服务)服务器上的代理,也就是本地进程。实际承担服务注册、服务发现、动态路由解析、负载均衡、配置管理等功能及调用统计上报的应用代理程序。


代理模式带来的好处:

- 标准化:用thrift IDL(接口描述语言Interface description language)提供标准接口,美团技术人人都知道的appkey(服务标识)的概念正是由此而普及。这也是美团内部统一配置中心MtConfig的基础。

- 策略下移:将原来直接打成jar包让业务引用的策略放到代理层来实现,可方便的进行策略热更新,业务代码不再感知。

- 提升可用性:代理缓存解决了zk挂业务就挂的问题。自身又采用了基于冗余的高可用设计,整体大幅度提高了可用性。


特点2 - 状态检查提高可用性

    数据一致性问题一直是分布式系统的要点和难点。对服务注册发现来说,最重要的数据就是服务的状态。是否在假死(进程还活着,但是不处理请求,比如正在fullgc)?

    很多团队是通过「keepalive探针」(心跳)来解决这个问题的。这种技术好处是准确,缺点是高消耗。因为这是业务端主动发起的探测,很多场景下keepalive的IO消耗可能比服务自身还要大。

    OCTO采用的集中式的探测,早期是基于Akka Actor(用于远程通信的工具,特点是高效)的,通过热备、数据分析自动水平扩展、Double Check、熔断等机制,可用性和准确性都在6个9以上。


特点3 - 数据驱动

    美团内部非常注重的一点就是「用数据说话」。OCTO的主要数据包括:调用数据、异常调用、调用链路信息、全链路参数传递。数据展示形式包括:监控报警、数据报表、数据视图。


特点4 - 全生命周期

美团分布式服务通信框架及服务治理系统OCTO


    美团内部的服务从在“妈妈肚子里”就开始和OCTO打交道。服务注册、机器申请的信息都要先同步到OCTO。因为OCTO全周期性,所以可以对服务的各个阶段数据提供监控和优化方案。比如在发布部署阶段,OCTO利用先禁用节点摘掉流量,让流量打到别的机器上再下掉此节点,启动后做服务状态检查,检查通过,再接收流量来实现平滑发布。


特点5 - 周边生态

    OCTO非常强大,强大在于它不是孤军奋战,是各个团队间的跨团队合作。这也是它被叫做“八爪鱼”的原因之一。

    和内核团队,OCTO进行深度定制,比如链接复用、链接保护、原生异步支持。和HULK(容器团队,参见:欧阳老师的)团队的合作也是日渐紧密。静儿就是HULK团队的一员。合作的重要一点就是业界常提到的「流动计算架构」。解决的问题主要是提升业务可用性、资源利用率、深度devOps高效运维。


四、总结

用服务进行设计

总是为并发进行设计

--《程序员修炼之道》


以上是关于美团分布式服务通信框架及服务治理系统OCTO的主要内容,如果未能解决你的问题,请参考以下文章

美团下一代服务治理系统 OCTO2.0 的探索与实践

分布式微服务治理框架-选型

饿了么分布式服务治理及优化经验(含PPT)

一文理解分布式开发中的服务治理

分布式系统架构-侵入式服务治理方案

分布式服务治理框架Dubbo