Документирование архитектуры программного обеспечения

Архитектура

инфраструктурный уровень

• библиотека stlport, которая содержит набор стандартных контейнеров и алгоритмов и собирается под разные платформы;
• библиотека zlib, которая позволяет сжимать и разжимать данные при помощи алгоритма deflate;
• библиотеки libpng и libjpeg для работы с изображениями растровой графики в форматах png и jpeg;
• библиотека aes для шифрования данных и создания электронных подписей;
• библиотека expat xml parser для чтения и разбора xml-файлов.

Уровень модели данных

• база данных;
• слой доступа к данным.

• карты в исходном (текстовом) формате;
• компилятор для преобразования карт из текстового формата в промежуточный бинарный;
• пять специализированных компиляторов, которые формируют специализированные базы данных:
  • базу данных для рисования карт;
  • базу данных для построения маршрута;
  • базу данных для поиска координат по адресу;
  • базу данных почтовых индексов;
  • базу данных точек интереса;
• слой доступа к данным, которые обеспечивает доступ к данным из специализированных баз данных.

уровень сервисов

1. Растеризатор карты. Формирует двумерное или трехмерное представление карты в заданной области.
2. Модуль роутинга. Отвечает за прокладку маршрута из текущего местоположения в заданную точку.
3. Модуль поиска адреса. Отвечает за поиск координат по адресу.
4. Модуль поиска по индекса. Отвечает за поиск координат по почтовому индексу.
5. Модуль поиска точек интереса. Отвечает за нахождение точек интереса в пределах заданной области.
6. Навигатор. Отвечает за формирование и выдачу навигационных указаний при движении по маршруту.

Уровень редактирования

• работа с профилями пользователей (у навигационной системы могут быть несколько пользователей, и данные каждого пользователя должны сохраняться в отдельном профиле);
• создание и управление списком мест-фаворитов;
• сохранение истории поездок (в простейшем случае — сохранение точек назначения).

Уровень взаимодействия с пользователем

Итоги

1. Архитектура клиентского приложения может быть представлена иерархией из пяти системных уровней:
2. Каждый уровень может содержать один или несколько модулей, или же быть пустым. В последнем случае он остается в пятиуровневой модели только из общесистемных соображений.
3. Количество модулей, расположенных на уровне, зависит от типа приложения. Если разрабатывается приложение, предназначенное для редактирования различных документов, то будут насыщенными уровни редактирования и взаимодействия с пользователем. Если же создается приложение, нацеленное на оказание услуг пользователю, то будет насыщенным уровень сервисов в то время, как уровень редактирования будет небольшим.
4. Сложность модели данных зависит от объема данных и от требований по производительности. В ряде случаев модель данных можно реализовать в виде самосериализуемых в XML классов. И этого будет достаточно. В других случаях потребуется создать базы данных со сложными структурами данных, оптимизированные для произвольного доступа. При использовании таких баз данных потребуется разработка программ-компиляторов, которые тоже относятся к модели данных.
5. Если требуется разработать линейку приложений, позволяющих редактировать или отображать однотипные данные (например, графы), то необходимо разделить модель данных на одну обобщенную и несколько специализированных (по числу разрабатываемых приложений). Такое разделение пройдет и через вышестоящие уровни: уровень редактирования и уровень взаимодействия с пользователем.

Литература

1. Document/View Architecture
2. Blueprint Visual Scripting/Unreal Engine 4 Documentation
3. Introduction to Undo Architecture
4. Gregory, Jason. Game Engine Architecture
5. Руководство Microsoft по проектированию архитектуры приложений, 2-е издание
6. Лебедев К.А., Сычев С.В. О потерянном уровне
7. Фаулер, Мартин. Архитектура корпоративных программных приложений. – Пер. с англ. – М.: Издательский дом «Вильямс», 2006. – 544 с.: ил.
8. @cobiot. Охота на мифический MVC. Обзор, возвращение к первоисточниками и про то, как анализировать и выводить шаблоны самому
9. @cobiot. Охота на мифический MVC. Построение пользовательского интерфейса

Автор благодарит своих коллег за помощь при подготовке статьи.

Ориентированное на приложение (Многоуровневая архитектура)

