NET微服务架构：容器化.NET应用指南

需积分: 3 95 浏览量更新于2024-07-18 收藏 12.78MB PDF 举报

"NET微服务架构——面向容器化的.NET应用程序" 本书《NET-Microservices-Architecture-for-Containerized-NET-Application》由iCesardelaTorre、BillWagner和MikeRousos三位专家撰写，由Microsoft Corporation的开发者部门和.NET及Visual Studio产品团队出版。这本书探讨了在.NET框架下构建和部署微服务架构的方法，尤其关注容器化.NET应用的实践。微服务架构是一种将大型复杂应用分解为一组小型、独立的服务的开发模式，每个服务都能在其自己的进程中运行，与其它服务通过轻量级机制进行通信，如HTTP RESTful API。这种架构方式提高了软件的可扩展性、灵活性和可维护性，同时也为DevOps文化提供了良好的支持。本书主要涵盖以下知识点： 1. 微服务基础：介绍微服务的基本概念，包括服务定义、服务间的通信、服务发现、数据管理以及服务边界设定等，帮助读者理解微服务架构的核心理念。 2. .NET与微服务：讨论如何利用.NET Framework或.NET Core来设计和实现微服务，包括选择合适的.NET技术栈，如ASP.NET Core，以及如何利用C#编程语言构建服务。 3. 容器化：详细阐述Docker容器技术在微服务中的应用，包括Docker镜像创建、容器编排（如Kubernetes或Docker Compose）以及容器在持续集成/持续部署(CI/CD)流程中的角色。 4. 微服务设计原则：讲解设计微服务时应遵循的原则，如单一职责原则(SRP)、无状态原则、服务间松耦合等，以及如何处理服务间的边界和接口设计。 5. 微服务实施策略：提供实际操作步骤，指导如何将现有应用分解为微服务，包括服务划分、数据库拆分、API设计以及服务间的交互策略。 6. 持续集成与持续部署：介绍CI/CD的重要性，以及如何利用工具如Jenkins、Azure DevOps和GitLab等建立有效的CI/CD流程，确保代码质量和快速迭代。 7. 监控与日志：讨论微服务环境下如何实现服务监控和日志管理，包括使用Prometheus、Grafana等工具进行性能监控，以及ELK (Elasticsearch, Logstash, Kibana)堆栈的日志收集和分析。 8. 故障恢复与弹性：讲解如何设计高可用和容错的微服务系统，包括服务网格、断路器模式、负载均衡以及故障转移策略。 9. 安全性：涵盖微服务架构下的安全问题，如身份验证、授权、数据加密以及API安全设计。 10. 微服务最佳实践：总结作者们在实践过程中积累的经验教训，提供微服务设计和实施的最佳实践，以避免常见陷阱。此书对于想要深入了解和实践.NET微服务架构的开发者，以及正在考虑将现有.NET应用迁移到微服务架构的企业，都是一份宝贵的参考资料。通过学习本书，读者能够掌握构建和管理容器化.NET应用的全面知识，从而提升系统的可扩展性和稳定性。

8 Introduction to Containers and Docker

To run the app or service, the app’s image is instantiated to create a container, which will be running

on the Docker host. Containers are initially tested in a development environment or PC.

Developers should store images in a registry, which acts as a library of images and is needed when

deploying to production orchestrators. Docker maintains a public registry via Docker Hu ; other

vendors provide registries for different collections of images. Alternatively, enterprises can have a

private registry on-premises for their own Docker images.

Figure 2-4 shows how images and registries in Docker relate to other components. It also shows the

multiple registry offerings from vendors.

Figure 2-4. Taxonomy of Docker terms and concepts

Putting images in a registry lets you store static and immutable application bits, including all their

dependencies at a framework level. Those images can then be versioned and deployed in multiple

environments and therefore provide a consistent deployment unit.

Private image registries, either hosted on-premises or in the cloud, are recommended when:

• Your images must not be shared publicly due to confidentiality.

• You want to have minimum network latency between your images and your chosen

deployment environment. For example, if your production environment is Azure cloud, you

probably want to store your images in Azure Container Registry so that network latency will

be minimal. In a similar way, if your production environment is on-premises, you might want

to have an on-premises Docker Trusted Registry available within the same local network.

9 Choosing Between .NET Core and .NET Framework for Docker Containers

S E CTIO N

Choosing Between .NET

Core and .NET Framework

for Docker Containers

There are two supported frameworks for building server-side containerized Docker applications with

.NET: .NET Framework and .NET Core. They share many.NET platform components, and you can share

code across the two. However, there are fundamental differences between them, and which

framework you use will depend on what you want to accomplish. This section provides guidance on

when to choose each framework.

General guidance

