Привет, меня зовут Дмитрий Марков. Я архитектор направления в Альфа-Банке. В этой статье мы поговорим об архитектуре, как ни странно. Без космических «прорывов» и «аналоговнет». Всё жизненно. 

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

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

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

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

Акт первый. Аналогии

Все мы с вами видели красивые архитектурные схемы. Многие читали монументальные труды о чистой архитектуре и таком же чистом, как слеза, коде. Спасибо великим (и не очень) авторам за то, что мы с вами уже имеем фактически описанный пазл с множеством паттернов и бесконечных оценок их применимости по месту жительства». А ещё ведь многие сотни конференций, где мы видим какие-то частные варианты использования тех или иных практик или же наблюдаем аргументированный отказ от шаблонов проектирования. В общем, мягко говоря, много всего имеем. Можно и глаза вывихнуть, и извилины ушибить…

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

• Итак, где-то в Подмосковье строитель Богдан пытается построить красивую парковку для авто на приусадебном участке. 

• Не так далеко от него, скажем, в Химках, плиточник Арсен озадаченно сидит на полу ванной комнаты, у которой все стены сильно не параллельны друг другу.

• В это же время в одном из высокотехнологичных бизнес-центров столицы сидит, нахмурившись, молодой и амбициозный ИТ-архитектор Василий, изрядно так обложившись любимыми трудами Фаулера и «дядюшки Боба» для воодушевления.

Всех их непоколебимо объединяет стремление быть профессионалом. Богдан вращает в руках пачку СНИПов дорожного строительства и благоустройства. Арсен обложился инструкциями производителя систем выравнивания плоскостей плитки. ИТ-архитектор Василий, конечно, знает и так всё наизусть, но не может понять, как так вышло, что в его хозяйстве 50 разных систем, из которых 15 уже вообще не поддерживаются, да и попутно в воздухе запахло предгрозовым импортозамещением.

Ну, давайте чуть ещё поразвлекаемся и поглядим, что там у нашего строителя Богдана на приусадебном. Перечитал он всю пачку документов и видит, что минимально предписанный уклон бетонного основания парковки составляет 2 см на метр, а то всё, хана — вода стекать не будет. Казалось бы, верная рекомендация именно для бетона, но представил Богдан свою площадку 20х20 метров и…

…и приуныл ????

Ну, что ж, можно понять. 40 см разницы высоты по краю или же 20-сантиметровое корыто по центру – так себе эстетический расклад. Но после некоторых раздумий Богдан, одержимый следованию рекомендации, придумал вариант секторальной плоскости со множеством перепадов. Бинго! Чистая архитектура площадки! Браво!

Однако после того, как он довел техническое задание до рабочих, они, к сожалению, куда-то пропали… Да и я, ваш покорный слуга, спасовал такой вариант отрисовать ☹

Рабочих, кстати, до сих пор ищут…

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

А что наш Василий? Он большинству читателей, вероятно, много ближе. Давайте посмотрим. У Василия тоже вот уже и мешки под глазами наклюнулись, да и сон стал какой-то прерывистый что ли. Не складывается идеально орнамент и у Васи. Итак, входим в его ситуацию. Какая задача у нашего архитектора?

Необходимо разработать архитектурный концепт, который позволит:

• освободить пользователей от ужасов работы с 50 разными системами и интерфейсами

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

• уменьшить зависимость от legacy

• расправить «извилины» интеграционных связей, провести оптимизацию

• удешевить и ускорить разработку, CI/CD, сопровождение в тех точках, где изменения происходят наиболее часто

• попутно купировать боли импортозамещения

Суровая реальность же примерно такая:

• По системам разный технологический стек. Солянка как на фронтах, так и на бэкенде.

• Используемые технологии местами сильно не актуальны, и системы невозможно оперативно доработать.

• Очень разные возможности интеграций как на межсистемном уровне, так и на уровне UI.

• Кто-то умеет работать с Kafka, кто-то нет. Кто-то поставляет нативный SDK для мобильных приложений, а какие-то системы умеют только Xamarin, к примеру, или же вообще никак не способны портироваться в рамки web или на iOS/Android.

