Привет, Хабр! Меня зовут Валерий Разномазов, я системный аналитик в РСХБ. Сегодня поговорим про архитектуру мобильного в разрезе высоких нагрузок и построения экосистем. В этой статье я собрал свой 10-летний опыт по этому направлению и готов его обсудить с вами.
![](https://habrastorage.org/getpro/habr/upload_files/924/4cc/42f/9244cc42f10478459b8a8d9a51a91660.png)
Предисловие
Архитектура — это набор правил, которые принимают все участники обмена данными в рамках проектируемого мобильного приложения. В энтерпрайзе термин «мобильное приложение» означает один из возможных видов фронта для получения и отправки данных пользователю.
Энтерпрайз — это архитектурная парадигма, в рамках которой происходит цифровизация крупной компании, характерная тем, что происходит объединение в единое целое абсолютно не связанных непосредственно друг с другом бизнес‑процессов. Любой банк — это энтерпрайз. Все баги и фичи, которые вы видите в мобильном приложении банка, являются следствием невидимых пользователю процессов, идущих в деловом обороте. Каждый банк уникален, а попытки внедрить приложение одного банка в деловом обороте другого банка всегда вызывают улыбку.
«Экосистема» — это метафора, означающая, что ИТ‑решения, созданные в рамках цифровизации различных бизнесов, объединяются в единое целое. Продолжая метафору из науки о живом, давайте метафорически в разрезе архитектуры поговорим процессе выживания сильнейшего.
Какая наука о живом без вопроса о Творце? Однозначно отвечаем на этот вопрос — Бизнес делает ИТ, а не ИТ делает Бизнес, поэтому каждая архитектура в той или иной степени уникальна. По нашему мнению, прочесть исходный замысел можно через концепцию Design First, а также через такой артефакт, как рабочие чаты, в которых решаются вопросы делового оборота. Если рассмотреть их в разрезе построения онтологической модели и DDD, то дизайн, нарисованный заказчиками (часто даже простыми карандашами), и JSON с выгрузкой рабочих чатов для последующего лингвистического анализа становятся ценнейшими элементами для понимания необходимой архитектуры.
Параллели законов развития ИТ с законами животного мира
Проектируя архитектуру ИТ-решения, важно осознать, что оно не может и не будет существовать само по себе. Подобно представителю флоры или фауны нашей планеты, оно обязательно должно влиться в существующую экосистему и наладить обмен информацией с другими представителями этого «ИТ-ценоза». Если вливание в существующую экосистему не происходит, то ИТ-решению приходится порождать свою.
Мы уже неоднократно убеждались, что универсальное, пытающееся вместить в себя все процессы решение неизбежно умрет, так как не сможет вместить в себя все информационные потоки, поэтому нахождение вне исторически сложившегося в данной предметной области информационного обмена и делового оборота для него смертельно. Рассуждая в таком ключе, можно сказать, что закладка в архитектуру принципов открытой архитектуры (API First) становится центральным понятием в проектировании архитектуры.
![ИТ-ценоз. Нет смысла проектировать универсальное ИТ-решение. Важно занять свою нишу и помнить, что ИТ-решения находятся в постоянном обмене данными друг с другом ИТ-ценоз. Нет смысла проектировать универсальное ИТ-решение. Важно занять свою нишу и помнить, что ИТ-решения находятся в постоянном обмене данными друг с другом](https://habrastorage.org/getpro/habr/upload_files/6d6/e1a/cf1/6d6e1acf1785ef72337e33f315e7997a.png)
Если в эпоху SOA мы и объединяли различные решения в рамках одного бизнеса, то сейчас мы объединяем уже различные бизнесы под одним флагом (как правило, крупной компании). Думаю, что любой из читателей сталкивался с существующими ИТ-экосистемами, построенными по подобному принципу.
В РСХБ также складывается своя крупная и уникальная экосистема. Нами разрабатывается ряд мобильных приложений не только для клиентов физических или юридических лиц, но и для владельцев бизнесов в сельском хозяйстве. Так, например, в нашей экосистеме есть отдельные внутрибанковские решения для сопровождения внутренних кадровых вопросов и подбора персонала, а также разрабатывается мобильное приложение для студентов с предложениями карьерных треков. Проведя детальный анализ технологий и тенденций, а также множество экспериментов, хотим сказать, что идеального стека технологий не существует.
Рассказ про ИТ-экосистемы в свете вышесказанного можно подытожить выделением трех тезисов:
подготовка неких общих API для интеграции,
разработка единых правил авторизации и аутентификации,
выделение единого бизнес-слоя (бека для всех фронтов).
Другим важным аспектом при проектировании архитектуры является феномен Highload. Если возвращаться к аналогиям с животным миром, то можно вспомнить: выживает не сильнейший, а способный лучше остальных приспосабливаться к изменениям, то есть по-нашему масштабироваться. Тут важно вспомнить о другом накладывающем отпечаток на архитектуру явлении — Highload.
Highload — это состояние системы, при котором масштабироваться горизонтально оно не может. Происходит это не столько из-за недостаточной производительности сервера, сколько из-за рассинхронизации по таймингу. Все больше процессов завершаются, не дождавшись необходимого ответа данных от мастер-системы. То есть, если нет необходимых нам данных, мы будем получать какую-то из 400 ошибок и постоянно уходить на 2-й круг запроса, ожидая, что данные там появятся. Высокие нагрузки, в свою очередь, выдвигают свои требования:
уменьшение количества точек интеграции,
уменьшение времени получения кортежа данных из хранилищ.
![Иллюстрация рассинхронизации по таймингу. Потребитель делает несколько запросов, чтобы получить данные от поставщика. Время задержки — время ожидания данных Иллюстрация рассинхронизации по таймингу. Потребитель делает несколько запросов, чтобы получить данные от поставщика. Время задержки — время ожидания данных](https://habrastorage.org/getpro/habr/upload_files/d83/4cd/ffd/d834cdffda0741b1cd8ec4c3319ca6ab.png)
Артефакты и их влияние на интеграцию
Архитектуру важно не только правильно спроектировать, ее надо еще понятно приподнести желающим интегрироваться. Понятные артефакты — это уже центральное понятие аналитики. 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 вызовы вы будете совершать со всеми вытекающими отсюда последствиями. Чтобы набросать интерфейс, необходимо построить «намерение», то есть оценить те бизнес-объекты, которые будут в нашем бизнес-процессе участвовать.
![От Дизайна к архитектуре. Одним из способов проектирования архитектуры является проектирование предполагаемого клиентского пути в интерфейсе самим заказчиком. Когда ясен клиентский путь, можно получить основные субъекты и объекты, построив онтологию, а из нее получить границы модель данных, границы микросервисов и основные артефакты От Дизайна к архитектуре. Одним из способов проектирования архитектуры является проектирование предполагаемого клиентского пути в интерфейсе самим заказчиком. Когда ясен клиентский путь, можно получить основные субъекты и объекты, построив онтологию, а из нее получить границы модель данных, границы микросервисов и основные артефакты](https://habrastorage.org/getpro/habr/upload_files/eea/d62/5d1/eead625d115ccffd0f14f11297780d38.png)
Чат в телеграмме как источник онтологии
А вот как понять, с какими объектами мы будем иметь дело? С чего начать бизнес-анализ? Что будет являться источником? Онтология это прежде всего живой язык. Раньше живой язык можно было услышать в курилках. Теперь живой язык можно
прочитать в рабочих чатах в телеграмме. Если выгрузить такой чат и провести частотный анализ высказываний, можно быстро оценить, что является наиболее
интересным для заказчика.
![От чата в телеграмме к архитектуре. Если выгрузить чат из какого-либо мессенджера и провести лингвистический анализ, можно выделить основные субъекты и объекты на его основе От чата в телеграмме к архитектуре. Если выгрузить чат из какого-либо мессенджера и провести лингвистический анализ, можно выделить основные субъекты и объекты на его основе](https://habrastorage.org/getpro/habr/upload_files/800/1c1/945/8001c1945ace62e726ca95f57b7c2638.png)
Матрица генерала Эйзенхауэра для оценки необходимой глубины клика
Для иллюстрации важности проектирования концепции интерфейса приведу пример не из ИТ. За несколько лет до аварии на Чернобыльской атомной электростанции в США случилась очень похожая авария на атомной станции в Три-Майл Айленде. Собственно, американцам повезло, и перегрев реактор они его не довели до теплового взрыва Несмотря на это, последствия были тяжелые, а аварию довольно долго ликвидировали. Конечно же, была создана комиссия для рассмотрения причин, и вот что выяснили: оператор переводил реактор из одного режима в другой, наблюдая за глубиной погружения стержней, давлением пара и температурой. И все три датчика располагались в разных частях щита управления. Оператору приходилось постоянно вращать головой, и, наблюдая за глубиной погружения стержней, он упустил давление пара и температуру. Из этого был сделан важный вывод — основные метрики процесса должны располагаться рядом. Если мы говорим об интерфейсе в ИТ-системе, то в пределах одной страницы.
Представим, что был разработан новый функционал. Архитектор начинает ждать обратной связи о внедрении, а ее мало; смотрит нагрузку на сервис, а она не такая, как предполагалось. Пользователь по каким-то причинам не стал ей использовать. И причина тут простая – пользователь не увидел нового функционала, потому что он очень глубоко спрятан в интерфейсе. Чтобы этого не произошло, после частотного анализа, описанного выше, необходимо провести грумминг с заказчиком и попросить разложить все выделенные объекты по четырем группам. Нужно понять, какое количество действий необходимо сделать в интерфейсе, чтобы добраться до необходимого функционала, мы называем “глубиной клика”. Глубина клика в интерфейсе - показатель потенциально высокой нагрузки. Чем важнее функционал и чем чаще он используется, тем глубина клика должна быть меньше.
Визуализируем получившуюся разметку. Это дает нам возможность примерно оценить, какие из сервисов будут наиболее нагруженными.
![Глубина клика в интерфейсе, полученная с помощью матрицы Эйзенхауэра. Она позволяет спроектировать понятный пользователю функционал и предсказать нагрузку на микросервисы Глубина клика в интерфейсе, полученная с помощью матрицы Эйзенхауэра. Она позволяет спроектировать понятный пользователю функционал и предсказать нагрузку на микросервисы](https://habrastorage.org/getpro/habr/upload_files/2f5/d65/783/2f5d65783bd023c1b1f88deea6869d13.png)
Закон примата бизнеса над ИТ
Известный факт, что ИТ не создает добавочный стоимости, подкрепляется утверждением, что каждая выделенная в ходе бизнес-анализа сущность должна иметь
единственное отражение в ИТ. Тем не менее, любой выделенный на этапе бизнес-анализа объект должен иметь однозначное и единственное отображение во фронте, в беке и в базе данных. И указать это отображение должен системный аналитик.
DevOps и новые подходы к доставке изменений
Доставка изменений и балансирование нагрузок также немаловажные события в энтерпрайзе. Ясно, что с одной стороны система будет меняться, причем быстро. С другой стороны, необходимо обеспечить решение проблемы балансировки нагрузок. В случае MSA и определения границ через построение доменной модели предлагается следующая концепция. Что если у нас будет существовать некая среда PaaS, в которой мы начинаем разворачивать все возможные микросервисы для нашей экосистемы. При этом один и тот же микросервис могут использовать различные экосистемные приложения. И пусть эта среда решает две задачи — CI/CD и балансировку нагрузок. В РСХБ и в построении его экосистемы используется платформа AppFarm, о которой мы уже писали в нашем блоге.
![App.Farm. Множество приложений экосистемы использует один и тот же набор микросервисов, развернутый в некой PaaS App.Farm. Множество приложений экосистемы использует один и тот же набор микросервисов, развернутый в некой PaaS](https://habrastorage.org/getpro/habr/upload_files/e18/f9f/54f/e18f9f54f7654aa09f571f47416616ed.png)
Монолит, микросервисы, Цитадель
Считается, что современный бек современной ИТ-системы в энтерпрайзе организован может быть двумя архитектурными стилями — либо монолит, либо микросервисы. Возможен ли «фьюжн», когда лишь часть функционала выносится в микросервисы? Однозначно да: ранее мы про него говорили — называется он «Цитадель». Давайте разберемся, в чем же отличие для нас монолита и микросервисов, чтобы дальше вести наши рассуждения, ведь современные реалии значительно разъехались с классическими определениями данных терминов.
Наряду со всем прочим отличиями, разница состоит в организации логики. Если в случае микросервисов мы имеем так называемую «слабую связность», то при другм сценарии мы уже говорим о так называемом «глубоком зацеплении». «Слабая связность» дает возможность легко и просто вносить изменения и, как многие считают, сравнительно легко масштабироваться. «Глубокое зацепление», в свою очередь, обеспечивает безопасность и надежность на более высоком уровне. Совершенно понятно, что на этапе RnD, когда неясен, в первую очередь, конечный замысел, применение монолита становится затруднительным.
Как сделать бек быстро? Ничего сложного. Методика быстрого создания бека в момент RND проста. Если есть набор бизнес объектов, полученных в ходе бизнес-анализа, то мы их рассовываем по контейнерам. Каждому контейнеру мы даем API, которое описываем через YAML. Когда говорим про экосистему, то бек одной экосистемы связан с беком другой экосистемы через фасад. Таким фасадом может стать шлюз, реализованный через REST API и описанный через YAML.
Все рано или поздно становится монолитом
Микросервисы, конечно, удобно, но очень дорого. Более того, со временем вы заходите сэкономить и на содержании DevOps специалистов. А поскольку в микросервисы нужно выносить далеко не все, у вас из желания сэкономить появится монолитное ядро. В этом ядре код и логика будет организована по законам DDD, так как монолит появился из микросервисов. При этом что-то, конечно, останется вне монолита, но основной функционал будет в нем.
Оркестрация и хореография при высоких нагрузках
Рассмотрим информационный обмен. Предположим, что у нас идет сбор документа JSON из разных источников. Каждый источник передает в некий супер Json свою часть. При хореографии существует некий оркестрирующий сервис, который этот Json собирает. Сервису надо уметь подключаться и отключаться от сервисов поставщиков. Теперь представим, что нагрузка возрастает. И не проще ли в этой ситуации перейти к хореографии? При хореографии у каждого сервиса только лишь два подключения — предыдущий и последующий.
![](https://habrastorage.org/getpro/habr/upload_files/8be/859/cfd/8be859cfd8a37ee4c7cfbde4d93743b1.png)
Формирование документа JSON при оркестрации и хореографии. Показано, что при оркестрации придется устанавливать и удерживать множество соединений. Хореография же подразумевает наличие всего двух соединений
Небольшая историческая аналогия: СССР собирал танки на конвейерах, что можно сравнить с процессом хореографии в микросервисной архитектуре. Вермахт при сборке танков конвейерную сборку не использовал, а собирал танк на стапеле. Как итог, скорость сборки и починки новых танков для фронта во время крупных сражений, таких как Курская битва, была у Красной армии выше, чем у Вермахта. Некоторые историки считают данный факт немаловажным при определении причин поражения Германия в войне. Особенно это сказалось в переломный момент войны.
Интеграция и асинхронная модель взаимодействия
Мартин Фауллер учил нас, что нет никаких других средств интеграции кроме файла, общей базы данных, удаленного вызова и передачи сообщения. Если оставим файл и общую базу как способы неудобные и небезопасные, то у нас остается только лишь вызов удаленной процедуры, и таким образом мы сможем активизировать контроллеры, и передачу сообщения, благодаря чему мы сможем работать с хранилищами документов. Да вот беда, обмен сообщениями подразумевает создание некого механизма асинхронного взаимодействия. Обычно для этого используются такие решения, как Kafka и Rabbit. А это требует поиска дополнительных компетенций, но при низких нагрузках мы можем использовать для создания асинхронного механизма сам REST API. Регулируя таймауты и применяя механизмы асинхронного программирования до определенного уровня нагрузок, асинхронность можно поддерживать.
Идеального и универсального стека технологий не существует
Применяя ту или иную технологию, нужно понимать, что улучшение одних метрик продуктивности ведет за собой ухудшение других. Если отбросить тот факт, что часто стек определяется набором компетенций, имеющихся у большинства соискателей на рынке труда, можно для обоснования воспользоваться аналитикой, вытекающей из CAP-теоремы. С другой стороны, можно заявить, что возможность реализации той или иной задумки определяется финансовыми возможностями организации, временем, которым она располагает, и компетенцией имеющейся команды.
Иногда бывает, что для использования каких-то передовых технологий не хватает ресурсов, кадров или времени. Поэтому серьезный вклад менеджмента в техносферу заставляет исследователей изучать себя. Крупный бизнес в современной литературе часто называют «социотехническими компаниями». Внедрение каких-либо ИТ-решений в деловой оборот таких компаний выходит далеко за рамки чистой техносферы.
Комментарии (16)
VVitaly
12.08.2024 09:51+1"Вытягивать весь объект целиком, как позволяет noSQL, проще." - Ну конечно "проще", но как это влияет на производительность? Если вам необходимо обновить один при признак объекта у которого их может быть сотни и они все могут обновляться в различных ситуациях? Т.е. (грубо говоря) вместо 16 байт данных вам придется сохранять весь "объект" в 128КB... И так для миллиона объектов и сотни их признаков. Где тут разум и логика?
DrRaznomazov Автор
12.08.2024 09:51то что вы говорите, это известный недостаток noSQL подхода. Конечно, если надо часто обновлять, к нему нужно относиться с опаской. И опять же, по нашему опыту ускорения при добавлении и обновлении это вопросы оптимизации.
А прощу в том что, представьте себе что вы идете на рынок и покупаете ингредиенты для супа. Вы ходите и ищете. И тут вам предлагают купить готовый суповой набор. Выв его быстренько берете и уходите с рынка.
VVitaly
12.08.2024 09:51:-) Это я к тому что "проще" - совсем не значит "оптимальнее"... Вы можете использовать сотни микросервисов на нескольких десятках серверов (поставщики ресурсов, разработчики и devops-ы этому будут только рады), хотя возможно вам вам вполне достаточно одного "монолита" на 3 серверах... Каждое оптимальное решение требует аналитики, оценки, проработки и тестирования под ваши конкретные требования и условия, но можно и "по agile" - "раз, два и в продакшен, а там видно будет...."
DrRaznomazov Автор
12.08.2024 09:51По-моему эту же мысль я и сказал в финале статьи. И "проще" значит путем наименьших потерь в настоящих условиях. Многие читатели не поняли, что я говорю про энтерпрайз, а в нем условия меняются очень быстро.
VVitaly
12.08.2024 09:51:-) Потерь для кого? Если "для разработчика" - то "чем дольше" будут появляться новые требования к ПО - тем больше "денег срубишь!", т.е. он не заинтересован делать "один раз и навсегда". Аналогично "для внедренцев" и devops и аналитиков. Ну а пользователи - "пусть страдают", как и бизнес который "дальше собственного носа не видит"... Как то так...
DrRaznomazov Автор
12.08.2024 09:51Это не про наш случай. На наших проектах работают только специалисты банка. А то о чем вы говорите, окончилось в 22 году. Хотя, наверное, где-то еще продолжается
BorisShumai
12.08.2024 09:51Как разработчик мобильных приложений, в т.ч. для финтеха, скажу, что статья, прочитанная по диагонали, заставила меня страдать и комплекс самозванца заиграл новыми красками. Впрочем, интуиция подсказывает мне, что я с автором расхожусь в понимании терминов до такой степени, что может эта статья и не касается мобильных разработчиков совсем.
DrRaznomazov Автор
12.08.2024 09:51Нужно быть благодарным хабру за то, что вы теперь можете у любое время дня и ночи рассказывать о своих страданиях миру.
BorisShumai
12.08.2024 09:51Дядька, чё такой дерзкий? Эмоционально и необдуманно. Будто бы у хабра это ноу-хау - возможность рассказывать всему миру...
Ты лучше мне и остальным разработчикам мобильных приложений расскажи, какие таймауты-то использовать, в разрезе высоких нагрузок и построения экосистем?
DrRaznomazov Автор
12.08.2024 09:51в статье ясно написано о величине этих таймаутов. Более того, мною и коллегами проводились эксперименты и данная тема неоднократно выносилась на обсуждение. Если возник подобный вопрос, вам следует еще раз ознакомиться с сиквенс-диаграммой, приведенной в настоящей работе и прочитать на ней о величине необходимого таймаута. Если вы не понимаете сиквенс-диаграммы, то обратитесь к своему сеньору или мидлу, они вам расскажут как их читать.
geotech
И это теперь стандарт и уровень статей на Хабре? Я понимаю, что мы живем в эпоху контента генерируемого ИИ, но можно же вычитать и поправить текст перед публикацией?! Даже если не придираться к отдельным формулировкам, то все равно в каждом разделе бессмыслица.
Вы используете различные термины, совершенно не к месту. И сами запутались в том, что хотели сказать. Как например в разделе "Оркестрация и хореография при высоких нагрузках"
В иллюстрации вы вообще вводите новый термин - "офрография":
Далее про CAP:
Вы даже не представляете себе насколько странное это предложение. Большинство компетенций на рынке - это относительно слабый фронт (HTML,CSS,JS). Так как это подмножество компетенций встречается и у серьезных синьоров, и у фуллстеков, у фронтенд разработчиков, у мобильных разработчиков, а также у тех кто прошел курсы и буткампы. Это определяет стек для вашей архитектуры? И при чем тут CAP-теорема? И какую "аналитику" вы из нее используете? Это теорема для вполне конкретного случая сформулирована: для распределенных источников данных. И от стека не зависит, да и влияет на него, разве что, косвенно.
Тут вы вообще меня потеряли:
Я сломал голову, пытаясь понять эту фразу.
Про "асинхронность":
Это какой-то поток сознания (или поток вывода ИИ)! Тезисно: обмен сообщениями может быть, вполне себе, синхронным; Kafka и Rabbit не гарантируют что у вас все "асинхронно" (что бы вы не понимали под этим) станет, и вообще, они про другое немного; дополнительные компетенции наверное понадобятся, если ваш стек продиктован "большинством компетенций соискателей"; REST API можно использовать и при высоких нагрузках и с теми же Kafka и Rabbit; регулируя таймауты (API Throttling/API Rate Limiting), вы можете контролировать нагрузку на сервера, но асинхронность тут ни при чем.
Про микросервисы и монолиты вы написали полную чушь. Вы совершенно не владеете этой темой.
На этапе RnD, как раз-таки, микросервисы сложно выделить, а вот монолит применяется легко. В крайнем случае, будет несколько монолитов сначала.
Вы, видно, никогда не занимались DevOps для монолитов. Релиз-менеджмент монолитов, слияние веток и фич, фича-флаги, объем тестирования и подготовки, процедуры развертывания и отката - это та еще боль! Это одна из причин почему нужны микросервисы.
И так можно про каждый раздел вашей статьи написать, но это уже по объему отдельная статья получается. Этот комментарий я пишу для тех, кто не достаточно опытен, чтобы увидеть вредность вашей статьи и чтобы это не появилось в рефератах студентов.
DrRaznomazov Автор
Благодарю вас за подробный отзыв. Очень рад, что вы во всем видите генерированный ИИ текст и искренне надеюсь, что этот генератор находится не с вами в одной комнате.
1. По поводу опечаток - спасибо. Исправили.
2. Про CAP теорему вы можете прочитать, найдя ссылку в любом поисковике и если вы когда-то касались архитектурных вопросов, то вам труда не составит понять, какую аналитику можно из нее вынести. Если же у вас с этим все-таки возникнут трудности постарайтесь почитать литературу, ссылку я могу дать в переписке.
Обмен сообщениями в энтерпрайзе сложно представить себе синхронным. Ну таков он энтерпрайз. Такова данность, опять же если у вас есть сомнения и вы просто никогда не работали в рамках крупного ИТ-проекта то я могу дать вам почитать пару книжек. Кстати, генератор ИИ тут не причем. Просто вы не понимаете сути написанного ввиду отсутствия какого-либо опыта.
По поводу релиза монолитов. Если у вас в монолите бардак, то проблемы с релизами будут обязательно. Фишка в том, что вы перенесете этот бардак в микросервисы и легче вам от переноса не станет.
geotech
Рад помочь.
Про CAP-теорему я читал, именно поэтому и не смог понять, что за аналитика подразумевалась в контексте той цитаты, что я привел. Вообще у нее есть дополнения и критика, поэтому так сложно понять про какую аналитику вы пишете. Я советую вам почитать критику CAP-теоремы и узнать границы ее применения (тут например, https://arxiv.org/abs/1509.05393).
Тут все зависит от того, что вы понимаете под синхронностью и асинхронностью. Именно это и вызвало трудности при прочтении статьи. Тоже хотелось бы понять что за энтерпрайз вы имеете в виду. В вашем определении - это просто большая гетерогенная система. Сейчас практически все более ли менее крупные системы являются таковыми, используют множество других сторонних систем и продуктов. Почему-то во многих местах, где вы пишите "асинхронно", мне видится Eventual Consistency. Что не одно и то же.
Ваша логика мне понятна. Если у вас бардак в микросервисах, то и в монолите при переносе бардак не уйдет, и наоборот. То есть проблема не в архитектуре. Поэтому я и указал метрики (не все, конечно) DevOps, по которым можно сравнивать и принимать решение в пользу одного или другого, или подумать о гибридном подходе. Ну и отсутствие бардака - это отсутствие легаси, не оптимальных решений, это зависимости, которые не меняются, не нужно поддерживать версионность, обратную совместимость, отсутствие распереденности по местоположению (датацентров) и так далее.
DrRaznomazov Автор
CAP- теорема позволяет выбрать стек технологий. Более того, когда выбирают какую-то концепцию СУБД, часто только её и вспоминают. В частности noSQL подход. Я прекрасно осведомлен, о том что у CAP- теоремы, в прочем как у любой другой технической парадигмы, есть критика. Это нормально и CAP- теорема действительно не всегда может сработать. Но в энтерпрайзе, где речь идет о мессенджинге, работает почти всегда.
Асинхронность в контексте данной статьи, это то чего требует месседжинг (по Мартину Фаулеру) в SOA. Нам нужен гарантированный метод доставки сообщения (XML или JSON, а может и некой позиционной строки), такой чтобы пока сообщение доставлялось, отправитель спокойно мог дальше работать, а не ждать ответа.
Давайте так, метрики DevOps я не рассматривал в данной статье. Если вы укажете на них, то будет интересно изучить и дать вам ответ в вашем контексте. В любом случае, работать с одним компонентом (монолит) это быстрее, чем работать с набором компонентов (контейнеры). Понятны, ваши апелляции к тому, что внутри этого монолита. Но я же говорю, монолит получим из микросервисов, внутри такого монолита жеткое разделение на домены. Теоретически, все должно быть быстрее чем деплоить микросервисы.
geotech
Что касается генерации текста ИИ, то я сделал предположение, что нестройность повествования и неточности формулировок - это результат генерации. Если это не так, то, простите, не хотел умалять ваш труд, текст большой получился. Ну раз это не ИИ, то давайте по формулировкам пройдемся:
Это не архитектура, а API. Архитектура находится уровнем выше и по сути является эссенцией знаний обо всей системе разделяемой всеми участниками (Мартин Фоулер). Набор правил для обмена данными, принятый всеми участниками - это реализация части архитектуры.
DrRaznomazov Автор
да что говорите! вы пойдите куда-то, в какой-нибуль ВУЗ типа ВШЭ и скажите им так "Ребята, а вы не правильно учите, я вот знаю как надо правильно". И если с вами после этого станут разговаривать и прислушаются к вам, вот тогда я соглашусь, что формулировка неверная.
Опять же, вы говорите, что API это не есть архитектура, а её воплощение. Наверное, это действительно так. Но только я говорю, что перед API есть онтология, а онтология это есть архитектура. Возможно, это надо было как-то по четче выразить.