1. Почему пора менять подход

В этой главе мы разберем, почему текущий подход к созданию программ — когда база данных и интерфейс жестко связаны — перестает работать при масштабировании. Для предприятия ЖКХ, где требования меняется с каждым новым законом или запросом заказчика, это вопрос не «когда», а «как быстро».

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

2. Кризис монолита в современных реалиях ЖКХ

Долгие годы основным стандартом разработки корпоративных приложений была Monolithic Architecture (монолитная архитектура). Представьте огромный бетонный куб, внутри которого залиты трубы, провода и вентиляция. Если нужно поменять одну трубу — придется ломать весь куб.

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

3. Микросервисы как выход из тупика

Современный подход — это конструктор Lego. Каждая деталь выполняет строго одну функцию, имеет свою независимую мини-базу данных и общается с другими только по строгим правилам. Один микросервис считает тарифы, другой — формирует квитанции, третий — управляет автопарком. Изменили расчет тарифов? Меняется один крошечный модуль, остальная система не трогается.

4. Кошмар интеграции и шина данных (ESB)

Когда компания решает уйти от монолита и внедрить множество независимых систем (1С, системы управления транспортом, новые Java-микросервисы), возникает новая проблема: Point-to-Point Integration (интеграция «точка-точка»).

Если заставить 1С напрямую отправлять данные в транспортную систему, а транспортную — напрямую в портал управления, мы получим хаос: системы «общаются» на разных языках, при сбое одной из них данные теряются безвозвратно.

Решение — Enterprise Service Bus (ESB, корпоративная сервисная шина). ESB выступает «центральным почтамтом» и переводчиком: системы больше не знают о существовании друг друга. Система транспорта просто «кричит» в шину: «Машина с номером ХХХ выехала!» — шина принимает сигнал, переводит в нужный формат и доставляет тем системам, которые подписаны на это событие. Подробно ESB мы разберем в главе 4.

5. Роли систем в новой парадигме предприятия

В целевой архитектуре каждая система занимается только своим профильным делом. Это ключевая схема главы — запомните позиции четырех участников:

6. Реальный сценарий: авария на очистных сооружениях

Представьте крупный объект — городские очистные сооружения. Срабатывает датчик падения давления в периметральной системе насосов.

Как это работало в жестком монолите: сигнал поступает в код Java. Код пытается напрямую создать задачу в базе диспетчера и напрямую лезет в 1С проверить наличие запчастей на складе. Если 1С в этот момент обновляется и недоступна — код выдает ошибку, процесс прерывается, авария не устраняется.

Как это работает в целевой архитектуре (Camunda + ESB):

1. Микросервис телеметрии ловит сигнал от оборудования и отправляет сообщение в шину (ESB): «Давление упало».
2. Шина передает это событие в Camunda.
3. Camunda запускает бизнес-процесс «Устранение аварии».
4. Camunda отправляет через ESB приказ в 1С: «Зарезервируй ремкомплект на складе». 1С выполняет и отвечает «Готово».
5. Camunda отправляет приказ в Битрикс24: «Создай задачу дежурной бригаде» — и запускает таймер.
6. Если бригада не закрыла задачу в Битрикс24 за 30 минут, Camunda видит это и по процессу эскалации отправляет уведомление руководителю.

7. Целевая архитектура предприятия (уровень руководителя)

Ниже — итоговая схема главы. Именно такую картину нужно уметь «читать» и показывать заказчикам: сверху — люди, далее единая точка входа (API Gateway), дирижер процессов (Camunda), в центре — шина данных (ESB), внизу — профильные системы, которые не знают друг о друге и общаются только через шину.

1. Исторический разрыв между бизнесом и ИТ

На любом предприятии — будь то ЖКХ или производство — есть два лагеря:

• Бизнес (руководители, аналитики, методологи) мыслит категориями эффективности: «С завтрашнего дня заявки на ремонт труб свыше 100 000 рублей должны проходить дополнительное согласование у главного инженера».
• ИТ-отдел (программисты) мыслит категориями стабильности кода и баз данных. Любое изменение для них — риск сломать работающую систему.

В классической схеме бизнес пишет техническое задание (ТЗ), отдает программистам, и те уходят на недели или месяцы, превращая ТЗ в строки Java. В результате бизнес-логика становится невидимой для руководителя — она спрятана внутри программы (черного ящика).

2. Анатомия хардкода: пример из практики ЖКХ

Процесс: отключение должника от услуги. Программист пишет строку кода: IF (debt > 5000) THEN { send_block_command() }. Программа работает идеально.

Через полгода руководство решает: теперь отключаем только при долге свыше 10 000 рублей, и за 3 дня до этого отправляем SMS-уведомление. Что делает руководитель в системе с хардкодом?

1. Пишет новое ТЗ.
2. Ждет, пока программист найдет нужную строчку в сотнях тысяч строк кода.
3. Программист перепишет код, добавив логику отправки SMS.
4. ИТ-отдел остановит сервер, чтобы загрузить новую версию программы.

Этот цикл называется Time-to-Market (время вывода изменений в работу). В жестких системах он катастрофически длинный — а требования в ЖКХ меняются постоянно.

3. Парадигма BPM: бизнес-логика становится видимой

Чтобы разорвать эту зависимость, была придумана концепция BPM (Business Process Management — управление бизнес-процессами). Суть: извлечь бизнес-логику из программного кода и вынести ее на отдельный визуальный уровень, понятный руководителю.

Вместо того чтобы программист писал условия ветвления в коде, бизнес-аналитик рисует визуальную схему (блок-схему) в специальной программе. А BPM-движок (например, Camunda) сам «читает» эту картинку и исполняет ее как программу.

4. BPMN: язык, который понимают и люди, и машины

Если каждый аналитик начнет рисовать схемы так, как ему хочется (квадратики, кружочки, стрелочки разных цветов), программисты не смогут научить систему это понимать. Нужен был единый мировой стандарт. Им стал BPMN (Business Process Model and Notation) — международный стандарт графического описания процессов, разработанный консорциумом OMG.

Главная «магия» BPMN: это не просто картинка. Под каждым нарисованным квадратиком скрывается машиночитаемый код в формате XML. Вы рисуете понятную вам картинку, а движок (Camunda) читает спрятанный под ней код и исполняет его. Бизнес и ИТ наконец-то говорят на одном языке.

5. Алфавит BPMN: 4 главных элемента

Чтобы читать схемы BPMN, руководителю достаточно знать всего четыре базовые фигуры. Сохраните эту «шпаргалку» — она понадобится на командных воркшопах.

6. Практический пример: читаем процесс как руководитель

Типовой согласованный процесс в нотации BPMN. Следуйте цифрам на стрелках — это путь одного «токена» (об этом ниже) через процесс «Обработка заявки ЖКХ».

Как руководитель читает эту схему: процесс стартовал (зеленый круг) → диспетчер в интерфейсе Битрикс24 смотрит данные (синий прямоугольник) → принимается решение (желтый ромб) → если всё хорошо, система без участия человека через шину бронирует машину → процесс разделяется на два параллельных потока: пока люди едут на объект, система резервирует расходы в 1С → процесс ждет выполнения обоих условий и завершается.

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

7. Camunda: чем движок отличается от Visio

Многие руководители спрашивают: «Мы и раньше рисовали схемы в Microsoft Visio или Miro — в чем разница?» Разница фундаментальна.

• Visio — вы рисуете мертвую картинку для регламента, который потом ляжет в стол.
• Camunda — это Process Engine (движок процессов): полноценная серверная программа, которая «проглатывает» вашу схему и начинает управлять другими системами по нарисованным стрелочкам. Если вы удалите стрелочку в Camunda, процесс на предприятии изменится в ту же секунду.

8. Принцип токена: как Camunda «гоняет» процессы

Представьте настольную игру, где вы кидаете кубик и двигаете фишку по клеточкам. В терминологии BPM эта фишка называется Token (токен — маркер выполнения). На рис. 2.3 красная точка и есть токен.

1. Поступает заявка на ремонт лифта — на зеленом стартовом круге появляется токен.
2. Движок толкает токен по стрелочке к следующему шагу — например, к задаче «Назначить бригаду в Битрикс24».
3. Токен «замирает» на этом прямоугольнике. Camunda отправляет команду через шину в Битрикс24.
4. Как только мастер в Битрикс24 нажимает «Выполнено», Битрикс шлет сигнал обратно — токен «оживает» и бежит дальше.

9. Из чего состоит Camunda

Для команды из 20 человек важно понимать три главных компонента платформы:

10. Почему Camunda (Open Source) — лучший выбор для заказчика

• Отсутствие Vendor Lock-in (привязки к продавцу). Платная проприетарная система = миллионы за лицензии каждый год; нет денег — система отключается. У Camunda есть мощная бесплатная Community Edition, которую можно использовать в коммерческих целях без лицензионных отчислений.
• Легкость интеграции. В отличие от тяжеловесных старых BPM-систем, Camunda изначально создавалась для программистов: идеально встраивается в архитектуру, где уже есть шина (ESB) и микросервисы на Java.
• Масштабируемость. Способна обрабатывать тысячи заявок в секунду — критично для сбора телеметрии с приборов учета или массовых платежей ЖКХ.

1. Историческая справка: братство на Java

Большинство современных популярных движков имеют одни и те же корни. Изначально существовал популярный продукт Activiti. Из-за разногласий в подходах часть разработчиков ушла и создала форк — Camunda. Чуть позже другая группа откололась от Activiti и создала Flowable. Именно поэтому под капотом Camunda 7 и Flowable очень похожи — но идеологически они пошли разными путями. А несколько лет назад разработчики Camunda совершили революцию и написали с нуля абсолютно новый движок — Zeebe, который сегодня является ядром платформы Camunda 8.

2. Битва классиков: Camunda 7 против Flowable

Оба продукта построены на классической RDBMS-архитектуре: каждый раз, когда процесс переходит от шага к шагу (токен сдвинулся), движок записывает изменение в строгую реляционную базу данных (например, PostgreSQL).

3. Новая эра: Zeebe (Camunda 8) и облака

С развитием IoT (умные счетчики в ЖКХ ежесекундно передают телеметрию) классическая архитектура баз данных перестала справляться. Появился Zeebe — с принципиально иной событийно-ориентированной (Event-Driven) архитектурой: он не фиксирует каждый чих в базе, а работает по принципу «бесконечной магнитофонной ленты» (Event Sourcing) — очень быстро записывает поток логов прямо на диск.

• Плюс Scalability: миллионы событий в секунду; не справляется — докупаете сервер, Zeebe сам распределяет нагрузку.
• Плюс Cloud-Native: идеально живет в распределенных кластерах.
• Минус (критично для ваших проектов): гораздо сложнее развернуть на обычных локальных серверах заказчика (On-Premise) — требует сложных облачных инструментов (Kubernetes). Бесплатная версия имеет более строгие лицензионные ограничения для коммерции, чем Camunda 7.

4. 🇷🇺 Platform V Flow (СберТех) — отечественная low-code BPM-система

