12가지 요소 아키텍처
12요소 앱 방법론이란 무엇인가요?
엄밀히 말해서 건축 원칙의 집합은 아니지만 12가지 요소 앱 이 방법론은 클라우드 기반 애플리케이션을 위한 모범 사례 모음입니다.
어떻게해야합니까? Mendix 런타임 지원 12가지 클라우드 네이티브 앱?
아래 섹션에서는 다음 방법을 설명합니다. Mendix 12요소 앱 방법론적 요구 사항을 준수합니다.
-
코드베이스
기본적으로, 당신이 만든 모든 애플리케이션의 소스 코드는 Mendix 에 저장됩니다 Mendix Team Server 코드 저장소. 앱을 배포하면 Team Server에 저장된 모델을 기반으로 패키지가 생성됩니다. 그런 다음 이 패키지는 수용 또는 프로덕션과 같은 다양한 환경에 배포됩니다.
-
종속성
앱의 모듈에서 사용하는 모든 종속성(모듈 및 라이브러리 등)은 앱 모델의 일부입니다. 즉, 환경에 도구에 대한 암묵적 종속성이 존재하지 않습니다. 이를 통해 안정적인 배포가 보장됩니다.
-
구성
구성 요구 사항은 상수를 통해 애플리케이션 모델에서 정의됩니다. 이러한 값은 환경에서 배포 시 지정하거나 CI/CD 파이프라인에서 호출되는 API를 통해 지정할 수 있습니다. 실제 구성 값은 모델의 일부가 되지 않으므로 앱 모델을 변경하지 않고도 동일한 배포 패키지를 모든 환경에 배포할 수 있습니다.
-
지원 서비스
모든 외부 요구 사항(예: 애플리케이션 데이터를 저장하는 데이터베이스)과 애플리케이션에서 호출할 서비스는 배포 시점에 구성할 수 있습니다. 이전 요구 사항과 마찬가지로, 이는 동일한 테스트된 배포 패키지를 모델 변경 없이 모든 상황에서 모든 백업 서비스와 함께 사용할 수 있음을 보장합니다.
-
빌드, 릴리스, 실행
프로덕션 환경에서 코드를 변경할 수 있다면 애플리케이션의 확장이 예측 불가능하고 신뢰할 수 없게 될 것입니다. 또한 디버깅과 문제 해결도 더 어려워질 것입니다. 이 문제를 피하려면 Mendix 플랫폼은 빌드와 실행 단계를 명확하게 구분합니다.
. Mendix 포털, 먼저 모델에서 패키지를 빌드해야 하며, 그런 다음 환경에 배포할 수 있습니다. 프로덕션에서 코드를 변경하려면 모델을 수정한 다음 새 패키지를 빌드해야 합니다. Mendix 또한 애플리케이션을 빌드하고 배포하기 위한 API를 제공하므로 이 접근 방식을 사용자 정의 CI/CD 파이프라인에 통합할 수 있습니다.
-
프로세스
따라서 Mendix 런타임은 완전히 무상태로 설계되었습니다. 데이터베이스를 통해 데이터를 공유하여 쉬운 확장성과 복원력을 보장합니다.
-
포트 바인딩
다양한 환경에서 동일한 앱을 쉽게 확장하고 실행하려면 앱이 독립형이어야 합니다(즉, 클라이언트 요청을 수신하는 위치를 구성할 수 있어야 함). Mendix 이런 방식으로 앱을 구성하면 Docker나 Kubernetes와 같은 기반 플랫폼 즉 서비스(PaaS)에서 앱을 호스팅하는 컨테이너 수를 쉽게 확장할 수 있습니다.
-
동시성
Mendix Java 스레드와 프로세스를 조합하여 최종 사용자의 요구에 맞게 확장합니다. Twelve-Factor App 방법론은 프로세스를 통해 확장해야 한다는 필요성을 강조합니다. 그렇지 않으면 확장 요구 사항이 하나의 Java 가상 머신(JVM)이 지원할 수 있는 최대치로 제한됩니다(수직적 확장). 프로세스 확장도 지원함으로써 추가 리소스를 항상 쉽게 추가할 수 있습니다(수평적 확장).
-
일회용
Mendix 런타임 인스턴스는 필요에 따라 중지하고 시작할 수 있습니다. 다중 인스턴스 환경에서 사용자는 일반적으로 하나의 런타임 인스턴스가 다시 시작되었는지 알아차리지 못합니다. 이것의 이점은 수평적 확장성이 더 간단하고 빠르며, 새로운 버전이나 새로운 구성의 배포가 더 빨라진다는 것입니다.
-
개발/생산 패리티
품질을 보장하기 위해 테스트 환경에 배포된 앱은 프로덕션 환경에서도 유사하게 작동해야 합니다. Mendix 클라우드, 모든 환경은 동일한 방식으로 프로비저닝됩니다. 유일한 차이점은 구성, 데이터 및 애플리케이션입니다. 데이터는 백업 및 복원을 통해 환경 간에 이동하여 대표적 데이터로 테스트를 보장할 수 있습니다.
-
로그
Mendix 클라우드는 Cloud Foundry Firehose를 사용하여 모든 애플리케이션의 모든 로그 이벤트를 수집합니다. 이는 다음에서 보고 필터링할 수 있습니다. Mendix 문.
-
관리 프로세스
동기화 문제를 피하기 위해 Twelve-Factor App 방법론은 애플리케이션 코드와 함께 관리 코드를 제공하는 것을 권장합니다. Mendix 이 관행을 강제하므로 앱 환경에서 실행되는 유일한 코드는 앱의 일부인 코드입니다. 즉, 관리자 코드를 모델의 일부로 만들어야 합니다. 사용자는 종종 앱이 시작된 후 실행될 마이크로플로를 구현하거나 관리자 작업을 트리거하는 API를 생성하여 관리자 페이지에서 관리자 로직으로 이를 구현합니다.