Какая хорошая практика для развертывания веб-сервисов?

Ответ 1

Вы пытаетесь внедрить поставщика данных или DAO в качестве службы. Сделать это -

• Простой
• Масштабируемость
• ОБСЛУЖИВАНИЕ чистые,
• Адаптируемый

Вы можете просто иметь один веб-сервис, развернутый за пределами WebApp (ов) и отключенной конфигурации. Сама конфигурация может быть сохранена как файл свойств или из базы данных. Идентификатор клиента должен передаваться в запросе webservice.

Это на самом деле довольно стандартный подход, реализованный для обеспечения оптимизации на уровне данных за пределами БД, например, кэширование (снова управляемое конфигурацией), истечение срока действия, объединение и т.д.

Другой вариант, который включает в себя как общую банку в webapp, да, имеет преимущество повторного использования кода (который вы также получаете с использованием внешней службы), но следующие недостатки перевешивают вариант.

• Связь
• Использование оптимизаций затруднено.
• Управление релизами (это также зависит от того, как организован ваш код)
• Versioning.

Надеюсь, что это поможет.

Ответ 2

Я предпочитаю подход ниже, который используется для одновременных пользователей 50K.

• Убедитесь, что каждая веб-служба инкапсулирует как пользовательский интерфейс, так и схему самостоятельно, выполнив необходимый бизнес-пример. Каждая веб-служба будет иметь все три уровня - Модель, Вид и Контроллер для этого бизнес-сервиса. Это означает, что ваш App-A - это один веб-сервис, а App-B - это другой веб-сервис.
• Все веб-службы будут регистрироваться и регистрироваться с помощью веб-сервиса Master. Главный веб-сервис отвечает за перенаправление запроса пользователя на соответствующий веб-сервис, например App-A OR App-B.

• У вас должен быть кластер основной веб-службы и кластер отдельных веб-сервисов - App-A и App-B

• В этом подходе ваша схема может находиться в другой базе данных вместо единой базы данных

Преимущества такого подхода:

• Каждый веб-сервис может масштабироваться горизонтально. Просто добавьте дополнительные узлы VM, если хотите увеличить масштаб.

• Если у вас разные схемы в разных базах данных в разных местах, вы избегаете узких мест в сети в OLTP-запросах (запросы обработки транзакций онлайн).

Недостатки:

• Я вижу только один недостаток, поскольку Master Web Service действует как Facade, и он должен знать внутренности отдельного веб-сервиса. Но это не недостаток преимуществ, которые он предлагает, если учесть компромисс.

Ответ 3

мои входы:

1) Любые конкретные причины для создания 2 разных войн для одного и того же кода? Это только потому, что у вас есть два разных источника данных для каждого из них? Почему у вас нет единого развертывания приложения с некоторым параметризованным механизмом в каждом запросе, чтобы определить, какая схема должна получать данные?

2) Зачем вам нужен веб-сервис на первом месте? Почему бы не приложить приложение непосредственно к базе данных, в которой он нуждался.

3) Является ли базовая транзакционная база данных или некоторые исторические данные? Как насчет слияния обеих схем в одном, как одноразовое усилие ИЛИ, используя какие-то виртуализированные представления, которые выбирают данные из 2-х схем на основе входных параметров.

***** отредактирован после входов Jay:

Мое предложение будет заключаться в том, что веб-сервис развертывается отдельно от 2 веб-приложений, поскольку он обеспечивает единое место для управления кодом в долгосрочной перспективе. У меня есть следующие предложения:

• Определите свои собственные заголовки в SOAP XML Schema, которые могут предоставить вам как appContext (вызов приложения), так и userContext (пользователь). Дайте хорошую мысль в этом аспекте, сохраняя долгосрочный взгляд.

• Сохраняйте запрос-ответ SOAP без сохранения состояния, который даст вам масштабируемость. Не поддерживайте любое состояние запроса SOAP на стороне сервера.

