전통적인 은행 구조의 변화

은행은 기술의 지속적인 발전과 고객 요구의 지속적인 개선으로 인해 인터넷 금융의 급속한 발전과 함께 은행 기술 시스템에 대한 요구 사항이 점차 증가하는 전통적인 금융 산업에 속합니다. 최근에는 전통적인 은행 시스템도 매우 빠르게 발전하고 있습니다. 저는 2008년과 2009년에 처음으로 외국 회사에서 북미 은행을 위한 온라인 뱅킹 및 모바일 뱅킹 상품 개발에 참여했습니다. 대형 국책은행에서 소프트웨어 개발 및 아키텍처 설계에 종사했습니다. 2016년 중반에 국책은행을 떠나 인터넷 전자상거래에 입사했습니다. 1년도 채 되지 않아 다양한 비기술적인 문제로 인해 퇴사했습니다. 문제를 해결하고 은행 시스템으로 복귀했습니다. 저는 현재 소규모 개인 은행에서 제품 디자인 및 아키텍처 디자인에 종사하고 있습니다. 일반적으로 은행 시스템은 지난 몇 년 동안 급속한 발전을 이루었으며 대규모 구조 변화도 수반했습니다. 오늘은 은행의 구조 변화에 대해 소개하겠습니다. 혹시 실수가 있으면 전문가에게 문의하십시오. 정정해줘.

1990년대 초 국내 은행산업이 호황을 누리던 시절, 국내 경제의 급속한 발전과 함께 초기에는 모든 지점이 수동으로 계좌를 관리했고, 정기적으로 본점 시스템에 보고했다. , 은행의 사업 규모도 증가했습니다. 급증하는 작업 모델은 더 이상 수요를 충족할 수 없으므로 1990년대 초에 4대 국영 은행이 과학 기술부의 연구 개발에 대한 투자를 늘리고 시작했습니다. 미국과 영국의 은행 시스템 구축 경험을 바탕으로 현대적인 은행 시스템을 구축하고자 했습니다. 사실 당시에는 컴퓨터에 대한 인상이 아직은 매우 낯설었습니다. 당시의 카운터 시스템은 모두 시각적 인터페이스 없이 통합된 명령줄 모드였습니다. 백엔드 시스템은 아래 그림과 같이 중앙 집중식 아키텍처를 사용했습니다.

그 당시에는 기본적으로 중앙 집중식 아키텍처가 있었습니다. 당시 대부분의 산업 시스템에도 일반적으로 이러한 아키텍처가 있었습니다. 이러한 아키텍처에서 카운터의 프런트엔드 및 백엔드 시스템은 CS 아키텍처와 씩(thick) 클라이언트 모델을 채택합니다. 클라이언트가 업그레이드될 때마다 설치 패키지는 하루 전에 각 콘센트에 배포되어야 합니다. 지금은 상대적으로 낮은 것 같아요. 은행의 백엔드는 대규모 핵심 모델입니다. 즉, 핵심 시스템은 계좌, 예금 및 대출, 총계정원장, 조정, 지불, 입금 계정 및 기타 기능이 모두 중앙 집중식 대규모 핵심 시스템에 있다고 가정합니다. 몇 가지 기능만 핵심 시스템에서 제거되어 주변 시스템에 속합니다. 이러한 주변 시스템은 일반적으로 시장에 나와 있는 일부 소프트웨어 회사에서 제공하는 기성 제품이며 요구 사항을 충족하기 위해 간단한 2차 개발만 필요합니다. 이로 인해 한편으로는 개발 비용이 절감되고 시스템 구현 진행 속도가 빨라집니다. 다른. 그러나 이 아키텍처의 시스템 수용 용량은 여전히 ​​상대적으로 제한되어 있으며, 거래량이 급증함에 따라 곧 수요를 충족할 수 없게 됩니다. 당시 업계 선배들이 이 장면을 소개했을 때 그들의 과학 기술 부서는 매우 매일 바쁘고, 매일 거래량이 늘어났습니다. 매달 상당한 증가가 있을 것이며, 분기별 이자 발생 일괄 처리와 연말 결산으로 모두가 밤새 바쁘게 지낼 것입니다. 그 시대의 모든 은행가들에게도 고통스러운 추억이 되었습니다.

