一、什么是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利用先禁用节点摘掉流量，让流量打到别的机器上再下掉此节点，启动后做服务状态检查，检查通过，再接收流量来实现平滑发布。
特点5 - 周边生态
OCTO非常强大，强大在于它不是孤军奋战，是各个团队间的跨团队合作。这也是它被叫做“八爪鱼”的原因之一。
和内核团队，OCTO进行深度定制，比如链接复用、链接保护、原生异步支持。和HULK(容器团队，参见：欧阳老师的美团点评容器平台HULK的调度系统)团队的合作也是日渐紧密。静儿就是HULK团队的一员。合作的重要一点就是业界常提到的「流动计算架构」。解决的问题主要是提升业务可用性、资源利用率、深度devOps高效运维。
四、总结
用服务进行设计
总是为并发进行设计
--《程序员修炼之道》
相关阅读：