В роликах из предыдущего поста отличная мысль Дениса о сложности. То, с чем часто сталкиваются архитекторы, начиная от непонимания команды и заканчивая непринятие объема от бизнеса. Мы последнее время много спорили и анализировали возможность внедрения в проект практик CQRS на предмет решит ли это наши проблемы и какие другие привнесет. Вопрос действительно сложный и места для экспериментов тоже нет. Нельзя просто так сказать "теперь мы делаем вот так". То, что одному человеку очевидно, другим людям может быть совсем не понятно и наоборот.
Как известно любая архитеткура это набор компромиссов и само проектирование это меньше половины работы, так как затем начинается сложный процесс внедрения, особенно когда в команде не 3-5 разработчиков а 50+ и кодовая база уже накопилась немаленькая.

Внезапно целый чей-то проект, рабочий, коммерческий, в открытом доступе на гитхабе https://github.com/automagistre/automagistre

История о поиске решения для распреденных кронов

В прошлом месяце искали решение для распределенного запуска кронов. Задача: три отдекльных, но при этом идентичных кластеров проекта, на которые балансируется весь трафик и каждая крон таска должна запускаться только один раз в одном кластере. Вначале казалось что все достаточно просто: делается где-то лок и проблема решена. Начали искать непосредственно то самое "где-то" для хранения локов.
Посмотрели первым https://dkron.io/, который выглядел очень интересно. Однако у него нужный функционал федерации оказался только в платной версии (750$ в год). Но дело даже не в платности, а (внезапно!) отсутствии триала. То есть просто взять и потыкать нельзя, необходимо сначала заплатить. Такая агрессивная политика разработчика немного оттолкнула.
Далее был рассмотрен вариант запуска через очереди, который вроде бы очень просто выглядит: при срабатывании крона мы не запускаем процесс, а ставим его в очередь. Однако, при более детальном рассмотрении начали всплывать нюансы. Все равно требовался лок с обеспечением атомарности между кластерами.
И тут вспомнили про Consul и про наличие у него замечательной фичи https://www.consul.io/commands/lock специально для такой задачи и разработанной. Consul хорошо работает в распределнных системах, имеет простой АПИ, готовые клиенты под наш стэк, и что самое главное не потребует масштабных переписываний всех команд, как в предыдущих случаях.
Пока еще тестируем и пробуем это решение, но выглядит оно очень много обещающе. До конца марта обкатаем в проде и расскажем о результатах.

https://github.com/jasontaylordev/CleanArchitecture Хоть и на шарпах, но разобраться не проблема. Сейчас как раз пытаюсь текущий проект повернуть в сторону чистой архитектуры. Главные проблемы как ни странно не с пониманием всей командой проекта (50+ иразработчиков) ценностей и принципов. Главная сложность как это контролировать, как не допустить расползания и скатывания в Big Ball of Mud от ошибочных действий.
Думаю через какое-то время родится история как это в итоге работает в продакшене 🙂

Мой коллега Денис Черносов продолжает делать полезные видосы

Следующее видео от Дениса. На этот поговорит о PlantUML https://youtu.be/85jKCusr6tk

Первый выпуск GoLang дайджеста от нашего коллеги Вадима Тимофеева 👍
https://habr.com/ru/company/vseinstrumenti/blog/541612/

Напоминаю, что завтра пройдет митап про MySQL, нагрузкам и асинхронности https://habr.com/ru/company/vseinstrumenti/news/t/540566/ В программе мероприятия два доклада и дискуссия на тему асинхронности в PHP и будущего этого направления в языке.
Для наиболее активных участников подготовлены приятные подарки в виде слонов 👆

Начало 12 февраля в 17:00 Ссылка на регистрацию https://vi-tech.timepad.ru/event/1546475/

Сходил на запись подкаста "Между скобок" про работу архитектора https://soundcloud.com/between-braces/12-anton-gubarev-rabota-arkhitektora

https://habr.com/ru/company/vseinstrumenti/blog/544640/ Подъехал очередной выпуск Golang дайджеста

Перевозим сайт на распределнную работу в 3ДЦ. Казалось бы простая задача с запуском cronjob в независимых кластерах вылилась в пробы нескольких вариантов. Consul, DKron, чуть ли не база. В итоге решение нашлось на удивление простое - использовать Redis SETNX. В очередной раз убеждаюсь, что надо думать проще изначально. https://news.1rj.ru/str/vseins_tech/15

Тем временем у кого-то сгорел делый ЦОД https://habr.com/ru/news/t/546264/ Хотя в голове не укладывается как такое могло произойти. Это же не сарай чтобы раз и все. Там серверов на столько денег, что проще нули считать сразу. И при таких рисках вложения в противопожарную безопасность должны быть максимальными казалось бы. Но видимо где-то просчет оказался.

Каеф

Deptrac https://github.com/qossmic/deptrac Жизненно важная тулзовина для контроля архитектуры проекта. Позволяет настраивать правила, по которым проверяет зависимости между директориями или неймспейсами. Правил достаточно много разных и можно формировать их по имени класса, имени директории, родителям или интерфейсам. И конечно же можно использовать регулярки.
Пример. Мы разделяем наш код на бандлы, которые взаимодействуют между собой через контракты, такой антикоррупционный слой. Проверка deptrac-ом внедрена в CI, и он смотрит чтобы не было обращений между бандлами только по контрактам.
Попутно разделяем бандлы на слои. И опять deptrac позволяет мониторить соблюдение этого правила и отсутствия прямой зависимости, например, домена от инфраструктуры или от приложения.
Его наличие дает возможность спать спокойно и не бояться, что завтра вся архитектура проекта начнет расползаться и трещать по швам. Особенно когда ваш репозиторий на несколько десятков человек.

Как-то незаметно прошло мимо появления такой необходимой штуки как https://www.asyncapi.com/ Это как OpenApi только для асинхронных сообщений например очередей, событий и т.д. В довесок уже идут готовые инструменты: парсеры, генераторы и даже actions для github. Очень и очень интересная инициатива с уже большой дорожной картой.

Нашлось уже несколько появлений в эфире упоминания этой спецификации

https://linuxfoundation.org/en/press-release/linux-foundation-will-host-asyncapi-to-support-growth-and-collaboration-for-industrys-fastest-growing-api-spec/

https://engineering.salesforce.com/asyncapi-and-openapi-an-api-modeling-approach-db9873695910

Интересный разбор различных способов объединения массивов в PHP в плане скорости работы и потребления памяти от нашего коллеги Алексндра Зубарева http://zualex.com/posts/php-array_merge-performance-in-a-loop/

Еще одна статья от автора разбора кишков array_merge. На этот раз пережовывается один из способов управлением памятью в PHP. В статье приводятся примеры и объяснения, что такое copy-on-write https://zualex.com/posts/copy-on-write-php/

Вчера на Highload Олег Бартунов рассказывал про будущее jsonb в postgres. Доклад получился очень углубленным и обязателен для тех кто использует jsonb. Но главное что стало понятно - проделана огромная работа и предстоит проделать ещё больше.

История из жизни коллеги, пример как можно красиво отшить 🙂 Уже как только не мониторят кандидатов. Скоро ситуация будет как с банками, запустят холодный обзвон роботами.