Порт монолитного серверного приложения для веб-сервисов попал

Question

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

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

У меня возникла мысль о том, чтобы разбить его на логические сервисные компоненты, удалить их из приложения, разместить их на Axis2 или Tomcat и поместить их в облако SOA.

Я написал много сервисов для Axis2, много работал с облаками SOA и написал несколько монолитных серверов, и это кажется прямым. Устраните как можно больше общего состояния - затем перенесите это в какую-нибудь БД, извлеките логические сервисы из монолитного приложения, повторите до завершения.

Но у меня плохое предчувствие, что дьявол кроется в деталях, и я уверен, что я не первый человек, у которого появилась такая идея.

Answer 1

Мой опыт работы с этими типами миграций системы / архитектуры, временными затратами и убийцами, как правило:

• Определение всех вариантов использования и функциональных требований.Примерно 50% не будут задокументированы.Из 50% 50% будут неправильными.Из 50% документов, которые являются правильными и правильными, 50% больше не будут действительными.
• Обеспечение обратной совместимости.Тот факт, что вы переходите на новую архитектуру, обычно не означает, что все клиенты будут перемещаться вместе с вами одновременно.
• Перенос существующих данных в новую структуру / модель / архитектуру.Это всегда занимает намного больше времени, чем вы думаете.Возьмите наихудший сценарий, который вы можете себе представить, с точки зрения времени / стоимости, удвойте его, и вы все равно будете коротким примерно вдвое.
• Модель контроля доступа.
• Документирование ваших услуг в ясной формеи полезный способ.Ваша блестящая новая архитектура SOA не будет стоить на корточках, если никто не сможет ее использовать.
• Тестирование производительности.Поразительно, как часто это пропускается или делается в самом конце проекта.Сначала создайте сценарии производительности, протестируйте инфраструктуру и базовые значения, а затем постоянно тестируйте и измеряйте их.Для архитектора это должно быть то же, что модульное тестирование для разработчика.

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