[Высокая производительность, Анализ и проектирование систем, Промышленное программирование, Распределённые системы] Выбор архитектурного стиля (часть 3)
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Привет, Хабр. Сегодня я продолжаю серию публикаций, которую написал специально к старту нового потока курса «Software Architect».
Введение
Выбор архитектурного стиля является одним из основополагающих технических решений при построении информационной системы. В этой серии статей я предлагаю разобрать самые популярные архитектурные стили построения приложений и ответить на вопрос когда какой архитектурный стиль является наиболее предпочтительным. В процессе изложения я постараюсь провести логическую цепочку, которая объясняет развитие архитектурных стилей от монолитов до микросервисов.
В прошлый раз мы поговорили о различных видах монолитов и об использовании компонентов для их построения, причем как компонентов сборки, так и компонентов развертывания. Мы разобрались с сервис-ориентированной архитектурой.
Сейчас мы наконец определим основные характеристики микросервисной архитектуры.
Отношение архитектур
Необходимо понимать, что исходя из данных в предыдущих статьях определений любой сервис является компонентом, но не любой сервис является микросервисом.
Характеристики микросервисной архитектуры
Основными характеристиками микросервисной архитектуры являются:
• Организация в соответствии с бизнес-возможностями
(Organized around Business Capabilities)
• Продукты, а не проекты (Products not Projects)
• Умные точки входа и глупые каналы (Smart endpoints and
dumb pipes)
• Децентрализованное управление (Decentralized Governance)
• Децентрализованное управление данными (Decentralized
Data Management)
• Автоматизация инфраструктуры (Infrastructure Automation)
• Страховка от сбоев (Design for failure)
• Архитектура с эволюционным развитием (Evolutionary
Design)
1-ый пункт приходит от сервис-ориентированной архитектуры, потому что микросервисы являются частным случаем сервисов. Другие пункты заслуживают отдельного рассмотрения.
Организация в соответствии с бизнес-возможностями (Organized around Business Capabilities)
Сейчас необходимо вспомнить закон Конвея: организации, создающие системы, организуют ее архитектуру, копирующую структуру взаимодействия внутри этих организаций. В качестве примера можно вспомнить случай создания компилятора: команда из семи человек разработала семипроходный компилятор, а команда из пяти — пятипроходный.
Если мы говорим про монолиты и микросервисы, то в том случае, если разработка организована по функциональным отделам (бэкенд, фронтенд, администраторы баз данных), то получается классический монолит.
Для получения микросервисов команды необходимо организовывать по бизнес-возможностям (команда заказов, отгрузок, каталога). Такая организация даст возможность командам сосредоточиться на создании конкретных частей приложения.
Продукты, а не проекты (Products not Projects)
Проектный подход при котором команда передает разработанную функциональность другим командам в случае микросервисной архитектуры совершенно не подходит. Команда должна поддерживать систему на протяжении всего ее жизненного цикла. Компания Amazon, один из флагманов внедрения микросервисов, заявляла: «вы создаете продукт, и вы же запускаете его» («you build, you run it»). Продуктовый подход позволяет команде почувствовать потребности бизнеса.
Умные точки входа и глупые каналы (Smart endpoints and dumb pipes)
SOA архитектура большое внимание уделяла каналам связи, в частности Enterprise Service Bus (сервисная шина предприятия). Что зачастую приводит к Erroneous Spaghetti Box, то есть сложность монолита переходит в сложность связей между сервисами. В микросевисной архитектуре используются только простые способы взаимодействия.
Децентрализованное управление (Decentralized Governance)
Ключевые решения по микросервисам должны принимать люди, которые действительно разрабатывают микросервисы. Здесь под ключевыми решениями подразумевается выбор
языков программирования, методологии развёртывания, контрактов публичных интерфейсов и т. д.
Децентрализованное управление данными (Decentralized Data Management)
Стандартный подход, в котором приложение опирается на одну базу данных, не может учитывать специфики каждого конкретного сервиса. MSA предполагает децентрализованное управление данными, вплоть до применения различных технологий.
Автоматизация инфраструктуры (Infrastructure Automation)
MSA поддерживает процессы непрерывного развертывания и поставки. Осуществить это возможно только путем автоматизации процессов. При этом, развертывание большого количества сервисов уже не выглядит чем-то страшным. Процесс развертывания должен стать скучным. Второй аспект связан с управлением сервисами в продуктовой среде. Без автоматизации, управление процессами, запущенными в разных операционных средах, становится невозможным.
Страховка от сбоев (Design for failure)
Многочисленные сервисы MSA подвержены сбоям. При этом, обработка ошибок в распределенной системе — весьма не тривиальная задача. Архитектура приложений должна быть устойчива к таким сбоям. Ребекка Парсонс считает очень важным, что мы больше не используем даже внутрипроцессное взаимодействие между сервисами, вместо этого для связи мы прибегаем к HTTP, который и близко не бывает столь же надёжен.
Архитектура с эволюционным развитием (Evolutionary Design)
Архитектура MSA системы должна развиваться эволюционно. Желательно ограничить необходимые изменения границами одного сервиса. Необходимо так же учитывать влияние на другие сервисы. Традиционный подход состоит в том, чтобы попытаться решить эту проблему с помощью управления версиями, но MSA предполагает использовать управление версиями в
качестве крайней меры.
Заключение
После всего вышесказанного можно сформулировать что такое микросервисы. Микросервисная архитектура — это подход к разработке отдельного приложения в виде набора небольших сервисов, каждый из которых работает в своем собственном процессе и взаимодействует посредством облегченных механизмов, часто API-интерфейсом HTTP-ресурсов. Эти сервисы построены на бизнес-возможностях и могут быть развернуты независимо с помощью полностью
автоматизированного механизма развертывания. Существует минимальный уровень централизованного управления этими сервисами, которые могут быть написаны на разных языках программирования и использовать разные технологии хранения данных.
оригинал
Читать часть 2
===========
Источник:
habr.com
===========
Похожие новости:
- [Agile, Тестирование IT-систем, Тестирование веб-сервисов, Тестирование мобильных приложений] 7 способов повысить эффективность автоматизации тестирования в Agile разработке (перевод)
- [Google Chrome, JavaScript, Софт] Используем Chrome DevTools профессионально (перевод)
- [API, Анализ и проектирование систем] Контрольный список для ревью кода в распределенных системах (перевод)
- [JavaScript, Программирование] Compose повсюду: композиция функций в JavaScript (перевод)
- [Laravel, Программирование] Новинки Laravel 8
- [Java, Программирование] Знакомимся с Event Sourcing. Часть 2 (перевод)
- [C++, Программирование] Полиморфные аллокаторы c++17
- [Программирование, Тестирование веб-сервисов] Враг не пройдёт, или как помочь командам соблюдать стандарты разработки
- [MongoDB, NoSQL, Администрирование баз данных] 14 вещей, которые я хотел бы знать перед началом работы с MongoDB (перевод)
- [PostgreSQL, SQL, Администрирование баз данных, Высокая производительность] PostgreSQL 13: happy pagination WITH TIES
Теги для поиска: #_vysokaja_proizvoditelnost (Высокая производительность), #_analiz_i_proektirovanie_sistem (Анализ и проектирование систем), #_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. Онлайн-образование
), #_vysokaja_proizvoditelnost (
Высокая производительность
), #_analiz_i_proektirovanie_sistem (
Анализ и проектирование систем
), #_promyshlennoe_programmirovanie (
Промышленное программирование
), #_raspredelennye_sistemy (
Распределённые системы
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 23-Ноя 00:12
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Привет, Хабр. Сегодня я продолжаю серию публикаций, которую написал специально к старту нового потока курса «Software Architect». Введение Выбор архитектурного стиля является одним из основополагающих технических решений при построении информационной системы. В этой серии статей я предлагаю разобрать самые популярные архитектурные стили построения приложений и ответить на вопрос когда какой архитектурный стиль является наиболее предпочтительным. В процессе изложения я постараюсь провести логическую цепочку, которая объясняет развитие архитектурных стилей от монолитов до микросервисов. В прошлый раз мы поговорили о различных видах монолитов и об использовании компонентов для их построения, причем как компонентов сборки, так и компонентов развертывания. Мы разобрались с сервис-ориентированной архитектурой. Сейчас мы наконец определим основные характеристики микросервисной архитектуры. Отношение архитектур Необходимо понимать, что исходя из данных в предыдущих статьях определений любой сервис является компонентом, но не любой сервис является микросервисом. Характеристики микросервисной архитектуры Основными характеристиками микросервисной архитектуры являются: • Организация в соответствии с бизнес-возможностями (Organized around Business Capabilities) • Продукты, а не проекты (Products not Projects) • Умные точки входа и глупые каналы (Smart endpoints and dumb pipes) • Децентрализованное управление (Decentralized Governance) • Децентрализованное управление данными (Decentralized Data Management) • Автоматизация инфраструктуры (Infrastructure Automation) • Страховка от сбоев (Design for failure) • Архитектура с эволюционным развитием (Evolutionary Design) 1-ый пункт приходит от сервис-ориентированной архитектуры, потому что микросервисы являются частным случаем сервисов. Другие пункты заслуживают отдельного рассмотрения. Организация в соответствии с бизнес-возможностями (Organized around Business Capabilities) Сейчас необходимо вспомнить закон Конвея: организации, создающие системы, организуют ее архитектуру, копирующую структуру взаимодействия внутри этих организаций. В качестве примера можно вспомнить случай создания компилятора: команда из семи человек разработала семипроходный компилятор, а команда из пяти — пятипроходный. Если мы говорим про монолиты и микросервисы, то в том случае, если разработка организована по функциональным отделам (бэкенд, фронтенд, администраторы баз данных), то получается классический монолит. Для получения микросервисов команды необходимо организовывать по бизнес-возможностям (команда заказов, отгрузок, каталога). Такая организация даст возможность командам сосредоточиться на создании конкретных частей приложения. Продукты, а не проекты (Products not Projects) Проектный подход при котором команда передает разработанную функциональность другим командам в случае микросервисной архитектуры совершенно не подходит. Команда должна поддерживать систему на протяжении всего ее жизненного цикла. Компания Amazon, один из флагманов внедрения микросервисов, заявляла: «вы создаете продукт, и вы же запускаете его» («you build, you run it»). Продуктовый подход позволяет команде почувствовать потребности бизнеса. Умные точки входа и глупые каналы (Smart endpoints and dumb pipes) SOA архитектура большое внимание уделяла каналам связи, в частности Enterprise Service Bus (сервисная шина предприятия). Что зачастую приводит к Erroneous Spaghetti Box, то есть сложность монолита переходит в сложность связей между сервисами. В микросевисной архитектуре используются только простые способы взаимодействия. Децентрализованное управление (Decentralized Governance) Ключевые решения по микросервисам должны принимать люди, которые действительно разрабатывают микросервисы. Здесь под ключевыми решениями подразумевается выбор языков программирования, методологии развёртывания, контрактов публичных интерфейсов и т. д. Децентрализованное управление данными (Decentralized Data Management) Стандартный подход, в котором приложение опирается на одну базу данных, не может учитывать специфики каждого конкретного сервиса. MSA предполагает децентрализованное управление данными, вплоть до применения различных технологий. Автоматизация инфраструктуры (Infrastructure Automation) MSA поддерживает процессы непрерывного развертывания и поставки. Осуществить это возможно только путем автоматизации процессов. При этом, развертывание большого количества сервисов уже не выглядит чем-то страшным. Процесс развертывания должен стать скучным. Второй аспект связан с управлением сервисами в продуктовой среде. Без автоматизации, управление процессами, запущенными в разных операционных средах, становится невозможным. Страховка от сбоев (Design for failure) Многочисленные сервисы MSA подвержены сбоям. При этом, обработка ошибок в распределенной системе — весьма не тривиальная задача. Архитектура приложений должна быть устойчива к таким сбоям. Ребекка Парсонс считает очень важным, что мы больше не используем даже внутрипроцессное взаимодействие между сервисами, вместо этого для связи мы прибегаем к HTTP, который и близко не бывает столь же надёжен. Архитектура с эволюционным развитием (Evolutionary Design) Архитектура MSA системы должна развиваться эволюционно. Желательно ограничить необходимые изменения границами одного сервиса. Необходимо так же учитывать влияние на другие сервисы. Традиционный подход состоит в том, чтобы попытаться решить эту проблему с помощью управления версиями, но MSA предполагает использовать управление версиями в качестве крайней меры. Заключение После всего вышесказанного можно сформулировать что такое микросервисы. Микросервисная архитектура — это подход к разработке отдельного приложения в виде набора небольших сервисов, каждый из которых работает в своем собственном процессе и взаимодействует посредством облегченных механизмов, часто API-интерфейсом HTTP-ресурсов. Эти сервисы построены на бизнес-возможностях и могут быть развернуты независимо с помощью полностью автоматизированного механизма развертывания. Существует минимальный уровень централизованного управления этими сервисами, которые могут быть написаны на разных языках программирования и использовать разные технологии хранения данных.  оригинал Читать часть 2 =========== Источник: habr.com =========== Похожие новости:
Блог компании OTUS. Онлайн-образование ), #_vysokaja_proizvoditelnost ( Высокая производительность ), #_analiz_i_proektirovanie_sistem ( Анализ и проектирование систем ), #_promyshlennoe_programmirovanie ( Промышленное программирование ), #_raspredelennye_sistemy ( Распределённые системы ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 23-Ноя 00:12
Часовой пояс: UTC + 5