Подключение к DataBus через websocket. А он уже под капотом прячет Kafka и знает куда писать и откуда читать. Главная задача DataBus - гарантировать что данные записаны и не пропадут.
Дополнительным достоинством существования кластера kafka внутри ДЦ является хороший latency на продьюсинг, когда данные не пытаются in-sync разлиться между несколькими ДЦ. Либо я упустил, либо в статье про это преимущество не упоминалось?
Интересно услышать больше деталей про ваш data-bus и опыт эксплуатации его в продакшн-среде. А именно:
1. Планируете ли вы отдавать data-bus в open-source? Обычно внутренние технологии быстро устаревают, если разработка ведется только внутри компании.
2. Как вы решаете вопросы изменения количества партиций топика кафки без даунтайма?
3. С какими проблемами вы столкнулись при использовании? Как принимаете фидбэк от команд, которые интегрируются с вашим решением?
Как именно в постгресе это делать — не знаю, но могу предположить теоритически. Возьмите хэш-функцию, которая на входе берет UUID, а на выходе будет давать цифру шарда. Для этих целей неплохо подходит murmur hash.
Мы решили попробовать citusdb для создания шардирования. В принципе, намного удобнее, нежели самому пытаться настроить и сконфигурировать postgresql, плюсом идет cstore_fdw для того чтобы сделать колоночную базу. В 2gis не смотрели на подобные citus-у решения?
А докер только tcp-линкование поддерживает? Мне кажется, что минусов побольше должно быть. С чем столкнулся лично я:
1. Проброшенные переменные окружения пришлось самому писать в /etc/environments
2. Если несколько докер-контейнеров слинкованы и нужно перезагрузить один из них, то линк автоматически не поднимается
3. Пару раз запущенный образ докера повесил хост-систему на которой запускался
Хотя в целом, идея таких контейнеров мне пришлась по душе.
В случае именно с NPE я понимаю, что цепочные запросы очень сложны в расшифровке.
Но если предположить, что метод всегда возвращает правильный результат, либо бросает Exception — то цепочные запросы не должны быть настолько плохи.
Таким образом:
1. Если логику и проверки перенести в исходный метод и они написаны корректно (покрыты тестами) — цепочные запросы будут использоваться правильно и легко читаемы.
2. Если метод будет возвращать непроверенный результат — это может вызывать NPE и тут цепочные запросы могут усложнить жизнь.
И вот в первом описанном случае я все еще не вижу проблем.
Нормально читается, а проверки все можно встроить внутри методов и в случае если нет друзей или имени (да чего угодно) — бросать соответствующий Exception.
В результате, вы напишете логичную и понятную 1 строчку, а все кейсы-исключения будут вынесены в отдельные блоки, таким образом логика не размазывается.
PS/ Сам php-шник, но думаю, что тут подходы могут быть едины.
А я вот тоже не понимаю чем так категорично плох апач. Большого опыта работы с альтернативами нет, было 2 варианта:
1. nginx + apache — довольно неплохо справлялся с нагрузкой, ну работал через чайлдов и имел некоторые огрничения, но такая архитектура может выдержать немало rps
2. nginx + php-fpm — нагрузка на процах выросла по сравнерию с апачем, прироста в скорости никакого, возможно он сможет держать большую нагрузку, но было прекрасно видно, что время которое пришлось потратить на смену архитектуры ничем не окупилось.
Да все уже давно отвязано, инстансев не существует. Теперь меня амазон спамит тем что я ему 7 баксов должен, которые он мне милостиво занял для обслуживания тех самых айпишников.
У меня как-то не заладилось с AWS, так как срок бесплатного годового использования EC2 прошел, а удалить elastic ip невозможно или просто мне не удалось — деньги продолжал за него списывать. Пришлось вообще карточку удалить и больше нет желания пользоваться их сервисами.
Те спортсмены, которых знаю я вполне могут объяснить особенности крутящего момента подаваемого на маховик или колесо. Представляют на каких оборотах этот самый момент выше, а кроме этого еще понимают что такое мощность двигателя и зачем она нужна.
Привет, а почему про репликатор не рассказали? Это важная часть архитектуры.
Подключение к DataBus через websocket. А он уже под капотом прячет Kafka и знает куда писать и откуда читать. Главная задача DataBus - гарантировать что данные записаны и не пропадут.
DataBus смотрит только в локальный кластер. Однако, перед DataBus есть энвой, который в случае проблем - отправит в другой датацентр.
Дополнительным достоинством существования кластера kafka внутри ДЦ является хороший latency на продьюсинг, когда данные не пытаются in-sync разлиться между несколькими ДЦ. Либо я упустил, либо в статье про это преимущество не упоминалось?
Рома, спасибо за статью.
1. Планируете ли вы отдавать data-bus в open-source? Обычно внутренние технологии быстро устаревают, если разработка ведется только внутри компании.
2. Как вы решаете вопросы изменения количества партиций топика кафки без даунтайма?
3. С какими проблемами вы столкнулись при использовании? Как принимаете фидбэк от команд, которые интегрируются с вашим решением?
Symfony же?
1. Проброшенные переменные окружения пришлось самому писать в /etc/environments
2. Если несколько докер-контейнеров слинкованы и нужно перезагрузить один из них, то линк автоматически не поднимается
3. Пару раз запущенный образ докера повесил хост-систему на которой запускался
Хотя в целом, идея таких контейнеров мне пришлась по душе.
Но если предположить, что метод всегда возвращает правильный результат, либо бросает Exception — то цепочные запросы не должны быть настолько плохи.
Таким образом:
1. Если логику и проверки перенести в исходный метод и они написаны корректно (покрыты тестами) — цепочные запросы будут использоваться правильно и легко читаемы.
2. Если метод будет возвращать непроверенный результат — это может вызывать NPE и тут цепочные запросы могут усложнить жизнь.
И вот в первом описанном случае я все еще не вижу проблем.
В результате, вы напишете логичную и понятную 1 строчку, а все кейсы-исключения будут вынесены в отдельные блоки, таким образом логика не размазывается.
PS/ Сам php-шник, но думаю, что тут подходы могут быть едины.
1. nginx + apache — довольно неплохо справлялся с нагрузкой, ну работал через чайлдов и имел некоторые огрничения, но такая архитектура может выдержать немало rps
2. nginx + php-fpm — нагрузка на процах выросла по сравнерию с апачем, прироста в скорости никакого, возможно он сможет держать большую нагрузку, но было прекрасно видно, что время которое пришлось потратить на смену архитектуры ничем не окупилось.