Комментарии

Репликационный слот накладывает ограничение на перезапись wal. Т.е. пока данные из слота не прочитаны wal будет расти и при высокой нагрузке может очень быстро съесть все отведенное место на диске, с дальше сервер упадёт с ошибкой.

Создает, но меньшую. Намного меньшую.

А репликационный слот не создает нагрузки?

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

Нагрузка не может не увеличится, вы же как минимум выполняете операцию чтения WAL. Плюс сам инструментарий.

Познавательно для желающих реализовать репликацию данных. Сам писал собственный тул для реплицирования из SQLServer в PostgreSQL и Kafka на основе вычитывания данных из SQLServer Snapshot и последующим автоматическим переключением на живую SQLServer базу и считыванием изменений из CDC (LSN является ориентиром). Очень много подводных камней. Сейчас улучшаю перформанс первоначальной загрузки из snapshot и тесты показывают, что в разы вырастает скорость если считываю данные из snapshot в CSV, после через CopyIn в PostgreSQL с временным удалением индексов и primary ключей в PostgreSQL.

Решения для работы с распределёнными источниками

БД-источник может быть шардированной, как, например, Tarantool. Каждый из инструментов работает с такими БД по-разному.

— Debezium Embedded. Масштабирование выполняется по шардам и вручную, оффсеты хранятся в приёмнике для каждого шарда.
— Debezium Server. Масштабирование выполняется по шардам с помощью Kubernetes. Оффсеты хранят в файле, Kafka, Redis, приемнике для каждого шарда.
— Kafka-connect. Масштабирование выполняется по шардам с помощью тасков Kafka-connect — для каждого ReplicaSet запускается отдельный таск, который будет считывать данные. Оффсеты для каждого шарда хранятся в Kafka.

Главное из нашего опыта

— Зачастую к репликации высокие требования. Нам были важны скорость, отказоустойчивость, отсутствие дополнительной нагрузки. Исходя из этих требований мы выбрали механизм Change Data Capture, который удовлетворял всем основным критериям.
— Инструмент надо выбирать с учётом стека конечных пользователей. Наши заказчики часто работают с Java, поэтому, чтобы обеспечить совместимость решения, в качестве основы стека мы выбрали Java и Debezium.
— Монолитные приложения не всегда хороши. Debezium Embedded было сложно масштабировать и конфигурировать, поэтому мы перешли на Debezium Server. Это универсальное не монолитное решение, которое позволяет добавлять свои коннекторы и масштабироваться с помощью Kubernetes.
— Ошибки при создании инструмента для репликации неизбежны. Мы столкнулись с рядом проблем: высокий лаг, низкая отказоустойчивость, сложная архитектура. Каждый из недостатков нам пришлось устранять отдельно. Но тщательная доработка помогла нам получить инструмент, с помощью которого можно переливать данные из PostgreSQL в Tarantool с низким лагом репликации и сохранением консистентности.

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

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

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

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

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

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

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

Изъяны в данных могут привести к различным результатам. Например, клиенту Skyscanner Джеймсу Ллойду на пути из Крайстчёрча (Новая Зеландия) в Лондон предложили подождать в Банкоке 413 786 часов, или 47 лет. Эта история стала виральной благодаря чувству юмора SMM Skyscanner по имени Джен, ответившей на вопрос Джеймса о том, что он может делать все эти годы.

Использование ошибочных данных может приводить к трагическим событиям, особенно в медицинской сфере. Дэвид Лошин в статье The Practitioner’s Guide to Data Quality Improvement упоминает случай 2003 года с Джесикой Сантиллан, погибшей из-за некачественной сердечно-лёгочной трансплантации. Хирург использовал органы донора с несовместимой группой крови. Ошибочная информация о группе крови вызвала хирургические осложнения, приведшие к смерти.

Низкокачественные данные также могут препятствовать и замедлять интеграцию бизнес-аналитики и прогностической аналитики на основе ML. Руководители компаний США, участвовавшие в опросе Data trust pulse, проведённом PricewaterhouseCoopers, указали, что ненадёжные данные — одно из препятствий к монетизации данных. «Во многих из исторических данных компании, собиравшихся хаотически, могут отсутствовать нужные подробности и точность, необходимые для работы с ИИ и другими технологиями автоматизации», — говорится в результатах опроса.

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

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

Изъяны в данных могут привести к различным результатам. Например, клиенту Skyscanner Джеймсу Ллойду на пути из Крайстчёрча (Новая Зеландия) в Лондон предложили подождать в Банкоке 413 786 часов, или 47 лет. Эта история стала виральной благодаря чувству юмора SMM Skyscanner по имени Джен, ответившей на вопрос Джеймса о том, что он может делать все эти годы.