Platform V — корпоративная PaaS-платформа СберТех (представлена в 2020 году, с 2021 года лежит в основе цифровой трансформации самого Сбера). Главный компонент для нашей архитектуры — Platform V Flow: low-code BPM-система для автоматизации бизнес-процессов, оркестрации микросервисов и исполнения пользовательских задач. Моделирование процессов происходит в нотации BPMN 2.0 — том самом международном стандарте, который разбирался в главе 2, поэтому все схемы и навыки переносятся один в один. Flow используется как самостоятельно, так и в качестве ядра для построения высоконагруженных, отказоустойчивых и безопасных enterprise-решений.

То есть для заказчика из госсектора или с задачей импортозамещения Flow забирает роль «дирижера», которую в нашей эталонной архитектуре играл Camunda, Synapse (глава 4) заменяет шину, а Pangolin — отечественную СУБД на основе PostgreSQL (совместима с 1С:Предприятие 8) — можно ставить на место базы процессов.

Ключевые преимущества Flow

• Отказоустойчивость 99,99% и нагрузочный опыт: 360+ млн запусков процессов в месяц внутри Сбера — от сервисов СберБанк Онлайн до Mission Critical систем.
• Перераспределяет ресурсы и разгружает ИТ-отдел: проектированием бизнес-процессов занимаются аналитики, а в разработке достаточно middle- и junior-специалистов под сильным системным аналитиком — экономия на senior-разработчиках.
• Корректировки в продакшен за минуты: достаточно поменять стрелку в схеме — изменение произойдет быстро, без перекомпиляции и новых релизов.
• Сокращает time-to-market: быстрый старт разработки, поэтапное развитие и оптимизация схем процессов; прозрачность процессов и удобный мониторинг — быстрые разборы инцидентов.
• Технически: среда исполнения — горизонтально масштабируемый сервис исполнения процессов с публичным API для управления; соответствие высоким требованиям доступности, надежности и безопасности.

Кому подходит (заявленные сценарии): компании с высоконагруженными ИТ-системами и фокусом на информационную безопасность; с большим количеством клиентских обращений и объемом регулярного документооборота; ищущие альтернативу коробочным решениям; с задачами цифровизации в финансах, страховании, промышленности и не только. Реальные внедрения: ключевые сервисы СберБанк Онлайн, цифровые финансовые активы и блокчейн, B2B/B2C-решения (зарплатные проекты, клиентские обращения, депозиты), заявочный комплекс в самом СберТехе, государственные информационные системы.

5. Как люди будут работать с задачами: три подхода к интерфейсам

Camunda по своей природе — Headless («безголовая») система: есть мощный «мозг» (движок), но нет «лица» (красивого сайта). Как диспетчер, слесарь и бухгалтер увидят, что им нужно сделать?

6. Паттерн External Task: как «подружить» Camunda и Битрикс24

Рассмотрим процесс «Закупка оборудования»:

1. Токен в Camunda доходит до шага «Согласовать закупку в рабочей группе».
2. Camunda не отправляет задачу в свой Tasklist — она создает Внешнюю Задачу и «замирает».
3. Между Camunda и Битрикс24 работает маленький микросервис-коннектор (Java), который постоянно «опрашивает» (Polling) Camunda: «Есть новые задачи?»
4. Микросервис видит задачу, забирает ее и через API Битрикс24 формирует карточку: рабочая группа, ответственные, файлы, дедлайн.
5. Руководитель видит обычную задачу в Битрикс24 и нажимает «Завершить задачу».
6. Битрикс24 отправляет сигнал — Webhook (механизм обратного вызова) — обратно в микросервис: «Задача №123 завершена».
7. Микросервис передает команду в Camunda — токен оживает и идет дальше по процессу.

7. Хореография против оркестрации

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

Представьте процесс «Подключение нового дома к сетям ЖКХ» с тремя участниками: Биллинг (расчеты), CRM (база клиентов) и Диспетчерская.

• Подход 1 — Хореография (Choreography): танец без дирижера. Каждая система работает сама и реагирует на события других. Биллинг кричит: «Счет создан!» → CRM создает карточку жильца и кричит: «Жилец создан!» → Диспетчерская отправляет бригаду. Проблема: нет единого центра управления. Если бригада не уехала — вы не знаете, где сбой: Биллинг считает, что отработал, CRM — тоже. Процесс «завис в пустоте». Искать ошибку — ад.
• Подход 2 — Оркестрация (Orchestration): симфонический оркестр с дирижером (Camunda). Микросервисы «молчат» и ждут команды. Дирижер смотрит в ноты (BPMN-схему) и дает приказы: «Биллинг, создай счет» → «Готово» → «Теперь ты, CRM, создай карточку». Преимущество: вы всегда можете открыть Cockpit и точно увидеть, на каком шаге сейчас подключение дома и какая именно система дала сбой.

8. Как Camunda управляет микросервисами (External Task для роботов)

Тот же механизм External Task, что и для Битрикс24, используется и для программ-роботов:

1. Camunda не «стучится» в закрытые двери систем безопасности заказчика. Она кладет задачу «Выписать штраф» во внутреннюю корзину — Topic (тема подписки).
2. Ваш микросервис штрафов постоянно опрашивает корзину через REST API (Polling): «Для меня есть работа?»
3. Если работа есть — забирает задачу, выполняет в своей базе данных и возвращает ответ: «Штраф выписан».

9. Управление сбоями: повторные попытки и компенсация

В реальном мире ЖКХ серверы «падают», интернет пропадает, 1С зависает из-за обновления. «Глупая» система с жестким кодом выдаст ошибку, и процесс сломается навсегда. Умный оркестратор:

