Архитектура мобильного приложения в разрезе высоких нагрузок и построения экосистем
Привет, Хабр! Меня зовут Валерий Разномазов, я системный аналитик в РСХБ. Сегодня поговорим про архитектуру мобильного в разрезе высоких нагрузок и построения экосистем. В этой статье я собрал свой 10-летний опыт по этому направлению и готов его обсудить с вами.
Предисловие
Архитектура — это набор правил, которые принимают все участники обмена данными в рамках проектируемого мобильного приложения. В энтерпрайзе термин «мобильное приложение» означает один из возможных видов фронта для получения и отправки данных пользователю.
Энтерпрайз — это архитектурная парадигма, в рамках которой происходит цифровизация крупной компании, характерная тем, что происходит объединение в единое целое абсолютно не связанных непосредственно друг с другом бизнес‑процессов. Любой банк — это энтерпрайз. Все баги и фичи, которые вы видите в мобильном приложении банка, являются следствием невидимых пользователю процессов, идущих в деловом обороте. Каждый банк уникален, а попытки внедрить приложение одного банка в деловом обороте другого банка всегда вызывают улыбку.
«Экосистема» — это метафора, означающая, что ИТ‑решения, созданные в рамках цифровизации различных бизнесов, объединяются в единое целое. Продолжая метафору из науки о живом, давайте метафорически в разрезе архитектуры поговорим процессе выживания сильнейшего.
Какая наука о живом без вопроса о Творце? Однозначно отвечаем на этот вопрос — Бизнес делает ИТ, а не ИТ делает Бизнес, поэтому каждая архитектура в той или иной степени уникальна. По нашему мнению, прочесть исходный замысел можно через концепцию Design First, а также через такой артефакт, как рабочие чаты, в которых решаются вопросы делового оборота. Если рассмотреть их в разрезе построения онтологической модели и DDD, то дизайн, нарисованный заказчиками (часто даже простыми карандашами), и JSON с выгрузкой рабочих чатов для последующего лингвистического анализа становятся ценнейшими элементами для понимания необходимой архитектуры.
Параллели законов развития ИТ с законами животного мира
Проектируя архитектуру ИТ-решения, важно осознать, что оно не может и не будет существовать само по себе. Подобно представителю флоры или фауны нашей планеты, оно обязательно должно влиться в существующую экосистему и наладить обмен информацией с другими представителями этого «ИТ-ценоза». Если вливание в существующую экосистему не происходит, то ИТ-решению приходится порождать свою.
Мы уже неоднократно убеждались, что универсальное, пытающееся вместить в себя все процессы решение неизбежно умрет, так как не сможет вместить в себя все информационные потоки, поэтому нахождение вне исторически сложившегося в данной предметной области информационного обмена и делового оборота для него смертельно. Рассуждая в таком ключе, можно сказать, что закладка в архитектуру принципов открытой архитектуры (API First) становится центральным понятием в проектировании архитектуры.
ИТ-ценоз. Нет смысла проектировать универсальное ИТ-решение. Важно занять свою нишу и помнить, что ИТ-решения находятся в постоянном обмене данными друг с другом
Если в эпоху SOA мы и объединяли различные решения в рамках одного бизнеса, то сейчас мы объединяем уже различные бизнесы под одним флагом (как правило, крупной компании). Думаю, что любой из читателей сталкивался с существующими ИТ-экосистемами, построенными по подобному принципу.
В РСХБ также складывается своя крупная и уникальная экосистема. Нами разрабатывается ряд мобильных приложений не только для клиентов физических или юридических лиц, но и для владельцев бизнесов в сельском хозяйстве. Так, например, в нашей экосистеме есть отдельные внутрибанковские решения для сопровождения внутренних кадровых вопросов и подбора персонала, а также разрабатывается мобильное приложение для студентов с предложениями карьерных треков. Проведя детальный анализ технологий и тенденций, а также множество экспериментов, хотим сказать, что идеального стека технологий не существует.
Рассказ про ИТ-экосистемы в свете вышесказанного можно подытожить выделением трех тезисов:
подготовка неких общих API для интеграции,
разработка единых правил авторизации и аутентификации,
выделение единого бизнес-слоя (бека для всех фронтов).
Другим важным аспектом при проектировании архитектуры является феномен Highload. Если возвращаться к аналогиям с животным миром, то можно вспомнить: выживает не сильнейший, а способный лучше остальных приспосабливаться к изменениям, то есть по-нашему масштабироваться. Тут важно вспомнить о другом накладывающем отпечаток на архитектуру явлении — Highload.
Highload — это состояние системы, при котором масштабироваться горизонтально оно не может. Происходит это не столько из-за недостаточной производительности сервера, сколько из-за рассинхронизации по таймингу. Все больше процессов завершаются, не дождавшись необходимого ответа данных от мастер-системы. То есть, если нет необходимых нам данных, мы будем получать какую-то из 400 ошибок и постоянно уходить на 2-й круг запроса, ожидая, что данные там появятся. Высокие нагрузки, в свою очередь, выдвигают свои требования:
уменьшение количества точек интеграции,
уменьшение времени получения кортежа данных из хранилищ.
Иллюстрация рассинхронизации по таймингу. Потребитель делает несколько запросов, чтобы получить данные от поставщика. Время задержки — время ожидания данных
Артефакты и их влияние на интеграцию
Архитектуру важно не только правильно спроектировать, ее надо еще понятно приподнести желающим интегрироваться. Понятные артефакты — это уже центральное понятие аналитики. 30 лет энтерпрайза показали, что страница в вики системе типа confluence (как любое текстовое описание) при технической интеграции — плохой артефакт.
Давайте рассмотрим эту ситуацию на простом жизненном примере. Часто бывает, что при строительстве нового объекта (например, подземного перехода) в земле находят какие-то черепки, скрижали, предметы культа. Приезжают археологи и историки, несут все найденное физикам с их высокочувствительной аппаратурой, и никто не может дать ответ, чьи это артефакты и к какой цивилизации их отнести. Потратив годы на исследования, ученые так и не смогут определить, какой культуре принадлежит найденное. Все очень просто: найденный народ не внес никакого вклада в мировую культуру, говорил на непонятном языке, имел непонятную письменность, был закрыт от других народов и агрессивно отстаивал свою идентичность.
Так же и у нас. Смотришь на реестр систем и видишь какие-то непонятные идентификаторы, идешь к архитектору, а он начинает морщить лоб и вспоминает, что лет 5 назад в банке работала команда, которая вывела в прод систему, которой никто не пользовался. Почему? Из-за непонятных API и отсутствия удобоваримой документации.
Почему это происходит часто? Дело в том, что, когда мы говорим «энтерпрайз», мы подразумеваем большое количество специалистов разного профиля, которые трудятся над решением одной бизнес задачи. Основной вызов — это проникновения социальных наук в техносферу. Люди разного склада мышления думают по-разному, а значит изначальная бизнес идея при движении от заказчика к разработчику претерпевает большие изменения. Для избегания подобной ситуации, необходимо создавать единые модели данных, которые бы лежали в основе закладываемой архитектуры. В данном случае, чтобы сохранить порядок и уменьшить время на разработку, необходимо применять объектно-ориентированные подходы. Едва ли не единственным способом удержать разработку в рамках модели данных является DDD, а прийти к DDD можно только через онтологию, которая, в свою очередь, является универсальным средством разметки предметного поля. Единая модель данных должна отражаться во всех артефактах, остающихся от проектирования архитектуры.
Трехзвенная архитектура сквозь экосистемы и Highload
Архитектура всегда предполагает наличие фронта, бека и хранилища. И если раньше мы использовали примерно одинаковые по свойствам решения, отличающиеся только тем, что их разрабатывали разные вендоры, то теперь мы должны реагировать на Highload. Можно заявить, что злейшими врагами высоких нагрузок в энтерпрайзе являются:
Реляционные связи
Оркестрация
Тайминговые параметры, рожденные из-за асинхронных взаимодействий и плохо настроенных таймаутов.
Поэтому, когда возникнет явление Highload, мы вынуждены отойти от традиционных подходов с использованием реляционных связей между таблицами (SQL) на стороне баз данных в сторону noSQL и newSQL (использовав формат JSONB в Posgres), а также учитывать количество подключений между микросервисами и тайминг асинхронного сбора информации между сервисами.
Если раньше выделенный по Мартину Фаулеру бизнес-слой (он же бек) брал на себя всю бизнес-логику, то сейчас мы так уже нельзя сказать. Любую логику можно реализовать и на фронте (применяя, например, Ajax), и на беке, и в базе данных (PLSQL).
Ускорить работу реляционных баз данных тоже можно. Что если наиболее часто используемую беком логику реализовать в виде хранимых процедур или посредством языка plSQL? Реализуя такие подходы (речь идет о паттерне Data Base Engine), нужно быть уверенным, что выигрыш от реализации вычислений базой данных не съест плохо организованное соединение базы с беком.
Описанные средства повышения производительности нужны далеко не всегда. Чтобы оценить возможность появления высоких нагрузок, нужно предварительно оценить метрики MAU и DAU. Для оценки этих метрик необходимо построить ролевую модель в рамках объектно-ориентированного подхода. В условиях предприятия можно поднять информацию о том, сколько пользователей имеет ту или иную роль.
Хранилище данных
Чем выше нагрузка, тем чаще мы прибегаем к организации хранилищ на основе подходов noSQL. Считается, что SQL и соединение к таким базам тяжелее из-за организации реляционных связей. Вытягивать весь объект целиком, как позволяет noSQL, проще. Интересен также подход newSQL, при котором в реляционной базе объекты хранятся в формате JSONB.
Ускорить работу реляционных баз данных можно. Что если наиболее часто используемую логику реализовать в виде хранимых процедур или посредством языка
plSQL? Прибегая к таким подходам нужно быть уверенным, что выигрыш от реализации вычислений базой данных не съест плохо организованное соединение базы с беком.
Если раньше при проектировании базы мы закладывали модель данных на уровне таблиц баз данных, руководствуясь принципом «один объект — одна таблица», то как быть с соблюдением модели данных при использовании noSQL концепции? Если вы используете noSQL, то модель данных можно заложить в YAML или в JSONSCHEMA.
Семантика — главный драйвер архитектуры
Чем больше наша команда занимается проектированием, тем чаще становится понятно, что понимание архитектуры ИТ-решения зарождается еще в момент бизнес-анализа. Если ИТ-ландшафт у нас развит до современного уровня, значит мы работаем в парадигмах SOA или MSA и определяем границы сервисов или микросервисов через доменную модель в рамках DDD. В таком случае бизнес-анализ дает нам концепцию предметного поля. DDD, в свою очередь, требует концептуального подхода к аналитике: определения субъектов, объектов делового оборота и связей между ними. Такой подход еще называется построением онтологической модели предметной области.
Что дальше делать с онтологической моделью? Она бесполезна, если не воплощена в какую-то из признанных технологических нотаций. Другими словами, как через онтологию прийти к DDD? Понятной нотацией может быть хорошо известные YAML или JSONSchema. Если руководствоваться той парадигмой, что граница микросервиса определяется границей домена, то разметка предметного поля является основой для построения архитектуры.
Архитектура рождается из модели данных
Невозможно описать все бизнес-процессы. Описать все бизнес объекты же вполне возможно. Практики сбора требований и аккумуляции их вне какой-то системы ведут к «семантическому безумию» в ИТ-системе. Попытки интегрироваться с такой системой будут мучительными: API будут неясными, одна и та же бизнес-сущность будет размыта по нескольким таблицам и нескольким конечным точкам. Скорее всего, такая система перестанет существовать. Чуть ли не единственным способом построить понятные API является объектно-ориентированный подход.
Субъекты, Объекты и связи между ними
Так как каждый объект должен быть предоставлен каким-то сервисом, и нам нужно эти сервисы проектировать, прежде всего надо разметить предметное поле. Чтобы это сделать, нужно задать три вопроса: Что? Где? Когда?
Собственно, когда ответы на эти вопросы будут получены, будет ясен состав субъектов, объектов, связи между ними, атрибутивный состав и тайминг — все и есть бизнес-анализ. Имея такую информацию, системный аналитик проектирует сервисы, хранилища и протоколы передачи. Итогом разметки является такое вот своеобразное кредо, которое по форме напоминает формулу изобретения при патентовании. Вот эту формулу можно нести на груминг бизнесу и отдавать в работу системным аналитикам.
Опять же, приведу пример не из IT. В 60-е годы в СССР весьма успешно строили атомные подводные лодки. Внедрение атомной силовой установки заставляло готовить экипажи к принципиально новым аварийным ситуациям. Конструкторы пошли на 2 существенных новшества. Во-первых, всех командиров боевых частей разместили в одном отсеке (что доказывает, что Agile работал еще в 60-е годы). А во-вторых, осознав что аварийные ситуации в каждом боевом походе могут быть уникальными, бросили пытаться писать аварийную инструкцию на каждую возможную ситуацию. Вместо этого, инженеры начали описывать все механизмы и их состояния как внутри прочного корпуса подводной лодки, так и в каждом отсеке по отдельности. То есть, при возникновении аварии, моряки, зная какие агрегаты затронуты, могли оценить и предсказать их состояние в соответствии с развитием ситуации. Можно сказать, что подобными идеями руководствуются уже в ИТ-архитектуре. 15 лет назад был предложен паттерн ограничить контейнером набор бизнес-объектов, с которыми ведется работа для микросервисной архитектуры.
Дизайн как предтеча архитектуры
Не могу в своем материале не коснуться проектирования дизайна. Что если мы проектируем от интерфейса? Я считаю его полноценным элементом архитектуры. Плохо спроектированный дизайн влияет на работу и нагрузку приложения. Поэтому, когда вы проектируете интерфейс, необходимо задать себе вопрос:, а какие объекты участвуют в бизнес процессе, который мне необходимо отразить? От этого будет зависеть то, какие REST вызовы вы будете совершать со всеми вытекающими отсюда последствиями. Чтобы набросать интерфейс, необходимо построить «намерение», то есть оценить те бизнес-объекты, которые будут в нашем бизнес-процессе участвовать.
От Дизайна к архитектуре. Одним из способов проектирования архитектуры является проектирование предполагаемого клиентского пути в интерфейсе самим заказчиком. Когда ясен клиентский путь, можно получить основные субъекты и объекты, построив онтологию, а из нее получить границы модель данных, границы микросервисов и основные артефакты
Чат в телеграмме как источник онтологии
А вот как понять, с какими объектами мы будем иметь дело? С чего начать бизнес-анализ? Что будет являться источником? Онтология это прежде всего живой язык. Раньше живой язык можно было услышать в курилках. Теперь живой язык можно
прочитать в рабочих чатах в телеграмме. Если выгрузить такой чат и провести частотный анализ высказываний, можно быстро оценить, что является наиболее
интересным для заказчика.
От чата в телеграмме к архитектуре. Если выгрузить чат из какого-либо мессенджера и провести лингвистический анализ, можно выделить основные субъекты и объекты на его основе
Матрица генерала Эйзенхауэра для оценки необходимой глубины клика
Для иллюстрации важности проектирования концепции интерфейса приведу пример не из ИТ. За несколько лет до аварии на Чернобыльской атомной электростанции в США случилась очень похожая авария на атомной станции в Три-Майл Айленде. Собственно, американцам повезло, и перегрев реактор они его не довели до теплового взрыва Несмотря на это, последствия были тяжелые, а аварию довольно долго ликвидировали. Конечно же, была создана комиссия для рассмотрения причин, и вот что выяснили: оператор переводил реактор из одного режима в другой, наблюдая за глубиной погружения стержней, давлением пара и температурой. И все три датчика располагались в разных частях щита управления. Оператору приходилось постоянно вращать головой, и, наблюдая за глубиной погружения стержней, он упустил давление пара и температуру. Из этого был сделан важный вывод — основные метрики процесса должны располагаться рядом. Если мы говорим об интерфейсе в ИТ-системе, то в пределах одной страницы.
Представим, что был разработан новый функционал. Архитектор начинает ждать обратной связи о внедрении, а ее мало; смотрит нагрузку на сервис, а она не такая, как предполагалось. Пользователь по каким-то причинам не стал ей использовать. И причина тут простая — пользователь не увидел нового функционала, потому что он очень глубоко спрятан в интерфейсе. Чтобы этого не произошло, после частотного анализа, описанного выше, необходимо провести грумминг с заказчиком и попросить разложить все выделенные объекты по четырем группам. Нужно понять, какое количество действий необходимо сделать в интерфейсе, чтобы добраться до необходимого функционала, мы называем «глубиной клика». Глубина клика в интерфейсе — показатель потенциально высокой нагрузки. Чем важнее функционал и чем чаще он используется, тем глубина клика должна быть меньше.
Визуализируем получившуюся разметку. Это дает нам возможность примерно оценить, какие из сервисов будут наиболее нагруженными.
Глубина клика в интерфейсе, полученная с помощью матрицы Эйзенхауэра. Она позволяет спроектировать понятный пользователю функционал и предсказать нагрузку на микросервисы
Закон примата бизнеса над ИТ
Известный факт, что ИТ не создает добавочный стоимости, подкрепляется утверждением, что каждая выделенная в ходе бизнес-анализа сущность должна иметь
единственное отражение в ИТ. Тем не менее, любой выделенный на этапе бизнес-анализа объект должен иметь однозначное и единственное отображение во фронте, в беке и в базе данных. И указать это отображение должен системный аналитик.
DevOps и новые подходы к доставке изменений
Доставка изменений и балансирование нагрузок также немаловажные события в энтерпрайзе. Ясно, что с одной стороны система будет меняться, причем быстро. С другой стороны, необходимо обеспечить решение проблемы балансировки нагрузок. В случае MSA и определения границ через построение доменной модели предлагается следующая концепция. Что если у нас будет существовать некая среда PaaS, в которой мы начинаем разворачивать все возможные микросервисы для нашей экосистемы. При этом один и тот же микросервис могут использовать различные экосистемные приложения. И пусть эта среда решает две задачи — CI/CD и балансировку нагрузок. В РСХБ и в построении его экосистемы используется платформа AppFarm, о которой мы уже писали в нашем блоге.
App.Farm. Множество приложений экосистемы использует один и тот же набор микросервисов, развернутый в некой PaaS
Монолит, микросервисы, Цитадель
Считается, что современный бек современной ИТ-системы в энтерпрайзе организован может быть двумя архитектурными стилями — либо монолит, либо микросервисы. Возможен ли «фьюжн», когда лишь часть функционала выносится в микросервисы? Однозначно да: ранее мы про него говорили — называется он «Цитадель». Давайте разберемся, в чем же отличие для нас монолита и микросервисов, чтобы дальше вести наши рассуждения, ведь современные реалии значительно разъехались с классическими определениями данных терминов.
Наряду со всем прочим отличиями, разница состоит в организации логики. Если в случае микросервисов мы имеем так называемую «слабую связность», то при другм сценарии мы уже говорим о так называемом «глубоком зацеплении». «Слабая связность» дает возможность легко и просто вносить изменения и, как многие считают, сравнительно легко масштабироваться. «Глубокое зацепление», в свою очередь, обеспечивает безопасность и надежность на более высоком уровне. Совершенно понятно, что на этапе RnD, когда неясен, в первую очередь, конечный замысел, применение монолита становится затруднительным.
Как сделать бек быстро? Ничего сложного. Методика быстрого создания бека в момент RND проста. Если есть набор бизнес объектов, полученных в ходе бизнес-анализа, то мы их рассовываем по контейнерам. Каждому контейнеру мы даем API, которое описываем через YAML. Когда говорим про экосистему, то бек одной экосистемы связан с беком другой экосистемы через фасад. Таким фасадом может стать шлюз, реализованный через REST API и описанный через YAML.
Все рано или поздно становится монолитом
Микросервисы, конечно, удобно, но очень дорого. Более того, со временем вы заходите сэкономить и на содержании DevOps специалистов. А поскольку в микросервисы нужно выносить далеко не все, у вас из желания сэкономить появится монолитное ядро. В этом ядре код и логика будет организована по законам DDD, так как монолит появился из микросервисов. При этом что-то, конечно, останется вне монолита, но основной функционал будет в нем.
Оркестрация и хореография при высоких нагрузках
Рассмотрим информационный обмен. Предположим, что у нас идет сбор документа JSON из разных источников. Каждый источник передает в некий супер Json свою часть. При хореографии существует некий окркестрирующий сервис, который этот Json собирает. Сервису надо уметь подключаться и отключаться от сервисов поставщиков. Теперь представим, что нагрузка возрастает. И не проще ли в этой ситуации перейти к хореографии? При хореографии у каждого сервиса только лишь два подключения — предыдущий и последующий.
Формирование документа JSON при оркестрации и хореографии. Показано, что при оркестрации придется устанавливать и удерживать множество соединений. Хореография же подразумевает наличие всего двух соединений
Небольшая историческая аналогия: СССР собирал танки на конвейерах, что можно сравнить с процессом хореографии в микросервисной архитектуре. Вермахт при сборке танков конвейерную сборку не использовал, а собирал танк на стапеле. Как итог, скорость сборки и починки новых танков для фронта во время крупных сражений, таких как Курская битва, была у Красной армии выше, чем у Вермахта. Некоторые историки считают данный факт немаловажным при определении причин поражения Германия в войне. Особенно это сказалось в переломный момент войны.
Интеграция и асинхронная модель взаимодействия
Мартин Фауллер учил нас, что нет никаких других средств интеграции кроме файла, общей базы данных, удаленного вызова и передачи сообщения. Если оставим файл и общую базу как способы неудобные и небезопасные, то у нас остается только лишь вызов удаленной процедуры, и таким образом мы сможем активизировать контроллеры, и передачу сообщения, благодаря чему мы сможем работать с хранилищами документов. Да вот беда, обмен сообщениями подразумевает создание некого механизма асинхронного взаимодействия. Обычно для этого используются такие решения, как Kafka и Rabbit. А это требует поиска дополнительных компетенций, но при низких нагрузках мы можем использовать для создания асинхронного механизма сам REST API. Регулируя таймауты и применяя механизмы асинхронного программирования до определенного уровня нагрузок, асинхронность можно поддерживать.
Идеального и универсального стека технологий не существует
Применяя ту или иную технологию, нужно понимать, что улучшение одних метрик продуктивности ведет за собой ухудшение других. Если отбросить тот факт, что часто стек определяется набором компетенций, имеющихся у большинства соискателей на рынке труда, можно для обоснования воспользоваться аналитикой, вытекающей из CAP-теоремы. С другой стороны, можно заявить, что возможность реализации той или иной задумки определяется финансовыми возможностями организации, временем, которым она располагает, и компетенцией имеющейся команды.
Иногда бывает, что для использования каких-то передовых технологий не хватает ресурсов, кадров или времени. Поэтому серьезный вклад менеджмента в техносферу заставляет исследователей изучать себя. Крупный бизнес в современной литературе часто называют «социотехническими компаниями». Внедрение каких-либо ИТ-решений в деловой оборот таких компаний выходит далеко за рамки чистой техносферы.
