S0ER

​​Для построения крупных распределенных приложений используется механизм обмена сообщениями. Процесс строится на принципе «положил в очередь/взял из очереди», обычно в роли места куда складываются сообщения выступает брокер сообщений. Микросервис который «кладет» в очередь называется Producer Микросервис который «берет» из очереди называется Consumer AMQP — открытый протокол для передачи сообщений между компонентами системы Высокая доступность при использовании микросервисов подразумевает планирование и определение сервисов, к которым предъявляются требования высокой доступности. Для этих сервисов должны быть определены возможные точки отказа и варианты восстановления. Один из эффективных подходов – файлуре толеранс (принятие сбоев). Уровень доступности определяется процентом времени в аптайме, 100% - 24/7 Основная идея для повышения доступности системы – дублирование основных элементов архитектуры. Сюда относится: - балансировка DNS - дублирование интернет провайдеров (ISP), использование BGP протокола - дублирование СУБД - дублирование инфраструктуры для развертывания микросервисов

CQRS — это стиль архитектуры, в котором операции чтения отделены от операций записи. CQRS строится на базе двух концепций: - команды - события #microservice

Practical Microservices Architectural Patterns Event-Based Java Microservices with Spring Boot and Spring Cloud Вводная часть книги содержит общее описание классического подхода к построению архитектуры систем: - менйфрейм архитектура, когда есть центральный супер компьютер и куча «тупых» терминалов, которые отображают данные, но весь стейт хранится на сервере; - клиент/серверная архитектура, когда стейт хранится на клиента, а тяжелые операции выполняются на сервере - 3-х уровневая архитектура системы – классическое разделение на клиентский уровень, бизнес логику (средний уровень) и данные - многоуровневая архитектура – выделение из среднего уровня несколько промежуточных уровней. В большинстве случаев архитектура систем используется сетевую инфраструктуру для взаимодействия между клиентом и сервером. Для этого есть несколько стандартных решений: - соединение точка/точка - брокер сообщений - общая шина сообщений В свою очередь, архитектурные уровни, входящие в систему, могут разделяться на слои приложения, которые бьются на модули. Модульный подход – классика построения сложных систем. У модульного подхода несколько недостатков: – ад зависимостей, которые с ростом системы все труднее поддаются управлению; - ограничения масштабирования, которые вытекают из предыдущего пункта; - монолитность на уровне системы, несмотря на то что внутри приложение разделено на слои и модули, разделение уровней системы невозможно и они развертываются как единый элемент. Основные принципы построение масштабируемых систем: - Стейтлес дизайн – без единой точки состояния система может тиражироваться на любое количество узлов; - Использование принципа разделяй и властвуй – способ разбить монолит на части и вынести части за пределы единого узла развертывания; Альтернативой классическим монолитным подходам выступает архитектура с независимыми модулями, которая имеет два основных преимущества: - параллельная разработка - разделенная публикация Основная проблема такого решение – организация взаимодействия между модулями. При синхронном взаимодействии возникают длительные периоды когда модуль ничего не делает ожидая ответ, поэтому асинхронная природа запросов – вынужденное зло. Наиболее продвинутым вариантом построения архитектуры с независимыми модуля является микросервисная архитектура, у нее следующие особенности: - общение сервисом посредством сообщений, которые передаются через сетевую инфраструктуру - разнородная, независимая природа сервисов (могут быть реализованы на разных языках, в разных модулях развертывания) - сосредоточенность на бизнес задачах - размер сервиса небольшой, ограничен решением маленькой задачи, с возможностью независимой публикации сервиса и его обновления. В основе взаимодействия микросервисов лежат REST-запросы и JSON нотация для представления данных. Но так же может быть использован другой формат, например XML. MASA (Mesh App and Service Architecture) – архитектурное решение, которое позволяет объединить и организовать различных пользователей, с различными девайсами, работающих на различные типах сетей. В такой архитектуре бесшовно должны работать мобильные приложения, веб-приложения, десктопные приложения, IOT устройства. Варианты построения облачной инфраструктуры: Infrastructure as a Service — одна из моделей обслуживания в облачных вычислениях, по которой потребителям предоставляются по подписке фундаментальные информационно-технологические ресурсы — виртуальные серверы с заданной вычислительной мощностью, операционной системой и доступом к сети Platform as a Service — модель предоставления облачных вычислений, при которой потребитель получает доступ к использованию информационно-технологических платформ: операционных систем, систем управления базами данных, связующему программному обеспечению, средствам разработки и тестирования Software as a Service — одна из форм облачных вычислений, модель обслуживания, при которой подписчикам предоставляется готовое прикладное программное обеспечение, полностью обслуживаемое провайдером Варианты виртуализации: виртуальные серверы или контейнеры. #microservice

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

