[转]美团.点评服务治理框架

原文地址：http://www.cnblogs.com/xiexj/p/7496347.html

美团.点评没用服务治理时的早期RPC架构：使用的是http+json调用，编码工做多，接口定义缺少强Scheme约束，不易规范化。http协议头较重，应用于内网时链路较长，有必定可用性风险。缺少服务自动注册发现机制，依赖人工运维。下图是美团.点评12年的服务治理架构，那时候我还在人人，人人用的也是这套架构。美团和人人仍是有很深的渊源的。

　　

　　这种架构存在服务注册中心强依赖zk,使用临时节点，容易因网络抖动致使不稳定。多语言支持带来的服务注册/发现需求，须要屡次实现类似逻辑，zk出现故障影响面大，不易进行隔离的问题。服务通讯框架未支持服务路由分组，机房路由，节点动态启停等策略。框架内强耦合，过多逻辑放到客户端，升级迭代困难，缺少服务数据采集，监控报警等机制。整体上未实现全生命周期的服务治理，运营，难以推动服务规范化，标准化。

 　　后来咱们就进入了OCTO分布式服务通讯框架及服务治理系统。OCTO是美团.点评内部公司级基础设施，为公司全部业务提供统一的高性能服务通讯框架，使业务具有良好的服务运营能力，轻松实现服务注册，服务自动发现，负载均衡，容错，灰度发布，数据可视化，监控告警等功能，提高服务开放效率，可用性及服务运维效率。

　　

• MTransport - 通讯服务框架。支持thrift, http，现包括mtthrift(java)，cthrift(C/C++)，pthrift(PHP)，Turbo thrift(Node.js)
• MNS - 命名服务。负责服务的注册，发现等功能。
• MSGP - 服务治理管理平台http://coto.sankuai.com 面向服务管理人员提供一站式治理功能。
• SgAgent - 本地代理，负责Region的划分，服务分组等特性功能的实现。主要在服务注册发现的时候采用代理模式，将注册发现结果保存在本地，策略热更新。避免了对zk的强依赖带来的网络抖动。
• HLB - 弹性负载均衡器。全部http请求/应答流量都会穿过这个系统，相似amazon elb。

 

作业务的嘛，下面从使用层面来说一下OCTO服务治理 。

　　首先定义服务：区分统一寄出组件服务，业务服务的分层，识别功能职责，边界。明确服务的负责人，备份负责人。

　　而后注册服务：肯定服务的惟一标识，与服务自己有关，和其角色（服务方，调用方）无关。OCTO平台注册服务：http://octo.sankuai.com/service/registry。建议格式为：com.公司(内部sankuai，外部meituan).业务线.具体服务名。

 　　其实这个服务治理是从SOA演化而来的，首先有面向服务，才有的RPC调用，调用的多，垂直切分不能知足需求，从而有了分布式架构，微服务架构。微服务多了，怎么保证各个模块的健康，高效合做，才有了服务治理。因此在小公司的区别和大公司的区别。就好像一个建一间房子，四合院，或者是一个小区，一个城镇的区别。有了需求规模，才有了对技术的要求。可是在大公司我可能也就是个拧螺丝的，在小公司，我须要本身建一套房子，谁也说很差哪一个技术含量更高。