TechX Sharing: введение в домен клиента | by MingMing Jantima Boonruethairat | май 2023 г.

Я хотел бы поделиться знаниями, полученными от TechX Sharing, в теме «Введение в домен клиента», чтобы друзья могли обновить свои знания о технологиях и управлении серверной системой. Удовлетворить все потребности клиентов, удобно, быстро, идти в ногу с быстро меняющимся ритмом жизни. От очень талантливого оратора, г-на Гольфа, заместителя директора по разработке программного обеспечения.

Общеизвестно, что сегодня банк старается разрабатывать различные системы, чтобы они были современными, своевременно реагирующими на потребности и образ жизни всех групп клиентов, а не на мейнфрейм, используемый для проведения транзакций. Поэтому он был изменен для работы в облачной системе, использующей новый технологический стек, который имеет хорошие результаты в масштабировании и может поддерживать больше приложений. Сократите затраты больше, чем при использовании мейнфрейма, многие проекты которого теперь перенесены с мейнфрейма, например, межбанковские переводы через ITMX теперь выполняются в системе, которая Микросервисы Существует также платежный домен с клиентским доменом.Платежный домен — это система, которая управляет всем, что связано с платежами, такими как денежные переводы, пополнение счета, оплата счетов и т. д. друзья, известная на этот раз как система для хранения данных о клиентах. Цель состоит в том, чтобы создать систему, удобную и быструю для получения информации от RM, которая является системой мейнфреймов банка.

RM — это мейнфрейм, который использует весь свой потенциал. Если вы хотите увеличить возможность работать больше или быстрее загружать различные данные Приходится платить, чтобы разблокировать, чтобы повысить уровень способности работать или загрузить больше, и стоимость, которую необходимо выделить для поддержки этого раздела, довольно высока. Кроме того, различным агентствам сложно запрашивать некоторые корректировки API, поскольку рабочий процесс мейнфрейма не способствует корректировкам API.Есть еще много проблем. Например, если вы хотите получить информацию о клиенте >> необходимо вызвать API Enterprise API (EAPI) >> Enterprise API отправляет запрос в MQ >> для повторного перехода к RM, и это еще не конец, поскольку API подготовлен. Будет API для извлечение отдельной информации, как информации о клиенте, адрес, контактный номер, которые в режиме реального времени, многие отделы имеют множество сценариев, которые они хотят получить информацию для использования. который должен получить более 5-6 строк данных, что вызовет довольно много накладных расходов.Кроме того, некоторые агентства теперь имеют некоторые данные в облачной системе.Если мы используем RM, как раньше, вызов будет запросить, чтобы облако спустилось на локальный мейнфрейм, это вызовет довольно большую задержку.

от вышеперечисленных проблем Это заставило команду разработчиков SCB TechX изобрести новую систему под названием «Домен клиента», чтобы заложить основу для гибкости API в соответствии с характеристиками информации о клиенте, которые каждое агентство предъявляет разные требования, например, некоторым агентствам нужна только основная информация. Личная информация, некоторые агентства могут хотеть только адрес. Или агентство может захотеть, чтобы личная информация могла выбирать дополнительные подполя. Что, при возможности, было бы очень полезной вещью. Сама система не обязана отправлять информацию, которой не пользуются различные агентства. Само агентство получает информацию по мере необходимости. И самое главное, сколько бы ни было запрошено полей, вызов осуществляется только один раз. Так что это может решить многие проблемы довольно много.

При разработке клиентского домена команда намеревается сделать его облачным, простым в масштабировании и с хорошей производительностью, поэтому мы выберем язык Golang, поскольку этот язык соответствует собственному коду, что обеспечивает высокую производительность. Высокий и при использовании в связке с Docker или Container, даже как нативный код, его можно легко масштабировать для работы на любой BM.На самом деле Golang в этом проекте не используется, это первый проект, в котором Golang используется. Раньше в Project Payment Domain, где при выполнении теста производительности результаты были удовлетворительными на 4000–5000 GTS когда-либо.

1. Приходите на помощь в вопросе RM Offload, потому что для настройки системы Customer Domain мы используем принцип под названием Primary-Slave позволяет RM быть основным или источником правды, а наша система является ведомой, которая снова синхронизирует данные из RM.

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

3. Гибкий, простой в использовании и может быть использован Любая организация, которой что-то нужно, может указать всю необходимую информацию в одном запросе, потому что мы используем GraphQL в качестве основного API.

4. Это система, которую мы разработали сами и запускаем в облаке, поэтому ее стоимость намного ниже, чем у мейнфрейма.

5. У нас также есть проекты поддержки для других проектов, таких как приложение SCB EASY и Level Up, которые в настоящее время используют API RM. Мы хотим, чтобы эти объекты легко переносились для использования домена клиента, поэтому мы подготовили библиотеку для приложения SCB. и Level Up можно использовать сразу, эта библиотека автоматически создаст запрос GraphQL к домену клиента. Вам не нужно иметь дело с GraphQL самостоятельно.

