微服务架构的服务兼容性问题整理笔记

1、jar包版本依赖

A、公共依赖包应定义在父项目的pom.xml <dependencyManagement> 升级的时候同步升级
B、非公共依赖包应定义在当前项目中的pom.xml
C、需要界定哪些是公共依赖包（例如：common之类）

避免问题：防止版本修改不及时，导致数据传递丢失（序列化，反序列化字段不统一就会丢失）

2、jar包版本定义格式

建议强制抽离到pom.xml <properties>定义（例如：<pegasus-common.version>1.4.2</pegasus-common.version>）

优势：进入后一目了然知道当前项目依赖的包，以及版本，在升级版本也不容易出错

3、接口升级

定义新增接口的格式（例如：/list 升级 list/v2），完全替换的话，应使用注释(@Deprecated)废弃原接口，并加上可废弃时间（真正废弃还得看某一时间范围内接口流量是否为0）

4、公共注解

抽离可全局使用的注解，spring的切面编程可以好好利用，这样也符合开闭原则（例如：redis缓存的公共注解、日志、数据校验、分布式锁等）

5、改造核心接口的注意事项

A、向上兼容（支持老得逻辑）
B、支持黑白名单（支持慢慢放量，回滚，关闭）
C、try,catch及时使用
D、全局异常捕获（标准异常透出：参数，服务，正常抛出）

6、response.code定义

A、系统级别1-99（公共包的全局异常捕获,程序员未定义的异常，避免返回数据包的格式错误导致前端无法正确解析）
B、各个微服务采用5位（区分3位的http.code，且支持更多扩容），每个微服务采用配置化前2位，例如：用户服务(10)-查询用户信息失败(001),对应code为10001

7、...

//TODO 持续更新中（整理到一定量后，进行汇总分类）