몇 달 전에 ASP.NET 팀의 Glenn Condron 및 Ryan Nowak과 마이크로 서비스용 .NET 3.0의 새로운 기능에 대해 이야기를 나눌 기회가 있었습니다.



주제

- .NET Core 3.0에서 마이크로서비스 템플릿의 목표는 무엇입니까?

- 새로운 Worker 템플릿은 무엇입니까?

- .NET Core 3에서 gRPC는 어떻게 됩니까?

- 개발자가 gRPC와 웹 API 중에서 선택하는 방법은 무엇입니까?

자원

Introduction to gRPC on ASP.NET Core

Download .NET Core 3.0

.NET Microservices Architecture Guidance

Comparing gRPC series with HTTP APIs

마이크로서비스에 크기가 중요합니까?

일반적으로 마이크로서비스와 마이크로서비스를 생각하는 방법에 대해 더 많이 생각하게 되었습니다. 여기서 "마이크로"가 올바른 접두사입니까? 그들은 실제로 작습니까? 아마 아닐 겁니다.

이 용어는 책임, 배포(크기가 아님), 관리 용이성, 서비스 경계 및 개발 팀에 더 가깝습니다.

헬로 월드

철회하지 말고 단순히 "Hello World"를 생성하기 위해 작성할 수 있는 .NET Core의 최소한의 현실적인 서비스는 무엇입니까?

public class Service
{
    public static void Main(string[] args)
    {
        CreateHostBuilder(args).Build().Run();
    }

    public static IHostBuilder CreateHostBuilder(string[] args) =>
        Host.CreateDefaultBuilder(args)
            .ConfigureWebHostDefaults(webBuilder =>
            {
                webBuilder.UseStartup<Service>();
            });

    public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
    {
        app.UseRouting();
        app.UseEndpoints(endpoints =>
        {
            endpoints.MapGet("/", async context =>
            {
                await context.Response.WriteAsync("Hello, world!");
            });
        });
    }
}

여기에서 "/"경로를 처리하고 "Hello, world!"를 반환하도록 설정된 EndpointRouting으로 호스트가 생성됩니다.
dotnet run를 사용하여 http://localhost:5000을 탐색하고 Hello, world! 화면으로 출력합니다. 그다지 실용적이지는 않지만 단일 책임 서비스가 작업을 수행합니다.

Use the .NET CLI to create a new API template using dotnet new webapi for a more complete template to build on. See tutorial/docs here.

일에 집중하세요

서비스를 구축하는 것은 작은 서비스가 아닌 "소규모 집중"서비스를 만들고자 하는 열망에 관한 것입니다.

여기에는 위험 대 보상 대화가 있습니다. 마이크로서비스 접근 방식의 만트라를 고수하기 위해 가능한 한 많은 소규모 서비스를 만들려는 욕구는 그럴 가치가 없는 정도의 오버헤드로 이어질 것입니다.



당신은 잘 모르겠지만 그 더미를 밟을 때마다 아파요...

제한된 컨텍스트

보고 듣고 읽는 위치에 따라 도메인 기반 디자인은 대규모 시스템에서 복잡성을 통합하는 방법에 대한 그림으로 나타날 수 있으며 많은 훌륭한 도구가 있습니다.

DDD에서 사용되는 용어 중 하나는 aggregate으로 단일 단위로 취급되는 개체의 클러스터 또는 컬렉션을 설명합니다. 따라서 고객 주문을 처리하는 애플리케이션에서는 모든 "CustomerOrder"작업과 데이터를 단일 서비스에서 처리하는 것이 좋습니다.

그러나 다른 "고객"또는 "주문"작업이 서비스에 번지기 쉽습니다. 서비스의 실제 기능 대신 클래스 또는 엔터티를 그룹화하는 자신을 찾습니다.

각 서비스/스키마를 독립적으로 유지 관리하고 배포할 수 있다는 것은 큰 이점이며 필요에 따라 각 서비스를 확장하는 것도 이 아키텍처에 도움이 됩니다. 그러나 네트워크 수다스러운 것은 부작용입니다. 배포 용이성, 확장성 및 유지 관리 용이성을 위해 초고속인 한 많은 호출에 대해 괜찮습니까?

작은 것은 얼마나 작습니까?

팀이 작습니까? 애플리케이션에 따라 6-8명의 엔지니어 또는 한 줌이 이상적인 숫자로 보이지만 대규모 시스템은 소규모 팀에서 구축했으며 그 반대도 마찬가지입니다.

내 코드는 줄 수로 측정됩니까?

디스크 크기? 일부 사람들은 디스크 공간이 저렴하다고 말합니다.

앱을 넣을 때까지 컨테이너는 매일 작아지고 있습니다.

당신의 생각은 무엇입니까?