Каковы плюсы и минусы PyRo и RPyC библиотек python?
-
05-07-2019 - |
Вопрос
Я ищу механизм удаленного вызова процедур для Python, и я нашел это PyRo (Удаленный объект Python) и RPyC (Удаленный вызов Python) и то, и другое - это то, что я ищу.
Тем не менее, мне любопытно узнать, как они соотносятся друг с другом и каковы их плюсы и минусы?
Решение
Лично я нахожу их примерно эквивалентными, но автор RPyC ( здесь ) требует большей простоты (и, возможно, для у кого-то не все, кто привык к распределенным вычислениям, у него есть точка зрения, я, возможно, слишком привык к этому, чтобы составить хорошее мнение ;-). Цитирую его ...:
хотя PYRO имеет длинный список значительные проекты в своем резюме, я найти настройку сервера тоже сложный, если принять во внимание количество необходимого кода, регистрация объекты, работающие серверы имен и т. д. Не говоря уже о количестве разных концепции, которые вы должны рассмотреть (события, переплет, с именем или без серверы, прокси против атрибута-прокси, имена должны быть уникальными и т. д.). А также это ограничено (удаленные объекты должны быть мариновать, чтобы вы не могли работать с удаленные файлы и т. д.). В общем, пиро имеет слишком много особых случаев и как правило, слишком сложно (да, я считаю это сложным). Так что из Конечно, я не независимый рецензент - но судите сами. Разве RPyC не проще и чище?
С другой стороны, PyRO пытается обеспечить некоторую безопасность (что, по мнению автора RPyC, в любом случае слишком слабо и лежит в основе многих заявленных сложностей PyRO).
Более независимый голос, Дэвид Мерц, предлагает здесь хорошее объяснение RPyC (PyRO существует намного дольше, и Дэвид указывает на предыдущие статьи, посвященные этому). «Классический режим» является полностью общей и простой частью с нулевой безопасностью, "по существу идентичной Pyro (без дополнительной структуры безопасности Pyro)"; «режим услуг»; более безопасен (все, что явно не разрешено, по умолчанию запрещено) и, по словам Дэвида, " сервисный режим по существу является RPC (например, XML_RPC), по модулю некоторых деталей относительно соглашений о вызовах и их реализации ». Мне кажется, это справедливая оценка.
Кстати, мне не особенно нравятся одноязычные RPC-системы - даже если Python покрывает 99% моих потребностей (и это не совсем так ;-), мне нравится тот факт, что я могу использовать любой язык для оставшиеся 1% ... Я не хочу отказываться от этого на уровне RPC! -) Я бы лучше сделал, например, JSON-RPC через этот модуль или что-то подобное ...! -).
Другие советы
YMMV, но вот мои результаты оценки RPyC, Pyro4 и ZeroRPC для использования в предстоящем проекте.Обратите внимание, что здесь нет подробных тестов, и это не задумано как подробный обзор, просто мои заметки о том, насколько хорошо каждый из них подходит для нужд моего предстоящего проекта.
ZeroRPC:
- довольно много зависимостей
- очень молодой проект (основная поддержка со стороны dotCloud)
- очень мало документации
- не могу получить доступ к атрибутам удаленного объекта, только к методам
- Из-за отсутствия доступа к атрибутам завершение вкладки IPython не работает на удаленных объектах
Пиро4:
- Поддержка Python3
- Хорошая, обильная документация
- зрелый проект
- Нет доступа к атрибуту / Завершение вкладки IPython
Пиро3:
- поддержка доступа к атрибутам (заявлена в документах;не проверяли)
- Нет поддержки Python3
RPyC:
- доступ к атрибутам, завершение работы с вкладкой IPython на удаленных объектах
- Поддержка Python3 (заявлена в документах;еще не проверено)
- неоднородная документация
FWIW:
Мне, как правило, нравится RPyC (может быть, потому, что это был мой первый?;-), но документация по нему скудная.Это было мое первое знакомство с RPC, и мне потребовалось много времени, чтобы "понять", как заставить все работать.Автор (Tomer) очень полезен и отвечает на вопросы из списка RPyC Google.
Если вы новичок в RPC, я бы посоветовал начать с Pyro и воспользоваться его надежной документацией, чтобы освоиться.Переходите к RPyC, ZeroRPC и т.д.в соответствии с вашими потребностями.