인터넷 금융 아키텍처의 개발 역사는 0에서 수백억까지

회사 설립 후 첫 번째 코드 라인이 타이핑된 지 거의 3년이 지났다는 점을 상기하면, 플랫폼의 기술 아키텍처와 기술 시스템도 4가지 주요 업그레이드와 변형을 거쳤습니다(현재 4세대 아키텍처 시스템이 진행 중). 연말이 다가오면서, 처음에는 거래가 전혀 없는 회사에서 거래량이 100억 개가 넘는 작은 회사의 기술적 변화를 되돌아보는 시간도 갖고 싶습니다.

일반 소개

100억 위안이 넘는 인터넷 금융 산업에서는 실제로는 큰 플랫폼이 아니며, 즉 2급 진영입니다. 실제로 모든 아키텍처 업그레이드에는 큰 비즈니스 발전이 수반됩니다. 이전 세대 시스템 아키텍처를 기반으로 사업 개발 과정에서 우수한 개발 사례가 축적되었으며, 차세대 시스템 개발에서도 아키텍처 업그레이드가 활발히 추진될 예정입니다. 한편으로는 전환을 원활하게 할 수 있고, 다른 한편으로는 회사 자원이 강력한 지원을 제공할 수 있으며, 동시에 기술 파트너는 최첨단 기술을 사용하고 이러한 방식으로 개발 성취감을 가질 수 있습니다. , 우리는 약 9개월에 한 번씩 시스템 아키텍처를 현재 구조로 업그레이드할 수 있습니다.

많은 네티즌들이 종종 귀하의 플랫폼의 TPS는 무엇이며 최대 동시성은 얼마이며 성능은 어떻습니까? 솔직히 말해서 우리는 소규모 회사이며 가장 과장된 것은 수만 명이 입찰을 위해 경쟁하고 있다는 것입니다. 동시에 중형 인터넷으로서 금융 플랫폼이 해야 할 일이 정말 많고, 우리가 고급 플랫폼이 아니라는 점을 명확하게 설명할 수 있는 것 이상입니다. , 그리고 우리가 사용하는 기술도 현재 상대적으로 주류인 오픈 소스 제품이지만 회사가 지속적으로 개발하는 과정에서 많은 문제에 직면했으며 더 많은 주류 오픈 소스 솔루션을 사용하려고 최선을 다했습니다. 플랫폼 개발에 따른 기술 업그레이드의 변화를 여러분과 공유하고 싶습니다.

우리는 네 가지 주요 아키텍처 변경을 수행했으며 각 세대의 아키텍처는 한 문장으로 요약됩니다.

• 1세대 아키텍처의 특징: 비즈니스가 상대적으로 집중되어 있고 기능이 투자 및 재무 관리 요구 사항을 충족하며 빠르게 출시될 수 있습니다.

• 2세대 아키텍처의 특징은 분산 시스템 전환, 플랫폼화가 구체화되기 시작, 다양한 수직적 비즈니스 시스템이 구축 및 출시되고, 제품 측면에서 사용자 투자가 크게 풍부해지고, 빅데이터 플랫폼 연구 및 사용이 가능하다는 것입니다.

• SOA 거버넌스의 특징, 등록 센터로 사육사를 사용하고 모니터링 및 파견 센터로 dubbo를 사용하여 단일 로그인을 달성하고 shiro를 사용하여 권한 제어를 수행합니다.

• 4세대 아키텍처의 특징: 4세대 아키텍처에 대한 기술 지원으로 springboot+springcloud 기술을 사용하여 마이크로서비스 개발 모델을 완벽하게 활성화합니다.

자세한 소개는 아래에

1세대 시스템 아키텍처

2014년은 인터넷 금융의 원년이라고 봐야 할 것 같습니다. 사실 이전에도 다양한 모델을 사용하는 인터넷 회사들이 많았고, 그 동안 미온적이었습니다. 그러나 2014년에는 갑자기 인기를 얻었습니다. 이런 종류의 제3자 웹사이트 트래픽이 갑자기 증가했고, 이후 언론 보도가 계속되면서 XXX달러의 투자를 받은 여러 인터넷 금융 회사에 대한 보도가 점점 많아졌고, 정책이 점차 명확해지면서 많은 사람들이 그렇게 되었습니다. 우리를 포함한 대기업(그룹))도 이러한 열풍을 이용해 후속 조치를 취했습니다.

