Protocol buffers 的问题和滥用

当前公司因为设计上的问题广泛使用了 Protocol buffers。

在使用的过程中发现了很多 Protocol buffers 的使用问题和滥用，一个好端端的工具被用成这样也是比较郁闷。

下面就对使用中的问题进行一些小的总结。

Protocol buffers 用意

Protocol buffers 是为了加快网络数据传输，对传输数据进行压缩处理，通过通过暴露接口让程序之间能够更快的进行通信。

举个栗子，服务或者程序 A 需要获得用户的信息，但是获得用户信息的方法已经在服务或者程序 B 中定义了。

有几个解决方案。

A 再重写一次 B 中已经定义的方法，这个显然是最不经济的，何必重写，并且还造成冗余，不便于维护。
B 程序提供接口，然后我们通过 HTTP 的方式访问，获得返回的数据然后进行序列化和反序列化。
使用 Protocol buffers，B 程序通过定义 proto 文件的方式将 B 中的方法暴露出来，A 程序可以在程序中直接使用这个方法，如果 B 程序的方法改变了或者升级了，A 程序也不需要做太多修改，因为在 A 程序中直接使用了这个方法。

我们来重点说说使用场景 3。在这个使用场景中，数据交换还是使用的 HTTP，定义的数据传输格式是在 proto 文件中定义的。

如果 B 程序中的方法改变了，但是传输格式没有改变，这是不会影响到程序 A 中的方法的。

通过 HTTP 的数据传输进行了压缩，效率比普通不压缩的 JSON 数据更小。对网络来说更小的数据就意味更大的效率。

简单的解释就是使用 Protocol buffers 就等于在场景 2 上面给你重新封装了一层。

Protobuf 限制最大的数据传输量是 2GB。

在默认情况下是 64MB。

不要以为使用了 Protocol buffers 就可以毫无节制的传输任何大小的数据了，其实不是这样的，如果程序中方法返回的数据量过大，或者对象 List 过于复杂。

你自然就会遇到超过 Protocol buffers 传输限制的大小，然后抛出异常。

这个和程序的设计也有很大关系，我们当前系统恨不得传输整个表，都不知道怎么说好。

没有人真正认真的维护 proto 文件，想怎么用怎么用。

结果的问题是：一个服务需要运行，需要启动其他 5 个服务才能在本地完成调试。

又因为每个服务的启动都占用端口，所以会导致各种方法进行交叉调用，让写好的程序非常难于在本地进行调试。

解决办法就是对每个服务的功能做出界定，不要过多的滥用 Protocol buffers 进行调用。

其实上面的问题都是人为导致的，再好的东西一旦滥用了，就是各种奇葩各种翔了。