Как только граница домена определена, следующим идет уровень приложения. Прикладной уровень становится надежным благодаря применению нижеприведенных SOLID принципов.

Абстракции (ЧТО?) — Приложение должно быть построено таким образом, чтобы оно могло содержать бизнес-логику с использованием абстракций. Он должен сосредоточиться на том, что(?) он хочет делать.

Сегрегация(КАК?) — это сделано, аспект деталей реализации можно подключить с помощью инъекции зависимостей(DI). DI применяется не только для внедрения бизнес-логики с использованием различных шаблонов проектирования, но и конкретно применяется при внедрении элементов инфраструктуры, таких как базы данных, кэш, серверы уведомлений, внешние веб-службы и т.д.

Интерфейсы/Контракты — Такой подход автоматически создает многоуровневую архитектуру с четкими интерфейсами для каждого внешнего элемента. Разделение ответственности в сочетании с тем, что каждый слой владеет одной-единственной ответственностью, уменьшает сцепление. Это, в свою очередь, помогает легко тестируемому коду, который также может быть протестирован с помощью моков (mocks).

Опять же, уровень приложений не зависит ни от каких других деталей реализации и имеет только знания о доменном уровне, от которого он зависит.

Диаграмма зависимостей классов

Диаграмма зависимостей Layer анализирует зависимости между слоями, но внутри слоя все еще есть зависимости, которые не должны возникать.

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

Например, если мы хотим, чтобы наши события были сериализуемыми, чтобы мы могли поместить их в очередь, мы, вероятно, не хотим, чтобы они содержали сущность, потому что было бы проблематично десериализовать ее и сохранить ее с помощью ORM. Также не имеет смысла, чтобы событие зависело от услуги. С помощью диаграмм этого типа или, точнее, с помощью инструмента для проверки зависимостей, мы можем легко обнаруживать такие случаи и предотвращать их попадание в производство.

API-шлюз

Это обеспечивает единую точку входа для всех сервисов, вместо того чтобы клиент напрямую общался с каждым сервисом. API-шлюз обеспечивает агрегацию, аутентификацию, кэширование и т.д.

API-шлюз помогает достичь следующих факторов.

Безопасность

API-шлюз не предоставляет сервисы внешнему миру напрямую, чтобы обеспечить их безопасность. Все вопросы, связанные с безопасностью, решаются на шлюзе, и только аутентифицированные клиенты получают дальнейший доступ.

Сквозные проблемы

Такие вопросы, как аутентификация, завершение SSL, ограничение скорости, дросселирование запросов, кэширование и другие, которые должны быть реализованы в каждом сервисе, находятся в ведении шлюза.

Агрегатор

Некоторые запросы требуют обращения к нескольким сервисам, что увеличивает время общения клиента с сервисами. Агрегатор может общаться со всеми сервисами и возвращать ответ после агрегации, чтобы сократить обширное общение клиента с сервисами.

Основы построения диаграмм: блок-схемы, C4 и UML 2.5.

Теперь, когда мы закончили говорить о том, какую пользу может принести вам документирование архитектуры программного обеспечения, давайте рассмотрим некоторые распространенные методы, используемые для создания диаграмм.

Блок-схемы

Блок-схемы являются одним из самых основных типов диаграмм, которые вы можете сделать. Их простота делает их эффективным инструментом для визуализации логики алгоритма или программы перед началом кодирования.

Вот пример ключа блок-схемы, содержащего некоторые общие символы, используемые в диаграммах.

Пример ключа блок-схемы

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

• Имя представляемого элемента
• Роль этого элемента в системе
• Технология этого элемента

Каждый компонент диаграммы будет иметь стрелки, соединяющие его с другими компонентами и описывающие взаимодействие между ними.

Модель С4

Модель C4 — это стандарт архитектурной документации для программных систем, который разбивает программную систему на четыре уровня:

