Пробы на роль Архитектора: наступление
В прошлой серии: вход в суровый мир энтерпрайз архитектуры лежит через панель. То, что мертво, умереть не может, а посему в задании меня попросили отрефлексировать над диаграммой легаси и предложить перерождение. Но чтоб было веселей — минимум информации и всего четыре часа времени.
Некая недосказанность всегда присутствует на первых свиданиях. Жаль, что в этот раз она в плоскости тех.задания. Когда времени мало — проще танцевать от требований и ограничений, а не заниматься подтверждением парадокса выбора. Поэтому будем сразу говорить об архитектуре. На собеседованиях только и разговоров, что об архитектуре и о дизайне. Там говорят о том, как чертовски здорово наблюдать за огромным монолитным легаси, как он тает в волнах.
Knockin' on Heaven’s Door: на берегу архитектуры
Чтоб утонуть в море возможностей, начнём с определения условий.
Догадки и додадки:
Система не занимается управлением и приёмом потоков, а только обработкой успешно законченных сессий. Задача стриминга, очереди ожидания, правильности и доступности исходных данных уже не наша проблема. Так же можно отсеять проблемы чтения. Если запись поступила на обработку — значит она без повреждений и доступна. (В реальном проектировании так и разделяют подсистемы — не надо тащить конвертацию форматов изображения и улучшения качества картинки в модуль распознавания текста. Делают конвейер отдельных модулей и медиатор. Например, микросервисы с ESB)
Все сессии идут с участием оператора и в систему одновременно не поступает записей больше числа операторов. А значит у нас не может быть непредсказуемой взрывной нагрузки из-за потока клиентов. Всё по теории ограничений. В данном случае нам не нужна пропускная способность больше, чем осилят принять операторы. Мы можем сразу высчитать максимальную возможную нагрузку на систему. Из необходимых данных у нас отсутствует еще размер/длинна сессии с оператором. Если минимально значимая сессия у нас 30 секунд и есть 100 операторов, то получать наша легаси система может максимум 200 вызовов в минуту с пиком в 100 за раз. Стоит учесть и выхлоп системы — вызовы API, но об этом дальше.
Вызовы API не блокируют систему. В идеале, конечно, мы совсем не хотим ждать ответа и хотелось бы просто куда-то постучаться и получить код 200 (не путать с грузом). Но если я правильно определил, что это точка интеграции, то значит API — это внешние системы и мы не можем управлять как они работают. На том конце может быть бодрый и отдохнувший REST, а может и мыльный SOAP. В случае более тяжелых систем и железок можно готовиться к TCP/UPD. Поэтому я заранее предлагаю быть готовым обсудить это, но по возможности убрать из проблем легаси, а значит и сэкономить нервы на следующем этапе. Легитимным предположением будет, что внешняя система получает данные и даёт ACK (подтверждение) в ответ. Заниматься обработкой данных она будет потом. Ну, а судя по диаграмме, в которой внешних игроков нет — какого-то особого результата нам от нее вообще не надо. Вот на этом невысказанном предположении и держится весь хрупкий механизм интеграции.
Категризатор обрабатывает все записи с полными метаданными, проводя их через все категории. Условный набор правил для вызова API не пропускает ничего. Раз нам известно, что он срабатывает по таймеру и обрабатывает всё, что доступно — мы рассматриваем легаси как проход по всему списку без всяких ухищрений с фильтрацией и поиском.
Запись, которая прошла, все обработчики переходит в архив сразу после категоризации. То есть полная категоризация происходит только один раз и только после всех мета процессоров. Это, видимо, сейчас решается тупо таймером. Сначала ждём всех обработчики, а потом размечаем категории.
Каждый обработчик (Processing Engine) работает независимо. Значит они не учитывают результатов других обработчиков и не конкурируют за саму запись. Можно даже уточнить, что каждый получает свою копию. Опять-таки сводим легаси к проходу по списку, без графа зависимостей, вхождение в ступор (deadlock) и бесконечных циклов.
Репозиторий служит лишь для хранения и предоставления доступа к записям и мета-данным. CRUD. Мы не хотим, чтоб в хранилище были бизнес функции. Всякие процедуры, триггеры и тд. На оригинальной схеме не было исходящего соединения из репозитория, но на всякий случай не будем предполагать, и что входящие выполняют вызовы функции.
Клиент всегда работает с одной и той же установкой системой (instance). Скорее всего система вообще устанавливается и работает локально у каждого из клиентов компании. Но SaaS — уже не новость, идея то родилась на вебе и хостингах. Вполне возможно, что мелкие клиенты работают с дата центром компании. Диаграмма не противоречит идее просто поднять всё на виртуалках в облаке. Lift & Shift — дорого, неэффективно, быстро. В таком случае хотелось бы, чтоб клиента не кидало от репы к репе как внучку и Жучку. Тем самым не усложняло нам жизнь с требованием запускать API только раз.
Предварительный итог:
Не совсем понятно, что изображают блоки в диаграмме — отдельно стоящие сервисы или модули внутри монолита. Я предполагаю, что это набор монолитов. Менеджер процессинга и обработчики — один большой камень, а категоризатор — другой. Каждый из них имеет свой интерфейс (UI/API/CLI), таймер (scheduler), конфигуратор и обработчик ошибок и базу данных. Хостят это где-то локально у клиента и, возможно, в своём дата центре. На облачную инфраструктуру явно не тянет. Все оптимистичные предположения можно смазать свежевыжитым маслом лести: «Я уверен, что раз продукт популярный, то тут у вас все грамотно спроектированно, и я представляю себе вот такой вариант…»
Карлсон не оставляет места сомнениям и вопросам.
Ответ на первые два вопроса готов. В общей презентации из 9 слайдов: 3 из них мишура (Титульный лист, Об авторе, Thank You!), 2 в этой статье, ещё 3 будут содержанием следующей.