중앙 집중식 시스템은 점차 비즈니스 요구의 급속한 성장을 충족할 수 없게 되었기 때문에 상대적으로 규모가 큰 국유 은행에서는 각 지방 지점에 기존 본사 중앙 집중식 시스템 중 한 세트를 배포하는 것을 고려하기 시작했습니다. 그런 다음 매일 밤 각 지역의 데이터를 일괄적으로 중앙 집중화합니다. 이 아키텍처 방법은 온라인 성능 문제를 가장 빠르게 해결할 수 있지만 새로운 문제도 발생합니다. 여러 은행에서 주정부 간 이체는 일반적으로 불가능합니다.

따라서 1990년대 중후반의 시스템 아키텍처 다이어그램은 아래와 같습니다.

사진을 보면 이전 아키텍처와 가장 큰 차이점은 헤드의 중앙 집중식 배포 아키텍처라는 것을 알 수 있습니다. 그러나 이 분산 아키텍처는 지금 우리가 논의하는 인터넷 분산 아키텍처가 아니었습니다. 당시에는 상대적으로 성숙한 분산 아키텍처 솔루션이 없었기 때문에 당시의 분산 아키텍처는 실제로는 단순한 분산 아키텍처였습니다. 그러나 본청에서 배치한 핵심시스템과 주변시스템을 각 도의 과학기술부서에 별도로 배치하여 행정관계 전반에 걸쳐 독립적으로 운영, 유지관리하는 형태이다. , 실제 과학과 기술 시스템은 분리되어 있으며 필요한 연결이 없습니다. 지방 간 이체 및 기타 업무를 실현하기 위해 매일 데이터를 교환하므로 많은 은행 업무의 효율성이 상대적으로 낮습니다. 좀 더 긴급한 고객 요구를 충족시키기 위해 마지막으로 고객이 타 지역 고객에게 돈을 송금하기 위해 가장 빠른 방법은 카드에서 현금을 인출할 때 먼저 현지를 사용하는 것입니다. 다른 곳으로 친구가 왜 현지에서 인출하지 않느냐고 물었습니다. 당시 지방 간 현금 인출은 현금 인출 시간과 금액에 제한이 있을 뿐만 아니라 처리 수수료도 높았기 때문입니다.

2000년 인터넷의 급속한 발전과 함께 최근 몇 년간 은행의 기술 수준도 급속도로 발전해 왔으며, 은행 간 수준의 격차도 점차 벌어지고 있으며, 은행의 경영상의 문제도 점차 커지고 있다. 각 지방의 기존 분산 배포도 점차 확대되었습니다. 이는 ICBC가 이전에 분산된 지방 은행 시스템을 본사로 이전하는 데 앞장섰음을 강조합니다. 시스템 이전이 왜 각 지방에서 별도로 배포되어야 했습니까? 이는 중앙 집중식 시스템 아키텍처가 매일 빠르게 증가하는 비즈니스 볼륨을 더 이상 감당할 수 없기 때문입니다. 각 지역의 데이터가 다시 수집되면 일일 핵심 배치가 완료되지 않고 주변 시스템에 배포될 수 있음을 의미합니다. 다음날 영업시간이에요 이를 위해 과학기술 부서에 대한 압박은 여전히 ​​매우 높으며 주로 다음 문제를 포함하여 많은 문제를 해결해야 합니다. 1) 통일된 데이터 구조, 데이터 매핑, 각 지역의 데이터 수집 및 데이터 마이그레이션; 2) 새로운 시스템 개발 작업 3) 시스템 이전이 이전된 지역의 일상 업무에 미치는 영향 4) 새로운 시스템에 대한 지점 직원 교육 5) 기존 시스템과 새로운 시스템의 원활한 마이그레이션 및 일상적인 호환성 상호 작용 6) 전체 프로덕션 마이그레이션 계획 및 롤백 계획. 나 역시 운이 좋게도 중국은행에서 이 과정을 경험하게 됐다. 전반적인 계획 설계부터 시스템 구현, 후속 시스템 마이그레이션 및 출시까지 거의 4년에 걸쳐 진행됐다. 기본적으로 야근이 일반화됐지만, 그 과정에서 나 역시 많은 것을 배웠고, 급속한 성장의 시기이기도 하다. 전체 전환의 핵심 아키텍처 아이디어는 코어 시스템을 슬림화 및 단순화하여 코어 시스템의 비즈니스 처리 처리량을 향상시키고 최신 메인프레임을 구입하여 처리 성능 및 IO 성능을 보장하고 대부분의 비즈니스 시스템을 줄이는 것입니다. 기본적으로 이러한 전체적인 아키텍처는 당시 평가로 봤을 때 향후 10~20년 내 사업 발전량을 보장할 수 있다. 아래 그림은 당시의 전체 아키텍처 다이어그램이지만, 이 아키텍처 다이어그램에서 우리는 핵심 시스템, 주변 시스템 및 채널 시스템의 전체 아키텍처가 완전히 메시되어 있음을 알 수 있습니다. 완성된 거미줄은 기본적으로 볼 수 없기 때문에 완전히 완성된 것은 아닙니다. 매우 복잡한 거미줄입니다. 일부 시스템은 아웃소싱되기 때문에 시스템의 메시지 구조가 다른 시스템과 다르기 때문에 시스템이 이러한 이상한 시스템과 인터페이스하려고 하면 이러한 이상한 인터페이스의 메시지를 모두 처리해야 합니다. 한 번 하면 작업이 많이 중복됩니다.