• Также различны поддерживаемые способы аутентификации и авторизации.

• Добавляем исторически сложившуюся изоляцию на уровне разработки и поддержки каждой системы.

Так вот, и что делать нашему архитектору Васе? Как не попасть на абсурдную сложность проекта и поиски сбежавших рабочих, как у строителя Богдана? ???? Или как не потратить деньги впустую на технологии, которые неприменимы «по месту», как у нашего плиточника Арсена? ???? Я уж молчу про архитектурную документацию, из которой неизменно получается необъятный «Котопёс», если идти на поводу у имеющейся архитектуры.

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

Ну, нельзя подойти к прекрасному 300-летнему замку и угрожать ему применением принципов SOLID – понимаете, о чем я? ???? Ну, или к примеру – шептать ему в замочную скважину что-то про Domain-Driven Design, трясти у ворот авоськой с микросервисами. Пустое это. А замок тем не менее стоит и вполне себе прекрасен.

В крупных организациях класса Enterprise описанная выше проблематика не является редкостью. Скорее, это обыденный расклад, так как много всего накоплено и собрать пазл иногда не легко.

Доминирующим ИТ-законом, который объясняет, почему происходит именно так, на мой взгляд, является закон Конвея 1967-го году от роду. Он гласит следующее:

«Организации проектируют системы, которые копируют структуру коммуникаций в этой организации».

Именно отсюда шаг за шагом произрастают вот такие ситуации, в которой находится наш гипотетический архитектор Василий. И будь он трижды семи пядей во лбу — необходимо думать и искать разумный компромисс. Удачный же поиск компромисса обеспечивается обычно лишь опытом. И не спрашивайте меня, почему Enterprise-архитекторы зачастую не самые молодые люди ????

Акт второй. «Ближе к телу!» — как говорил Ги де Мопассан

Мы в Альфа-Банке также сталкиваемся со схожей проблематикой. У нас немало квалифицированных архитекторов, которые могут модно и красиво — «всё в уровень» ???? 

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

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

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

Попробуем графически пояснить, от чего бежим, зачем и в итоге — куда.

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

Правильно, это значит, что изменения будут делаться не только в соответствующих системных БД и API, но нам придется еще и рисовать кнопки в разных UI, писать для них код на разных языках, ну, и так далее. А ведь для этого нужно держать сведущих специалистов, а ещё хуже — на каждый чих заказывать разработку у вендора. Промолчим даже про то, сколько надо тужиться, чтобы доставить такой функционал ещё и на мобилу.

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

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

«Прекрасный план, Кэп!», — воскликнули участники тайного собрания ???? Так, и что нам это дает? Какая идеологическая основа? Какие принципы? 

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

• Компоновку продукта, контроль за ним, доступы – берем в одни руки.

• Отбираем игрушки у тех, кто не умеет ими играть. Даем взамен безопасные

• Отменяем крепостное право. Функция продукта <> Функция системы

• Освобождаем большинство трудящихся от аутентификации и авторизации

• Получаем возможность компоновать виджеты, не меняя сами сервисы

• Снижаем зависимость от бэковых бизнес-систем

• Адаптируем бизнес-системы для работы через Kafka. Убогим же выдаем удобные универсальные костылики.

В итоге в основу решения мы закладываем ряд простых технических принципов:

• Минимизируем и унифицируем точки контакта с пользователями. Буквально на раз-два

• Выделяем в архитектуре слой, где собираем и создаем все фронты и API. Единый стиль

• Сервисный слой приводим к единому стеку, оптимальному его задачам

• Выводим на передний план понятие сервиса и прячем корпоративные системы

• В сервисном слое закладываем готовность к смене бэкенда / системы

• Выбираем максимально открытый, простой и долгоиграющий стек технологий

• Держим курс на переиспользование готовых UI/API – микрофронтенды

• Упрощаем лапшу связей/интеграций, например, за счет событийной архитектуры

Такая вот предыстория революционного движения. Давайте теперь по мере возможности раскроем этот план слева направо. По ходу повествования местами будем делать корреляцию между «Было» и «Стало». Начнем с незатейливого серенького ромбика «auth/authz» с аутентификацией и авторизацией.