• Контекст (уровень 1) : Диаграммы контекста представляют собой высокоуровневые концептуальные описания того, что делает ваша система, какие проблемы она решает, вовлеченных людей и любых внешних систем, которые с ней взаимодействуют. Эти диаграммы помогают составить общую картину.
• Контейнеры (уровень 2). Диаграммы контейнеров идут на один уровень глубже, описывая взаимодействия высокого уровня между приложениями или службами, составляющими вашу систему. Контейнеры могут представлять API, базы данных, файловые системы, микросервисы и т. д.
• Компоненты (уровень 3) : диаграммы компонентов рассматривают различные тела кода внутри контейнера. Эти диаграммы помогают визуализировать абстракции вашей кодовой базы.
• Код (уровень 4). Как следует из названия, диаграммы кода рассматривают архитектурные элементы, сопоставленные с кодом, такие как классы, интерфейсы, объекты и функции.

Как минимум, большинство команд должны создавать и поддерживать контекстные и контейнерные диаграммы для своей программной системы.

Диаграммы компонентов могут быть созданы, если они добавляют ценность, но вы захотите найти способ автоматизировать обновления этих диаграмм для долгосрочных целей документирования.

Большинство IDE (или инструментов моделирования UML) могут генерировать диаграммы кода по запросу, поэтому документацию на этом уровне детализации легче извлекать, чем поддерживать. Если компонент особенно важен или сложен, то иметь под рукой диаграммы уровня 4 может быть полезно, но в большинстве случаев вы можете подождать, пока вам не понадобятся эти диаграммы, чтобы сгенерировать их.

UML 2.5

Унифицированный язык моделирования (UML) чаще всего используется в разработке программного обеспечения для создания диаграмм для документирования архитектурных элементов уровня 4.

Существует 14 типов диаграмм UML, которые можно разделить на две основные категории:

• Структурные диаграммы показывают, какие объекты находятся в моделируемой системе.
• Поведенческие диаграммы показывают, как эти объекты взаимодействуют друг с другом.

Структурные схемы	Поведенческие диаграммы
Диаграммы классов	Диаграммы деятельности
Диаграммы компонентов	Диаграммы связи
Диаграммы развертывания	Диаграммы взаимодействия
Диаграммы объектов	Диаграммы конечного автомата
Схемы пакетов	Диаграммы последовательности
Схемы профилей	Временные диаграммы
Схемы составной структуры	Диаграммы вариантов использования

В этой статье мы сосредоточимся в первую очередь на диаграммах уровней 1 и 2, поэтому не будем вдаваться в подробности.

Однако, если вы хотите создавать диаграммы уровня 4, изучение UML может быть хорошей отправной точкой.

Пример: система выставления счетов

Вы создаете веб-приложение, которое цифровые художники могут использовать для управления и отправки счетов клиентам. Как будет выглядеть контекстная диаграмма для этого?

Как минимум, ваша диаграмма должна включать:

• База данных
• Компонент бизнес-логики
• Интерфейс

Во-первых, начните с представления вашей программной системы.

Затем вы хотите задокументировать, кто такие актеры. Актеры — это все, кто будет использовать программную систему.

В этом сценарии нашими действующими лицами являются:

• Цифровые художники
• Клиенты

Теперь, когда вы знаете, кто ваши действующие лица, задокументируйте любые внешние системы, взаимодействующие с программной системой.

Если вы хотите пойти еще дальше, вы можете создать контейнерную диаграмму. Диаграмма контейнера фокусируется на приложениях, составляющих конкретный контейнер.

Поддержка Docker

Проект работает в .NET. Поэтому его можно запускать как в контейнерах Linux, так и в контейнерах Windows

Обратите внимание на то, что для развертывания Docker необходимо использовать тот же тип узла для SQL Server. Контейнеры на основе Linux требуют меньше ресурсов и более предпочтительны

Вы можете использовать Visual Studio 2017, чтобы добавить поддержку Docker в существующее приложение, щелкнув проект в обозревателе решений правой кнопкой мыши и выбрав Добавить>Поддержка Docker. Таким образом вы добавите необходимые файлы и внесете изменения в проект для их использования. В текущем примере эти файлы уже есть.

Файл на уровне решения содержит сведения о том, какие образы необходимо создать и какие контейнеры запустить. Этот файл позволяет использовать команду для запуска нескольких приложений одновременно. В этом случае он запускает только веб-проект. Вы также можете с его помощью настроить зависимости, например отдельный контейнер базы данных.

Файл ссылается на в проекте . С помощью можно указать, какой базовый контейнер будет использоваться и как приложение будет настроено на нем. :

