Как мне интегрировать два PHP-приложения - через общий код, REST, RPC?

Question

Я работаю над двумя взаимосвязанными веб-приложениями, разработанными на PHP, которые начались независимо. Со временем мы начали более тесно интегрировать их функциональность по деловым причинам. Для этого мы устанавливаем каталог для общего кода в отдельном репозитории SVN, чтобы мы могли развертывать разные версии этого кода при развертывании каждого приложения отдельно. Текстовый файл в любом хранилище приложения указывает, какая версия общего кода должна быть развернута.

Если до сих пор работал довольно хорошо, но возникли некоторые проблемы и соображения:

• Весь код, который используется любым приложением в этом общем интерфейсе, должен быть «видимым» для обоих приложений. Например, если элемент в приложении № 1 сохранен через приложение № 2, то весь вспомогательный код, классы ORM, поддерживающие классы и т. Д. Должны находиться в общей области.

• Если приложение № 1 выполняет вызовы методов для кода приложения № 2, то оно игнорирует весь код запуска приложения № 2 - аутентификацию, структуру и т. Д. Это может привести к нежелательным результатам и неожиданным зависимостям.

На данный момент мы предпочитаем хранить приложения отдельно.

Как лучше всего взаимодействовать между этими двумя приложениями? Мы могли бы использовать http-связь, которая обеспечивает надежный интерфейс и каждое приложение обрабатывает процессы через свои собственные процессы приложения. Мы беспокоимся о возможной нагрузке на http, но компромисс более слабосвязанной системы, вероятно, превзойдет эту проблему.

В настоящее время оба приложения работают на одном и том же наборе серверов и, как уже упоминалось, почти исключительно используют PHP.

РЕДАКТИРОВАТЬ: Связь будет конфиденциальной и аутентифицированной в приложениях, что означает отсутствие планов для публичного API.

Answer 1

Это компромисс, который вы делаете; База общего кода - все считается - проще и эффективнее. По крайней мере, в краткосрочной перспективе.

xml-rpc или простой API на основе http может хорошо работать и хорошо подходит для разделения обязанностей, поскольку вы получаете явные границы. Для полноты, SOAP также является опцией, но я бы ее не выбрал, если бы не принуждал.

Answer 2

Зависит от того, хотите ли вы интегрировать свое приложение с некоторыми другими приложениями. Если да, то я бы предпочел использовать архитектуру SOAP, чтобы у вас был лучший интерфейс для следующих приложений, возможно, на каком-то другом языке программирования.

Answer 3

На мой взгляд, используйте API на основе HTTP. Раньше мне приходилось иметь дело с этим с набором приложений, и общий код в итоге вернулся, чтобы укусить меня. Отсоедините их сейчас, если можете. Хорошая реализация кэширования данных с использованием pub / sub вместо постоянного опроса и т. Д. Должна сводить издержки к минимуму.