Использование ошибочных данных может приводить к трагическим событиям, особенно в медицинской сфере. Дэвид Лошин в статье The Practitioner’s Guide to Data Quality Improvement упоминает случай 2003 года с Джесикой Сантиллан, погибшей из-за некачественной сердечно-лёгочной трансплантации. Хирург использовал органы донора с несовместимой группой крови. Ошибочная информация о группе крови вызвала хирургические осложнения, приведшие к смерти.

Низкокачественные данные также могут препятствовать и замедлять интеграцию бизнес-аналитики и прогностической аналитики на основе ML. Руководители компаний США, участвовавшие в опросе Data trust pulse, проведённом PricewaterhouseCoopers, указали, что ненадёжные данные — одно из препятствий к монетизации данных. «Во многих из исторических данных компании, собиравшихся хаотически, могут отсутствовать нужные подробности и точность, необходимые для работы с ИИ и другими технологиями автоматизации», — говорится в результатах опроса.

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

Думаю Вам следует тщательно оценить Аврору, прежде чем рассматривать ее. Запустите экземпляр и настройте тестовый экземпляр вашего приложения и базы данных. Создайте как можно большую нагрузку. Я делал это в своей прошлой компании и обнаружил, что, несмотря на заявления Amazon о высокой производительности, Aurora потерпела сокрушительное поражение. На два порядка медленнее, чем RDS. У нашего приложения был высокий уровень трафика записи.

Наш вывод: если у вас есть вторичные индексы и высокий трафик записи, Aurora не подходит. Могу поспорить, что это хорошо для трафика только для чтения.

(Редактировать: тестирование, которое я описываю, было проведено в первом квартале 2017 года. Как и в случае с большинством сервисов AWS, я ожидаю, что Aurora со временем улучшится. У Amazon есть четкая стратегия: « Выпускать идеи на 70%, а затем повторять ». Отсюда мы должны сделать вывод, что новый продукт AWS достоин тестирования, но, вероятно, не готов к производству в течение как минимум нескольких лет после его представления).

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

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

Я сравнил экземпляр RDS в нескольких зонах доступности с набором реплик экземпляров EC2, управляемых Orchestrator. Поскольку для обеспечения кворума Orchestrator требуется три узла, RDS оказался здесь явным победителем по стоимости, а также по простоте настройки и эксплуатации.

Я искал лучшие практики по настройке базы данных в облаке, но мне до сих пор не ясно, какое из следующих решений нам следует использовать?

— Amazon RDS Аврора
— Amazon RDS MySQL
— MySQL в экземплярах EC2

Я считаю, что Amazon Aurora позиционируется как лучшая альтернатива, однако после некоторых исследований кажется, что люди ее не используют. Есть ли в этом проблема?

Архитекту́ра или зодчество, согласно википедии, это искусство и наука строить, проектировать здания и сооружения (включая их комплексы), а также сама совокупность зданий и сооружений, создающих пространственную среду для жизни и деятельности человека.

В той же википедии есть определения того, что такое программная архитектура

Архитектура программного обеспечения (англ. software architecture) — совокупность важнейших решений об организации программной системы, включающая в себя:

— выбор структурных элементов и их интерфейсов, с помощью которых составлена система, а также их поведения в рамках сотрудничества структурных элементов;

— соединение выбранных элементов структуры и поведения во всё более крупные системы;

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

Наиболее понятным, на мой взгляд, кажется определение, которое объединит эти два понятия:

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

Проще говоря, если мы решили использовать HEAD-FIRST подход (сначала думай, потом делай), то без проработки архитектуры нам не обойтись. Да и в ситуации, когда мы сначала всё сделали, а потом начали думать – к вопросу архитектуры мы тоже придем, только теперь с большим объемом кода, который надо переписывать.

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

Наиболее популярное сейчас деление архитектур (по опыту собеседований и общения с коллегами), это деление на монолитную архитектуру и микросервисную. На самом деле такое деление не совсем верно, поскольку:

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

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

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

Model-View-Controller (MVC, «Модель-Представление-Контроллер», «Модель-Вид-Контроллер») — схема разделения данных приложения и управляющей логики на три отдельных компонента: модель, представление и контроллер — таким образом, что модификация каждого компонента может осуществляться независимо.

— Модель (Model) предоставляет данные и реагирует на команды контроллера, изменяя своё состояние.

— Представление (View) отвечает за отображение данных модели пользователю, реагируя на изменения модели.

— Контроллер (Controller) интерпретирует действия пользователя, оповещая модель о необходимости изменений.

Model-View-Presenter (MVP) — шаблон проектирования, производный от MVC, который используется в основном для построения пользовательского интерфейса.

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

Model-View-ViewModel (MVVM) — шаблон проектирования архитектуры приложения, представленный в 2005 году Джоном Госсманом (John Gossman) как модификация шаблона Presentation Model. Ориентирован на современные платформы разработки, такие как Windows Presentation Foundation, Silverlight от компании Microsoft, ZK framework.

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

