Микросервисы *

Представьте: у вас пара сотен микросервисов, и вдруг всё ломается. А может даже не всё, а, скажем, только одна страница. Если вы хорошо знакомы с системой, то по мониторингам и логам быстро обнаружите проблему и пойдете её решать. Но иногда систему вы видите впервые, и на поиск бага могут часы, или даже дни.

Всем привет, меня зовут Саша Казанцев, я — тимлид команды “Clickme” в hh.ru. В этой статье расскажу о том, как мы внедряли трейсинг. 

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

Под катом: формат данных, способы отправки, типы метрик и их применение, кардинальность.

Продолжаем знакомиться с современной микросервисной архитектурой. Ведущий архитектор Группы «Иннотех» Александр Соляр рассказал об основных сложностях аналитиков, с которыми можно столкнуться при работе с микросервисами, и способах их преодоления.

Наверняка многие бекенд программисты сталкивались с задачей ограничением запросов к некоторому источнику данных. Существует множество решений этой проблемы:

1) хранить историю во внешнем источнике данных, как redis. Для вычисления возможности отправить запрос, нужно каждый раз ходить в этот источник данных, что может быть непозволительно в некоторых сферах (так как существенно увеличивается время обработки запроса)

2) не париться с limiter и анализировать ответ от внешнего источника данных и на основе его ответов, принимать решение когда и сколько запросов можно отправить (но такие ответы есть не у каждого сервиса и существует вероятность, что будут отправлены лишние запросы, что может привести к бану)

3) хранить историю запросов локально, но использовать алгоритм leaked bucket, но это не позволяет накидать несколько запросов и ждать

4) хранить историю запросов локально, но использовать алгоритм sliding window, можно накидать запросов и ждать какое-то известное время

О реализации sliding window для java пойдет речь в этой статье.

Пройдя много собеседований, выяснилось, что довольно приличная часть собеседующих, спрашивавших или как-то затрагивавших тему транзакций и их работы, не знают как работают транзакции и что означает для разработчика термин изоляция. Вплоть до архитектора в одной очень большой российской компании, для которого выводы, использованные мною для формулирования решения при прохождении архитектурной секции оказались чем-то вроде бреда. Пока готовится вторая статья (Миллиард абитуриентов МИРЭА 2), можно отвлечься и разобрать тему, продемонстрировать разработчикам что означает для них I в ACID.

Однажды мне понадобилось внедрить метрики в сервисы своей команды. С самого начала я не понимал, что именно хочу получить: одно дело — прикрутить библиотеку и нарисовать графики, другое дело — показывать осмысленные данные.

Мне нужен был гайд, который сочетает эти две вещи: сначала «почему так принято», а затем — «как правильно делать». В результате такой гайд мне пришлось написать самому. Его цель — объяснить разработчикам с любым бэкграундом, что такое метрики, как правильно о них думать и осмысленно использовать. Сначала гайд жил во внутренней документации Точки, но я решил сделать его публичным — возможно, кому-то этот опыт будет полезен. Разбираться будем с Prometheus и Grafana. Если у вас другой стек — не страшно. Мы затронем и фундаментальные темы: например, перцентили, производные и кардинальность.

Гайд будет выходить как цикл статей. Сначала посмотрим на архитектуру: как собираются метрики и где хранятся. Дальше разберемся с типами метрик — они не так просты, как кажется. Потом придется немного отвлечься на математику (но только с инженерной точки зрения!). И, наконец, научимся писать запросы, но не просто так: сразу посмотрим на разные грабли и неочевидные моменты.

Первые упоминания о практическом использовании микросервисной архитектуры появились в 2010-х годах. Но сейчас она стала стандартом для отрасли. Ведущий архитектор Группы «Иннотех» Александр Соляр рассказал о некоторых нюансах микросервисов, а также принципах их использования.

В современной экономике создание программного обеспечения (ПО) — это целая индустрия, которая, с одной стороны, оказывает помощь бизнесу в автоматизации и цифровизации всех процессов, а с другой стороны, самостоятельно приносит прибыль и создает виртуальные активы. В настоящее время проектирование в сфере R&D усложнилось, количество программистов постоянно растет, задачи для них становятся все более сложными. Эти причины привели к появлению новых методологий разработки ПО и видов архитектуры.

Современные веб-приложения многофункциональны, а цифровая трансформация, которая происходит сейчас со многими бизнесами, повышает требования к ПО. Приложение должно быть: легко масштабируемым, гибким и кроссплатформенным, быстро изменяемым под задачи пользователей. Данные требования задаются постановщиками задач уже на этапе разработки такого софта.

Для создания программного обеспечения, которое соответствует всем требованиям современного бизнеса необходимо предварительно серьезно изучить сам процесс разработки софта и выбрать правильную архитектуру.

