Рубрика «микросервисы» - 11

Переход к микросервисной архитектуре требует пересмотра подхода к разработке, тестированию, сопровождению, проектированию – иными словами, ко всем аспектам жизненного цикла программных компонентов. В этом посте мы расскажем о практиках, к которым пришла команда архитекторов Acronis на пути к лучшим API компонентов. Рассказ будет включать как постановку задачи, так и анализ ее решений. Возможно, кому-то этот пост покажется “капитанским”, кому-то будет неясно почему упустили супер-решение Х, но надеемся, что вам он будет интересен и полезен. Строителей микросервисов приглашаем под кат – почитать и оставить свои комментарии.

image
Читать полностью »

Пока весь мир, вместо того, чтобы нарезать салаты готовиться к встрече Нового года, следит за развитием ситуации с nginx, мы решили не усугублять и не готовить серьезную научную статью, не шокировать технологиями наступившего будущего и не грузить очень хитрым алгоритмом. Мы тоже пользуемся nginx и надеемся, что и с его создателями и с ним все будет хорошо. И нам (да и не только нам) важно, чтобы ситуация разрешилась не как подарок Деда Мороза, а как естественный ход событий.
Т — значит творчество - 1
Читать полностью »

Как Kafka стала былью - 1

Привет!

Я работаю в команде Tinkoff, которая занимается разработкой собственного центра нотификаций. По большей части я разрабатываю на Java с использованием Spring boot и решаю разные технические проблемы, возникающие в проекте.

Большинство наших микросервисов асинхронно взаимодействуют друг с другом через брокер сообщений. Ранее в качестве брокера мы использовали IBM MQ, который перестал справляться с нагрузкой, но при этом обладал высокими гарантиями доставки.

В качестве замены нам предложили Apache Kafka, которая обладает высоким потенциалом масштабирования, но, к сожалению, требует практически индивидуального подхода к конфигурированию для разных сценариев. Кроме того, механизм at least once delivery, работающий в Kafka по умолчанию, не позволял поддерживать необходимый уровень консистентности из коробки. Далее я поделюсь нашим опытом конфигурации Kafka, в частности расскажу, как настроить и жить с exactly once delivery.

Читать полностью »

Прим. перев.: Service mesh — явление, которое ещё не имеет устойчивого перевода на русский язык (более 2 лет назад мы предлагали вариант «сетка для сервисов», а чуть позже некоторые коллеги стали активно продвигать сочетание «сервисное сито»). Постоянные разговоры об этой технологии привели к ситуации, в которой слишком тесно переплелись маркетинговая и техническая составляющие. Этот замечательный материал от одного из авторов оригинального термина призван внести ясность для инженеров и не только.

Service Mesh: что нужно знать каждому Software Engineer о самой хайповой технологии - 1
Комикс от Sebastian Caceres

Введение

Если вы инженер-программист, работающий где-то в районе бэкенд-систем, термин «service mesh», вероятно, уже прочно закрепился в вашем сознании за последние пару лет. Благодаря странному стечению обстоятельств, это словосочетание захватывает отрасль все сильнее, а хайп и связанные с ним рекламные предложения нарастают словно снежный ком, летящий вниз по склону и не подающий никаких признаков замедления.

Service mesh зародилась в мутных, тенденциозных водах экосистемы cloud native. К сожалению, это означает, что значительная часть связанной с ней полемики варьируется от «низкокалорийной болтовни» до — если воспользоваться техническим термином — откровенной чуши. Но если отсеять весь шум, можно обнаружить, что у service mesh есть вполне реальная, определенная и важная функция.

В этой публикации я попытаюсь проделать именно это: представить честное, глубокое, ориентированное на инженеров руководство по service mesh. Я собираюсь ответить не только на вопрос: «Что это такое?», — но и «Зачем?», а также «Почему именно сейчас?». Наконец, попытаюсь обрисовать, почему (по моему мнению) конкретно эта технология вызвала такой сумасшедший ажиотаж, что само по себе интересная история.Читать полностью »

Привет!

В этом релизе мы сосредоточились на производительности и качестве. Вместе с другими командами JetBrains, мы занимались оптимизацией производительности, повышением отзывчивости интерфейса, улучшением существующей функциональности.

