3.0 Введение к части 3: Системы

Архитектура это набор решений, которые дорого обращать. Как разбить систему на части? Как эти части общаются между собой? Как моделируются данные? И как вся система ведёт себя под нагрузкой и при отказах? Часть 3 о том, как принимать эти решения намеренно. В небольшой команде архитектура может жить в нескольких головах и развиваться по ходу дела. В большой организации (сотни инженеров, десятки команд, системы, которые переживут карьеры строящих их людей) архитектура становится тем, что удерживает всех согласованными. Когда она ясна, команды двигаются независимо, не сталкиваясь. Когда она расплывчата, каждая межкомандная зависимость превращается в переговоры, а каждый инцидент в археологический проект.

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

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

Главы этой части

• 3.1 Основы архитектуры. Долговечные инструменты, переживающие технологическую моду: атрибуты качества («-ости»), архитектурно значимые требования, функции пригодности (автоматические тесты, охраняющие выбранное архитектурное качество) и эволюционная архитектура, лёгкая документация с моделью C4 (вложенные архитектурные диаграммы на четырёх уровнях приближения) и arc42 (шаблон архитектурной документации) и структурированный анализ компромиссов.

• 3.2 Архитектурные стили и паттерны. Обзор основных форм систем от монолита через микросервисы, событийно-ориентированные архитектуры с CQRS (Command Query Responsibility Segregation, разделяющим модели чтения и модели записи) и событийным хранением (хранением состояния как журнала событий только для добавления), сервисную сетку (выделенный инфраструктурный слой для связи между сервисами) и шлюзы, бессерверные вычисления и гексагональную и чистую архитектуру, с указаниями, когда каждая подходит, в рамке закона Конвея (системы склонны отражать структуру коммуникаций организации, которая их строит).

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

• 3.4 Архитектура данных и хранение. Как данные моделируются, хранятся, поддерживаются согласованными и быстро отдаются в масштабе: основные парадигмы хранения и когда использовать каждую, полиглотная персистентность (использование нескольких специализированных хранилищ данных в одной системе), эволюция и миграция схем, кэширование и CDN (сети доставки контента), а также транзакции и конкурентность под нагрузкой.

• 3.5 Масштабируемость, производительность, устойчивость. Три различных качества, закладываемых в проект, а не дооснащаемых: горизонтальное и вертикальное масштабирование, отсутствие состояния и шардирование (разделение данных по машинам по ключу), балансировка нагрузки и автомасштабирование, бюджеты производительности, паттерны устойчивости и хаос-инженерия и многорегиональное аварийное восстановление в рамке RTO (целевого времени восстановления) и RPO (целевой точки восстановления).

• 3.6 Модернизация унаследованных систем. Постепенные паттерны, которые действительно работают: «душащая фига» (выращивание новой системы вокруг старой, пока старую не станет возможно вывести) и ветвление через абстракцию (замена компонента за интерфейсом в основной линии разработки), плюс оценка рисков наследия, управление мейнфреймами и COBOL (Common Business-Oriented Language), миграция данных и параллельная работа и как противостоять соблазну большого переписывания, порождающему самые дорогие провалы в отрасли.

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

• 3.8 Совместимость и открытые стандарты. Проектирование систем так, чтобы они взаимодействовали через открытые стандарты, а не самодельные интеграции: техническая, синтаксическая и семантическая совместимость, предметные стандарты вроде FHIR в здравоохранении и цена проприетарной привязки.

• 3.9 Системная инженерия. Инженерия сложных систем от начала до конца, часто объединяющих программы, оборудование, людей и процессы: жизненный цикл, распределение и прослеживаемость требований, интерфейсы, интеграция, верификация и валидация.

• 3.10 Встраиваемые системы и системы реального времени. Программы для устройств в жёстких ограничениях: поведение реального времени и детерминизм, RTOS или прошивка «на голом железе», ограниченные память и питание, взаимодействие с оборудованием и стандарты критичных для безопасности систем.

• 3.11 Облачная архитектура. Проектирование для облака вместо переноса центра обработки данных «как есть»: модели обслуживания и бессерверные вычисления, регионы и зоны доступности как домены отказа, модель общей ответственности, компромиссы управляемых сервисов и привязки, мультиоблако и гибрид, когда они оправдывают свою сложность, и проектирование с учётом стоимости и хорошо спроектированного (well-architected) подхода.

• 3.12 Событийно-ориентированная архитектура и обмен сообщениями. Построение систем, общающихся созданием событий и реакцией на них: очереди против долговечных потоков, хореография против оркестровки, событийное хранение и CQRS там, где они оправдывают себя, саги для распределённых транзакций, гарантии доставки и идемпотентность и паттерны, удерживающие асинхронные потоки надёжными.

• 3.13 Сети и связность. Сети, с которыми на самом деле имеет дело прикладной инженер: DNS, TCP и эволюция HTTP, терминирование TLS, балансировка нагрузки и обратные прокси, доставка контента и край, обнаружение сервисов и сервисная сетка, а также тайм-ауты, повторы и предохранители, делающие ненадёжность сети переживаемой.

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

• 3.15 Кэширование и доставка контента. Размен небольшой устарелости на большой выигрыш в задержке, нагрузке и стоимости по иерархии кэшей (клиент, край и CDN, обратный прокси, приложение и хранилище данных) при воспринимании инвалидации кэша и защиты от лавин как первоклассного проектирования.

• 3.16 API-шлюзы и сервисная сетка. Обработка трафика «север-юг» на API-шлюзе (маршрутизация, аутентификация, ограничение частоты, композиция) и трафика «восток-запад» через сервисную сетку (взаимный TLS, переключение трафика, повторы, наблюдаемость) и решение о том, когда сетка оправдывает свою сложность.

• 3.17 Поиск и информационный поиск. Воспринимание поиска как первоклассной системы, от инвертированного индекса и ранжирования по релевантности до понимания запроса, фасетов и векторного и гибридного поиска, с настоящей оценкой релевантности, а не гаданием.

Как эти главы связаны между собой

Главы строятся друг на друге по порядку. Глава 3.1 даёт словарь (атрибуты качества и анализ компромиссов), которым пользуется каждая последующая глава; названные в ней «-ости» это именно то, что главы 3.4 и 3.5 делают конкретным. Глава 3.2 превращает эти основы в структурные выборы, а более распределённые стили, которые она одобряет (микросервисы, событийно-ориентированные, сервисная сетка), несут издержки, управлять которыми учит глава 3.3. Главы 3.3, 3.4 и 3.5 сильно опираются друг на друга: распределённость вынуждает к решениям о согласованности и долговечности архитектуры данных, а вместе распределённость и данные определяют, какой масштабируемости и устойчивости вы реально можете достичь. Глава 3.6 замыкает круг, потому что большинство больших организаций строят не на чистом листе: они развивают системы записи, ограничивающие каждый выбор, описанный в предыдущих главах.

Часть 3 также тянется наружу. Глава 3.2 опирается на принципы проектирования и предметно-ориентированное проектирование главы 2.2, чтобы находить хорошие границы сервисов. Эксплуатационные дисциплины, поддерживающие работу этих систем, живут в части 9: инженерия надёжности сайтов (глава 9.1) и наблюдаемость (глава 9.2) это место, где архитектурная устойчивость доказывается в эксплуатации. Свойства безопасности и приватности, которых требуют регуляторы, проектируются здесь, но детально описаны в части 4, а платформенные практики и практики поставки из части 8 решают, может ли архитектура действительно быть выпущена и эксплуатироваться многими командами одновременно.