Как мы переписывали сервер-сайд СберБанк Онлайн на микросервисы / Хабр

Где мы сейчас и что делаем дальше

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

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

Тем не менее мы ещё в начале пути и ещё много задач, которые предстоит решить:

• миграция профиля и сессии. Мы обеспечили запуск проектов, но Legacy продолжает оставаться источником основных данных по профилю клиента. В отличие от запуска атомарных клиентских сценариев, это то, что нельзя разработать рядом и потом плавно переключиться. Приходится много дорабатывать одновременно: и Legacy, и новое приложение. Всё это — под огромной пользовательской нагрузкой. Весьма сложная история, достойная отдельной статьи;

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

Так что наши разработчики счастливо программируют на Java 8. А деплоится это всё на вендорском JDK. Многие, кто слышит об этом на наших собеседованиях, расплываются в улыбке от счастья. Или не от счастья, мы точно не знаем. Если серьёзно, то это надо менять, и одна из текущих задач на платформе сейчас — смена стека. А для прикладных команд мы обсуждаем возможность разработки на Kotlin.

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

Спасибо за внимание, жду вопросы в комментариях.

Sbercloud «локализует» github

Одновременно представители Сбербанка сообщили CNews о том, что Sbercloud и принадлежащий Microsoft популярный хостинг ИТ-проектов Github намерены запустить локально размещенный и администрируемый на стороне отечественного провайдераоблачный сервис для использования Github корпоративными клиентами в России.

Sbercloud и Github обеспечат поддержку русского языка. «Облачный Github» будет доступен на платформе Sbercloud.Advanced.

Напомним, в январе 2020 г. Минэкономразвития Россиипредложило запустить отечественный аналог Gitlab и GitHub в связи с угрозой отключения России от иностранных хранилищ исходных текстов открытого ПО из-за антироссийских санкций и предложило выделить на реализацию проекта 2,1 млрд руб.

Sbercloud.advanced для физлиц

Облачные сервисы платформы Sbercloud.Advanced компании Sbercloud (входит в экосистему Сбербанка) c 20 мая 2021 г. стали доступны физическим лицам. Об этом CNews сообщил представитель Сбербанка.

Платформа Sbercloud.Advanced содержит огромный набор из более чем 50 интегрированных между собой облачных сервисов, доступ к которым предлагается по моделям IaaS («инфраструктура как сервис») и PaaS («платформа как сервис»).

Среди них: Cloud Container Engine – cервис для автоматизации развертывания, масштабирования и управления приложениями в высокопроизводительных кластерах Kubernetes; API Gateway – хостинг API, упрощающий публикацию, обслуживание, мониторинг, защиту и использование API;

Elastic Cloud Server GPU – сервис, который позволяет развернуть виртуальные машины с GPU-ускорением на базе Nvidia Tesla V100 с оперативной памятью от 16 до 512 ГБ; Document Database Service – сервис управления документоориентированной базой данных, полностью совместимой с MongoDB;

Distributed Cache Service – распределенный сервис кэширования данных в памяти на базе Redis или Memcached; Data Lake Insight – cервис анализа больших данных, совместимый с Apache Spark и Apache Flink.

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

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

Платформа Sbercloud.Advanced, запущенная в 2020 г., изначально была доступна исключительно корпоративным заказчикам. Однако некоторые услуги частным лицам облачный провайдер Сбербанка все же оказывал и ранее. К примеру, с конца сентября 2020 г. работает сервис «Сбердиск», предназначенный для хранения и обмена файлами.

Архитектурный контроль

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

Ввели контроль платформенного api

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

• на старте проекта попросили всех владельцев платформенных сервисов опубликовать свои контракты как можно раньше, ещё до того, как началась разработка. После чего они не должны были меняться. Здесь многое упирается в профессионализм людей, которые проектируют API. Мы доверили это самым опытным сотрудникам внутри команд, отвечающих за разработку сервисов;

• создали инструмент, который осуществляет контроль этого API. У нас для этого есть отдельный компонент — синтетическое приложение. О нём чуть позже;

