배경
이 회사는 오랜 역사와 많은 양의 오래된 프로젝트를 가지고 있습니다.전통적인 오래된 프로젝트의 특성 외에도 프로젝트는 백엔드 템플릿에 크게 의존하고 각 페이지는 템플릿에 해당합니다.스타트업은 도커에 의존합니다. 프로젝트가 지속적으로 업데이트되고 반복됨에 따라 프로젝트 구조가 점점 더 복잡해지고 유지 관리 비용이 점점 더 높아져 일련의 문제가 발생합니다...
Monolith 앱의 문제
프로젝트 크기가 너무 크고 복제 시간이 깁니다.
구조가 혼란스럽고 결합도가 높으며 유지 관리가 어렵습니다.
긴 빌드 시간 문제 해결 및 복잡한 웹팩 구성 유지 필요
여러 사람이 동일한 프로젝트를 개발할 때 릴리스 배포가 혼동되기 쉽습니다.
기술 스택 반복 비용이 높습니다.
분할하는 방법?
거석 응용 프로그램이므로 생각하기 쉬운 변환 솔루션은 여러 하위 응용 프로그램으로 분할하고 분할 및 정복하는 것입니다.일반적으로 다음과 같은 분할 솔루션이 있습니다.
기술로 나누기
비즈니스 또는 페이지로 분할
권한으로 분할
변경 빈도에 따라 프로젝트를 분할하는 것은 권한 제한 및 불일치 기술 스택 문제가 없습니다.분명히 이 두 가지 분할 방법은 적합하지 않습니다.비즈니스 시나리오에서 프로젝트는 여러 페이지로 구성됩니다 .
전통적인 솔루션
당신은 repo를 말한다
그것은 간단하고 조잡하지만 많은 문제가 있는 여러 창고로 직접 분할하는 것입니다.
관리 및 디버깅이 어려움
여러 개의 git 웨어하우스를 관리하는 것은 당연히 번거로운 일입니다. 유사한 기능을 가진 모듈에 대해 여러 창고로 분할하면 여러 사람이 협업하거나 독립적인 개발을 위해 여러 창고를 열어야 합니다.
vscode는 작업 공간을 통해 다중 창고 관리 문제를 해결하지만 다중 사용자 협업 시나리오에서는 모든 사람의 환경 구성이 일관적임을 보장할 수 없습니다.
Npm을 통해 설치된 공유 패키지의 경우 컴파일된 코드를 디버깅할 수 없거나 npm을 연결할 때마다 종속 하위 패키지를 디버깅할 방법이 없습니다.
지점 관리 혼란
A와 B 두 개의 프로젝트에 대해 웨어하우스가 제공되고 프로젝트 B가 프로젝트 A와 호환되지 않는 기능 b의 개발을 우선시하는 경우 이 기능을 지원하기 위해 기능/b의 분기를 이 웨어하우스에서 열어야 합니다. 트렁크에서 프로젝트 A로의 향후 동기화에서 병합됩니다.
분기해야 하는 구성 요소가 더 많아지고 이들 사이에 종속성이 생기면 분기 관리의 복잡성이 기하급수적으로 증가합니다.
복잡한 종속성
독립적인 웨어하우스 간의 컴포넌트 버전 번호 유지는 수동 작업이 필요하며, 소스 코드가 함께 있지 않기 때문에 종속성을 전체적으로 분석하고 버전 번호의 종속성을 자동으로 관리할 수 있는 방법이 없습니다. 3자 종속성의 버전이 일치하지 않을 수 있습니다. 독립 패키지에는 독립적인 개발 환경이 있고 하위 모듈의 버전이 기본 프로젝트와 완전히 일치하는지 확인하기 어렵고 실행 결과가 일치하지 않을 위험이 있습니다.
많은 공간을 차지
정상적인 상황에서 회사의 비즈니스 프로젝트는 백본이 하나뿐이고, multi-git repo 방식은 저장 공간이 많이 낭비됩니다. 외장하드가 없는 학생 사용하지 않는 프로젝트 아래에 있는 node_modules를 정기적으로 정리하는 것도 번거로운 일입니다.
팀워크에 좋지 않음
대규모 프로젝트에서는 수백 개의 2차 패키지를 사용할 수 있습니다. 2차 패키지마다 유지 관리 빈도, 권한 및 창고 위치가 서로 다릅니다. 기본 창고는 서로 다른 방식으로 의존합니다. 패키지 중 하나가 비정상적으로 변경되면 전체 프로젝트에 영향을 미치고 에너지가 제한되어 메인 창고만 바라보고 겸손한 2차 패키지 출시에 자주 빠집니다.
코드는 재사용할 수 없습니다
우리 프로젝트는 백엔드 의존도가 높다고 말씀드렸는데 직접 여러 프로젝트로 분할하면 백엔드 코드도 여러 웨어하우스에 존재하게 되지만 전체 변환으로 인해 프런트엔드에만 집중하고 싶습니다. 백엔드 동급생에게 둔감합니다. 분명히 이런 식으로 할 수 없습니다
현대적인 솔루션
모노레포
프로젝트 웨어하우스(repo)에서 여러 개의 모듈/패키지(패키지)를 관리하는 것을 말하며 프로젝트 코드를 관리하는 방식으로 모듈별로 repo를 구축하는 일반적인 방식과 다릅니다.
이점:
여러 프로젝트에 대한 일련의 구성을 배치로 구축하고 별도로 릴리스할 수 있습니다.
개발 단계에서 프로젝트를 앞뒤로 전환할 필요가 없습니다.
게시하지 않고 로컬에서 코드를 공유하고 공용 패키지를 디버그할 수 있습니다.
단순화된 종속성 관리, 모든 프로젝트에 대해 하나의 공통 버전 번호만 있기 때문에 종속성에 대한 버전 번호를 지정할 필요가 없습니다.
재사용 가능성에 따라 다름
단점:
창고 부피가 크다
커밋 레코드는 혼동되기 쉽습니다.
창고이기 때문에 하위 프로젝트에 대한 별도의 권한 처리가 쉽지 않음
자동 릴리스에 적합하지 않음 여러 프로젝트가 일반적으로 독립적인 릴리스이므로 통합이 쉽지 않음
종속성을 직접 관리해야 함
제출 내역은 혼동되기 쉬우므로 직접 관리해야 함
적용 가능한 장면:
React 관련 및 Angular 관련과 같이 응집력이 강한 도구 및 프레임 워크 프로젝트에 적합합니다.일반적으로 릴리스에는 일련의 종속성과 동시 업데이트가 있으며 동시에 이러한 종류의 프로젝트 개발은 제어 가능합니다. 마음대로 확장되지 않으므로 라이브러리의 볼륨도 제어할 수 있습니다.
적용할 수 없는 시나리오:
볼륨을 제어할 수 없는 항목
권한 관리가 필요한 프로젝트
하위 프로젝트의 기술 스택이 크게 다른 시나리오에는 적용할 수 없습니다.
비즈니스 시나리오로 돌아가서 다양한 하위 응용 프로그램 구성의 차이로 인해 구성 구성 집합을 공유할 필요가 없으며 프로젝트 크기를 제어할 수 없고 현재 전체 릴리스만 지원하는 등의 요소가 있으므로 수정 계획이 채택되지 않았습니다.
git 하위 모듈 + 덤 저장소
git 하위 모듈이란 무엇입니까?
Git 리포지토리를 다른 Git 리포지토리의 하위 디렉터리로 유지할 수 있습니다. 이렇게 하면 다른 리포지토리를 프로젝트에 복제하고 커밋을 별도로 유지할 수 있습니다. 하위 리포지토리에는 .git 디렉터리를 포함하여 전체 전체 git 리포지토리가 포함됩니다.
우리 회사도 이 솔루션을 채택하고 있는데 시나리오에서 Jushi 프로젝트의 각 페이지를 독립적인 프로젝트로 분할한 다음 모든 페이지가 의존하는 기본 서비스, 공용 구성 요소 및 공용 메서드를 하위 프로젝트로 추출합니다. , 하위 창고를 수정할 때 프로젝트를 전환할 필요가 없습니다 cd ${子仓库目录}.
이점
코드는 재사용 가능하고 디버깅 비용이 낮습니다. 하위 모듈을 분할한 후 npm 패키지를 설치하지 않고 공통 코드 세트를 공유하고 로컬에서 직접 디버그할 수도 있습니다.
디스어셈블된 프로젝트에서 직접 서브모듈의 코드를 실행할 수 있습니다. 우리 사업, 단지 하위 창고는 일련의 백엔드 템플릿 및 도커 구성을 유지 관리합니다. 하위 창고의 호스트 창고를 실행할 때
cd ${子仓库目录}컨테이너를 실행한 다음 호스트 창고의 포트를 프록시하기 만 하면 됩니다. 컨테이너에서 실행되는 포트 8083 기본 서비스(백엔드 코드)의 고유성
불리
복제 시 하위 프로젝트를 추가로 복제해야 하며 하위 창고의 크기가 너무 크면 복제 시간이 너무 길어집니다.
하위 프로젝트 수정 시 하위 프로젝트의 저장소로 전환해야 합니다.
npm 패키지의 형태와 비교할 때 하위 모듈의 코드가 수정되는 한 전체 본문에 영향을 미치며 위험이 있습니다.
코드를 재사용할 수 있는 솔루션만 제공하며 기타 기존의 다중 창고 문제는 여전히 존재합니다.
webpack5 모듈 연합(Module Federation)
퍼블릭 모듈을 추출하는 솔루션이기도 하며, 각각의 서브애플리케이션은 별도로 구축되고, 메인애플리케이션은 런타임에 컨테이너를 통해 원격 모듈을 로드하는 즉, 서브애플리케이션의 구축이다. 기본 응용 프로그램은 현재 버전의 하위 응용 프로그램의 최신 리소스를 자동으로 사용하므로 온라인 배포 프로젝트가 런타임에 다른 온라인 배포 프로젝트의 구성 요소를 로드할 수 있습니다.
근본적인
이후에 로드된 일부 모듈을 웹팩에서 청크 패키지로 패키징한 다음 이 모듈을 사용할 때 지연 로드할 수 있다고 상상해보십시오.이 상황은 일반적으로 동일한 프로젝트에서 수행됩니다.
그렇다면 구성 요소와 그 종속성을 프로젝트 A의 청크 패키지로 패키징하고, 프로젝트 B의 합의된 주소에 따라 지금 막 프로젝트 A의 청크 패키지를 비동기적으로 가져와서 사용할 수 있습니까? 답은 모듈 연합입니다.
기본 사상
원격 구성 요소 공급자를 원격 측이라고 하고 원격 구성 요소 사용자를 호스트 측이라고 합니다.
프로젝트는 원격 및 호스트가 될 수 있고 여러 다른 프로젝트의 구성 요소를 사용할 수 있으며 다른 여러 프로젝트에 다른 구성 요소를 제공할 수 있습니다.
어떻게 작동합니까?
예: 프로젝트는 다음과 같이 작업 주문 워크벤치 페이지를 도입해야 합니다. 
원격 구성으로 작업 주문 워크벤치
원격 종료(작업 주문 워크벤치)
(1) 두 프로젝트 모두 vue3 + vite 솔루션을 사용하므로 vite-plugin-federation 플러그인을 사용하는 것이 최선의 선택입니다. 먼저 다음과 같이 호스트 측과 원격 측에 플러그인을 설치해야 합니다.
yarn add @originjs/vite-plugin-federation -D(2) 플러그인에서 제공해야 하는 컴포넌트를 등록하고, 공유해야 하는 3자 의존성 제공
(3) 구성 완료 후
해당 엔트리 파일, 청크 파일 및 종속 패키지 파일은 원격 측에서 패키징 후 생성됩니다.
호스트 측(IM 및 전화 워크벤치)
(1) 플러그인 구성, 원격 패키지 주소 설정
(2) 컴포넌트 참조 및 등록 main.ts 파일은 다음과 같다 
. 참고로 ticket-share는 호스트 측에서 vite 플러그인에 등록된 패키지 이름이고, Detail은 노출된 원격 측에서 선언된 컴포넌트 이름이다. (필드 노출). 전역 등록 외에도 참조가 필요한 모든 곳에서 참조가 가능합니다.
(3) 컴포넌트의 사용은
필요한 곳에 도입하여 사용하며, 사업 여건에 따라 props를 전달합니다.props의 사용은 일반 컴포넌트와 다르지 않습니다. 
이 시점에서 우리는 모든 구성을 완료했으며 그 후에는 온라인으로 패키징하고 실행하기만 하면 됩니다.
온라인 디버깅 방법
Redirector 브라우저 확장 사용:
마이크로앱의 원격 항목 파일이 https://my-federated-app.com/federated/my-micro-app/remoteEntry.js에 있다고 가정한 다음 로컬 개발 서버를 사용하여 이 앱을 처리하면 /federated/my-micro-app/ 패턴이 포함된 모든 요청을 개발 서버가 실행 중인 http://localhost:3000으로 리디렉션할 수 있습니다.
이점
낮은 업데이트 비용: 공개 패키지의 도입은 패키지 및 릴리스가 필요하지 않습니다.npm 패키지와 비교하여 이 패키지를 사용하는 프로젝트의 종속 버전을 하나씩 업그레이드할 필요가 없습니다.높은 페이지 수준 구성 요소
낮은 기술 비용: 웹팩 구성만 수정하면 됨
지연 로딩 지원: 필요할 때만 모듈을 로드하는 번들로 웹 성능을 향상시킵니다.
반복 종속성 감소: 가져온 공개 코드는 호스트 환경의 종속성을 직접 사용할 수 있습니다.
유연한 분할, 높은 수준의 세분화: git 하위 모듈과 비교하여 단일 페이지 애플리케이션 또는 구성 요소에 세분화될 수 있습니다. 즉, iframe을 대체할 수도 있습니다.
불리
스타일 분리 메커니즘이 없으면 기본 및 하위 애플리케이션의 스타일 오염을 일으키기 쉽습니다.
로컬 개발은 번거로운 여러 포트 서비스를 열어야 합니다.
공유 패키지의 유지 비용이 높습니다: 구성 요소가 공유하는 모든 패키지를 찾아야 합니다. 공유는 때때로 필수입니다. 일부 패키지가 누락되면 페이지 오류 또는 충돌이 발생할 수 있습니다. 동일한 라이브러리가 내에서 유지 관리되어야 하는 경우가 있습니다. 합의된 버전 범위 내부에서 때때로 너무 오래되었거나 너무 새로운 패키지는 로드할 때 오류를 보고합니다(단, 사용자는 공유 여부를 선택할 수 있음).
청크 분할의 합리적인 계획이 필요합니다.청크를 너무 많이 분할하면 요청 청크 수가 너무 많아지고 동시성이 너무 커집니다.여러 모듈이 하나를 공유하면 그 안에 포함된 모듈의 버전
remoteEntry이 별도로 관리
비즈니스 시나리오로 돌아가서 모듈 연합은 JS 청크만 재사용할 수 있기 때문에 우리가 의존하는 백엔드 서비스에 재사용할 수 없으므로 기본 솔루션으로 사용할 수 없지만 현재 코드에 존재하는 문제를 해결할 수 있습니다. 재사용 방법: 각 하위 프로젝트는 submodule. 각 응용 프로그램에서 이러한 공용 구성 요소 및 메소드에 사용됩니다.응용 프로그램의 재컴파일 및 패키징은 분명히 효율성에 영향을 미칩니다.모듈 연합의 특성을 사용하여 수정이 부작용이 없다는 전제하에 콘텐츠를 직접 시작할 수 있습니다 submodule. 하위 응용 프로그램은 인식하지 못하지만 Js chunkcdn 링크가 가리키는 콘텐츠가 변경되었습니다.
마이크로 프론트엔드
마이크로프론트엔드는 마이크로서비스와 유사한 아키텍처로 마이크로서비스의 개념을 브라우저 측, 즉 웹 애플리케이션을 단일 단일 애플리케이션에서 여러 개의 작은 프론트엔드 애플리케이션을 하나로 통합하는 애플리케이션으로 변환합니다. 마이크로 프런트엔드 아키텍처는 프레임워크와 관련이 없으며 각 마이크로 애플리케이션을 독립적으로 개발, 실행 및 배포할 수 있습니다.
첸쿤
Qiankun은 시장에서 흔히 볼 수 있는 마이크로 프론트엔드 프레임워크입니다.Qiankun은 이 방법을 사용하여
대체 HTML Entry하고 최적화합니다.
HTML 항목이란 무엇입니까?
서브애플리케이션의 HTML을 직접 엔트리로 출력하는 것으로, 메인 프레임은 html을 가져오는 것을 통해 서브애플리케이션의 정적 자원을 획득함과 동시에 HTML 문서를 자식 노드로 삽입할 수 있다. 메인 프레임의 컨테이너.
마이크로 프런트엔드 변환을 위해 qiankun을 사용한 후 페이지는 기본 응용 프로그램과 여러 하위 응용 프로그램으로 분할되며 각각은 독립적인 샌드박스 환경에서 실행됩니다.
다음과 같은 특징이 있습니다.
독립성: 마이크로 프런트엔드의 기본 애플리케이션과 각 하위 애플리케이션은 독립적으로 개발 및 배포되며 마이크로 프런트엔드의 하위 애플리케이션은 어느 정도 기본 애플리케이션과 독립적으로 실행될 수 있습니다.
샌드박스 격리: 하위 애플리케이션에는 자체 독립 런타임이 있으며 하위 애플리케이션 간의 상태는 공유되지 않습니다. 즉, 하위 애플리케이션 간에 CSS와 JS는 서로 독립적이며 다른 하위 애플리케이션에 의해 오염되지 않습니다.
프레임워크 독립적: 기존 마이크로 프런트엔드 프레임워크의 구현에서 기본 애플리케이션은 하위 애플리케이션이 빌드된 후에만 번들을 로드하기 때문에 다른 프레임워크를 사용하여 하위 애플리케이션을 개발할 수 있습니다.
상태 공유: 하위 앱은 기본 앱의 상태를 공유할 수 있습니다.
다른 솔루션에 비해 가장 큰 장점은 샌드박스 격리가 프레임워크와 관련이 없다는 것입니다.
해당 장면
모놀리식 애플리케이션의 특정 부분을 기술 스택에서 점진적으로 업그레이드하거나 리팩토링해야 하는 경우
사용자 경험과 리소스 활용도를 향상시키기 위해 프런트엔드 애플리케이션의 동적 로딩 및 언로딩을 구현해야 합니다.
각 프런트 엔드 애플리케이션 간에 스타일 격리 및 js 샌드박스를 보장해야 합니다.
각각의 기술 스택 및 개발 방법을 희생하지 않고 여러 프런트 엔드 애플리케이션을 전체로 통합해야 함
해당 없음
프런트 엔드의 복잡성이 낮고 애플리케이션 간의 강력한 비즈니스 연결 또는 데이터 종속성, 빈번한 통신 또는 공유 상태가 필요하지 않습니다.
우리 프로젝트 자체가 다중 페이지 프로젝트이기 때문에 자연스럽게 HTML Entry를 지원하고 여러 개의 작은 응용 프로그램을 통합하는 대신 단일 응용 프로그램을 여러 개의 작은 응용 프로그램으로 분할하므로 기술 스택이 일치하지 않는 문제가 없습니다.
요약하다
어떤 솔루션이 완벽하든 구체적으로 적용할 솔루션은 비즈니스 시나리오 및 개인 사례와 결합하여 선택해야 합니다.
참고
https://xie.infoq.cn/article/cab16528dc0ecf3514fdfd492
https://www.burhanuday.com/blog/2023/03/devx-and-deployments-in-a-module-federated-micro-frontend
- 끝 -
Qi Wu 극단 소개
Qi Wu Troupe는 360 Group의 가장 큰 프런트 엔드 팀이며 그룹을 대신하여 W3C 및 ECMA 구성원(TC39)의 작업에 참여합니다. Qi Wu Troupe는 인재 양성을 중시하고 엔지니어, 강사, 번역가, 비즈니스 인터페이스 담당자 및 팀 리더와 같은 다양한 개발 방향을 직원이 선택할 수 있으며 해당 기술, 전문, 일반 및 리더십 교육 과정을 제공합니다. Qi Dance Troupe는 개방적이고 재능을 추구하는 태도로 Qi Dance Troupe에 관심을 갖고 합류하기 위해 모든 종류의 뛰어난 재능을 환영합니다.
