4.07M

Category:

software

Архитектура информационных систем. Блок 4

2.

Блок 4 – Архитектура
информационных систем

Что такое архитектура
информационных систем?
Архитектуру программного обеспечения часто сравнивают с архитектурой зданий, но это не
совсем верная параллель.
Архитектура ПО подразумевает фокус только на его структуре — из каких компонентов состоит
приложение и как они взаимодействуют между собой.
Разработкой архитектуры программного обеспечения занимается архитектор ПО. Если в команде
нет архитектора, эту роль на себя может взять ведущий разработчик, реже — системный
аналитик.
Архитектуру приложения описывают в виде набора диаграмм и текстовых документов.

4.

Основные слои архитектуры
1
Клиент - предоставляет пользователям интерфейс для взаимодействия с приложением. Через
этот интерфейс он принимает от пользователя команды и показывает ему данные,
предоставленные сервером приложений (веб-приложение, мобильное приложение, десктопприложения)
2
Сервер приложений — принимает команды от клиента и обрабатывает их. Если для ответа на
запрос клиента необходимы данные, сервер приложений обращается к серверу баз данных.
При обмене данными через сеть Интернет функции сервера приложений выполняет вебсервер.
3
Сервер баз данных (или сервер БД) — хранит данные приложения и управляет ими. В
трёхзвенной архитектуре клиент и сервер баз данных не могут взаимодействовать напрямую
— им нужен сервер приложений.

5.

Основные слои архитектуры

6.

Дополнительные слои

7.

Определение компонента
Компонент – это логическая замещаемая часть системы, которая соответствует некоторому
набору интерфейсов и обеспечивает их реализацию.
Компонент – это единица развёртывания, представляющая наименьшую сущность, которую
можно развернуть в составе системы. Например – jar-файлы, dll-файлы, exe-файлы. С точки
зрения разработки, компонент – это отдельный проект/модуль исходного кода системы

8.

Монолитная и микросервисная
архитектура
Микросервисная архитектура — это
способ построения приложения в виде
набора слабо связанных между собой
компонентов («микросервисов»). У
микросервисного приложения может
быть несколько маленьких серверов
приложений и серверов баз данных.
В монолитной архитектуре не
выделяют микросервисы, всё
приложение реализуется цельным
«куском». У монолитного приложения
единый сервер приложений, один
сервер баз данных.

9.

Преимущества монолитов
Проще реализовать в жизнь (по сравнению с SOA и микросервисами);
Легко развёртывать;
Высокая производительность;
Простота сквозного тестирования функциональности.

10.

Недостатки монолитов
― Большая кодовая база – пугает разработчиков, трудно понимаема и в ней постепенно
стираются границы между компонентами (если они были);
― Ограничена по горизонтальному масштабированию ;
― Новые функции или изменения существующих затрагивают всю систему;
― Ограниченность технологическим стеком;
― Возникающие сложности при росте команды разработчиков.

11.

Микросервисная
архитектура
Микросервисную архитектуру отличают два основных принципа — слабая связанность и единая
ответственность.
Принцип слабой связанности (Low сoupling) подразумевает, что один микросервис не должен
зависеть от реализации другого. Микросервис предоставляет другим микросервисам API. Если API
остаётся неизменным, реализовывать микросервис можно как угодно, например, написав его на
другом языке программирования.
Принцип единой ответственности (Single-responsibility principle) подразумевает, что микросервис
решает только одну задачу — и в полном объёме. Если микросервис отвечает за рассылку
уведомлений пользователям приложения, он должен решать эту задачу «от и до» — в
приложении не должно быть аналогичной функциональности. В то же время в микросервисе не
должно быть функциональности, которая никак не связана с рассылкой уведомлений.

12.

Микросервисная архитектура.
Диаграмма компонентов

13.

Преимущества микросервисов
Высокая отказоустойчивость и надежность;
Гибкость к изменениям технологического стека;
Сервисы могут развёртываться независимо и на разных сетевых узлах;
Сервисы можно повторно использовать, не дублируя функциональность в других сервисах;
Быстрое подключение новых разработчиков в работу;
Новые бизнес-функции появляются как новые сервисы и не затрагивают существующие.

14.

Недостатки микросервисов
― Сложность развёртывания;
― Сложность сквозного тестирования функциональности;
― Дублирование данных в хранилищах ;
― Проблемы с обеспечением безопасности доступа к сервисам;
― Зоопарк «технологий»;
― Уменьшение производительности при большом количестве межсервисного обмена.

15.

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

16.

Особенности работы системного аналитика
при разработке в микросервисной архитектуре
Одна из типовых задач нашего времени — «переход от монолита к микросервисам». Она
возникает в том случае, когда организация долгое время развивала приложение в
монолитной архитектуре. Приложение усложнилось, и для решения этой проблемы
организация меняет его монолитную архитектуру на микросервисную.
Это сложная задача — разом перевести большое приложение на микросервисную
архитектуру невозможно. Перевод происходит поэтапно: из приложения один за другим
выделяют микросервисы. При этом важно не нарушать работу приложения — оно всё
время должно быть доступно для пользователей.