1세대 시스템의 주요 목적은 시간을 확보하는 것이었고, 회사는 그 시점에 이미 모바일 물결이 시작되었기 때문에 시스템이 가능한 한 짧은 시간 내에 온라인 상태가 되도록 보장하기를 원했기 때문에 출시를 우선적으로 결정했습니다. 모바일 버전이며, 홈페이지는 당분간 고려하지 못했습니다. 당시 회사는 PHP와 Java라는 두 가지 개발 언어에 대한 기술 보유고를 갖고 있었습니다. PHP는 빠른 개발에 큰 이점이 있었기 때문에 프론트엔드 PHP + 백엔드 Java 모델을 채택하기로 결정했습니다. 시스템은 세 가지 계층으로 나뉩니다. 사용자 계층: Android 및 IOS 모바일 터미널 인터페이스 계층: PHP는 사용자 및 트랜잭션 인터페이스를 제공합니다. 백엔드는 백그라운드 시스템과 타이밍 시스템이라는 두 부분으로 구성됩니다. 백엔드는 PHP 개발과 인터페이스 레이어를 사용하여 하나의 시스템을 공유하고, 다른 하나는 타이밍 시스템으로 이자 계산, 배당금 분배, 만기 및 기타 예정된 작업을 담당하며 Java를 사용하여 개발되었습니다.

기본 서비스 및 미들웨어의 경우 mysql은 가장 기본적인 마스터-슬레이브 지원을 제공합니다. 1세대 시스템은 mysql의 기본 데이터베이스만 사용하고, 슬레이브 데이터베이스는 동기 백업에만 사용되며 사용자의 동시성 문제를 처리합니다. ;ActiveMQ는 2차 시장 이체 매칭 및 기타 비동기 메시지 알림을 사용하는 데 사용됩니다. 프로젝트 배포: PHP는 apache를 사용하여 배포되고, 타이밍 서비스는 tomcat6을 애플리케이션 서버로 사용하며, lvs는 프런트 엔드 apache 로드로 사용됩니다. 기본적으로 이러한 기술은 1세대 아키텍처 다이어그램입니다. 체계.

1세대 시스템 출시 이후 홈페이지 구축과 H5(모바일 브라우저 또는 위챗) 시스템 구축이 특히 두드러졌다. 인터넷 금융회사로서는 공식 홈페이지가 없는 것을 참을 수 없어 홈페이지와 H5 개발에 나섰다. 이 기간 동안 PHP가 이전에 수행했던 백엔드를 제거하고 Java를 사용하여 다시 계획했습니다. 지금까지 PHP는 공유되는 핵심 트랜잭션인 웹사이트, APP 인터페이스의 세 가지 시스템을 담당합니다. 세 시스템에서 Java는 관리 및 타이밍 서비스를 담당하며 일반적으로 이 아키텍처를 1.1세대 아키텍처라고 부릅니다.

1.1세대 시스템 아키텍처 다이어그램, 녹색 부분이 변경된 부분

1세대 시스템의 단점은 사업이 너무 집중되어 있고, 서둘러 출시되며, 후기에는 문제가 많다는 점이다.

2세대 시스템 아키텍처

2세대 제도의 배경은 기업의 사업 규모가 급속히 발전하면서 초기에 빚진 많은 기술 부채가 폭증했고, 온라인상에서도 많은 문제가 등장했다는 점이다. 가장 심각한 것은 개인에게 반복되는 배당금 지급이었다. 유저들에게 여러가지로 혼났던 기억이 지금도 생생합니다. 한편, 다양한 사업 부서에서는 끊임없는 수요가 있고 회사의 제품에 대한 수요가 끊임없이 있기 때문에 현 단계에서는 다양한 생산 문제를 해결하는 동시에 수직적 비즈니스 시스템을 개발하는 데 분주합니다. 그 동안 거의 미칠 지경이었는데, 1세대 시스템은 폐쇄적으로 개발이 되었는데, 돌아와서도 회복하기 힘들었지만, 다시 시장에 내놓으니 정말 고통스럽고 기뻤습니다.

