건축 설계 조건
다음 세 가지 경우는 건축 설계에 적합하지 않습니다.
건축에 관심이 있는 것이 아니라 수요에 대한 압박입니다.
IT 업계에 진출한 지 4 년도 채 되지 않았습니다.
주관적 능동성이 약하고, 현실에 안주하다.
건축 설계의 장점
비즈니스 구조 시스템을 더 잘 빗질하십시오.
더 나은 확장, 유지 보수 및 성능 최적화
기업 비즈니스의 유연한 홍보에 더 잘 적응하십시오.
대용량 데이터의 정련 및 응답에 더 잘 적응;
안정성 향상, 비용 절감, 반복 속도 향상
건축 설계는 문제에주의를 기울여야한다.
아키텍처 설계는 아키텍처가 어떻게 구축되느냐가 아니라 비즈니스 요구 사항에 따라 엄격하게 분석해야 하며, 이를 달성하기 위해 어떤 기술이 더 좋고 장기적으로 발전해야 하는지에 유의해야 합니다.
또한, 구축 된 아키텍처는 작동 할 수 있지만, 성능은 따라 잡아야합니다. 그렇지 않으면 아키텍처 설계가 역효과를 내고 불필요한 작업량을 증가시킬 수 있습니다. 아키텍처 설계 전략에 대해 자세히 설명합니다.
플랫폼 요구 사항
고객 요구 사항
온라인 쇼핑, 온라인 지불 또는 착불;
고객이 상품을 구입한 후 고객 서비스와 소통할 수 있다.
상품 조달 프로세스 및 물류 관리 및 추적;
수령 후, 상품 및 물류 평가 점수;
고객의 요구는 가장 높으며, 이는 또한 기업의 핵심 수요를 나타낸다. 물론, 기업의 요구에는 다른 많은 비기능적 요구도 포함되어 있다. 자세한 내용은 수요 정렬 섹션을 참조하십시오.
플랫폼의 비즈니스 아키텍처
업무의 필요에 따라 상품 하위 시스템, 쇼핑 하위 시스템, 지불 하위 시스템, 물류 하위 시스템, 고객 서비스 하위 시스템, 리뷰 하위 시스템으로 나눌 수 있습니다. 코어가 아닌 요구 사항은 고객 서비스 하위 시스템, 설명 하위 시스템 및 인터페이스 하위 시스템으로 나눌 수 있습니다. 또한 각 하위 시스템의 코어 수준에 따라 코어 하위 시스템과 비코어 하위 시스템으로 나눌 수 있습니다. 전자에는 상품 하위 시스템, 쇼핑 하위 시스템, 지불 하위 시스템 및 물류 하위 시스템이 포함됩니다. 후자는 설명 하위 시스템, 고객 서비스 하위 시스템 및 인터페이스 하위 시스템을 포함합니다. 일반적인 대형 전자 상거래 플랫폼의 물류 시스템은 독립 시스템 (창고, 보관, 재고 관리, 배송 관리, 화물 관리) 으로, 여기서 하위 시스템으로 나누는 주요 목적은 핵심 아키텍처를 입증하는 것입니다. 이 아키텍처에서 물류 하위 시스템은 일반적으로 도킹 모듈로 사용되어 독립 하위 시스템을 도킹하고 관리합니다.
1. 비즈니스 분할의 목적
모듈 하위 시스템 간의 커플링, 서비스 가능성 및 확장성을 해결하기 위해
하위 시스템을 개별적으로 배포하여 중앙 집중식 배포로 인해 문제가 발생하지 않도록 합니다.
생산성을 극대화하기 위해 특정 하위 시스템을 담당하는 전담 팀을 지정합니다.
큰 데이터와 높은 압력에 대응하여 핵심 하위 시스템의 정상적인 사용을 보장합니다.
2. 비즈니스 맵
위의 서비스 아키텍처에서 핵심 서비스와 비 핵심 서비스는 분리되어 있으며 각 시스템은 독립적으로 배포 및 구현되어야 많은 양의 데이터를 줄이고 각 시스템을 독립적으로 실행하여 가용성을 높일 수 있습니다. 필요한 경우 핵심 서비스가 사용자를 정상적으로 서비스할 수 있도록 비핵심 시스템의 리소스 오버헤드를 일시 중지할 수 있습니다.
플랫폼의 기술 아키텍처
이러한 비즈니스 아키텍처 다이어그램을 바탕으로 사용자의 경험과 지원에 기반한 기술 아키텍처의 진화가 필요합니다. 따라서 기술 아키텍처 구축은 한 번에 이루어지는 것이 아니라 비즈니스가 발전함에 따라 비즈니스 데이터의 영향에 대응하기 위해 시스템 아키텍처가 점진적으로 개선되고 업데이트됩니다.
1, 인프라 설계
옛날에는 많은 중소기업들이 채택한 아키텍처 설계가 매우 간단했던 것을 기억한다. 기본적으로 서버 한 대가 모든 배포 요구 사항을 충족하는 데 사용됩니다. 예를 들어 어플리케이션 배포, 데이터베이스 스토리지, 사진 스토리지용 서버 한 대가 있습니다. 사용자 데이터가 50 만 명이 넘을 때 시스템에 많은 성능 문제가 발생할 줄은 생각지도 못했다. 데이터베이스와 프로그램에 대한 다양한 성능 최적화에도 불구하고 결과는 크게 개선되지 않았습니다. 이 아키텍처는 다음과 같습니다.
나중에 IT 청서원은 그림의 읽기와 쓰기가 시스템 성능에 심각한 영향을 미치는 것을 발견하고, 그림을 독립형 서버에 저장하고, Memcache 와 같은 캐시 미들웨어를 아키텍처에 도입했다. 이는 바람직하며 성능이 1-2 향상되었습니다. 아키텍처 설계는 다음과 같습니다.
2. 초급 건축 설계
몇 년 전, 전자 상거래 웹 사이트의 일반적인 관행은 서버 3 대, 배포 응용 프로그램 1 대, 배포 데이터베이스 1 대, 배포 NFS 파일 시스템 1 대, 규모, 성능 소모가 많은 부분을 서로 다른 서버 장치로 분리하고 필요한 캐시 미들웨어를 갖추어 거의 654.38+00 만 개에 달하는 데이터를 만족시킬 수 있었다. 구체적인 아키텍처 다이어그램은 다음과 같습니다.
그러나 현재 주류 웹 사이트 아키텍처는 이미 다르며, 대부분 클러스터를 사용하여 로드 밸런싱 및 고가용성을 달성합니다. 아키텍처는 다음과 같을 수 있습니다.
참고:
여러 웹 서버가 관련된 경우 세션을 동기화하는 방법에 문제가 발생할 수 있습니다. 일반적으로 가장 일반적인 방법은 캐시 미들웨어를 사용하여 세션 정보를 저장하고 관리하는 것입니다.
3. 최적화된 아키텍처 설계
분산, 클러스터링, 로드 밸런싱, 리버스 에이전트, 메시지 큐 및 다중 레벨 캐싱 기술을 주로 사용하여 높은 동시성과 가용성이 높은 대형 전자 상거래 웹 사이트의 아키텍처 설계를 해결합니다. 아키텍처 설계는 타오바오, JD.COM 등과 같은 프로세스를 비교하는 대규모 전자 상거래 웹 사이트에서 사용되는 아키텍처 모델입니다. 약간 다를 수도 있지만 다 비슷해요! 구체적인 아키텍처 시나리오는 다음과 같습니다.
플랫폼 아키텍처 개요
여기서 주로 요약한 것은 최적화된 아키텍처로, 계층별로 구성되어 있다. * * * 4 계층으로 나뉘어 계층 분업이 명확하고, 확장성이 높고, 커플링이 낮고, 로드 밸런싱, 클러스터, 배포, 캐싱이 가능합니다. 이 아키텍처는 다음과 같습니다.
자, 여기 전자상거래 플랫폼의 아키텍처 설계를 소개하겠습니다. 이 글은 주로 건축 설계의 이념과 응용의 핵심 기술을 소개하여 학생들이 건축 설계에서 참고할 수 있도록 합니다! 더 많이 알고 싶으면 나에게 관심을 가질 수 있다.