В серии из трех статей рассказываем о переходе с монолитной на микросервисную архитектуру. Разбираемся, когда и кому это действительно нужно, рассматриваем 7 миграционных шаблонов и самый больной вопрос: «Как быть с данными?».
Привет, меня зовут Алексей, я руковожу цифровыми продажами одного из крупнейших региональных банков нашей страны. Специфика моей работы заключается в том, что под моим крылом сконцентрирован и бизнес, и IT. Поэтому сегодня я расскажу, как при помощи технических решений мы решали базовые потребности бизнеса, а точнее, как мы сделали систему мониторинга и навигации звонков на бесплатном движке, увеличили конверсию и при этом сократили расходы.
В этой статье расскажем о решении для поддержки бизнес-процессов оператора и управления доходами. Также поделимся опытом разработки одного из его компонентов с использованием микросервисов. Эта информация будет полезна как для инженеров, которые собираются применять микросервисную архитектуру в разработке приложений, так и для владельцев и менеджеров продуктов, которые должны иметь представление о ее основах для оценки связанных с проектом рисков.
На тему миграции с монолита на микросервисную архитектуру были написаны замечательные статьи, например, эта, возможно, относится к лучшим примерам. Преимущества и недостатки этих архитектур должны быть достаточно очевидны. Однако я хочу поговорить о другом: о стратегии. Мы создаем монолиты, потому что с ними легче начинать работу. Микросервисы обычно возникают в силу необходимости, когда наша система уже находится в продакшне.
Однако при принятии решения о необходимости миграции возникает множество вопросов: как вы определяете границы услуги? Как вы проверяете свойства самовосстановления архитектуры микросервиса?
Это особенно сложно с учетом распределенности сервисной сетки. Нам нужно иметь представление обо всем приложении, поскольку его фрагменты разделены. Наша цель — сохранить преимущества, которые мы имели в унаследованном монолите, избежав при этом сильной связанности, которая является его неотъемлемой частью. В данной статье я расскажу о некоторых практических подходах, которые вы можете использовать при выполнении этой миграции.
Интеграционная или shared база данных это архитектурный подход с которым мне часто приходилось сталкиваться, и практически никогда эта встреча не сулила ничего хорошего. Как правило, команда выбирает данный подход по нескольким причинам:
Не надо писать никакие контракты и схемы для интеграций сервисов между собой через API, а каждый может читать/писать из одной БД.
Не надо думать о синхронизации данных, если данные в БД записались значит консистентность достигнута.
Не надо снимать бэкапы с нескольких хранилищ, если можно снимать с одной единственной БД.
В своем стремлении перейти на микросервисы я столкнулся с аналогичными проблемами. Чаще всего я работал с клиентами и корпорациями, чей «микросервисный» дизайн приводил к единому моносервису. По сути, монолитное приложение было заменено действительно большим RESTful API.
Я решил рассмотреть пример создания целенаправленного микросервисного дизайна… правильным способом.
Представьте: у вас пара сотен микросервисов, и вдруг всё ломается. А может даже не всё, а, скажем, только одна страница. Если вы хорошо знакомы с системой, то по мониторингам и логам быстро обнаружите проблему и пойдете её решать. Но иногда систему вы видите впервые, и на поиск бага могут часы, или даже дни.
Всем привет, меня зовут Саша Казанцев, я — тимлид команды “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, это накладывает определенные требования к безопасности. А ещё код должен быть тестируемым.
Сегодня мы поговорим о двух метриках — корректность и тестируемость. Одна метрика напрямую влияет на другую, через тестируемость мы добиваемся корректности в том числе, мы проверяем, насколько код ожидаемо работает.
Перед тем как говорить об интеграционном тестировании, нужно понять, какой процесс мы будем тестировать. Рассмотрим сценарий интеграционного тестирования из жизни. Это сценарий выставления счета, на самом деле процесс проходит в несколько этапов, но мы рассмотрим в посте первые две стадии этого сценария.