처음으로 온라인에 진출한 수직적 하위 시스템은 계약 시스템이었습니다. 당시에는 사용자가 입찰을 제출한 후 계약이 이루어지지 않아 많은 사용자가 우려를 표했습니다. 나중에 계약 시스템만 세 가지 버전으로 변경되었습니다. 첫 번째 버전은 PDF만 생성했고, 두 번째 단계는 전자 서명을 사용하여 온라인으로 진행했으며, 세 번째 단계에서는 워터마크를 추가하고, 맞춤화되고 동적으로 생성된 PDF를 개발했습니다. 사용자 초대, 투자 및 기타 생산 포인트를 현금 쿠폰 등으로 교환할 수 있습니다. 메시지 시스템 추출: 사이트 메시지, 문자 메시지, 이메일 등 온라인 모니터링 시스템, 비즈니스 모니터링 및 서비스 모니터링을 시작합니다. 장애조기경보, 각 사업부서 지속적으로 수요 증가 및 온라인화 금융 시스템: 재무 담당자가 금액을 계산하고, 위험 관리 시스템: 판매를 위한 판매 시스템을 개발하고 인터페이스하기 때문에 외부 액세스 시스템을 개발합니다. 많은 타사 시스템을 사용합니다.

1세대 시스템은 급하게 구축되었고, 제품 인터페이스도 형편없었고, 바로 웹사이트 2.0, APP2.0, H52.0 기획에 착수했습니다. 프론트엔드 시스템의 요구에 부응하여 CMS를 개발하게 되었습니다. 프로젝트 및 회사 공지사항, 뉴스 등을 게시하기 위한 백엔드 시스템; 2세대 제품 측면에서는 일반적으로 많은 빅데이터 분석 요구 사항이 완료되면 공식 웹사이트에 표시됩니다. 데이터 분석 프런트 엔드에서는 지도를 사용하여 표시하고 개인에 대한 상환도 있을 예정입니다. 캘린더, 수집된 데이터 분석 등은 전량의 데이터를 실행해야 하기 때문에 오프라인으로 처리되도록 설계되었습니다. 계획하는 동안 데이터는 mysql 슬레이브 라이브러리에서 mongodb 클러스터로 동기화되며, 대량의 데이터를 처리하기 위해 mongdo의 mapreduce 기술이 사용됩니다.

Mysql은 실시간으로 mongodb와 동기화되며, mysql 서버 측에서 모니터링 에이전트를 시작하여 동시에 mysql의 binlog 로그를 모니터링합니다. mongodb 서버 측에서도 서비스가 시작됩니다. 클라이언트 측에서는 에이전트가 데이터 변경 사항을 모니터링하고 이를 서버로 보냅니다. 서버는 이를 구문 분석하여 mongodb 클러스터에 삽입하여 실시간 동기화를 달성합니다. 위의 그림은 원래 소개하기 위해 글을 썼습니다: 빅데이터 실습-데이터 동기화 기사 tungsten-relicator (mysql->mongo) 사실 이 도구는 사용하는데 특별히 안정적이지는 않습니다. 처음에는 선택지가 많지 않았는데, 점차 익숙해지고 나서는 안정됐어요. 우리는 데이터 정리 시스템을 개발하기 위해 대담하게 golang을 사용했습니다. 당시 사용했던 golang 버전은 1.3이었지만 지금은 1.8입니다. 다행히도 golang 언어 자체는 이전에 접해본 적이 없었습니다. 매우 간단하고 효율적입니다. 비록 N을 밟았지만 많은 어려움이 있었지만 결국 제 시간에 맞춰 프로덕션에 투입했고 나중에 golang을 사용하여 beego 프레임워크를 기반으로 한 백엔드를 개발했습니다. 빅데이터 분석 시스템은 이후 다른 세대로 업그레이드되었으며, 각 프런트엔드 비즈니스 시스템에서 UI 사용자 계층은 사용자 데이터를 수집하기 위해 많은 노력을 기울였으며 이를 activeMQ 전송을 통해 수신하고 최종적으로 mongodb에 저장했습니다. 정리된 결과는 프런트엔드 비즈니스 시스템에서 사용할 수 있도록 결과 데이터베이스에 저장되었으며, 나중에 beego+echart를 사용하여 새로운 버전의 데이터 분석 시스템이 구축되었습니다.

