这是一个发生在公司的真实对话：
A：我下载了你们的代码库怎么编译不通过啊，依赖中xxx-api-1.1.3版本的jar包找不到了，那可都是RELEASE版本啊。
B：你不知道我们nexus容量有限，只能保存最新的20个RELEASE版本吗?那个API现在最新的版本是1.1.31啦。
A：啊，这才几个月就几十个RELEASE版本啦?这接口太不稳定啦。
B： 其实接口一行代码没改，我们业务分析是很牛逼的，一直很稳定。但是这个API是和我们项目一起打包的，我们需求更新一次，就发布一次，API就被迫一起升级版本。发生这种事，大家都不想的。
如何看待这样的事情?
事情的起因是因为nexus容量不够，但是却暴露了一个问题，API没有改变，却在大量的发布无效版本。API的jar包在工程内部，对最初的开发是比较便利的，可以直接引用到未发布的代码，不需要maven build。
但是在后续长期的迭代过程中，这种和业务一起强制升级的做法，会极大的影响用户(调用者)的体验。我们一直说API应该是一种契约，一种承诺，那在平时生活中我们如何处理契约合同?— 合同都是一式两份，双方各保留一份作为凭证，如果要更新，需征得双方的同意。
而我们现在处理API代码的这种做法，相当于只保留了一份合同在乙方手里，乙方(服务方)想改就直接改了，甚至可以删除原来的合同(删除旧版本的api包)，导致甲方(调用者)根本找不到原来合同来维权了。
如何改进比较好?
将API作为单独工程，或者在Maven做Submodule可以设定单独的版本号，就不用一起升级了。不过这样都会带来额外的工作量，也可以在jenkins打包的时候设置参数，这部分API不和项目一起升级。
RPC和REST优缺点分析
RPC优势和缺点
优势：我们觉得RPC好用的原因就是可以将服务端的API功能直接发布为可以引用的代码，我们避免了解析Payload这样的繁琐工作。在初期上线的时候特别方便，减少了前端开发人员的工作量。
缺点：但是RPC的接口代码由服务端开发，服务端的人为了省事，往往把所有接口都放到了一个大的Endpoint中，号称“门面模式 Facade”。这就对调用者来说不方便了，也许我只需要调用一个接口，但是要把一个Facade所有涉及到的对象、参数、异常都导入进来，这样后续升级的耦合就麻烦来了。即使和我需要的接口没啥相关的，也会被迫升级。
REST优势和缺点
优势：而REST却恰好相反，因为REST只有协议定义，没有代码，甚至客户端是JavaScript，服务器端是Java，即使想重用代码也不可能。而且因为REST的Endpoint可以直接到资源这样的细粒度，调用者只需要实现自己的业务领域的客户端代码即可。松耦合带来了后续持续维护的便利
缺点：给我们初期带来了工作量。
微服务的陷阱
可以这么认为REST是一种意义上的依赖反转，明确了客户端的对协议、Payload的解析的代码责任是客户端自己的。作为调用方的开发者，我们不能依赖服务端的代码。传统的软件设计一直在强调重用，但是在微服务架构中，很多设计是反直觉的，我们必须要做一些反模式的折中设计，其中共享代码就是要反对的。对于微服务架构来说 -- 松耦合大于重用。
閱讀更多 萬米電商雲 的文章