Kubernetes, как система оркестрации, позволяет автоматизировать процесс развертывания сложных приложений и восстанавливать ожидаемое состояние кластера после сбоев. В общем случае приложение представляет собой резидентно запущенные контейнеры, которые обрабатывают запросы клиентов в цикле обработки событий, при этом при росте нагрузки могут создаваться дополнительные реплики (с использованием механизма Horizontal Pod Autoscaling). Однако, нередко бывают случаи, когда сервис используется не очень часто, но при этом в запущенном состоянии он забирает большое количество оперативной памяти или процессорного времени, и желательно обеспечить механизм запуска сервиса по запросу (или по внешнему событию). Для реализации такого варианта использования сейчас доступен инструмент knative, который был принят в марте 2022 года в качестве incubating-проекта в CNCF (Cloud Native Computing Foundation). В этой статье мы разберемся с основными понятиями knative и попробуем создать архитектуру приложения, основанную на событиях, с использованием eventing-возможностей knative.

Продолжаем обзор паттернов интеграции микросервисов. В первой части мы рассказали, зачем IT-специалистам нужны шаблоны интеграции, и для каких задач они подходят. Подробно остановилисьна Circuit Breaker, Sidecar, Ambassador, Anti-Corruption Layer и Async Request-Reply. Сегодня по плануразобрать Backends for Frontends, Cache-Aside, Gateway, Gateway Aggregation и Gateway Routing. 

Когда кто-то говорит о безопасности, в первую очередь имеет ввиду авторизацию и аутентификацию, но в контексте Kubernetes эти две составляющие являются лишь маленькими кусочками большого пазла.

В этой статье вы увидите, как пользователь с ограниченными правами может повысить свои привилегии и стать администратором кластера с неограниченными правами.

Привет! Меня зовут Михаил Боровиков, я тимлид команды, которая отвечает за систему процессинга заказов Lamoda — Orders Management. Эта система, словно «сердце» Lamoda, через которое проходит самый важный для бизнеса шаг — оформление заказа.

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

Для решения этой проблемы мы выбрали паттерн Outbox. И в этой статье я расскажу, что он из себя представляет, как мы его применили, почему пошли по пути at-least-once и не положились на работу одного брокера сообщений.

Недавно мы проводили вебинар «Обзор паттернов интеграции микросервисов». На нём энтерпрайз архитектор Пётр Щербаков рассказал, зачем IT-специалистам нужны шаблоны интеграции, и разобрал, для каких задач они подходят, а для каких нет. Для тех, кто пропустил или предпочитает читать, а не смотреть подготовили текстовый обзор интеграционных паттернов: Circuit Breaker, Sidecar, Ambassador, Anti-Corruption Layer и Async Request-Reply.

Всем привет! Сегодня мы поговорим об интеграционном тестировании платежного шлюза, но перед этим расскажу немного про нашу команду и наш проект. Мы (ContactPay) — самостоятельный финтех-стартап внутри QIWI, строим высокопроизводительный отказоустойчивый платежный шлюз и соответствуем стандартам безопасности PCI DSS. 

Как платежный шлюз мы интегрированы со множеством внешних API, это могут быть и платежные системы, и сторонние сервисы мониторинга, антифрода, KYC (know your customer) и так далее. 

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

Мы стараемся писать корректный код с наименьшим количеством  багов. Код должен быть читаемым, самодокументируемым и поддерживаемым. Кроме того, он должен быть безопасным, так как мы  финтех и у нас PCI DSS, это накладывает определенные требования к безопасности. А ещё код должен быть тестируемым. 

Сегодня мы поговорим о двух метриках — корректность и тестируемость. Одна метрика напрямую влияет на другую, через тестируемость мы добиваемся корректности в том числе, мы проверяем, насколько код ожидаемо работает. 

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

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

Часто основная сложность заключается в том, что нужно одновременно поддерживать уже существующий код монолита и параллельно внедрять новые принципы и подходы.  В статье я расскажу, как мы в Wrike, используя reverse engineering и немного кодогенерации, реализовали первые шаги по выделению отдельных микросервисов и запустили первый «почти настоящий» BFF-сервис в рамках нашего монолита.

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

Монолиты слишком раскритикованы

Сейчас, когда о какой-то компании говорят, что она продолжает развивать монолит, может показаться, что компания эта старомодная, а с масштабированием монолита у нее могут возникнуть проблемы, правда? Я решил написать о том, что некоторым людям (и мне в том числе) монолиты кажутся замечательными. Тем не менее, технология действительно ушла далеко вперед, и я думаю, что пора пересмотреть подход к созданию монолитов.

Всем привет. Я Игорь, тимлид в команде, которая занимается системой лояльности в CSI. Расскажу, как работают и устроены системы лояльности в ритейле, о том, как мы создали новую архитектуру системы Set Loyalty, что применяем из фреймворков и инструментов. 

Решения в области дистанционного банковского обслуживания юридических лиц (ДБО ЮЛ) довольно продолжительное время строились на монолитных автоматизированных системах подрядчика. Вначале было Legacy от BSS, потом решение от R-Style SoftLab. В таких монолитах нет ничего плохого, это отличный базис, который не просто поддерживает жизнеспособность системы, но и до определенного момента оставляет простор для развития. Однако есть в них и минусы, и чем больше массив становится, тем острее они ощущаются.

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