1. Политика повторных попыток (Retry Policy): «Если 1С не отвечает — не ломай процесс. Подожди 5 минут и попробуй снова. Три попытки. Если 1С все еще лежит — отправь уведомление системному администратору».
2. Компенсация (Compensation): иногда нужно «откатить» процесс назад. Camunda дала команду Биллингу списать деньги — деньги списались. Следующий шаг: направить водовозку — но свободных водовозок нет (ошибка). В BPMN есть специальный значок — событие компенсации (кнопка перемотки назад). Camunda автоматически вернется на шаг назад и даст команду Биллингу: «Верни деньги на счет, услуга не может быть оказана». ИТ-система сама исправляет свои логические ошибки без участия программиста!

1. Проблема: интеграция «точка-точка» и архитектура спагетти

В реальной практике предприятий ЖКХ (водоканалы, теплосети, управляющие компании) никогда не бывает одной универсальной программы. Всегда есть «ИТ-зоопарк»: 1С для бухгалтерии, старая биллинговая система (написанная 15 лет назад), новая программа диспетчеризации автотранспорта и современный портал Битрикс24.

Когда руководство ставит задачу «Сделайте так, чтобы при оплате счета в 1С у диспетчера появлялась галочка в Биллинге», программисты обычно выбирают самый быстрый и пагубный путь — интеграцию Point-to-Point (точка-точка): 1С напрямую стучится в базу Биллинга. Затем появляется Битрикс24 — и его тоже напрямую связывают с 1С и с Биллингом. И так далее.

2. Решение: концепция ESB

Чтобы разорвать хаос, в архитектуру вводится центральный элемент — шина данных. Представьте сетевой фильтр (удлинитель) или USB-хаб: компьютеру не нужно знать, как устроены мышка или клавиатура — они просто втыкаются в единый хаб по общему стандарту.

В программировании ESB — это мощная серверная программа, которая становится единым центром обмена сообщениями.

3. Три кита, на которых стоит ESB

Шина — это не просто труба, по которой летят данные. Это умный механизм, выполняющий три ключевые задачи, которые экономят бизнесу тысячи часов программирования.

4. Обогащение сообщений (Message Enrichment)

Иногда система-отправитель передает слишком мало данных. Датчик давления шлет в шину короткий сигнал: {"sensor_id": "845", "status": "critical"}. А Camunda для отправки бригады нужен полный адрес.

1. Шина получает сигнал sensor_id: 845.
2. «Ставит сигнал на паузу» и молниеносно делает скрытый запрос в базу оборудования: «Какой адрес у датчика 845?»
3. База отвечает: «Улица Ленина, 15, подвал».
4. Шина обогащает исходное сообщение и передает в Camunda полный пакет: {"sensor_id": "845", "status": "critical", "address": "Улица Ленина, 15, подвал"}.

С точки зрения архитектуры это гениально: ни датчику не нужно хранить адреса (он остается дешевым и простым), ни Camunde не нужно лезть в справочники оборудования. Всю «грязную работу» берет на себя шина.

5. Обзор рынка интеграционных решений

На рынке Open Source два абсолютных лидера — Apache Camel и WSO2 — исповедуют два совершенно разных подхода. Плюс для госсектора и крупных компаний в сравнение нужно включать отечественную Platform V Synapse (СберТех).

1. Что такое API

В старых монолитных системах программа (например, 1С) просто брала данные напрямую из своей собственной базы. В микросервисной архитектуре, где десятки программ разбросаны по разным серверам, прямое чтение чужих баз строго запрещено. Системы должны «общаться» культурно — через специально выделенные окна. Это окно и называется API (Application Programming Interface — программный интерфейс приложения): набор строгих правил, по которым одна программа может попросить другую что-то сделать или отдать данные.

2. Почему запрещаем прямой доступ к базам данных

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

1. Нарушение бизнес-логики. Если программа «А» просто запишет данные в таблицу программы «Б», программа «Б» об этом не узнает: не сработают проверки, не отправятся уведомления. Через API программа «Б» сама решает, как правильно обработать данные.
2. Безопасность. База данных содержит всё. API позволяет выдать только нужную часть: транспортной компании — номер машины и время выезда, но не зарплатные ведомости водителей.
3. Контракт (API Contract). Если программисты переделают структуру таблиц внутри своей базы, прямой доступ сломается. Но если есть API-контракт, они обязаны поддерживать его неизменным снаружи, даже если внутри всё переделали.

3. Swagger (OpenAPI): как API описывают для людей

API — это интерфейс для машин: у него нет кнопок и красивого дизайна. Как программист узнает, как правильно «попросить» данные у чужой системы? Стандарт документации — Swagger (OpenAPI): веб-страница, автоматически генерируемая из кода, где человеческим языком описано:

• Endpoint (эндпоинт) — адрес, куда обращаться, например https://api.vodokanal.ru/get_debt;
• Request (запрос) — что нужно отправить (например, номер лицевого счета);
• Response (ответ) — в каком виде придет ответ (цифра долга).

4. REST против SOAP: битва стандартов

Сегодня 90% новых мировых ИТ-систем строятся на REST. Но в госсекторе и ЖКХ SOAP все еще жив: вы не заставляете свои мобильные приложения учить этот сложный язык — вы пропускаете запросы через шину (ESB), которая переводит легкий REST в тяжелый SOAP и обратно, «на лету».

5. API Gateway: главный «охранник» вашей архитектуры

Представьте, что в ресторан одновременно ворвались 10 000 человек, или кто-то попытался пройти на кухню без пропуска. Официанты (API) не справятся, и работа предприятия встанет. Чтобы защитить микросервисы и шину от внешнего хаоса, в архитектуру внедряется API Gateway (Шлюз API) — единая точка входа для всех внешних запросов.

Аналогия: крупный бизнес-центр. Шлюз — это ресепшн и турникеты с охраной на первом этаже. Мобильное приложение бригадира не знает адреса серверов, где лежат 1С или биллинг — оно знает только один адрес: адрес вашего API Gateway. Подходит к ресепшену, показывает пропуск, и только тогда его направляют на нужный этаж.