This section provides a summary of when to choose .NET Core or .NET Framework. We provide more

details about these choices in the sections that follow.

You should use .NET Core for your containerized Docker server application when:

• You have cross-platform needs. For example, you want to use both Linux and Windows

Containers.

• Your application architecture is based on microservices.

• You need to start containers fast and want a small footprint per container to achieve better

density or more containers per hardware unit in order to lower your costs.

In short, when you create new containerized .NET applications, you should consider.NET Core as the

default choice. It has many benefits and fits best with the containers philosophy and style of working.

An additional benefit of using .NET Core is that you can run side by side .NET versions for applications

within the same machine. This benefit is more important for servers or VMs that do not use

containers, because containers isolate the versions of .NET that the app needs. (As long as they are

compatible with the underlying OS.)

You should use .NET Framework for your containerized Docker server application when:

• Your application currently uses .NET Framework and has strong dependencies on Windows.

• You need to use Windows APIs that are not supported by .NET Core.

• You need to use third-party .NET libraries or NuGet packages that are not available for .NET

Core.

10 Choosing Between .NET Core and .NET Framework for Docker Containers

Using .NET Framework on Docker can improve your deployment experiences by minimizing

deployment issues. This “lift and shift” scenario is important for “dockerizing” legacy applications (at

least, those that are not based on microservices).

When to choose .NET Core for Docker containers

The modularity and lightweight nature of .NET Core makes it perfect for containers. When you deploy

and start a container, its image is far smaller with .NET Core than with .NET Framework. In contrast, to

use .NET Framework for a container, you must base your image on the Windows Server Core image,

which is a lot heavier than the Windows Nano Server or Linux images that you use for .NET Core.

Additionally, .NET Core is cross-platform, so you can deploy server apps with Linux or Windows

container images. However, if you are using the full .NET Framework, you can only deploy images

based on Windows Server Core.

The following is a more detailed explanation of why to choose .NET Core.

Developing and deploying cross platform

Clearly, if your goal is to have an application (web app or service) that can run on multiple platforms

supported by Docker (Linux and Windows), the right choice is .NET Core, because .NET Framework

only supports Windows.

.NET Core also supports macOS as a development platform. However, when you deploy containers to

a Docker host, that host must (currently) be based on Linux or Windows. For example, in a

development environment, you could use a Linux VM running on a Mac.

Visual Studio provides an integrated development environment (IDE) for Windows. Visual Studio for

Mac is an evolution of Xamarin Studio running in macOS, but as of the time of this writing, it still does

not support Docker development. You can also use Visual Studio Code (VS Code) on macOS, Linux,

and Windows. VS Code fully supports .NET Core, including IntelliSense and debugging. Because VS

Code is a lightweight editor, you can use it to develop containerized apps on the Mac in conjunction

with the Docker CLI and the .NET Core CLI (dotnet cli). You can also target .NET Core with most third-

party editors like Sublime, Emacs, vi, and the open-source OmniSharp project, which also provides

IntelliSense support. In addition to the IDEs and editors, you can use the .NET Core command-line

tools (dotnet CLI) for all supported platforms.

Using containers for new (“green-field”) projects

Containers are commonly used in conjunction with a microservices architecture, although they can

also be used to containerize web apps or services that follow any architectural pattern. You can use

.NET Framework on Windows Containers, but the modularity and lightweight nature of .NET Core

makes it perfect for containers and microservices architectures. When you create and deploy a

container, its image is far smaller with .NET Core than with .NET Framework.

Creating and deploying microservices on containers

You could use the full .NET framework for microservices-based applications (without containers) when

using plain processes, because .NET Framework is already installed and shared across processes.

However, if you are using containers, the image for .NET Framework (Windows Server Core plus the

11 Choosing Between .NET Core and .NET Framework for Docker Containers

full .NET Framework within each image) is probably too heavy for a microservices-on-containers

approach.

In contrast, .NET Core is the best candidate if you are embracing a microservices-oriented system that

is based on containers, because .NET Core is lightweight. In addition, its related container images,

either the Linux image or the Windows Nano image, are lean and small.

A microservice is meant to be as small as possible: to be light when spinning up, to have a small

footprint, to have a small Bounded Context, to represent a small area of concerns, and to be able to

start and stop fast. For those requirements, you will want to use small and fast-to-instantiate container

images like the .NET Core container image.

A microservices architecture also allows you to mix technologies across a service boundary. This

enables a gradual migration to .NET Core for new microservices that work in conjunction with other

microservices or with services developed with Node.js, Python, Java, GoLang, or other technologies.

There are many orchestrators you can use when targeting microservices and containers. For large and

complex microservice systems being deployed as Linux containers, Azure Container Service has

