Protocol buffer 这东西真的很轻便吗？
Protocol buffer 这东西一点都不轻便，定义文件后需要重新编译一次，编译出来的代码没有可读性，没有可调试的可能。
版本不兼容
Protocol buffer 的版本是不会向后兼容的，你必须要保证版本一致。
如果版本升级了，恭喜你，所有的文件都需要重新编译一次。如果你的项目在 Maven 的依赖定义的有点乱，比如说一个项目中有 2 个版本，那大概率会出问题。
这个问题不是编译问题，是运行时的问题，出了问题非常不好调试。
滥用
曾经一个公司可以说一个教科书基本的滥用典范。
为了调用另外一个服务的服务层方法，定义了 Protocol buffer，然后从另外一个服务的服务层调用。
这个项目有 10 多个微服务，本地调试有可能需要启动 3 到 4 个服务才能真正拿回来一个数据，在 DevOps 定义的时候端口定义不明确，经常让开发人员搞不清楚要那个端口。
启动的时候需要占用一个端口，我们在定义 Protocol buffer 的时候需要为 Protocol buffer 单独开一个端口，这要求令人发指，本地上经常的端口冲突。
为了重用方法，很多方法不加思索的就给了一个 Protocol buffer 定义，后来发现这个方法要修的话，参数一改，另外的地方就出错，数据调用异常，空对象。
Protocol buffer 这东西看起来很美好，用起来步步惊心。
效率
Protocol buffer 标称的就是效率高。
Protocol buffer 其实本身也是基于 JSON 的数据传输格式，而且在数据传输的消息上是有大小限制的。
默认可传输的大小不大，别指望返回以几万的 List ，大概率会报错。
Protocol buffer 的数据传输是通过压缩进行传输的，JSON 数据格式因为是文本，通常压缩比还是蛮高的，只是压缩也会消耗计算能力和资源，因此有时候压缩后的传输比较难分析真正 API JSON 调用中的数据。等于是开盲盒。
对于一些定义不明确的引用，方法老改的微服务，就那么几个服务在跑的项目，就别折腾了。
直接用 JSON 吧。