Он так и напрашивается, не правда ли? ????

Акт третий. Что вы тут нам навертели?!

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

«Как бы сделать так, чтобы потом ничего не делать?», – почти все рано или поздно думали об этом ???? Выглядит, как вполне веская причина пофантазировать, не правда ли? Ну вот, и мы такие же весельчаки. Стали придумывать, как приблизить наш концепт и решить все проблемы, да желательно «из коробки». В ходе долгих и продолжительных баталий, всяческих исследований и запросов на пилотирование, мы получили такую вот схемотехнику. Смотрим.

Уже несу таблетки. ???? Не расходимся, рано ещё.

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

Именно по этой причине мы видим на картинке «Стало» несколько более замысловатые узоры нежели на картинке «Было» ???? Однако особо пытливый читатель будет настаивать на пояснительной бригаде. Ок, затем и статья.

У нас все функции аутентификации и общей авторизации ранее выполнялись на импортном F5, благо у него имеется великолепное оснащение. Целый комбайн с редким скриптовым языком TCL. Но, как вы могли заметить, на картинке «Было» «товарищ майор» очень просил нас не завязываться в этом аспекте на импортное изделие, так как оно перестало оказывать нам дружественные знаки внимания. Смотрим на открытое ПО.

Вполне ожидаемо, что среди Open Source решений аналогов F5 не наблюдается. По этой причине нужно было декомпозировать его функционал. При этом мы очень хотели избежать каких-то глубоко ручных поделок и скриптов. Хотели перейти на свежие стандарты OIDC Oauth, а также очень хотели делать авторизацию к API/UI «из коробки».

И как раз-таки связка Keycloak+Gogatekeeper позволяет нам получить желаемое.

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

А вот Gogatekeeper забрал на себя ту часть, которую мы раньше частично держали на F5 и частично в самом приложении. Теперь же все микросервисы и само мобильное приложение освобождены от повинности инициировать аутентификацию и блюсти авторизацию.

Гейткипер пропускает через себя все запросы, и если они поступают без артефактов состоявшейся аутентификации, он её сам инициирует, перенаправляя приложение на Keycloak. Если же в запросах уже есть признак ранее пройденной аутентификации, то Гейткипер сверяется со своей сессионной «таблицей», а также коммуницирует с Keycloak для проверки валидности имеющихся в сессии токенов. 

Ещё стоит подчеркнуть, что токены передаются на Front в зашифрованном виде в рамках соответствующих кукисов.

Для тех, кто приуныл от обилия квадратиков и стрелок, а также от омерзительного слова «кукисы», предлагаю графическое резюме показанного ранее участка:

Что нам дает эта принципиальная наскальная схема? 

Итого:

• Приложение Alfa People легко сделать полностью универсальным – всех форм и видов (iOS/Anfroid + Web Internet + Web LAN ) без лишних overhead-ов

• Основной контент Alfa People – это WEB UI / API, реализуемые сервисами в Middle-слое. Вот всё это великолепие и защищается/управляется рассматриваемой обвязкой

• Вопросы аутентификации решены в одной манере для всех форм приложения

• Вопросы авторизации к UI / API решены также в одной манере «из коробки», и это уже не нужно делать в самом приложении и в слое микросервисов

• Возможность удобно приглядывать за опубликованными UI / API нам дарует API Gateway

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

Напомню, что мы очень не хотели писать какие-то свои системы аутентификации и авторизации и потом всё это весело поддерживать. Поэтому козлом отпущения в этом плане был выбран Keycloak, благо его удобно кастомизировать, что называется, «не отходя от мангала». 

Как итог – было решено создать в нем ветку для аутентификации кандидатов, для чего нам потребовалась интеграция Keycloak с рекрутинговой бизнес-системой. Таким образом, наш Keycloak черпает данные по сотрудникам из Active Directory, а по кандидатам берет данные из рекрутинговой системы. Всё, в общем-то, просто.

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

Далее внутри GoGatekeeper проходит авторизация, в ходе которой на основании ролей и признаков из токена принимается решение, пропускать далее такой запрос или нет. Понятное дело, что для кандидатов у нас в приложении Alfa People обустроена уютная Prelogin-зона, в рамках которой доступна только определенная группа UI / API.

Конечно, о каждом компоненте можно очень долго рассказывать, и никакой статьи на всё не хватит. Скажу, что в сети масса материалов конкретно по Keycloak, Gatekeeper и также по API-шлюзу Gravitee. В частности, есть относительно свежие статьи на Хабре. 

А вот конкретных раскладов маловато. Поэтому делаю акцент именно на этом.

Так-с. Помнится, несколькими картинками выше, там котик продирался сквозь API Gateway (можете посмотреть) и просил продолжения. Пришло время.

Акт четвертый. Гора родила мышь, а «умный» её обошел и пошел пилить сервисы

Тут будем говорить про Middle-слой, про наши сервисы. Кстати, а почему, собственно, Middle? Да потому что оно посередине между работающим фронтом и стаей корпоративных бизнес-систем. Всё просто.

Понимаете, в чем дело ???? В разделе выше мы весь свой стероидный функционал с платформы F5 Big IP декомпозировали и импортозамещали в стиле Open Source. 

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

И вроде, на наскальных схемах, как мог, упростил. Однако какой-то налет сложности имеется, да и сопровождение с DevOps недовольно бурчат. И бизнес-пользы-то от этого «синхрофазотрона», по сути, около плинтуса. «Гора родила мышь», – скажете вы, но, тем не менее, это архиважнейший кусок архитектуры! 

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

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

Область, в которой мы формируем продукт – то, что задает конечный образ результата. Другими словами, это именно тот слой, который нам позволяет абстрагировать пользователя от суровых бизнес-систем и их особенностей. И это именно то место, которое постоянно меняется, где постоянно что-то креативят.

Неудивительно, что для организации Middle-слоя мы выбрали Kubernetes, так как, по сути, концептуально решили, что будем делать эту историю на базе микросервисов. Почему мы так решили? Ну, ровно по той причине, что разных команд у нас с десяток, и все рвутся в бой решать свои специфические задачи. Также напомню, что мы хотели иметь возможность компоновать и переиспользовать различные UI, используя технологию микрофронтендов. Хороший Time To Market хотели, бесшовный деплой хотели, да и много чего ещё, о чем писали выше. Всё это, понятно, удобнее делать, придерживаясь определенной атомарности функционала.

На чем писать микросервисы, какой стек? Этот вопрос, конечно, нас также посещал. Соображения были следующие. С одной стороны в банке очень мощный центр экспертизы Java, с другой стороны – не сильно уступающая экспертиза и по JS. Вспоминаем о желании экономить вычислительные ресурсы и в параллель оцениваем характер задач. А, собственно, какой характер то?

А характер такой, что в 99% случаев мы ничего не вычисляем, никакие циклы не гоняем, а также не перемалываем in-memory гигабайты информации. У нас направление автоматизации клиентского пути сотрудник/кандидат. Наша задача – сделать жизнь сотрудника красивой и удобной: дать ему новости, облегчить рутину, помочь оформить справки, заявки, уйти в отпуск и т.п. 

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

Из озвученного круга задач становится понятно, что нам выгоднее построить всю эту тему на базе JS (TypeScript), охватив им как UI часть, так и Back for Front. То есть мы пришли к такой модели, что подавляющее большинство наших сервисов — это пары из двух контейнеров: в одном торчит фронтовая сборка, в другом торчат API, которые необходимы для решения поставленной задачи. 

Сама же типовая задача сводится к следующему:

• Отобрази прекрасный UI

• Принимай запросы от UI и сопроводи их к соответствующему API

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

Исходя из вышесказанного, остановили свой выбор на React.js и Node.js. В части фреймворка поверх Node.js мы выбрали NestJS (не путать с Next). В банке есть опыт использования фреймворка Hapi, однако с благословения центра экспертизы JS мы взяли на борт именно NestJS и не разу не пожалели о содеянном. NestJS позволяет создавать зрелую архитектуру JS-приложения, хорошо понятную также и Java-разработчикам. Ещё раз подчеркну, что наш материал носит обзорный характер, и в этих рамках останавливаться подробно на сравнении фреймворков просто не хватит букв ????