Роль «Архитектор» - определение и взаимодействие со стекхолдерами - определение требований - определение ограничений - построение архитектуры соответствующей требованиям и ограничениям Специализации архитектора: - product architect – отвечает за поставку продукта внешним заказчикам или стекхолдерам - domain architect – основные функции по построению архитектуры высокого уровня (бизнес-архитектура, архитектура данных и т.д.) - solution architect - отвечает за архитектуру на уровне решения - enterprise architect – высокоуровневые задачи управления предприятием – продажи, маркетинг, продукты, сервисы и т.д. Подходы к проектированию архитектуры: - Каскадная модель (waterfall) – модель при которой архитектор проходит стандартные фазы: анализ требований, проектирование, реализация и т.д. - Итеративный подход – разделение проектирования на итерации (обычно каждая итерация – это отдельный вопрос проектирование) и проход по каждой итерации как по самостоятельному проекту - Agile - непрерывный цикл проектирования включающий «дизайн», «разработка и тестирование», «развертывание», «анализ». Важные элементы архитектуры: - Бизнес цели и «драйверы» - конкретны задачи, которые хочет решить бизнес, а так же способы их достижения; - Архитектурный контекст – это описание важных элементов архитектуры, которые определяют ее взаимодействие с внешним миром, а так же ее функциональные возможности. Описывается коротко, с достаточной для понимания сути детализацией, без жаргона и скрытой «магии»; - Архитектурные вопросы – описание того какие проблемы существуют и как они решаются в рамках построения системы, а также ограничения которые нужно учитывать. Описание как правило включает архитектурные цели, функциональные требования, архитектурные требования и т.д. - Архитектурные принципы – это принципы построения системы, ее каркас, а так же подсказка какие решения в рамках архитектур должны приниматься. Принципы должны быть конструктивными, обдуманными, существенными. Архитектурные паттерны как правило бьются на три группы: - архитектурные стили – паттерн описывающий архитектуру на системном уровне, основное отличие в том что стиль рассматривает систему целиком, не концентрируясь на деталях. Стиль как правило описывается в терминах «архитектурных элементов» их взаимодействии и ограничениях. - шаблон проектирования – это более конкретное решение, которое направлено на решение специфического вопроса и содержит описание какой-то конкретной ситуации; - идиомы языка программирования – шаблоны для реализации на уровне языка программирования, учитывающие особенности языка и реализующие лучшие практики. Распространённые архитектурные стили: - Pipes and filters - Client/Server - Tiered Computing (отличается от Layered тем, что порядок взаимодействия tier-ов может быть любым) - Peer-to-Peer - Layered Implementation - Publisher/Subscriber (реактивные архитектуры) - Asynchronous Data Replication (отличается от pub/sub тем, что предназначена для синхронизации источников данных) - Distribution Tree (publisher -> distributor -> consumer) - Integration Hub (отличается от Data Replication тем, что синхронизация данных идет между системами, а не репликами БД) - Tuple Space Важные артефакты описания архитектуры: - Архитектурное описание (общее описание системы) - Моделирование (модель отражает упрощенное представление реальной бизнес задачи и служит для выстраивания аспектов системы) - Сценарии использования готовой системы - Валидация (проверка технических и логических моментов на корректность)

​​Цели использования перспектив: - улучшения - создание артефактов

