微服务架构与.NET应用开发

微服务

.net

需积分: 1 134 浏览量更新于2024-07-19 收藏 12.57MB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

"architecting-and-developing-containerized-and-microservice-based-net-applications-ebook-early-draft.pdf" 本文档是微软公司DevDiv、.NET和Visual Studio产品团队早期草案的电子书，主要讨论了基于微服务和容器化的.NET应用程序的架构与开发。作者 CesardelaTorre 是微软公司的.NET产品团队高级项目经理。本书涵盖了微服务架构的核心概念，.NET框架在微服务环境中的应用，以及如何利用容器技术来构建和部署这些应用。 1. **微服务架构**：微服务架构是一种将大型复杂应用程序分解为一组小型、独立的服务的方法，每个服务都有自己的业务功能，它们之间通过API进行通信。这种架构允许团队独立地开发、测试和部署服务，提高了系统的可伸缩性、可维护性和容错性。 2. **.NET框架在微服务中的应用**：.NET框架提供了丰富的库和工具支持微服务开发，如ASP.NET Core，它是一个轻量级、高性能的框架，适用于构建跨平台的Web API和微服务。此外，.NET Core的模块化特性使得服务可以按需选择组件，进一步优化了资源使用。 3. **容器化**：容器技术（如Docker）是实现微服务的关键工具，它提供了一种轻量级的虚拟化方式，使得每个服务都可以在一个独立的运行环境中运行。容器化的优点包括一致性的运行环境、高效的资源利用率和快速的部署能力。 4. **服务发现与治理**：在微服务环境中，服务发现是确保服务间通信的关键。书中可能介绍了服务注册与发现机制，如使用Consul或Eureka等工具，以及服务网格如Istio和Linkerd的作用，它们可以提供负载均衡、熔断、限流等功能，帮助管理和监控微服务间的交互。 5. **持续集成/持续部署(CI/CD)**：微服务架构强调快速迭代和频繁部署。书中可能会讨论如何设置有效的CI/CD流程，利用Jenkins、Azure DevOps或GitHub Actions等工具自动化构建、测试和部署过程，以确保代码质量并快速响应变化。 6. **监控与日志管理**：微服务架构下，监控和日志收集尤为重要。书中可能涉及如何使用Prometheus、Grafana进行性能指标监控，以及使用ELK(Elasticsearch、Logstash、Kibana)堆栈或Splunk进行日志分析，以确保系统的健康和可诊断性。 7. **数据一致性与分布式事务**：微服务间的独立数据库可能导致数据一致性问题。文档可能讨论了CAP定理、ACID与BASE原则，以及如何在微服务架构中处理分布式事务，如使用Event Sourcing或Saga模式。 8. **安全性**：微服务的安全性涉及身份验证、授权和通信安全。书中可能涵盖了OAuth2、OpenID Connect、TLS/SSL加密，以及如何使用API Gateway进行统一的权限控制。 9. **设计模式与最佳实践**：文档可能探讨了适用于微服务的一些设计模式，如反向API、事件驱动架构、补偿事务等，并提供了在实际项目中实施微服务的最佳实践。 10. **故障隔离与弹性**：微服务架构旨在提高系统的弹性和容错性。书中可能包含如何设计服务以防止单点故障，使用断路器模式以防止级联失败，以及通过服务复制和负载均衡来提高可用性。以上是对基于微服务和容器化的.NET应用程序架构与开发的初步概述，具体的技术细节和深度分析将取决于书中更详尽的章节。

资源详情

资源推荐

2 Introduction to Containers and Docker

When to choose .NET Core for Docker containers

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

also be used to containerize web apps or services which follow any architectural pattern. The

modularity and lightweight nature of .NET Core makes it perfect for containers. When creating and

deploying a container, the size of its image is far smaller with .NET Core than with .NET Framework.

Because it is cross-platform, you can deploy server apps to Linux Docker containers, for example

The following is a more detailed explanation of the previously-stated reasons for picking .NET Core.

Cross-platform needs

Clearly, if your goal is to have an application (web/service) that is able to run on multiple platforms

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

only supports Windows.

.NET Core also supports MacOS as a development platform, but when deploying containers to a

Docker host, that host currently must 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 and Mac. Visual

Studio for Mac is an evolution of Xamarin Studio. You can also use Visual Studio Code on MacOS,

