Оркестрированная и хореографическая сервис-ориентированная архитектура в больших масштабах?
Я архитектор крупной финансовой компании, и мы начинаем внедрять новую бизнес-ориентированную инфосистему в разных странах.
С самого начала основная идея заключалась в том, чтобы как можно больше следовать принципам, ориентированным на микросервисы (и убедиться, что инженеры прочитали книгу Сэма Ньюмана "Создание микросервисов" ).
К настоящему времени я пришел на перекресток. Нашими сервисами являются, прежде всего, сервисы JSON REST, использующие Swagger для автоматизированной документации, но для того, чтобы использовать эти сервисы в наших бизнес-процессах и не допускать вложения бизнес-логики в сервисы вне домена этих сервисов, мы использовали Camunda в качестве оркестровки инструмент. И с Камундой все в порядке (хотя некоторые рассматривают Corezoid как альтернативу), но несколько неуклюже в том, что в остальном является элегантным набором сервисов.
В настоящее время сервисная оркестровка является концепцией, довольно знакомой большинству инженеров. Но это тот, который меня не совсем устраивает из-за того, что у меня все еще есть центральный двигатель. Это невероятно дорого, чтобы заменить позже в будущем (хотя все еще дешевле заменить чем монолит). И даже если этот центральный двигатель разбит на несколько двигателей (что на самом деле имеет место сегодня), это не обязательно сделает его намного лучше.
В последние годы наблюдается движение с микросервисами к хореографической (близкой к управляемой событиями) архитектуре. Именно в этот момент я ищу советы от инженеров и архитекторов, которые сталкивались с подобными перекрестными решениями.
Мне очень нравится идея отделенной архитектуры, и, несмотря на то, что я чувствую себя хорошо, убивая монолиты и имея элегантные независимые сервисы, я все же обнаруживаю множество зависимостей в бизнес-процессе в целом в текущем оркестрированном решении, в котором оно фактически не должно существовать.
И это не значит, что мы избегаем событий. Мы также реализовали события в нашей архитектуре для того, чтобы отделить многие процессы с помощью основного принципа: если вам не нужен синхронизированный ответ и вам просто нужно уведомить о том, что происходит, чтобы инициировать другой процесс, создается событие, которое может быть пойман другим процессом, который начинает выполняться. А оркестровку легче объяснить и визуализировать, ее легче настраивать и модифицировать более технически настроенными бизнес-пользователями. И я думаю, что это проще для тестирования и проверки с точки зрения бизнеса. Подобная оркестрованная архитектура также (как правило) ожидает хорошего обнаружения услуг и качественной автоматизированной документации, а также нефункциональных требований, которые я очень ценю.
Все те вещи, которые являются вопросом для меня в хореографическом подходе, так как я не имею непосредственного опыта в выполнении этого в крупном масштабе - только некоторые локальные тестовые прототипы.
Но я думаю, ты видишь, откуда я. Я пытаюсь рассмотреть альтернативы, не сожалея о том, что в конечном итоге управляю компанией.
Возможно, вы можете поделиться своим собственным опытом с похожей ситуацией или поделиться интересной ссылкой или двумя? Или я ищу серебряную пулю, которой еще нет?
2 ответа
Сервисы должны взаимодействовать - сервисы, которые не взаимодействуют, не являются частью одной и той же системы. Для поиска необходим доступ к каталогу, корзина не получает информацию о цене со страницы, аккаунту нужна история покупок, рекомендателю нужна история покупок, корзина должна проверить доступные в настоящее время купоны, инвентарь должен что-то знать был куплен и т. д.
Границы обслуживания устанавливаются так, чтобы минимизировать необходимые взаимодействия. Может иметь смысл разделить службу на более мелкие компоненты, но если они совместно используют базу данных (внутреннюю структуру), они являются различными аспектами службы.
Когда сервисы взаимодействуют, он создает уровень связи - по крайней мере, это соединение - это некоторый API (JSON или другой), который сервис должен "поддерживать", чтобы другие сервисы могли взаимодействовать с ним.
Другой тип связи - это временная связь - это то, что вы получаете в ситуациях запроса-ответа (и вы можете устранить их в системах, управляемых событиями). Однако оркестрация и хореография не об этих различиях (хотя оркестровка в основном связана с запросом / ответом) - речь идет о центральном контроле и управлении в сравнении с гибкостью и непредсказуемостью.
Оркестровка имеет риски, такие как перенос бизнес-логики из сервисов в оркестровку, в то время как хореография рискует хаосом. Кстати, прямая интеграция запросов / ответов имеет худшее значение в обоих мирах, но выигрывает в простоте, когда системы достаточно малы.
Например, выбор между ними - это балансирование (как и большинство архитектурных решений). NETflix долгое время строил хореографию, но потом обнаружил, что им нужен контроль, и ввел механизм оркестровки. Ничто не является серебряной пулей:)
Лично мне больше нравится хореография из-за уменьшенного сцепления и гибкости, и я люблю такие инструменты, как open Zipkin, чтобы внести некоторый порядок в хаос.
Частичный пример для арки на основе оркестровки можно увидеть на слайдах 10-22 презентации, которую я сделал о микросервисах
Я думаю, что понимаю, откуда вы пришли, недавно переоборудовав систему в архитектуру "микросервисов". Мне нравится (и я использую) подход этих ребят: http://scs-architecture.org/
Суть в том, что вы пытаетесь избежать взаимозависимостей между вашими "услугами", что в основном делает хореографию устаревшей. Сложная часть состоит в разложении вашего проблемного домена на куски, которые не нуждаются ни в одном другом для выполненных бизнес-кейсов. Им могут понадобиться разные типы данных, которые могут или не могут быть "общими", как в настоящее время в нескольких системах, но им не нужны синхронные вызовы между ними для любого конкретного бизнес-случая.
Это сильно отличается от того, что делает, например, Netflix. Эти парни / девушки выполняют цепные вызовы через разные уровни услуг, каждый из которых добавляет свою логику в "процесс". Эта модель может подходить в некоторых случаях и, вероятно, подходит в случае Netflix. Но это может быть не нужно для вас.
Идеальная автономная система была бы полностью независимой от других автономных систем, охватывала бы одну или несколько весьма взаимосвязанных бизнес-функций (на всю глубину от пользовательского интерфейса до персистентности!) И не вызывала бы никакую другую систему синхронно. Идеальная система позволила бы клиенту "оркестрировать", просто предлагая ссылки через его веб-интерфейс (HTML).
Думай больше как амазонка. "Целевая страница" - это другое приложение, чем "Поиск", которое по-прежнему отличается от "Оформить заказ". Они совершенно разные, иногда даже выглядят немного иначе! Интегрировано по ссылкам и формам в HTML, не организовано явно.
Это может быть то, что вы ищете.
Некоторые предупреждения: Первый инстинкт некоторых людей заключается в том, чтобы иметь микросервис "Клиент" или микросервис "Репозиторий продуктов" и тому подобное. Это не приведет к автономным системам, так как вам понадобятся синхронные вызовы этих вещей, делающие их по сути "центральными" компонентами. Ключ состоит в том, чтобы разделить сферу бизнеса, так ограниченный контекст а-ля Эрик Эванс.