На первом этапе, если клиент использует финансовую транзакцию через приложение SCB EASY или Level Up >>, приложение будет обращаться к серверной части приложения. Если это приложение SCB EASY, оно будет обращаться к серверной части приложения в локальной среде, что если это Level Up, он будет обращаться к серверной части Level Up >> и когда приложению SCB EASY или Level Up потребуются данные клиента, оно будет вызывать наш домен клиента (в настоящее время это RM, нам нужно будет изменить его на домен клиента) Домен клиента. Мы будем работать в Azure, и в будущем мы стремимся поддерживать больше отделов.

Чтобы проиллюстрировать больше, давайте приведем следующий пример: когда приложение SCB EASY вызывает серверную часть самого приложения SCB EASY, первоначально Call RM, если мы хотим перейти на Call GraphQL, мы разработаем Lb для подключения к приложению SCB. EASY >> Затем пусть приложение SCB EASY приходит и вызывает через функцию, которую мы подготовили, используя те же параметры, которые они использовали для вызова RM >> тогда LB сможет выбрать Authen из домена клиента для управления запросом на сборку в Это GraphQL >> управлять прошлым ответом, который возвращается >> и затем отправлять его обратно в приложение SCB EASY для продолжения использования >> тот же код, который использовался для работы с RM, можно использовать немедленно, изменить только слой, который запрашивает данные, чтобы изменить его на Call LB вместо этого наш

Лицо запроса Graph QL выглядит как на картинке ниже Предположим, что в Hero (верхнее поле) нам нужны какие-то данные, мы вставляем их в строки, а система (нижнее поле) будет возвращать значения в соответствии с нашей командой.

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

После вызова API в После этого есть база данных, используемая для хранения пользовательских данных, которую мы используем как MongoDB >> Затем микросервисы будут запрашивать данные из MongoDB >> Когда результат будет получен, он вернется обратно в различные отделы в виде простого потока >> данные в этой базе данных берутся из RM, используется модель Primary-Slave, мы являемся ведомыми, которые синхронизируют данные из RM.

Существует два уровня синхронизации данных.

1. Первый уровень — это ежедневная синхронизация данных (ежедневно).В конце дня RM собирает все обновления за этот день и помещает их в одно место, а клиентский домен подготавливает пакет для получения этого обновления файла для обработки.И обновляет в базу данных, поэтому информация будет обновляться каждый день.

2. Второй уровень, обновления в течение дня. Также известна как онлайн-синхронизация.Она работает, когда у RM есть обновления. Независимо от того, кто редактирует данные, изменения публикации отправляются в MQ. В EAPI есть прослушиватель синхронизации RM, который подписывается на изменения MQ. есть и другие системы, которые тоже хотят знать об изменениях, вы можете подписаться на них. Микросервисы Еще один, который поддерживает подписку на e-Kafka, поэтому, если есть изменение от RM, когда бы оно ни поступало, оно будет получать обновление от этой e-Kafka, втекающее в него. Microservices (ETL), то этот Microservices обновит запись в базе данных, которая почти в реальном времени синхронизируется с RM, и будет пакет в конце дня, чтобы гарантировать, что обновление пройдет успешно, без каких-либо ошибок. Если есть, это будет исправлено во время ежедневной партии в конце дня.

Шаги аналогичны эпизоду, но будут немного подробнее о том, через какие маршруты проходят, то есть приложение SCB EASY приходит с мобильного >> проходит через CA Layer 7 Gateway >> входит в бэкенд SCB EASY само приложение >> из. Это входит в Instio Ingress, потому что клиентский домен мы снова запускаем в Instio, который находится в службе Azure Kubernetes (AKS), поэтому при входе в Instio Ingress >> через микросервисы >> доступ к базе данных

Теперь, этап ежедневной пакетной обработки, если мы посмотрим глубже, когда вводится файл публикации RM, сначала он отправляется в большой двоичный объект Azure, который сначала размещается (постановка похожа на размещение банковского файла, здесь будет размещен файл из обновления RM) > > Позже Trigger Daily Batch, который поступает каждый день, перенесет файл отсюда в большой двоичный объект Azure на стороне клиентского домена. Для обработки ежедневного пакетного файла мы используем Azure Databricks для помощи в обработке. Azure Databricks — это система, которая используется для ETL или обработки данных.Обработка, которая имеет большой объем, поэтому, если в будущем у нас будет много данных, которые необходимо обновлять в день, Azure Databricks внутри него может извлекать текст, извлекать узлы, выполнять параллельную обработку, чтобы помочь процессу данные, позволяющие быстро обрабатывать данные, несмотря на их размер очень большой

Домены клиентов используют Prometheus для сбора различных показателей. Микросервисы Работу можно просматривать через Grafana, которая имеет систему журналов, которую можно хранить в Запрос можно сделать через Kibana. Секреты хранятся в хранилище. Существует система Pager Duty, которая вызывает оповещения. Когда система обнаруживает ошибку или неисправность, руководителю разработки отправляется SMS для расследования и устранения проблем и т. д.