synapse сбербанк это что
Зачем мы делаем Enterprise Service Mesh
Service Mesh — известный архитектурный паттерн для интеграции микросервисов и перехода на облачную инфраструктуру. Сегодня в облачно-контейнерном мире обойтись без него довольно сложно. На рынке уже доступны несколько open-source реализаций service mesh, но их функциональности, надежности и безопасности далеко не всегда достаточно, особенно когда речь идет о требованиях больших финансовых компаний масштаба всей страны. Поэтому мы в Сбертехе решили кастомизировать Service Mesh и хотим рассказать о том, что в Service Mesh круто, что не очень и что мы с этим собираемся сделать.
Популярность шаблона Service Mesh растет с популярностью облачных технологий. Он представляет собой выделенный инфраструктурный слой, который упрощает взаимодействие между различными сетевыми сервисами. Современные облачные приложения состоят из сотен и даже тысяч таких сервисов, каждый из которых может иметь тысячи копий.
Взаимодействие между этими сервисами и управление ими — ключевая задача Service Mesh. Фактически это сетевая модель из множества прокси, управляемая централизованно и выполняющая набор весьма полезных функций.
На уровне прокси (data plane):
Для чего нужен Service Mesh в корпоративном секторе
Использование Service Mesh приносит множество очевидных преимуществ. Прежде всего, это просто удобно разработчикам: для написания кода появляется технологическая платформа, которая существенно упрощает интеграцию в облачную инфраструктуру за счет того, что транспортный слой полностью изолирован от прикладной логики.
Кроме того, Service Mesh упрощает взаимоотношения поставщиков и потребителей. Сегодня поставщикам и потребителям API гораздо проще договориться об интерфейсах и контрактах самостоятельно, не привлекая для этого специального интеграционного посредника и арбитра – корпоративную сервисную шину. Такой подход существенно влияет на два показателя. Увеличивается скорость вывода новой функциональности на рынок (time-to-market), но при этом повышается стоимость решения, так как интеграцию приходится делать самостоятельно. Использование Service Mesh командами разработки бизнес-функциональности позволяет сохранить здесь баланс. В итоге поставщики API могут сфокусироваться исключительно на прикладной составляющей своего сервиса и просто опубликовать его в Service Mesh — API сразу станет доступен всем клиентам, а качество интеграции будет production ready и не потребует ни одной строчки дополнительного кода.
Следующим преимуществом является то, что разработчик, используя Service Mesh, фокусируется исключительно на бизнес-функциональности — на продуктовой, а не на технологической составляющей своего сервиса. Например, уже не приходится думать о том, что в ситуации, когда сервис будет вызываться по сети, где-то может произойти обрыв соединения. Кроме того, Service Mesh помогает сбалансировать трафик между копиями одного и того же сервиса: если одна из копий «умерла», то система переключит весь трафик на оставшиеся живые копии.
Service Mesh — это хорошая основа для создания распределенных приложений, которая скрывает от клиента детали обеспечения вызовов его сервисов как изнутри, так и снаружи. Все приложения, использующие Service Mesh, на транспортном уровне изолированы и от сети, и друг от друга: никакой связи между ними нет. При этом разработчик получает полный контроль над своими сервисами.
Нельзя не отметить, что обновление распределенных приложений в среде, где используется Service Mesh, становится проще. Например, blue/green-развертывание, при котором для установки доступны две среды приложения, одна из которых не обновляется и находится в режиме ожидания. Откат на прошлую версию в случае неудачного релиза осуществляется специальным роутером, с ролью которого прекрасно справляется Service Mesh. Для обкатки новой версии можно использовать и канареечный релиз — переключить на новую версию только 10% трафика или запросы от пилотной группы клиентов. Основной трафик идет на старую версию, ничего не ломается.
Также Service Mesh дает нам контроль SLA в реальном времени. Система распределенных прокси не позволит завалить сервис, когда кто-то из клиентов превысит выданную ему квоту. Если пропускная способность по API ограничена, никто не сможет заддосить его большим количеством транзакций: Service Mesh стоит перед сервисом и не пропускает лишний трафик. Он просто будет отбиваться в интеграционном слое, а сами сервисы продолжат работать, не замечая этого.
Если компания хочет сократить расходы на развитие интеграционных решений, Service Mesh также выручает: на его open-source версии можно перейти с коммерческих продуктов. Наш Enterprise Service Mesh базируется на open-source версии Service Mesh.
Еще одно преимущество — наличие единого полноценного набора интеграционных сервисов. Поскольку вся интеграция строится через этот промежуточный слой, мы можем управлять всем интеграционным трафиком и связями между приложениями, которые формируют бизнес-ядро компании. Это очень удобно.
И наконец Service Mesh стимулирует компанию к переходу на динамическую инфраструктуру. Сейчас многие смотрят в сторону контейнеризации. Распиливать монолит на микросервисы, все это красиво внедрять — тема находится на подъеме. Но когда ты пытаешься перевести на новые рельсы систему, которая уже много лет в продакшне, то сразу сталкиваешься с целым рядом проблем: затолкать все это в контейнеры и развернуть на платформе непросто. А внедрение, синхронизация и взаимодействие этих распределенных компонентов —еще одна сложнейшая тема. Как они будут друг с другом общаться? Не будет ли каскадных сбоев? Service Mesh позволяет решить часть этих проблем и облегчить миграцию со старой архитектуры на новую за счет того, что про логику сетевого обмена можно забыть.
Зачем нужна кастомизация Service Mesh
У нас в компании уживаются вместе сотни систем и модулей, а runtime очень нагружен. Так что простого паттерна, когда одна система вызывает другую и получает ответ, недостаточно, потому что в production мы хотим большего. Что еще нужно от корпоративного Service Mesh?
Сервис обработки событий
Представим, что нам нужно сделать real-time event processing — систему, которая в реальном времени анализирует действия клиента и может сразу сделать ему релевантное предложение. Чтобы реализовать подобную функциональность, используется архитектурный паттерн под названием event-driven architecture (EDA). Ни один из актуальных Service Mesh такие паттерны нативно не поддерживает, а ведь это очень важно, особенно для банка!
Довольно странно, что «удаленный вызов» Remote Procedure Call (RPC) поддерживают все версии Service Mesh, а с EDA они не дружат. Потому что Service Mesh — это подобие современной распределенной интеграции, а EDA — очень актуальный архитектурный паттерн, который позволяет делать уникальные вещи в плане клиентского опыта.
Наш Enterprise Service Mesh данную проблему должен решать. Кроме того, мы хотим видеть в нем реализацию гарантированной доставки, потоковой и комплексной обработки событий с использованием разнообразных фильтров и шаблонов.
Сервис передачи файлов
Помимо EDA было бы неплохо иметь возможность передавать файлы: в масштабах Enterprise очень часто возможна только файловая интеграция. В частности, используется архитектурный паттерн ETL (Extract, Transform, Load — «извлечение, преобразование, загрузка»). В нем, как правило, все обмениваются исключительно файлами: используются большие данные, которые нецелесообразно пихать отдельными запросами. Возможность нативной поддержки передачи файлов в Enterprise Service Mesh дает необходимую для бизнеса гибкость.
Сервис оркестрации
В крупных организациях почти всегда есть разные команды, которые делают разные продукты. Например, в банке одни команды работают с депозитами, а другие — с кредитными продуктами, и таких кейсов достаточно много. Это разные люди, разные команды, которые делают свои продукты, разрабатывают свои API и предоставляют их другим. И очень часто возникает потребность в композиции этих сервисов, а также имплементации сложной логики последовательного вызова набора API. Для решения данной проблемы необходимо решение в интеграционном слое, которое позволит упростить всю эту композитную логику (вызов нескольких API, описание маршрута запросов и т.д.). Это и есть сервис оркестрации в Enterprise Service Mesh.
AI и ML
Когда микросервисы общаются через единый интеграционный слой, Service Mesh, естественно, знает все о вызовах каждого сервиса. Мы собираем телеметрию: кто кого вызывал, когда, как долго, сколько раз и так далее. Когда этих сервисов сотни тысяч, а вызовов — миллиарды, то все это накапливается и формирует Big Data. Эти данные можно проанализировать средствами ИИ, machine learning и пр., а потом сделать на основе результатов анализа какие-то полезные вещи. Было бы уместно хотя бы частично передать искусственному интеллекту управление всем этим сетевым трафиком и вызовами приложений, интегрированных в Service Mesh.
Сервис API Gateway (Шлюз API)
Как правило, в Service Mesh есть прокси и сервисы, которые обращаются друг с другом внутри доверенного периметра. Но существуют еще и внешние контрагенты. Требования к API, предоставляемым этой группе потребителей, намного серьезнее. Эту задачу мы делим на две основные части.
Сервис поддержки специфических протоколов и форматов данных (шлюз АС)
На текущий момент большинство решений Service Mesh умеют нативно работать только с трафиком HTTP и HTTP2 или в урезанном режиме на уровне TCP/IP. У Enterprise Service Mesh появляется много других весьма специфических протоколов передачи данных. Одни системы могут использовать брокеры сообщений, другие интегрированы на уровне баз данных. Если в компании есть SAP, то он также может использовать собственную систему интеграции. Причем все это работает и является важной частью бизнеса.
Нельзя просто сказать: «Давайте откажемся от legacy и сделаем новые системы, которые смогут использовать Service Mesh». Чтобы подружить все старые системы с новыми (на микросервисной архитектуре), системам, которые могут использовать Service Mesh, понадобится какой-то адаптер, посредник, шлюз. Согласитесь, было бы неплохо, если бы он поставлялся в коробке вместе с сервисом. Шлюз АС как раз и может поддержать любой вариант интеграции. Только представьте, вы просто устанавливаете Enterprise Service Mesh, и он уже готов взаимодействовать со всеми протоколами, которые вам нужны. Для нас такой подход очень важен.
Примерно так мы представляем корпоративную версию Service Mesh (Enterprise Service Mesh). Описанная кастомизация решает большинство проблем, возникающих при попытках использовать готовые open-source версии интеграционной платформы. Появившись всего пару лет назад, архитектура Service Mesh продолжает развиваться, и мы рады, что можем внести вклад в ее развитие. Надеемся, что наш опыт будет вам полезен.
Java разработчик решения Synapse
Требуемые навыки
Местоположение и тип занятости
Компания
Описание вакансии
В Сбербанк-Технологии активно ведется разработка инновационного интеграционного решения Synapse. И сейчас команда Synapse ищет Java-разработчиков для разработки cloud-native решений на Java!
Вот всего лишь несколько причин, почему стоит присоединиться к нашей команде:
Результатом твоих трудов станет решение, которое позволит выйти Банку выйти на новый уровень реализации интеграционной логики и значительно сократить время вывода новых продуктов!
Основные функции и задачи:
• Анализ требований, проектирование, разработка архитектуры и реализация сервисного слоя Банка;
• Доработка интеграционных решений, построенных на архитектуре SOA с использованием продуктов линейки IBM Websphere, а также opensource-решений на Java;
• Доработка интеграционных шлюзовых решений Банка;
• Разработка профильного программного обеспечения:
— Развитие средств мониторинга и управления интеграционными решениями;
— Оптимизация рабочего процесса, CI, СD, DevOps;
• Оптимизация существующих решений, повышение отказоустойчивости систем в целом в рамках стратегических задач Сбербанка России;
• Участие в приемо-сдаточных испытаниях, внедрениях;
• Оказание третьей линии поддержки со стороны разработки;
• Участие в пилотных проектах по разработке новейших программных и банковских продуктов.
Что мы от Вас ожидаем:
• Экспертиза в области SOA/event-driven architecture/microservices/business rules MS/Big Data.
• Опыт разработки высоконагруженных систем;
• Твердое знание языка Java и JavaCore;
• Опыт работы с opensource-решениями;
• Знание гибких методологий разработки agile;
• Опыт работы со средствами автоматизации разработки программных решений (CI/DevOps);
• Знание реляционной модели данных, владение SQL на уровне написания запросов. Понимание полного цикла разработки программного обеспечения;
• Опыт промышленной разработки приложений на любом современном технологическом стеке не менее года;
• Развитый технический кругозор;
• Умение предлагать и реализовывать новые решения;
• Умение тестировать собственный код и работать с чужим.
Приветствуется:
• Экспертиза в области SOA / event-driven architecture / microservices / business rules MS / machine learning / Big Data.
• Опыт работы с линейкй продуктов IBM WebSphere (в частности IBM WebSphere Message Broker / IBM Integration Bus, IBM WebSphere MQ);
• Опыт участия в интеграционных проектах, общее понимание современных принципов и технологий системной интеграции;
• Понимание концепций message queuing и web-сервисов;
• Опыт работы с XSD, WSDL, XSLT;
• Опыт работы с Unix-подобными ОС на уровне пользователя;
• Рабочее место на Энгельса 36 г. Екатеринбург.
РЖД и Сбер — братья навек. Крупнейший госбанк навязывает сервисы своей «экосистемы» ЖД-монополии
Российский финансовый конгломерат «Сбер» (в недавнем прошлом «Сбербанк») намеревается наладить тесное сотрудничество с ОАО «РЖД». Для этого он собирается продать холдингу сразу 13 цифровых продуктов и сервисов своей экосистемы. Речь идёт о современных небанковских услугах, которые разработаны на единой цифровой платформе и позволяют решать самые разные задачи. Это если говорить языком красивых презентаций «зелёных» банкиров. На деле до конца понять, что именно предлагает финансовый гигант гиганту железнодорожному, не представляется возможным. Как и то, как нанопроекты «Сбера», адресованные РЖД, сочетаются с вечным лозунгом: «Идите туда, где карту получали».
Определённое соглашение между «Сбербанком» (простите, пока не отвыкли от старого названия — прим. ред.) и РЖД уже существует. И вроде бы, если верить нашим источникам, в холдинге даже понимают, о каких 13 продуктах идёт речь. С декабря этого года по март следующего банкиры и перевозчики изучат возможность внедрения новых программ, оценят эффекты, а в некоторых случаях и проведут пилотные проекты по использованию небанковских цифровых продуктов и сервисов, разработанных в структурах экосистемы «Сбера».
Сама экосистема, по сути, представляет собой новый пакет услуг, который предоставляет «Сбер» своим клиентам. Она состоит из разветвлённой сети программ/организаций/сервисов, связанных единой цифровой платформой.
«Сейчас крупные компании идут курсом на создание экосистем. Глобальные корпорации понимают, что мир меняется, и ключевым активом будут клиенты. Поэтому они собирают под собой другие более мелкие компании для оказания как можно более широкого комплекса услуг, — рассказал vgudok.com технический директор Linagora RUS Алексей. — Например, ВТБ заходит в транспорт, покупает страховые компании. «Сбербанк» делает то же самое. Он хочет предоставлять набор услуг, который нужно каким-то образом капитализировать. В идеале сделать так, чтобы эти услуги ещё и зарабатывали.
Основная задача — охватить как можно больше людей, задача вторая — самоокупаемость составных элементов системы (пусть и частичная).
Мы все станем клиентами экосистем в будущем. Будут, условно, «люди Тинькова», «люди ВТБ», «люди Сбера» и так далее. Сейчас компании ворвались на рынок и завоевывают клиентов, предоставляя пакеты услуг, которые привлекают как разнообразием, так и интеграциями внутри пакета (такси и доставка, к примеру). Приходишь к нам, условно, в «Яндекс.Еду» — получи ещё и музыку, и такси и так далее. То же самое хочет сделать «Сбер».
Что касается предложений, выдвинутых финансовым госгигантом РЖД, речь идёт о 13 программах, которые должны будут помогать монополии в будущем более эффективно работать. Не исключено, что некоторыми ИТ-продуктами холдинг сможет воспользоваться уже в будущем году. Об этом говорится в совместном плане двух госкомпаний.
На первом месте в списке железнодорожных предложений от «Сбера» расположился сервис под названием Sber Works. Это единая среда с широким набором инструментов для архитекторов и разработчиков. Внедрить её планируется уже в декабре-январе.
Synapse, ещё один продукт, разработанный банковскими экспертами, представляет собой интеграционное решение, которое позволяет выйти «на новый уровень реализации интеграционной логики и значительно сократить время вывода новых продуктов». В декабре-январе запланировано подобрать процессы, подходящие для внедрения Synapse, и оценить возможности внедрения. Очень интересно, что же это за процессы.
Крупнейший банк ожидаемо предлагает ЖД-монополисту и сотрудничество в сфере внедрения искусственного интеллекта (ИИ). Для начала предстоит выявить процессы и системы РЖД, где потенциально применимо использование ИИ, а также оценить технические возможности решений «Сбера». И только потом можно будет подсчитать, во сколько это всё может обойтись.
К слову, некоторые проекты уже реализуются РЖД. К примеру, Cognitive Pilot (на 30% принадлежит «Сбербанку» и входит в предлагаемый перечень услуг экосистемы). В июле 2019 года был представлен первый в России и один из первых в мире прототипов железнодорожного локомотива с возможностью автономного управления. Проект реализуется госкомпанией совместно с компанией Cognitive Pilot. В декабре-январе партнёры намерены оценить эффективность пилота.
Некоторые из предложенных сервисов могут перепасть и «дочкам» холдинга.
К примеру, один из них — популярный онлайн-кинотеатр Okko. Он может появиться в поездах «Федеральной пассажирской компании» (ФПК). До февраля планируется оценить максимально возможный охват, после чего сделать вывод об экономической эффективности внедрения.
Подкинули на пробу банкиры и проект для другой «дочки» монополии — «РЖД-Медицины». Называется он «Сбербанк-Здоровье» и включает набор телемедицинских сервисов, запись на приём к врачу, онлайн-консультации. Пилот опробуют в январе-феврале 2021 года.
«Сбер» рассчитывает предоставить РЖД пакет из своих опций, которые органически войдут в сервисы монополии. К примеру, «РЖД-Медицина» будет предоставлять свои услуги и параллельно предлагать «Сбер Здоровье». Тем самым клиенты холдинга под брендом РЖД будут получать услуги фактически от «Сбера», в том числе преференции от использования остальных сервисов банка, которые не оказывают РЖД. Например, покупка билета на поезда с автозаполнением деталей по «Сбер ID». Не придётся больше заполнять свои паспортные данные, если вы клиент экосистемы конечно», — рассказал Алексей.
«Для бизнеса внедрение таких вещей, как внутренние системы управления, разработки — это, во-первых, проверка, насколько системы жизнеспособны вне компании, где они разработаны и, во-вторых, это попытка их капитализировать и хотя бы частично окупить. Если ты сделал для себя какую-то удобную вещь, можно её кому-то сдавать в аренду, компенсируя часть затрат. Обе цели абсолютно логичные и правильные. Экосистема требует новых клиентов и новых партнёров.
Что касается восприятия коллаборации пользователям, «Сбер» может не афишировать себя как партнёра.
К примеру, «РЖД-Медицина» не обязана публично упоминать, что часть услуг на самом деле оказывает «Сбер Здоровье». В тех моментах, где это неизбежно, например, авторизация через «Сбер ID», прозрачность будет всячески нивелироваться тем, что это просто удобно. Не вижу никаких рисков как на уровне «Сбербанка» и его технологий, так и на уровне РЖД. Партнёрство может быть удачным», — уверен эксперт.
Мы уже упоминали, что всего в предложении 13 блоков, и в РЖД по каждому уже сформирована рабочая группа. Она должна сопоставить то, что предлагает внедрить «Сбер» с тем, что уже работает в госкомпании. И определить в целом, насколько монополисту целесообразно пользоваться сервисами банковской структуры. Решение в итоге будет приниматься по каждому продукту отдельно.
В целом, задуматься господам с Новой Басманной есть над чем. «Сбер» давно и плотно ассоциируется у россиян с компанией, которая никак не может переместиться из прошлого в будущее. Вроде бы и Жоржа Милославского уже оттуда сюда в рекламных целях пригнали. А проблемы всё те же. Диджитал диджиталом, а в очередь к нанобанкомату талон из ненанобумаги возьми, отстояв в ненаноочереди. И так повсеместно. Может, не с того начинаем? Однако это подход гуманитариев-журналистов. У технарей к хотелкам «Сбера» свои претензии.
«Когда во всём мире акцент идёт на децентрализацию данных: блокчейн, прозрачность, доступ к статистике и так далее, за исключением персональных данных, не факт, что в долгосрочной перспективе эта история может быть популярна. Сейчас набирает рост понимание ценности оупенсорс-продуктов. Это продукт с открытым исходным кодом, где человек может почитать и убедиться, как он работает.
Для полной паранойи его можно поставить самостоятельно и контролировать, что происходит.
Например, когда у пользователя падает любая программа, и там написано «отправить заказчику информацию», он ничего не знает: какую информацию он отправит и как. Потому что код программы закрыт. В открытом коде можно докопаться до модуля, прочитать в открытом, публичном репозетории то, что необходимо узнать. И убедиться, что именно отправляется, как собрано и куда уходит.
В этом плане, мне кажется, что это стратегическая цель «Сбера». Но, с точки зрения страны и нашей IT-культуры и, главное, мировых IT-тенденций, это, конечно, не самый лучший вариант. Интересы «Сбербанка» не всегда соответствуют интересам общества, государства и всего человечества», — делает свой вывод технический директор Linagora RUS Алексей.
Соответствуют ли интересы «Сбера» чаяниям и стратегиям ОАО «РЖД», покажет время. Думается, что в самом начале уже нового, но наверняка всё ещё «ковидного» 2021 года топ-менеджменту монополии будет чем заняться, помимо летучек с 13-ю рабочими группами по вхождению в «экосистему» детища г-на Грефа. Со своими системами бы разобраться — эко и не только.
Больше лёгкого чтива для тяжёлых будней ищите в нашем разделе LIGHT и в Telegram-канале @Vgudok
Максим Ярошевский, Семён Карабанов
Как мы переписывали сервер-сайд СберБанк Онлайн на микросервисы
Вы, наверное, в последнее время часто слышите о новых продуктах Сбера, со многими из них сталкиваетесь как клиенты.
А есть в Сбере крупные и сложные технологические проекты, которые напрямую не видны для клиентов, но от их запуска сильно зависит успех клиентских продуктов. Сложность связана с необходимостью трансформировать приложения, которые каждую секунду обеспечивают непрерывность текущего бизнеса Сбера, а масштаб обусловлен большим количеством функционала, который востребован 68 млн клиентов. В статье я расскажу об одном из таких очень больших изменений — запуске новой платформы для СберБанк Онлайн.
Это вводный текст о новой платформе, поэтому в нем не будем глубоко уходить в практические детали, а постараемся дать общее представление.
В какой-то момент, когда Сбер ещё был Сбербанком, а технологическая трансформация только начиналась, появилась идея, что флагманское приложение СберБанк Онлайн может разрабатывать не одно подразделение, а весь банк, а впоследствии и вся Группа Сбер. А у команды, которая раньше разрабатывала это приложение самостоятельно, появилась задача создать платформу, которая построит параллельную и независимую разработку в СберБанк Онлайн.
Уточним вводные, с которыми предстояло работать:
продуктовых команд будет много (несколько сотен — в ближайшей перспективе и тысячи — в перспективе). Размер одной команды — около 10 человек, возможность разрабатывать функционал end-to-end;
T2M по бизнес-функционалу — 2‒3 недели. Разумеется, срочные фиксы должны выходить на клиентов в течение часов;
приложения должны иметь лучший клиентский опыт и высокие оценки в App Store и Google Play;
текущий сервер-сайд и фронтальные приложения — монолиты с многолетней историей;
менять колёса надо на ускоряющемся ходу. Пользователей уже перевалило за 45 млн, нагрузка каждый день растёт. Речь и о количестве TPS, и о количестве новых фич, которые нужны бизнесу;
большинство операций — банковские. Это к тому, что платёжные транзакции, в отличие от, например, развлекательного контента, нельзя терять ни в коем случае. А если мы не отразим корректный остаток по картам в момент входа, сразу положим контакт-центры высоким количеством обращений клиентов;
надёжность и безопасность — высшие приоритеты.
Теперь пару слов о том, что мы называем сервер-сайдом СберБанк Онлайн. Как правило, сервер-сайд в крупной организации можно условно разделить на два основных слоя — мидл, который обеспечивает надёжность, доступность и хороший UX клиентских приложений, и бэкенд, который хранит и обрабатывает мастер-данные по разным системам (например, карточный процессинг, вклады или «Кредитная фабрика»).
Когда мы говорим «сервер-сайд приложений СберБанк Онлайн», имеем в виду именно мидл-слой, который отвечает за следующий функционал:
бизнес-приложения (прикладные), которые реализуют конечный функционал для пользователей приложений;
аутентификацию пользователя в приложении;
наполнение распределённого кэша в памяти серверов приложений при установке клиентской сессии, который обеспечивает доступность, низкое время отклика и надёжность при большом количестве запросов от приложений;
общие страницы приложения (главный экран, история операций и т. д.);
логирование, мониторинг, авторизацию и другой функционал для надёжности и безопасности.
Список на этом не заканчивается, но должен дать общее представление. Явно ещё раз подчеркну, что бэкенд не входил в объём поставленной задачи.
Зачем новая платформа
Недавно СберБанк Онлайн отметил свой десятый день рождения, и на протяжении этой истории в качестве мидл-слоя служил монолит. Надо отдать должное, он с достоинством пережил активную стадию роста пользовательской и функциональной нагрузки. Но всё время рос и по большей части представлял собой сильно связанный код, где прикладной функционал был прочно переплетён с тем, который обеспечивал надёжность и доступность. Поэтому невозможно было продолжать увеличивать интенсивность разработки при одновременном сокращении T2M. Очевидное решение — уменьшить связанность кода, чтобы проходить все этапы производства без сильного влияния одного функционала на другой.
Достичь низкой связанности можно было двумя способами. Первый — глубокий рефакторинг текущего Legacy с целью разделить прикладной и платформенный функционалы на отдельные компоненты, которые взаимодействуют по зафиксированным контрактам. И второй — создание платформы с нуля с последующей миграцией прикладного функционала и пользователей. По совокупности причин выбрали второй вариант.
Ключевые моменты
Итак, мы примерно определились, зачем делаем новую платформу, дальше самое главное — добиться результата. А опыт подсказывал, что добиться его на таком большом масштабе непросто. Поэтому заранее спланировали ключевые моменты, на которых в первую очередь надо держать фокус.
Разделили сервисы на две группы — платформенные и прикладные
Как бы мы ни старались делать микросервисы максимально независимыми, всегда будут те, от которых зависят все. Появляются общие сервисы из-за необходимости централизованного управления платформой. Например, логирование у нас общее, потому что логи зачастую собираются в результате проблемы клиента, а не отдельного сервиса
Для таких сервисов невозможно обеспечить T2M в пару недель, потому что все пользуются логированием, и, если мы не протестируем потребителей во время нового релиза, есть риск потерять в качестве.
Поэтому платформенные и прикладные сервисы мы условно разделили по количеству зависимостей. Если от сервиса зависит множество других, то мы помещаем его в платформенный слой. Если от сервиса не зависят другие сервисы, то мы помещаем его в прикладной. При этом стараемся минимизировать количество зависимостей, а, следовательно, и количество платформенных сервисов.
Почему мы акцентируем внимание на количестве связей? Если грубо, то каждая зависимость — это дополнительный тестовый кейс или несколько кейсов. Кроме того, при росте количества связей мы получаем высокую спутанность и, как следствие, циклические зависимости. И неутешительные сроки по исправлению дефектов. Всё это напрямую влияет на T2M.
Таким образом, у нас появляются горизонтальные связи в рамках одного слоя и вертикальные — между слоями. В платформенном слое мы допускаем горизонтальные зависимости, в прикладном — стараемся их избегать (исключения возможны, но именно исключения, и мы следим за этим).
В нашем случае получилось порядка 40 платформенных и около 10 пилотных бизнес-сервисов на старте. На данный момент количество платформенных сервисов почти не изменилось, а число прикладных проектов превысило 250.
Создали отдельные релизные процессы
Платформенные и прикладные сервисы отвечают разным требованиям и свойствам. Платформенные — максимальная стабильность и отказоустойчивость. Прикладные — лучший клиентский опыт, минимальное влияние на другие сервисы и максимальная скорость разработки.
Если мы начнём тестирование и платформы, и прикладных сервисов на одном общем стенде, то длительный процесс отладки платформенного сервиса приведёт к такому же времени отладки прикладных сервисов + времени на их собственное тестирование. Поэтому мы выделили отдельные тестовые контуры для платформы и прикладов.
Так как основных слоя два, то и контуров достаточно двух. На платформенном контуре производится сборка и отладка платформенного релиза. В зависимости от зрелости инструментов DevOps и процессов производства, на контуре может быть разное количество стендов. Но главное, чтобы в итоге мы получили стабильную версию платформы.
После этого её можно передавать на контур с бизнес-потребителями, где они производят тестирование в своём быстром релизном цикле.
Ввели контроль платформенного API
Понятная вещь, о которой все говорят, но которая не всегда случается. Обязательные правила, которые мы применили:
на старте проекта попросили всех владельцев платформенных сервисов опубликовать свои контракты как можно раньше, ещё до того, как началась разработка. После чего они не должны были меняться. Здесь многое упирается в профессионализм людей, которые проектируют API. Мы доверили это самым опытным сотрудникам внутри команд, отвечающих за разработку сервисов;
создали инструмент, который осуществляет контроль этого API. У нас для этого есть отдельный компонент — синтетическое приложение. О нём чуть позже;
сделали процесс согласования изменения API максимально дорогим:
согласование изменений архитектурой платформы;
согласование со всеми потребителями API;
согласование с руководителями. Инициатор изменений должен был получить ОК от двух ключевых людей — владельца СберБанк Онлайн и руководителя программы внедрения новой платформы. Да, им лично приходилось объяснять, почему API всё-таки нужно поменять и как так случилось, что делать это нужно после того, как началась разработка. И да, такие кейсы были, но штучные. По сравнению с потоком изменений, которые были до введения контроля, — ничтожное количество.
Важно отметить, что мы строго контролируем API в рамках минорных релизов платформы и не строго (изменения возможны, но согласуются с архитектурой) — в рамках мажорных релизов.
Следим за удобством разработки на платформе
Случается так, что платформу сделали, а пользоваться ей неудобно. Вроде как клиент платформы — внутренний, поэтому может потерпеть. Это большая ошибка, особенно когда потребителей платформы много. И мы создали независимый орган, который следит за клиентским опытом потребителей платформы и отстаивает их интересы — «Синтетическое приложение».
Эта команда играет ключевую роль — собирает отдельные сервисы платформы в единый продукт. У ребят много задач:
выпуск POM/BOM. Большая часть платформенного API предоставляется в виде клиентских библиотек. Ребята из «Синтетического приложения» собирают их вместе, разрешают конфликты зависимостей и публикуют для потребителей POM- и BOM-файлы;
контроль обратной совместимости API. Кроме проверки на конфликт зависимостей, все библиотеки проходят тестирование на бинарную совместимость с предыдущими версиями;
тестирование платформы в качестве бизнес-потребителя. После того как каждый компонент платформы прошёл своё компонентное тестирование, важно убедиться, что собранная конфигурация платформы стабильна. Сделать это можно с помощью бизнес-потребителя. Но тогда бизнес-проект будет нести на себе все риски отладки дефектов в платформе. Тем более один бизнес-проект может не выявить проблем, которые специфичны другому. Поэтому мы делаем это с помощью специального приложения, которое похоже на реальное бизнес-приложение, но содержит максимально возможное количество кейсов использования платформенных сервисов и покрыто кучей тестов. Таким образом, бизнес-потребители приходят уже на стабильную версию платформы, а риски пересборок из-за дефектов на платформе значительно меньше;
контроль за документацией. Идеальному сервису документация не нужна. Но сервисы неидеальны. Кроме того, как бы вы ни старались сделать платформенные компоненты универсальными, требования от потребителей будут отличаться. Компенсировать эти отличия позволяют возможности конфигурирования, которые тоже надо документировать и описывать. Опять же, если платформенных сервисов много и в промышленной эксплуатации уже несколько версий платформы, то даже навигация по документации становится непростой задачей;
СSI и обратная связь. Продукт не может быть хорошим, если нет механизма обратной связи от клиентов. Мы проводим регулярную оценку CSI и сессии обратной связи с потребителями платформы. После этого направляем фидбэк в команды разработки платформенных сервисов и контролируем, что «боли» клиентов не останутся без внимания;
сообщество разработчиков. Разработка на платформе становится легче и результативнее, если есть инструменты прямого взаимодействия с её разработчиками и можно пообщаться с коллегами, которые раньше вас пришли на платформу. У нас основным инструментом такого взаимодействия выступает сообщество разработчиков. У них есть чаты, где они могут задать любые вопросы по разработке на платформе, митапы и воркшопы, на которых можно получить новые и обменяться своими знаниями. Основная польза от этой истории для прикладного разработчика — помощь сообщества. Главная польза для ребят из платформы — прямое взаимодействие со своими потребителями.
Архитектурный контроль
Для всех прикладных сервисов мы ввели необходимость прохождения ревью архитектуры. Основная задача этого ревью — исключить влияние прикладного компонента на другие и на платформу в целом. Ошибка в проектировании прикладного сервиса может привести к тому, что повышенная нагрузка на один из платформенных сервисов вызовет недоступность всей платформы, а, следовательно, и всего СберБанк Онлайн. Кроме того, на архитектурном ревью мы следим за горизонтальными вызовами между прикладными сервисами.
Где мы сейчас и что делаем дальше
Внедрение платформы случилось порядка двух лет назад, и сейчас уверенно можно говорить, что оно успешно решило основные вызовы, которые перед ним ставились. В настоящее время у нас уже более 250 проектов, количество которых постоянно растёт.
Мы существенно сократили T2M для прикладных проектов относительно Legacy, где релизный процесс предполагал включение в релиз за шесть месяцев до полной раскатки. Точные цифры назвать сложно, так как они зависят от доработок смежных систем, но мы уменьшили время от подачи заявки в релиз до прома до трёх недель.
Тем не менее мы ещё в начале пути и ещё много задач, которые предстоит решить:
миграция профиля и сессии. Мы обеспечили запуск проектов, но Legacy продолжает оставаться источником основных данных по профилю клиента. В отличие от запуска атомарных клиентских сценариев, это то, что нельзя разработать рядом и потом плавно переключиться. Приходится много дорабатывать одновременно: и Legacy, и новое приложение. Всё это — под огромной пользовательской нагрузкой. Весьма сложная история, достойная отдельной статьи;
нормальный технологический стек и удобство разработки. Если вы обратили внимание, в цели проекта не входило внедрение нового стека. Даже больше: мы сознательно от него отказались. Основной аргумент — не увеличивать сложность на и так сложном проекте. Если смена стека с точки зрения разработки несёт приемлемые риски, то с точки зрения эксплуатации и внедрения риски очень высокие. Так как надёжность, доступность и безопасность — самые важные критерии, которым мы следуем при любой разработке в СберБанк Онлайн, то и требования к инфраструктуре и эксплуатации очень высокие. Поэтому смена стека в run-time требует большой аккуратности, что неизбежно сказалось бы на сроках.
Так что наши разработчики счастливо программируют на Java 8. А деплоится это всё на вендорском JDK. Многие, кто слышит об этом на наших собеседованиях, расплываются в улыбке от счастья. Или не от счастья, мы точно не знаем. Если серьёзно, то это надо менять, и одна из текущих задач на платформе сейчас — смена стека. А для прикладных команд мы обсуждаем возможность разработки на Kotlin.
Кроме того, на платформе много специфики этой платформы. Это тоже нехорошо, так как создаёт высокий порог вхождения для новых разработчиков и способствует изоляции от внешнего мира тех, кто давно на проекте. У нас есть трек активностей, направленных на то, чтобы изменить это в лучшую сторону.
Спасибо за внимание, жду вопросы в комментариях.