6. Три главные функции шлюза

1. Аутентификация и авторизация. «Кто ты?» — шлюз проверяет логин, пароль или цифровой токен. «Что тебе можно?» — проверяет права: бригадиру Иванову можно запрашивать список своих заявок, а финансовые отчеты всей компании — нельзя (ошибка 403 Forbidden, запрос даже не доходит до 1С).
2. Rate Limiting (ограничение частоты запросов). Защита от перегрузок и DDoS-атак (когда систему заваливают миллионами фальшивых запросов). Правило: «Один IP может делать не более 100 запросов в минуту». Если система умных счетчиков сошла с ума и шлет по 5000 показаний в секунду, шлюз отбросит лишнее, спасая внутренние базы данных.
3. Маршрутизация и сокрытие архитектуры. Внешнее приложение обращается по красивому адресу api.vodokanal.ru/v1/payments, а шлюз «под капотом» перенаправляет запрос на скрытый внутренний сервер 192.168.1.45:8080/billing/pay. Завтра перенесете биллинг на новый сервер — мобильное приложение этого даже не заметит: вы просто поменяли маршрут на ресепшене.

7. Хранение данных: SQL против NoSQL

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

Отечественные СУБД: Platform V Pangolin и О.К.Е.А.Н.

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

1. Как НЕ надо делить систему (техническая нарезка)

Переход от монолита к микросервисам — это не просто техническая задача, а изменение мышления. Когда программистам дают задачу «распилить монолит», они часто начинают мыслить техническими слоями: один сервис для всех баз данных, один — для всей бизнес-логики (расчетов), один — для интерфейса. Это называется Horizontal Slicing (горизонтальная нарезка).

Почему это катастрофа? Если бизнес просит добавить новую галочку «Срочный ремонт» на экран диспетчера, программистам придется вносить изменения во все три слоя. Они будут ждать друг друга, тестировать всё вместе — и система останется такой же неповоротливой, как монолит. Получается «распределенный монолит», который работает еще медленнее, чем обычный.

2. Правильный подход: DDD (Domain-Driven Design)

Чтобы микросервисы приносили пользу бизнесу, ИТ-архитектура должна копировать структуру самого предприятия. Этот подход называется DDD (предметно-ориентированное проектирование): мы режем систему не горизонтально (по технологиям), а вертикально — по бизнес-функциям. В терминологии архитектуры это называется Bounded Context (ограниченный контекст).

У предприятия ЖКХ (управляющая компания, водоканал) есть четкие независимые отделы: Биллинг (считает тарифы, формирует квитанции), Диспетчерская (принимает аварийные заявки), Автопарк (управляет тракторами и водовозками). По правилам DDD каждый из этих отделов должен стать отдельным микросервисом. Микросервис «Диспетчерская» содержит внутри себя всё необходимое для работы диспетчера: свой интерфейс, свою бизнес-логику на Java и свою собственную базу данных.

3. Золотое правило: Database-per-Service

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

В монолите все таблицы лежали в одной базе: диспетчер брал ФИО жильца из таблицы «Клиенты», и бухгалтер брал ФИО из той же таблицы. В микросервисной архитектуре:

• Микросервис «Биллинг» хранит у себя ФИО жильца, номер счета и баланс;
• Микросервис «Диспетчерская» хранит у себя то же ФИО, адрес и историю аварий.

Почему нельзя сделать общую базу? Если будет общая, то программист «Биллинга», решив переименовать колонку FIO на FullName, мгновенно «сломает» микросервис «Диспетчерская». Раздельные базы гарантируют слабую связность (Loose Coupling): если сервер «Биллинга» сгорит, «Диспетчерская» продолжит принимать аварийные заявки, потому что у нее есть своя независимая база с адресами и фамилиями.

4. Правило «двух пицц» (Two-Pizza Team)

Как руководителю понять, правильного ли размера получился микросервис? Правило, придуманное в Amazon: микросервис должен быть такого размера, чтобы его могла полностью спроектировать, написать, протестировать и поддержать команда, которую можно накормить двумя пиццами (обычно 4–6 человек).

Если для поддержки сервиса «Биллинг» требуется 15 разработчиков — это уже не микросервис, вы снова создали монолит, и его нужно делить дальше (например, на «Тарификатор» и «Генератор квитанций»).

5. Синхронное и асинхронное взаимодействие

Предприятие ЖКХ — единый организм: если Диспетчерская оформила вызов сантехника (услуга оказана), Биллинг должен об этом узнать, чтобы выставить счет. Как изолированные программы должны общаться? Два принципиально разных подхода.

Синхронное взаимодействие реализуется через REST API или gRPC (более быстрый протокол от Google). «Диспетчерская» отправляет «Биллингу» вопрос «Какой баланс у Иванова?» и ждет ответа. Плюс: просто запрограммировать, ответ мгновенный. Минус: каскадные сбои — описаны на рисунке.

Асинхронное взаимодействие использует Message Brokers (брокеры сообщений) — серверы-почтальоны (Kafka, RabbitMQ). «Диспетчерская» кидает в брокер «Заявка №123 выполнена» и сразу продолжает принимать новые звонки. «Биллинг» забирает сообщение, когда готов. Минус: сложнее в разработке, результат не мгновенный (Eventual Consistency — согласованность в конечном счете).

6. Событийно-ориентированная архитектура (EDA) и паттерн Сага

Асинхронный подход породил самую современную парадигму — EDA (Event-Driven Architecture): микросервисы не отдают друг другу прямые приказы, а генерируют События — факты того, что что-то произошло. Умный счетчик шлет «Показания воды изменились» → Биллинг слушает и сам решает обновить счет → генерирует «Счет сформирован» → сервис уведомлений отправляет SMS жильцу.

