отказ
Я надеюсь, что я не наступаю ни на чьи-либо пальцы и не оскорбляю энтузиастов концептов
Фон
Я искал реальные различия между сервис-ориентированной архитектурой и микросервисами, но не нашел четкого ответа.
Я читаю такие вещи, как:
- побочные эффекты 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 не сможет обрабатывать сложные системы рабочих процессов, например, системы управления кредитными картами или системы выверки.
источник
Martin Fowler's Site (I think he hates it big time)
Это были не мои чувства, когда я отправился на его разговор в Барселоне. Он знает о компромиссах и о том, как люди слепо перешли на эту архитектуру, не считая, что MS подходит не всем.Ответы:
Основное отличие, которое имеет широко распространенные последствия проекта, состоит в том, что с помощью микросервисов эти поставщики услуг могут быть независимо развертываемы и масштабируемы .
Это здорово, потому что вы можете быть более проворным. Если сервис нуждается в изменении, вы просто меняете его, ни одного из его родственников. Если вы хотите попробовать новый фреймворк или язык, просто сделайте замену этого сервиса. Если вам вдруг понадобится 100-кратная емкость, раскрутите несколько новых машин с этим сервисом, чтобы справиться с этим наплывом. Если вы хотите что-то версия, просто версия, не затрагивая всего приложения. И это делает вещи проще для мониторинга, инструментов, разделения среди команд, устаревшие ...
Но это имеет некоторые тяжелые последствия:
источник
Вот итог. Одно очевидное различие между SOA и микросервисами - это понятие
В отличие от SOA , это будет зависеть от забывчивых потребителей и производителей услуг, делегируя управление трафиком, трансляцию формата сообщений и управление сервисами внешним системам, например, ESB, Orchestrator, брокер сообщений.
источник