|
Рубрика:
Финтех /
Банковская архитектура
|
Facebook
Мой мир
Вконтакте
Одноклассники
Google+
|
 ВИЗИТКА
Ольга Федорова,
технический лидер «Альфа банка»
Эволюция банковской архитектуры
как пособие по старту нового проекта
В данной статье мы рассмотрим способы, которые помогали решать проблемы финтеха на пути его становления, общую эволюцию банковских решений, а через ее призму и подход к выбору архитектуры новых проектов.
Архитектура банковских решений имеет свои характерные особенности.
Во-первых, любой банк – это в первую очередь крупный участник финансового рынка, деятельность которого всегда находится под пристальным вниманием регуляторов, что не может не отражаться на безопасности, выборе технологий, применяемых подходах.
Во-вторых, любой банк – это крупная компания с долгой историей развития, среди продуктов которой обычно можно найти как решения, реализованные в соответствии с лучшими практиками на последнем стеке технологий, так и откровенно устаревшее легаси, существующее по принципу «работает – не трогай» и «это для внутреннего пользования».
В-третьих, любой банк – это корпорация, обладающая огромными ресурсами, которые позволяют экспериментировать с технологиями при реализации программных продуктов (в рамках разумного, конечно). В результате обычно получается широкое разнообразие решений, весьма креативных как в положительном смысле, так в отрицательном.
Развитие и поддержка продуктов в таких условиях выглядит довольно нетривиальной задачей: зачастую в рамках обеспечения очередного взаимодействия требуется совместить несовместимое.
В данной статье мы рассмотрим способы, которыми решали проблемы финтеха на пути его становления, общую эволюцию банковских решений, а через ее призму и подход к выбору архитектуры новых проектов.
В начале был Oracle
Цифровизация финансовых операций началась в 70-х годах прошлого столетия. В этот же период компания (SDL) представила революционную технологию для хранения и управления данными: базу Oracle. Последняя буквально за несколько лет стала лидером рынка.
Этому способствовал целый ряд факторов. Во-первых, предложенная Эдгаром Коддом модель хранения данных в виде связанных таблиц с жестко заданными правилами произвела маленькую, но значимую революцию на зарождающемся рынке.
Во-вторых, Oracle разработала SQL, язык запросов к реляционным базам данных, который позже был стандартизирован в виду своей популярности и лег в основу других реляционных СУБД.
В-третьих, будущая корпорация уделяла много внимания производительности и надежности своего решения: разрабатывались оптимизаторы запросов, кэширование данных и другие подобных технологии.
Кроме того, надо отдать должное маркетингу: Oracle сотрудничала с крупнейшими организациями и правительственными учреждениями. Достоверно известно, что компания участвовала в реализации критически важных информационных систем для государственных органов и организаций в области обороны, здравоохранения и финансов. Это сотрудничество подчеркнуло надежность и безопасность их продуктов для коммерческого мира. Последствия не заставили себя долго ждать, и экспансия технологических рынков Oracle вышла на мировой уровень.
История финтеха началась абсолютно также: банки покупали СУБД как готовое решение, а оно, в свою очередь, постепенно обрастало логикой трансформации, хранения и извлечения данных, по сути, являясь сердцем банковской структуры.
Достаточно быстро финансовые учреждения столкнулись с проблемой: сложность обработки кратно увеличилась Новые клиентские данные, растущий объем транзакций, зарождение сложных бизнес-процессов постепенно привели к тому, что более-менее единая система невероятно разрослась.
Вместе с этим возникла потребность в логическом разделении системы. Во-первых, встал вопрос эффективного управления командами и их взаимодействия.
Во-вторых, наметился функционал, который можно было бы переиспользовать для разных процессов.
В-третьих, отдельные части системы нужно было независимо оптимизировать и масштабировать. Примерно на этом этапе начали внедряться идеи модульного программирования.
В тоже время развитие компьютерных сетей, протоколов и ограниченность физических ресурсов привели к тому, что начали отделяться отдельные логические элементы, превращаясь в независимые приложения.
Вместе с тем усложнялась и структура. СУБД Oracle все еще являлась сердцем банковской структуры, но уже постепенно можно было говорить про зарождение более сложной архитектуры и переход от монолитных решений к первым попыткам создать нечто распределенное.
В середине тоже был Oracle
Свою популярность начали набирать идеи SOA -архитектуры, однако первые попытки были не очень удачными. В условиях отсутствия стандартов каждый отдельный проект мог использовать свой собственный протокол, свой собственный формат данных, да и разнообразием платформ они тоже отличались. Особенно решения, приобретенные у разных поставщиков. Все это приводило к так называемым точечным интеграциям: любое взаимодействие требовало индивидуальной разработки и поддержки.
Вместе с тем шли все сопутствующие проблемы: сложность обновления и мониторинга систем приводила к большим затратам ресурсов, а общая сложность всех этих решений только увеличивалась, вместе с нагрузкой на них. Вдобавок, не было единого центра управления системой. Потребность в согласованности данных и процессов росла, и Oracle, как ведущий поставщик программных решений, предложил свое видение концепта ESB, а именно Oracle Service Bus. Ради справедливости, отметим, что корпорация не была автором оригинальной концепции, однако в том числе благодаря ей этот паттерн на долгие годы поселился в enterprise-решениях.
Service bus привнес в финтех долгожданную управляемую и единообразную интеграцию для всех типов систем и приложений независимо от используемых технологий и протоколов.
Кроме того, он забрал на себя ответственность за маршрутизацию, стандартизацию, мониторинг, обработку ошибок взаимодействия. Как следствие существенно расширились возможности для масштабирования.
На этом этапе развития СУБД перестала быть центром банковской вселенной, им стал ESB. Отголоски этой эпохи до сих пор можно найти практически в любом банке, хотя на данный момент технология признана устаревшей.
А что было потом?
Все преимущества ESB (корпоративная сервисная шина) постепенно превращались в его же недостатки. Да, раньше в системах не хватало контроля, но теперь его стало слишком много. Для такой архитектуры характерны крупные релизы, во-первых, из-за высокой зависимости компонентов друг от друга, во-вторых, из-за централизованного контроля.
В результате мы получаем картину, когда банк сначала накапливает определенную существенную дельту изменений, потом долго исследует совместимость всех доработок, планирует технологическое окно для релиза и если вдруг что-то пойдет не так… Процедура возможного отката изменений опять-таки слишком сложна из-за централизации и зависимостей, откатить всю ESB-платформу крупной корпорации невероятно сложно.
Тот факт, что каждый релиз – это всегда большое событие, постепенно начинает сказываться на масштабируемости. По мере роста системы ESB становится уязвимым местом, которое влияет на производительность. Стоимость внедрения систем, которые должны быть доступны 24/7 существенно возрастает. И это вдобавок к тому, что сам по себе service bus – недешевое удовольствие, требующее специализированных знаний, а привязка к конкретному поставщику (как Oracle, например) добавляет рисков и затрудняет переход на новые технологии.
Кроме того, на рынке появляются новые гибкие методологии управления проектами, пропагандирующие быструю доставку ценности конечному потребителю.
Эра микросервисов
Новым решением накопившихся проблем стала микросервисная архитектура. Самое главное, что в итоге индустрии дал ESB – это стандартизация. И как показала практика, ее достаточно для обеспечения нормальной работы системы даже в условиях отсутствия централизация. Более того, именно децентрализованность микросервисов кратно снизила их зависимость друг от друга.
Это позволило разработчикам увеличивать частоту релизов. На данный момент стандарт в индустрии держится в районе нескольких релизов в день, однако специфика разработки в банках, особенно бюрократическая составляющая, зачастую сводит этот показатель до нескольких релизов в неделю. Но это уже несравнимо с тем, что было раньше.
Децентрализованная архитектура кратно проще масштабируется, позволяет легко использовать разные технологии и не зависит от конкретного поставщика.
Несмотря на популярность данного решения, переписать абсолютно всю банковскую структуру именно на него не представляется возможным, а главное – целесообразным. Именно поэтому во многих банковских структурах осталось наследие Oracle, к которому так или иначе обращаются уже новые приложения, написанные на микросервисах через какие-либо фасады.
Особо интересным в этом разрезе выглядит вопрос импортозамещения. Но скорее всего он разрешится большинством участников рынка через использование отечественных ESB-решений, а сама структура останется практически неизменной, опять-таки из-за сложности перехода на более современные решения.
Таким образом, почти любой крупный банк, давно представленный на рынке, является некоторым отражением истории развития индустрии и включает элементы всех пройденных ею этапов.
Эволюция индустрии в проектах
Более того, эта историчность присуща и проектам, особенно в сложных доменных областях, коей, в том числе, является финтех. Когда микросервисная архитектура только набирала свою популярность, многие воспринимали ее как серебряную пулю, способную решить все проблемы монолитных решений. Это привело к тому, что многие проекты пробовали начать сразу именно с распределенной архитектуры, пропустив все предыдущие шаги.
Однако, как показала практика, преждевременное разбиение на микросервисы чаще всего приводит к проблемам, нежели к оптимизации использования ресурсов. На ранних стадиях развития проекта очень сложно определить границы контекстов. Неправильное разбиение нивелирует все потенциальные преимущества. В результате вместо микросервисов получится распределенный монолит, который, в отличии от его нераспределенного варианта, кратно сложнее поддерживать, мониторить и масштабировать.
Безусловно, как и везде, в данном правиле есть свои исключения, однако наиболее органичный вариант развития проекта начинается именно с монолита. По мере реализации сложных бизнес-процессов постепенно будут проявляться отдельные логические части, претендующие на то, чтобы в будущем отделиться.
На этом этапе уже можно переходить к модульной структуре, которая позволит безопасно наметить границы и проверить насколько верным оказалось решение. Даже если оно неверное (как обычно бывает с первого раза), изменение разбиения потребует минимальное количество ресурсов. При этом после корректного определения границ задача превращения модуля в отдельный сервис представляется довольно простой и является следующим логичным этапом эволюции архитектуры проекта.
В среднем проекту достаточно около полутора лет, чтобы повторить тот путь, который индустрия прошла более чем за 70 лет. Любопытно то, что попытка пропустить любой из этапов в большинстве случае лишь создает дополнительные проблемы как стейкхолдерам, так и команде разработки.
Ключевые слова: архитектура банковских решений, Oracle, микросервисы, ESB- решения, СУБД
Подпишитесь на журнал
Купите в Интернет-магазине
Facebook
Мой мир
Вконтакте
Одноклассники
Google+
|
Эволюция банковской архитектуры как пособие по старту нового проекта