• сделали процесс согласования изменения API максимально дорогим:

Важно отметить, что мы строго контролируем API в рамках минорных релизов платформы и не строго (изменения возможны, но согласуются с архитектурой) — в рамках мажорных релизов.

Зачем новая платформа

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

Достичь низкой связанности можно было двумя способами. Первый — глубокий рефакторинг текущего Legacy с целью разделить прикладной и платформенный функционалы на отдельные компоненты, которые взаимодействуют по зафиксированным контрактам. И второй — создание платформы с нуля с последующей миграцией прикладного функционала и пользователей. По совокупности причин выбрали второй вариант.

Ключевые моменты

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

Новая версия платформы smartmarket

Сбербанк также анонсировал запуск обновленной платформы для создания приложений Smartmarket.

Платформа дает возможность создавать приложения с ассистентами семейства «Салют», работать с zero- и low-code-инструментами, то есть требующими минимальных навыков программирования – например, Smartapp Graph; подключать платежи (SaaS-сервис Smartpay); управлять отправкой уведомлений (SaaS-сервис Smart Push); работать с данными пользователей (SaaS-сервис Smart Profile); а также подключать базы данных для проектов и отправлять приложения на публикацию в каталоге.

Smartmarket работает на десктопах и в мобильных браузерах и позволяет создавать новые продукты без необходимости устанавливать какое-либо ПО: все необходимые инструменты доступны прямо на сайте или через запросы по API, отмечают в Сбербанке.

Первая версия платформы была запущена Sberdevices (входит в экосистему Сбербанка и специализируется на создании «умных» устройств) в сентябре 2020 г.

Разделили сервисы на две группы — платформенные и прикладные

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

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

Поэтому платформенные и прикладные сервисы мы условно разделили по количеству зависимостей. Если от сервиса зависит множество других, то мы помещаем его в платформенный слой. Если от сервиса не зависят другие сервисы, то мы помещаем его в прикладной.

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

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

В нашем случае получилось порядка 40 платформенных и около 10 пилотных бизнес-сервисов на старте. На данный момент количество платформенных сервисов почти не изменилось, а число прикладных проектов превысило 250.

Следим за удобством разработки на платформе

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

Эта команда играет ключевую роль — собирает отдельные сервисы платформы в единый продукт. У ребят много задач:

• выпуск POM/BOM. Большая часть платформенного API предоставляется в виде клиентских библиотек. Ребята из «Синтетического приложения» собирают их вместе, разрешают конфликты зависимостей и публикуют для потребителей POM- и BOM-файлы;

• контроль обратной совместимости API. Кроме проверки на конфликт зависимостей, все библиотеки проходят тестирование на бинарную совместимость с предыдущими версиями;

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

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

• СSI и обратная связь. Продукт не может быть хорошим, если нет механизма обратной связи от клиентов. Мы проводим регулярную оценку CSI и сессии обратной связи с потребителями платформы. После этого направляем фидбэк в команды разработки платформенных сервисов и контролируем, что «боли» клиентов не останутся без внимания;

• сообщество разработчиков. Разработка на платформе становится легче и результативнее, если есть инструменты прямого взаимодействия с её разработчиками и можно пообщаться с коллегами, которые раньше вас пришли на платформу. У нас основным инструментом такого взаимодействия выступает сообщество разработчиков. У них есть чаты, где они могут задать любые вопросы по разработке на платформе, митапы и воркшопы, на которых можно получить новые и обменяться своими знаниями. Основная польза от этой истории для прикладного разработчика — помощь сообщества. Главная польза для ребят из платформы — прямое взаимодействие со своими потребителями.

Создали отдельные релизные процессы

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

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

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

После этого её можно передавать на контур с бизнес-потребителями, где они производят тестирование в своём быстром релизном цикле.

Ценовая политика

Как рассказали CNews в Сбербанке, стоимость облачных сервисов Sbercloud.Advanced начинается от 350 руб. в месяц. При регистрации в личном кабинете разработчик получает грант в размере 10 тыс. руб., который может потратить на использование сервисов Sbercloud.Advanced.