跨语言统一治理Golang，谈谈另辟蹊径的开源RPC框架Motan
Posted 聊聊架构
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了跨语言统一治理Golang，谈谈另辟蹊径的开源RPC框架Motan相关的知识，希望对你有一定的参考价值。
随着容器化等技术的发展，微服务持续火爆。不同规模、不同业务场景的服务适合什么样的微服务呢？从无到有构建服务化系统会遇到哪些问题？微博在服务化过程中是如何演进，并逐步构建成支撑每天万亿级服务调用的服务化架构的？
2017 年 12 月 8-11 日，由 InfoQ 举办的 ArchSummit 全球架构师峰会将于北京举行，此次大会共策划 17 个技术专题以及 4 场深度培训，其中邀请了新浪微博技术专家、Motan 开源框架技术负责人张雷准备了《微博微服务化最佳实践》培训，借此机会我们提前采访了张雷老师并整理成下述文章，更多微博微服务架构细节，可识别下方二维码进行了解。
我的经历比较简单，最开始在一家游戏公司做支付业务，支付业务对系统的可靠性要求非常高，是一个需要更多细致与耐心的工作，当时参与了整个支付系统架构升级方案设计与实施。
支付系统的功能需求与迭代节奏相比其他系统是比较缓慢的，所以我想要尝试一些更有挑战性的业务场景，而且很多的技术需要合适的场景去应用、很多的问题也只有在特定的场景下才可能发生，当时微博的高并发场景对我非常有吸引力，对喜欢钻研的技术控来说微博是个非常难得平台，于是我在 2013 年加入了微博。
由于从事高可用架构及服务中间件方向与支付方向类似，也需要考虑非常多的细节，此外还需要考虑不同的业务场景，做架构或实现的 tradeoff、不断地调整实现细节优化性能，这是个非常有挑战性的方向，随后我也在高可用架构和服务中间件上获得了大量经验，也获得了更多的在技术广度与深度上的提升。
微博 DCP 属于公有云 + 私有云的混合云模式，在面对极端流量下能够做到快速动态扩缩容，能够提供 10 分钟扩容 1000+ 节点的能力。
今年主要在智能弹性调度方向做了一些探索，例如视频和 feed 等业务已经实现了高峰时自动扩缩容能力。这些尝试主要目的是完善全流程自动化，为后续的智能决策系统提供基础功能。在扩缩容阈值、扩缩容比例、前后置依赖服务管理、容量评估等在细节上还有较大的完善空间。
微博在无人值守方面进行了积极的尝试，目前在 feed、视频等自动弹性扩容中取得了比较好的效果，针对主要服务已经有比较合理的阈值计算模型，但现在主要还是高峰定时扩容和智能调度扩容相结合的方式。
微博的业务类型多种多样，不同业务的容量、性能评估侧重点也不尽相同，我们针对不同的业务抽象了多种性能评估模型、容量评估模型，并通过自动线上压测、历史数据训练等方式对评估模型不断修正以达到更好的效果。
其实智能调度的技术并不复杂，但是打通完整的智能调度链路需要花费大量的时间和精力，例如对模型所需数据的准实时采集、单机容量动态评估、自动化压测、全自动调度系统、对不同业务评估模型的迭代等。后续会对评估模型不断调优，适配更多的业务类型的计算模型，为决策中心统一智能调度打好基础。
如果微服务落地不当可能导致后期付出昂贵的成本，例如技术选型失误、服务化拆分解耦不彻底、服务拆分粒度过大或过小等，我觉得做服务化首先应该根据实际的业务场景、规模、发展速度、期望效果、实施时间等因素，综合分析制定方案。
服务化不是拆分的越细越好，过度拆分会大大增加系统的复杂程度。服务化的拆分优先以服务解耦为目标、在考虑业务发展规模、速度的前提下，尽可能的提高扩展性，然后拆分为小的阶段分期实施，避免一上来就搞终极方案。
服务间的依赖关系复杂，在业务快速发展的时期是经常会遇到的问题，有时候甚至因为业务的需求而难以避免，我认为关键还是做好服务的解耦，同时加强服务调用的管理，避免服务的误用。还可以通过 trace 系统来分析服务调用关系，精简调用链路。
Motan 其实就是魔毯的拼音，大家应该记得阿拉丁有一块神奇的魔毯，可以瞬间去到任何地方，我们希望我们的框架就像"魔毯"一样，可以极速地传输数据，而不用关心数据到底是如何传输过去的。
Motan 的发展大概经历的三个阶段：
第一个阶段主要目的是快速满足内部需求，这个阶段 Motan 功能快速迭代，Motan 自身特点也逐渐明确；
第二个阶段是开源阶段，这个阶段对 Motan 从功能与扩展方面进行了重新梳理，使 Motan 变得更加轻量，扩展能力更强。开源后，借助开源社区的力量，Motan 的功能也不断地完善；
第三个阶段就是目前正在进行的跨语言服务化阶段，这个阶段主要由内部跨语言服务的需求触发，通过对研发成本、后期维护、提供的功能、使用成本等方面进行评估，最终确定使用 agent 代理方式。通过内部几次快速迭代开发，最终确定了 weibo mesh 的服务化方向，将 Motan Agent 定位为统一服务管理的执行节点。
每个公司都会有一些定制化的需求，一个框架也很难满足所有的使用场景，最简单的场景，公司内部已经有针对服务器的监控和管理系统、日志采集系统、trace 系统等，自然需要新的系统能够和这些已有系统深度结合。另外，实际场景中也会有一些业务相关的统一处理逻辑，需要框架提供灵活的扩展能力来实现，比如认证等。
当时在开源与自研进行选择时，主要考虑了定制化需求、研发实力、后期维护等几个方面，结合实际情况，自研是当时的最佳选择。
Motan 进行开源时，也充分考虑了上面说的这些因素，因此轻量、扩展灵活、适合二次开发是 Motan 的主要方向。Motan 在开源前把内部依赖的相关部分进行抽象剥离，然后利用开源 Motan 框架的强大扩展能力，把内部依赖相关的功能通过 SPI 进行扩展，通过开源版本 + 内部适配扩展的方式实现了内部所有的定制化需求。
至于为什么选择开源，由于开源社区中有很多优秀的技术与框架，开源促进了技术的不断发展，我们从开源社区中有收获也有责任贡献社区。开源能让我们保持更高的质量要求，同时依靠社区的力量也能促进自身的快速发展。
Motan 框架在 2016 年开源后取得了社区的广泛好评，并且由社区贡献了众多 PR，开源后增加了全注解配置、不同序列化方式、异步调用、OpenTracing、Restful 等众多功能，得到了快速的发展。
我们也对跨语言服务治理方面进行探索和实现，我们实现了
Motan 的 Golang 版本 ：
https://github.com/weibocom/motan-go
Motan-PHP：
https://github.com/weibocom/motan-php
Motan-Openresty：
https://github.com/weibocom/motan-openresty
通过 Golang 版本的 Agent，把 Java 体系中成熟的服务治理能力提供给不同语言的异构系统使用，为平台统一服务治理提供基础。目前微博内部正在使用 Motan Agent 构建统一的 weibo mesh 体系。
跨语言服务化会是 Motan 近期的主要发展方向，非常欢迎对跨语言服务化、service mesh 感兴趣的朋友一起交流，一起完善 Motan。
service mesh 最近快速兴起，被称作下一代的微服务，在微服务与云原生应用中有着广泛的应用场景。service mesh 将微服务中业务无关的通用功能抽象为一个基础设施层，是轻量级的高性能网络代理。
weibo mesh 是由跨语言服务化的需求驱动而产生的，与 service mesh 的思路非常相似，也是想把服务治理的通用功能提出，放在单独的基础组件中，这样所有服务都可以获得统一的服务治理能力，并且可以做到无感知功能升级。
我个人的理解，service mesh 更偏向于服务的发现与通讯，在服务的交互过程中提供软负载、动态路由、熔断等通信相关功能，类似高级的 TCP 协议层。
而 weibo mesh 会更偏向服务治理方向，还会提供服务的动态管理能力，例如服务降级、动态配置、权限管理、数据采集、服务指令处理等，我们对 weibo mesh 的规划是 AI 系统的服务管理节点，可以根据智能决策系统的指令对服务做出动态管理。
目前的 weibo mesh 已经在平台 feed 与主站、热门、搜索中的部分业务上运行，但整体功能还比较简单，后续会逐步完善功能，并且会支持更多的交互协议，例如 redis 协议、mc 协议，将资源也作为服务进行交互管理。
Motan 的跨语言方案是为不同语言提供非常轻量的 Client，只实现与 Agent 的交互和必要的请求序列化能力；提供一个 local 的 Agent 代理，能够提供不同 RPC 协议交互能力，以及统一的服务治理能力与标准，服务治理的绝大部分功能都在语言无关的 Agent 中实现。通过使用 Agent，可以为类似 PHP 这样的解释型语言提供长链接复用能力，提高请求性能。
这种方案为不同语言提供了语言友好的 Client，由于 Client 非常轻量，后续的维护工作会非常简单；由语言无关的 Agent 模块为不同语言提供统一的 RPC 协议、负载均衡、HA 策略等服务治理能力支持，Agent 升级和维护都不需要使用方代码做任何变更。特别是在使用 Docker 容器化部署的场景中，Agent 可以作为组件打包至基础镜像，业务使用时可以很方便做到无感知升级。
选用 Golang 作为 Agent 的开发语言主要基于下面两个原因：
一个是 Golang 非常适合处理高并发的场景；
另一个是 Docker 生态中很多组件都是 Golang 实现的，后续 Motan Agent 作为基础组件会更容易和容器化相关功能进行结合。
性能对一个服务化框架来讲是必须要重点考虑的问题，但不是全部的问题，我觉得性能优化就像从海绵中挤水，只要使劲挤一定能挤出水分，使的力气越大，挤出的水分越多。
但是越往后，挤出水分的代价就越高，优化性能的性价比会逐渐降低。我们发现在实际使用的场景中，框架基本上不会是性能的瓶颈点，反倒是功能的需求会更加强烈。我们会在开发中充分优化性能，但不会只关注在这一个点上。
其实技术并无好坏之分，主要看适用的场合，Motan 在开发中肯定会遇到许多需要决策的问题，一般会在团队内部进行多次充分的讨论，一起分析利弊，再确定结果。如果讨论分析也无法清晰理出思路的情况下，可能会做一些快速试错，我们在微博跨语言服务化的过程中也进行过一些方向性的调整。
例如团队比较倾向于 gRPC 的服务描述能力，但在实际使用时发现切换成本过于高昂，而直接对原有 Restful 接口快速转为 RPC 的方式更受业务团队欢迎，因此，我们的方向也调整为在实现跨语言服务治理能力的同时，最大限度的降低迁移成本。
我觉得阿里重启 Dubbo 对整个开源社区是一个非常好的事情，Dubbo 与 Spring Cloud 都是非常优秀的服务治理框架，通过开源社区能够很好地推动服务化技术的发展。
当然 Dubbo 的重启也会对 Motan 带来更大的挑战，不过有竞争才会有发展，我们会更努力把 Motan 做得越来越优秀。如我前面所说的，目前 Motan 主要的发展方向是跨语言的统一服务治理，想把 Java 体系中成熟的技术更便捷地输出到不同语言的系统中，这与 service mesh 的很多思路是一致，但又会更加偏重服务治理的方向，从这点上来说，Motan 并没有在重复走 RPC 服务治理框架的老路，而是在探索一条属于自己的道路，前面会有更广阔的技术方向在等待我们。
再次推荐即将在下周五开幕的 ArchSummit 全球架构师峰会。
2017 年在架构领域发生了很多大事，Kubernetes 结束容器编排之争、Kafka 发布 1.0、Serverless 逐渐发力、边缘计算要取代云计算、Service Mesh 蓄势待发。另外人工智能为业务赋能，也给架构带来了新的挑战。
我们希望用 4 场深度培训和 100+ 分享来总结过去的实践，也展望面向未来的架构，献给聊聊架构的读者。我们还请来了王坚博士，让他来分享一下对技术的思考。
以上是关于跨语言统一治理Golang，谈谈另辟蹊径的开源RPC框架Motan的主要内容，如果未能解决你的问题，请参考以下文章