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

DuBoisMark 发布于6月前
0 条问题

 一、什么是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应运而生。

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

整体架构图如下:

美团分布式服务通信框架及服务治理系统 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

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

四、总结

用服务进行设计

总是为并发进行设计

--《程序员修炼之道》

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

查看原文: 美团分布式服务通信框架及服务治理系统 OCTO

  • crazysnake
  • smallleopard
  • crazyrabbit
  • heavybird
  • organicelephant
需要 登录 后回复方可回复, 如果你还没有账号你可以 注册 一个帐号。