오토홈 전자상거래 시스템 아키텍처 진화 및 플랫폼 아키텍처 실습-일체 포함-php.cn

★ 목차★

01	서문
02	건축 진화 2.1 초기 단계 2.2 마이크로서비스 단계 2.3 마스터 데이터 단계 2.4 플랫폼 아키텍처 단계
03	플랫폼 아키텍처 실습 3.1 비즈니스 아이덴티티 3.2 서비스 오케스트레이션 3.3 비즈니스 구성 3.4 개발 도구 3.5 데이터 시각화 3. 6 지식 축적
에필로그	4.1 새로운 소매점 탐색 4.2 아키텍처 업그레이드 머리말 오토홈 전자상거래 시스템은 2014년 탄생하여 2016년부터 2019년까지 성장했습니다. 수년 동안 Double 11 및 818 파티의 피크 테스트를 경험했으며 안정적이고 신뢰할 수 있으며 우수한 온라인 거래 기능을 축적했습니다. . 비즈니스 중간 플랫폼 구축 열풍에 맞춰 2019년 중간 플랫폼 구축 단계에 돌입해 자동차 전자상거래 분야에서 5년간 축적한 역량을 수출해 자동차 전자상거래 산업 발전에 도움을 주고 있다. , 기업의 디지털 혁신을 가속화합니다! Architecture Evolution 이 부분에서는 주로 오토홈 전자상거래 시스템의 아키텍처 개발 과정과 각 단계에서의 기술 시스템의 사업 현황, 기술적 과제 및 대응 전략에 대해 이야기합니다. 초기 인터넷 환경은 2011년부터 2013년까지 수만개 집단전쟁과 전자상거래 전쟁‍[1]을 겪은 후 전자상거래 사업이 수익화 사업으로 변모했습니다. 광고를 제외한 인터넷 트래픽의 또 다른 전략적 우위. 2013년 '더블 일레븐' 기간 동안 오토홈은 자동차 구매 서비스를 시작했으며 거래 링크를 중요한 발전 방향으로 여겼습니다[2]. 사업 초기 단계에서는 제품의 타당성을 검증하기 위해 빠르게 반복하고 온라인에 접속하는 것이 기술적 요구 사항입니다. 일상적인 비즈니스 요구를 충족하는 동시에 기술 아키텍처에 대한 생각은 멈추지 않았습니다. 미래 전자상거래 시스템의 확장성을 고려하고 업계 내 Alibaba의 기술 시스템을 참조하여 2014년부터 기술 스택 개발을 시작하여 점차적으로 .NET 시스템에서 Java 시스템으로 변경하고 모든 애플리케이션 전환을 완료했습니다. 2015년 5월 30일. 완전한 온라인 자동차 쇼핑 플랫폼 Car Mall 을 출시했습니다. 마이크로서비스 단계 전자상거래 사업의 급속한 발전에 따라 기술인력도 2016년 기준 수백명으로 늘어났습니다. 모놀리식 아키텍처의 어려움은 요구 사항이 충족될 때 거의 30개의 Maven 하위 프로젝트가 병렬로 개발되고 요구 사항이 온라인 상태가 될 때까지 기다립니다. 온라인 개발이 자주 발생하면서 SQL 등의 문제로 인해 전체 시스템의 개발 효율성과 시스템 안정성이 저하되었습니다. 현재 시스템 지원은 큰 도전에 직면해 있으며 시스템 아키텍처를 업그레이드하고 발전시켜야 합니다. 우리는 원래의 단일 시스템을 응집력이 높고 결합도가 낮은 여러 중앙 집중식 시스템으로 분할하는 분산 전략을 개발하기 시작했습니다. 즉, 현재의 사용자센터, 상품센터, 주문센터, 프로모션센터, 쿠폰센터, 머천트센터 각각의 독립된 시스템을 독립적으로 설계하고, 독립적으로 수신, 독립적으로 출시할 수 있어 전체적인 R&D 효율성과 시스템 안정성이 향상되었습니다. 단계. 이 단계에서 우리는 자동차 전자상거래를 지원하기 위한 백만급 제품 시스템[3], 주문 시스템[4], 쿠폰 시스템[5]의 구축을 기술적으로 완료했으며 모든 애플리케이션의 클라우드 마이그레이션을 완료했습니다. 6] 및 자동화 테스트 플랫폼 구축[7]. 동시에 자율주행차 전자상거래 모델, 오픈 플랫폼 모델, B2B2C 모델, 견적 모델, 컨설팅 모델, TPCC 모델, 수입차 병행판매 등 다양한 비즈니스 모델을 탐구해왔습니다. 마스터 데이터 단계 전자상거래 발전 속도가 정말 빠릅니다. 2019년까지 회사는 이미 여행, 자동차 제품 및 애프터마켓 서비스, 포인트 상환 등 다양한 온라인 거래 모델을 보유하고 있습니다. . 회사는 개발 전략에 따라 전자상거래 중간 플랫폼을 구축하기로 결정했으며, 한편으로는 회사의 고품질 제품 자원과 운영 자원을 집중하여 영향력 있는 수직 전자상거래 플랫폼을 만들기로 결정했습니다. 다른 한편으로는 기술자원을 합리적으로 관리 및 통제하여 통일된 전자상거래 시스템을 구현하는 것이기도 합니다. 이러한 배경에서 우리 팀은 전자상거래 중간 플랫폼을 구축하는 작업을 맡았는데, 각 시스템의 비즈니스 형태와 기술 아키텍처가 매우 다르기 때문에 우리가 직면한 첫 번째 문제는 클래스 시스템을 통합하는 방법이었습니다. 이를 위해 우리는 한편으로는 다양한 비즈니스 시나리오에서 거래 시스템의 현재 상태를 익히기 시작했으며, 다른 한편으로는 기술적인 솔루션도 생각하고 논의하고 있습니다. 결국 우리는 "데이터 정규화를 기반으로 표준화된 중간급 서비스를 제공하고, 아래에서 위로 시스템별로 시스템을 통합하는" 솔루션을 선택했습니다. 데이터 정규화 데이터는 회사의 핵심 자산이며, 특히 거래 시스템에서는 데이터가 최우선입니다. 마스터 데이터의 구축은 데이터 모델을 통합하고 시스템 장벽을 무너뜨릴 수 있는 한편, 중앙 집중화된 데이터를 통해 운영 데이터 분석을 수행하고 비즈니스 의사결정의 기초를 제공할 수도 있습니다. 시스템 통합의 첫 번째 단계로 마스터 데이터를 관리합니다. 거래 과정에서 가장 중요한 데이터는 가맹점, 상품, 주문, 판촉활동 등 4개 분야에 집중되어 있습니다. 회사의 거래 시나리오 현황을 토대로 이 4개 분야의 마스터 데이터를 추상화하여 모델링합니다. 가능한 한 통일된 방식으로 대부분의 거래 시나리오에 적합합니다. 다음은 주문 마스터 데이터의 핵심 데이터 모델 구조에 대한 개략도입니다. 통합 데이터 모델을 완성한 후 다음 단계는 기존 이기종 데이터를 기본 데이터베이스로 가져오는 것입니다. binlog 초기 데이터 동기화 가져오기는 데이터 처리(mysql, sqlserver)를 통해 완료되며 이는 비즈니스에 가장 빠르고 방해가 적은 솔루션이기도 합니다. API 표준화 마스터 데이터 구축이 완료되면 다음 단계는 마스터 데이터를 기반으로 API 표준화 구축을 시작하는 것입니다. 고품질 API는 시스템을 연결하는 신경이라고 할 수 있습니다. API는 또한 어느 정도 시스템의 폐쇄성을 실현합니다. 이를 위해 우리는 단일 책임 원칙을 따르고, 도메인별로 구분하고, 경계를 명확하게 하고, 모든 기본 API 기능을 원자화하여 업스트림 사용자가 API를 유연하게 조합하여 비즈니스 로직을 완성할 수 있도록 합니다. 동시에 매개변수 구조를 통합합니다. API 및 응답 결과 구조 통합 오류 코드, API 게이트웨이 기반 통합 게시 및 호출, API 데이터 통계 모니터링, 성능 저하 및 전류 제한을 통해 통합 관리 및 제어가 가능합니다. API 읽기 및 쓰기 전환 표준화된 API로 비즈니스 당사자가 API의 가치를 반영하여 사용하는 것이 당연하며, 그 단계가 너무 큰 단계를 거치지 않도록 하기 위해 사용합니다. 읽기와 쓰기의 단계적 해결은 사업별로 사업을 호출하고 전환하는 것을 포함하며, 이는 매우 합리적인 조치인 것처럼 보이지만 실제 실행과정에서 많은 문제점을 노출시킨다. 1) 시나리오에서 읽기와 쓰기가 크게 종속되는 경우, 예를 들어 사용자는 주문 후 즉시 주문 내용을 보려면 주문 세부정보로 이동합니다. 이때 쓰기 API 전환이 완료되지 않으면 읽기 API를 통해 데이터를 읽습니다. 데이터 동기화 지연으로 인해 실패합니다. 이때 읽기와 쓰기를 동시에 단계적으로 전환할 수 있는 방법은 없습니다. 2) 비즈니스 전환에 미치는 영향이 가장 적은 방법은 물론 원래 인터페이스의 매개변수 및 반환 결과와 호환됩니다. 표준 API에 따라 비즈니스 측을 강제로 전환하면 필연적으로 전환 비용이 발생하고 불필요한 부정적인 효과가 발생합니다. 사업쪽에. 이때 우리는 자연스럽게 상대방의 관점에서 어느 정도 트레이드오프(trade-off)를 해야 합니다. 우리가 채택한 방법은 기존 프로토콜과 새 프로토콜의 변환을 위해 표준 API 위에 적응 레이어를 추가하여 비즈니스 당사자가 도메인 이름과 요청 URL만 전환하면 되고 다른 로직은 변경되지 않고 최대화되는 것입니다. 비즈니스 측면에 우호적입니다. 3) 우리가 제공하는 기본 API는 모두 원자적이므로 실제 시나리오, 특히 프런트엔드와 백엔드가 분리된 프로젝트에서 프런트엔드는 동일한 결과를 얻기 위해 인터페이스를 여러 번 호출할 의향이 없습니다. , 우리는 또한 백엔드에 Facade 레이어가 추가되어 기본 Atomic API를 기반으로 비즈니스 시나리오에 맞는 API를 외부에 제공하며 차별화된 인터페이스 로직과 적당히 호환됩니다. 4) 읽기 및 쓰기 전환은 하룻밤 사이에 이루어질 수 없습니다. 이 과정에서 기본 데이터 API와 원래 비즈니스 API가 공존하는 시나리오가 불가피하게 발생합니다. 모든 API 입구는 당사에서 제공하므로 다음을 통해 라우팅 메커니즘도 채택합니다. 라우팅 계층 다양한 위치가 전달되며 모든 API는 호출자에게 투명합니다. 5) 실제 API 전환 과정에서는 결국 시스템을 통합해야 하는 특수한 시나리오가 있는데, 나중에 통합될 기능에 대해 강제로 API 전환을 하는 것은 사실상 자원 낭비이기 때문에 예정보다 앞선다. .사전 판단을 한 후, 전체 기능을 전환하기 전에 전환을 적당히 피하고 기능이 통합될 때까지 기다릴 수 있습니다. 시스템 기능 통합 API 읽기 및 쓰기 전환이 완료된 후 마스터 데이터를 기반으로 한 기능은 기본적으로 집계가 완료되었습니다. 이때 통합 가맹점 관리 등 일반적인 기능을 체계적으로 통합해야 합니다. 백엔드, 통합 운영 백엔드, 통합 C-end 거래 경험 등 시스템 수준의 통합 통합의 목적은 사용자에게 통일된 운영 인터페이스를 제공하고 플랫폼의 전문성을 반영하는 것입니다. 시스템 통합 과정에서 우리는 "공통성의 촉진과 차이점의 절충" 원칙을 채택했습니다. 제품 출시, 주문 목록 및 기타 기능과 같은 공통 기능에 대해 공통 기능을 추상화하고 통일된 단위화된 서비스를 제공합니다. 운영 인터페이스는 다양한 비즈니스 당사자의 사용 요구 사항을 충족합니다. 비즈니스 측에 고유한 기능에 대해서는 비즈니스 측에서 구현하도록 권장합니다. 아직은 일반 기능을 형성할 수 없지만 향후 일반 기능이 될 수 있는 기능에 대해서는 MVP 원칙을 따르며 가장 빠른 방법을 사용합니다. 온라인으로 작은 버전을 구현합니다. 비즈니스가 반복됨에 따라 기능 침전이 지속적으로 실현됩니다. 전체 시스템 통합 과정에서 원래 시스템 기능을 통합하는 동안 새로운 요구 사항이 필연적으로 발생하게 됩니다. 이러한 시나리오에 직면했을 때 우리의 접근 방식은 새로운 시스템과 기존 시스템을 동시에 개발하는 것인데, 이는 실제로 새로운 시스템의 통합으로 인해 비용이 증가하는 것으로 보입니다. 한편으로는 기술 통합으로 인해 비즈니스 발전에 영향을 미치지 않으며 비즈니스 정체를 초래하지 않습니다. 반면에 기존 시스템과 새 시스템을 비교하면 새로운 시스템에서 발생할 수 있는 문제를 찾을 수 있습니다. 이는 새로운 통합 시스템의 기능을 검증하는 가장 좋은 방법이기도 합니다. 대부분의 시스템 통합 작업을 완료한 후 핵심 전자상거래 거래 링크가 운영되었으며 판매자 입력, 제품 출시, 제품 표시, 주문 배치, 지불, 계약 이행, 판매 후까지 장기적인 온라인 검증을 거쳤습니다. 최종 해결까지 그 과정에서 발생한 문제도 하나씩 해결해 나가고 있습니다. 이 단계에서 우리는 회사의 3대 거래 시스템 통합을 완료하고 전자상거래 플랫폼[8]의 플래시 세일 시스템 아키텍처 업그레이드와 818을 지원하기 위한 쿠폰 시스템 구조 업그레이드를 수행했습니다. 2020~2021년 파티 및 더블11, 더블12 등 플래시 세일, 쿠폰 발행 시나리오 등 대규모 이벤트. 또한 우리는 도메인 중심 모델 DDD의 이론과 업계 실무를 적극적으로 탐구하고 있으며 이를 송장 데이터베이스 시스템 재구성에 구현했으며[9], 후속 플랫폼 아키텍처 업그레이드에 대한 기술 지원도 제공합니다. 플랫폼 아키텍처 단계 전자상거래 비즈니스 센터가 비즈니스에 지속적으로 "접근"함에 따라 시스템의 추상화 및 구축 난이도도 기하급수적으로 증가했으며 일련의 새로운 문제가 나타났습니다. 1) 건설 중간 플랫폼 프로젝트 종료 및 인력 대피로 인해 전자상거래 비즈니스 중간 플랫폼은 수많은 사업 분야의 로직을 통합했으며 코드는 수많은 조건부 판단으로 가득 차 있다. 각 수요 반복의 테스트 회귀 비용이 매우 높습니다. 서로 다른 비즈니스 간의 논리를 분리하고 비즈니스 간의 결합을 줄이는 방법은 무엇입니까? 2) 구축의 중복을 피하기 위해 전자상거래 비즈니스 플랫폼에 연결된 여러 비즈니스 라인의 공통 기능을 어떻게 추상화할 수 있습니까? 3) 새로운 비즈니스가 전자상거래 비즈니스 센터에 연결될 때, 신속한 비즈니스 반복과 혁신을 지원하기 위해 기존 역량과 솔루션을 기반으로 어떻게 신속하게 구성하고 출시할 수 있습니까? 4) 제품 운영에서 일상 업무의 효율성을 향상시키기 위해 기술적 수단을 어떻게 사용할 수 있습니까? 요약하자면, 비즈니스 중간 플랫폼 구축 과정에서 비즈니스 라인의 공통 기능과 전자상거래 비즈니스 중간 플랫폼의 공통 기능의 재사용 가능한 설계 및 구현을 추상화하는 것이 특히 중요합니다. 중간 플랫폼을 만들기 위해 건설은 기업의 개발 과정에서 비용을 절감하고 효율성을 높이는 역할을 합니다. 시스템 아키텍처를 업그레이드해야 하며, 이는 플랫폼 아키텍처 단계로 이어집니다. 플랫폼 아키텍처 실습 플랫폼 아키텍처란? 기본 기능과 각 사업체의 특징적인 서비스를 분리하고, 서비스 간 로직을 분리하는 것이 필요합니다. 플랫폼화의 핵심은 비즈니스 추상 모델링과 시스템 아키텍처의 개방성입니다. 비즈니스 추상화는 일반적인 문제의 80%를 해결하고, 시스템 아키텍처의 개방성은 개인화된 문제의 20%를 해결합니다. ThoughtWorks[10]에서 제공한 "현대 엔터프라이즈 아키텍처 백서" 솔루션과 업계 인터넷 기업의 중간급 솔루션인 Meituan[11] 및 Youzan[12] 을 참조한 후 적합한 집을 제시했습니다. 전자상거래 플랫폼을 위한 어플라이언스 솔루션: 도메인 기반 모델링을 사용하여 전자상거래 비즈니스에서 여러 비즈니스 라인의 공통 기능을 추상화하고 확장 지점을 예약한 다음 서비스 조정을 사용하여 공통 기능을 결합합니다. 원리는 그림과 같다. 전자상거래 사업에서 운영되는 각 사업은 비즈니스 아이덴티티 + 비즈니스 프로세스 + 규칙으로 이해될 수 있다. 비즈니스 프로세스는 프로세스 서비스 오케스트레이션을 통해 구현되고, 확장점은 확장을 통해 구현된다. 포인트 메커니즘. 전체 거래 프로세스에서 B측의 가맹점 입력 및 제품 출시는 상대적으로 일반적입니다. 각 비즈니스의 주요 프로세스 차이는 주문 수집 전과 결제 후의 주문 이행에 반영되는 경우가 많습니다. 이러한 이유로 전체 솔루션의 핵심은 주문 플랫폼 아키텍처 설계에 있습니다. 그림과 같이 전체 주문 플랫폼 아키텍처는 아래에서 위로 4개의 레이어로 나뉩니다. 인프라 레이어: 스토리지, 메시징, RPC 등의 미들웨어를 제공합니다. 기본 서비스 레이어: 도메인별로 구성된 기본 서비스, 도메인 서비스는 다양한 비즈니스의 차이점에 대한 확장 지점을 제공합니다. 비즈니스 기능 레이어: 다양한 도메인 서비스를 연결하여 주문, 결제 등 외부에서 사용할 수 있는 비즈니스 기능을 형성합니다. 비즈니스 프로세스 계층: 비즈니스 기능을 정리하고 주문 거래 프로세스를 구성하며 주문 거래 프로세스를 완료합니다. 비즈니스 계층: 다양한 비즈니스 차이를 달성하기 위해 비즈니스 정체성, 확장 지점 구현 및 비즈니스 프로세스 구성을 개발합니다. 전체 주문 플랫폼 아키텍처 업그레이드 실습 프로세스는 다음과 같이 요약할 수 있습니다. 비즈니스 식별 비즈니스 플랫폼이 다양한 비즈니스에 동시에 서비스를 제공할 때 비즈니스 식별 개념은 Alibaba에서 처음 제안되었습니다. 차별화되고 개인화된 서비스를 제공하기 위해서는 각 비즈니스 서비스 요청의 비즈니스 아이덴티티 요소를 구별할 수 있어야 하며, 따라서 기업의 각 비즈니스에 대한 아이덴티티와 특성을 모델링하고 구별해야 하며 그 결과물은 비즈니스 정체성. 비즈니스 ID는 고유하며 ID 번호와 유사하며 전체 비즈니스에서 고유해야 합니다. 비즈니스 아이덴티티를 통해 비즈니스 센터에서는 비즈니스 프로세스와 비즈니스 규칙을 추상화하고, 비즈니스 아이덴티티를 기반으로 서비스 라우팅 및 비즈니스 모니터링을 구현할 수 있습니다. 둘째, 비즈니스 ID는 SAAS 시스템의 테넌트 개념과 유사합니다. 다양한 비즈니스 당사자가 비즈니스 ID를 사용하여 중간 사무실에서 데이터 권한을 분리합니다. 이를 통해 각 비즈니스의 운영은 해당 비즈니스 부분의 데이터만 볼 수 있습니다. 예를 들어 자동차 전자상거래 분야에서는 사람, 상품, 장소라는 세 가지 차원을 통해 비즈니스 정체성을 추상화합니다. 인간 차원에는 멤버십 보유 여부, 자동차 인증 소유자인지, 어떤 부가 가치 서비스가 활성화되었는지 등이 포함됩니다. 배송 방법(상각, 교환, 4S 매장 배송) 등 분야의 차원에는 온라인 주문, 오프라인 주문, 주문한 온라인 쇼핑몰, 주문한 배송 매장, 출처가 포함됩니다. 제품 배송 채널 등 이러한 차원을 기반으로 고유한 비즈니스 정체성이 결정되면 각 거래에 대한 비즈니스 프로세스가 결정됩니다. 서비스 오케스트레이션 전자상거래 비즈니스 센터는 전체적으로 마이크로서비스 아키텍처를 채택하고 전체 전자상거래 시스템이 판매자 센터, 사용자 센터, 상품 센터, 프로모션 센터, 거래 센터, 이행 센터로 분할됩니다. 센터 및 판매 후 서비스 센터. 각 센터는 비즈니스 속성이 있는 기능과 비즈니스 속성이 없는 기본 기능이라는 두 가지 계층으로 논리적으로 구분됩니다. 기본 기능 계층은 비즈니스 요구 사항의 조정에 따라 변경되지 않는 도메인 모델의 엔터티 속성, 동작 및 이벤트에 중점을 두고 업계 공통 동작에 중점을 두고 비즈니스 모델을 융합하며 기본 서비스의 안정성을 보장합니다. 비즈니스 속성을 지닌 역량은 서비스 구성, 프로세스 오케스트레이션 등의 기술적 수단을 통해 기본 역량 계층에 구축되어 비즈니스 중심의 솔루션을 형성하고 비즈니스 공통성에서 개인화로의 전환을 완료합니다. 두 가지 일반적인 접근 방식이 있습니다. 하나는 하드 코딩을 사용하는 것입니다. 다양한 비즈니스 라인의 논리가 계속 증가함에 따라 각 비즈니스 기능에서 호출하는 기본 기능이 복잡해지고 복잡해지며 이를 구성하고 유연하게 구현하기가 어려워집니다. 요구 사항이 변경되면 테스터가 수정 사항의 영향 범위를 평가하기 어렵고 회귀 테스트의 비용 주기가 길어 진정한 민첩한 개발과 신속한 비즈니스 대응을 달성하기 어렵습니다. 두 번째는 서비스 오케스트레이션을 사용하는 것입니다. 기존 마이크로서비스의 서비스 오케스트레이션을 통해 서비스를 구성한 후 프런트 데스크에서 요구하는 정보를 한 번에 반환합니다. 다양한 비즈니스 라인의 기능은 다양한 프로세스를 실행합니다. 그래픽, XML 및 JSON 조정 프레임워크를 통해 프로세스를 명확하게 만들고 코드 세부 정보를 보호할 수 있습니다. 서비스 분할의 이점에 대해 자세히 설명할 필요는 없지만 비즈니스 가치를 실현하려면 단일 서비스의 기능이 아니라 모든 서비스를 조율하여 기업의 End-to-End 비즈니스 성공을 보장해야 합니다. 프로세스. 비즈니스 중간 플랫폼은 기업 비즈니스를 위한 통합 플랫폼입니다. 통합 기술은 프로세스를 구성하는 애플리케이션과 리소스를 느슨하게 결합해야 합니다. 그렇지 않으면 프로세스의 논리가 특정 기술 플랫폼에 하드 코딩되어 변경될 수 있습니다. 비용이 많이 들기 때문에 전체 목표를 위반합니다. 서비스 오케스트레이션 프레임워크 서비스 오케스트레이션 분야에는 이미 많은 산업 솔루션이 있습니다. API 게이트웨이 기반 서비스 오케스트레이션[13], 워크플로 시스템 기반 오케스트레이션 프레임워크 Flowable 및 Activiti[14], Netflix를 참조합니다. Conductor[16]와 Zeebe[17]는 마이크로서비스 아키텍처 오케스트레이션 프레임워크입니다. 기술적 원리 분석을 통해 우리는 모두 일정한 결함이 있으며 전자상거래 비즈니스 중간 단계의 서비스 조정에 적용할 수 없다는 것을 발견했습니다. 결국 우리는 Apache Camel [18]을 기본 엔진으로 선택했습니다. 두 번째로 서비스 오케스트레이션을 진행했습니다. Apache Camel은 2007년에 탄생했습니다. 2009년경에 Apache Camel의 최상위 프로젝트가 되었으며 최신 버전은 3.0입니다. Apache Camel의 장점은 출시 이후 10년 넘게 300개 이상의 확장 구성 요소를 보유하고 있다는 것입니다. 확장 메커니즘도 매우 편리하고 유연하며 즉시 사용할 수 있는 모범 사례를 통해 애플리케이션 통합 문제를 해결합니다. 이벤트 기반 아키텍처를 기반으로 하여 성능과 처리량이 우수합니다[19]. 다음은 간단한 서비스 프로세스 조정 예입니다. 비즈니스 중간 사무실은 서비스 조정 기술을 사용하여 구성 요소의 시각적 표현으로 트랜잭션 기능을 자동으로 식별하여 기능 맵을 형성할 수 있습니다. 드래그 앤 드롭을 통해 서비스 프로세스를 조율하는 방식으로 비즈니스에 적합한 거래 프로세스의 전부 또는 일부를 빌딩 블록과 유사하게 신속하게 구축하고, 기본 구성요소를 재사용하고 유연하게 매칭함으로써 기업 차원의 전자상거래 재사용을 실현합니다. 기능을 제공하고 개발 비용을 절감하며 비즈니스 역량을 빠르게 강화합니다. 확장 포인트 프레임워크 확장 포인트의 전체 이름은 Service Provider Interface, 줄여서 SPI입니다. 이는 타사 확장의 인터페이스 구현 클래스를 로드하고 실행하기 위해 Java에서 제공하는 메커니즘 집합입니다. 일반적으로 구성 요소 교체 및 프레임워크 확장 시나리오에 사용됩니다. SPI는 서비스 구현에서 서비스 인터페이스를 분리하여 분리를 달성하고 애플리케이션 확장성을 향상시킵니다. 프로그래밍에서는 특정 구현 클래스 참조 없이 모듈 간에 인터페이스 지향 프로그래밍이 사용되며, 구현 클래스를 동적으로 로드하여 애플리케이션 플러그인을 구현합니다. COLA 프레임워크는 Alibaba 기술 전문가가 제안한 애플리케이션 아키텍처용 확장 포인트 프레임워크입니다[20]. COLA 프레임워크의 확장은 주석을 통해 구현됩니다. 확장 확장 주석은 유스 케이스(useCase), 비즈니스(bizId) 및 시나리오(scenario)의 세 가지 속성을 사용하여 ID를 식별합니다. COLA 프레임워크의 확장점을 사용하면 코드 수준에서 다양한 비즈니스 ID의 논리적 격리를 지원할 수 있습니다. 이는 소프트웨어 설계의 시작 및 종료 원칙에 따라 다양한 구현 클래스에 다양한 로직이 분산되어 있기 때문입니다. 애플리케이션 Spring 컨텍스트가 초기화되면 COLA 프레임워크는 Map 구조에 저장된 확장 지점 등록을 위한 확장 주석을 사용하여 Bean을 스캔하기 시작합니다. 키는 useCase, bizId 및 시나리오의 문자열 연결이며 값은 콩. 런타임 시 비즈니스 ID를 통해 확장점 구현 클래스를 찾은 다음 확장점에서 구현한 로직이 실행됩니다. 확장점 구현 위치를 찾을 때 3계층 라우팅이 지원됩니다. 먼저 useCase+bizId+scenario에 따라 확장점을 찾습니다. 확장점이 없으면 useCase+bizId+scenario 기본값에 따라 검색됩니다. 발견되지 않은 경우 useCase+bizId 기본값+시나리오에 따라 발견됩니다. 기본값 검색, 구체적인 원칙은 그림에 표시됩니다. 간단한 비즈니스 시나리오의 경우 기능적이지 않은 경우가 많지 않습니다. 애플리케이션 시스템의 높은 확장성과 비즈니스 격리에 대한 요구 사항입니다. 그러나 동일한 애플리케이션 시스템이 더 많은 비즈니스를 지원하고 비즈니스 시나리오가 더욱 복잡해짐에 따라 변화하는 비즈니스 규칙을 확고히 하기 위해 아키텍처 수준에서 통합 확장 솔루션을 제공해야 합니다. 이는 기술 사양을 통일하는 데 도움이 될 뿐만 아니라 하드 코딩을 줄이는 데도 도움이 됩니다. IF-ELSE, 전략 모드 등은 개발자 수준의 불일치로 인해 사양의 이해가 복잡하고 일관성이 없기 때문에 발생합니다. 확장 지점 메커니즘을 통해 비즈니스 센터는 SAAS 관리 테넌트와 같은 비즈니스 ID 및 프레임워크 수준에서 다양한 서비스를 관리할 수 있으며 다양한 시나리오에서 사전 정의된 확장 지점을 확장할 수 있습니다. 알리바바의 비즈니스 미들 오피스 역시 확장 포인트 아이디어를 기반으로 핵심 비즈니스 로직과 기술 세부 사항의 분리 및 분리를 실현함으로써 공유 비즈니스 유닛이 그룹 내 수백 개의 비즈니스 라인을 지원할 수 있도록 한다. 서비스 오케스트레이션 + 확장 포인트 적용 예시 기능 검증 후 전자상거래 거래 시스템의 시나리오를 분류했습니다. 먼저, 문제가 발생하더라도 사용자에게 미치는 영향이 최소화되고 사용자 인식이 낮은 노드를 선택하여 재구성을 시도했습니다. , 예를 들어 미결제 주문은 시간이 지남에 따라 종료되고 사용자가 주문을 취소합니다. 사용자가 주문을 취소하는 경우를 예로 들면, 수정 전 각 업체의 사용자가 주문을 취소하는 로직은 주문 상태를 취소 상태로 수정한 후 동일한 프로세스를 실행하는 것입니다. -코딩된 의사 코드는 그림과 같습니다. 수정 후 각 업종의 특성에 맞게 꼼꼼히 정리했습니다. 예를 들어 중고차 사업이 쿠폰을 사용하지 않는 경우, 그러면 이 링크가 필요하지 않습니다. 포인트의 일반적인 능력 측면에서 Wanlitong 포인트가 확장되었습니다. 의사 코드는 그림에 나와 있습니다. 여행자 비즈니스 라인의 호텔 및 항공권 사업에는 전통적인 상품 재고 개념이 없으므로 더 이상 상품 재고를 반환할 필요가 없지만 추상화합니다. 새로운 일반 기능: 공급업체 주문을 취소하고, 호텔 공급업체 주문 취소 및 항공권 공급업체 주문 취소를 위한 두 개의 확장 지점을 미리 설정합니다. 의사 코드는 그림과 같습니다. 전체 시스템의 적용 효과는 명백하며 주로 성능 향상과 인간 효율성 향상에 반영됩니다. 성능 개선은 주로 시스템 응답 시간 단축에 반영됩니다. 수정 후 주문 취소를 위한 인터페이스의 생산 환경에 대한 TP99 개선 비율은 약 30%입니다. 인적 효율성의 향상은 주로 주문 취소와 새로운 프로세스 노드 추가를 테스트하는 데 걸리는 시간을 비교하는 데 반영됩니다. 수정하기 전에 각 비즈니스 프로세스 간의 코드를 결합하여 새로운 노드를 추가하는 프로세스를 수정하려면 회귀가 필요합니다. 이전 사업에 대한 테스트 수정 후에는 각 사업에 대해 회귀 테스트를 수행할 필요가 없습니다. 비즈니스 구성 플랫폼 아키텍처 실무에서 비즈니스 흐름에 영향을 미치는 핵심 구성을 일률적으로 추출하고, 비즈니스 아이덴티티에 따라 속성 값을 구성하여 전체 거래 프로세스 링크의 표준이 보장되도록 합니다. 거래 핵심 링크 코드는 자주 수정되며, 서로 다른 속성 값을 기반으로 동일한 거래 과정에서 서로 다른 노드에서 서로 다른 비즈니스가 유연하게 전환됩니다. 예를 들어, 제품이 자원 풀에 자동으로 푸시되는지, 주문하려면 신분증이 필요한지, 결제가 성공하면 단서가 푸시되는지, N일 이상 영수증이 확인되지 않는지, 영수증이 자동으로 확인됩니다. 모든 구성 항목은 구성 관리 배경 유지를 통해 통합됩니다. 또한 비즈니스 ID를 포함한 전자상거래 플랫폼의 모든 메타데이터에 대해서도 구성 관리 백엔드를 통해 통합 관리하고 외부 쿼리 서비스를 제공하기 위한 통합 API를 제공합니다. 개발 도구 비즈니스와 기술의 다차원적인 측면에서 시작하여 일반적인 비즈니스 문제나 일상 업무에서 발생하는 기술적 문제에 대해 다양하고 실용적이고 편리한 장치를 개발하여 업무 효율성을 높이고 문제를 신속하게 해결합니다. . 메시지 배포 및 검색 도구, 제품 표시 가격 비교 및 모니터링 도구 등의 기타 효과. 도구에 대한 모든 사람의 인식이 계속 높아짐에 따라 이러한 작은 도구가 계속해서 등장하고 함께 모여 R&D 인력에게 없어서는 안 될 도구 상자를 형성합니다. 데이터 시각화 전자상거래 시스템의 성과 지표, 자원 활용 지표, 통화량 등 시스템 차원의 지표를 기업의 클라우드 플랫폼을 통해 균일하게 모니터링할 수 있는 것이 비즈니스 데이터와 마찬가지로 필요합니다. 통합된 비즈니스 데이터 제공 시각적 도구는 비즈니스 당사자에게 관련 결정을 내리는 데 참조 자료를 제공합니다. 이를 위해 실시간 + 오프라인 접근 방식을 활용한 주문 시각화 대형 화면 시스템을 개발했습니다. 이 시스템을 통해 사업 부문, 주문 상태, 지역 등 다차원에서 주문량 변화를 실시간으로 모니터링할 수 있습니다. 일정 기간 동안의 주문량 변동이 사전 구성된 임계값을 초과하는 경우 DingTalk 메시지가 전송되어 비즈니스 당사자에게 즉시 주의를 알립니다. 또한 오프라인 데이터의 경우에도 일, 주, 월별로 다차원의 데이터에 대한 통계 분석을 실시하여 최종적으로 이메일 및 오피스 APP 메시지 형태로 비즈니스 당사자에게 전송합니다. 이러한 수단의 목적은 전자상거래 데이터의 시각적 관리를 실현하고 비즈니스 사용자에게 전자상거래 비즈니스의 포괄적인 관리 및 제어를 위한 보다 편리한 도구를 제공하는 것입니다. 지식 축적 제가 속한 팀은 회사 내 전자상거래 분야의 전문팀으로, 다년간 기술 및 제품 운영 분야에서 많은 경험을 축적해 왔습니다. 우리는 전자상거래 중간 플랫폼 구축 과정 전반에 걸쳐 이러한 경험과 일상적인 문제에 대한 솔루션을 지속적인 부의 축적으로 활용했습니다. 과거에는 이를 요약하기 위해 위키와 같은 문서 관리 도구를 사용했습니다. 이러한 지식으로부터 가치를 창출하기 위해 자체 전자상거래 지식베이스 시스템을 구축하기 시작했으며, 전체 지식베이스가 제공하는 다양한 분야에 따라 지식 축적으로 활용될 수 있는 모든 콘텐츠를 지식베이스 시스템에 입력합니다. 빠른 검색 및 위치 지정 기능은 기술 인력 및 제품 운영 인력에게 도움이 될 수 있으며 모든 사람의 지식 축적에 대한 인식을 더욱 높이고 모든 사람의 작업 효율성을 향상시킬 수 있습니다. 에필로그 20년 전, 중국에서는 이제 막 인터넷이 대중화되기 시작했습니다. 정보는 정보의 형태로 표시되었으며 온라인 거래는 거의 없었습니다. 10년 전에는 인터넷이 급속히 발전하여 소비자가 타오바오로 대표되는 온라인 제품을 구매할 수 있게 되었습니다. , Tmall, JD.com 온라인 거래를 위해 쇼핑몰에서 필요하거나 좋아하는 제품을 구매하세요. 이제 다양한 전자상거래 형태가 끊임없이 등장하고 있으며 콘텐츠 전자상거래 Xiaohongshu, 관심 등이 번성하는 추세가 되었습니다. 전자상거래 Douyin Kuaishou, 소셜 전자상거래 WeChat, Pinduoduo 등, 회원 전자상거래 업체 Tmall 88vip, JD plus 등 이러한 온라인 거래 형태는 전자상거래가 인터넷 분야의 트래픽을 수익화하는 중요한 부분이며 인터넷 기업 인프라의 물, 전기, 석탄이 되었음을 완전히 입증합니다. 전자상거래 중간 플랫폼 구축은 기술적인 시스템 구축일 뿐만 아니라 조직 구조를 재편하는 과정이기도 하다. 그러나 시간이 지날수록 미들오피스의 가치가 성장할 수 있는 여지는 점점 좁아질 것입니다. 이를 위해서는 의식적으로 혁신 포인트를 찾고, 기존 시스템의 경계를 뛰어넘고, 국경을 초월한 사고가 필요하기 때문에 저희도 시작하게 되었습니다. 프론트오피스 사업에 더욱 다가가기 위해 신규사업 발굴과 기술아키텍처 업그레이드를 적극 추진합니다. 새로운 소매점 탐색 과거 자동차 전자상거래의 비즈니스 모델을 탐색하면서 우리는 서비스 제공을 위해 4S 매장을 우회할 수 없다는 것이 핵심 문제점이라는 것을 발견했습니다. 최근에는 테슬라와 국내 자동차 제조사의 새로운 세력이 등장하면서 기존 자동차 회사의 4S 유통 시스템 생태계가 단숨에 무너지고 있다. 온라인 자동차 주문 + 오프라인 배송의 새로운 모델이 가능해지고 있습니다. 기존 전자상거래 시스템의 역량을 업그레이드하여 상품은 SKU 선택을 지원하고, 주문은 대·소 예치금 통합결제 및 환불을 지원하며, 새로운 배송시스템을 추가하여 산업협회의 맞춤형 자동차 사업 및 신규 자동차 소매점 오프라인 매장 지원사업입니다. 앞으로도 우리는 새로운 에너지 옵션에 대한 업계 조정 가격 변동 모델과 옵션 제품 패키지에 대한 서비스 패키지 모델을 계속해서 만들 것입니다. 아키텍처 업그레이드 원래 전자상거래 주문 프로세스에서 설계된 외부 서비스는 상대적으로 세분화된 세분화된 서비스이므로 비즈니스 측면에서 상대적으로 높은 액세스 비용과 열악한 사용자 경험을 초래합니다. 앞으로는 BFF 레이어 추가, 콜체인 간소화, 전자상거래 접근 스캐폴딩 등 기술적 수단을 통해 사업의 제품력과 운영 효율성을 향상시킬 예정이다.