Привет, я фронт, и за десять лет разработки в энтерпрайзах, стартапах и некрупных компаниях я впервые деплою свой код сам и отвечаю за его эксплуатацию, а не только за проектирование и разработку сервиса. О том, как я до этого дошел и почему не собираюсь останавливаться, в этой статье.
В октябре прошлого года мои коллеги представили на EnvoyCon доклад "Построение гибкой подсистемы компрессии в Envoy". Вот он ниже
Судя по статистике сегодняшней статьи от SergeAx, тема компрессии сетевого трафика оказалась интересной многим. В связи с чем я немедленно возжелал вселенской славы и решил кратко пересказать содержание доклада. Тем более, что он не только о компрессии, но и том, как можно упростить сопровождение сетевой подсистемы как backend'а, так и мобильного frontend'а.
Привет, коллеги!
В феврале необязательно доставать чернила и плакать — можно и радоваться.
Во-первых, Grafana заапрувила новую версию нашего плагина для мониторинга Kubernetes: KubeGraf v.1.5.0 доступен для инсталляции.
Во-вторых, оказалось, что за полтора года с момента выхода первой версии плагин скачали четверть миллиона раз!
Если вы хотите узнать, чем плагин стал лучше и удобнее в новой версии — добро пожаловать под кат.
Envoy — это высокопроизводительный программируемый прокси L3/L4 и L7, на котором основано множество реализаций service mesh, например, Istio. Envoy обрабатывает трафик с помощью сетевых фильтров, которые можно объединять в цепочки, чтобы реализовывать сложные функции для контроля доступа, преобразования, обогащения данных, аудита и так далее. Чтобы расширить функционал Envoy, новые фильтры можно добавить одним из двух способов:
Прим. перев.: автор этой статьи — Ben Nadel, сооснователь и главный инженер InVision App Inc. Миссию своей команды, поддерживающей серверную инфраструктуру компании, он сам характеризует как «advocate for the users», т.к. её главная цель — гарантировать пользователям InVision «получение опыта, который они заслуживают». Его опыт — яркая иллюстрация того, что микросервисы не серебряная пуля.
Если вы следите за мной в Твиттере, то наверняка заметили, что периодически я публикую победные твиты о возвращении одного из наших микросервисов в InVision обратно в монолит. Обычно эти твиты сопровождаются гифкой, в которой Танос вставляет последний Камень бесконечности в Перчатку бесконечности. Нахожу ее вполне уместной, поскольку воссоединение камней придает Таносу невероятную силу — так же, как воссоединение микросервисов придает силу мне и моей команде. Меня много раз спрашивали, почему я избавляюсь от микросервисов. Настало время поделиться своими мыслями по поводу этого путешествия в мире разработки веб-приложений…
У меня возникла задача настроить отказоустойчивый Bare Metal кластер для комплексного приложения, в связи с чем и возникла данная статья. Сразу хочу сказать, что не являюсь экспертом в K8S, однако имею опыт развертывания продуктовых кластеров DC/OS (экосистемы, основанной на Apache Mesos).
Долгое время K8S меня отпугивал тем, что, при попытке его изучения, тебя закидывают кучей концепций и терминов, отчего мозг взрывается.
Event storming — метод, который смещает акцент у событий с технического на организационный и бизнес уровни и помогает создать устойчивую модульную систему. Он нередко используется в контексте моделирования микросервисов. Но как применить его на практике?
При создании системы на микросервисах можно легко получить распределенный монолит. Event Storming не уберегает от этого на 100 %, но позволяет существенно снизить риск этого события. О том, как именно этого добиться, рассказал в своем докладе на конференции TechLead Conf 2020 практикующий консультант по архитектуре, процессам разработки и продуктовым практикам Сергей Баранов.
Всем привет. Меня зовут Нещадин Иван, и я расскажу про оптимизацию одного из микросервисов Авито на Go. История построена вокруг различных инструментов, которые доступны в языке, и пойдёт от простых примеров к более сложным.
В этой статье мы поговорим о том, как установить и настроить службу обнаружения (service discovery) для Java-микросервисов.
Сегодня мы хотим обсудить практическую сторону внедрения концепций Service Level Objectives и Service Level Indicators. Рассмотреть, что входит в понятия SLI, SLO и Error budget, как рассчитывать эти показатели, как за 7 шагов внедрить их отслеживание и как в последствии контролировать эти показатели на примере инструмента Instana.
Определимся с терминологией
Service Level Indicator (SLI) – это количественная оценка работы сервиса, как правило, связанная с удовлетворенностью пользователей производительностью приложения или сервиса за заданный период времени (месяц, квартал, год). А если говорить конкретнее – это индикатор пользовательского опыта, который отслеживает одну из многочисленных возможных метрик (рассмотрим их ниже) и, чаще всего, представляется в процентном эквиваленте, где 100 % - означает отличный пользовательский опыт, а 0% - ужасный.
Service Level Objectives (SLO) – это желаемое, целевое значение нашего SLI или группы SLI. При установке SLO необходимо указывать реально достижимое значение для каждого конкретного SLI. Ниже мы рассмотрим логику установки SLO на примере конкретных SLI.
Также важно понимать, что SLO – это наш внутренний показатель качества работы сервиса и/или приложения, в отличие от Service Level Agreement (SLA), который обычно устанавливается бизнесом как внешнее обязательство по доступности сервиса перед клиентами компании.
Когда дело доходит до работоспособности и мониторинга, распределенная архитектура может подкинуть вам пару проблем. Вы можете иметь дело с десятками, если не сотнями микросервисов, каждый из которых мог быть создан разными командами разработчиков.
При работе с крупномасштабной системой очень важно следить за ключевыми показателями этой системы, работоспособностью приложений и достаточным объемом данных, чтобы иметь возможность быстро отслеживать и устранять проблемы. Пребывание в ОБЛАЧНОЙ среде, такой как AWS, Google Cloud, Azure, еще больше усугубляет проблему и затрудняет обнаружение, устранение и локализацию проблем из-за динамического характера инфраструктуры (вертикальное масштабирование, временные машины, динамические IP-адреса и т. д.).
Хочу рассказать о том, как мы оптимизировали наш оркестратор микросервисов.
Потому что в случае с такого рода сервисами наш любимый подход "пихаем в базу - строим индексы" не работает. Как минимум потому что базы нет).
В статье расскажу про общие подходы к оптимизации оркестраторов, что и как мы пробовали, как переходили с блокирующего RestTemplate на неблокирующий WebClient.
Как пытались подружить его с CompletableFuture, как положили прод, как нашли проблему, и какие сделали из всего этого выводы.
Забегая вперёд, могу сказать, что переход на неблокирующий веб-клиент для нашего оркестратора, в разы увеличил производительность, а ещё, если думаете использовать WebClient совместно с CompletableFuture, то лучше не надо имеет смысл кое-что проверить.
Когда сервисы интегрируются при помощи Kafka очень удобно использовать REST API, как универсальный и стандартный способ обмена сообщениями. При увеличении количества сервисов сложность коммуникаций увеличивается. Для контроля можно и нужно использовать интеграционное тестирование. Такие библиотеки как testcontainers или EmbeddedServer прекрасно помогают организовать такое тестирование. Существуют много примеров для micronaut, Spring Boot и т.д. Но в этих примерах опущены некоторые детали, которые не позволяют с первого раза запустить код. В статье приводятся примеры с подробным описанием и ссылками на код.
Хочу поделиться своим опытом реализации микросервисной архитектуры поверх actor-model фреймоворков, таких как AKKA и Microsoft Orleans.
Моя гипотеза: если использовать один стек для реализации микросервисов, то можно:
О… Похоже на «серебряную пулю»! Давайте разберемся, так ли это.