Linux and Windows. Visual Studio Code fully supports .NET Core, including IntelliSense and

debugging. 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 also the .NET Core command-line tools (dotnet CLI), available for all supported

platforms.

The “by-default” selection when targeting containers in new projects (“green-field”)

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

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

the .NET Framework for Windows containers, but the modularity and lightweight nature of .NET Core

makes it perfect for containers. When creating and deploying a container, the size of its image is far

smaller with .NET Core than .NET Framework. Because .NET Core is cross-platform, you can deploy

server apps to Linux Docker containers, for example.

Microservices architecture

.NET Core is the best candidate if you are embracing a microservices oriented system composed of

multiple independent, dynamically scalable, stateful or stateless microservices. .NET Core is

lightweight and its API surface can be minimized to the scope of the microservice. A microservices

architecture also allows you to mix technologies across a service boundary, enabling a gradual

migration to .NET Core for new microservices that work in conjunction with other microservices or

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

There are many infrastructure platforms you can use when targeting microservices and containers.

3 Introduction to Containers and Docker

For large and complex microservice systems being deployed as Linux containers, Azure Container

Service with its multiple orchestrator offering (Mesos DC/OS, Kubernetes and Docker Swarm) is a

great and mature choice. You can also use Azure Service Fabric for Linux which also supports Docker

