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

В современной экономике создание программного обеспечения (ПО) — это целая индустрия, которая, с одной стороны, оказывает помощь бизнесу в автоматизации и цифровизации всех процессов, а с другой стороны, самостоятельно приносит прибыль и создает виртуальные активы. В настоящее время проектирование в сфере 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. В таких монолитах нет ничего плохого, это отличный базис, который не просто поддерживает жизнеспособность системы, но и до определенного момента оставляет простор для развития. Однако есть в них и минусы, и чем больше массив становится, тем острее они ощущаются.

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

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

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

Рассчитываю на новичков, но если у вас есть интересный опыт в этих вопросах - добро пожаловать в комментарии.

Sanic - современный мощный фреймворк, незаслуженно обделённый вниманием российского IT-сообщества.

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

Привет!

Меня зовут Коля, и я системный аналитик.

В большинстве источников моделирование данных (в контексте создания приложений) рассматривается как последовательное создание трёх моделей данных - концептуальной, логической и физический. Такого порядка придерживаются, например, DMBOK2 и BABOK, а также многочисленные статьи в сети Интернет:

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

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

Разбираемся, в чем трудности перехода и как устроено взаимодействие в архитектуре микросервисов.

Чем быстрее идея воплотится в новый проект, тем больше шансов занять нишу, завоевать лояльность пользователей и, как следствие, стать успешнее конкурентов. Ускорить разработку и сделать её более гибкой и управляемой помогает микросервисная архитектура. Вместе с Дмитрием Горчаковым, руководителем отдела разработки РЕД-СОФТ, мы разобрали плюсы и минусы микросервисов, а ещё рассмотрели сценарии, как компании приходят к их внедрению.  

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

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

Под катом шесть вопросов, их задают себе системные архитекторы Газпромбанка, когда хотят понять, пора пилить микросервисы или можно обойтись монолитом.