ฝัง
- เผยแพร่เมื่อ 19 ม.ค. 2022
- Видео с онлайн-конференции Software Architecture fwdays'21, которая прошла с 27 октября по 2 ноября 2021 года.
Описание доклада:
Поговорим об архитектуре в BigTech, выборе технологий и принятых "правилах".
Коснемся темы свободы в принятии архитектурных решений для команд Product и Core.
Углубимся в Fintech решение, созданное как важный компонент глобального SaaS: микросервисы, API и очереди, Event Sourcing, Feature Toggles, SDLC, CI/CD, DevOps, мониторинг, аналитика и т.д.
Страница доклада:
fwdays.com/event/architecture...
Больше докладов и видео по теме конференции:
fwdays.com/event/architecture...
Fwdays более 10 лет занимается организацией масштабных конференций для разработчиков таких направлений: JavaScript, .NET, Python, Data Science, PHP, QA, Highload, Architecture, DevOps, Databases.
Больше информации про актуальные события:
fwdays.com/events
Подписывайтесь, чтобы первыми узнавать про старт продаж билетов по самой выгодной цене:
Facebook: / fwdays
Twitter: / fwdays
Telegram: t.me/highload_fwdays - วิทยาศาสตร์และเทคโนโลยี
![Request Lifecycle у Prom.ua [ukr] / Віталій Харитонський](http://i.ytimg.com/vi/urR97QharXs/mqdefault.jpg)
![Request Lifecycle у Prom.ua [ukr] / Віталій Харитонський](/img/tr.png)
![Как задизайнить Facebook за пол часа или секреты System Design Interview [rus] / Алексей Петров](http://i.ytimg.com/vi/Be7INI_U6GY/mqdefault.jpg)
что бы не было деградации при CQRS добавляеться кеширующий пайплайн, зачастую типа кафки котороя обеспечивает куда большую пропускную способность чем сторейдж.
дополнительно создаются так называемые промежуточные агрегаты которые тоже записываются. Промежуточный агрегат это суммация куска ивентов который прошли и все ок.
Это можно сравнить с подтверждением транзакции на блокчейне, если N блоков замайнилось то все история безопасна и тразакция валидирована. Таки тут. В итоге мы получаем вместо 5М ивентов, 1к промежуточных агрегатов которые уже куда как проще прочитать и применить.
Есть еще всякие методы - но зачастую узкий и под конкретный кейс. Проще говоря решаем проблемы по мере их понимания.
20мин прослушал вообще пока вода.
Хотелось бы видеть собственно сами NFR, либо хотя бы базову стату RPS, Bandwidth, etc. Услышать как реально устроено решение, а не что вообще это такое, об этом в вики есть.
Ну вот например у вас ивенты идут напрямую в базу причем мускуль. Следовательно у вас одна точка жестко отвечает за рид/врайт при том что она не то что бы для этого писалась. К этому еще добавляем доп внутренний трафик на репликацию и шардинг, который у реляционных баз не самый лучший тем более у мускуля(хотя снова таки какой мускуль бо их уже версий штук 20). Сколько например занимает времени поднять новый агрегат, сколько среднее время запроса агрегата, почему нету прокси пулов к бд, как происходит исключение дублирования ивента и тому подобное?
Проще говоря вот вы что то рассказали, но опытом не поделились, и другие в других проектах его использовать не смогут. Следовательно все сказанное теряет смысл.
Весь ваш доклад по сути можно свести к словам "там где это типично - используйте ивент сорсинг".
зачем юзать реляционку если вы не юзаете реляционность?
По правде, это совсем не критично. Скорее всего, на старте проекта у команды было больше опыта с mysql и планировались джойны и транзакции. Потом бизнес попер. Нужно было быстро добавлять новые фичи. MySql , кроме джойнов, продолжал не вызывать проблем. Джойны убрали. И в какой-то момент переход с sql на nosql оказался слишком трудоемким и не стоящим возможных выгод.
А если проще то Легаси) А мигрировать на лету не решились потому что риски.
@@bubblesort6368 Легаси или не легаси - дискуссионный вопрос. Разные люди понимают разное под «легаси». Если решение поддерживается, развивается и позволяет оперативно реагировать на новые запросы бизнеса, то может и не легаси совсем.
@@bohdan4677 проблема в том что команда потратила кучу времени на нормальное маштабирование мускуля, хотя это же время можно было потратить на миграция на то что проблем особых вызывать не будет и даст запас прочности на будущее.
Собственно именно такие решения и принимает арх и это то зачем он нада.
@@bubblesort6368 наличие ботлнека при быстрорастущем бизнесе это куда большие риски.
При этом риски как и легаси должны быть прописаны и мониториться. Для легаси должна быть составлена аналитика влияния на бизнес и сроки погашения тех долга. Иначе в какойто момент бизнес встанет.
Особенно когда говориться что быстрый выпуск новых фич очень критичен
про логи честно убили.
- тоесть хранить логи в бд S3 это не секьюрно. Хранить логи в другой бд уже секьюрно?
- зашифрованные данные можно дешифровать, это не хеш, и есть куча опытных блек-спецов которые могут это сделать и даже чисто ради фана?
- зачем вообще в трейс логах персональная инфа?
- почему безопасность важна только для логов, а в отсальном будь как будь, особенно учитывая что все реквесты внутри системы у вас ходят без тлс(один сервак вскрыли и все добрый вечер)?
Вообщем после видео кол-во вопросов только выросло
инженеры - это не архитекторы. это всеравно что генералы - это наши солдаты. только вот обучение и поыт разный нада для них и ответсвенность разная.
Как говориться - если все отвечают за что то - то не отвечает никто.
Вон в грамарли не было архов.. и там пришел пиздец, ибо каждый городил как хотел и что хотел. В стиле я художник я так вижу.
Настолько всё абстрактно, что практического смысла в презе - 0