当前公司因为设计上的问题广泛使用了 Protocol buffers。
在使用的过程中发现了很多 Protocol buffers 的使用问题和滥用,一个好端端的工具被用成这样也是比较郁闷。
下面就对使用中的问题进行一些小的总结。
Protocol buffers 是为了加快网络数据传输,对传输数据进行压缩处理,通过通过暴露接口让程序之间能够更快的进行通信。
举个栗子,服务或者程序 A 需要获得用户的信息,但是获得用户信息的方法已经在服务或者程序 B 中定义了。
有几个解决方案。
我们来重点说说使用场景 3。在这个使用场景中,数据交换还是使用的 HTTP,定义的数据传输格式是在 proto 文件中定义的。
如果 B 程序中的方法改变了,但是传输格式没有改变,这是不会影响到程序 A 中的方法的。
通过 HTTP 的数据传输进行了压缩,效率比普通不压缩的 JSON 数据更小。对网络来说更小的数据就意味更大的效率。
简单的解释就是使用 Protocol buffers 就等于在场景 2 上面给你重新封装了一层。
Protobuf 限制最大的数据传输量是 2GB。
在默认情况下是 64MB。
不要以为使用了 Protocol buffers 就可以毫无节制的传输任何大小的数据了,其实不是这样的,如果程序中方法返回的数据量过大,或者对象 List 过于复杂。
你自然就会遇到超过 Protocol buffers 传输限制的大小,然后抛出异常。
这个和程序的设计也有很大关系,我们当前系统恨不得传输整个表,都不知道怎么说好。
没有人真正认真的维护 proto 文件,想怎么用怎么用。
结果的问题是:一个服务需要运行,需要启动其他 5 个服务才能在本地完成调试。
又因为每个服务的启动都占用端口,所以会导致各种方法进行交叉调用,让写好的程序非常难于在本地进行调试。
解决办法就是对每个服务的功能做出界定,不要过多的滥用 Protocol buffers 进行调用。
其实上面的问题都是人为导致的,再好的东西一旦滥用了,就是各种奇葩各种翔了。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。