대부분의 은행은 이러한 중앙 집중식 메시 아키텍처의 단점을 빠르게 깨달았습니다. 당시 ESB 버스 아키텍처도 인기가 있었기 때문에 은행 시스템은 필연적으로 ESB 버스를 구현했습니다. 버스 아키텍처는 채널 시스템과 코어 및 주변 시스템 사이에 ESB 버스 브리지를 설정합니다. 모든 주변 장치 및 코어 시스템 인터페이스는 ESB 버스에 등록 및 게시되므로 외부 세계에 완벽하게 통합된 인터페이스 표준 프로토콜을 제공합니다. 각 시스템은 동일한 표준 인터페이스 세트에 액세스하므로 서로 다른 메시지 프로토콜을 반복적으로 구현할 필요가 없습니다.

이러한 종류의 아키텍처는 매우 신선해 보이며 채널 시스템과 주변 시스템 모두 다양한 시스템의 인터페이스를 호출하는 것이 더 편리합니다. 이런 종류의 아키텍처는 오랫동안 은행 시스템에서 구현되어 왔으며 대부분의 은행은 여전히 ​​이 아키텍처 모델을 채택하고 있습니다. 비록 지금은 매우 흔해 보이지만 당시에는 이 아키텍처가 완벽했던 것 같습니다. 게다가 이 구조는 지금도 중소은행이 사용하기에 매우 적합하다.

인터넷이 발달하면서 온라인 뱅킹, 모바일 뱅킹, 다이렉트 뱅킹이 새로운 채널로 자리 잡았고 사람들은 이러한 신흥 인터넷 채널을 빠르게 받아들이기 시작했습니다. 이전 아키텍처는 보안 아키텍처이므로 나중에 보안에 관해 두 개의 별도 기사를 작성하겠습니다. 다른 측면의 아키텍처는 기본적으로 변경되지 않았지만, 한 가지 현상은 핵심 시스템에 새로운 주요 기능을 추가하지 않고도 새로운 주변 장치 제품이 지속적으로 추가된다는 것입니다. 당시 중국 은행에는 100개 이상의 주변 시스템이 있었습니다. 곧 오프라인 상태가 될 일부 시스템은 포함되지 않습니다. 비즈니스 볼륨이 계속 증가함에 따라 핵심 시스템의 비즈니스 볼륨도 계속 증가하고 버스에 대한 압력도 점차 증가합니다. 버스 클러스터는 배포 전 100노드로 계속 확장됩니다.

2012년 이후 Facebook과 Amazon 개방형 플랫폼이 큰 성공을 거두면서 BAT는 점차 인터페이스를 개방하고 개방형 플랫폼 생태계 전략을 구현하여 보다 서비스 지향적인 SOA 개발을 추진했습니다. 은행들은 이전에도 서비스 지향 구현 계획을 연구해 왔지만 ESB 버스 아키텍처는 매우 안정적으로 작동하고 문제가 없기 때문에 각 은행이 서비스 지향 전환을 수행하려는 동기가 그다지 강하지 않습니다. 전반적인 아키텍처 관련 부서 및 비즈니스에 미치는 영향은 매우 크며 은행과 같은 상대적으로 안정적인 회사조차도 일반적으로 감히 큰 움직임을 보이지 않습니다. 나는 또한 은행에서 중국 은행의 시범적인 인터넷 금융을 따라잡고 새로 구축된 인터넷 금융 시스템에 대한 서비스 지향 아키텍처를 구현하는 행운을 누렸습니다. 다음은 당시 중국 은행의 인터넷 금융 서비스 아키텍처입니다. 아키텍처는 실제로 전통적인 은행 인터넷 금융의 절충 아키텍처입니다.