17.

Особенности работы системного аналитика
при разработке в микросервисной архитектуре
Особенности работы системного аналитика при микросервисной архитектуре приложения:
Работа становится «двухслойной» — нужно проектировать как всё приложение в целом (из
каких микросервисов оно состоит и как они взаимодействуют между собой для решения
задач пользователя), так и каждый отдельный микросервис (как он устроен и что делает).
Увеличивается количество задач по проектированию API и порядку взаимодействия
микросервисов между собой и со сторонними приложениями.
Необходимо глубже погружаться в архитектуру приложения — из каких микросервисов оно
состоит и как они взаимодействуют между собой.
Нужно больше думать об ошибках и нештатных ситуациях. Если в монолитных приложениях
есть стандартные решения для их обработки, то в микросервисных — вариантов решения
много.

18.

SOA архитектура
Сервис-ориентированная архитектура (SOA) – это архитектурный подход к созданию
программных систем, основанный на использовании сервисов. Они представляют собой
независимые компоненты.
Взаимодействие между сервисами осуществляется через корпоративную шину данных (ESB) по
унифицированному протоколу обмена (например, SOAP). Сервисы публикуют свои интерфейсы
на шине.
Сервисы ничего не знают друг о друге, но знают
об интерфейсах и методах, которые
предоставляет ESB.
На ESB также публикуются различные служебные
сервисы, обеспечивающие журналирование,
авторизацию, мониторинг и т.д.
Подход ESB предполагает единое хранилище
данных.

19.

Преимущества ESB
Сервисы разделены физически и могут разрабатываться разными командами без
вмешательства друг в друга;
Сервисы могут развёртываться независимо и на разных сетевых узлах;
Сервисы можно повторно использовать, не дублируя функциональность в других сервисах;
Протоколы обмена унифицированы;
Для интеграции всех сервисов с новым приложением/сервисом достаточно интегрировать
это приложение с ESB.

20.

Недостатки ESB
― Трудность реализации ESB и управления большим количеством сервисов;
― ESB становится «бутылочным горлышком» ;
― Множество ESB являются проприетарными (самописные, программное обеспечение,
которое находится в собственности у его авторов или правообладателей) и для
разработки под них нужно развивать специализированные компетенции.

21.

Сравнение монолита, SOA
и микросервисной архитектуры

22.

Хорошая архитектура
Масштабируемость (Scalability) – возможность расширять систему и увеличивать ее
производительность, за счет добавления новых компонентов.
Ремонтопригодность (Maintainability) – изменение одного компонента не требует
изменения других компонентов.
Заменимость модулей (Swappability) – компонент легко заменить на другой.
Возможность тестирования (Unit Testing) – компонент можно отсоединить от всех остальных
и протестировать / починить.
Переиспользование (Reusability) – компонент может быть переиспользован в других
программах и другом окружении.
Сопровождаемость (Maintenance) – разбитую на компоненты программу легче понимать и
сопровождать.

23.

Плохая архитектура
― Жесткость (Rigidity) – систему тяжело изменить, поскольку любое изменение влияет на
слишком большое количество других частей системы.
― Хрупкость (Fragility) – при внесении изменений неожиданно ломаются другие части
системы.
― Неподвижность (Immobility) – «Этот код проще переписать с нуля». Общую
функциональность тяжело использовать повторно в другом приложении, поскольку её
слишком тяжело «выпутать» из текущего приложения.

24.

ДИАГРАММА С4

25.

С4
Это метод визуализации архитектуры программного обеспечения,
разработанный Саймоном Брауном. Она используется для создания
диаграмм, описывающих архитектуру систем.
КАК РАСШИФРОВЫВАЕТСЯ:
Context - Контекст
Containers - Контейнеры
Components - Компоненты
Code - Код

26.

С4. УРОВЕНЬ КОНТЕКСТА
Показывает, как система взаимодействует с внешними сущностями
(пользователями, внешними системами). Сразу видно интеграции
Элементы:
системы
пользователи
взаимосвязи

27.

С4. УРОВЕНЬ КОНТЕЙНЕРОВ
Описывает верхнеуровневую архитектуру и технологии. Используется для
понимания технологического стека и разделения зон ответственности.
Элементы:
контейнеры (например, вебприложения, базы данных)
взаимосвязи
технологии

28.

С4. УРОВЕНЬ КОМПОНЕНТОВ
Детализирует структуру внутри контейнера системы, т.е. описывает более детально только один
контейнер из предыдущего уровня. Используется для проектирования и документирования
внутренней структуры компонентов системы.
Элементы:
компоненты
взаимосвязи
технологии
зависимости

Архитектура информационных систем. Блок 4

1.

2.

3.

4.

5.

6.

7.

8.

9.

10.

11.

12.

13.

14.

15.

16.

17.

18.

19.

20.

21.

22.

23.

24.

25.

26.

27.

28.

29.

30.

31.