[Анализ и проектирование систем, Высокая производительность, Промышленное программирование, Распределённые системы] Выбор архитектурного стиля (часть 2)
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Привет, хабр. Сегодня я продолжаю серию публикаций, которую написал специально к старту нового потока курса «Software Architect».
Введение
Выбор архитектурного стиля является одним из основополагающих технических решений при построении информационной системы. В этой серии статей я предлагаю разобрать самые популярные архитектурные стили построения приложений и ответить на вопрос когда какой архитектурный стиль является наиболее предпочтительным. В процессе изложения я постараюсь провести логическую цепочку, которая объясняет развитие архитектурных стилей от монолитов до микросервисов.
В прошлый раз мы разобрались с монолитом и пришли к тому, что монолит имеет ряд проблем: размер, связанность, развертывание, масштабируемость, надежность и косность.
В этот раз я предлагаю поговорить о возможностях организации системы в виде набора модулей/библиотек (компонентно-ориентированная архитектура) или сервисов (сервис-ориентированная архитектура).
Компонентно-ориентированная архитектура
Компонентно-ориентированная архитектура предполагает выполнение системы в виде набора компонентов, которые можно использовать как в текущем, так и в будущих проектах. При разбиении системы на компоненты учитываются: пригодность их для повторного использования, их замещаемость, независимость от контекста, расширяемость, инкапсуляцию и независимость.
При грамотном использовании компонентов решается проблема «большого кома грязи» (большой размер + высокая связанность), а сами компоненты могут представлять из себя как единицы сборки (модули, библиотеки), так и единицы развертывания (сервисы). Единицы развертывания не всегда отображаются на выполняемый процесс: например, веб-приложение и база данных развертываются совместно.
Наиболее часто монолиты разрабатываются в виде набора модулей. Такой подход приводит к обеспечению независимости разработки, но при этом проблемы независимых масштабирования и развертывания, отказоустойчивости и независимости от общего технологического стека остаются. Именно поэтому модуль — частично независимая компонента.
Самая главная проблема такого монолита заключается в том, что разделение на модули является чисто логическим и может быть легко нарушено разработчиками. Может появиться модуль core, который постепенно превращается в помойку, может расти граф зависимостей между модулями и так далее. Для избежания таких проблем разработка должна вестить либо очень зрелой командой, либо под руководством «архитектора», который на full time занимается code review и бьет нарушающих логическую структуру разработчиков по рукам.
«Идеальный» монолит представляет из себя набор логически разделенных модулей, каждый из которых смотрит в свою базу данных.
Сервис-ориентированная архитектура
Если все-таки предполагается организация системы в виде набора сервисов, то речь идет о сервис-ориентированной архитектуре. Ее принципы: сочетаемость приложений, ориентированных на пользователей, многократное использование бизнес-сервисов, независимость от набора технологий и автономность (независимые эволюция, масштабируемость и развертываемость).
Сервис-ориентированная архитектура (SOA = service oriented architecture) решает все обозначенные проблемы монолита: при изменении затрагивается только одна служба, а четко определенный API поддерживает хорошую инкапсуляцию компонент.
Но не все так гладко: SOA приводит к возникновению новых проблем. Удаленные вызовы дороже локальных, а перераспределение обязанностей между компонентами стало существенно дороже.
Кстати говоря, возможность независимого развертывания — это очень важная особенность сервиса. Если сервисы должны развертываться совместно или, тем более, в определенной последовательности, то система не может считаться сервис-ориентированной. В таком случае говорят о распределенном монолите (считается антипаттерном не только с точки зрения SOA, но и микросервисной архитектуры).
Сервис-ориентированная архитектура неплохо поддерживается архитектурным коммьюнити и вендорами. Отсюда следует наличие множества курсов и сертификаций, хорошо проработанных паттернов. К последним относится, например, не безызвестная сервисная шина предприятия (ESB = enterprise service bus). При этом ESB — это багаж от вендоров, она не обязательно должна использоваться в SOA.
Пик популярности сервис-ориентированной архитектуры приходился примерно на 2008 год, после чего она пошла на спад, который стал существенно более резким после появления микросервисов (~2015 год).
Заключение
После того, как мы обсудили возможности организации информационных систем в виде сервисов и модулей, я предлагаю наконец-то перейти к принципам микросервисной архитектуры и уделить особое внимание отличию микросервисной архитектуры от сервис-ориентированной в следующей части.
оригинал
===========
Источник:
habr.com
===========
Похожие новости:
- [FPGA, Высокая производительность, Искусственный интеллект, Конференции, Программирование микроконтроллеров] Бывший вице-президент Sun, MIPS и DEC прокомметировал покупку компании ARM компанией NVidia
- [Java, Open source, Анализ и проектирование систем, Программирование] Добавляем ORM в проект за четыре шага
- [Python, Тестирование веб-сервисов] Как читать файлы конфигурации в тестах с Selenium на Python (перевод)
- [Удалённая работа, Разработка под e-commerce, Микросервисы, Тестирование веб-сервисов] Что помогло нам быстро перестроиться на онлайн-торговлю в новых условиях
- [Cisco, Сетевые технологии] VxLAN фабрика. Часть 3
- [Google Cloud Platform, Администрирование баз данных] Как загрузить данные в Google BigQuery (перевод)
- [Высокая производительность, Программирование, Проектирование и рефакторинг] Почему так важна иммутабельность (перевод)
- [Разработка под Android] Антипаттерн “Репозиторий” в Android (перевод)
- [Java, Scala, Анализ и проектирование систем, Высокая производительность] Как построить надежное приложение на базе Event sourcing?
- [Системы обмена сообщениями, Python, Программирование, Анализ и проектирование систем] Система отложенного исполнения на RabbitMQ
Теги для поиска: #_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 (
Распределённые системы
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 25-Ноя 07:40
Часовой пояс: UTC + 5
Автор | Сообщение |
---|---|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
Привет, хабр. Сегодня я продолжаю серию публикаций, которую написал специально к старту нового потока курса «Software Architect». Введение Выбор архитектурного стиля является одним из основополагающих технических решений при построении информационной системы. В этой серии статей я предлагаю разобрать самые популярные архитектурные стили построения приложений и ответить на вопрос когда какой архитектурный стиль является наиболее предпочтительным. В процессе изложения я постараюсь провести логическую цепочку, которая объясняет развитие архитектурных стилей от монолитов до микросервисов. В прошлый раз мы разобрались с монолитом и пришли к тому, что монолит имеет ряд проблем: размер, связанность, развертывание, масштабируемость, надежность и косность. В этот раз я предлагаю поговорить о возможностях организации системы в виде набора модулей/библиотек (компонентно-ориентированная архитектура) или сервисов (сервис-ориентированная архитектура). Компонентно-ориентированная архитектура Компонентно-ориентированная архитектура предполагает выполнение системы в виде набора компонентов, которые можно использовать как в текущем, так и в будущих проектах. При разбиении системы на компоненты учитываются: пригодность их для повторного использования, их замещаемость, независимость от контекста, расширяемость, инкапсуляцию и независимость. При грамотном использовании компонентов решается проблема «большого кома грязи» (большой размер + высокая связанность), а сами компоненты могут представлять из себя как единицы сборки (модули, библиотеки), так и единицы развертывания (сервисы). Единицы развертывания не всегда отображаются на выполняемый процесс: например, веб-приложение и база данных развертываются совместно. Наиболее часто монолиты разрабатываются в виде набора модулей. Такой подход приводит к обеспечению независимости разработки, но при этом проблемы независимых масштабирования и развертывания, отказоустойчивости и независимости от общего технологического стека остаются. Именно поэтому модуль — частично независимая компонента. Самая главная проблема такого монолита заключается в том, что разделение на модули является чисто логическим и может быть легко нарушено разработчиками. Может появиться модуль core, который постепенно превращается в помойку, может расти граф зависимостей между модулями и так далее. Для избежания таких проблем разработка должна вестить либо очень зрелой командой, либо под руководством «архитектора», который на full time занимается code review и бьет нарушающих логическую структуру разработчиков по рукам. «Идеальный» монолит представляет из себя набор логически разделенных модулей, каждый из которых смотрит в свою базу данных. Сервис-ориентированная архитектура Если все-таки предполагается организация системы в виде набора сервисов, то речь идет о сервис-ориентированной архитектуре. Ее принципы: сочетаемость приложений, ориентированных на пользователей, многократное использование бизнес-сервисов, независимость от набора технологий и автономность (независимые эволюция, масштабируемость и развертываемость). Сервис-ориентированная архитектура (SOA = service oriented architecture) решает все обозначенные проблемы монолита: при изменении затрагивается только одна служба, а четко определенный API поддерживает хорошую инкапсуляцию компонент. Но не все так гладко: SOA приводит к возникновению новых проблем. Удаленные вызовы дороже локальных, а перераспределение обязанностей между компонентами стало существенно дороже. Кстати говоря, возможность независимого развертывания — это очень важная особенность сервиса. Если сервисы должны развертываться совместно или, тем более, в определенной последовательности, то система не может считаться сервис-ориентированной. В таком случае говорят о распределенном монолите (считается антипаттерном не только с точки зрения SOA, но и микросервисной архитектуры). Сервис-ориентированная архитектура неплохо поддерживается архитектурным коммьюнити и вендорами. Отсюда следует наличие множества курсов и сертификаций, хорошо проработанных паттернов. К последним относится, например, не безызвестная сервисная шина предприятия (ESB = enterprise service bus). При этом ESB — это багаж от вендоров, она не обязательно должна использоваться в SOA. Пик популярности сервис-ориентированной архитектуры приходился примерно на 2008 год, после чего она пошла на спад, который стал существенно более резким после появления микросервисов (~2015 год). Заключение После того, как мы обсудили возможности организации информационных систем в виде сервисов и модулей, я предлагаю наконец-то перейти к принципам микросервисной архитектуры и уделить особое внимание отличию микросервисной архитектуры от сервис-ориентированной в следующей части. оригинал =========== Источник: habr.com =========== Похожие новости:
Блог компании OTUS. Онлайн-образование ), #_analiz_i_proektirovanie_sistem ( Анализ и проектирование систем ), #_vysokaja_proizvoditelnost ( Высокая производительность ), #_promyshlennoe_programmirovanie ( Промышленное программирование ), #_raspredelennye_sistemy ( Распределённые системы ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 25-Ноя 07:40
Часовой пояс: UTC + 5