Модульность
В основе модульности лежит идея слабого зацепления и автономность модулей.
Иерархия стандартная: модуль - компонент - код
В основе модульности лежит идея слабого зацепления и автономность модулей.
Иерархия стандартная: модуль - компонент - код
Workflow
- инкрементальные изменения
- построение и поддержание фитнес функций
- поддержание модульности
- инкрементальные изменения
- построение и поддержание фитнес функций
- поддержание модульности
Все остальные архитектуры могут развиваться эволюционнно. В книге есть пояснения относительно следующих архитектур:
Монолитные
- цельный монолит
- многослойный монолит
- модульный монолит
- микроядерный монолит
Event Driven
- брокеры
- медиаторы
Сервис ориентированные архитектуры
- ESB driven SOA
- микросервисы
Серверлес архитектура
Монолитные
- цельный монолит
- многослойный монолит
- модульный монолит
- микроядерный монолит
Event Driven
- брокеры
- медиаторы
Сервис ориентированные архитектуры
- ESB driven SOA
- микросервисы
Серверлес архитектура
Алгоритм построения эволюционной архитектуры
- определить требования, которые защищены эволюцией
- определить фитнес функции (оценки качества)
- настроить непрерывное развертывание с учетом автоматизации фитнес функций (конвейр развертывания)
- движение вперед по workflow описанному выше
- определить требования, которые защищены эволюцией
- определить фитнес функции (оценки качества)
- настроить непрерывное развертывание с учетом автоматизации фитнес функций (конвейр развертывания)
- движение вперед по workflow описанному выше
Конспект книги «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: согласованность, доступность, устойчивость к разделению)
Оценка книги: книга обзорно рассматривает основные понятия связанные с разработкой надежных баз данных. Сюда входит и подготовка инфраструктуры, и обзор средств и способов мониторинга, и вопросы связанные с построением и проектированием БД. Рекомендую к прочтению.
Оценка
Основные индикаторы работоспособности сервиса:
- Latency (время ответа)
- Availability (доступность)
- Throughput (пропускная способность) обычно измеряется в операциях за единицу времени
- Durability (прочность или целостность данных)
- Cost or Efficiency (цена или эффективность) похожа на оценку «стоимость владения» - затраты на выполнение действий и поддержание СУБД
Для оценки сервиса для каждого из этих параметров нужно определить нижнюю и верхнюю границы, исходя из здравого смысла и требований заказчика.
Далее нужно автоматизировать процесс мониторинга, чтобы контроль за БД осуществлялся непрерывно.
Риск менеджмент
Основные действия:
- определить возможные проблемы/опасности которые создают операционные риски для сервиса
- оценить каждый риск и его влияние
- определить вероятности и последствия рисков
- определить способы контроля и уменьшения рисков
- расставить приоритеты рисков
- настроить системы мониторинга
- итеративно повторять данный список действий
Основные категории рисков:
- неучтенные факторы и сложность
- доступность ресурсов
- человеческий фактор
- безынициативность
- игнорирование простых проблем
- страх перед принятием решения
- излишний оптимизм
- групповые факторы
- перекладывание ответственности/принятия решения
- перекладывание рисков
Для избегания рисков – не позволяйте себе «стагнировать» и полагаться на случай.
Операционная прозрачность
Идея в том, чтобы сосредоточиться на анализе параметров работы сервиса и планировать его развитие.
Особенность современных БД – распределенность. Это дополнительная сложность для качественной оценки. Для анализа следует использовать специализированные системы, например BI
Советы при организации систем мониторинга:
- высокая скважность для сбора ключевых метрик
- простая архитектура сервисов
- использование фреймворков OpViz (операционная прозрачность)
- использование реальных данных для тестирования, а не синтезированных данных (тестирование как черный ящик)
- использование граничных случаев (тестирование как белый ящик)
- использование метрик и событий для анализа
- использовать продуманную политику для отображения данных и нотификации
Необходимо мониторить не только доступность сервиса, но и удовлетворенность клиентов качеством предоставляемой услуги.
Точки контроля
- контроль аппаратных средств (диск, процессор, память)
- контроль подключений
- контроль внутреннего состояния
Бэкап
Основные концепции
- логический – сохранение в формате подразумевающим возможность экспорта в другие системы
- физический – копирования файлов данных на систему резервного копирования
- онлайн – при одновременной работе СУБД
- офлайн – при выключенной СУБД
- полный – полное копирование
- инкрементальный – только изменения с прошлого бэкапа
- дифференциальный – только изменения с проглого полного бэкапа
В зависимости от выбранных опций резервного хранения можно делать различные схемы восстановления, которые продумываются на этапе проектирования.
Миграции
Шаблоны, которые используются для миграций БД:
- locking operations
- high resource utilization operations
- rolling migrations
Теория БД
- ACID (атомарность, согласованность, изолированность, долговечность)
- BASE (базовая доступность, неустойчивое состояние, согласованность в конечном счете)
- CAP теорема (только 2 из 3: согласованность, доступность, устойчивость к разделению)
Оценка книги: книга обзорно рассматривает основные понятия связанные с разработкой надежных баз данных. Сюда входит и подготовка инфраструктуры, и обзор средств и способов мониторинга, и вопросы связанные с построением и проектированием БД. Рекомендую к прочтению.
Я осознанно опустил из конспекта вопросы касающиеся процесса управления конфигуациями, изменениями и проблемами. Эти процессы очень похожи на то, что описывает ITIL и так как я планирую конспектировать ITIL здесь не рассматриваю эти вопросы.
Конспект 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 - устраняет инцидент
Инцидент – событие требующее немедленной реакции и устраняющееся в короткие сроки. Важно как можно быстрее восстановить работоспособность системы.
Ключевые концепции 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 - устраняет инцидент
Инцидент – событие требующее немедленной реакции и устраняющееся в короткие сроки. Важно как можно быстрее восстановить работоспособность системы.
Non-Abstract Large System Design (NALSD)
Процесс проектирования:
1 стадия включает принципиальную возможность построения решения:
- Возможно ли это?
- Можем ли мы сделать лучше?
2 стадия вписывает принципиальное решение в рамки проекта:
- возможно ли реализовать в заданных границах (деньги, время и т.д.)
- устойчиво ли полученное решение?
- можно ли сделать лучше?
Далее итеративно делается следующее:
- формируются требования
- выполняется дизайн системы
- выполняется калькуляция ресурсов
- определяются варианты развития системы
- процесс повторяется со второй позиции, до получения удовлетворяющего требованиям решения.
Конвейеры обработки данных используются в следующих приложениях:
1. ETL (Extract Transform Load)
ETL служат для:
- изменения состава данных
- выполнения промежуточных расчетов
- назначение индексов
- обогащение данных
2. Анализ данных (например на базе BI системы). Используются для оперативного мониторинга, построения отчетов, анализа данных.
3. Машинное обучение используется для поиска корреляций и «умного» анализа данных.
Процесс проектирования:
1 стадия включает принципиальную возможность построения решения:
- Возможно ли это?
- Можем ли мы сделать лучше?
2 стадия вписывает принципиальное решение в рамки проекта:
- возможно ли реализовать в заданных границах (деньги, время и т.д.)
- устойчиво ли полученное решение?
- можно ли сделать лучше?
Далее итеративно делается следующее:
- формируются требования
- выполняется дизайн системы
- выполняется калькуляция ресурсов
- определяются варианты развития системы
- процесс повторяется со второй позиции, до получения удовлетворяющего требованиям решения.
Конвейеры обработки данных используются в следующих приложениях:
1. ETL (Extract Transform Load)
ETL служат для:
- изменения состава данных
- выполнения промежуточных расчетов
- назначение индексов
- обогащение данных
2. Анализ данных (например на базе BI системы). Используются для оперативного мониторинга, построения отчетов, анализа данных.
3. Машинное обучение используется для поиска корреляций и «умного» анализа данных.
1. Прототипирование
2. Запуск на малом объеме реальных данных (пробный запуск)
3. Стейджинг (или препродакшен)
4. Канареечное тестирование (частичный запуск)
5. Частичное развертывание на «боевом» окружении
6. Развертывание на всем «боевом» окружении
Принципы построения релизов:
- воспроизводимые сборки
- автоматизированные сборки
- автоматизированные тесты
- автоматизированные публикации
- небольшие развертывания
В цикле выше важный этап – это канареечное тестирование, когда деплой выполняется на ограниченное количество ресурсов и может быть ограничен по времени, так же предполагается возможность быстрого отката. Для эффективного канареечного тестирования нужно реализовать принципы построения релизов. В конечном итоге это ложится в модель CI/CD
При выполнении канареечного тестирования нужно подобрать время и ресурсы, которые с одной стороны обеспечат необходимый объем тестирования, с другой стороны (в случае сбоя) риски будут минимизированы. Для проведения канареечного тестирования важно выбрать набор репрезентативных метрик, которые могут наглядно показать, что развертывание прошло успешно.
Варианты канареечного развёртывания:
- Синее/зеленое развертывание – зеленые – куда реально идет трафик и выполняется развертывание, синее – резерв куда можно перейти, если найдены ошибки в релизе
- искусственная генерация данных – вместо реальной среды канарейка помещается под нагрузку, но с синтезированными данными
- теневое копирование – когда канарейка развертывается в тестовой среде, но с копией реальных данных
Выводы: Книга глубоко рассматривает выстраивание рабочего процесса на базе SRE, приведено очень много примеров и разъяснений, которые помогают «нащупать» основные моменты реализуемые в стандарте и наметить путь внедрения SRE. Но при этом эта одна из тех книг, которые требуют повторного прочтения и переосмысления. Особенно удобно использовать книгу в процессе реального развертывания SRE. Рекомендую к прочтению все кто занимается организационными вопросами в командах разработчиков.
2. Запуск на малом объеме реальных данных (пробный запуск)
3. Стейджинг (или препродакшен)
4. Канареечное тестирование (частичный запуск)
5. Частичное развертывание на «боевом» окружении
6. Развертывание на всем «боевом» окружении
Принципы построения релизов:
- воспроизводимые сборки
- автоматизированные сборки
- автоматизированные тесты
- автоматизированные публикации
- небольшие развертывания
В цикле выше важный этап – это канареечное тестирование, когда деплой выполняется на ограниченное количество ресурсов и может быть ограничен по времени, так же предполагается возможность быстрого отката. Для эффективного канареечного тестирования нужно реализовать принципы построения релизов. В конечном итоге это ложится в модель CI/CD
При выполнении канареечного тестирования нужно подобрать время и ресурсы, которые с одной стороны обеспечат необходимый объем тестирования, с другой стороны (в случае сбоя) риски будут минимизированы. Для проведения канареечного тестирования важно выбрать набор репрезентативных метрик, которые могут наглядно показать, что развертывание прошло успешно.
Варианты канареечного развёртывания:
- Синее/зеленое развертывание – зеленые – куда реально идет трафик и выполняется развертывание, синее – резерв куда можно перейти, если найдены ошибки в релизе
- искусственная генерация данных – вместо реальной среды канарейка помещается под нагрузку, но с синтезированными данными
- теневое копирование – когда канарейка развертывается в тестовой среде, но с копией реальных данных
Выводы: Книга глубоко рассматривает выстраивание рабочего процесса на базе SRE, приведено очень много примеров и разъяснений, которые помогают «нащупать» основные моменты реализуемые в стандарте и наметить путь внедрения SRE. Но при этом эта одна из тех книг, которые требуют повторного прочтения и переосмысления. Особенно удобно использовать книгу в процессе реального развертывания SRE. Рекомендую к прочтению все кто занимается организационными вопросами в командах разработчиков.
Конспект книги Software System Architecture
(автор Nick Rozanski, Eoin Woods)
Книга рассматривает три основные концепции, которые используются при построении архитектуры любой системы:
1. Stackholders (заказчики системы) – люди, которые принимают решения относительно того, какие функции должны быть реализованы, а какие нет
2. Viewpoins и view (представление) – это способ структурировать систему, дать описание каждого важного аспекта системы как самостоятельной сущности. Для построения представлений используется принцип «разделяй и властвуй». Каждое преставление описывает «что» должна делать программа или система, а так же взаимодействие и влияние представлений между собой.
Обычно через представления описываются «функциональная структура», «информационная организация», «среда развертывания» и т.д.
3. Perspective (архитектурные перспективы) это аналог представлений, но используются они для того чтобы описать «как» должна работать система. Обычно через представления описываются вопросы относящиеся к качественным характеристикам – безопасность, надежность, производительность. Перспективы могут быть общими для многих представлений.
Архитектура - это базовая организация системы, воплощенная в ее компонентах, их отношениях между собой и с окружением, а также принципы, определяющие проектирование и развитие системы.
Структуры в архитектуре:
- статичные структуры – определяют то чем является проектируемая система (описание интерфейсов, аппаратного обеспечения, модулей и т.д.)
- динамические структуры – описывают как именно работает система, обычно эти структуры создаются и используются в рантайме.
Свойства системы - такие свойства, которые может увидеть или оценить внешний наблюдатель, воспринимая систему как черный ящик. То ради чего система создается.
Качественные характеристики – это целевые показатели системы, которые важны для разработки системы.
Архитектурные кандидаты – варианты организации архитектуры.
Архитектурные элементы – это элементы из которых состоит система.
Ключевые атрибуты архитектурных элементов:
- четко определенные обязанности
- четко определенные ограничения
- набор строго определенных интерфейсов, которые определяют сервисы для взаимодействия архитектурных элементов.
(автор Nick Rozanski, Eoin Woods)
Книга рассматривает три основные концепции, которые используются при построении архитектуры любой системы:
1. Stackholders (заказчики системы) – люди, которые принимают решения относительно того, какие функции должны быть реализованы, а какие нет
2. Viewpoins и view (представление) – это способ структурировать систему, дать описание каждого важного аспекта системы как самостоятельной сущности. Для построения представлений используется принцип «разделяй и властвуй». Каждое преставление описывает «что» должна делать программа или система, а так же взаимодействие и влияние представлений между собой.
Обычно через представления описываются «функциональная структура», «информационная организация», «среда развертывания» и т.д.
3. Perspective (архитектурные перспективы) это аналог представлений, но используются они для того чтобы описать «как» должна работать система. Обычно через представления описываются вопросы относящиеся к качественным характеристикам – безопасность, надежность, производительность. Перспективы могут быть общими для многих представлений.
Архитектура - это базовая организация системы, воплощенная в ее компонентах, их отношениях между собой и с окружением, а также принципы, определяющие проектирование и развитие системы.
Структуры в архитектуре:
- статичные структуры – определяют то чем является проектируемая система (описание интерфейсов, аппаратного обеспечения, модулей и т.д.)
- динамические структуры – описывают как именно работает система, обычно эти структуры создаются и используются в рантайме.
Свойства системы - такие свойства, которые может увидеть или оценить внешний наблюдатель, воспринимая систему как черный ящик. То ради чего система создается.
Качественные характеристики – это целевые показатели системы, которые важны для разработки системы.
Архитектурные кандидаты – варианты организации архитектуры.
Архитектурные элементы – это элементы из которых состоит система.
Ключевые атрибуты архитектурных элементов:
- четко определенные обязанности
- четко определенные ограничения
- набор строго определенных интерфейсов, которые определяют сервисы для взаимодействия архитектурных элементов.
Обычно архитектурные элементы – это компоненты или модули.
Для архитектуры так же справедливо правило «Быстро, качественно, недорого» - можно выбрать только два из трех.
Представления
Сама большая ошибка при разработке архитектуры проекта – создание сложных моделей, отвечающих и выполняющих все на свете. Таких перегруженных решений нужно избегать.
Правильное решение – декомпозировать систему на набор представлений.
Определять представления каждый раз при проектировании системы – бессмысленно, для переиспользования готовых решений можно применять паттерны, соглашения и другие наработки созданные в рамках представлений, которые в рамках книги называются viewpoint.
Преимущества использования идеи «архитектурных представлений»:
- разделение проблем
- управление сложностью
- упрощение коммуникаций со стекхолдером
- сфокусированность на проблема разработки
Подводные камни:
- несогласованность представлений
- неправильный выбор представлений
- фрагментация
Перспективы
Основные: безопасность, производительность, масштабируемость, доступность, устойчивость, эволюционность.
Для архитектуры так же справедливо правило «Быстро, качественно, недорого» - можно выбрать только два из трех.
Представления
Сама большая ошибка при разработке архитектуры проекта – создание сложных моделей, отвечающих и выполняющих все на свете. Таких перегруженных решений нужно избегать.
Правильное решение – декомпозировать систему на набор представлений.
Определять представления каждый раз при проектировании системы – бессмысленно, для переиспользования готовых решений можно применять паттерны, соглашения и другие наработки созданные в рамках представлений, которые в рамках книги называются viewpoint.
Преимущества использования идеи «архитектурных представлений»:
- разделение проблем
- управление сложностью
- упрощение коммуникаций со стекхолдером
- сфокусированность на проблема разработки
Подводные камни:
- несогласованность представлений
- неправильный выбор представлений
- фрагментация
Перспективы
Основные: безопасность, производительность, масштабируемость, доступность, устойчивость, эволюционность.