Устранение неполадок с Docker

После запуска контейнерное приложение продолжает работать, пока его не остановят. Используйте команду , чтобы посмотреть, какие контейнеры выполняются. Вы можете остановить выполняющийся контейнер с помощью команды и идентификатора контейнера.

Обратите внимание, что запущенные контейнеры Docker могут быть привязаны к портам, которые в противном случае вы могли бы использовать в среде разработки. При попытке запустить или выполнить отладку приложения через порт, связанный с контейнером Docker, возникнет ошибка с сообщением о том, что сервер не может выполнить привязку к этому порту

Проблемы будет решена, если вы остановите контейнер.

Если вы хотите добавить поддержку Docker в приложение с помощью Visual Studio, убедитесь, что Docker Desktop при этом запущен. Если при запуске мастера средство Docker Desktop не выполняется, мастер будет работать неправильно. Кроме того, мастер проверяет выбранные контейнеры, чтобы правильно реализовать поддержку Docker. Чтобы добавить поддержку контейнеров Windows, необходимо запускать мастер при запущенном инструменте Docker Desktop с настроенными контейнерами Windows. Чтобы добавить поддержку контейнеров Linux, запускайте мастер при запущенном инструменте Docker с настроенными контейнерами Linux.

Другие стили архитектуры веб-приложений

• Web-Queue-Worker. Основными компонентами этой архитектуры являются внешний веб-интерфейс, который обслуживает клиентские запросы, и рабочая роль, которая выполняет ресурсоемкие задачи, длительные рабочие процессы или пакетные задания. Веб-интерфейс взаимодействует с рабочей ролью через очередь сообщений.
• N-уровень. N-уровневая архитектура разделяет приложение на логические и физические уровни.
• Микрослужба. Архитектура микрослужб состоит из коллекции небольших автономных служб. Каждая служба является самодостаточной и должна реализовывать возможности одной компании в ограниченном контексте.

Ссылки — общие архитектуры веб-приложений

• Чистая архитектураhttps://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html
• Многослойная архитектураhttps://jeffreypalermo.com/blog/the-onion-architecture-part-1/
• Шаблон репозиторияhttps://deviq.com/repository-pattern/
• Шаблон решения с чистой архитектуройhttps://github.com/ardalis/cleanarchitecture
• Электронная книга по разработке архитектуры микрослужбhttps://aka.ms/MicroservicesEbook
• DDD (предметно-ориентированное проектирование)https://learn.microsoft.com/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/

Что представляют собой слои?

По мере увеличения сложности приложения для эффективного управления им может применяться разбиение по обязанностям и задачам. Такой подход соответствует принципу разделения задач и помогает сохранить организацию расширяющейся базы кода, благодаря чему разработчики могут быстро определять, где именно реализованы определенные функции. Многослойная архитектура имеет также целый ряд других преимуществ.

Благодаря упорядочению кода с помощью слоев общие низкоуровневые функции могут многократно использоваться по всему приложению

Это крайне важно, поскольку такой подход требует меньшего объема кода и, за счет стандартизации приложения на уровне одной реализации, соответствует принципу «Не повторяйся»

В приложениях с многослойной архитектурой могут устанавливаться ограничения на взаимодействие между слоями. Такая архитектура помогает реализовать инкапсуляцию. При изменении или замене слоя будут затронуты только те слои, которые работают непосредственно с ним. Ограничивая зависимости слоев друг от друга, можно уменьшить последствия внесения изменений, в результате чего единичное изменение не будет влиять на все приложение.

Применение слоев (и инкапсуляция) позволяет заметно упростить замену функциональных возможностей в рамках приложения. Например, приложение может изначально использовать собственную базу данных SQL Server для сохраняемости, а впоследствии перейти на стратегию сохранения состояния на основе облака или веб-API. Если в приложении надлежащим образом инкапсулирована реализация сохраняемости на логическом слое, этот слой SQL Server может быть заменен новым, где будет реализовываться тот же открытый интерфейс.

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

Разделение на логические слои широко распространено и помогает упорядочить код приложений предприятия. Сделать это можно несколькими способами.

Примечание

