tgoop.com/emacsway_log/1490
Last Update:
После двух лет забвения по причине личных обстоятельств, наконец-то возвращаюсь к привнесению общественно-профессиональной пользы.
17 января совместно с командой закончил работу над созданием нагрузочного фреймворка для микросервисов, аналоги которого мне неизвестны (иначе я бы их применил).
Началось все с создания генератора объема фейковых данных (см. здесь и здесь) для микросервисов, который воспроизводил бы селективность индексов как в целевой системе.
При этом все зависимые объекты создаются автоматически, а вероятностная распределенность их внешних ключей соответствует селективности индексов целевой системы.
Поддерживаются композитные ключи (первичные и внешние). Вероятностная распределенность поддерживается как для композитного ключа целиком, так и для составляющих его ключей.
Поддерживается логика многоступенчатого создания агрегата (black-box), когда агрегат возможно привести в необходимое состояние только серией запросов через public API.
Скажу честно, что я не смог бы этого сделать, не будь за моими плечами четырех собственноручно написанных ORM на четырех разных языках программирования и пяти фейкеров. Полученный опыт оказался бесценным.
Конечно, писать свой ORM архитектору может и нет практической необходимости, но в чем я сейчас твердо убежден, так это в том, что успешность архитектора немыслима без нагрузочных fitness-functions. А там практические навыки применения PoEAA оказываются на вес золота, независимо от того, создаете ли вы ORM или генератор фейковых данных. И наивно полагать, что эта задача посильна рядовому программисту. Если вдруг где-то специалисты с такими навыками и засиделись на позиции программиста, то будьте уверены - долго они на этой позиции в такой компании не задержатся. Это к вопросу о том, должен ли уметь архитектор в код.
Вскоре мы обнаружили, что полученный генератор данных можно использовать и для нагрузочных тестов. Адаптировали его для работы с публичным API (вместо прямого доступа к БД), сделали поддержку multiprocess.
Интегрировали его с нагрузочным движком molotov. Изначально рассчитывали на Locust, но обнаружили, что asyncio там не поддерживается и его поддержка пока не предвидится. Позже я узнал от @nkhitrov, что решение все-таки есть.
Потом мы обнаружили, что полученное решение можно без труда использовать для Out-of-process Component (Acceptance) Testing.
Таким образом, нам удалось сделать тестовый фреймворк (на Python), который позволяет одновременно и генерировать фэйковые объемы данных, включая автоматическое создание всех зависимых объектов, и создавать нагрузочные скрипты, и выполнять component out-of-process tests.
Теперь хотим завернуть его в Gherkin, чтобы fitness-functions в нем описывать. И добавить декларативное описание моделей посредством YAML-file.
Свои функции он уже выполняет. На текущий момент исходный код проприетарен. В перспективе возможно его раскрытие (обсуждается с владельцем кодовой базы) или оказание услуг нагрузочного тестирования сторонним ИТ-компаниям.
Работаем!
BY emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Share with your friend now:
tgoop.com/emacsway_log/1490