Будет ли развязка выгодна при редизайне устаревшего приложения?

Question

Я работаю в компании, имеющей несколько интернет-магазинов. Мы собираемся полностью переписать весь код: управление содержимым сайта и продуктами, обработка заказов, партнерские отношения, бухгалтерский учет, клиентская база и прочее. В настоящее время у нас есть система, в которой все компоненты (все внутренние сайты управления, бизнес-логика и веб-сайты интернет-магазина) тесно связаны между собой и работают на одном экземпляре LAMP, и абсолютно все данные находятся в буквально единой базе данных мусора. Из-за этого (а также из-за 10-летней разработки, частично переписанной с perl, качества php-кода), введение нового интернет-магазина, перепроектирование любого существующего или изменение чего-либо в логике - своего рода невыполнимая задача.

Чтобы не только переписать старый код, но и оптимизировать архитектуру системы, я, безусловно, решил отделить веб-сайты (друг от друга), отделить «бизнес-ядра» от веб-сайтов и бизнес-ядра друг от друга.

С одной стороны, все интернет-магазины в основном продают одну общую товарную базу, они являются своего рода зеркалами, иногда просто разработанными по-разному, чтобы ориентироваться на международных клиентов (названия и описания могут отличаться). Вещи, которые мы продаем, - это сервисный продукт, который зависит от местных партнеров, но с общим заранее определенным ассортиментом. Но в некоторых городах у нас есть специальные цены, в других городах мы предлагаем расширенный ассортимент продукции в дополнение к общему ассортименту. Таким образом, у нас также есть специальные веб-сайты, ориентированные на один город, веб-сайты, на которых продаются только специальные предложения и т. Д.

В отличие от решения, в котором у каждого веб-сайта есть своя собственная база данных продуктов (иногда это копия другого), я рассматриваю возможность объединить всю описательную информацию о продуктах, доступность в разных городах и / или различных сайтах и ​​цены в один изолированный Система управления продуктом и обслуживать всю информацию через SOAP. И каждый раз, когда любой пользователь посещает какой-либо сайт, сайт использует эту услугу (предоставляя некоторые параметры), а затем перечисляет продукты. Очевидно, можно создать библиотеку общего доступа, чтобы включить ее в каждый сайт.

1) Это решение адекватно? Будет ли он работать достаточно быстро без кеширования? У нас ограниченные ресурсы (1,5 разработчика), поэтому я стараюсь не вводить (когда это возможно) дополнительные технические сложности, такие как требование использовать memcached на каждом сайте.

2) Предположим, я реконструирую систему отделенным образом. Будет ли выгода достаточной, чтобы участвовать во всей работе с memcached и т. Д.? * 10101 *

3) Целесообразно кэшировать данные на стороне сервера SOAP, но не на веб-сайте, и продолжать делать тысячи запросов на мыло?

Все системы будут разъединены, некоторые веб-сайты, связанные с ними, например, обрабатывают заказ, авторизацию клиента (распространено на все веб-сайты), интеграцию приема платежей и т. Д. В случае обработки заказа, когда необходимо размещать веб-сайт удаленно, размещать его в системе обработки заказов через SOAP, а затем, в свою очередь, выставлять собственный SOAP-сервер для получения обновлений статуса заказа.

4) Правильно ли это разделение SOAP-ориентированной философии?

Используемые технологии: nginx, php, MySQL

Answer 1

Эдуард. Я постараюсь ответить на ваш вопрос. Сначала я приведу небольшую преамбулу, а затем пункт за пунктом:

I. Практически очевидно, что полное переписывание должно быть оптимизацией архитектуры системы, просто чтобы иметь некоторый смысл. В вашем конкретном случае введение «некоторой» модульности в архитектуру - это оптимизация такого рода. (Я также хотел бы подчеркнуть, что до тех пор, пока вы не будете связаны с какой-либо платформой приложений в стиле AR, в вашем коде должно быть не менее трех распознаваемых корпусов:

1) модель в настоящее время является очень «общим» термином, но все же имеет смысл отделять все абстрактные знания области (объекты и отношения) от всего, что не имеет к этому никакого отношения
2) организация персистентности данных, которая по сути является «слоем доступа к данным», но я надеюсь, что она может быть не такой плотной из-за структуры ORM по вашему выбору.
3) другой код библиотеки, который не является ни одним из перечисленных выше

С помощью этого параметра вы можете перераспределить и совместно использовать всю свою массивную часть кода на столько виртуальных узлов, сколько потребуется.

II. Небольшое замечание, которое я могу сделать, касается общей идеи качества приложения. Вы будете вынуждены найти баланс между краткостью вашей системы, сроками проекта и полученными метриками производительности. Все это противоречивые требования, но я не могу сказать, что является главным в вашем случае. Но слишком общий и абстрактный код может оказаться сложным в обслуживании, поэтому вам нужно будет иметь хотя бы правильное описание функциональных требований к полученной системе ... действительное по крайней мере 3-5 месяцев, я думаю.

---

Теперь соответствующая часть:
1) Адекватный? По крайней мере, он должен быть более подходящим, чем то, что у вас есть сейчас. Будет ли он работать быстро без кэширования? На самом деле я не знаю, но я думаю, что краткий ответ - «нет» - я полагаю, вы имеете в виду именно целевое кэширование данных (большие наборы данных), которые я не вижу подходящими для чего-либо подобного memcache. (Кстати, у вас нет 1,5 разработчика, но (1 - 0,25) разработчика, что дает вам 0,75, я думаю:))
2) В качестве предложения вы можете написать агентов, связанных с бизнес-логикой, чем-то менее дерьмовым, чем PHP. Кроме этого - зависит от вашего личного опыта с технологиями, которые могут быть задействованы. 3) Я думаю, что в любом случае это возможно, но я думаю, что кэширование на веб-стороне лучше, потому что вы можете устранить возможное узкое место
4) Для этого конкретного примера? Не в моем видении. В качестве аргумента я мог бы заявить, что интеграция двух веб-сайтов (!) В целом ужасный процесс.