Проблема распределенных транзакций. Когда базы были едиными, существовал механизм транзакций: если посередине перевода денег отключался свет, база сама откатывала всё. В микросервисах (у каждого своя база) классическая транзакция невозможна. Что делать, если «Биллинг» деньги списал, а «Склад» выдал ошибку (нет запчастей)?

Решение — паттерн Saga (Сага): цепочка локальных транзакций. Если один из шагов дает сбой, запускается цепочка компенсирующих транзакций в обратном порядке: Шаг 1 — списать деньги (успех) → Шаг 2 — выделить бригаду (сбой: нет свободных) → Компенсация Шага 1: вернуть деньги на счет жильца с пометкой «Отмена заявки». Именно Camunda — идеальный оркестратор для паттерна Сага: в BPMN-схеме есть специальный значок компенсации, который позволяет настроить возврат средств визуально, без сложного кода.

7. Выбор брокера: Kafka против RabbitMQ

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

1. Два столпа безопасности: аутентификация и авторизация

В микросервисной архитектуре безопасность должна быть централизованной: 20 разработчиков не должны писать модуль проверки логинов и паролей внутри каждого нового микросервиса — это долго, дорого и небезопасно. Всю работу с паролями выносим в отдельную инфраструктурную систему.

2. IAM (Identity and Access Management) и Keycloak

Для управления доступом разворачивается отдельный серверный продукт — IAM (Identity and Access Management), его также называют IdP (Identity Provider — поставщик учетных данных). Это специализированная, невероятно защищенная база данных, в которой хранятся профили всех сотрудников, жильцов и подрядчиков: логины, пароли в зашифрованном виде (хеши) и роли.

Почему это важно для заказчика: ни один микросервис («Биллинг», «Автопарк», Camunda) больше не хранит в своих базах ни одного пароля. Если хакер взломает микросервис «Диспетчерская», он не украдет пароли жильцов — их там просто нет, они изолированы в IAM-сервере.

3. SSO (Single Sign-On): один пароль на всё предприятие

SSO — механизм, при котором пользователь вводит пароль только один раз и получает доступ ко всем разрешенным корпоративным приложениям без повторного ввода. Как это выглядит для мастера участка:

1. Мастер утром открывает корпоративный портал (Битрикс24). Система перенаправляет его на страницу входа корпоративного IAM-сервера.
2. Он вводит логин и пароль. IAM-сервер проверяет их.
3. Затем мастер открывает на планшете программу управления складом. Система видит, что он уже прошел аутентификацию утром, и пускает его автоматически.
4. Если мастер увольняется, администратор безопасности нажимает одну кнопку «Заблокировать» в IAM-сервере — доступ мгновенно аннулируется ко всем программам предприятия.

4. Токен: что это такое (аналогия с отелем)

Этот «ключ» называется Token (электронный пропуск/маркер). Представьте заселение в отель:

1. Вы подходите на ресепшн (наш сервер Keycloak) и показываете паспорт (логин и пароль). Это аутентификация.
2. Администратор убеждается, что вы — это вы. Он не отдает вам ключи от всех дверей, а выдает пластиковую карточку-пропуск (токен).
3. На карточке магнитной лентой записано: «Гость из номера 415. Оплатил на 3 дня. Можно в свой номер и в спортзал, нельзя в кабинет директора». Это авторизация.
4. Вы подходите к номеру (наш микросервис или портал Битрикс24), прикладываете карту — дверь открывается. Двери не нужен ваш паспорт, ей достаточно правильной карточки.

5. JWT: вскрываем токен

Самый популярный в мире формат электронных пропусков — JWT (JSON Web Token). Многие думают, что токен — зашифрованный черный ящик. На самом деле JWT — это просто длинная строка текста, внутри которой хранится открытая информация. Любой разработчик может взять токен и прочитать, что там написано.

6. Как системы договариваются: OAuth 2.0 и OIDC

Если JWT — это сам электронный пропуск, то как звучат правила его выдачи? Мировые стандарты позволяют программам разных производителей (от 1С до мобильных приложений) понимать друг друга без переводчиков.

• OAuth 2.0 (Open Authorization) — стандарт, который позволяет выдать программе ограниченные права, не передавая ей пароль пользователя. Аналогия: ключ парковщика (Valet Key) — можно завести двигатель и проехать 100 метров, но открыть багажник этим ключом нельзя. На практике: приложение «Умный дом ЖКХ» просит у Keycloak доступ к вашим счетчикам — и получает токен, который может только читать счетчики, но не может оплачивать счета.
• OIDC (OpenID Connect) — OAuth 2.0 отлично выдает права, но ничего не говорит о том, кто этот человек. OIDC надстроен поверх OAuth 2.0 и добавляет в JWT информацию с фамилией «Иван Иванов» и его фотографией. Если корпоративный портал поддерживает OIDC, вход через Keycloak настраивается за 10 минут.

7. Ролевая модель: RBAC и ABAC

Кто решает, что именно будет написано в токене? Как система понимает, что Иванову можно удалять заявки, а Петрову — только смотреть? Для этого архитектор проектирует модель управления доступом — иначе программисты зашьют проверки прямо в код (хардкод), и система станет неуправляемой.

RBAC (Role-Based Access Control) — самый популярный и надежный стандарт. Проблема: 100 диспетчеров × 50 разных разрешений. Назначать разрешения каждому лично — администратор сойдет с ума. Решение: люди и разрешения никогда не связываются напрямую — между ними вводится прослойка «Роль». ИТ-архитектор создает роль «Старший_Диспетчер» и привязывает к ней разрешения: Создать_Заявку, Удалить_Заявку, Просмотр_Отчетов. Иванову просто назначают роль — он автоматически получает все права. Если правила компании меняются (диспетчерам запретили удалять заявки), администратор снимает «галочку» с самой роли в Keycloak — и это мгновенно применяется к сотне сотрудников.

