7年前我飞去厦门帮男神做项目，得到的结果他们老板惊呆了，真是大牛啊。说一定要意思一下，不能让大牛白做，结果还是什么也没给，所以我衷心祝福那个老板尽快破产。但是男神却很鄙视我，鄙视了很多年。因为他看到了我的过程，觉得没有技术含量。事情是这样：当时男神做了一个extjs框架的管理系统。这个框架现在基本没有用了，因为它很重，页面渲染很慢。我的做法是服务一启动我就预测操作人员要加载哪个页面，偷偷给它预先加载上。虽然当时也用了压缩等很多别的技术，时间长了，不记得了。但是都是为了写文档好看，真正起作用的还是预先加载。被男神鄙视了很多年，我也思考了很多年，我的做法真的没有技术含量吗？后来知道了真正大牛的一些做法：谷歌曾静用一行代码代替了一个几万行的大文件，搜索速度提高60%。这行有名的代码有个官方名字，叫：jquery mini[汗]。其最核心思想是去掉空行，空白，注释。后来我学习了jvm，spring框架，他们都在预加载和懒加载上颇费苦心。仔细研究linux内核看到的也是大牛尽量将底层的复杂性抽象成一些简单的概念。如果现在让我说我当时是怎么做的，我可以用一些很专业名词：预加载，人工智能预测，大数据分析等等。金庸笔下的乔峰，遇强则强，平平无奇的招式到他手中都可以威力无比。关键是怎么用，别人搞不定的东西，到我手里可以很简单的方式解决，怎么就没有技术含量啦。好吧，为了让我家高大帅气，写得代码，下得厨房的男神能另眼相看，咱也研究点高大上的。

　　我在人人的时候，用的还是简单的RMI或RPC工具，简单的暴露和引用远程服务，通过配置服务的URL地址进行调用。负载均衡，好吧，我那时候那个部门数据量比较小，也就是master-slave做个高可用，都谈不上负载均衡。当服务越来越多，服务URL配置管理变得非常困难，单点压力也越来越大。这时候需要一个服务注册中心，动态的注册和发现服务，使服务的位置透明。而且消费方要能获取到服务提供方的地址列表，实现软负载均衡和failover。

　　像美团.点评现在，服务很多，沟通成本高，调某个服务失败该找谁？服务的参数都有什么约束？如何确保服务质量？如何降级或熔断？机器总是有闲时和忙时，或者荣誉机器防灾，如何极高机器的利用率，自动扩容？这些都是服务治理要考虑的问题。

 　　我在业务部门，对于服务治理只是用。但是原理要知道一些，否则遇到问题难以去排查。美团.点评没用服务治理时的早期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调用，调用的多，垂直切分不能满足需求，从而有了分布式架构，微服务架构。微服务多了，怎么保证各个模块的健康，高效合作，才有了服务治理。所以在小公司的区别和大公司的区别。就好像一个建一间房子，四合院，或者是一个小区，一个城镇的区别。有了需求规模，才有了对技术的要求。但是在大公司我可能也就是个拧螺丝的，在小公司，我需要自己建一套房子，谁也说不好哪个技术含量更高。有个朋友想挖我去他们公司当技术总监，待遇是我现在的2倍。待遇给到了，活自然也不会少。我有我家男神，还没被逼到这份儿上，还是想找个有点时间想学点啥学点啥的，走可持续发展的道路。

跑题时间：

　　周三晚上下班回家路上遇到一只肥胖的蛤蟆，它在人行道上趴着，吓了我一跳。然后它开始爬爬停停的走向草丛。让我想起自己170多斤的时候想跑跑不动的样子。这只蛤蟆很漂亮，一看就是蛋白质很充足，皮肤很光亮。自己更年轻的时候走过许多地方，现在已经不屑于为了旅行而旅行。用心去看，在哪里都会看到不同的世界。春天里行道树桃树和梨树间隔的排列，每天看到的花开的景象都不同，现在树上已经结满了果子。美团.点评的院子里紫薇花开的正好。让我想起东软时候满园的花儿。

　　每次换工作我都要给东软的赵叔叔发封邮件到他公司邮箱，15年他都没换过工作。他才大我5岁。我是开他玩笑才叫他叔叔，一叫叫了十年。赵叔叔对女孩子相当刻薄。经常见到他劈头盖脸的朝着小翻译骂。我觉得那些小翻译跟他说过什么事之后都会去厕所哭一会儿吧。但是他一见到我就会没了脾气。我们一起去日本的时候，经常加班到半夜3，4点。有时候他干完活儿睡着了，我有事儿找他，就毫不客气的把他叫醒。我们同去的人说我太过分了，但我不觉得，因为他从来没跟我发过脾气。我的最爱是巧克力。在日本过情人节之前，我念叨情人节都没人送我巧克力。结果，情人节当天，我们去公司的时候，每个女孩子的桌子上都有一大块的巧克力。但是其他女孩子桌子上的巧克力都或多或少的化掉了，只有我的是好的。大家都不知道是谁放的，只有我知道。因为在这前一天我看到赵叔叔买的，然后装到外套里面靠近胸口的兜里，因为太热，巧克力从靠近里面的部分开始化掉了。

　　在