multiple orchestrator offerings (Mesos DC/OS, Kubernetes, and Docker Swarm), which makes it a

good choice. You can also use Azure Service Fabric for Linux, which supports Docker Linux containers.

(At the time of this writing, this offering was still in preview. Check the Azure Service Fabric for the

latest status.)

For large and complex microservice systems being deployed as Windows Containers, most

orchestrators are currently in a less mature state. However, you currently can use Azure Service Fabric

for Windows Containers, as well as Azure Container Service. Azure Service Fabric is well established for

running mission-critical Windows applications.

All these platforms support .NET Core and make them ideal for hosting your microservices.

Deploying high density in scalable systems

When your container-based system needs the best possible density, granularity, and performance,

.NET Core and ASP.NET Core are your best options. ASP.NET Core is up to ten times faster than

ASP.NET in the full .NET Framework, and it leads other popular industry technologies for

microservices, such as Java servlets, Go, and Node.js.

This is especially relevant for microservices architectures, where you could have hundreds of

microservices (containers) running. With ASP.NET Core images (based on the .NET Core runtime) on

Linux or Windows Nano, you can run your system with a much lower number of servers or VMs,

ultimately saving costs in infrastructure and hosting.

When to choose .NET Framework for Docker

containers

While .NET Core offers significant benefits for new applications and application patterns, .NET

Framework will continue to be a good choice for many existing scenarios.

12 Choosing Between .NET Core and .NET Framework for Docker Containers

Migrating existing applications directly to a Docker container

You might want to use Docker containers just to simplify deployment, even if you are not creating

microservices. For example, perhaps you want to improve your DevOps workflow with Docker—

containers can give you better isolated test environments and can also eliminate deployment issues

caused by missing dependencies when you move to a production environment. In cases like these,

even if you are deploying a monolithic application, it makes sense to use Docker and Windows

Containers for your current .NET Framework applications.

In most cases, you will not need to migrate your existing applications to .NET Core; you can use

Docker containers that include the full .NET Framework. However, a recommended approach is to use

.NET Core as you extend an existing application, such as writing a new service in ASP.NET Core.

Using third-party .NET libraries or NuGet packages not available for

.NET Core

Third-party libraries are quickly embracing the .NET Standard, which enables code sharing across all

.NET flavors, including .NET Core. With the .NET Standard Library 2.0, this will be even easier, because

the .NET Core API surface will become significantly bigger. Your .NET Core applications will be able to

directly use existing .NET Framework libraries.

Be aware that whenever you run a library or process based on the full .NET Framework, because of its

dependencies on Windows, the container image used for that application or service will need to be

based on a Windows Container image.

Using.NET technologies not available for .NET Core

Some .NET Framework technologies are not available in the current version of .NET Core (version 1.1

as of this writing). Some of them will be available in later .NET Core releases (.NET Core 2), but others

do not apply to the new application patterns targeted by .NET Core and might never be available.

The following list shows most of the technologies that are not available in .NET Core 1.1:

• ASP.NET Web Forms. This technology is only available on .NET Framework. Currently there are

no plans to bring ASP.NET Web Forms to .NET Core.

• ASP.NET Web Pages. This technology is slated to be included in a future .NET Core release, as

explained in the .NET Core roadmap.

• ASP.NET SignalR. As of the .NET Core 1.1 release (November 2016), ASP.NET SignalR is not

available for ASP.NET Core (neither client nor server). There are plans to include it in a future

release, as explained in the .NET Core roadmap. A preview is available at the Server-side and

Client Library GitHub repositories.

• WCF services. Even when a WCF-Client library is available to consume WCF services from .NET

Core (as of early 2017), the WCF server implementation is only available on .NET Framework.

This scenario is being considered for future releases of .NET Core.

• Workflow-related services. Windows Workflow Foundation (WF), Workflow Services (WCF +

WF in a single service), and WCF Data Services (formerly known as ADO.NET Data Services)

are only available on .NET Framework. There are currently no plans to bring them to .NET

Core.

剩余296页未读，继续阅读

rookieclover

粉丝: 0
资源: 2

NET微服务架构：容器化.NET应用指南

NET-Microservices-Architecture-for-Containerized-NET-Applications.pdf

容器化.NET应用的.NET微服务架构

NET-Microservices-Architecture-for-Containerized-NET-Applications

mastering-spring-cloud2018

Learning Docker - Second Edition [2017].azw3电子书下载

Best Practices for Model Deployment: 5 Steps to Ensure Your Model Runs Steadily

(175797816)华南理工大学信号与系统Signal and Systems期末考试试卷及答案

深圳建设施工项目安全生产奖惩管理制度.docx

离散数学课后题答案+sdut往年试卷+复习提纲资料

自考04741计算机网络原理真题及答案及课件

最新资源