Что действительно отличается между SOA и микросервисами

10

отказ

Я надеюсь, что я не наступаю ни на чьи-либо пальцы и не оскорбляю энтузиастов концептов

Фон

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

Я читаю такие вещи, как:

  • побочные эффекты SOA
  • SOA - это анти-паттерн
  • Микросервисы пришли, чтобы исправить ошибки SOA
  • ESB на самом деле не ESB, а EAI
  • Чрезмерная зависимость от брокеров сообщений
  • Продавцы злоупотребляют понятием SOA и пытаются продать свою продукцию
  • SOA растет неудержимо

Но, тем не менее, ничто четко не определяет архитектурные различия между сервис-ориентированной архитектурой (как концепция) и микросервисами (как концепция)

Согласно тому, что я понял, они оба имеют:

  • Поставщики услуг делают только одно
  • Service Gateway / ESB, предоставляющий эти услуги потребителям
  • Потребители услуг, получающие доступ к услугам через ESB / Service Gateway

Вопрос

Итак, есть ли что-то отличное от перемаркировки SOA в микросервисах? это технологическое ограничение, ограничивающее превращение микросервисов в макросы?

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

Ссылки

Обновить

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

Вывод из СО вопроса:

  • MS является частным случаем SOA
  • MS поддерживает меньший размер служб размещения приложений
  • MS зависит от технологии (использование HTTP, а не открытых параметров протокола)
  • MS использует технологии для обеспечения дисциплины (автоматическое развертывание служб)
  • MS рассматривает ESB (зло), но использует API-шлюзы, которые IMHO является типом ESB

Это делает вывод, что MS является SOA, если верно следующее:

  • MS поддерживает понятие оркестровки? Один или несколько основных процессов управляют рабочими процессами
  • Есть ли в MS слой посредника сообщений? Набор адаптеров, переводящих форматы сообщений из пространства сообщений производителей услуг в потребителей услуг
  • Могут ли микросервисы считывать данные из монолитных корпоративных приложений? Это могут быть API монолитного приложения? или это должны быть автономные автономные приложения, способные работать независимо?

Если ответ на последний вопрос окажется отрицательным, то Microservices не сможет обрабатывать сложные системы рабочих процессов, например, системы управления кредитными картами или системы выверки.

A.Rashad
источник
Мода для распределенных вычислений в настоящее время - это небольшие, слабо связанные, децентрализованные, отказоустойчивые «агенты» или «модули», которые имеют четкие, конкретные обязанности и связаны друг с другом простым и понятным протоколом связи. SOA в значительной степени противоположна всему этому. Вы наблюдаете за кротовой стороной поверхностных сходств и пропускаете гору различий.
Роберт Харви
1
Разве SOA также не должен реализовывать небольшие слабосвязанные компоненты? Я знаю, что на заднем плане SOA находятся многофункциональные приложения, в основном описываемые как «лучшие в своем роде», предоставляющие услуги другим приложениям и потребляющие услуги от других приложений, используя любой формат сообщения, протокол и доступ к среде, подходящий для него
A .Рашад
Должен, но, как вы только что указали, обычно нет.
Роберт Харви
Martin Fowler's Site (I think he hates it big time)Это были не мои чувства, когда я отправился на его разговор в Барселоне. Он знает о компромиссах и о том, как люди слепо перешли на эту архитектуру, не считая, что MS подходит не всем.
Laiv
1
Микросервис - это связка маркетинга. Нет никакой разницы. Люди делали это много лет назад, и теперь кто-то назвал это, а теперь это что-то новое. Вы правы: MS - это (НЕ ОСОБЕННЫЙ) случай SOA. Пожалуйста, прекратите пытаться сделать что-то из этого.
Кайл Джонсон

Ответы:

12

Поставщики услуг делают только одно

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

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

Но это имеет некоторые тяжелые последствия:

  • Ваш процесс выпуска должен измениться, потому что развертывание нескольких служб отличается от развертывания нескольких десятков служб.
  • Ваш процесс выпуска должен измениться, потому что развертывание службы на одной машине отличается от развертывания на нескольких десятках машин.
  • Дизайн, использование и развертывание вашей базы данных должны измениться, потому что развертывание службы бессмысленно, если ей нужно развернуть эту большую совместно используемую базу данных (нарушая все остальные ваши службы).
  • Ваш дизайн и использование библиотек должны измениться, потому что развертывание службы бессмысленно, если нужно обновить эту общую библиотеку (нарушая все остальные ваши службы).
  • Ваша регистрация / авторизация / управление сеансом / и т.д. должно измениться , потому что это довольно легко поделиться вещами , когда вы только один сервисом, но отличается , когда у вас есть несколько независимых услуг мало, составляющие продукт - и они собираются в хочу поделиться материалом. О, и все эти общие вещи должны иметь дело с тем, чтобы быть на разных версиях.
  • Ваше общение должно измениться. С помощью нескольких сервисов вы можете разбить вещи по линиям, где общение происходит не часто и / или может происходить медленно. С микросервисами они будут много общаться друг с другом, и большие задержки не помогут.
Telastyn
источник
1
По всем этим причинам я рассматриваю микросервисы как конкретное решение конкретной проблемы (масштабирование с помощью распределенных вычислений), а не как общую архитектуру приложения.
Роберт Харви
1
Да, у них достаточно широкое влияние, и я думаю, что их следует рассматривать как архитектуру приложения с масштабируемостью / распределенными вычислениями в качестве положительного эффекта (со сложностью и другими недостатками в качестве компромисса)
Теластин
1
Итак, с архитектурной точки зрения, микросервисы - это автономные микросистемы, выполняющие одно дело, а SOA - это монолитные приложения с множеством сервисов, предоставляемых потребителям?
А.Рашад
1
Я сейчас больше сбит с толку! Возможно ли для монолитного применения выставить микросервисы? или это должны быть отдельные микро приложения?
А.Рашад
1
Взгляните на эту статью в DZone Microservices против SOA .
Laiv
2

Вот итог. Одно очевидное различие между SOA и микросервисами - это понятие

Умные конечные точки Тупые трубы

В отличие от SOA , это будет зависеть от забывчивых потребителей и производителей услуг, делегируя управление трафиком, трансляцию формата сообщений и управление сервисами внешним системам, например, ESB, Orchestrator, брокер сообщений.

A.Rashad
источник