Архитектура цифрового мира. Андрей Николаевич Трушкин

свою жизнь без Интернета, без сервисов, предоставляемых самыми различными компаниями как в региональном, так и в глобальном масштабе. Но любая медаль имеет обратную сторону – технологические решения, прорвавшись в жизнь человека, связали себя новыми требованиями – они должны быть доступны из любой географической точки и предоставлять неизменно высокое качество сервиса. В противном случае они станут неконкурентоспособными. Подобные требования являются исключительно важными с точки зрения архитектуры.

      Ранее по ходу настоящего раздела мы рассмотрели современные организационные, технические и архитектурные практики, применяющиеся для разработки современных ИТ-решений распределенными командами. Как же будут функционировать создаваемые таким образом решения? Например, решение, иллюстративно представленное на Рисунках 13 и 14, должно быть доступно всем юридическим лицам России (кроме, разумеется, тех, на кого наложены предписанные законом ограничения). Рассмотрим функционирование распределенного решения, принимая во внимание те архитектурные принципы, которые уже были предложены для его организации: микросервисная архитектура, продуктовый подход, практики EDA.

      Описанные ранее ключевые принципы микросервисной архитектуры имеют ряд следствий практического применения. Одним их них является то, что абсолютное большинство микросервисов проектируется и разрабатывается в формате stateless компонентов, то есть они не сохраняют свое состояние между вызовами – для выполнения данной функции служит внешнее по отношению к микросервису хранилище информации. Таким хранилищем может быть база данных, in-memory data grid (IMDG), платформа событийного обмена (и такие варианты реализации используются, например, The New York Times). С точки зрения самих микросервисов отсутствие сохранения состояния между вызовами позволяет создавать количество экземпляров микросервиса, необходимое для корректной обработки запросов, учитывая возможный рост числа последних. Отсутствие необходимости репликации сессий на уровне экземпляров микросервисов позволяет минимизировать внимание, уделяемое данному вопросу, и масштабировать микросервисы в допустимых инфраструктурой пределах. При этом крайне важным оказывается наличие располагаемых инфраструктурных мощностей для развертывания соответствующих программных компонентов в таких местах, где сетевая латентность не станет преградой для высокого качества сервиса. Например, финансовая организация, предоставляющая услуги в части продуктов по всей территории России, может быть заинтересована в нескольких центрах обработки данных, которые будут географически распределены.

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