Алексей @fuCtor
Backend developer
Information
- Rating
- Does not participate
- Location
- Санкт-Петербург, Санкт-Петербург и область, Россия
- Date of birth
- Registered
- Activity
Specialization
Backend Developer
Lead
Scala
Git
Docker
Redis
High-loaded systems
Designing application architecture
PostgreSQL
В Сириус ещё можно на экскурсии сходить. Там покажут расскажут чем занимаются, покажут лаборатории, стенды, все, куда можно зайти будет. Ещё столовая хорошая с демократичным ценником)
https://antithesis.com/docs/using_antithesis/sdk/go/overview.html вот SDK, тут видно, что они предоставляют замену random и другие вспомогательные пакеты, которые позволяют интегрировать код в платформу. Технические подробности того что легло в основу можно глянуть в исходниках FoundationDB.
Статика хорошо, но не принципиально, зависимости всегда можно доставить, а в Docker это вообще пофиг.
В мониторинге хотя бы базовые RED метрики, чтобы видеть что и как работает. А отдавать их можно по классике, в формате prometheus на /metrics ручке.
Как pet project хорошо. Но вот по протоколу для клиентов рекомендовал бы выбрать что-то стандартное. Сейчас только для PHP есть клиент, другие попробовать не смогут. Взяли бы gRPC, под любой язык готовый клиент из коробки.
Так же, не заметил метрик, любых средств мониторинга.
Для корректной работы circuit breaker нужно отказаться от промежуточных балансировщиков, либо перенести circuit breaker на них. В случае клиентской балансировки, клиент видит все хосты и может выкидывать их точечно, а не весь балансер разом.
Тут вопрос, а нужны ли они, если исходить из описанных пунктов, то:
Есть атомарные операции https://apple.github.io/foundationdb/developer-guide.html#atomic-operations
И если нам нужно писать сообщения, то получаем следующую структуру:
префикс/<channel>/<version>/<ts>/<user> = <payload>
version - может проставляться самой БД в момент коммита, что гарантирует всегда растущую последовательность
тогда чтение лога будет выглядеть как getRange(префикс/<channel>/<last_version>, префикс/<channel>/\xff)
В целом, не обязательно использовать CAS, если можно использовать особенности и возможности самой БД.
А смотрели для БД на что-нибудь ещё? По описанию не плохо подходит сюда FoundationDB, есть и сортировка, и внутренние "часы", она же версия, и полностью асинхронный.
Пробовали, но значимых различий не получили, на синтетике тоже не заметил, возможно синтетика была не подходящая или не выполнил требуемые условия, надо будет повторить. Больше понравился вариант с aperture, так как снизу было большое количество хостов и по метрикам сразу был заметен эффект от уменьшения активного множества.
Neo4j хорош, пока не надо на нем строить прод. С этого момента надо готовить кошелек, так как в бесплатной версии, можно сказать, для этого ничего нет. В текущих реалиях, даже будучи готовым заплатить не факт что их возьмут.
По описанию warden, вобрал некоторые идеи от linkerd, он кстати уже на go+rust переписан, и Twitter (Finagle), на котором тот базировался.
Как стартовая точка сойдёт, но теперь нужно провести к более преемлему виду. Класс Game смешивает и логику и данные, так делать не хорошо. Вынесите в отдельный класс, который будет выполнять это. В остальных классах тоже бы вынести. Case class без атрибутов лучше заменить на case object.
И даже такое есть www.tinkoff.ru/invest/web-terminal
Тут есть момент, из отчётности то они удалить ничего не могут. Следовательно в любом случае какие-то данные останутся. Аналогично как быть с бэкапами.
— есть два контура внешний и внутренний
— снаружи токен = oauth2 токен, со всеми плюшками, а внутри ходит JWT.
— при проверки oauth2 токена получаем короткоживущий JWT
— всё общение внутри уже идет используя именно JWT
Как результат на каждый запрос сервер авторизации запрашивается лишь раз, а остальные микросервисы довольствуются лишь данными из JWT, в принципе в подавляющем числе случаев достаточно UserID и набора прав.
Санкт-Петербург, Мегафон, LTE работает вполне, как раз пишу в пути сейчас. Да, на особо длинных участках бывает проседает в середине, но в целом не плохо.