Техническое сопровождение

В этой статье я хочу прозрачно рассказать о своих мыслях о направлении.

Изменение подхода к работе с факапами. Хотим предсказывать факапы и иметь возможность проактивно действовать, а не тушить пожар и потом с симптомами разбираться.

Предсказать факап невозможно. Можно определить наши возможности и нагрузку, при которой мы работаем стабильно. В результате направления хотим:

помочь Инфраструктуре Биллинга включить инфраструктурные инструменты из набора "Как не упасть под нагрузкой";
измерить "предел" системы, чтобы правильно настроить инструменты и отслеживать влияние внесённых в систему изменений;
увеличение независимости от внешних по отношению к Заказам подсистемам;
уменьшить роль разработчика в устранении факапов и последствий;
предсказуемое время стабилизации системы.

Для этого очертим нашу зону ответственности: сервисы, за которые мы несём полную ответственность. Сейчас Заказы это 14 проектов в Меге:

PurchaseService
BillingService
PriceService
PositionCostService
IncentiveService
AbonentService
AddresseeService
OnlineOrdersService
BillingGateway
Orders.Dto
Billing.BusinessObjects
OrdersApi
BillingApi
Billing.Web

В первую очередь нужно сконцентрироваться на этих сервисах. Для этого нужно провести нагрузочное тестирование наших сценариев. Считаю, что у Заказов сейчас есть сценарии, которые сделаны в АПИ: АПИ Абонентов, АПИ Продуктового Каталога, АПИ Выставления счетов (ещё я помню про методы получения счетов по пользователю). Это действие позволит снять метрики с сервисов и дальше анализировать станет лучше/хуже от действия и видеть некоторые количественные изменения.

После этого хочется внедрять инструменты:

Серверный и клиентский троттлинг

Что будет, если сервис попытается обработать слишком много запросов? Он деградирует или совсем перестанет работать. Чтобы этого не произошло, нужно ограничивать число одновременно обрабатываемых сервисом запросов. Это число обычно называется ёмкостью сервиса. (прим. автора: ёмкость сервиса настраивается через параметр CapacityLimit троттлинга);

Тайм-бюджеты + стратегии запросов

Паттерн Timeout не позволяет удаленным вызовам процедур бесконечно ожидать ответа. Если по истечении времени ожидания ответа нет, RPC вызывает механизм отката, независимо от того, повторяет ли он запрос, генерирует исключение или что-то еще. Этот шаблон, возможно, является самым основным, фундаментальным шаблоном устойчивости, используемым в RPC. Правильный подбор значений повысит устойчивость микросервисной архитектуры. (Ссылка на источники: 1, 2, 3) (прим. автора: учимся прогнозировать нагрузку внутри подсистемы Заказы и гарантировать время жизни запроса внутри системы независимо от общего состояния системы; не допускаем лавинообразного роста нагрузки при деградации системы - запрос приходит от одного фронта, sequntially реплицируется на 3 реплики второго сервиса, оттуда уже на 9, на 27, ...).

Батчинговые асинхронные запросы – грануляция процессов

Всегда проектируйте ваши методы для работы в батчевом режиме. При этом делайте так чтобы все эти методы работали в батчевом режиме насквозь. Из базы доставали данные пачками, в другие сервисы ходили тоже по батчевым АПИ. Этот принцип построения контрактов потребует больше усилий на обработку ошибок, рейт лимитинг. Но правда в том, что он сходу заставит вас задуматся об важных вещах: - что будет если я попросил 10 сущностей, а вернулись только 8? - как правильно контролировать конкурентность и потребление ресурсов? - как ограничивать доступ к сущностям, к которым доступа не должно быть? Бонус получите более производительную по пропускной способности систему в которой сеть, базы, кеши работают лучше. (источник) (прим. автора: сейчас есть ограничения на стороне БД - ситуация, когда сущностей слишком много, считается исключительной; при батчевом подходе: снижается нагрузка на сеть –происходит запрос части данных; внедрение асинхронных перечислений позволяет снизить нагрузку с сервисов – клиент генерирует несколько запросов вместо одного тяжёлого, что снимает долгие блокировки, запросы разделены во времени; потребители запросов должны думать о возможно больших объёмах данных; получаем чистый АПИ сервисов без специфичных методов фильтрации)

Отдельная база данных

Базовый принцип, который лежит в основе работы SQL Server с хранилищами данных, заключается в том, что базы данных состоят из файлов двух типов: Файлы данных *.mdf. В этих файлах хранится информация базы данных. Файлы журналов *.ldf. В этих файлах хранятся транзакции базы данных, что позволяет восстановить базу данных на определенный момент времени. (прим. автора: учимся за гарантированное время восстанавливать состояние БД, первый шаг к переезду БД на отдельный сервер для независимости от нагрузки на остальную часть системы).

Одним из этапов должно стать исследование зависимостей Заказов с целью:

уменьшить влияние сбоев во внешних системах на процессы внутри Заказов;
прогнозировать нагрузку на внешние системы;
увеличение производительности системы за счёт уменьшения времени жизни запроса внутри системы (отсутствие сетевых обращений).