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

отказ

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

Фон

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

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

• побочные эффекты 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 не сможет обрабатывать сложные системы рабочих процессов, например, системы управления кредитными картами или системы выверки.

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

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

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

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

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

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

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

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