​​Обычно архитектурные элементы – это компоненты или модули. Для архитектуры так же справедливо правило «Быстро, качественно, недорого» - можно выбрать только два из трех. Представления Сама большая ошибка при разработке архитектуры проекта – создание сложных моделей, отвечающих и выполняющих все на свете. Таких перегруженных решений нужно избегать. Правильное решение – декомпозировать систему на набор представлений. Определять представления каждый раз при проектировании системы – бессмысленно, для переиспользования готовых решений можно применять паттерны, соглашения и другие наработки созданные в рамках представлений, которые в рамках книги называются viewpoint. Преимущества использования идеи «архитектурных представлений»: - разделение проблем - управление сложностью - упрощение коммуникаций со стекхолдером - сфокусированность на проблема разработки Подводные камни: - несогласованность представлений - неправильный выбор представлений - фрагментация Перспективы Основные: безопасность, производительность, масштабируемость, доступность, устойчивость, эволюционность.

Конспект книги Software System Architecture (автор Nick Rozanski, Eoin Woods) Книга рассматривает три основные концепции, которые используются при построении архитектуры любой системы: 1. Stackholders (заказчики системы) – люди, которые принимают решения относительно того, какие функции должны быть реализованы, а какие нет 2. Viewpoins и view (представление) – это способ структурировать систему, дать описание каждого важного аспекта системы как самостоятельной сущности. Для построения представлений используется принцип «разделяй и властвуй». Каждое преставление описывает «что» должна делать программа или система, а так же взаимодействие и влияние представлений между собой. Обычно через представления описываются «функциональная структура», «информационная организация», «среда развертывания» и т.д. 3. Perspective (архитектурные перспективы) это аналог представлений, но используются они для того чтобы описать «как» должна работать система. Обычно через представления описываются вопросы относящиеся к качественным характеристикам – безопасность, надежность, производительность. Перспективы могут быть общими для многих представлений. Архитектура - это базовая организация системы, воплощенная в ее компонентах, их отношениях между собой и с окружением, а также принципы, определяющие проектирование и развитие системы. Структуры в архитектуре: - статичные структуры – определяют то чем является проектируемая система (описание интерфейсов, аппаратного обеспечения, модулей и т.д.) - динамические структуры – описывают как именно работает система, обычно эти структуры создаются и используются в рантайме. Свойства системы - такие свойства, которые может увидеть или оценить внешний наблюдатель, воспринимая систему как черный ящик. То ради чего система создается. Качественные характеристики – это целевые показатели системы, которые важны для разработки системы. Архитектурные кандидаты – варианты организации архитектуры. Архитектурные элементы – это элементы из которых состоит система. Ключевые атрибуты архитектурных элементов: - четко определенные обязанности - четко определенные ограничения - набор строго определенных интерфейсов, которые определяют сервисы для взаимодействия архитектурных элементов.

1. Прототипирование 2. Запуск на малом объеме реальных данных (пробный запуск) 3. Стейджинг (или препродакшен) 4. Канареечное тестирование (частичный запуск) 5. Частичное развертывание на «боевом» окружении 6. Развертывание на всем «боевом» окружении Принципы построения релизов: - воспроизводимые сборки - автоматизированные сборки - автоматизированные тесты - автоматизированные публикации - небольшие развертывания В цикле выше важный этап – это канареечное тестирование, когда деплой выполняется на ограниченное количество ресурсов и может быть ограничен по времени, так же предполагается возможность быстрого отката. Для эффективного канареечного тестирования нужно реализовать принципы построения релизов. В конечном итоге это ложится в модель CI/CD При выполнении канареечного тестирования нужно подобрать время и ресурсы, которые с одной стороны обеспечат необходимый объем тестирования, с другой стороны (в случае сбоя) риски будут минимизированы. Для проведения канареечного тестирования важно выбрать набор репрезентативных метрик, которые могут наглядно показать, что развертывание прошло успешно. Варианты канареечного развёртывания: - Синее/зеленое развертывание – зеленые – куда реально идет трафик и выполняется развертывание, синее – резерв куда можно перейти, если найдены ошибки в релизе - искусственная генерация данных – вместо реальной среды канарейка помещается под нагрузку, но с синтезированными данными - теневое копирование – когда канарейка развертывается в тестовой среде, но с копией реальных данных Выводы: Книга глубоко рассматривает выстраивание рабочего процесса на базе SRE, приведено очень много примеров и разъяснений, которые помогают «нащупать» основные моменты реализуемые в стандарте и наметить путь внедрения SRE. Но при этом эта одна из тех книг, которые требуют повторного прочтения и переосмысления. Особенно удобно использовать книгу в процессе реального развертывания SRE. Рекомендую к прочтению все кто занимается организационными вопросами в командах разработчиков.

