11 | 服务发布和引用的实践

遇到过版本变更时序列化兼容问题 我们用的dubbo，经常会出现，某个dubbo接口的API升级：包含新增方法，或者某个方法的入参或者返回值新增字段。 我们的服务提供者更新消费者并不是一定要更新，如果我的api改动没有改动某个消费者调用的方法或者那个消费者可以兼容提供者的改动，那么消费者是可以不升级的。也就是允许系统中存在：服务提供者依赖的api是1.1版本，而服务消费者依赖的的api的jar包是1.0版本……这样的情况。 以前用hessian2做序列化方式，服务提供者单方面引用新版本api，老的消费者一样能正常调用。可是有同事听说FST序列化更快更强……于是某些接口改动了序列化方式为FST……发现这时依赖老版本api的服务都异常了…… 经验：性能是一方面，但也要考虑业务兼容性

这个服务引用配置文件放在哪里

<motan:service ref="userLastStatusLocalService" requestTimeout="50" retries="2" interface="com.weibo.api.common.status.service.UserLastStatusService" basicService="serviceBasicConfig" export="motan:8882"> <motan:method name="getLastStatusId" requestTimeout="300" retries="0" /> <motan:method name="getLastStatusIds" requestTimeout="300" retries="0" /> </motan:service> 这里的userLastStatusLocalService定义在哪呢？ 可以提个建议：每一章都把源码打包附加到文章尾部可以吗？只提供部分源码比较容易把人弄的越来越晕

一个接口上百个方法，设计上是否不合理

对于超大规模的分布式系统来说 服务详细配置信息放到消费者侧的方案不可取 因为涉及服务众多 底层服务根本不知道有多少上层服务对其有依赖 所以服务详细描述文件还是要放在配置中心里 解耦提供者与消费者 同时对提供者和配置中心提出要求 1 提供者：保证接口前向兼容 2 配置中心：明确性能规格 设置限流策略

使用dubbo遇到的一些坑。 之前没有形成规范，很多发布的服务都没有配置retry-time和和timeout导致经常出一些莫名其妙的问题。有些业务办理接口没有做幂等，接口超时导致重试，产生脏数据等。 后续主要通过团队形成一些规范来规避问题。

服务发布和引用的步骤是： 1、服务提供者定义接口，包括接口名，方法名，方法入参，方法出参等 2、在服务发布配置文件中配置接口名、通信协议、端口号，方法调用超时时间和重试次数 3、在服务引用配置文件中配置接口名、通信协议 服务发布预定义配置：为了解决多个服务消费者引用同一个服务的问题，可以用服务发布预定义配置的方式来减少消费者端的配置工作。 服务引用定义配置：但是随着服务方法数量的增多，每个方法都有自己的超时时间和重试次数信息，服务提供者所发布服务的详细配置信息都需要存储在注册中心中，配置信息占据内存容量会过大，每个消费者通过注册中心拉取最新配置信息时，会导致网络带宽被打满的情况。这种情况下，最好是把服务发布端的详细服务配置信息转移到服务引用端，注册中心中就不需要存储服务提供者发布的详细服务配置信息。 服务配置升级：服务升级就是把配置信息从服务发布配置文件中迁移到服务引用配置文件中。需要按照特定的流程来，先通过升级两台服务器观察升级是否成功，如果没问题再进行全部服务器的升级。

服务发布预定义配置如果遇到提供者接口超级多的极端情况的话建议把配置信息转移到服务信用配制中。请问老师如果这么做的话那不就每一个客户端都要配置一份了吗？这样的话客户端配制参差不齐的问题又出现了，总觉得这里跟您前面讲的矛盾了

多个服务消费者调用了服务提供者A，如果服务提供者A的接口参数发生变化，那所有消费者都需要变更，是否有好的解决方案呢？

目前只会spring cloud ，dubbo没有细研究过 只是看dubbo 官网会使用，觉得体系都差不多 没有太多机会去实战