Про масштабируемость:

— Монолит — масштабируется не рационально(поднимаем всё) + не всегда возможно, если монолит изначально не писался с учетом масштабируемости

— Микросервисы масштабируются рационально (увеличиваем количество экземпляров только нужных сервисов.)

Вывод: если ваше приложении не разрастется (и Вы в этом уверены), у вас маленькая команда и сильно ограниченные ресурсы — смело выбирайте монолит.

Лайфхак: никто не догадается о том, что монолит, это монолит, если не допускать людей к кодовой базе! :)

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

Наиболее популярное сейчас деление архитектур (по опыту собеседований и общения с коллегами), это деление на монолитную архитектуру и микросервисную. На самом деле такое деление не совсем верно, поскольку:

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

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

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

Model-View-Controller (MVC, «Модель-Представление-Контроллер», «Модель-Вид-Контроллер») — схема разделения данных приложения и управляющей логики на три отдельных компонента: модель, представление и контроллер — таким образом, что модификация каждого компонента может осуществляться независимо.

— Модель (Model) предоставляет данные и реагирует на команды контроллера, изменяя своё состояние.

— Представление (View) отвечает за отображение данных модели пользователю, реагируя на изменения модели.

— Контроллер (Controller) интерпретирует действия пользователя, оповещая модель о необходимости изменений.

Model-View-Presenter (MVP) — шаблон проектирования, производный от MVC, который используется в основном для построения пользовательского интерфейса.

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

Model-View-ViewModel (MVVM) — шаблон проектирования архитектуры приложения, представленный в 2005 году Джоном Госсманом (John Gossman) как модификация шаблона Presentation Model. Ориентирован на современные платформы разработки, такие как Windows Presentation Foundation, Silverlight от компании Microsoft, ZK framework.

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

Про масштабируемость:

— Монолит — масштабируется не рационально(поднимаем всё) + не всегда возможно, если монолит изначально не писался с учетом масштабируемости

— Микросервисы масштабируются рационально (увеличиваем количество экземпляров только нужных сервисов.)

Вывод: если ваше приложении не разрастется (и Вы в этом уверены), у вас маленькая команда и сильно ограниченные ресурсы — смело выбирайте монолит.

Лайфхак: никто не догадается о том, что монолит, это монолит, если не допускать людей к кодовой базе! :)

Архитекту́ра или зодчество, согласно википедии, это искусство и наука строить, проектировать здания и сооружения (включая их комплексы), а также сама совокупность зданий и сооружений, создающих пространственную среду для жизни и деятельности человека.

В той же википедии есть определения того, что такое программная архитектура

Архитектура программного обеспечения (англ. software architecture) — совокупность важнейших решений об организации программной системы, включающая в себя:

— выбор структурных элементов и их интерфейсов, с помощью которых составлена система, а также их поведения в рамках сотрудничества структурных элементов;

— соединение выбранных элементов структуры и поведения во всё более крупные системы;

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

Наиболее понятным, на мой взгляд, кажется определение, которое объединит эти два понятия:

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

Проще говоря, если мы решили использовать HEAD-FIRST подход (сначала думай, потом делай), то без проработки архитектуры нам не обойтись. Да и в ситуации, когда мы сначала всё сделали, а потом начали думать – к вопросу архитектуры мы тоже придем, только теперь с большим объемом кода, который надо переписывать.

Напоминаю, что главная проблема Enterprise Architecture (ЕА) – это отсутствие конкретных примеров этой самой ЕА в открытом доступе. Алхимики их хранят «как зеницу ока», видимо потому, что если их публиковать, то откроется страшный секрет «платья короля» и все скажут: А король то голый!

В основном всем понятно, чем занимаются архитекторы решений, архитекторы по интеграции, системные архитекторы, но у многих возникают вопросы по поводу Архитекторов Предприятий, они же Enterprise Architects.

Архитектура предприятия (EA) — это практика проектирования, планирования и управления общей структурой и работой организации. Она связана с согласованием технологий, процессов и людей организации с ее бизнес-целями и стратегией.

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

EA часто используется для того, чтобы:

— Определять и документировать текущее состояние систем и процессов организации.

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

— Определять приоритеты областей для улучшения и модернизации.

— Убедиться, что инвестиции в новые технологии соответствуют бизнес-целям и стратегии.

— Способствовать общению и сотрудничеству между отделами и уровнями организации.

EA обычно включает в себя комбинацию подходов «сверху вниз» и «снизу вверх». Подходы «сверху вниз» включают в себя постановку целей высокого уровня и разработку плана их достижения, тогда как подходы «снизу вверх» включают сбор информации и отзывов от заинтересованных сторон по всей организации.

Существует несколько платформ и методологий, которые можно использовать для поддержки EA, в том числе Open Group Architecture Framework (TOGAF), Zachman Framework и Federal Enterprise Architecture Framework (FEAF). Эти рамки содержат общий словарь и набор принципов, которым должны следовать специалисты по АП, и могут помочь организациям обеспечить всеобъемлющий и последовательный характер их усилий по АП.

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

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

Open Group Architecture Framework (TOGAF) — это широко используемая структура корпоративной архитектуры (EA), которая помогает организациям проектировать, планировать и управлять общей структурой и работой своих систем и процессов. Разработанный и поддерживаемый The Open Group, глобальным консорциумом из более чем 600 организаций, TOGAF спроектирован так, чтобы быть независимым от поставщиков и масштабируемым, что делает его подходящим для организаций любого размера и в любой отрасли.

В основе TOGAF лежит метод разработки архитектуры (ADM), систематический подход к разработке и поддержке архитектуры предприятия. ADM состоит из ряда этапов, которые помогают организациям в процессе определения и реализации своего EA. Эти этапы включают:

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

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

— Этап C: Архитектура данных. На этом этапе рассматриваются требования организации к данным и информации, включая структуры данных и модели, необходимые для поддержки бизнес-процессов, источников и приемников данных, а также политик руководства и управления данными.

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

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

— Этап F: Возможности и решения. Этот этап включает в себя определение возможностей для улучшения и инноваций в архитектуре, а также разработку решений и дорожных карт для реализации этих возможностей.

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

— Этап H: Управление реализацией. Эта фаза касается руководства и управления архитектурой во время и после внедрения, включая создание процессов управления, мониторинг и измерение архитектуры, а также текущее обслуживание и развитие архитектуры.

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

Федеральная структура архитектуры предприятия (FEAF) — это структура, используемая федеральным правительством США для разработки и поддержки архитектуры предприятия (EA). Разработанный Управлением управления и бюджета (OMB), FEAF призван помочь агентствам федерального правительства привести свои технологии, процессы и людей в соответствие с их миссией и целями.

FEAF состоит из пяти основных компонентов:

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

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

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

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

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

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

FEAF поддерживается набором инструментов и ресурсов, в том числе Методом разработки архитектуры на основе FEAF (FEAF-ADM), который обеспечивает систематический подход к EA, и Методологией архитектуры федеральных сегментов (FSAM), которая обеспечивает руководство по разработке и поддержание архитектур сегментов, которые представляют собой специализированные структуры EA, ориентированные на определенные области или области правительства.

Zachman Framework — это инструмент, используемый для организации и классификации архитектуры предприятия. Это матрица, состоящая из шести строк и столбцов, где каждая ячейка представляет определенный аспект архитектуры. Строки представляют шесть вопросов «wh» (who, what, where, when, why, and how): кто, что, где, когда, почему и как; а столбцы представляют шесть категорий: контекста, мотива, масштаба, перспективы, реализации и эволюции.

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

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

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

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

На самом деле, помимо базовых трех существует много разных подходов.

Для проектирования высокопроизводительного адаптивного веб-приложения с помощью сервисов AWS можно следовать таким рекомендациям:
— Использовать Amazon CloudFront и Amazon S3 для размещения веб-приложения. CloudFront распределяет контент по глобальной сети кэширования, обеспечивая низкую задержку и высокую пропускную способность.
— Применить AWS AppSync для создания API приложений. Сервис позволяет развёртывать бессерверные серверные части GraphQL в облаке AWS и обеспечивает кэширование данных на стороне сервера.
— Использовать AWS MSK для получения различных событий из приложений-источников событий. Сервис потоковой передачи данных AWS предназначен для управления инфраструктурой и операциями Apache Kafka.

Для настройки производительности можно использовать следующие методы:
— Кэширование. 15 Например, кэширование в памяти и интеграция с сервисами AWS DynamoDB или Amazon ElastiCache помогут снизить нагрузку на API GraphQL и сократить время отклика.
— Пакетирование и свёртывание. Встроенные функции пакетной обработки и отложенной обработки AWS AppSync позволят объединить несколько запросов и мутаций в один запрос, сокращая задержку.
— Шаблон загрузчика данных. Его можно реализовать для пакетной обработки и кэширования запросов к базе данных, снижая нагрузку на базу данных и увеличивая время ответа.
— Регулирование и ограничение запросов. Это поможет предотвратить перегрузку API AWS AppSync и гарантировать справедливое использование и управление ресурсами.
— Сжатие. AWS AppSync предлагает возможность сжимать ответы API, повышая скорость загрузки и скачивания полезного контента.

Для разработки высокопроизводительного адаптивного веб-приложения с помощью сервисов AWS рекомендуется обратиться к специалисту.