빅데이터 시스템의 아키텍처 다이어그램

백엔드 데이터베이스에 대한 압력이 계속 증가함에 따라 백엔드 관리 시스템과 비즈니스 시스템이 마스터와 슬레이브로 분리되었습니다. 백엔드 관리 시스템은 캐시를 추가하고 독립적인 이미지 서버를 위한 Redis를 시작했습니다. nginx를 사용하여 구축되었으며, 이 과정에서 온라인에서 수많은 활동이 시작되면서 회사가 가장 빠르게 성장하는 단계이기도 했습니다.

2세대 시스템 아키텍처 다이어그램:

잠시 요약하자면:
2세대 아키텍처는 다양한 비즈니스 시스템을 출시하고 마스터와 슬레이브를 분리하고 빅데이터 플랫폼을 구축해 향후 더 많은 데이터 처리를 위한 기술적 기반을 제공합니다
단점: 각 비즈니스 시스템이 분할된 후 각 프로젝트 간의 호출이 복잡하고, 백엔드 시스템이 많고, 각 시스템 간에 별도의 계정 시스템이 있어 플랫폼 운영 모니터링을 완료하려면 운영을 전환해야 합니다.

3세대 시스템 아키텍처

2세대 시스템 개발이 완료된 후, 우리에게는 세 가지 어려운 문제가 남았습니다. 첫 번째는 3세대 시스템 초기에 비즈니스 시스템이 계속 증가함에 따라 시스템 간의 호출 관계가 기하급수적으로 증가했다는 것입니다. 우리가 개발한 많은 기본 구성 요소가 추가되어 이 문제가 더욱 악화되었습니다. 두 번째 문제는 첫 번째 문제를 보완하며, 하위 시스템 중 하나를 이동하는 경우 구성 파일을 수정해야 할 수도 있습니다. 관련 시스템을 업데이트하고 서비스를 다시 시작합니다. 종종 한 시스템을 업데이트하기 때문에 다른 시스템도 수동적으로 업데이트해야 하므로 문제가 발생할 때 프로덕션에 투입하고 전환하는 것이 복잡해집니다. 세 번째 문제는 우리가 많은 백-시스템을 개발했다는 ​​것입니다. 그러나 계정은 통합되어 있지 않습니다. 각 하위 시스템에는 자체 계정 센터가 있으며, 비즈니스 직원은 일상 업무를 완료하기 위해 로그인을 반복해야 하며 이 문제는 점점 더 두드러지고 있습니다.

그래서 연구와 시스템 선정 등을 시작했습니다. 가장 먼저 해결해야 할 문제는 SOA 서비스 거버넌스를 도입하고 서비스 등록 및 검색을 통해 시스템 간 디커플링을 해결하는 것이었습니다. 당시에 많이 조사했고 결국 A 외에 다른 이유 없이 더보를 선택했습니다. 많은 사람들이 기본적인 물을 사용하여 물 속을 걸었습니다. 두 번째 문제를 해결하기 위해 Configuration Center를 도입했는데, 당시 360의 Qihoo360/QConf, Spring의 spring-cloud-config, Taobao의 Diamond, Baidu의 disconf 등을 조사하다가 결국 disconf를 선택하게 되었습니다. 이는 spring cloud에 딱 맞는 것이었습니다. 그러나 여기서 우리는 spring-cloud와 Spring-boot가 4세대 아키텍처 선택의 토대를 마련했다는 것을 알게 되었습니다. 실제로 disconf는 4세대에서만 사용되었습니다. 세 번째 문제는 싱글 사인온(Single Sign-On)을 구현하는 cas, 권한 제어를 위한 shiro, 로그인 후 권한 목록과 같은 서버 인터페이스를 제공하는 dubbo를 사용하는 계정 센터에 의해 해결됩니다.

변환 후 아키텍처 다이어그램