В итоге имеем сплошной JS в основе. Получаем возможность ротации по командам. Друг спас жизнь друга и всё такое прочее. Фронт-разработчики понимают, что внутри BFF и наоборот. Все могут оперативно включиться фактически на любом этапе, от разработки и ревью до поддержки. Это удобно, и всё делается довольно быстро. При всём при этом сервисы легковесны, и продуцируемый ими UI бесшовно доступен как в браузере, так и в мобильной версии Alfa People.

Вот, собственно, примерно так выглядит основное наполнение сервисного кластера Kubernetes, который и является нашим Middle-слоем.

Вы, возможно, скажете: «А где же данные микросервисов и всё такое прочее?». С другой стороны наверняка кто-то заметил на картинках выше, что внизу сервисного кластера таки есть Mongo, Minio, Redis. Однако в нашем случае эти хранилища не предназначены для бизнес-данных, а если так можно сказать, являются операционными. Да, действительно, в некоторых случаях они используются и для хранения состояния сервиса, и какие-то порции бизнес-данных через них проходят. Но это в основном происходит с Mongo, ибо у неё есть удобная опция – задавать срок жизни, по истечении которого данные благополучно аннигилируются ????

Опять же не буду тут читать унылые лекции про то, как именно эти «БД» используются, но я думаю, и так понятно, что мы руководствовались принципом «Кесарю кесарево». Если кратко, то в Mongo настройки и состояния сервисов, а также различные расклады для реализации функций back for front. По Minio и Redis: ну, тут стандартно, в одном всякие статичные файлы, а в другом кэши. К слову сказать, GoGatekeeper тоже использует Redis в технических целях для хранения сессионной информации.

А тем временем мы с вами уже близки к подведению итогов.

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

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

Самое время вспомнить начало статьи, где реальность обычно подталкивает к поиску компромиссов. Зачем и кто станет разбирать прекрасные средневековые замки? Вот-вот. И мы просто научились всё это вкусно готовить ????

Давайте ещё раз окинем взглядом все основные слои, которые мы «взяли в оборот»:

Акт пятый. Брутальный. Подводим итоги

Единым каналом взаимодействия с пользователем мы сделали корпоративное приложение для сотрудников, которое называется Alfa People. Наши пользователи – это все сотрудники банка, а также кандидаты, весело тусующиеся в специальной прелогин-зоне. Про Alfa People и прелогин-зону у нас, кстати, есть самостоятельные материалы:

• Как мы создали Digital Workplace для сотрудников

• Как менять работу без стресса: идём в гости в компанию через прелогин

Alfa People существует как в виде классического мобильного приложения Android/iOS, так и в виде корпоративного портала под Web browser, разумеется, с доступом также из интернета.

Конечно же, мы сделали всё таким образом, что сервисы, которые доступны в рамках мобильного приложения – это те же сервисы, что пользователь использует внутри корпоративного портала ????

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

Также мы создали сервисный Middle-слой + API Gateways и создали выделенный сервисный кластер под управлением Kubernetes. Внутри кластера работают микросервисы, выдающие тематический фронт и реализующие API. Наши микросервисы в основном относятся к классам: Front/Middle/BFF.

Стек наших сервисов: Frontend на NGINX+React.js, Middle(BFF) – Node.js (NestJS).

Активно используем концепцию микрофронтендов (Module Federation): на одном экране соединяются несколько веб-приложений и виджетов.

Шлюзы же мы исполняем таким образом, чтобы освободить разработчиков микросервисов от таких вопросов, как аутентификация и авторизация. Это сильно упрощает и ускоряет разработку в целом. Как описывал выше, прикрутили и SSO OIDC(OAuth 2) с использованием связки Gatekeeper/Keycloak->Gravitee.io. 

Gravitee используем как элемент управления и контроля за используемыми API. Не подразумеваем сколько-либо заметной кастомизации компонент (кроме Keycloak), дабы не впадать в сильную зависимость и иметь возможность переехать на аналогичные решения.

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

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

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

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