ABAC (Attribute-Based Access Control) — эволюция, когда RBAC не хватает. Пример: два диспетчера, Иванов (Северный район) и Петров (Южный). RBAC потребует ролей «Диспетчер_Север» и «Диспетчер_Юг» — а если районов 50 и еще разделение по типам аварий? Ролей станут тысячи (взрыв ролей — Role Explosion). ABAC решает иначе, оценивая атрибуты: атрибут пользователя «работает в филиале Северный» + атрибут заявки «район Северный» → правило: разрешить доступ, если атрибуты совпадают. В Keycloak ABAC настраивается через визуальные конструкторы правил.

8. Единый источник правды: синхронизация прав в зоопарке систем

У Битрикс24 есть свои «Отделы» и «Рабочие группы», у Camunda — свои внутренние пользователи для распределения задач по веткам BPMN, у ваших Java-микросервисов — свои права. Архитектурное решение: сервер Keycloak становится Single Source of Truth (единым источником правды). Настраивается Identity Provisioning (синхронизация учетных записей): администратор заводит нового сотрудника Иванова только в одном месте — в Keycloak, назначает роль «Инженер». Keycloak сам автоматически отправляет команды в Битрикс24 (создать профиль) и в Camunda (создать профиль), прокидывая нужные роли. Никакого ручного дублирования в разных базах!

1. Почему старые методы поиска ошибок больше не работают

Это то, что в ИТ называют «Day 2 Operations» — система запущена в работу, и в ней произошел сбой. В эпоху монолитов программисты заходили на единственный сервер, открывали один большой текстовый файл — Log (журнал системных событий), — нажимали «Поиск» и сразу видели, на какой строчке кода произошел сбой. В микросервисной архитектуре этот метод абсолютно бесполезен.

Проследим путь одного простого нажатия кнопки «Оформить наряд» в целевой архитектуре ЖКХ: запрос прилетает с планшета в API Gateway → шлюз проверяет права в Keycloak → шлюз отправляет запрос в микросервис «Диспетчерская» → «Диспетчерская» кидает сообщение в очередь RabbitMQ → Camunda забирает сообщение и дает приказ через ESB → шина передает приказ микросервису «Склад». За одну секунду заявка «прыгнула» через 6 разных программ на 6 разных серверах. Без новой дисциплины 20 программистов могли бы потратить несколько дней, вручную собирая логи со всех серверов и сопоставляя их по времени.

2. Централизованное логирование и Correlation ID

Но даже собрав все логи в одном месте, возникает вторая проблема: ежесекундно льются тысячи строк от сотен диспетчеров — как понять, какие строчки относятся к зависшей заявке Иванова? Гениальный обязательный паттерн — Correlation ID (уникальная метка запроса):

1. Когда запрос впервые касается границы системы (попадает в API Gateway), шлюз генерирует случайный уникальный номер, например Trace-ID: 999-ABC, и «приклеивает» бирку к запросу.
2. Каждая следующая система пишет в свой лог строку с этой же биркой и передает ее дальше.
3. Результат: программист вводит 999-ABC в строку поиска и мгновенно видит всю цепочку шагов через все 6 серверов.

3. Три столпа наблюдаемости (Observability)

В современной архитектуре термин «Мониторинг» уступил место термину Observability (Наблюдаемость — способность системы самой рассказывать о своем внутреннем состоянии). Чтобы ИТ-отдел мог сказать, что система полностью управляема, она должна поставлять три вида данных:

4. Работа с логами: стек ELK (или OpenSearch)

5. Метрики (Prometheus) и визуальный пульт (Grafana)

Логи — отличный инструмент для расследования аварий, которые уже произошли. Но руководитель и системный администратор хотят узнавать о проблемах до того, как они сломают систему (например, когда жесткий диск заполнен на 95%). Для этого нужны метрики.

Prometheus — лидер сбора метрик, база данных временных рядов (TSDB). Главное архитектурное отличие — модель Pull (вытягивание): если логи сами «текут» в базу (Push), то Prometheus работает иначе. Он похож на обходчика с блокнотом: каждые 10 секунд Prometheus стучится в микросервисы через скрытый API-адрес /metrics и спрашивает: «Сколько оперативной памяти ты потребляешь? Сколько аварийных заявок сейчас в очереди?» Сервисы отдают цифры, и Prometheus складывает их в графики, привязанные к точному времени. Если сервис «упал» и не ответил на стук — Prometheus мгновенно это зафиксирует.

Grafana — инструмент красивых дашбордов: подключается к Prometheus, базам SQL, к 1С и переводит скучные цифры в спидометры, графики, круговые диаграммы и тепловые карты. Пример для ЖКХ: на одном огромном телевизоре в ситуационном центре диспетчерской — текущее давление в трубах (датчики IoT через Kafka), количество зависших процессов в Camunda (бизнес-показатели), загрузка процессоров на серверах Битрикс24 (ИТ-показатели). Все в одном окне.

6. Распределенная трассировка (Distributed Tracing)

А что делать, если система не выдает явной ошибки, а просто очень медленно работает? Диспетчеру нужно объяснить жильцу, почему страница с квитанцией грузится 15 секунд. Для поиска узких мест (Bottlenecks) применяется третий столп — Tracing, стандарты вроде OpenTelemetry, а среди продуктов — Jaeger или Zipkin.

