Андрей Трушкин – Архитектура цифрового мира (страница 12)
Если функционирование прикладной логики, реализующей соответствующие продукты, достаточно хорошо ложится на распределенную модель, то возникают вопросы, на какой же уровень переносится растущая сложность исполнения ИТ-решений. Выше уже отмечалось, что для сохранения состояния решений используются внешние по отношению к микросервисам хранилища данных. И вопрос функционирования данных хранилищ в распределенной конфигурации становится исключительно важным. Традиционные решения с централизованными базами данных оказываются слабо применимыми в современных условиях – несколько мощных вычислительных узлов попросту не доставят данные микросервисам за приемлемые временные промежутки. В случае, если речь идет о доступности ИТ-решений по дистанционным каналам, когда время отклика и предоставления услуг (по крайней мере, их части) должно составлять несколько секунд, таковые задержки недопустимы. Создание территориально распределенных кластеров традиционных решений по хранению данных также оказывается проблематичным – используемые такими решениями методы синхронизации и поддержания целостности данных зачастую оказываются несостоятельными в условиях значительной сетевой латентности. Соответственно, мир оказывается заинтересован в принципиально новых хранилищах информации. И такие хранилища, опять же, пришли из стартапов. Например, одно из самых популярных на сегодняшний день решений по построению распределенных баз данных Apache Cassandra было создано в Meta Platforms (ранее Facebook). Аналогично распределенные конфигурации предлагают IMDG решения, такие как Apache Ignite. Отметим, что приводимые примеры современных технологий являются решениями с открытым исходным кодом.
Современные распределенные платформы предполагают совершенно новый уровень производительности и надежности в распределенной среде. Безусловно, модель работы с информацией в данном случае отличается от моделей, принятых в соответствии с традиционными подходами предыдущих архитектурных поколений, синхронизация больших объемов данных в распределенной среде вносит свои ограничения. И здесь на помощь командам разработки приходит большое количество потенциальных топологий рассматриваемых решений. Благодаря глобальной цепочке разделения труда, актуальной для создания подобных технологических решений, становится возможным создать набор потенциальных конфигураций, количественный и качественный состав которого значительно превосходит то, что предлагалось традиционным «закрытым» программным обеспечением. Подобные технологические решения предоставляют новые возможности для проектирования программного обеспечения, но и предъявляют дополнительные требования к работе архитектора. Если ранее он мог ссылаться на известные топологии и лучшие практики (которых было достаточно ограниченное число) «закрытого» программного обеспечения, использовавшегося организацией, то теперь он должен ориентироваться в широком спектре современного открытого программного обеспечения, его возможных топологиях, а также лучших практиках применения последних. Создаваемые информационные системы должны подвергаться тщательному архитектурному анализу на предмет вариантов развертывания, доступа клиентов, сценариев использования, интеграционной составляющей. Результатом анализа станет выбор необходимого программного обеспечения для реализации, рекомендации по его использованию, направляющие по развитию для команд разработки.
Все сказанное касается не только хранения информации и использования распределенных СУБД. Платформа событийного обмена также должна обеспечивать возможность исполнения решений в распределенной конфигурации. Из современных решений первым кандидатом на подобную роль может считаться Apache Kafka, уже использующаяся в таких компаниях, как вышеупомянутый The New York Times, Linkedin, Uber, «Сбербанк России» и многих других. Решение изначально поддерживает распределенную топологию развертывания и предоставляет широкий спектр возможностей для «тонкой» настройки.
Поскольку микросервисы не сохраняют состояние между вызовами, они нуждаются в предварительной выборке данных для отображения пользователю необходимой ему информации, а также реакции на его запросы. Для обеспечения эффективного доступа к часто используемым данным обычно применяются технологии кэширования (IMDG), также поддерживающие распределенные топологии. Примерами могут служить упомянутый выше Apache Ignite или Infinispan.
Пример решения, представленный на Рисунках 13 и 14, не является исчерпывающим с точки зрения распределенного функционирования современных ИТ-решений. Например, для финансовой сферы актуально выполнение групповых операций, предполагающих проведение однотипных действий над огромными объемами данных. Примером такой операции может служить массовое начисление процентов по счетам. Современные технологии позволяют осуществлять выполнение подобных ресурсоемких операций в оперативной памяти на распределенных узлах обработки, при этом мощность каждого отдельного узла соответствует скорее продвинутому персональному компьютеру, а не гигантскому серверу, что представляет собой разительное отличие от традиционных подходов, стяжавших недобрую славу в профессиональном сообществе и по праву получивших наименование жаргонного типа «залить железом». Аналогичным образом данные могут храниться не только в распределенных базах данных, но и в распределенной файловой системе, что принципиально снижает стоимость хранения (крайне актуально при современном росте объемов хранимых данных).
Таким образом, мы видим, что на всех уровнях создания и развития программного обеспечения востребована концепция распределенного исполнения, под нее создается соответствующий технологический базис. Задача архитектора при этом – не только распределить границы областей разработки решения по продуктовым областям, но и предложить технологические платформы и их топологии, позволяющие максимально эффективно выполнять задачи ИТ-решения по мере реализации последнего. Одновременно учитывается возможность непредсказуемой нагрузки на решение посредством дистанционных каналов. Например, если финансовая организация предложит исключительно выгодный по меркам рынка продукт, каналом предложения которого и соответствующего приема заявок станет сайт компании (без требования регистрации, что выгодно отличает его перед, например, системами дистанционного банковского обслуживания, ДБО), то нагрузка на ИТ-ландшафт может резко возрасти за краткий промежуток времени. Создаваемая архитектура должна позволить решению сохранить корректность функционирования и качество предоставления услуг и при столь агрессивно возрастающей нагрузке.
Основываясь на вышеизложенном, можем отметить, что роль архитектора в рамках ответа на те вызовы, которые ставит перед архитектурой фактор распределенности, существенно изменилась. На сегодня необходимо обладать знанием широкого спектра программного обеспечения, рассчитанного на функционирование в распределенной гетерогенной среде, знать его основные топологии и сценарии их применения, погружаться в предметную область для качественной грануляции проектируемых информационных систем, позволяющей вести разработку силами распределенных команд. На сегодня архитектор – это не выделенный специалист, привлекаемый командами «по случаю», но лидер технологических изменений. Он задает ключевые направляющие создания, развития решений, а также их технологического наполнения.
Архитектура и бизнес-процессы
Важнейшей тенденцией развития архитектуры является ее способность обеспечить качественное и эффективное исполнение бизнес-процессов, актуальных для организации, автоматизация деятельности которой рассматривается.
Любая современная организация обеспечивает структуризацию своей деятельности на основании ее упорядочивания с последующим описанием и формирования бизнес-процессов, которые в удобочитаемом формате (например, в BPMN-нотации) обеспечивают наглядное и доступное описание выполняемых действий. При этом к бизнес-процессам обычно предъявляются требования по обеспечению возможности моделирования, определения этапа исполнения, а также задания количественных метрик (KPI), позволяющих проводить их анализ и оптимизацию.
Для обеспечения автоматизированного исполнения бизнес-процессов используются движки исполнения бизнес-процессов (BPM-движки), обеспечивающие следующие основные возможности:
• Моделирование процесса при помощи наглядных визуальных средств (полнота поддержки BPMN-нотации может варьироваться в зависимости от конкретного моделирующего средства).
• Задание связей, как выполняемых в рамках процесса действий, так и интеграций с внешними системами, которые ответственны как за непосредственное выполнение операций, так и могут предоставлять интерфейсы автоматизированных рабочих мест для выполнения задач пользователями (внутренними и внешними).
• Автоматизированное выполнение шагов процесса в соответствии с заданным алгоритмом.
• Назначение ролей, ответственных за этапы выполнения процесса.
• Определение метрик и KPI процесса и его составляющих, а также ролей, задействованных в процессе.
При этом в течение долгого времени BPM-движки представляли собой сложные платформы автоматизации монолитного характера, которые осуществляли управление всеми бизнес-процессами организации. Указанный подход содержал серьезные риски, которые затрудняли эффективное внедрение средств автоматизации управления бизнес-процессами: