데이터부터 대형 모델 적용까지, 개발 팁을 공유하기 위해 11월 25일 항저우 위안추앙 컨퍼런스가 개최되었습니다.

시스템을 설계하는 과정은 건물을 짓는 과정이며, 건축설계의 품질이 건물의 품질을 직접적으로 결정합니다.

시스템 아키텍처를 설계할 때 우리는 항상 대규모 시스템의 아키텍처를 어떻게 시작해야 할지, 어디서 설계를 시작해야 할지 등 일련의 문제에 직면하게 됩니다. 시스템을 여러 모듈로 나누어야 하며, 모듈을 어떻게 나누어야 보다 합리적일까요? 아니면 제품이 제시하는 요구 사항이 매우 불합리하고 일반적인 아키텍처 설계에 완전히 영향을 미친다고 느낄 수도 있습니다! 기능적이지 않은 요구사항에 주의를 기울이지 않고 혼란스럽게 만들 수 있습니까?

이러한 문제로 인해 우리는 처음 아키텍처 설계를 시작했을 때 당황했지만, 시스템 아키텍처 설계를 하나씩 완성해 나가면서 아키텍처 설계에는 따라야 할 규칙과 규정이 있다는 것을 알게 되었습니다. 지속적인 축적과 침전을 통해 완전한 아키텍처 설계 방법론이 형성되며, 새로운 대규모 시스템 아키텍처 설계에 직면하면 단계별로 리드미컬하게 수행되어 최종적으로 전체 아키텍처 설계가 완성됩니다. .

건축 디자인의 원리

건축 설계는 다음과 같은 몇 가지 원칙을 따라야 합니다.

1. 아키텍처 설계에는 메소드 시스템이 필요합니다.

건축설계는 건축설계에 직접 사용되는 '단일 방식'이 아닌, 여러 가지 고유한 방식으로 구성된 '방식 시스템'이며, 이 시스템은 새로운 기술의 발전과 함께 계속 진화해 나갈 것이다.

2. 건축 디자인은 질문에 의해 주도됩니다

건축 설계는 질문 중심 프로세스입니다. "수요 중심"을 기반으로 건축 설계의 중간 결과에 대해 끊임없이 질문하고 "질문"을 통해 더 많은 "품질 속성"과 더 많은 "기능 시나리오"를 도입해야 합니다. .

3. 다단계의 멀티뷰

건축 설계, 다단계 또는 다중 뷰? 건축설계는 우선 '다단계'로 건축설계를 여러 단계로 나누어 각 단계에서만 '관점' 차원을 고려하게 된다.

건축 설계의 세 단계

1단계. 준비단계

준비 단계의 목표는 요구사항을 종합적으로 이해하고, 요구사항의 특성을 파악하고, 아키텍처 설계의 원동력을 결정하는 것입니다.

준비단계에서는 요구사항을 종합적으로 정리하고 이해해야 하며 요구사항의 세부사항을 하나도 놓치지 않아야 합니다. 동시에 우리는 요구 사항에 의해 생성된 다양한 품질 속성과 시스템 제약 조건을 분석하고 주요 아키텍처 속성이 누락되지 않도록 아키텍처를 설계할 때 이러한 제약 조건을 고려합니다.

2단계. 개념적 아키텍처

개념적 아키텍처는 기능 , 품질 및 제약 조건을 포함하여 요구 사항의 모든 측면을 고려해야 합니다 .

3단계: 아키텍처 개선

아키텍처 개선 단계에서는 5가지 관점의 5가지 뷰를 설계하여 전체 시스템의 종합적인 설계를 완성했습니다.

건축 디자인의 전체 라인

비기능적 요구사항 고려 : 비기능적 요구사항은 설계 과정에서 새로운 요구사항이 계속 발견되기 때문에 하루아침에 해결될 수 없으며, 설계가 완료되더라도 개발 단계에서 비기능적 요구사항에 영향을 미치는 제약사항이 나타나게 됩니다. , 따라서 이 단계 전체에서 비기능적 요구 사항에 주의를 기울여야 합니다.

준비 아키텍처 단계 분석

아키텍처 준비의 가장 중요한 목표는 수요에 대한 전반적인 관점을 확립하고, 수요의 특성을 파악하며, 아키텍처 설계의 추진력을 결정하는 것입니다. 요구 사항에 대한 상세한 분석을 통해 요구 사항에 대한 거시적 인식을 갖게 되는 동시에 시스템 품질 요구 사항 및 제약 조건에 따라 시스템 설계에 부과되는 제약 조건도 고려합니다.

요구사항 구조화

수요는 분산된 수요 지점이 아닌 구조화되어 있으며, 분석된 수요를 구조화해야만 전체 수요를 거시적으로 파악할 수 있습니다. ADMEMS 2차원 매트릭스를 사용하여 아키텍처에 영향을 미치는 요소를 분류할 수 있습니다.

예를 들어, 다음 매트릭스 분석은 요구사항을 다차원으로 나누어 "일반 기능", "품질", "제약 조건"의 3가지 측면에서 수평적으로 분석합니다. 광역 기능이란 충족해야 하는 기본 기능을 말합니다. , 제품의 특성이나 영업담당자에게 직접 물어보세요. 품질 차원은 시스템이 기본 요구 사항을 충족하는 동시에 후속 시스템 진화 및 극단적인 시나리오(예: : 이용자 급증, 반짝 매출) 기다림의 만족. 제약 조건은 출시 날짜, 출시 환경, 개발자 기술 수준 등과 같은 시스템 설계 중 일부 제한 사항입니다. 수직적으로 "비즈니스 수준 요구 사항", "사용자 수준 요구 사항", "개발 수준 요구 사항"의 세 가지 유지 관리 수준으로 구분됩니다. "비즈니스 수준 요구 사항"은 제품이나 비즈니스 담당자가 제시하는 기본 요구 사항을 의미하고 "사용자 수준 요구 사항"을 의미합니다. '레벨 요구사항'은 시스템에서 도출되며, 사용자 관점에서는 사용자 컴퓨터 운용 수준, 사용자 사용 습관 등 잠재적인 요구 사항을 발굴하고, '개발 수준 요구 사항'은 R&D 인력 관점에서 확장성, 테스트 가능성, 기술 환경 및 기타 다양한 차원이 필요합니다.

요구사항을 구조화함으로써 전반적인 요구사항을 종합적으로 분석하고 요구사항을 전체적으로 이해할 수 있으며, 동시에 다양한 각도에서 시스템 제약 조건을 발견하고 누락을 방지하기 위해 시스템 설계 초기부터 설계를 시작할 수 있습니다. 주요 제약 사항 건축 설계 실패.

제약조건의 영향 분석

제약 분석의 여러 측면:

1. 제품 또는 운영 담당자의 구속력 있는 요구 사항

온라인 시간, 예산, 건설 기간 요구 사항 등과 같은 시스템의 비기능적 요구 사항

사업규칙이나 사업제한, 관련법령, 특허 등 사업분야와 관련된 제한

2. 사용자 의 바인딩 요구 사항

시스템 사용자에게는 사용자의 컴퓨터 수준, 연령 그룹, 사용 선호도, 국가 등과 같은 제한적인 요구 사항도 있습니다.

예를 들어 일반적으로 사용자의 컴퓨터 능력이 약한 경우 개발 시 상호 작용 방법이 너무 복잡하지 않아야 하며 동시에 사용자가 시스템을 중단시키지 않도록 시스템의 견고성을 고려해야 합니다. .

사용자가 제품을 사용할 때 외부 환경에 따라 제약이 발생할 수도 있는데, 예를 들어 접속 환경이 인트라넷인지 외부 네트워크인지 여부에 따라 링크 접속을 위해 시스템에서 제공하는 다양한 네트워크 권한이 결정됩니다. 액세스 환경의 신호 강도가 낮으면 시스템의 성능 요구 사항이 높아집니다.

3. 개발 또는 운영 및 유지관리 인력 의 구속력 있는 요구사항

개발팀의 기술 수준과 통합 정도도 시스템 개발을 제한하며, 개발자가 모두 고위 R&D 인력이고 현재 기술 스택에 대한 심층적인 이해를 갖고 있다면 개발 진행 속도가 더 빨라질 것입니다. 개발에 개입하기 전에 기술 스택을 배워야 하는 경우 구축 기간이나 시스템 위험 측면에서 추가 고려 사항이 필요합니다.

4. 업계의 현재 기술 환경

현재 기술 환경에서 미들웨어의 성숙도, 프로그래밍 언어와 대중성, 장점과 단점 등은 모두 아키텍처 설계에 제약을 가할 것입니다.

제약사항 분류:

1. 직접적인 제지

예를 들어 시스템은 Linux 플랫폼에서 실행됩니다.

2. 제약조건을 기능적 요구사항으로 변환

이러한 제약사항의 경우 기능적 요구사항으로 직접 변환할 수 있습니다.

예: 공급업체는 자체 도시 정보 테이블 세트를 보유하고 있습니다. -> 기능적 요구 사항이 도출됩니다. 도시 변환이 필요합니다.

예: 공급자의 서버 성능이 낮고 최대 tps가 10 -> 결과적인 기능 요구 사항: 현재 제한 요청이 필요합니다.

3. 제약조건을 품질 속성 요구사항으로 변환

예: 시스템 사용자의 컴퓨터 기술이 높지 않습니다.

품질 속성으로 변환: 사용 용이성(그렇지 않으면 사용되지 않음), 견고성(시스템이 마비됨)

중요한 품질 결정

시스템의 주요 품질은 절충이 필요하므로, 비즈니스 담당자가 어떤 측면에 더 주의를 기울여야 하는지 확인하거나, 어떤 측면이 필요하고, 어떤 측면은 필요에 따라 적절하게 무시할 수 있는지 판단해야 합니다.

먼저 아키텍처가 지원하는 데 중점을 둔 품질 속성을 결정한 다음 상충되는 품질 속성 간에 균형을 맞춰야 합니다. 예를 들어, 성능의 품질 속성이 충족되면 새로운 솔루션이나 구성 요소의 도입으로 인해 유지 관리성과 테스트 가능성이 낮아지고, 확장성이 향상되면 시스템의 성능과 보안 등에 영향을 미치게 됩니다. 우리가 해야 할 일은 다양한 핵심 특성들 사이에서 균형을 맞추는 것입니다.

주요 기능 식별

주요 기능의 4가지 측면 식별

1. 핵심 기능

2. 꼭 해야 할 기능

3. 고위험 기능

4. 독특한 기능

다른 일반 시스템에는 없는 기능

파생된 요구 사항에 유의하세요.

요구사항에서 설계로 전환할 때 솔루션 공식화 프로세스의 복잡성으로 인해 파생된 요구사항이 많이 생성되며 파생된 요구사항은 원래 요구사항의 몇 배입니다.

예:

원래 요구 사항: 정기적으로 공급업체 데이터를 가져옵니다.

파생된 요구사항:

1. 공급자 수가 많기 때문에 분산 예약 작업 및 클러스터 동시 풀링 도입이 필요합니다.

2. 공급업체 데이터의 양이 많기 때문에 별도의 데이터베이스 및 테이블 설계가 필요합니다.

3. 빠른 검색, 스토리지 엔진 구성 요소 소개 등이 필요합니다.

이러한 도출된 요구사항을 고려해야 하는데, 비즈니스 요구사항이 반영되지는 않았지만 건축 설계에 영향을 미치는 주요 요소가 누락되어 있습니다.

아키텍처 드라이버 비교:

비즈니스 요구 사항에 따라 아키텍처가 결정됩니다.

중요한 수요 중심 아키텍처:

이를 통해 주요 요구 사항에 따라 구동되는 아키텍처를 통해 더 중요한 부분을 고려할 수 있고, 설계된 아키텍처가 요구 사항을 더 잘 충족할 수 있으며, 성공적인 아키텍처 설계 확률이 더 높아진다는 것을 알 수 있습니다.

개념적 아키텍처 단계 분석

개념적 아키텍처 단계에서는 시스템이 세부 사항에 얽매이지 않고 적절하게 분해됩니다.

개념적 아키텍처의 프로세스는 먼저 핵심 기능을 기반으로 예비 설계를 수행한 다음 설계된 시스템의 상위 수준 분할을 수행하고, 다음으로 비기능 요구사항(핵심 품질 및 제약 조건)을 고려한 후 예비 설계를 수정하는 것입니다. 그리고 그 순환은 계속됩니다.질문과 최적화 과정에서 아키텍처 설계가 개선됩니다.

초기 디자인

예비 설계의 목표는 세부 설계에 들어가지 않고 책임을 찾는 것입니다. 핵심기능을 중심으로 예비설계를 진행하고, 메인프로세스, 핵심프로세스, 골든프로세스 등을 기반으로 흐름도 설계를 진행하여 책임을 발굴합니다.

높은 수준의 세분화

복잡한 시스템을 여러 보조 시스템으로 나눕니다. 또는 특정 하위 시스템으로 직접 분할됩니다.

상위 수준 분할의 두 가지 방법:

1. 시스템 세분화

세분화 시 고려 사항에는 시스템 기능, 배포 환경, 언어, 시스템 규모 등이 포함됩니다.

예를 들어 대규모 시스템은 주문, 제품, 공급망 및 기타 시스템으로 구분됩니다.

2. 시스템 내 세분화

책임, 호출 관계, 다양성 등을 기반으로 시스템의 내부 분할을 수행합니다.

가장 일반적인 것은 계층화인데, 예를 들어 시스템은 게이트웨이 계층, 서비스 계층, 검색 모듈, 맨 터미널 등으로 구분됩니다.

레이어드 앵글

1. 논리적 계층화

논리적 계층화는 책임 분할에 큰 중요성을 부여합니다. 책임은 종종 상위 계층과 하위 계층 간의 관계와 직접적으로 관련됩니다. 상위 계층과 하위 계층은 서로 다른 시스템에 분산되거나 동일한 시스템에 분산될 수 있습니다.

2. 물리적 계층화

소프트웨어 단위는 서로 다른 시스템에 분산되어 있습니다.

3. 유니버설 레이어링

범용성이 다른 것은 여러 계층으로 나누어지며, 일반적으로 범용성이 높을수록 레벨이 낮아집니다.

비기능적 요구사항 고려

구체적인 방법은 다음과 같습니다. 목표-시나리오-결정 테이블을 사용합니다 . 아래 그림을 참조하세요.

아키텍처 설계는 의심에 의해 주도됩니다. 예를 들어 시스템의 가용성에 의문을 제기하고 시스템이 다운될 수 있다고 생각하는 경우 클러스터 배포 설계를 도입합니다. 다운스트림 인터페이스가 시간 초과되거나 예외가 발생할 수 있다고 생각하는 경우 인터페이스 저하 등에 대한 설계를 도입할 예정입니다.

장면에 고려해야 할 5가지 요소

1. 시스템 내부에서 나오든, 시스템 외부에서 나오든 영향의 원천

2. 영향을 미치는 방식

3. 영향을 받는 개체

4. 문제점이나 가치는 무엇입니까?

5. 환경은 어떤가요?

시나리오 장단점:

가치, 비용, 개발 난이도, 발생 확률. 일부 시나리오의 경우 포괄적인 검토와 고려 끝에 지원되지 않을 수 있으며 모든 시나리오가 지원되어야 하는 것은 아니며 그렇지 않으면 과잉 설계가 발생할 수 있습니다.

세부 아키텍처 단계 분석

논리적 관점

논리적 관점은 시스템의 다양한 부분의 책임을 분할 하는 것으로, 다양한 책임에 따라 시스템은 여러 하위 시스템으로 세밀하게 분할될 수 있습니다.

계층적 세련미

시스템 설계의 필요에 따라 시스템의 계층을 세분화할 수 있습니다. 예를 들어 프리젠테이션 계층 -> 비즈니스 계층 -> 데이터 계층을 다음과 같이 세분화할 수 있습니다: 프리젠테이션 계층 -> 제어 계층 -> 인터페이스 계층 -> 인터페이스 구현 레이어 -> 데이터 레이어.

파티션의 도입

분할의 개념은 비즈니스 프로세스와 관련이 있으며 분할의 기본은 책임 입니다 . 예를 들어 정산 프로세스를 분할로 사용할 수 있고 주문 프로세스를 분할로 사용할 수 있습니다. 시스템을 여러 파티션으로 나누면 병렬 개발을 지원할 수 있을 뿐만 아니라 시스템을 여러 하위 도메인으로 나눌 수 있어 비즈니스 개념과 비즈니스 프로세스의 융합에 도움이 됩니다.

메커니즘 추출

메커니즘은 공용 도구, 공용 구성 요소, 공용 프로세스 등과 같이 추상화할 수 있는 시스템의 공용 부분을 나타냅니다. 이러한 공용 부분을 추출하는 것은 아키텍처 설계에 매우 중요합니다.

하위 시스템 분할 원칙:

1. 서로 다른 책임을 가진 단위는 서로 다른 하위 시스템으로 나뉩니다.

2. 다양한 다양성을 지닌 유닛은 다양한 하위 시스템으로 나뉩니다.

3. 다양한 개발 기술이 필요한 단위는 작업량을 고려하여 여러 하위 시스템으로 나누고, 너무 큰 시스템은 추가로 나눕니다.

개발 관점

아키텍처 뷰를 개발하는 작업은 독립적으로 작성되는 "소스 프로그램", 재사용 가능한 라이브러리, 프레임워크 등과 같은 "프로그램 단위"에 "논리적 책임"을 매핑하는 동시에 개발 기술의 선택, 예: 개발 언어, 개발 도구 등 그리고 프로그램 단위, 프로젝트 분할, 디렉토리 구조, 컴파일 종속성 등 간의 관계를 설정해야 합니다.

실행 보기

실행 아키텍처 설계의 작업 내용은 프로세스, 스레드 등 어떤 제어 흐름을 도입할지 결정하고, 각 제어 흐름의 작업을 결정하며, 생성, 파괴, 통신 메커니즘 등과 같은 관련 문제를 처리하는 것입니다. 제어 흐름, 제어 흐름 간 동기화 관계, 리소스 경합 여부, 잠금이 필요한지 여부 등도 고려해야 합니다.

물리적 관점

물리적 아키텍처 설계를 위한 3가지 작업

1. 하드웨어 선택 및 물리적 토폴로지

2. 소프트웨어 대 하드웨어 매핑 관계

3. 계획 최적화

사고의 핵심 포인트: "오버헤드"와 "경합"이 핵심입니다. 경합을 피하고 오버헤드를 줄여야 합니다.

데이터 보기

데이터 뷰는 시스템의 데이터 저장 설계입니다. 시스템 분석을 기반으로 하나 이상의 데이터 전략이 결정됩니다. 6가지 일반적인 데이터 배포 전략은 다음과 같습니다.

1. 독립적인 스키마

다양한 시스템 응용 프로그램은 서로 다른 데이터 스키마를 사용하며 데이터는 완전히 독립적이므로 일반적으로 경계가 명확한 다양한 시스템에서 이 방법을 사용할 수 있습니다.

2. 집중

서로 다른 시스템 응용 프로그램이 동일한 데이터베이스를 사용합니다. 일반적으로 연관된 속성을 가진 응용 프로그램에서 이 방법을 사용할 수 있습니다. 예를 들어 시스템이 서버 측과 관리 측으로 구분되어 있지만 둘 다 동일한 시스템에 속해 있는 경우 동일한 데이터베이스를 사용할 수 있습니다. .

3. 파티션

수평 파티션

수평 파티셔닝은 일반적인 테이블 파티셔닝 방식으로, 스키마가 데이터 볼륨 요구 사항을 충족할 수 없는 경우 여러 파티션으로 나누어 각 파티션이 데이터의 일부를 저장할 수 있습니다.

수직 파티션

수직 파티셔닝은 파티셔닝 전략의 또 다른 차원으로, 단일 데이터베이스가 많은 양의 데이터를 처리할 수 없는 경우 데이터 유형에 따라 수직 파티셔닝을 수행할 수도 있습니다.

4. 복사

여러 데이터베이스가 동일한 데이터를 저장하고 설정된 업데이트 전략에 따라 서로 다른 데이터베이스 간의 데이터 동기화를 보장합니다. 일반적으로 라이브러리 읽기 및 쓰기 분리를 사용하는 솔루션이 바로 이 솔루션입니다. 메인 라이브러리는 쓰기 기능을 제공하고 슬레이브 라이브러리는 읽기 기능을 제공합니다. 그 중 슬레이브 라이브러리는 메인 데이터베이스 데이터를 기반으로 데이터를 동기화합니다.

5. 하위 집합

일부 특수 시나리오의 요구 사항에 따라 원본 데이터의 일부를 저장해야 합니다. 예를 들어 애플리케이션1은 모든 주문을 저장하고 애플리케이션2는 후속 분석 작업을 위해 성공적으로 발행된 주문 중 일부만 필요합니다. 하위 집합 전략을 사용할 수 있습니다. 데이터 뷰 디자인.

6. 개편

데이터 분석이나 후속 프로세스 사용을 위해 여러 다른 애플리케이션을 데이터 소스로 사용하고 다른 애플리케이션과 이기종을 사용합니다.

요약하다

건축 설계의 3단계: 예비 건축 단계, 개념 건축 단계, 세부 건축 단계

아키텍처 설계의 4가지 요소: 요구 사항 구조화, 제약 조건의 영향 분석, 중요 품질 결정, 주요 기능 결정

개념적 아키텍처의 3단계: 핵심 기능을 기반으로 한 예비 설계, 시스템 상위 수준 분할, 비기능적 요구 사항 분석

개선된 아키텍처의 5가지 보기: 논리적 보기, 개발 보기, 운영 보기, 물리적 보기, 데이터 보기

A 통과 링크: 비기능적 요구사항 고려

참고자료

1. "1차 아키텍처 설계 가이드"

저자: JD Retail Feng Xiaotao

출처 : JD Cloud 개발자 커뮤니티 전재시 출처를 밝혀주세요

건축설계를 잘하려면 어떻게 해야 하나요?건축설계에 있어서 지켜야 할 규칙이 있나요? | JD클라우드 기술팀