Java developer
Всем привет, меня зовут Алексей Жуков, я старший программист в студии IT Territory. В этой статье я расскажу, как мы строили игровой сервер для Rush Royale. Объясню, почему создание сервера в геймдеве — это не так просто, как кажется на первый взгляд, а также опишу плюсы и минусы реактивного подхода, который мы использовали в нашей работе.
Я делаю много ревью для чужого кода на Ансибл и много пишу сам. В ходе анализа ошибок (как чужих, так и своих), а так же некоторого количества собеседований, я понял основную ошибку, которую допускают пользователи Ансибла — они лезут в сложное, не освоив базового.
Для исправления этой вселенской несправедливости я решил написать введение в Ансибл для тех, кто его уже знает. Предупреждаю, это не пересказ манов, это лонгрид в котором много букв и нет картинок.
Ожидаемый уровень читателя — уже написано несколько тысяч строк ямла, уже что-то в продакшене, но "как-то всё криво".
strace. Вот что случалось при запуске strace в Docker-контейнере на моем ноутбуке:$ docker run -it ubuntu:18.04 /bin/bash
$ # ... install strace ...
root@e27f594da870:/# strace ls
strace: ptrace(PTRACE_TRACEME, ...): Operation not permittedstrace работает через системный вызов ptrace, поэтому без разрешения для ptrace ничего не заработает! Но это легко исправить, и на моем ноутбуке я все сделала вот так:docker run --cap-add=SYS_PTRACE -it ubuntu:18.04 /bin/bashstrace не работает, а --cap-add=SYS_PTRACE все исправляет?
Эта статья содержит краткую выжимку из моего собственного опыта и опыта моих коллег, с которыми мне днями и ночами доводилось разгребать инциденты. И многих инцидентов не возникло бы никогда, если бы всеми любимые микросервисы были написаны хотя бы немного аккуратнее.
К сожалению, некоторые невысокие программисты всерьёз полагают, что Dockerfile с какой-нибудь вообще любой командой внутри — это уже сам по себе микросервис и его можно деплоить хоть сейчас. Докеры крутятся, лавешка мутится. Такой подход оборачивается проблемами начиная с падения производительности, невозможностью отладки и отказами обслуживания и заканчивая кошмарным сном под названием Data Inconsistency.
Если вы ощущаете, что пришло время запустить ещё одну аппку в Kubernetes/ECS/whatever, то мне есть чем вам возразить.
English version is also available.
Привет, Хабр!
Я работаю в команде Tinkoff, которая занимается разработкой собственного центра нотификаций. По большей части я разрабатываю на Java с использованием Spring boot и решаю разные технические проблемы, возникающие в проекте.
Большинство наших микросервисов асинхронно взаимодействуют друг с другом через брокер сообщений. Ранее в качестве брокера мы использовали IBM MQ, который перестал справляться с нагрузкой, но при этом обладал высокими гарантиями доставки.
В качестве замены нам предложили Apache Kafka, которая обладает высоким потенциалом масштабирования, но, к сожалению, требует практически индивидуального подхода к конфигурированию для разных сценариев. Кроме того, механизм at least once delivery, работающий в Kafka по умолчанию, не позволял поддерживать необходимый уровень консистентности из коробки. Далее я поделюсь нашим опытом конфигурации Kafka, в частности расскажу, как настроить и жить с exactly once delivery.
В последние два месяца лета в управлении хранилищ данных (Data Warehouse, DWH) Тинькофф Банка появилась новая тема для кухонных споров. 
Всем привет! Я бэкэнд-разработчик, пишу микросервисы на Java + Spring. Работаю в одной из команд разработки внутренних продуктов в компании Тинькофф.
У нас в команде часто встает вопрос оптимизации запросов в СУБД. Всегда хочется еще чуть-чуть быстрее, но не всегда можно обойтись продуманно выстроенными индексами — приходится искать какие-то обходные пути. Во время одного из таких скитаний по сети в поисках разумных оптимизаций при работе с БД я нашел бесконечно полезный блог Маркуса Винанда, автора книги SQL Performance Explained. Это тот самый редкий вид блогов, в котором можно читать все статьи подряд.
Хочу перевести для вас небольшую статью Маркуса. Ее можно назвать в какой-то степени манифестом, который стремится привлечь внимание к старой, но до сих пор актуальной проблеме производительности операции offset по стандарту SQL.
Привет.
Меня зовут Ваня, и я Java-разработчик. Так получилось, что я много работаю с PostgreSQL – занимаюсь настройкой БД, оптимизацией структуры, производительностью и немного играю в DBA по выходным.
За последнее время я привёл в порядок несколько баз данных в наших микросервисах и написал java-библиотеку pg-index-health, которая облегчает эту работу, экономит моё время и помогает избежать некоторых типовых ошибок, допускаемых разработчиками. Именно об этой библиотеке сегодня и пойдёт речь.
Основная версия PostgreSQL, с которой я работаю, это 10-ка. Все используемые мною SQL-запросы также проверены на 11-й версии. Минимальная поддерживаемая версия — это 9.6.
Началось всё почти год назад со странной для меня ситуации: конкурентное создание индекса на ровном месте завершилось с ошибкой. Сам индекс, как водится, в невалидном состоянии остался в базе. Анализ логов показал нехватку temp_file_limit. И понеслось… Копнув поглубже, я обнаружил целый ворох проблем в конфигурации БД и, засучив рукава, с блеском в глазах принялся их чинить.
WelcomeService service = new WelcomeService();@RestController
public class WelcomeController { private WelcomeService service = new WelcomeService(); @RequestMapping("/welcome")
public String welcome() {
return service.retrieveWelcomeMessage();
}
}
Источник: 'Nova typis transacta navigatio' (Linz: s.n., 1621), p.12 (British Library, G.7237).
Часто во время разговоров о Docker я слышу мнения, с которыми не совсем согласен.
«Docker по своей сути предназначен для крупных компаний»
«под OSx у него экспериментальная поддержка, под Windows работает еле-еле»
«Я не уверен, что смогу быстро развернуть его локально»
… и еще много всякого.
В этих утверждениях есть доля истины (см. ниже мифы 3 и 5), но она мала, и по большей части реальная картина получается искаженной.
А есть еще и наполненные жаргоном статьи о том, как при использовании немалого количества фреймворков обрабатывать 10к миллионов запросов в секунду. И это с помощью всего лишь 30к контейнеров при автоматизации 5к микросервисов, размещенных на шести сотнях облачных виртуальных машин…
Что ж, нетрудно догадаться, почему Docker окружен таким количеством мифов.
К сожалению, эти мифы очень живучи. И главное их достижение заключается в том, что они пугают разработчиков и не дают им решиться на использование Docker.
Давайте поговорим о самых распространенных мифах – тех, с которыми я сталкивался и в которые верил, – и попробуем найти в них истину, а также решения, если таковые имеются.
Я должен признаться. Я ненавижу docker. Всей своей душой. Это самая ужасная софтина, которую я видел за последние 10 лет.
С одной стороны, я очень уважаю одноименную компанию. Ребята из Docker Inc. реально популяризировали контейнеризацию. Теперь о ней не знает только ленивый. С другой стороны, ничего принципиально нового они не изобрели — контейнеризация на момент, когда Docker "выстрелил", уже существовала более 30 лет (начиная от chroot, вспомним еще jails и zones, ну, и наконец-то — namespaces & cgroups).
Круто, что docker реально ускоряет разработку во множество раз. Если вести ее правильно, то даже без потери в качестве. В любом случае, docker здесь, от него не деться и приходится им пользоваться.
Но почему у меня этот продукт с логотипом кита вызывает столь разнообразные эмоции? Ниже я перечислю те моменты, от которых бомбит. Возможно, что читатель будет не согласен или, напротив, найдет какие-то вещи, о которых не знал и сочтет интересными.
Disclaimer: все написанное ниже является личным мнением автора и может как отражать реальность, так и не отражать реальность. Материал строго провокационного характера и основной целью является не унизить или обидеть кого бы то ни было, а скорее заставить людей включить голову и осознать масштабы глубин (с).
Недавно я осознал нехватку вводных обучающих материалов о современной сетевой балансировке и проксировании. Я подумал: «Почему так? Балансировка нагрузки — одна из ключевых концепций для построения надёжных распределённых систем. Ведь должна быть доступна качественная информация об этом?» Я поискал и обнаружил, что информации мало. Статьи в Википедии о балансировке и прокси-серверах содержат обзоры некоторых концепций, но не могут похвастаться последовательным описанием предмета, особенно в том, что касается современных микросервисных архитектур. Поиск в Google информации о балансировке в основном возвращает сайты вендоров, заполненные модными терминами и скупые на подробности.
В этой статье я постараюсь восполнить нехватку постепенного введения в современную сетевую балансировку и проксирование. По правде сказать, это объёмная тема, достойная целой книги. И чтобы статья не получилась безразмерной, я постарался ряд сложных задач подать в виде простого обзора.