ii000314 Feb 26 2019 at 12:19

WG Contract API: zoo of services

11 min

5.4K

ex-Wargaming corporate blogSystem Analysis and Design*API*Distributed systems*Microservices*

+27

Comments 7

Tiendil Feb 26 2019 at 13:48

Спасибо. Очень интересно.

Есть много вопросов:

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

ii000314 Feb 26 2019 at 14:51

Спасибо. Постараюсь дать как можно более развёрнутые ответы

За минимальную единицу функциональности в Contract API мы принимаем Контракт, независимо от того какой из платформенных компонентов обслуживает этот контракт. В контексте аутентификации/авторизации Контракт является action_item'ом, на использование которого можно выдать права. По задумке каждый платформенный компонент имеет свой уникальный identity и список ассоциированных с ним action_item'ов. Всё это хранится в специализированном платформенном компоненте, отвечающем за идентификацию, аутентификацию, авторизацию и аудит (i3a). В результате серверная библиотека, принимая запрос на обработку Контракта, первым делом аутентифицирует клиента, получая его identity. Затем авторизует в контексте используемого action_item'а. После этого кэширует результат на некоторое время. Для того что бы при следующем запросе этого клиента не ходить в сторонний сервис. Другими словами вся логика скрыта внутри библиотеки и программисту не нужно об этом заботится.
Это внутренний API который мы рекомендуем использовать тем платформенным компонентам, которые не хотят или не могут использовать наши библиотеки. Либо тем, чьей кодовой базой платформа не владеет. Последнее сделано скорее из соображений безопасности, т.к. брокер сообщений в центре Contract API — это наш «хрустальный сосуд», от работоспособности которого зависит функционирование платформы. А наличие специализированного сервиса между клиентом и Contract API позволяет, при необходимости, фильтровать запросы и не дать клиентам перегрузить запросами брокер сообщений. Это, в случае чего, даст нам дополнительное время на реагирование.
Временами есть необходимость вызывать привычный API в массовом порядке. Например, создать 1000 аккаунтов, или выставить 10000 банов. Раньше под каждый такой случай писались специализированные API, или даже целые сервисы. Но благодаря тому что контракт имеет строго определённую структуру, мы смогли написать сервис который целиком отвечает за исполнение массовой операции и генерацию отчётов, при этом, не зная о том какую конкретную операцию он выполняет. Ближайшая аналогия которая сейчас приходит в голову — это Invoker из шаблона проектирования «команда». Сам Контракт, в данном случае его структура, выступает той самой обёрткой Command из того же шаблона проектирования.\
Для того что бы отобразить контракт на UI необходимо зарегистрировать виджет в специализированном компоненте. По умолчанию виджет выглядит как формочка для ввода данных. Однако пользователь имеет возможность управлять как отображением данных, так и самими данными (например задать параметры по умолчанию или, теоретически, подгрузить часть данных, для передачи в API, снаружи). После этого виджет можно встроить в необходимое количество мест. Изменив виджет, он соответственно изменится одновременно во всех админках.

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

Tiendil Feb 26 2019 at 15:13

Промахнулся с ответом: habr.com/ru/company/wargaming/blog/441708/#comment_19808562

Tiendil Feb 26 2019 at 15:12

надеюсь мне удалось ответить на заданные вопрос

Вполне.

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

ii000314 Feb 26 2019 at 15:33

На уровне ядра платформы мы наделяем правами компонент-админку, а то, как распределить эти права между своими пользователями — админка решает сама. То есть Contract API может проверить, что админка использует функциональность платформы, к которой у неё действительно есть доступ, не более.

Tiendil Feb 26 2019 at 17:15

Искали open source аналоги (если не софт, то хоть стандарты)? Если нашли то какие и почему не использовали их?

ii000314 Feb 26 2019 at 18:24

Насколько я помню, мы в первую очередь смотрели на RAML/Swagger/OpenAPI + ServiceDiscovery, но в итоге решили не привязывать своё решение к REST. К тому же мы хотели построить Event Driven систему, т.к. на неё хорошо ложатся некоторые из наших процессов.

Наиболее близким по духу стандартом, как мне кажется, является SOA. Однако SOAP показался тяжеловатым. Одним из основных требований предъявляемых Contract API было обеспечение высокой производительности.

Анализируя различные решения мы обнаружили что все они в той или иной мере комбинируют паттерны из Enterprise Integration Patterns, предоставляя лишь слой абстракции над ними. Мы решили пойти по тому же пути, собрав легковесный протокол поверх интересующих нас низкоуровневых паттернов. В результате получился Contract API, спецификация которого раза в полтора-два меньше этой статьи. Потом оказалось что AMQP является довольно каноничным протоколом обмена сообщениями и уже реализует большую часть из выбранных нами паттернов. Это одна из причин почему в качестве транспорта мы сейчас используем AMQP.

Другими словами мы взяли россыпью классические Enterprise Integration Patterns и собрали из них решение которое подходило бы нам исключительно хорошо, как костюм сшитый на заказ.