В конце октября мы запускаем новую группу курса «Архитектура и шаблоны проектирования» и приглашаем всех специалистов на бесплатный демо-урок.Теги: #отказоустойчивость #архитектура #Высокая производительность #Микросервисы #Системный анализ и проектирование #Распределенные системы #масштабируемость #Промышленное программирование #высокая нагрузка #сервис #монолит #soa #архитектура #надежность #стиль #сервисный #сервисный #распределенный # распределенный #распределенный #связность #связность #инерция #ориентированный #ориентированный«Шаблон адаптера» , который проведет Матвей Калинин, главный разработчик одного из крупнейших банков страны.
Введение
Выбор архитектурного стиля является одним из фундаментальных технических решений при построении информационной системы.В этой серии статей я предлагаю проанализировать наиболее популярные архитектурные стили для строительства и ответить на вопрос, в каких случаях какой архитектурный стиль является наиболее предпочтительным.
В процессе изложения я попытаюсь нарисовать логическую цепочку, объясняющую развитие архитектурных стилей от монолитов к микросервисам.
В прошлый раз мы сформулировали понятие микросервиса и определили основные положения, отличающие микросервисную архитектуру от сервис-ориентированной архитектуры.
Напомним, что микросервисная архитектура — это подход к разработке отдельного приложения как набора небольших сервисов, каждый из которых работает в своем собственном процессе и взаимодействует с помощью облегченных механизмов, часто API-интерфейсов HTTP-ресурсов.
Эти услуги основаны на бизнес-возможностях и могут быть развернуты независимо с помощью полностью автоматизированного механизма развертывания.
Существует минимальный уровень централизованного управления этими сервисами, которые могут быть написаны на разных языках программирования и использовать разные технологии хранения данных.
Проблема выбора
На самом деле микросервисная архитектура — это не панацея: она решает вполне конкретные задачи и влечет за собой большое количество проблем, возникающих наряду с преимуществами этого архитектурного стиля.
Независимое развертывание
С одной стороны, в микросервисной архитектуре нет необходимости координировать доставку и развертывание разного функционала.Это обеспечивает быстрый запуск, а сбой при развертывании не приводит к сбою системы.
Каждый сервис может быть развернут в том количестве, которое действительно необходимо, а специализация сервисов позволяет обеспечивать их только необходимыми ресурсами.
С другой стороны, из-за большого количества разнородных компонентов процесс развертывания в целом становится достаточно сложным и требует автоматизации.
Кроме того, усложняются процессы тестирования и обслуживания.
Переход от гигантских мэйнфреймов к множеству слабых машин приводит к проблемам с сетью, а сетевые соединения становятся медленными и ненадежными.
Повышение отказоустойчивости
Возможность самостоятельного масштабирования и развертывания позволяет повысить избыточность отдельного сервиса и при необходимости перезапустить его, не останавливая всю систему.Но необходимо учитывать, что каждый сетевой вызов может завершиться неудачей; любой сервис, с которым вы взаимодействуете, может перестать отвечать на запросы.
Кроме того, распределение данных по сети затрудняет обеспечение согласованности данных.
Гибкость и ясность
Жесткие физические границы сервиса обеспечивают низкую связанность, хорошее управление частями и их независимое развитие.Разработчики хорошо понимают свою часть системы.
Но независимость разработчиков приводит к хорошему эффекту, когда никто не видит всей картины.
Изменение стека технологий
Каждый сервис может использовать те технологии и стили, которые лучше всего соответствуют его условиям.Ошибочное архитектурное решение не фатально, так как его можно исправить в кратчайшие сроки.
Но наличие множества подходов и технологий затрудняет отчуждение услуг.
Более того, каждая новая технология — это новая возможность выстрелить себе в ногу.
Техническая сложность
На основании вышеизложенного можно сделать вывод, что разработка микросервисов — это достаточно сложная техническая задача, требующая особых навыков разработчиков, технических специалистов (DevOps) и тестировщиков.А также, что самое главное, определенная организационная перестройка и смена парадигмы мышления у отдельных людей.
Распространенные заблуждения
Существует ряд заблуждений, связанных с микросервисной архитектурой.Вот некоторые из них:
- Код станет чище.
Код не станет чище, если не будут предприняты усилия по его очистке.
- Проще писать модули, решающие одну задачу.
Это не проще, так как у таких модулей будет много интеграций.
- Работает быстрее монолита.
Monolith работает быстрее из-за меньшего количества сетевых вызовов.
- Инженерам будет проще, если им не придется работать с единым кодом.
база.
- Это самый простой способ обеспечить автоматическое масштабирование.
- И где-то замешан Докер.
Заключение
Предлагаю закончить на этой радостной ноте.В следующий раз мы поговорим о том, когда использовать такой архитектурный стиль, как микросервисная архитектура.
-
Обзор Air Display Для Ipad
19 Oct, 24 -
В Питере Прошла Большая Встреча Новаторов-)
19 Oct, 24 -
Комикс Xkcd На 13 Гигапикселей
19 Oct, 24 -
Интернет-Магазины
19 Oct, 24 -
Использование Opencv В Delphi
19 Oct, 24
