聊一聊Spring Boot和Motan这套组合。Motan是我这几年做微服务拆分时用得相当顺手的一套RPC框架不像有些框架那样配置繁琐到劝退也不像轻量到只适合玩具项目。如果你正打算在Spring Boot项目里引入RPC调用或者在Dubbo、Feign、Motan之间纠结这篇东西应该能帮你省不少时间。先说清楚这个标题要解决的问题Spring Boot项目如何把Motan完整用起来从依赖引入、服务发布、客户端调用到集群部署、高级特性实战以及真正上线之后会遇到哪些坑。我按自己实际接入项目的顺序来写不是官方文档的翻译版本里面会夹带不少我自己踩过的坑和调整过的配置。1. RPC框架选型与Motan核心设计1.1 为什么在众多RPC框架里选了Motan做微服务拆分之后服务之间互相调用是躲不开的事。选型那会儿摆在我面前的无非那几种方案基于HTTP的Feign、生态成熟的Dubbo、还有今天要聊的Motan。先说结论如果你们的服务基本是Java技术栈、部署环境以自建机房为主、并且不希望被注册中心和配置中心绑定得太死Motan的性价比相当高。Feign走HTTP协议入门确实快但到了业务量上来之后HTTP序列化开销、连接管理成本、超时控制粒度这些都会变成问题。Dubbo功能全但配置体系和学习曲线相对重而且它和Spring Boot的整合需要花点心思处理版本兼容。Motan的定位恰好卡在中间走自定义TCP协议性能不错支持多种序列化方案对Spring Boot的整合做得也比较直接基本思路就是加依赖、写注解、完事。Motan的核心设计从使用者的角度看就是三个关键词接口暴露、服务引用、注册中心。服务端把自己的实现类“暴露”出去客户端通过一个代理对象“引用”这个接口两边通过注册中心做地址发现剩下的网络通信、负载均衡、容错逻辑全部在框架内部完成。你要做的只是定义好接口、配置好参数业务代码几乎不会被侵入。1.2 Motan几个容易忽视的特性很多人在选型时只看功能列表忽略了Motan一些很实际的特性。第一是它支持多注册中心配置同一个服务可以同时注册到多个ZooKeeper集群这在做机房级容灾时非常有用。第二是它的过滤器机制通过Filter可以很干净地实现调用链追踪、鉴权、限流不需要在业务代码里到处埋点。第三是优雅下线机制服务端关闭时能把正在处理的请求跑完再摘除节点这在滚动发布场景里能明显降低报错率。Motan的序列化默认走Hessian但也支持JSON、Protobuf等跨语言调用场景下可以按需切换。我没法用一句话说它比Dubbo好或者比Feign好但如果你需要一个“能用得久、关键时刻不掉链子”的框架Motan是值得认真评估的选项。2. Spring Boot集成Motan的环境准备与依赖引入2.1 版本搭配是第一道坎Spring Boot集成Motan看似简单但版本搭配不对启动会直接报各种奇奇怪怪的错。我这里把自己实测的比较稳定的组合写出来给各位参考Spring Boot 2.x搭配Motan的spring boot starterJDK 8或11都行ZooKeeper作为注册中心版本用3.4.x或3.5.x均可。第一步是引入依赖。在pom.xml里加上motan-spring-boot-starter这个依赖即可注意starter会传递引入motan-core、motan-registry、motan-transport这些核心模块不需要额外逐个添加。我当时第一次手动把motan-core和motan-registry分开加结果因为版本号不一致导致Netty兼容问题折腾了小半天。后来换成只用starter靠它统一管理依赖版本这个坑才算绕过去。dependency groupIdcom.xxx/groupId artifactIdmotan-spring-boot-starter/artifactId version1.1.2/version /dependency版本号不一定必须用我写的建议以官方仓库最新的稳定版为准但有一点可以确定不要随手拉一个SNAPSHOT版本到生产环境。Motan的版本迭代节奏不算快稳定版之间差异不大选最新的release版最省心。2.2 核心配置项与注册中心接入引入依赖之后Spring Boot的application.properties里需要准备最基本的配置。先说说我常用的注册中心配置。Motan的注册中心抽象做得比较清晰只需要指定一个RegConfig告诉框架注册中心是谁、地址在哪。# 注册中心配置可配置多个用逗号分隔 motan.registry.reg.registry-classZookeeperRegistry motan.registry.reg.registry-address127.0.0.1:2181 motan.registry.reg.defaulttrue注意这个配置只是声明了注册中心服务端和客户端是否使用这个注册中心还要在对应的注解或配置里显式指定。我最开始踩过一个很无语的坑注册中心配置好了服务端也暴露了但客户端一直提示找不到服务提供者查了半天发现是客户端没有声明要使用这个注册中心默认走了直连模式。这点希望各位引以为鉴。在Spring Boot里还有一类配置是用来调整Motan性能底座的比如transport的线程池大小、连接池大小、请求超时时间。这些配置不一定要在一开始就调但需要知道它们存在。2.3 多网卡环境下的host地址匹配问题这个问题在真实机房环境里非常常见。服务器装了多块网卡Motan注册到注册中心时会选择一个本机IP去注册如果选错了客户端拿到这个地址连不上服务端会表现为间歇性超时或者调用失败。解决办法是给Motan设置显式的host地址。可以在启动参数里加-Dmotan.host.ip10.0.0.5或者把它写到配置文件里。这个值一定要是客户端能连通的IP别拿内网管理口地址去注册。我遇到过某次运维把服务注册到了管理网段业务网段的客户端全连不上最后在注册中心看到一堆“僵尸节点”排查的时候非常难发现因为服务端日志看起来一切正常。3. 服务端发布服务的三种姿势3.1 注解发布服务最推荐的方式注册配置就绪后服务端发布一个Motan服务的方式非常直白。定义好一个普通接口比如public interface OrderService { OrderInfo getOrderById(Long orderId); }实现类上加上MotanService注解即可MotanService(export motan:8002, group order-group) public class OrderServiceImpl implements OrderService { Override public OrderInfo getOrderById(Long orderId) { // 业务实现 } }这个注解干了什么事export motan:8002告诉框架要通过motan协议在8002端口对外暴露服务group用来做服务分组隔离可以在同一个接口上部署多套分组分别对应不同的调用方或环境。这样一套环境里“测试分组”和“正式分组”可以同时存在而不会互相干扰。注意这里有个容易被忽略的细节MotanService是框架自动扫描并注册的所以你的Spring Boot主类上需要保证包扫描路径能覆盖到OrderServiceImpl所在的位置。如果扫描路径不对服务不会暴露但Spring Boot本身还能正常启动不会报错风险非常隐蔽。3.2 API方式与XML方式的适用场景注解方式适合绝大多数新项目但Motan保留了API方式和XML配置方式在两种特殊场景下我会主动用它们。API方式适合那种需要动态暴露服务的场景。比如某些平台类型项目接口是业务方通过配置动态创建的没法提前写死。这时候可以用Motan提供的服务配置类在代码里创建ServiceConfig手动设置接口、实现类、协议、注册中心等属性然后调用export()方法发布。这种方式的灵活度最高但代码量也最大而且需要自己管理生命周期。XML方式是老项目迁移时会遇到的。Motan早期版本大量使用XML配置motan:protocol、motan:registry、motan:service等标签如果你接手的是这类老项目并且暂时不打算改造为注解方式只需要在Spring配置里沿用原XML即可新版兼容性做得还可以。但我的建议是只要条件允许逐步迁到注解方式毕竟XML文件里散落的服务配置在服务多了之后很难维护。3.3 服务端基本参数设置发布服务时还有一些基本参数值得花时间调整。我认为三个参数最重要第一个是requestTimeout控制服务端处理请求的超时时间。这个值不是越大越好设太大会拖垮线程池。比如下游调用数据库超时是3秒那这个参数设为3秒到5秒之间比较合理。第二个是maxServerConnection控制单机最大连接数。如果客户端很多这个值需要调大否则连接被占满后新请求会被拒绝。第三个是workerThreads服务端处理线程池大小。默认值对突发流量来说有点保守我一般会根据服务的TP99和机器核心数来调。比如8核机器、接口延迟在20ms以内设为200到300线程通常能扛住中等流量。4. 客户端调用的完整实操4.1 使用MotanReferer完成服务注入客户端调用Motan服务在Spring Boot环境下非常简单。在需要调用远程服务的类里直接注入一个被MotanReferer标记的接口字段Component public class OrderFacade { MotanReferer(group order-group, requestTimeout 2000) private OrderService orderService; public OrderInfo query(Long id) { return orderService.getOrderById(id); } }这个注解的解析过程是Spring启动时Motan的starter会扫描这些字段为接口生成一个动态代理这个代理负责从注册中心拉取服务端地址列表、做负载均衡、发起网络调用、处理超时和重试。你在业务代码里感知不到这些细节调用起来就跟调本地方法一样。这里说一个我实际遇到的坑MotanReferer注入的是Motan代理对象不是Spring容器里已有的Bean。如果同一个接口在本地也注册了一个实现类要特别注意注入的是哪个否则可能出现“调来调去结果调用到本地”的诡异现象。排查思路很简单看Motan启动日志里有没有生成对应的代理。4.2 直连模式与注册中心模式切换给位开发者可能在公司内部调试时需要连到对端某台机器上的服务而注册中心里有一堆节点在负载均衡。此时可以用直连模式指定固定地址motan.client.directUrl10.0.8.10:8002这个配置会绕过注册中心直接把客户端指向指定地址。直连模式适合联调场景也适合在注册中心出问题时的临时应急方案。但千万不要在配置里把直连地址写死到生产环境否则注册中心就形同虚设了。正常生产建议绕过直连逻辑走注册中心自动发现。客户端会订阅ZooKeeper上的服务节点变化服务端新增或下线节点客户端在很短时间内就会感知到。实测下来节点变更的感知时间默认在1秒内滚动发布时几乎无感知。4.3 负载均衡与集群容错策略Motan内置了几种负载均衡策略默认是随机算法但实际生产我倾向于使用一致性哈希或最少活跃数策略。随机策略的问题在于后端节点性能不一致时慢节点会被大量请求打中从而拉高整体时延。一致性哈希策略对相同请求参数总是路由到同一节点适合需要本地缓存或状态维持的场景。最少活跃数策略能动态感知节点负载情况优先把请求发给当前处理中的请求数最少的节点。客户端还可以配置集群容错策略。Motan支持Failover和Failfast两种主流策略。Failover会尝试在超时失败后重试下一个节点适合操作幂等的查询类接口Failfast则失败立即返回适合写操作避免一次业务请求被重复执行产生脏数据。这一点特别重要我在项目里就碰到过因为重试策略配置不当导致重复下单的问题。5. 高级特性过滤链、序列化定制与优雅下线5.1 过滤器机制的实际运用Motan的过滤链设计是它最值得称道的扩展点。你可以把过滤器理解为一次RPC调用旅程中的“收费站”在请求发出前、接收到响应后都能插入自定义逻辑。实现一个自定义Filter核心就是实现Filter接口public class TraceFilter implements Filter { Override public Response call(Caller caller, Request request) { long start System.currentTimeMillis(); try { return caller.call(request); } finally { long cost System.currentTimeMillis() - start; // 记录耗时、服务名等 } } }把过滤器配置到服务端或客户端的过滤器链中后所有的RPC调用都会自动经过它。用它做调用链追踪、鉴权、限流都非常顺手。我在实践里用过滤器做了两件事一个是把RPC调用都打上TraceId配合日志平台排查链路问题另一个是给核心接口做服务端限流避免下游被突发流量打垮。5.2 序列化方案的选择与坑Motan默认使用Hessian序列化这个选择在Java技术栈内部是稳妥的性能也不错。但如果你的服务需要跨语言比如有Python或Go的调用方Hessian会带来兼容性问题。在这种场景下可以切换到JSON或Protobuf。切换序列化方式不是只改一个配置就完事的还需要保证接口的类定义、字段结构在两端保持一致。我遇到过序列化方面的典型问题服务端升级接口加了字段旧客户端还在跑结果Hessian反序列化报错。虽然Hessian对新增字段的兼容性比Java原生序列化好一些但并不是彻底免疫。遇到这种场景最好将接口字段的变更设计为新增而非修改并且提前通知所有调用方升级依赖。5.3 优雅下线与滚动发布实践服务端重启或发布时如果强制断掉连接所有正在处理中的请求会直接失败。Motan的优雅下线机制能在这个场景下减少错误率服务进程退出前会先从注册中心摘除自己然后等待一段时间让客户端感知到节点变化最后再关闭端口。实测下来配合Spring Boot的生命周期监听器可以做到收到停机信号后执行Motan的优雅关闭逻辑等待10到15秒再执行Spring容器关闭。这样在滚动发布期间老节点的请求都能正常完成客户端最多在节点切换时出现一次短暂等待。我建议在发布流程里加一个健康检查脚本检测服务真正退出后再部署新节点。不然可能出现新节点还没起来老节点已经关闭中间有一小段服务真空期。6. 常见问题与排障心得实录6.1 服务端已注册但客户端找不到服务提供者这个问题出现的频次很高排查时遵循一个顺序先查ZooKeeper上的节点信息再用直连模式测试最后再回头检查客户端的注册中心配置。查ZooKeeper节点时看的是Motan创建的服务路径路径下应该能看到已经注册的提供者地址。如果这里没有节点问题基本在服务端要么服务没有真正暴露要么注册中心配置没生效。如果节点存在但是客户端报找不到服务问题多半在客户端的注册中心关联配置。这个问题的隐性原因还包括客户端和服务端用的注册中心集群不是同一个或者ZooKeeper连接超时导致订阅失败。你可以通过抓包或者查看客户端日志确认是否成功订阅了路径。6.2 偶发超时问题怎么定位偶发性超时是最让人头疼的因为它不一定每次都复现。我的排查套路是先区分是网络问题还是服务端处理慢。在客户端开启Motan调用耗时日志如果发现耗时分布有明显的长尾那基本就是服务端处理慢。服务端慢的进一步排查方向包括数据库慢查询、线程池满等待、Full GC停顿。Motan启用了线程池拒绝策略时会打印很明显的告警日志。如果是因为线程池满了就按前面提到的参数调大workerThreads同时优化下游依赖的耗时。有一种容易被忽略的情况是客户端和服务端处于不同的机房跨专线调用时网络延迟偏高。这种场景下除了调大超时时间之外更重要的是考虑做就近部署让调用尽量在同一个机房内完成。6.3 连接数被打满与文件句柄暴涨高并发场景下Motan服务端可能会出现连接数打满的情况。表象是日志里频繁出现连接拒绝客户端报连不上。此时先看系统层面的连接数上限比如ulimit的文件句柄限制以及TCP层的timewait状态连接。实践里我遇到过这样一件事某个服务连接数涨到接近上限服务还没挂但新连接无法建立。最后定位是客户端连接池配置太大导致每个客户端都建立了大量连接服务端连接总和远超预期。解决方式是调小客户端连接池大小同时限制单机最大连接数做到双向约束。如果服务端的TIME_WAIT连接特别多可以考虑调整系统内核参数开启TCP连接复用。这个操作需要和运维确认但往往能解决掉很大一部分连接资源浪费。6.4 版本升级引发的不兼容问题Motan版本升级不算频繁但跳过太多版本时可能会遇到注册中心数据结构变化或协议不兼容的问题。我的建议是升级时遵循一个原则先升级服务端再升级客户端并且服务端要保留一个版本周期来兼容旧客户端。升级到新版本后最快验证兼容性的方式是启动一个测试服务端用旧版本客户端去调用它看能否正常通讯。如果通讯失败要重点检查序列化相关的配置和协议版本设置。写在最后的几点体会Motan这套东西说实话用顺了之后会觉得它“存在感”很低这恰恰是好事。业务代码里没有一堆Xml和注解的干扰RPC调用就是一行接口方法的事。但存在感低不意味着底层没故事读源码时我发现很多细节做得非常扎实比如服务端的连接管理、客户端的路由策略、注册中心的容灾处理。最后再分享一个小技巧如果你所在团队刚开始接触Motan建议把一套完整的调用链做成Demo从接口定义、服务发布、客户端调用到注册中心节点查看、过滤链日志调试全部跑通一遍。这个过程会把框架的真实行为摸透比看十篇文档都管用。等到上线时遇到奇怪的问题心里起码有个大概的排查方向不至于慌了手脚。