아키텍처 다이어그램에서 볼 수 있듯이 왼쪽은 기존 은행의 중앙 집중식 버스 아키텍처이고 오른쪽은 개방형 플랫폼, 서비스 등록 및 검색을 포함하는 인터넷 서비스 지향 아키텍처입니다. , 서비스 지향 제품 시스템. 이러한 설계를 하는 이유는 전통적인 은행의 다양한 상품 시스템이 상대적으로 안정적이고, 은행 시스템에서 일해 본 학생들은 전통적인 은행이 새로운 시스템을 구축하거나 새로운 요구 사항을 구현하는 데 오랜 시간이 걸린다는 것을 모두 알고 있기 때문입니다. Waterfall 개발 방식과 다양한 검토 및 승인 프로세스를 사용하다 보니 요청부터 기능 출시까지 거의 3개월이 지났고 효율성은 여전히 ​​매우 낮습니다. 당시 우리는 새로운 SOA 아키텍처를 시험할 뿐만 아니라 반복적인 개발도 시험하고 있었기 때문에 인터넷 금융 상품은 별도로 구현 일정을 잡고 별도로 배포했습니다. 시스템에는 기존 은행 상품 인터페이스 호출이 포함됩니다. 모든 곳에서는 ESB 버스를 통해 기존 은행 상품 시스템 인터페이스를 호출합니다. 모든 인터넷 금융 상품 시스템은 서비스 등록 센터에 인터페이스가 등록되어 있습니다. 당시 당사의 모든 인터넷 금융 상품 시스템은 ZooKeeper에 인터페이스를 등록한 시스템이었습니다. 모델; 외부 세계에 대한 인터페이스 노출을 제공하는 개방형 플랫폼을 통해 이 아키텍처는 전통적인 은행 시스템의 안정성을 보장할 수 있을 뿐만 아니라 상호 금융 요구의 신속한 반복 구현을 충족할 수 있음을 알 수 있습니다. 개발 비용을 줄이기 위한 인터넷 분산 기술 및 운영 및 유지 관리 비용과 관련하여 제가 아는 많은 은행에서는 현재 이 아키텍처를 사용하여 인터넷 금융 서비스를 구현하고 있습니다.

지난 2년간 컨테이너 기술이 지속적으로 발전하면서 프라이빗 클라우드 플랫폼과 데브옵스(DevOps)가 점차 은행 시스템에 시범 적용되고 있으며, 현재 제가 근무하는 소규모 민간 은행에서는 이 분야의 기술을 시범 운영하고 있습니다. 하단 레이어는 Docker를 채택하여 이미지 관리, 구성 및 릴리스를 수행하며 모두 시스템 수준에서 서비스 지향 아키텍처를 채택하고 있으며 전체 springcloud 솔루션을 사용하고 있습니다.

이러한 종류의 아키텍처는 상대적으로 명확하고 확장성이 뛰어나 향후 비즈니스 개발 요구 사항을 잘 충족할 수 있는 것으로 보입니다. 도커 기술이 계속 발전함에 따라 후속 DevOps는 점차적으로 인터넷 전자 상거래의 대부분을 대체하게 될 것입니다. 제가 근무했던 회사에는 80개 이상의 제품 시스템에 대한 운영 및 유지 관리 인력이 3명뿐이었습니다. 모든 일일 모니터링 및 버전 배포가 자동화되어 기본적으로 수동 개입이 필요하지 않았습니다. 이 모델도 향후 은행에 필요할 개발입니다. 및 유지 관리 방법.

오늘은 은행 시스템의 역사적 변화를 간략하게 소개했을 뿐입니다. 사실 아주 간단한 소개일 뿐입니다. 사실 각 아키텍처에는 많은 이야기가 담겨 있으며, 이에 대해 많이 설명하겠습니다. 나중에 시간이 나면 무슨 일이 있었는지 모두가 볼 수 있도록 자세히 썼습니다 :)