Корпоративная сервисная шина сбербанк

Enterprise Service Bus (ESB) / Корпоративная сервисная шина (КСШ) = ПО, обеспечивающее централизованный и унифицированный обмен сообщениями между различными ИС предприятия. Подробнее в wikipedia.
Если в «дошинную» эпоху общепринятой концепцией была интеграция различных систем друг с другом напрямую, т.н. соединение «точка-точка», то с появлением шины — она становится главным транспортным узлом в интеграционной архитектуре предприятия, в определённом смысле объединяя в себе все API предприятия:

КСШ собой эволюционный виток архитектурной мысли в рамках сервисно-ориентированной архитектуры в «домикросервисную эпоху». Хорошо подходит для средних размеров предприятий с относительно небольшим количеством ИС (десятки).

Оглянувшись на свой и чужой опыт, можно извлечь несколько уроков использования КСШ:

1. Заклинаю, не надо совать в Шину бизнес-логику, проблем потом не оберётесь. Использовать Шину следует только как транспорт.
   Да и вообще идея вставлять бизнес-логику в вендорные решения и фреймворки — нарушение принципов DDD и заключение вашего предприятия в т.н. vendor-lock;
2. ESB могут стать «узким горлышком», когда множество команд других ИС ждёт доработок от команды ESB. Больше зависимостей —> больше общий TTM (time to market).
   Всё это может значительно усугубиться в ситуации, когда в вашей компании количество специалистов, знающих Шину — стремится к нулю.
3. На Шину со множеством адаптеров обязательно нужны автотесты, руками регресс десятков-сотен кейсов адаптеров не покроется, особенно если необходимость в регрессе возникает раз в несколько дней или чаще, ведь на Шине с большой связанностью постоянно будет что-то меняться. Вопрос: стоит ли «вешать» разработку и тестирование на вендора?
   Автотесты требуют всегда актуальных артефактов п.4;
4. Должен быть выстроен процесс сохранения и актуализации артефактов проектирования, разработки, тестирования Шины и всех ИС, работающих с Шиной. Нужны Архитекторы, и они должны быть «пишущие».

В основном это касается крупных ESB, на которые «нацеплены» большая часть ИС предприятия.
Если мы говорим о «небольших» шинах типа Kafka и RabbitMQ, то с ними всё гораздо проще, кроме того, они часто задействованы в микросервисной и service-mesh архитектуре, а также в смешаной архитектуре.

Видео:Интеграционные шиныСкачать

Корпоративная сервисная шина Сбербанка: особенности применения и стратегия обновления

Видео:Плюсы и минусы сервисной шины данных I Enterprise service bus (ESB) I kt.teamСкачать

Что такое КСШ?

Использование информационных систем для управления информации производится на основе взаимосвязанных между собой отдельных протоколов обмена. Негативной стороной данного подхода выступает необходимость создавать новый протокол для обмена данными между внедренными сервисами.

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

Видео:Корпоративная сервисная шина данных DATAREON ESB. Знакомство с продуктом. Урок 1Скачать

Структурные характеристики

Программы интеграционной логики:

• АБПК Прагма автоматизирует процессы банковской системы по обработке запросов физлиц и юрлиц.
• CRM розничный обеспечивает процессы реализации клиентам-физлицам.
• CRM бизнес (корпоративный) обеспечивает процессы реализации клиентам-юрлицам.
• Transact SM скоринговый сервис оценки заемщика банковской организации.
• ЕПК/ЦНСИ – сервисный инструмент для управления профилем пользователя и направления нормативно-справочной информации.
• Way4 – процессинг, направленный на обработку данных, применяемых при осуществлении платежных операций.
• СМС-шлюз Intervale – шлюз для обмена СМС.

Видео:СПРОСИ ЭКСПЕРТА: Выпуск 1. Чем отличается шина данных от ETL?Скачать

Преимущества системы

Относительно других методик, интеграция КСШ направлена на получение ряда привилегий:

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

Видео:Интеграция систем 1С с помощью сервисной шины предприятия DATAREON ESBСкачать

Функционал системы

• Образование единой гибкой структуры интегрирования, обеспечение системных архитектурных решений.
• Формирование масштабов, направленных на расширение функционала системной шины посредством включения новых сервисов.
• Динамическое внедрение маршрутов, системы фильтрации, агрегирования СМС. В основе лежат правила или бизнес логика, дополненные инновационными расширениями. К примеру, доступно задание установки приоритетных опций для отдельной категории потребителей или направление больших заказов на спецобслуживание.
• Преобразование данных, обмен информацией программных обеспечений в разных формах.
• Создание новых сервисов или поддержание существующих. К примеру, использование готового приложения без внесения изменений в код.
• Осуществление посредничества между сервисами, виртуализация.

Видео:Интеграция систем на примере шины ESB · Евгений Путилин · ЛАФ #системныйаналитикСкачать

Роль КСШ в банковской системе

Основным приоритетом стратеги выступает создание операций в компетентном центре. При запуске систем «Сбербанк Онл@йн» и «Сбербанк Бизнес Онл@йн» развитие совершалось самостоятельно. Системы имеют технические сходства, однако эта взаимосвязь не фиксировалась ранее. С использованием best practices обоих сервисов, возможно совмещение части функций, вынесение их в общие роли и команды.