Чтобы правильно расставить приоритеты, мы полагались на ваши отзывы и благодарим всех, кто делился идеями и сообщал об ошибках в нашем трекере. В результате мы исправили более 1600 проблем, которые в общей сложности получили около 4000 голосов пользователей.
Читать полностью »

Привет! Этот пост-отчёт с митапа Backend United, нашей серии тематических встреч для разрабочиков серверной части. Пятая встреча получила название «Шаурма», и здесь мы говорили о микросервисах: о способах синхронного и асинхронного взаимодействия между ними, организации потоков данных и роли Кафки в микросервисной архитектуре.

Заходите под кат, если вам интересны эти темы. Внутри поста — все материалы встречи: видеозаписи докладов, презентации спикеров, отзывы гостей митапа и ссылки на фотоотчёт.

Что внутри шаурмы: микросервисы, распределенные системы и Кафка. Делимся материалами со встречи Backend United #5 - 1

Читать полностью »

Разработка MQ JMS приложения на Spring Boot - 1

Разработчики приложений, работающие на Java, при использовании интерфейса JMS, часто предпочитают работать со Spring Framework. Spring может упростить написание кода новых приложений, предоставляя шаблоны для общих паттернов (templates for common patterns) и успешно используется в течение многих лет с классами MQ JMS. Класс Spring JmsTemplate является ключевым интерфейсом, но он по-прежнему зависит от конфигураций и зависимостей в коде.

Spring Framework включает в себя различные модули для различных нужд. Одним из таких компонентов является Spring Boot. Spring Boot стартеры удобно подтягивают все зависимости и библиотеки авто-конфигураций, необходимые для использования конкретной технологии. Это позволяет очень легко начать работу с новым приложением и технологией, быстрее, чем работать непосредственно с классами, такими как JmsTemplate. Итак, как мы можем воспользоваться этим легким доступом для приложений MQ?

Переведено @middle_java
Читать полностью »

Привет! 30 ноября в нашем офисе вместе с сообществом Golang Москва мы проводили митап по случаю десятилетия Go. На встрече обсуждали машинное обучение в Go-сервисах, решения для мультикластерной балансировки, приёмы для написания Go-приложений под Cloud Native и историю Go.

Заходите под кат, если вам интересны эти темы. Внутри поста — все материалы встречи: видеозаписи докладов, презентации спикеров, отзывы гостей митапа и ссылки на фотоотчёт.

Go на десяточку: видео и фото с юбилейного митапа - 1

Читать полностью »

Перевод статьи подготовлен специально для студентов курса «Инфраструктурная платформа на основе Kubernetes».


Service mesh для микросервисов. Часть III. Более глубокий взгляд на Istio - 1

Это третья статья из серии публикаций, посвященных  Kubernetes и технологии service mesh (также известной как «сеть микросервисов» и «mesh-сеть микросервисов»). В предыдущей статье мы изучили основы работы с Istio и выяснили, как этот инструмент помогает настраивать и администрировать сложные облачные архитектуры. Так, с его помощью можно сконфигурировать mesh-сеть микросервисов и получить некоторые возможности централизации в распределенной микросервисной среде. Сегодня мы более подробно изучим функции Istio, чтобы по достоинству оценить преимущества технологии service mesh.Читать полностью »

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

Принцип security through obscurity не работает. Если пойти погуглить насчет новостей в разрезе «Клиента банка Х взломали и увели Y рублей», то такие новости будут всегда. Почти каждый день (почти — потому что не всегда об этом пишут).

Первое правило антифрода — никому не рассказывать про антифрод - 1

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

Поэтому система, которая считается защищенной только потому, что люди не знают, как она работает — вообще ни разу не защищенная. А вот чем такая система открытее, тем быстрее въедливое сообщество укажет своим критически настроенным перстом на все косяки в реализации. Что позволит эти косяки устранить.

Я работаю именно в парадигме открытости протоколов и систем, и в этом посте я хочу рассказать про устройство стандартного антифрода, о работе нашего в RBK.money, почему будущее за OpenSource, а также о том, как всё это может работать в идеальном мире.

Который мы с вами и можем приблизить.

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js