팁 (조언)
이 콘텐츠는 .NET Docs 또는 오프라인으로 읽을 수 있는 다운로드 가능한 무료 PDF로 제공되는 컨테이너화된 .NET 애플리케이션용 .NET 마이크로 서비스 아키텍처인 eBook에서 발췌한 내용입니다.
이 섹션에서는 가상의 서버 쪽 엔터프라이즈 애플리케이션 개발에 중점을 둡니다.
애플리케이션 사양
가상 애플리케이션은 비즈니스 논리를 실행하고 데이터베이스에 액세스한 다음 HTML, JSON 또는 XML 응답을 반환하여 요청을 처리합니다. 애플리케이션은 SPA(단일 페이지 애플리케이션), 기존 웹앱, 모바일 웹앱 및 네이티브 모바일 앱을 실행하는 데스크톱 브라우저를 포함하여 다양한 클라이언트를 지원해야 합니다. 애플리케이션은 타사에서 사용할 API를 노출할 수도 있습니다. 또한 마이크로 서비스 또는 외부 애플리케이션을 비동기적으로 통합할 수 있어야 하므로 부분 오류가 발생하는 경우 마이크로 서비스의 복원력에 도움이 됩니다.
애플리케이션은 다음과 같은 유형의 구성 요소로 구성됩니다.
프레젠테이션 구성 요소입니다. 이러한 구성 요소는 UI를 처리하고 원격 서비스를 사용하는 역할을 담당합니다.
도메인 또는 비즈니스 논리 이 구성 요소는 애플리케이션의 도메인 논리입니다.
데이터베이스 액세스 논리입니다. 이 구성 요소는 데이터베이스 액세스(SQL 또는 NoSQL)를 담당하는 데이터 액세스 구성 요소로 구성됩니다.
애플리케이션 통합 논리입니다. 이 구성 요소에는 메시지 브로커를 기반으로 하는 메시징 채널이 포함됩니다.
특정 하위 시스템에는 다른 하위 시스템보다 더 많은 확장성이 필요하기 때문에 애플리케이션의 수직 하위 시스템이 자율적으로 확장되도록 허용하면서 높은 확장성이 필요합니다.
애플리케이션은 여러 인프라 환경(여러 퍼블릭 클라우드 및 온-프레미스)에 배포할 수 있어야 하며, 이상적으로 플랫폼 간이어야 하며, Linux에서 Windows로 쉽게 이동할 수 있어야 합니다(또는 그 반대의 경우도 마찬가지).
개발 팀 컨텍스트
또한 애플리케이션의 개발 프로세스에 대해 다음을 가정합니다.
애플리케이션의 여러 비즈니스 영역에 중점을 둔 여러 개발 팀이 있습니다.
새 팀 구성원은 신속하게 생산성을 높일 수 있어야 하며 애플리케이션을 쉽게 이해하고 수정할 수 있어야 합니다.
애플리케이션은 장기적으로 진화하고 끊임없이 변화하는 비즈니스 규칙을 갖게 됩니다.
좋은 장기 유지 관리 기능이 필요합니다. 즉, 나중에 새로운 변경 내용을 구현할 때 민첩성을 유지하면서 다른 하위 시스템에 미치는 영향을 최소화하면서 여러 하위 시스템을 업데이트할 수 있습니다.
애플리케이션의 지속적인 통합 및 지속적인 배포를 연습하려고 합니다.
애플리케이션을 발전시키는 동안 새로운 기술(프레임워크, 프로그래밍 언어 등)을 활용하려고 합니다. 새 기술로 전환할 때 애플리케이션을 완전히 마이그레이션하는 것은 비용이 많이 들고 애플리케이션의 예측 가능성과 안정성에 영향을 주므로 원하지 않습니다.
아키텍처 선택
애플리케이션 배포 아키텍처는 무엇인가요? 애플리케이션 명세와 개발 컨텍스트는 애플리케이션을 협업 마이크로서비스와 컨테이너 형태의 자율 하위 시스템으로 분해하여 설계해야 함을 강력하게 제안합니다. 여기서 마이크로서비스는 컨테이너 역할을 합니다.
이 방법에서 각 서비스(컨테이너)는 응집력 있고 좁게 관련된 함수 집합을 구현합니다. 예를 들어 애플리케이션은 카탈로그 서비스, 주문 서비스, 장바구니 서비스, 사용자 프로필 서비스 등의 서비스로 구성될 수 있습니다.
마이크로 서비스는 HTTP(REST)와 같은 프로토콜을 사용하지만, 특히 통합 이벤트로 업데이트를 전파할 때 가능하면 비동기적으로(예: AMQP 사용) 통신합니다.
마이크로 서비스는 서로 독립적으로 컨테이너로 개발 및 배포됩니다. 이 방법은 개발 팀이 다른 하위 시스템에 영향을 주지 않고 특정 마이크로 서비스를 개발하고 배포할 수 있음을 의미합니다.
각 마이크로 서비스에는 자체 데이터베이스가 있으므로 다른 마이크로 서비스에서 완전히 분리할 수 있습니다. 필요한 경우 CQRS(명령 및 쿼리 책임 분리)에서 처리되는 것처럼 애플리케이션 수준 통합 이벤트(논리 이벤트 버스를 통해)를 사용하여 서로 다른 마이크로 서비스의 데이터베이스 간의 일관성을 달성합니다. 따라서 비즈니스 제약 조건은 여러 마이크로 서비스와 관련 데이터베이스 간의 최종 일관성을 수용해야 합니다.
eShopOnContainers: 컨테이너를 사용하여 배포된 .NET 및 마이크로 서비스에 대한 참조 애플리케이션
알 수 없는 가상의 비즈니스 도메인에 대해 생각하는 대신 아키텍처와 기술에 집중할 수 있도록, 잘 알려진 비즈니스 도메인, 즉 제품 카탈로그를 제시하고, 고객의 주문을 받고, 재고를 확인하고, 다른 비즈니스 기능을 수행하는 간소화된 전자상거래(전자상거래) 애플리케이션을 선택했습니다. 이 컨테이너 기반 애플리케이션 소스 코드는 eShopOnContainers GitHub 리포지토리에서 사용할 수 있습니다.
애플리케이션은 여러 저장소 UI 프런트 엔드(웹 애플리케이션 및 네이티브 모바일 앱)와 여러 API 게이트웨이를 내부 마이크로 서비스에 대한 통합 진입점으로 사용하는 모든 필요한 서버 쪽 작업에 대한 백 엔드 마이크로 서비스 및 컨테이너를 포함하여 여러 하위 시스템으로 구성됩니다. 그림 6-1은 참조 애플리케이션의 아키텍처를 보여줍니다.
그림 6-1. eShopOnContainers는 개발 환경에 대한 애플리케이션 아키텍처를 참조합니다.
위의 다이어그램은 모바일 및 SPA 클라이언트가 단일 API 게이트웨이 엔드포인트와 통신한 다음 마이크로 서비스와 통신한다는 것을 보여줍니다. 기존 웹 클라이언트는 API 게이트웨이를 통해 마이크로 서비스와 통신하는 MVC 마이크로 서비스와 통신합니다.
호스팅 환경. 그림 6-1에서는 단일 Docker 호스트 내에 여러 컨테이너가 배포된 것을 볼 수 있습니다. docker-compose up 명령을 사용하여 단일 Docker 호스트에 배포할 때도 해당됩니다. 그러나 오케스트레이터 또는 컨테이너 클러스터를 사용하는 경우 아키텍처 섹션의 앞부분에서 설명한 대로 각 컨테이너가 다른 호스트(노드)에서 실행 중일 수 있으며 모든 노드에서 여러 컨테이너를 실행할 수 있습니다.
통신 아키텍처. eShopOnContainers 애플리케이션은 기능 작업의 종류(쿼리 및 업데이트 및 트랜잭션)에 따라 두 가지 통신 유형을 사용합니다.
API 게이트웨이를 통한 Http 클라이언트-마이크로 서비스 통신 이 방법은 쿼리 및 클라이언트 앱에서 업데이트 또는 트랜잭션 명령을 수락하는 경우에 사용됩니다. API 게이트웨이를 사용하는 방법은 이후 섹션에서 자세히 설명합니다.
비동기 이벤트 기반 통신입니다. 이 통신은 이벤트 버스를 통해 마이크로 서비스 간에 업데이트를 전파하거나 외부 애플리케이션과 통합하기 위해 발생합니다. 이벤트 버스는 RabbitMQ와 같은 메시징 브로커 인프라 기술을 사용하거나 Azure Service Bus, NServiceBus, MassTransit 또는 Brighter와 같은 상위 수준(추상화 수준) 서비스 버스를 사용하여 구현할 수 있습니다.
애플리케이션은 컨테이너 형식의 마이크로 서비스 집합으로 배포됩니다. 클라이언트 앱은 API 게이트웨이에서 게시한 공용 URL을 통해 컨테이너로 실행되는 마이크로 서비스와 통신할 수 있습니다.
마이크로 서비스당 데이터 주권
모든 SQL Server 데이터베이스는 단일 컨테이너로 배포되지만 샘플 애플리케이션에서 각 마이크로 서비스는 자체 데이터베이스 또는 데이터 원본을 소유합니다. 이 디자인 결정은 개발자가 GitHub에서 코드를 쉽게 가져오고, 복제하고, Visual Studio 또는 Visual Studio Code에서 열 수 있도록 하기 위한 것이었습니다. 또는 .NET CLI 및 Docker CLI를 사용하여 사용자 지정 Docker 이미지를 쉽게 컴파일한 다음 Docker 개발 환경에서 배포하고 실행할 수 있습니다. 어느 쪽이든, 데이터 원본에 컨테이너를 사용하면 개발자가 인프라(클라우드 또는 온-프레미스)에 대한 종속성이 어려운 외부 데이터베이스 또는 다른 데이터 원본을 프로비전하지 않고도 몇 분 만에 빌드하고 배포할 수 있습니다.
실제 프로덕션 환경에서 고가용성 및 확장성을 위해 데이터베이스는 클라우드 또는 온-프레미스의 데이터베이스 서버를 기반으로 하지만 컨테이너에는 기반하지 않아야 합니다.
따라서 마이크로 서비스(그리고 이 애플리케이션의 데이터베이스)에 대한 배포 단위는 Docker 컨테이너이며, 참조 애플리케이션은 마이크로 서비스 원칙을 수용하는 다중 컨테이너 애플리케이션입니다.
추가 리소스
- eShopOnContainers GitHub 리포지토리. 참조 애플리케이션의 소스 코드
https://aka.ms/eShopOnContainers/
마이크로 서비스 기반 솔루션의 이점
이와 같은 마이크로 서비스 기반 솔루션에는 다음과 같은 많은 이점이 있습니다.
각 마이크로 서비스는 비교적 작으며 관리 및 발전하기 쉽습니다. 특히:
개발자가 이해하기 쉽고 높은 생산성으로 빠르게 시작할 수 있습니다.
컨테이너가 빠르게 시작되어 개발자의 생산성이 향상됩니다.
Visual Studio와 같은 IDE는 더 작은 프로젝트를 빠르게 로드하여 개발자의 생산성을 높일 수 있습니다.
각 마이크로 서비스는 다른 마이크로 서비스와 독립적으로 설계, 개발 및 배포할 수 있으며, 새 버전의 마이크로 서비스를 자주 배포하는 것이 더 쉽기 때문에 민첩성을 제공합니다.
애플리케이션의 개별 영역을 확장할 수 있습니다. 예를 들어 카탈로그 서비스 또는 장바구니 서비스를 스케일 아웃해야 하지만 주문 프로세스는 확장해야 할 수 없습니다. 마이크로 서비스 인프라는 모놀리식 아키텍처보다 스케일 아웃할 때 사용되는 리소스와 관련하여 훨씬 더 효율적입니다.
개발 작업을 여러 팀 간에 나눌 수 있습니다. 각 서비스는 단일 개발 팀에서 소유할 수 있습니다. 각 팀은 나머지 팀과 독립적으로 서비스를 관리, 개발, 배포 및 확장할 수 있습니다.
문제는 더 격리되어 있습니다. 한 서비스에 문제가 있는 경우 해당 서비스만 처음에 영향을 받습니다(잘못된 디자인이 사용되는 경우를 제외하고 마이크로 서비스 간의 직접 종속성 사용). 다른 서비스는 요청을 계속 처리할 수 있습니다. 반면, 모놀리식 배포 아키텍처에서 하나의 오작동하는 구성 요소는 특히 메모리 누수와 같은 리소스를 포함하는 경우 전체 시스템을 중단시킬 수 있습니다. 또한 마이크로 서비스의 문제가 해결되면 애플리케이션의 나머지 부분에 영향을 주지 않고 영향을 받는 마이크로 서비스만 배포할 수 있습니다.
최신 기술을 사용할 수 있습니다. 독립적으로 서비스를 개발하고 함께 실행할 수 있으므로(컨테이너 및 .NET 덕분에) 전체 애플리케이션에 대한 이전 스택 또는 프레임워크에 고정되는 대신 최신 기술 및 프레임워크를 신속하게 사용할 수 있습니다.
마이크로 서비스 기반 솔루션의 단점
이와 같은 마이크로 서비스 기반 솔루션에도 몇 가지 단점이 있습니다.
분산 애플리케이션. 애플리케이션을 배포하면 개발자가 서비스를 디자인하고 빌드할 때 복잡성이 더해집니다. 예를 들어 개발자는 HTTP 또는 AMQP와 같은 프로토콜을 사용하여 서비스 간 통신을 구현해야 하므로 테스트 및 예외 처리가 복잡해집니다. 또한 시스템에 대기 시간을 추가합니다.
배포 복잡성. 수십 가지의 마이크로 서비스 유형이 있고 높은 확장성이 필요한 애플리케이션(서비스당 많은 인스턴스를 만들고 여러 호스트에서 이러한 서비스의 균형을 유지할 수 있어야 합니다)은 IT 운영 및 관리를 위한 높은 수준의 배포 복잡성을 의미합니다. 마이크로 서비스 지향 인프라(예: 오케스트레이터 및 스케줄러)를 사용하지 않는 경우 이러한 복잡성이 비즈니스 애플리케이션 자체보다 훨씬 더 많은 개발 노력이 필요할 수 있습니다.
원자성 트랜잭션. 일반적으로 여러 마이크로 서비스 간의 원자성 트랜잭션은 불가능합니다. 비즈니스 요구 사항은 여러 마이크로 서비스 간의 최종 일관성을 수용해야 합니다. 자세한 내용은 idempotent 메시지 처리의 문제를 참조하세요.
전역 리소스 요구가 증가했습니다 (모든 서버 또는 호스트의 총 메모리, 드라이브 및 네트워크 리소스). 대부분의 경우 모놀리식 애플리케이션을 마이크로 서비스 접근 방식으로 바꾸면 새 마이크로 서비스 기반 애플리케이션에 필요한 초기 전역 리소스의 양이 원래 모놀리식 애플리케이션의 인프라 요구 사항보다 큽니다. 이 방법은 더 높은 수준의 세분성 및 분산 서비스를 사용하려면 더 많은 글로벌 리소스가 필요하기 때문입니다. 그러나 일반적으로 리소스 비용이 저렴하고 모놀리식 애플리케이션을 발전할 때 장기 비용에 비해 애플리케이션의 특정 영역을 확장할 수 있다는 이점을 감안할 때 리소스의 사용 증가는 일반적으로 대규모 장기 애플리케이션에 좋은 장단점입니다.
직접 클라이언트-마이크로 서비스 통신과 관련된 문제입니다. 수십 개의 마이크로 서비스가 있는 애플리케이션이 큰 경우 애플리케이션에 직접 클라이언트-마이크로 서비스 통신이 필요한 경우 어려움과 제한 사항이 있습니다. 한 가지 문제는 클라이언트의 요구 사항과 각 마이크로 서비스에서 노출하는 API 간의 잠재적 불일치입니다. 경우에 따라 클라이언트 애플리케이션은 인터넷을 통해 비효율적일 수 있고 모바일 네트워크를 통해 비실용적일 수 있는 UI를 작성하기 위해 여러 개의 별도 요청을 수행해야 할 수 있습니다. 따라서 클라이언트 애플리케이션에서 백 엔드 시스템으로의 요청을 최소화해야 합니다.
직접 클라이언트-마이크로 서비스 통신의 또 다른 문제는 일부 마이크로 서비스에서 웹 친화적이지 않은 프로토콜을 사용할 수 있다는 점입니다. 한 서비스는 이진 프로토콜을 사용할 수 있고 다른 서비스는 AMQP 메시징을 사용할 수 있습니다. 이러한 프로토콜은 방화벽에 친숙하지 않으며 내부적으로 가장 잘 사용됩니다. 일반적으로 애플리케이션은 방화벽 외부의 통신에 HTTP 및 WebSockets와 같은 프로토콜을 사용해야 합니다.
그러나 이러한 직접 클라이언트-서비스 접근 방식의 또 다른 단점은 해당 마이크로 서비스에 대한 계약을 리팩터링하기 어렵게 만든다는 것입니다. 시간이 지남에 따라 개발자는 시스템이 서비스로 분할되는 방식을 변경하려고 할 수 있습니다. 예를 들어 두 서비스를 병합하거나 서비스를 둘 이상의 서비스로 분할할 수 있습니다. 그러나 클라이언트가 서비스와 직접 통신하는 경우 이러한 종류의 리팩터링을 수행하면 클라이언트 앱과의 호환성이 손상됩니다.
아키텍처 섹션에서 설명한 것처럼 마이크로 서비스를 기반으로 복잡한 애플리케이션을 디자인하고 빌드할 때 더 간단한 직접 클라이언트-마이크로 서비스 통신 방식 대신 여러 세분화된 API 게이트웨이를 사용하는 것이 좋습니다.
마이크로 서비스를 분할합니다. 마지막으로, 마이크로 서비스 아키텍처에 대해 어떤 접근 방식을 취하든 엔드 투 엔드 애플리케이션을 여러 마이크로 서비스로 분할하는 방법을 결정하는 것이 또 다른 과제입니다. 가이드의 아키텍처 섹션에서 설명한 것처럼 몇 가지 기술과 방법을 사용할 수 있습니다. 기본적으로 다른 영역과 분리되고 하드 종속성이 적은 애플리케이션 영역을 식별해야 합니다. 대부분의 경우 이 방법은 사용 사례에 따라 분할 서비스에 맞춰집니다. 예를 들어 e-shop 애플리케이션에는 주문 프로세스와 관련된 모든 비즈니스 논리를 담당하는 주문 서비스가 있습니다. 다른 기능을 구현하는 카탈로그 서비스 및 장바구니 서비스도 있습니다. 이상적으로 각 서비스에는 작은 책임 집합만 있어야 합니다. 이 방법은 클래스에 적용되는 SRP(단일 책임 원칙)와 유사하며, 클래스에는 한 가지 이유만 변경해야 한다고 명시되어 있습니다. 그러나 이 경우 마이크로 서비스에 관한 것이므로 범위는 단일 클래스보다 큽니다. 무엇보다도 마이크로 서비스는 자체 데이터 원본에 대한 책임을 포함하여 종단 간 자율적이어야 합니다.
외부 및 내부 아키텍처 및 디자인 패턴
외부 아키텍처는 이 가이드의 아키텍처 섹션에 설명된 원칙에 따라 여러 서비스로 구성된 마이크로 서비스 아키텍처입니다. 그러나 각 마이크로 서비스의 특성과 선택한 상위 수준 마이크로 서비스 아키텍처와는 별개로, 각기 다른 마이크로 서비스에 대해 서로 다른 패턴에 따라 서로 다른 내부 아키텍처를 사용하는 것이 일반적이며 때로는 권장됩니다. 마이크로 서비스는 다양한 기술과 프로그래밍 언어를 사용할 수도 있습니다. 그림 6-2에서는 이러한 다양성을 보여 줍니다.
그림 6-2. 외부 및 내부 아키텍처 및 디자인
예를 들어 eShopOnContainers 샘플에서 카탈로그, 바구니 및 사용자 프로필 마이크로 서비스는 간단합니다(기본적으로 CRUD 하위 시스템). 따라서 내부 아키텍처와 디자인은 간단합니다. 그러나 정렬 마이크로 서비스와 같은 다른 마이크로 서비스가 있을 수 있습니다. 이는 더 복잡하고 도메인 복잡성이 높은 끊임없이 변화하는 비즈니스 규칙을 나타냅니다. 이와 같은 경우 eShopOnContainers 에서 마이크로 서비스를 주문하는 것처럼 DDD(도메인 기반 디자인) 접근 방식으로 정의된 것과 같이 특정 마이크로 서비스 내에서 고급 패턴을 구현할 수 있습니다. (이후 섹션에서 이러한 DDD 패턴을 검토하여 마이크로 서비스를 주문하는 eShopOnContainers 의 구현을 설명합니다.)
마이크로 서비스당 다른 기술에 대한 또 다른 이유는 각 마이크로 서비스의 특성일 수 있습니다. 예를 들어 C#과 같은 개체 지향 프로그래밍 언어 대신 F#과 같은 기능 프로그래밍 언어 또는 AI 및 기계 학습 도메인을 대상으로 하는 경우 R과 같은 언어를 사용하는 것이 더 좋을 수 있습니다.
결론은 각 마이크로 서비스가 서로 다른 디자인 패턴에 따라 다른 내부 아키텍처를 가질 수 있다는 것입니다. 고급 DDD 패턴을 사용하여 모든 마이크로 서비스를 구현해야 하는 것은 아닙니다. 이는 과도하게 엔지니어링되기 때문입니다. 마찬가지로, 끊임없이 변화하는 비즈니스 논리가 있는 복잡한 마이크로 서비스는 CRUD 구성 요소로 구현해서는 안 되며, 결국 품질이 낮은 코드로 끝날 수도 있습니다.
새로운 세계: 여러 아키텍처 패턴 및 다국어 마이크로 서비스
소프트웨어 설계자와 개발자가 사용하는 많은 아키텍처 패턴이 있습니다. 다음은 몇 가지(아키텍처 스타일 및 아키텍처 패턴 혼합)입니다.
간단한 CRUD, 단일 티어, 단일 레이어.
클린 아키텍처 ( eShopOnWeb과 함께 사용됨)
Event-Driven 아키텍처 (EDA).
ASP.NET Core Web API, NancyFx, ASP.NET Core SignalR(.NET Core 2 이상에서 사용 가능), F#, Node.js, Python, Java, C++, GoLang 등과 같은 많은 기술 및 언어로 마이크로 서비스를 빌드할 수도 있습니다.
중요한 점은 특정 아키텍처 패턴이나 스타일이나 특정 기술이 모든 상황에 적합하지 않는다는 것입니다. 그림 6-3에서는 다른 마이크로 서비스에서 사용할 수 있는 몇 가지 접근 방식과 기술(특정 순서는 아님)을 보여 줍니다.
그림 6-3. 다중 아키텍처 패턴 및 다국어 마이크로 서비스 세계
다중 아키텍처 패턴 및 다각형 마이크로 서비스는 언어와 기술을 각 마이크로 서비스의 요구 사항에 혼합하고 일치시킬 수 있으며 여전히 서로 통신할 수 있습니다. 그림 6-3에 표시된 것처럼, 많은 마이크로 서비스(도메인 기반 디자인 용어의 제한된 컨텍스트 또는 단순히 자율 마이크로 서비스로 "하위 시스템")로 구성된 애플리케이션에서 각 마이크로 서비스를 다른 방식으로 구현할 수 있습니다. 각 아키텍처 패턴은 서로 다르며 애플리케이션의 특성, 비즈니스 요구 사항 및 우선 순위에 따라 서로 다른 언어 및 데이터베이스를 사용할 수 있습니다. 경우에 따라 마이크로 서비스가 비슷할 수 있습니다. 그러나 각 하위 시스템의 컨텍스트 경계와 요구 사항이 일반적으로 다르기 때문에 일반적으로는 그렇지 않습니다.
예를 들어 간단한 CRUD 유지 관리 애플리케이션의 경우 DDD 패턴을 디자인하고 구현하는 것은 의미가 없을 수 있습니다. 그러나 핵심 도메인 또는 핵심 비즈니스의 경우 끊임없이 변화하는 비즈니스 규칙으로 비즈니스 복잡성을 해결하기 위해 고급 패턴을 적용해야 할 수 있습니다.
특히 여러 하위 시스템에 의해 구성된 대규모 애플리케이션을 처리하는 경우 단일 아키텍처 패턴에 따라 단일 최상위 아키텍처를 적용해서는 안 됩니다. 예를 들어 CQRS는 전체 애플리케이션에 대한 최상위 아키텍처로 적용되지 않아야 하지만 특정 서비스 집합에 유용할 수 있습니다.
모든 특정 사례에 대해 만능 해결책이나 유일한 아키텍처 패턴은 없습니다. "모든 것을 지배하는 하나의 아키텍처 패턴"을 가질 수 없습니다. 각 마이크로 서비스의 우선 순위에 따라 다음 섹션에 설명된 대로 각각에 대해 다른 방법을 선택해야 합니다.
GitHub에서 Microsoft와 공동 작업
이 콘텐츠의 원본은 GitHub에서 찾을 수 있으며, 여기서 문제와 끌어오기 요청을 만들고 검토할 수도 있습니다. 자세한 내용은 참여자 가이드를 참조하세요.
.NET