Стратегия Сбербанка заключается на выведении более 90% операций в каналы ДБО, отличающиеся удобством и экономией средств, относительно обслуживания с ВСП (внутренних структурных подразделений). СБОЛ и СББОЛ выступают в виде ключевых фронтальных сервисов СБ, обеспечивающих ежедневное взаимодействие с клиентами и совершение основной части операций.

СББОЛ изначально был разработан на 350 тыс. клиентов. Сегодня показатели достигают до 1 миллиона. Программа не была готова к подобному приросту, что и повлияло на создание параллельного сервиса. Он обладал индивидуальными техническими характеристиками и структурой, позволяющей разделить нагрузку. Попытка не дала результатов из-за недостаточности ресурсов вендора. Решено дублировать готовую систему и разделить базу клиентов на два параллельных направления. Отделение системы для бизнеса произошло без сбоев. Это максимальный уровень качества в ИТ.

Читайте также: Давление в шинах спортивного автомобиля

Видео:DATAREON ESB. Коротко о главномСкачать

Особенности реализации стратегии

Основная цель новых внедрений направлена на усовершенствование удаленных каналов по обслуживанию клиентов СБ:

1. Розничного онлайн-банкинга для частных лиц.
2. Бизнес онлайн-банкинга (инструмента для обслуживания юрлиц и частных предпринимателей).
3. Мобильного банкинга и процессинга.

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

«Новая форма обслуживания индивидуальных клиентов способствует совершенствованию взаиморасчетов Сбербанка с пользователями, увеличивает объем предоставляемых услуг, стимулирует клиентов производить операции удаленно. Приоритетным направлением выступает использование стандартных услуг банка, не посещая офисы компании. Пользователи удовлетворены новыми направлениями и это главное», — сообщил В. Кузьмин, руководитель финансового отдела.

«Запуск новой формы предоставления услуг стал возможен вместе с внедрением КСШ. Она позволяет объединить более 100 типов систем и производить сквозные транзакции между узлами, расположенными в 9 часовых поясах по РФ», — пояснил И. Рубцов, замдиректора ИТ-организации КРОК.

«Новые решения в области интеграции систем выступает отличной основой для развития IT-инфраструктуры Сбербанка, запуска новых опций и оптимизирования бизнес-операций», — сообщил В. Орловский, ответственный за внедрение IT технологий.

Разработка системы производилась с использованием платформы ИВМ ВебСфер Месседж Брокер 7.0. Специалисты организации КРОК наряду с ИТ-отделами Сбербанка с помощью профессиональных сотрудников в сфере IBM, спроектировали и разработали интеграционные решения, объединившие смежные системы банка, создание прикладного программного обеспечения (функциональной подсистемы, бизнес-приложения), развертывание средств программ.

«В условиях рыночной конкуренции предоставления услуг, необходимо руководствоваться новыми способами борьбы за клиентскую базу, направляя свои силы на качество и надежность обслуживания, доступность банковских информационных систем. Разработка программных продуктов IBM способствует внедрению эффективных бизнес-методов и получению новых достоинств, относительно конкурентов», — говорит Андрей Суворов, администратор отдела по работе с финорганизациями, IBM в РФ и стран союзников.

Видео:Вебинар "InterSystems IRIS как сервисная шина предприятия (Enterprise Service Bus)"Скачать

Видео

Видео:Применение корпоративной шины данных "1С:Интеграция КОРП" для задач ГК "Ростех"Скачать

Сбербанк завершает внедрение нового формата обслуживания частных клиентов

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

В рамках программы «Базовый продукт» Сбербанк завершит внедрение новой ИТ-системы для обслуживания частных клиентов в территориальных подразделениях Сбербанка. Новый формат обслуживания позволяет клиентам банка, оформившим универсальный договор банковского обслуживания, получить нужную им информацию через банкомат или службу Сбербанк ОнЛ@йн. Клиенты могут узнать о состоянии счетов, вкладов, кредитов, а также осуществлять перевод денежных средств между разными счетами, в том числе платежи по погашению кредитов. Для идентификации клиента используется любая карта банка.

Заместитель начальника управления платежных средств и расчетов Сбербанка России, руководитель программы Владислав Кузьмин отмечает, что новый формат позволяет клиентам пользоваться различными стандартными банковскими услугами, не обращаясь в отделение банка. «Новый формат обслуживания частных клиентов помогает совершенствовать взаимоотношения банка с клиентами, расширять спектр услуг, мотивировать клиентов на работу через дистанционные каналы обслуживания», — заявляет Кузьмин.

«Внедрение нового формата обслуживания стало возможно после разворачивания и запуска в эксплуатацию Корпоративной Сервисной Шины. Она объединяет более 100 экземпляров систем и позволяет в режиме реального времени выполнять сквозные операции между территориальными узлами, находящимися в 9 часовых поясах по всей России», — отмечает заместитель генерального директора компании Крок, которая сотрудничала с Сбербанком в разработке программы «Базовый продукт», Иван Рубцов. Корпоративная Сервисная Шина Сбербанка представляет собой самое масштабное интеграционное решение в мире, созданное на основе продуктов компании IBM.

