原文地址：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调用，调用的多，垂直切分不能满足需求，从而有了分布式架构，微服务架构。微服务多了，怎么保证各个模块的健康，高效合作，才有了服务治理。所以在小公司的区别和大公司的区别。就好像一个建一间房子，四合院，或者是一个小区，一个城镇的区别。有了需求规模，才有了对技术的要求。但是在大公司我可能也就是个拧螺丝的，在小公司，我需要自己建一套房子，谁也说不好哪个技术含量更高。