[Анализ и проектирование систем, Высокая производительность, Промышленное программирование, Распределённые системы] Выбор архитектурного стиля. Часть 4

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

news_bot ^® написал(а)
12-Окт-2020 18:31

Цитировать

В конце октября запускаем новую группу курса «Архитектура и шаблоны проектирования» и приглашаем всех специалистов на бесплатный Demo-урок «Шаблон адаптер», который проведёт Матвей Калинин — главный разработчик в одном из крупнейших банков страны.

Введение
Выбор архитектурного стиля является одним из основополагающих технических решений при построении информационной системы. В этой серии статей я предлагаю разобрать самые популярные архитектурные стили построения приложений и ответить на вопрос когда какой архитектурный стиль является наиболее предпочтительным. В процессе изложения я постараюсь провести логическую цепочку, которая объясняет развитие архитектурных стилей от монолитов до микросервисов.
В прошлый раз мы сформулировали понятие микросервиса и определили основные положения, отличающие микросервисную архитектуру от сервис-ориентированной.
Напомню: микросервисная архитектура — это подход к разработке отдельного приложения в виде набора небольших сервисов, каждый из которых работает в своем собственном процессе и взаимодействует посредством облегченных механизмов, часто API-интерфейсом HTTP-ресурсов. Эти сервисы построены на бизнес-возможностях и могут быть развернуты независимо с помощью полностью автоматизированного механизма развертывания. Существует минимальный уровень централизованного управления этими сервисами, которые могут быть написаны на разных языках программирования и использовать разные технологии хранения данных.
Проблема выбора
На самом деле, микросервисная архитектура не является серебрянной пулей: она решает вполне конкретные задачи и влечет большое количество проблем, которые возникают наравне с преимуществами этого архитектурного стиля.
Независимое развертывание
С одной стороны, в микросервисной архитектуре нет нужды координировать поставку и развертывание разного функционала. Таким образом обеспечивается быстрй запуск, а сбой при развертывании не приводит к отказу системы. Каждая служба может быть развернута в том количестве, которое действительно необходимо, а специализация сервисов позволяет предоставлять им только необходимые ресурсы.
С другой стороны, в связи с большим количеством разнородных компонент, процесс развертывания в целом становится достаточно сложным и требует автоматизации. Кроме того усложняются процессы тестирования и сопровождения. Переход от гигантских мэйнфреймов к множеству слабых машин приводит к сетевым проблемам, а соединение по сети медленно и ненадежно.
Улучшение отказоустойчивости
Возможность независимого масштабирования и развертывания позволяет повышать избыточность отдельного сервиса и при необходимости перезапускать его без остановки всей системы.
Но при этом необходимо учитывать то, что каждый сетевой вызов может закончится неудачей любая служба, с которой вы взаимодействуете, может перестать отвечать. Кроме этого распределение данных в сети делает проблемой обеспечение согласованности данных.
Гибкость и ясность
Жесткие физические границы сервиса обеспечивают низкую связанность, хорошо управляемые части, их независимую разработку. Разработчики хорошо понимают свою часть системы.
Но, независимость разработчиков приводит к эффекту колодца, когда никто не видит картины целиком.
Варьирование технологического стека
Каждый сервис может использовать наиболее подходящие под его условия технологии и стили. Ошибочное архитектурное решение не фатально, так как может быть исправлено в кратчайшие сроки.
Но, наличие множества подходов и технологий делает сервисы плохо отчуждаемыми. Кроме того, каждая новая технология эта новая возможность выстрелить себе в ногу.
Техническая сложность
Исходя из всего вышесказанного можно сделать вывод, что разработка микросервисов является достаточно сложной технической задачей, требующей особых навыков разработчиков, технических специалистов (DevOps) и тестировщиков. А так же, что самое главное, определенной организационной перестройки и смены парадигмы мышления у отдельных индивидуумов.
Распространенные заблуждения
С микросервисной архитектурой связан ряд заблуждений. Вот некоторые из них:

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

Заключение
На этой радостной ноте предлагаю закончить. В следующий раз поговорим о том, когда стоит применять такой архитектурный стиль как микросервисная архитектура.

оригинал
===========
Источник:
habr.com
===========
Похожие новости:

Теги для поиска: #_analiz_i_proektirovanie_sistem (Анализ и проектирование систем), #_vysokaja_proizvoditelnost (Высокая производительность), #_promyshlennoe_programmirovanie (Промышленное программирование), #_raspredelennye_sistemy (Распределённые системы), #_monolit (монолит), #_stil (стиль), #_mikroservisy (микросервисы), #_soa, #_servicebased, #_arhitektura (архитектура), #_highload, #_raspredelennye (распределенные), #_masshtabiruemost (масштабируемость), #_svjazannost (связанность), #_nadezhnost (надежность), #_otkazoustojchivost (отказоустойчивость), #_kosnost (косность), #_service, #_oriented, #_architecture, #_blog_kompanii_otus._onlajnobrazovanie (
Блог компании OTUS. Онлайн-образование
), #_analiz_i_proektirovanie_sistem (
Анализ и проектирование систем
), #_vysokaja_proizvoditelnost (
Высокая производительность
), #_promyshlennoe_programmirovanie (
Промышленное программирование
), #_raspredelennye_sistemy (
Распределённые системы
)

Профиль ЛС

Ответить на тему

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 23-Ноя 01:00
Часовой пояс: UTC + 5