Linux containers (Note: At the time of 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, but you will be able to use Azure Service Fabric

supporting Windows containers soon, as well as Azure Container Service. However, Azure Service

Fabric has a long experience running mission-critical Windows applications (without Docker) in

comparison to other orchestrators.

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

A need for high performance and scalable systems

When your container-based system needs the best possible performance and scalability, .NET Core

and ASP.NET Core are your best options. ASP.NET Core outperforms ASP.NET by a factor of 10, 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 can run your system with a much lower number

of servers/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, the .NET

Framework will continue to be a good choice for many existing scenarios and as such, it won’t be

replaced by .NET Core for all containerized server applications.

Current .NET Framework application directly migrated to a Docker container

You may want to use Docker containers for reasons other than targeting microservices. It could be

simply because you want to improve safety of your DevOps workflow and eliminate deployment

issues caused by missing dependencies in production environments. In this case, even when the

deployment type of your application might be monolithic, it makes sense to use Docker and Windows

containers for your current .NET Framework applications.

In most cases, you won’t need to migrate your existing applications to .NET Core. Instead, a

recommended approach is to use .NET Core as you extend an existing application, for example writing

a new service in ASP.NET Core.

A need to use third-party .NET libraries or NuGet packages not available for .NET Core

Libraries are quickly embracing .NET Standard, which enables sharing code across all .NET flavors

including .NET Core. With .NET Standard 2.0 this will be even easier, as the .NET Core API surface will

become significantly bigger and .NET Core applications can directly use existing .NET Framework

 
 
4    Introduction to Containers and Docker 
libraries. This transition won’t be immediate, though, so we recommend checking the specific libraries 
required by your application before deciding. 
However, consider that whenever you run a library/process based on the traditional .NET Framework, 
because of its dependencies on Windows, the container image used for that application/service will 
need to be based on a Windows Container image.  
A need to use .NET technologies not available for .NET Core 
Some .NET Framework technologies are not available in .NET Core 1.1. Some of them will be available 
in later .NET Core releases (.NET Core 2), but others don’t apply to the new application patterns 
targeted by .NET Core and may never be available. The following list shows the most common 
technologies not found in .NET Core 1.1: 
•  ASP.NET Web Forms applications: ASP.NET Web Forms is only available on the .NET 
Framework, so you cannot use ASP.NET Core / .NET Core for this scenario. Currently there are 
no plans to bring ASP.NET Web Forms to .NET Core. 
•  ASP.NET Web Pages applications: ASP.NET Web Pages are not included in ASP.NET Core 1.1, 
although it is planned to be included in a future release as explained in the .NET Core 
roadmap. 
•  ASP.NET SignalR server/client implementation. At .NET Core 1.1 release timeframe (November 
2016), ASP.NET SignalR is not available for ASP.NET Core (neither client nor server), although 
plans are to include it in a future release, as explained in the .NET Core roadmap. Preview 
state is available at the Server-side and Client Library GitHub repositories. 
•  WCF services implementation. Even when there’s a WCF-Client library to consume WCF 
services from .NET Core, as of January 2017, WCF server implementation is only available on 
the .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 the .NET Framework and there are no plans to bring them to .NET Core. 
•  Language support: Visual Basic and F# don’t currently have tooling support for .NET Core, but 
both will be supported in Visual Studio 2017 and later versions of Visual Studio. 
In addition to the official .NET Core roadmap, there are other features to be ported to .NET Core - For 
a full list, take a look at CoreFX issues marked as port-to-core. Please note that this list doesn’t 
represent a commitment from Microsoft to bring those components to .NET Core — they are simply 
capturing the desire from the community to do so. That being said, if you care about any of the 
components listed above, consider participating in the discussions on GitHub so that your voice can 
be heard. And if you think something is missing, please file a new issue in the CoreFX repository. 
A need to use a platform/API that doesn’t support .NET Core 
Some Microsoft or third-party platforms don’t support .NET Core. For example, some Azure services 
provide an SDK not yet available for consumption on .NET Core. This is temporary, as all of Azure 
services will eventually use .NET Core. For example, the Azure DocumentDB SDK for .NET Core was 
released as preview on November 16
th
 2016. In the meantime, you can always use the equivalent REST 
API instead of the client SDK. 

5 Introduction to Containers and Docker

Decision table - .NET frameworks to use for Docker

As a recap, the following is a summary decision table depending on your architecture or application

type and the server operating system you are targeting for your Docker containers.

Consider that if you are targeting Linux containers you will need Linux based Docker hosts (VMs or

Servers) and in a similar way, if you are targeting Windows containers you will need Windows Server

based Docker hosts (VMs or Servers).

Architecture / App Type

Linux containers

Windows containers

Microservices

.NET Core

Monolithic deployment App

.NET Core

.NET Framework

.NET Core

Best-in-class performance and

scalability

.NET Core

Windows Server “brown-field”

migration to containers

.NET Framework

Containers “green-field”

.NET Core

ASP.NET Core

.NET Core

.NET Core recommended

.NET Framework is possible

ASP.NET 4 (MVC 5, Web API 2)

.NET Framework

SignalR services

.NET Core in upcoming

releases

.NET Framework

.NET Core in upcoming

releases

WCF, WF and other traditional

frameworks

WCF in .NET Core (In the

Roadmap)

.NET Framework

WCF in .NET Core (In the

Roadmap)

Consumption of Azure services

.NET Core

(Eventually all Azure services

will provide Client SDKs for

.NET Core)

.NET Framework

.NET Core

(Eventually all Azure services

will provide Client SDKs for

.NET Core)

What OS to target with .NET Containers

Given the diversity of Operating systems supported by Docker and the “by design” differences

between .NET Framework and .NET Core, you should target specific OS and versions depending on

the framework you are using. For instance, in Linux there are many distros available but just few of

them are targeted in the official .NET Docker images (like Debian and Alpine). In Windows you can use

Windows Server Core or Nano Server which provide different characteristics (like IIS vs. Kestrel, etc.)

that might be needed by .NET Framework or NET Core.

In figure X-X you can see the recommended OS version depending on the .NET frameworks.

剩余243页未读，继续阅读

ebookkingbobo

粉丝: 0
资源: 5

微服务架构与.NET应用开发

microservice-template:快速创建.NET微服务的解决方案模板

.NET实现微服务架构

microservice-dotnet：使用开放天气API的.NET 5微服务

Point-based方法中transformer-based的方法有什么改进的地方

IC的STA中的Graph-Based Analysis和Path-based analysis的区别是什么

channel-based access和network-based access的区别

Influence of Autoencoder-Based Data Augmentation on Deep Learning-Based Wireless Communication

godec-based分解

In Defense of Color-based Model-free Tracking

基因位置one-based 和zero-base

Transformer-Based Visual Segmentation: A Survey

rank-based stochastic pooling

Granger因果关系检验的结果。具体来说，对于一个滞后期数为1的Granger因果关系检验，采用了ssr-based F检验、ssr-based chi2检验、似然比检验和参数F检验四种方法，应该用哪一种方法

NoC-based SoC Design

anchor-based和anchor-free的具体区别

policy-based-route与security-policy

施耐德触摸屏中的1-based代表什么意思

pyproject.toml-based是什么，如何安装

Rate-based算法

最新资源