Вы бы порекомендовали Google Protocol Buffers или Caucho Hessian для межязыкового двоичного формата?
Вы бы порекомендовали Google Protocol Buffers или Caucho Hessian для межязыкового двоичного формата? Или что-нибудь еще, в этом отношении - Facebook Thrift, например?
8 ответов
Мы используем Caucho Hessian из-за снижения стоимости и простоты интеграции. Его производительность очень хорошая, поэтому он идеально подходит для большинства случаев.
Для нескольких приложений, в которых межъязыковая интеграция не так важна, есть еще более быстрая библиотека, которая может увеличить производительность даже под названием Kryo. К сожалению, он не так широко используется, и его протокол не является квази-стандартным, как протокол от Hessian.
Зависит от варианта использования. PB гораздо более тесно связан, лучше всего используется внутри тесно связанных систем; не подходит для общих / общедоступных интерфейсов (например, для совместного использования более чем двумя конкретными системами). Гессиан немного более информативен, имеет хорошую производительность на Java. Лучше, чем PB на моих тестах, но я уверен, что это зависит от варианта использования. У PB, похоже, проблемы с текстовыми данными, возможно, он был оптимизирован для целочисленных данных.
Я не думаю, что это особенно хорошо для публичных интерфейсов, но, учитывая, что вы хотите двоичный формат, это, вероятно, не большая проблема.
РЕДАКТИРОВАТЬ: производительность Hessian на самом деле не так хорошо, как в тесте jvm-serializer. И PB довольно быстр, если вы обязательно добавите флаг, который заставляет использовать быстрые опции на Java. А если PB не подходит для публичных интерфейсов, что это? IMO, открытые форматы, такие как JSON, превосходят внешне и чаще всего не настолько быстро, чтобы производительность не имела большого значения.
Для меня Каучо Гессиан самый лучший.
Начать очень легко, а производительность хорошая. Я проверил местный, латентный составляет около 3 мс, на Lan вы можете ожидать около 10 мс.
С hessian вам не нужно писать другой файл для определения модели (мы используем java + java). Это экономит много времени на разработку и обслуживание.
Если вам нужна поддержка для соединения приложений на многих языках / платформах, то лучше всего использовать Hessian. Если вы используете только Java, чем Kryo еще быстрее.
Я сам смотрю на это.. пока нет хороших выводов, но я нашел http://dewpoint.snagdata.com/2008/10/21/google-protocol-buffers/ обобщены все варианты.
Muscle имеет бинарный транспорт сообщений. Извините, что я не могу комментировать другие, потому что я не пробовал их.
Я попробовал Google Protocol Buffers. Он работает с C++/MFC, C#, PHP и другими языками (см.: http://code.google.com/p/protobuf/wiki/ThirdPartyAddOns) и работает очень хорошо независимо от транспорта и сохранения / загрузки диска.
Я бы сказал, что ProtocolBuffers, Thrift или Hessian довольно схожи в том, что касается их двоичных форматов - там, где они обеспечивают поддержку межязыковой сериализации. Присущая им сериализация может иметь небольшие различия в производительности (компромиссы между размером и пространством), но это не самое главное. ProtocolBuffers, безусловно, является хорошо работающим форматом, определенным IDL, который имеет функции для расширяемости, которые делают его привлекательным.
ОДНАКО использование "по проводам" в этом вопросе подразумевает использование библиотеки связи. Здесь Google предоставил определение интерфейса для protobuf RPC, что эквивалентно созданию спецификации, в которой все детали реализации оставлены на усмотрение разработчика. Это прискорбно, потому что это означает, что де-факто НИКАКОЙ мультиязычной реализации не существует - если только вы не можете найти мультиязычную реализацию, возможно, упомянутую здесь http://code.google.com/p/protobuf/wiki/ThirdPartyAddOns. Я видел некоторые реализации RPC, которые поддерживают java и c, или c и C++, или python и c и т. Д., Но здесь вам просто нужно найти библиотеку, которая удовлетворяет вашим конкретным требованиям, и оценить, иначе вы, вероятно, будете разочарованы. (По крайней мере, я был достаточно разочарован написанием protobuf-rpc-pro)
Kyro - это формат сериализации, подобный protobuf, но только для Java. Kyro/Net является реализацией RPC только для Java, использующей сообщения Kryo. Так что это не лучший выбор для общения между языками.
Сегодня может показаться, что ICE http://www.zeroc.com/ и Thrift, которые предоставляют реализацию RPC из коробки, являются лучшими реализациями RPC для разных языков.