이를 기반으로 우리는 많은 기본 구성 요소를 추출했습니다. coomn 구성 요소는 문자 클래스, 날짜 클래스, 암호화 클래스 등을 포함한 일반적인 기본 클래스를 처리하고 파일 시스템을 처리하기 위한 fastDFS 클러스터를 구축했으며 Redis 클러스터를 구축했습니다. 예약된 작업을 모두 예약 시스템에 통합하여 예약된 예약 시스템을 독립적으로 개발했습니다. 예약된 작업이 필요한 시스템은 자동으로 페이지에 예약 전략을 추가할 수 있으며, PHP는 시스템 변환, 마스터-슬레이브 분리, 정적 최적화 등을 수행했습니다.

이후 회사는 크라우드 펀딩 플랫폼 구축을 시작했습니다. 이번에 시스템은 완전히 Java 언어로 개발되었으며 앱 측은 모든 1차 레벨 페이지가 기본적으로 개발되었으며 2차 레벨은 모두 하이브리드 개발 모델을 채택했습니다. 페이지는 H5+vue였습니다. 이 모델에서는 모든 백엔드가 서비스에 dubbo를 사용합니다.

그림에는 시스템의 일부만 나열되어 있으며 대신 다른 서비스가 사용됩니다.

3세대 시스템은 SOA 서비스 거버넌스를 시작하고 통합 계정 센터와 기본 구성 요소를 도입했습니다. 단점은 개발 환경이 더 복잡하다는 것입니다.

4세대 시스템 아키텍처

사람들은 항상 불만족스럽고 기술은 항상 최고의 아키텍처 시스템을 사용하기를 희망합니다. 3세대 시스템 아키텍처를 개발하면서 저는 스프링 클라우드와 스프링 부트에 대해 계속 배우면서 점점 더 많은 편리함을 알게 되었습니다. 스프링 부트.스프링 클라우드 시스템은 대규모 시스템에서 고려해야 할 모든 측면을 완벽하게 충족한다는 장점이 있습니다. 한편, 국가에서는 P2P 회사에 은행 예금을 엄격하게 요구하기 시작했습니다. 은행의 관련 인터페이스를 분석한 결과, 규칙을 엄격하게 준수하려면 동시에 시스템에 대대적인 변화가 필요하다는 사실을 발견했습니다. 규제 요구 사항을 충족하기 위해 회사는 Baitiao 관련 제품도 개발했으며 이는 또한 큰 프로젝트입니다. 위의 두 가지 배경을 활용하여 우리는 은행 예금 및 Baitiao 프로젝트를 진행하면서 마이크로서비스를 완전히 수용하기로 결정했습니다.

Dubbo를 포기하고 Spring Cloud를 전면 도입하는 이유는 세 가지입니다. 1. Dubbo는 수년 동안 업데이트되지 않았으며 Spring Cloud는 지속적으로 업데이트 및 업그레이드되고 있습니다. 2. Dubbo는 주로 서비스 관리 및 모니터링을 수행하며 Spring은 다음과 같습니다. 클라우드는 거의 모든 마이크로서비스를 고려합니다. 통합 구성 센터, 라우팅 센터 등 모든 측면이 필요합니다. 3. Spring 클라우드는 방해가 되지 않으며 다른 Spring 프로젝트와 완벽하게 통합되어 개발 효율성을 높입니다.

이제 변환을 위해 스프링 부트 + 스프링 클라우드를 선택했으므로 마이크로서비스 기술 선택이 결정되었습니다. 그렇다면 어떻게 변환을 시작해야 할까요? 결국 차세대 시스템 변환이 원래 비즈니스에 영향을 주어서는 안 됩니다. 가장 중요한 것은 원래 시스템은 분산 개발 모델에 따라 개발되었음에도 불구하고 기존 시스템으로 인해 일부 시스템이 여전히 데이터베이스를 공유하고 있다는 점입니다. 시스템은 하위 시스템 데이터를 수정하거나 쿼리해야 하며, 이는 서비스 간 인터페이스 호출을 통해 얻어야 합니다. 따라서 새로 개발된 프로젝트와 변환이 필요한 프로젝트부터 springcloud 프로젝트를 시작할 계획이며, 다른 시스템은 일시적으로 라우터 모드를 통해 통신할 예정입니다.

아키텍처의 길에는 끝이 없습니다. 변화는 영원하며 아키텍처의 업그레이드는 비즈니스를 더 잘 지원하는 것입니다.