• В прошлом я использовал решение для виртуализации данных (CISCO Composite).. какие преимущества он предоставляет: если есть два (или более) источника данных, содержащие похожие типы данных (объектов), он может присоединиться, очистить и объединить его практически и показать его как веб-службу на основе REST/SOAP. Попробуйте оценить этот вариант. Что еще может помочь, если в будущем у вас есть другие пользователи для доступа к вашей информации, используя простой вызов SQL/JDBC, они смогут это сделать... также решения для виртуализации данных поддерживают многие другие интерфейсы для таких потребителей, как Hadoop, OData и т.д..Agay это зависит от бюджета и других ограничений проекта... Я не уверен, есть ли эффективное решение для виртуализации данных с открытым исходным кодом или нет?

Ответ 4

Я понятия не имею о ваших бизнес-требованиях, чтобы поддерживать разные схемы для пользовательских данных и работать с webservice.

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

Эта ссылка может помочь вам настроить несколько DS

Если вы воспользуетесь вышеупомянутой логикой, вы можете оказаться в одном развертываемом контексте.

По-прежнему хочется придерживаться нескольких войн как webservice, я бы предложил вам взглянуть на SpringBoot, простой, менее гибкий и масштабируемый контейнер.

Ответ 5

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

Вы можете посмотреть Microservices как идею, но это должно иметь смысл с вашей точки зрения.

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

Ответ 6

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

Ответ 7

Подход 1: - (Предполагаемый)

У вас должно быть одно веб-приложение, в котором будет весь код для пользовательского интерфейса приложения и взаимодействия репо/данных.

В зависимости от типа запроса динамически переключайте источник данных по мере необходимости. Вы можете посмотреть Spring Динамическая маршрутизация источника данных здесь

Подход 2: -

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

Снова в зависимости от типа запроса вы можете динамически маршрутизировать источник данных.

Надеюсь, что это поможет:)

Ответ 8

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

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

Плюс, если что-то не удастся, вы можете иметь 1 микросервис вниз, пока ваш основной все еще работает без перерывов, он будет отклонен только 1 службой, а не будет все вниз, пока вы ее исправите.

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

Ответ 9

Это действительно зависит от того, чего вы хотите достичь.

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

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

Если бы мы пошли на этот подход, появится вопрос. Зачем беспокоиться об этом слое? Не может ли каждое веб-приложение напрямую запрашивать db? Если ответ "Да", то просто полностью удалите весь слой.

Ответ 10

Учитывая вашу ситуацию, я бы посоветовал обратиться к ONE webapp (один "проект" ) с некоторым оговоркой, а затем рассмотреть одно из двух решений:

1) Учитывая, что вы используете spring, я предполагаю (надеюсь), что вы также используете maven.. Сделайте другую цель компиляции и сделайте так, чтобы в зависимости от цели, призванной произвести войну, соответствующий файл свойств отличается. Таким образом, у вас есть ONE webapp и на основе компиляции (или, скорее, на основе файла свойств, привязанного к этой конкретной компиляции), вы получите войну, привязанную к конкретной среде и схеме... Вы развертываете индивидуальную войну для каждого веб-сервиса с помощью чистое разделение, хотя корневой код тот же самый, и только одно приложение... [РЕШЕНИЕ CLEANER] 2) Сделайте так, чтобы вы не только получили запрос json, но и https-сертификат отправителя (таким образом, вы идентифицируете конкретный "webapp" на основе открытого https-сертификата) и на основе сертификата AND. Источник запрос, вы гарантируете источник как "квалифицированный" для получения данных из схемы X, а не схемы Y.. Вы развертываете только одну войну, которая, по своему усмотрению, применяет логику для перенаправления вашего "запроса выборки пользовательских данных" в одну базу данных или другой [Я УСТАНАВЛИВАЮ ЭТУ ПРАКТИЦИЮ]

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

Ответ 11

Я бы развернул один экземпляр. Не важно что. Конечно, существуют обстоятельства, при которых может потребоваться развертывание отдельно. Из лучшей практики "кодирования" один экземпляр должен использоваться, чтобы позволить "сразу один раз использовать многие".

Тогда...

• Определите различные XSD для каждого AppA, AppB и т.д. Маршалл соответственно.
• Или используйте Groovy для сортировки соответствующих объектов как json или xml.