Trace (трасса) — полный путь запроса от начала до конца, связанный тем самым Correlation ID. Трасса разбивается на Span (интервал/шаг): спан 1 (API Gateway): занял 10 мс; спан 2 (Диспетчерская): 40 мс; спан 3 (Склад): 4.85 секунды! Программист открывает интерфейс Jaeger, вбивает номер заявки и видит каскадный график (похожий на водопад), где сразу красным подсвечена самая длинная полоска. Споры между отделами («Это ваша программа тормозит!» — «Нет, ваша!») заканчиваются мгновенно.

7. Умные оповещения: Alertmanager и ловушка «усталости от алертов»

Grafana отлично показывает графики, когда на них кто-то смотрит. Но ночью администраторы спят — сервер должен сам будить людей. В экосистеме Prometheus есть модуль Alertmanager с умной логикой маршрутизации (не слать все ошибки всем подряд):

1. Проблема «У меня всё работает»

В эпоху монолитов установка программы (Deployment) была простой: сисадмин брал один большой файл, копировал на сервер заказчика и запускал. В микросервисной архитектуре у вас десятки программ — каждой нужна своя версия Java, свои настройки ОС, свои библиотеки. Самая частая фраза при сдаче проекта: «Я не знаю, почему сервер заказчика выдает ошибку. У меня на компьютере всё работает!»

Программист пишет код на ноутбуке с Windows и Java 11. А сервер заказчика работает на Linux с Java 8. Программа, идеально работавшая у разработчика, при переносе ломается из-за несовпадения окружения (Environment). Когда программ много, вероятность конфликтов версий близится к 100%. Эта ситуация получила название «Матрица из ада».

2. Решение: контейнеры (аналогия с морскими перевозками)

До 1950-х годов погрузка кораблей была хаосом: мешки с кофе, бочки с маслом, ящики с телевизорами. Грузчики тратили недели, чтобы уложить всё в трюм, а мешки часто рвались. Потом придумали стандартный морской контейнер: портовому крану стало абсолютно все равно, что внутри. В 2013 году компания Docker совершила такую же революцию в ИТ: разработчик упаковывает код в Container вместе с нужной версией Java, системными библиотеками и настройками. Системный администратор заказчика берет контейнер и просто запускает его — программа внутри думает, что работает на компьютере разработчика, и 100% не выдаст ошибку версий.

3. Почему одного Docker недостаточно: проблема масштаба

Если микросервисов всего 3, сисадмин запускает их вручную. Но представьте: комплексная система защиты периметра (СКУД) на критически важном объекте — очистные сооружения острова Белый для Водоканала. Запущено 50 контейнеров на трех разных физических серверах. В 3 часа ночи один сервер выходит из строя из-за скачка напряжения — вместе с 15 контейнерами. При обычном Docker система остановится: администратор проснется, удаленно подключится к резервному серверу и будет вручную запускать каждый из 15 упавших контейнеров. В критических инфраструктурах такой простой недопустим. Нужна программа, которая следит за контейнерами и управляет ими автоматически.

4. Kubernetes (K8s): «начальник порта»

Kubernetes (Кубернетис) — платформа для оркестрации контейнерами, изначально разработанная в Google. (K8s — потому что между первой буквой «K» и последней «s» ровно 8 букв.) Если Docker — матрос, который умеет переносить один контейнер, то Kubernetes — начальник порта, который знает, куда поставить каждый ящик, следит за их сохранностью и руководит всей логистикой.

5. CI/CD: автоматизация доставки кода

Вспомните, как обновляли системы ЖКХ 10 лет назад: в пятницу вечером сисадмин выгонял всех пользователей, останавливал сервер, вручную копировал файлы, запускал сервер и молился. Если возникала ошибка (Human Error), диспетчеры сидели без системы до понедельника. В современной архитектуре ручной перенос файлов строго запрещен. Используется конвейер CI/CD.

CI (Continuous Integration — непрерывная интеграция): 20 программистов ежедневно пишут сотни строк кода. Практика CI — весь новый код автоматически собирается и проверяется роботом несколько раз в день. Программист заканчивает задачу и отправляет код в центральное хранилище — Git (система контроля версий). Сервер CI мгновенно замечает новые строки: сам «собирает» из них программу и запускает автотесты. Если программист ошибся и новый код ломает расчет тарифов — сервер CI загорается красным и блокирует этот код. Ошибка даже не доходит до тестировщика, не говоря уже о заказчике.

CD (Continuous Deployment — непрерывная доставка): если код успешно прошел все автоматические тесты, CD забирает его, запаковывает в Docker Image и доставляет на боевой сервер (в Kubernetes). Главная магия CD — Zero Downtime Deployment (развертывание без простоя):

1. В Kubernetes работает старая версия «Биллинга» (1.0).
2. Сервер CD отправляет в K8s новый контейнер «Биллинга» (2.0).
3. K8s запускает 2.0 рядом со старой, не выключая старую, и проверяет, что новая версия успешно включилась.
4. K8s плавно, за долю секунды, переключает поток пользователей со старого контейнера на новый.
5. Старый контейнер удаляется. Система обновилась днем, прямо во время работы предприятия — и ни один диспетчер или жилец этого не заметил!

1. Итоговая схема: вся архитектура на одном листе

Перед вами — картина, которую вы теперь можете нарисовать с закрытыми глазами и объяснить любому заказчику. Пять горизонтальных «слоев»: пользователи, периметр с безопасностью, оркестрация и шина, профильные системы с брокерами, инфраструктура (Kubernetes) и наблюдаемость. Запомните эту схему — она является ответом на вопрос «куда мы вообще идем?»

2. План перехода: пять фаз без остановки бизнеса

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

3. Как лучше организовать обучение команды

Курс получился плотным и требует фундаментальной смены инженерного мышления — поэтому его прохождение нужно строго регламентировать. Четыре правила: