Вчера автор побывал на прекрасной конференции Backend Talks 360 от компании Yandex и не в силах спокойно спать, не ответив конструктивной критикой на доклад Ильи Абрамова о работе Яндекс.Диска, автор принялся писать очередной «В интернете кто‑то не прав». Что из этого вышло — добро пожаловать под кат.

Для обычного пользователя разрешать уходить в минус по балансу - не может позволить себе ни одна организация, как говорилось в одном известном фильме - утром деньги, вечером стулья. Но для больших корпораций остановка платежей даже на секунду - это уже не проблема корпорации, а всего государства. Невозможно приостановить работу концерна (например Росатом) только потому, что в данный момент у него нет средств. На перезапуск может уйти куда как больше ресурсов.

Поэтому пора исправлять эту проблему в MireaPay и наконец-то добавить работу с крупными юр. лицами, которые будут называться корпоративными пользователями!

Продолжаем прорабатывать методы шардирования. В прошлой статье было предложено простое, но крайне трудозатратное решение по реализации динамического шардирования (когда ассоциация ключа и шарда лежат в отдельном сервисе, а не вычисляется при помощи функции). В этой статье предлагается универсальное решение, которое позволяет гибко настраивать параметры шардирования и при этом не быть перегруженной возможностями, из-за которых производительность неуклонно снизится.

Пришло время заключительной статьи проекта Mireapay, в этой последней статье программы минимум автор расскажет о том, как шардировать сервисы и какие варианты возможны. Но что самое главное, как это сделать просто и не тратить лишнее время на разработку в дальнейшем.

Если ваш сервис рассчитан на миллиарды пользователей, то несомненно возникнет вопрос о масштабировании.

Ранее, автор уже рассмотрел способ масштабирования через партицирование. В данной статье рассмотрим шардирование сервиса Баланс дабы обеспечить его работу с миллиардами пользователей без необходимости использовать суперкомпьютеры, а при желании вовсе запускать на "кофеварках".

Деньги - кровь экономики, а кредиты - уровень сахара. Ни одна современная платёжная система не может считаться полноценной, если отсутствует возможность кредитования производства - то, без чего современное производство не может существовать в принципе. Если вам интересно, как Mireapay работает с задолженностями и сможет ли наконец автор получить твердо и четко сервис с производительностью 100 рпс, то добро пожаловать под кат!

Проводить платежи без транзакций да ещё и без ограничения по количеству запросов? Разве это возможно? Если желаешь узнать как, то добро пожаловать под кат!

В прошлой статье автором были выявлены проблемы производительности в следствие блокировок и других причин. В этой статье попробуем с ними разобраться.

Спустя три месяца с публикации самой популярной статьи автора наконец-то удалось собрать первый прод и настроить его. Если вам интересно развитие проекта mireapay, а так же желаете выяснить почему по статистике 9 разработчиков из 10 считает DevOps потрясающими, то добро пожаловать под кат.

При разработке микросервисов рано или поздно возникает вопрос о специализированном микросервисе, через который проходят запросы и маршрутизируются в нужный. Это необходимо не только с точки зрения безопасности (в одной точке аудита можно увидеть все нужные события), но так же с точки зрения производительности. Ваш микросервис выполняющий важную функцию наверняка использует массу ресурсов, например подключения к БД - даже если обработка плохого запроса не требует подключения к БД, то она гарантированно ворует ресурс ЦП. Разумеется можно покупать все более производительные сервера, но такой путь ни к чему не приведет.

Если вас интересует эта тема, то добро пожаловать под кат.

Наверняка в вашем проекте используется очередь сообщений (не важно kafka, pulsar или какой-нибудь зайчик). Основной проблемой является подробное тестирование работы вашей системы. Рассмотрим варианты решения и посмотрим, что там у автора в рукаве.

В прошлой статье был предложен вариант для создания docker образов БД для последующего использования в разработке и тестирования приложений в пайплайнах гитлаба.

Из-за перехода на новую инфрастуктуру k8s 1.30 (restricted psp) и новый гитлаб 17.3 все это ломается. Поэтому придется исправлять ситуацию!

В это нелегкое время, так сложно найти работу, когда первокурсники МИРЭА уже пишут курсовые с микросервисами на 1к рпс, а выпускники каждый по системе на миллиарды пользователей. Видимо старому Java-коту ничего не остается, кроме как беседовать с вечностью и её сестрой бесконечностью. Если не они, то кто поможет коту найти работу?

Статью можно прочесть в формате pdf.

Уже немало копий поломали в поиске грааля идеального способа интеграционного тестирования с использованием БД.

Вашему вниманию предлагается способ решения этой проблемы самым минималистичным способом без необходимости создавать угрозы безопасности вашего кластера или создавать разработчикам невыносимые условия труда. Впрочем что может быть хуже сломанной кофе-машины или отсутствия лавандового рафа?

В прошлой работе автор представил описание архитектуры платформы приемной коммисии для обработки миллиарда абитуриентов за один день. В этой работе автор предлагает разработать, используя Spring + JDBCTemplate и Kafka микросервисы для предложенной архитектуры.

Пройдя много собеседований, выяснилось, что довольно приличная часть собеседующих, спрашивавших или как-то затрагивавших тему транзакций и их работы, не знают как работают транзакции и что означает для разработчика термин изоляция. Вплоть до архитектора в одной очень большой российской компании, для которого выводы, использованные мною для формулирования решения при прохождении архитектурной секции оказались чем-то вроде бреда. Пока готовится вторая статья (Миллиард абитуриентов МИРЭА 2), можно отвлечься и разобрать тему, продемонстрировать разработчикам что означает для них I в ACID.

В предыдущей статье, была рассмотрена модель данных, необходимая для хранения информации об абитуриентах. Теперь пришло время показать, как используя реляционные БД можно обрабатывать модифицирующие запросы от миллиарда абитуриентов. А что бы расставить все точки над i, предлагаемая архитектура должна обрабатывать миллион модифицирующий запросов в секунду. Используя реляционные БД, гарантировать, что все возможные комбинации обрабатываются за сутки для миллиарда абитуриентов, каждому из которых предоставляется 20 вариантов! С ростом числа абитуриентов требования по железу должны рости линейно.

Этим летом абитуриентам было жарко, МГУ по проходному баллу почти превратился в ПТУ, а кто-то успешно поступил в вооруженные силы РФ, сам того не желая. Отсутствие автоматизации в 2021 году, способной обработать распределение абитуриентов по учебным заведениям, а так же необходимость написать продолжение предыдущей статьи, описывающей основы теории о Распределенной Авторизации (РА) побудило решить эту детскую задачу автоматизации. Посмотрим, сколько же рпс нам в этом раз отсыпет антилопа.

Пока индексируется github (спасибо лимиту в 5000 запросов в час), поговорим пока о тестировании парсеров. Обсудим пожелания к процессу разработки грамматик, их тестирования и контроля качества так, что бы не превращаться в существо на картинке.