В прошлой серии: вход в суровый мир энтерпрайз архитектуры лежит через панель. То, что мертво, умереть не может, а посему в задании меня попросили отрефлексировать над диаграммой легаси и предложить перерождение. Но чтоб было веселей – минимум информации и всего четыре часа времени.
Некая недосказанность всегда присутствует на первых свиданиях. Жаль, что в этот раз она в плоскости тех.задания. Когда времени мало – проще танцевать от требований и ограничений, а не заниматься подтверждением парадокса выбора. Поэтому будем сразу говорить об архитектуре. На собеседованиях только и разговоров, что об архитектуре и о дизайне. Там говорят о том, как чертовски здорово наблюдать за огромным монолитным легаси, как он тает в волнах.
Чтоб утонуть в море возможностей, начнём с определения условий.
Догадки и додадки:
-
Система не занимается управлением и приёмом потоков, а только обработкой успешно законченных сессий. Задача стриминга, очереди ожидания, правильности и доступности исходных данных уже не наша проблема. Так же можно отсеять проблемы чтения. Если запись поступила на обработку – значит она без повреждений и доступна. (В реальном проектировании так и разделяют подсистемы – не надо тащить конвертацию форматов изображения и улучшения качества картинки в модуль распознавания текста. Делают конвейер отдельных модулей и медиатор. Например, микросервисы с 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), конфигуратор и обработчик ошибок и базу данных. Хостят это где-то локально у клиента и, возможно, в своём дата центре. На облачную инфраструктуру явно не тянет. Все оптимистичные предположения можно смазать свежевыжитым маслом лести: «Я уверен, что раз продукт популярный, то тут у вас все грамотно спроектированно, и я представляю себе вот такой вариант…»
Низкая целостность процессов, в отличии от данных. У данных один источник, а процесс поделён на части. Если один из обработчиков постоянно падает, то категоризатор об этом не знает и возможно будет ждать и возвращаться к обработке записи вечно. Общий процесс и состояние процесса не известно. Особо стоит обратить, что отсутствующий результат обработчика может быть как ошибкой/падением, так и приемлемым поведением. Такие вот процессоры Шредингера.
Много точек полного отказа (fragility). Каждый блок незаменим (single point of failure), и падение/остановка влияют на весь процесс. Судя по диаграмме, там нет разделения очередей. Если репозиторий не доступен – всё лежит. И даже не переваривает уже проглоченное. Но если он доступен, а упал процессор, мало того, что клиент не получит вызовы интеграции, то у нас ещё и сработает эффект плотины. Мы рассчитывали на 100 запросов в секунду, но репа накапливает записи и как только процессор вернётся, но у него и категоризации будет бесконечный поток. Слава богу, что процессор сам управляет своими задачами, а значит не утонет. Но SLA интеграции и сервисы на той стороне может затопить. Так что плотина у вас, а прорвать может у клиента.
Проблема масштабируемости/производительности (performance). Если процессинг явно можно распараллелить и выделить каждый в отдельный сервис без сохранения состояния (stateless), то вот категоризатор так не выглядит. В текущей архитектуре – это единый блок, который видит и делает всё. Да, и по заданию его трогать нельзя, но это уже само по себе проблема. О ней стоит заявить и учесть в новом дизайне.
Ограниченная пропускная способность (throughput). Это боль скорее всего самая головная из всех головных у бизнеса. Если учесть, что процессоры метаданных не всегда возвращают ответ и работают несколько минут, то скорее всего мы ждём впустую часть времени. Это предположение строится на том, что в диаграмме таймер Х < У. И (вы же понимаете, что предложение должно было начаться с этой буквы?) если начнём подставлять цифры и прикинем, что максимальное время обработки 5 минут, и таймер обработки тоже 5 минут, то логичный таймер категоризации будет 6 минут. Получается, что в случае, если у нас сессия с оператором меньше 6 минут, то система будет всегда в догоняющем режиме. А значит не способна давать полезный выхлоп 24/7. Иными словами, для нагруженного бизнеса нужно больше, чем одна система. Типа в течение дня работаем на системе 1, а ночью дообрабатываем, но работаем в системе 2. Чтоб дорабатывать в 2 днём. Сомневаюсь, что клиенты рады active-passive масштабированию по системе близнецов Диоскуров.
Вывод:
С одной стороны времени в презентации мало, но очень важно показать, что вы учли и знаете многое. Озвучивать всё нужно тезисно и уверено. Так как бы это сделал Карлсон. Не оставляя места сомнениям и вопросам. А вот расписать можно подробней, если есть время. После панельки вас попросят прислать презентацию и настоящий отсев претендентов пойдёт, когда выступят все. А там уже могут уделить отдельное внимание содержанию. Возможно, в приемной комиссии будут и люди, не участвовавшие в этом интервью, но очень желающие «всех посмотреть». Очень важно упомянуть про плюсы легаси архитектуры. Вам же сказали, что продукт успешный, так что своё φ высказать стоит, зайдя с комплиментов. Не стоит указывать в списке минусов неразрешимые проблемы либо то, что вы не смогли/захотели исправить в новом подходе. Разложить грабли надо так, что их можно было обойти. Вот тот самый exactly once – ну его на XOR.
Ответ на первые два вопроса готов. В общей презентации из 9 слайдов: 3 из них мишура (Титульный лист, Об авторе, Thank You!), 2 в этой статье, ещё 3 будут содержанием следующей.
Приглашение на собеседование |
|
Ответ на вопросы по легаси |
|
Новый дизайн и финал |
ссылка на оригинал статьи https://habr.com/ru/articles/826286/
Добавить комментарий