Слои обеспечивают логический уровень разделения в приложении. Если логика приложения физически распределена между несколькими серверами или процессами, такие раздельные физические целевые объекты развертывания называются уровнями. Таким образом, не только возможно, но и широко распространено развертывание N-слойных приложений на одном уровне.

UML – Что это?

Проще говоря, если посмотреть картинки в поисковых системах, то станет понятно, что UML – это что-то про схемы, стрелочки и квадратики.

Есть несколько диаграмм, которые мы можем создать с помощью UML, и мы можем разделить их на две категории:

Поведенческая UML-диаграмма

• Activity Diagram
• Use Case Diagram
• Interaction Overview Diagram
• Timing Diagram
• State Machine Diagram
• Communication Diagram
• Sequence Diagram

Структурная диаграмма UML

• Class Diagram
• Object Diagram
• Component Diagram
• Composite Structure Diagram
• Deployment Diagram
• Package Diagram
• Profile Diagram

Я не буду вдаваться в подробности каждого типа диаграмм, потому что это будет слишком много для освещения в этом посте. К каждому типу диаграммы я привел ссылку для ознакомления.

В целом, UML — это хороший вариант для быстрого прототипирования идей и обсуждения их с коллегами.

Однако для документирования всей архитектуры приложения с использованием UML нам необходимо будет использовать несколько типов диаграмм. Кроме того, если мы пытаемся использовать одну единственную диаграмму классов для отображения всего приложения, у нас ничего не получится.

Примером правильного использования диаграммы классов UML является документирование шаблонов проектирования:

Выглядит замечательно! Он может выражать классы, интерфейсы, юзабилити и отношения наследования, данные и поведение. Он также лаконичен и удобен для чтения, а также потому, что он маленький, его также можно быстро нарисовать.

Однако приведенный ниже пример не очень полезен … Он очень большой, поэтому становится запутанным и трудным для понимания. Более того, на его создание уйдет так много времени, что когда мы закончим, он, вероятно, уже устареет, потому что кто-то в это время внес изменения в код.

Таким образом, мы можем и должны использовать UML, но он подходит только для конкретных ситуаций: для подробного описания шаблонов, небольших частей приложения или представлений приложения на довольно высоком уровне.

Но тогда остается вопрос: как нам оформить полную картину ?!

Архитектура определяет поведение

Наряду с определением структурных элементов любая архитектура определяет взаимодействия между этими структурными элементами. Это такие взаимодействия, которые обеспечивают желаемое поведение системы. На рисунке 2 представлена диаграмма сценария UML, которая показывает несколько взаимодействий, которые в сумме позволяют системе поддерживать создание заказа в системе обработки заказов. Мы видим здесь пять взаимодействий. Сначала, деятель Sales Clerk создает заказ при помощи экземпляра класса OrderEntry. Экземпляр класса OrderEntry получает сведения о клиенте при помощи экземпляра класса CustomerManagement. Затем экземпляр класса OrderEntry использует экземпляр класса AccountManagement для того, чтобы создать заказ, внести в него элементы заказа, а затем разместить заказ.

Рисунок 2: диаграмма сценария UML, показывающая элементы поведения

Следует отметить, что рисунок два согласуется с рисунком 1 так, что мы можем извлечь зависимости, показанные на рисунке 1, из взаимодействий, определенных на рисунке 2. Например, экземпляр класса OrderEntry в процессе выполнения зависит от экземляра класса CustomerManagement, как показывают взаимодействия на рисунке 2. Эта зависимость отражается в отношении зависимости между соответствующими классами OrderEntry и CustomerManagement, как показано на рисунке 1.

Суть архитектуры системы

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

Существует минимум три тематических определения архитектуры системы (наборов рабочих моделей).

Суть архитектуры системы

То, как видит систему пользователь, называется операционным (практическим) описанием, или Operation View. Описание содержит в себе этапы применения системы оператором, сценарии и потоки работ:

• графический и числовой вид операций;
• организационную структуру схемы (organization charts);
• различные вариации использования (use cases) и сценарии;
• диаграммы потоков задач (task flow diagrams);
• диаграммы потоков информации (information flow diagrams).

Только до25 декабря

Пройди опрос иполучи обновленный курс от Geekbrains

Дарим курс по digital-профессиям
и быстрому вхождения в IT-сферу

Чтобы получить подарок, заполните информацию в открывшемся окне

Перейти

Скачать файл

Логическое описание (Logical View) это видение системы со стороны руководителя или заказчика. Logical View включает в себя продукты, определяющие границы между самой системой и ее окружением, между функциональными интерфейсами и внешними системами. Кроме того, логическое описание включает в себя артефакты видов поведения и функций системы, потоков данных, внешних и внутренних наборов данных, внешних и внутренних пользователей и внутренних функциональных интерфейсов:

• принципиальные схемы;
• функциональная декомпозиция (data flow chart);
• диаграммы IDEF0;
• схемы или диаграммы функциональных потоков (FFBD).

• физические блок-схемы с подробной детализацией;
• классификация базы данных;
• контроль интерфейса документов и их управления (interface control document, ICD);
• стандарты.

Архитектура операционной системы должна логически связывать между собой все три вида описаний, которые на выходе образуют конечный продукт со всеми основными функциями. Существует термин «архитектурные требования». Он определяет запросы, имеющие максимальное влияние на проектирование архитектуры системы, и указывает на её неразрывную связь с требованиями.

Разработкой архитектуры системы занимаются системные архитекторы. Это является одним из преобладающих видов специализации для этой профессии. Архитектура системы содержит большое количество структур, которые напрямую зависят от потребностей и требований заказчика и разработчика. Это требует определенного системного подхода. Отсюда вытекает ещё одно определение для архитектурного проектирования – системное проектирование.

Первые разработки компьютерных систем происходили без архитектуры. У такого подхода, как тогда казалось, было много плюсов. Разработчики не несли издержек по планированию и быстро реализовывали проект.

Однако со временем, по мере нагрузки и усложнения ПО, оно теряло управляемость. Приходилось добавлять новые изменения, которые с каждым разом становились дороже. Изначальные планы развивать проект за границей рушились. Системы без архитектуры того времени получили название «Большой комок грязи» (Big Ball of Mud).

На сегодняшний день разработчики придумали способы устранения недостатков проектирования программного обеспечения без архитектуры.

Mикросервисная архитектура

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

Основа таких сервисов – бизнес-возможности. Они имеют отдельный автоматизированный механизм и работают отдельно друг от друга.

Административное управление между сервисами сводится к минимуму. Они могут использовать разные технологии хранения данных и иметь отличные друг от друга языки написания.

Создание микросервисной архитектуры систем основывается на компонентизации сервисов, которая делит программное обеспечение на различные компоненты (сервисы) изолированные друг от друга. Каждый из таких сервисов несёт свою ответственность. Изменение одних компонентов не должны влиять на другие.

Архитектура работает по принципу компонентизации сервисов. Она разделяет программное обеспечение на различные изолированные компоненты (сервисы) каждый из которых несет единую ответственность. Изменения в одной сервисе не должны затрагивать другие.

Mикросервисная архитектура

Архитектура включает в себя отдельные компактные микросервисы. Они способны расширяться обособленно и не зависят друг от друга. Вот 5 основных компонентов такой архитектуры:

• сервисы (Services);
• сервисная шина (Service Bus);
• внешняя конфигурация (External configuration);
• шлюз API (API Gateway);
• контейнеры (Containers).

Популярные статьи

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

Дополнительный заработок в Интернете: варианты для новичков и специалистов

Востребованные удаленные профессии: зарабатывайте, не выходя из дома

Разработчик игр: чем занимается, сколько зарабатывает и где учится

Как выбрать профессию по душе: детальное руководство + ценные советы

Основными характеристиками микросервисной архитектуры являются:

• сервисная компонентизация;
• организация отталкивается от бизнес-возможностей;
• ориентация на продукты, а не на проекты;
• умные конечные точки и глупые каналы (Smart endpoints and dumb pipes);
• децентрализованное управление;
• децентрализованное управление данными;
• автоматизированная инфраструктура;
• защита от сбоев;
• эволюционное проектирование.

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

Плюсы:

• Высокий уровень изоляции со слабой связанностью.
• Повышенная модульность.
• Изолированные системы предотвращают влияние сбоя в одном сервисе на другой.
• Гибкость и масштабируемость на высоком уровне.
• Ускоренные итерации, благодаря простой модификации.
• Улучшенная система обработки ошибок.
• В отличие от многослойной архитектуры, решает проблемы с потоками данных.

Недостатки:

• При обмене данных между сервисами есть повышенный риск сбоя.
• Затрудненное управление из-за большого количества сервисов.
• Распределительная архитектура обязывает искать пути решения ряда проблем: задержка в сети, удержание гармоничного баланса нагрузки.
• Требует обязательного тестирования в распределительной среде.
• Долгое время реализации.

Мы рассмотрели все виды архитектуры систем. Отражение взаимодействия бизнеса и ИТ является основной задачей при создании архитектуры. С одной стороны, это документирование и стандартизация бизнес-процессов. С другой – описание составляющих архитектуры веб-систем на логическом уровне с учетом связей с бизнес-процессами.

Микросервисы против Монолитов

И микросервисы, и монолитные сервисы – это архитектурные паттерны, которые используются при разработке программных приложений для обслуживания бизнес-требований. У каждого из них есть свои преимущества, недостатки и проблемы.

С одной стороны, когда монолитные архитектуры служат в качестве крупномасштабной системы, это может усложнить ситуацию. Они могут быть громоздкими в работе, когда нужно добавить новые функции, внести изменения или даже удалить некоторые ненужные функции.

Однако монолитные архитектуры по-прежнему являются хорошим вариантом для приведенных ниже случаев:

• малогабаритные приложения;

• нет необходимости в обновлении технологии;

• вам требуется меньше времени для вывода на рынок;

• команды знакомы с Монолитными подходами.

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

Микросервисная архитектура является хорошим вариантом для следующих случаев:

• широкомасштабные приложения;

• вам необходимо обновление технологии;

• разные команды работают с разными техническими скилами (языки программирования, фреймворки и другое);

• если у вас есть различные домены, которые необходимо обработать;

• И многие другие.

Паттерн Saga

Этот паттерн помогает в управлении транзакциями, где локальные транзакции в каждом сервисе (saga) выполняются, и выдают событие для следующего сервиса, чтобы начать транзакцию. Если какая-либо из транзакций терпит неудачу, серия транзакций, компенсирующих предыдущую транзакцию, будет выполнена saga, чтобы отменить все изменения, сделанные локальными транзакциями, предшествующими этой.

Ниже приведены два способа реализации паттерна Sagа.

Хореография

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

Оркестрирование

Оркестрирование обеспечивает способ управления участниками saga (сервисами), сообщая каждому сервису о локальной транзакции, которую ему необходимо выполнить. На событийной основе операции для saga и транзакций обрабатываются оркестратором saga. Состояние отдельной задачи управляется saga, и в случае сбоя он выполнит транзакцию, чтобы компенсировать предыдущие транзакции.

Зачем беспокоиться об архитектуре, принципах, практиках?

Снижение затрат — Хотя изначально скорость разработки будет меньше, но в конечном итоге общая стоимость создания, а затем и технической поддержки будет меньше

Делайте только то, что требуется, — это позволяет нам создавать самые необходимые блоки кода. Важно делать именно то, что требуется для решения задачи, делать это раньше – путь к плохой архитектуре. Этот подход помогает устранить беспорядок, создавая только то, что необходимо, тем самым уменьшая накладные расходы на обслуживание кода. Оптимизация — Регулярно задумывайтесь о рефакторинге кода

Это позволит содержать большие объемы кода в чистоте и порядке

Оптимизация — Регулярно задумывайтесь о рефакторинге кода. Это позволит содержать большие объемы кода в чистоте и порядке.

Оптимизация производительности — Не делайте оптимизации производительности кода, пока не достигните LRT.

LRT – это концепция, заимствованная из принципов бережливого производства, в которой решения/изменения откладываются до определенного момента времени, после которого стоимость непринятия решения станет дороже, чем принятие решения. Когда требования серые, проектные решения следует отложить до LRT, чтобы к тому времени мы получили достаточно знаний для принятия обоснованных проектных решений.

Адаптивность/Эволюция — Следуя вышесказанному, программное обеспечение всегда следует эволюционной модели, когда оно продолжает адаптироваться к новым требованиям бизнеса и масштаба