Совместная работа компании Крок, ИТ-подразделения Сбербанка и специалистов IBM позволила выполнить проектирование и разработку интеграционного решения, которое объединяет банковские системы, разработку специализированного прикладного ПО и развертывание программных средств.

Видео:Шины данных и интеграции | ESB шина данных | Интеграция 1С ERPСкачать

Зачем мы делаем Enterprise Service Mesh

Service Mesh — известный архитектурный паттерн для интеграции микросервисов и перехода на облачную инфраструктуру. Сегодня в облачно-контейнерном мире обойтись без него довольно сложно. На рынке уже доступны несколько open-source реализаций service mesh, но их функциональности, надежности и безопасности далеко не всегда достаточно, особенно когда речь идет о требованиях больших финансовых компаний масштаба всей страны. Поэтому мы в Сбертехе решили кастомизировать Service Mesh и хотим рассказать о том, что в Service Mesh круто, что не очень и что мы с этим собираемся сделать.

Популярность шаблона Service Mesh растет с популярностью облачных технологий. Он представляет собой выделенный инфраструктурный слой, который упрощает взаимодействие между различными сетевыми сервисами. Современные облачные приложения состоят из сотен и даже тысяч таких сервисов, каждый из которых может иметь тысячи копий.

Взаимодействие между этими сервисами и управление ими — ключевая задача Service Mesh. Фактически это сетевая модель из множества прокси, управляемая централизованно и выполняющая набор весьма полезных функций.

Читайте также: Зимові шини бел шина

На уровне прокси (data plane):

• Назначение и распространение политик маршрутизации и балансировки трафика
• Распространение ключей, сертификатов, токенов
• Сбор телеметрии, формирование метрик мониторинга
• Интеграция с инфраструктурой безопасности и мониторинга

На уровне управляющего контура (control plane):

• Применение политик маршрутизации и балансировки трафика
• Управление повторами и таймаутами, определение «мертвых» узлов (сircuit breaking), управление сбойными ситуациями (injecting faults) и обеспечение устойчивости (resilence) сервисов через другие механизмы
• Аутентификация/авторизация вызовов
• Отбрасывание метрик (observability)

Круг пользователей, заинтересованных в развитии этой технологии, очень широк — от небольших стартапов до крупных интернет-корпораций, например, PayPal.

Видео:Сравнение ESB-систем | Ключевые отличия от брокеров сообщений | kt.teamСкачать

Для чего нужен 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 позволяет решить часть этих проблем и облегчить миграцию со старой архитектуры на новую за счет того, что про логику сетевого обмена можно забыть.

Видео:Установка и настройка шины DATAREON ESBСкачать

Зачем нужна кастомизация Service Mesh

У нас в компании уживаются вместе сотни систем и модулей, а runtime очень нагружен. Так что простого паттерна, когда одна система вызывает другую и получает ответ, недостаточно, потому что в production мы хотим большего. Что еще нужно от корпоративного Service Mesh?

Читайте также: Всесезонные шины r13 для прицепа

Сервис обработки событий

Представим, что нам нужно сделать 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, предоставляемым этой группе потребителей, намного серьезнее. Эту задачу мы делим на две основные части.

• Безопасность. Вопросы, связанные с ddos, уязвимостью протоколов, приложений, операционных систем и так далее.
• Масштабы. Когда счет API, которые нужно отдать клиентам, идет на тысячи или даже сотни тысяч, возникает необходимость в некоем средстве управления этим набором API. Нужно постоянно отслеживать API: работают они или нет, в каком статусе, какой трафик идет, какая статистика и т.д. Шлюз API должен справляться с этой задачей, делая весь процесс управляемым и безопасным. Благодаря этому компоненту Enterprise 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 продолжает развиваться, и мы рады, что можем внести вклад в ее развитие. Надеемся, что наш опыт будет вам полезен.

• Свежие записи
  • Нужно ли менять пружины при замене амортизаторов
  • Скрипят амортизаторы на машине что делать
  • Из чего состоит стойка амортизатора передняя
  • Чем стянуть пружину амортизатора без стяжек
  • Для чего нужны амортизаторы в автомобиле

  
  

  источники:

  https://fasad-adelante.ru/korporativnaya-servisnaya-shina-sberbank

  🎦 Видео

  Опыт внедрения ESB интеграционной шины в ПАО «Газпром Нефть» Михаил ХаритоновСкачать

  

  Шины - ключевой элемент качественной архитектуры | Андрей ПутинСкачать

  

  Интеграционная шина данных для ВУЗовСкачать

  

  Интеграция 1С с СУБД при помощи сервисной шины данных DATAREON ESBСкачать

  

  Офис Сбербанка: сауна, акулы, шаурмаСкачать

  

  Шины VS брокеры сообщений | KT.Team | Андрей ПутинСкачать

  

  Как устроиться дворником в "Сбербанк"Скачать