​​Цикл разработки

​​Non-Abstract Large System Design (NALSD) Процесс проектирования: 1 стадия включает принципиальную возможность построения решения: - Возможно ли это? - Можем ли мы сделать лучше? 2 стадия вписывает принципиальное решение в рамки проекта: - возможно ли реализовать в заданных границах (деньги, время и т.д.) - устойчиво ли полученное решение? - можно ли сделать лучше? Далее итеративно делается следующее: - формируются требования - выполняется дизайн системы - выполняется калькуляция ресурсов - определяются варианты развития системы - процесс повторяется со второй позиции, до получения удовлетворяющего требованиям решения. Конвейеры обработки данных используются в следующих приложениях: 1. ETL (Extract Transform Load) ETL служат для: - изменения состава данных - выполнения промежуточных расчетов - назначение индексов - обогащение данных 2. Анализ данных (например на базе BI системы). Используются для оперативного мониторинга, построения отчетов, анализа данных. 3. Машинное обучение используется для поиска корреляций и «умного» анализа данных.

Конспект The Site Reliability Workbook Ключевые концепции DevOps: - уменьшение преград и разрозненности - проблемы – это нормально - изменения должны внедряться поэтапно - инструменты и корпоративная культура взаимосвязаны - измерения важны (что нельзя измерить, нельзя улучшить) SRE – Site Reliability Engineering Ключевые концепции SRE: - Все операции по сопровождению выполняются программным обеспечением - Управленческие решения принимаются на базе SLO (Service level objectives) - Минимизация человеческого труда - Автоматизация прежде всего - Уменьшение стоимости ошибки - Уменьшение границ между разработкой и сопровождением - Унификация используемых инструментов Вывод: SRE и DevOps очень похожи друг на друга. Организация работы построена на идеях персональной ответственности (делай сам, а не перекладывай на других), взаимозаменяемости (каждый можем кого угодно), взаимоуважения. SLO – документ определяющий требования к продукту (список целей и критерии их достижения) Организация работы начинается с определения SLO SLO включает в себя требования надежности Для оценки надежности и качества используют показатели уровня обслуживания SLI (Service Level Indicator) – числовые метрики, которые можно измерить и агрегировать по времени. Сбор данных SLI должен осуществляться автоматизировано средствами системы мониторинга. Для мониторинга предлагается использовать стандартные принципы и системы. Идея состоит в сборе числовых метрик и событий. Использовании распределенных, слабозацепленных систем мониторинга. Для оповещения использовать стандартные схемы с всплывающими окнами, смс и почтой. Для уменьшения потока оповещений использовать механизмы агрегации. Человеческий труд – основное препятствие для повышение эффективности работы. Уменьшение труда делается за счет автоматизации и отказа от лишнего труда. Основные «пожиратели» времени сотрудников – бизнес процессы, консультации и контроль правильности выполнения работ, миграции на новые технологии, проблемы с инструментами (вынужденные простои). При этом SRE не ставит перед собой задачу полностью устранить труд, но сделать это там где возможно. Основное решение – автоматизация. Но перед выполнением автоматизации должна быть выполнена оценка целесообразности изменений, возможно от можно просто отказаться от лишних действий. Важный момент автоматизации – системы восстановления работоспособности. Советы по оптимизации систем восстановления работоспособности: - графический интерфейс не должен быть сложным или перегруженным - не полагаться на человеческую экспертизу/опыт (имеется в виду анализ потока событий одним или несколькими людьми, анализ должен быть автоматизирован) - проектируйте переиспользуемые компоненты - не переоценивайте проблему и не усложняйте решение - не стремитесь делать идеальную автоматику - автоматизация – не разовое мероприятие - подходите к проблему целостно Одна из важных целей SRE – оставлять систему максимально простой. Оценка сложности программной системы имеет множество нюансов. Недостаточно оценить цикломатическую сложность исходного кода софта, входящего в систему. В число параметров для оценки входят: время обучения нового члена команды для работы с системой, время объяснения устройства системы, разнообразие административных возможностей, разнообразие конфигурационных моментов, возраст системы. Упрощение системы – непрерывный процесс поиска решений, которые позволяют уменьшать время на освоение системы новыми членами команды, переиспользовать системы повторно и т.д. SRE инженеры должны быть задействованы и в оперативной работе, и в проектировании. Один из основных механизмов устранения проблема – инцидент менеджмент. Средство автоматизации – ICS (Incident Command System). Ролевая модель: - Incident Commander – управляет устранением инцидента (обычно человек обнаруживший инцидент) - Communication Lead – обеспечивает внешние коммуникации - Ops Lead - устраняет инцидент Инцидент – событие требующее немедленной реакции и устраняющееся в короткие сроки. Важно как можно быстрее восстановить работоспособность системы.

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

рекомендую посмотреть вводный видос в эту тему

Эту концепцию активно продвигает Google

Следующий конспект будет ко книге The Site Reliability Workbook

Конспект книги «Database Reliability Engineering» (DBRE) Оценка Основные индикаторы работоспособности сервиса: - Latency (время ответа) - Availability (доступность) - Throughput (пропускная способность) обычно измеряется в операциях за единицу времени - Durability (прочность или целостность данных) - Cost or Efficiency (цена или эффективность) похожа на оценку «стоимость владения» - затраты на выполнение действий и поддержание СУБД Для оценки сервиса для каждого из этих параметров нужно определить нижнюю и верхнюю границы, исходя из здравого смысла и требований заказчика. Далее нужно автоматизировать процесс мониторинга, чтобы контроль за БД осуществлялся непрерывно. Риск менеджмент Основные действия: - определить возможные проблемы/опасности которые создают операционные риски для сервиса - оценить каждый риск и его влияние - определить вероятности и последствия рисков - определить способы контроля и уменьшения рисков - расставить приоритеты рисков - настроить системы мониторинга - итеративно повторять данный список действий Основные категории рисков: - неучтенные факторы и сложность - доступность ресурсов - человеческий фактор - безынициативность - игнорирование простых проблем - страх перед принятием решения - излишний оптимизм - групповые факторы - перекладывание ответственности/принятия решения - перекладывание рисков Для избегания рисков – не позволяйте себе «стагнировать» и полагаться на случай. Операционная прозрачность Идея в том, чтобы сосредоточиться на анализе параметров работы сервиса и планировать его развитие. Особенность современных БД – распределенность. Это дополнительная сложность для качественной оценки. Для анализа следует использовать специализированные системы, например BI Советы при организации систем мониторинга: - высокая скважность для сбора ключевых метрик - простая архитектура сервисов - использование фреймворков OpViz (операционная прозрачность) - использование реальных данных для тестирования, а не синтезированных данных (тестирование как черный ящик) - использование граничных случаев (тестирование как белый ящик) - использование метрик и событий для анализа - использовать продуманную политику для отображения данных и нотификации Необходимо мониторить не только доступность сервиса, но и удовлетворенность клиентов качеством предоставляемой услуги. Точки контроля - контроль аппаратных средств (диск, процессор, память) - контроль подключений - контроль внутреннего состояния Бэкап Основные концепции - логический – сохранение в формате подразумевающим возможность экспорта в другие системы - физический – копирования файлов данных на систему резервного копирования - онлайн – при одновременной работе СУБД - офлайн – при выключенной СУБД - полный – полное копирование - инкрементальный – только изменения с прошлого бэкапа - дифференциальный – только изменения с проглого полного бэкапа В зависимости от выбранных опций резервного хранения можно делать различные схемы восстановления, которые продумываются на этапе проектирования. Миграции Шаблоны, которые используются для миграций БД: - locking operations - high resource utilization operations - rolling migrations Теория БД - ACID (атомарность, согласованность, изолированность, долговечность) - BASE (базовая доступность, неустойчивое состояние, согласованность в конечном счете) - CAP теорема (только 2 из 3: согласованность, доступность, устойчивость к разделению) Оценка книги: книга обзорно рассматривает основные понятия связанные с разработкой надежных баз данных. Сюда входит и подготовка инфраструктуры, и обзор средств и способов мониторинга, и вопросы связанные с построением и проектированием БД. Рекомендую к прочтению.

Стоит ли продолжать публиковать конспекты по книгам?