protobuf google protocol-buffers thrift hessian caucho

protobuf - ¿Recomendaría Google Protocol Buffers o Caucho Hessian para un formato binario multidireccional sobre la red?



protobuf python (8)

¿Recomendaría Google Protocol Buffers o Caucho Hessian para un formato binario multidireccional sobre la red? ¿O cualquier otra cosa, para el caso, Facebook Thrift, por ejemplo?


Muscle tiene un mensaje de transporte binario. Perdón por no poder comentar sobre los demás ya que no los he probado.




Utilizamos Caucho Hessian debido a los costos de integración reducidos y la simplicidad. Su rendimiento es muy bueno, por lo que es perfecto para la mayoría de los casos.

Para algunas aplicaciones donde la integración entre idiomas no es tan importante, existe una biblioteca aún más rápida que puede ofrecer aún más rendimiento, llamado Kryo . Desafortunadamente no es muy utilizado, y su protocolo no es casi estándar como el de Hessian.


Si necesita un soporte para interconectar aplicaciones de muchos idiomas / plataformas, entonces Hessian es el mejor. Si usa solo Java, entonces Kryo es incluso más rápido.


Para mí, Caucho Hessian es el mejor.

Es muy fácil comenzar, y el rendimiento es bueno. He probado el local, el latente es de aproximadamente 3 ms, en Lan puede esperar unos 10 ms.

Con hessian no tienes que escribir otro archivo para definir el modelo (estamos usando java + java). Ahorra mucho tiempo para el desarrollo y el mantenimiento.


Depende del caso de uso. El PB está mucho más acoplado, se usa mejor internamente con sistemas estrechamente acoplados; no es bueno para interfaces compartidas / públicas (como para ser compartido entre más de 2 sistemas específicos). Hessian es un poco más autodescriptivo, tiene un buen rendimiento en Java. Mejor que PB en mis pruebas, pero estoy seguro de que eso depende del caso de uso. PB parece tener problemas con los datos de texto, tal vez se ha optimizado para datos enteros.

No creo que ninguno sea particularmente bueno para las interfaces públicas, pero dado que quieres un formato binario, probablemente no sea un gran problema.

EDITAR: El rendimiento de Hessian en realidad no es tan bueno como, por referencia de jvm-serializadores . Y PB es bastante rápido siempre y cuando se asegure de agregar el indicador que obliga al uso de opciones rápidas en Java. Y si PB no es bueno para interfaces públicas, ¿qué es? IMO, los formatos abiertos como JSON son superiores externamente, y la mayoría de las veces lo suficientemente rápido como para que el rendimiento no importe mucho.


Yo diría que ProtocolBuffers, Thrift o Hessian son bastante similares en lo que respecta a sus formatos binarios, donde ofrecen soporte de serialización en varios idiomas. La serialización inherente puede tener pequeñas diferencias de rendimiento entre ellos (compensaciones de tamaño / espacio) pero esto no es lo más importante. ProtocolBuffers es sin duda un formato definido IDL con buen rendimiento que tiene características de extensibilidad que lo hacen atractivo.

SIN EMBARGO el uso de un "sobre-el-cable" en la pregunta implica el uso de una biblioteca de comunicaciones. Aquí, Google ha proporcionado una definición de interfaz para protobuf RPC, que es equivalente a hacer una especificación donde todos los detalles de la implementación se dejan al implementador. Esto es desafortunado porque significa que de hecho no hay implementación de lenguaje cruzado, a menos que pueda encontrar una implementación de lenguaje cruzado, probablemente mencionado aquí http://code.google.com/p/protobuf/wiki/ThirdPartyAddOns . He visto algunas implementaciones de RPC que admiten java yc, o c y c ++, o python yc, etc., pero aquí solo tiene que encontrar una biblioteca que satisfaga sus necesidades concretas y evaluar de lo contrario es probable que se sienta decepcionado. (Al menos me decepcionó lo suficiente como para escribir protobuf-rpc-pro)

Kyro es un formato de serialización como protobuf, pero solo para Java. Kyro / Net es una implementación de RPC java única que utiliza mensajes de Kryo. Por lo tanto, no es una buena opción para la comunicación "entre lenguaje".

Hoy parece que ICE http://www.zeroc.com/ y Thrift, que proporciona una implementación RPC lista para usar, son las mejores implementaciones de RPC entre idiomas disponibles.