基于eShopOnContainers学习ASP.NET Core之简介

简介

官方地址

设计面向微服务的应用

应用程序规范：

包含单页面应用（SPA）、传统web应用、移动端web应用，还可能公开一个api供第三方使用

包含组件：

• 演示组件。 这些组件负责处理 UI 并使用远程服务。
• 域或业务逻辑。 此组件是应用程序的域逻辑。
• 数据库访问逻辑。 此组件包括负责访问数据库（SQL 或 NoSQL）的数据访问组件。
• 应用程序集成逻辑。 此组件包括基于消息代理的消息传递通道。

应用程序必须要有伸缩性、并且可以在多个环境中部署

开发团队的要求

应用程序的开发过程中可能会有：

• 不同的开发团队专注于应用程序的不同业务方面。
• 新的团队成员必须快速提高工作效率，且应用程序必须易于理解和修改。
• 应用程序将具有长期发展和不断变化的业务规则。
• 你需要良好的长期可维护性，这意味着在未来实现新更改时具有灵活性，同时能够更新多个子系统，且尽可能减少对其他子系统的影响。
• 你希望执行应用程序的持续集成和持续部署。
• 你希望利用新兴技术（框架、编程语言等），同时发展应用程序。 你不想在转换为新技术时，对应用程序进行完整迁移，因为这样做会产生高额费用，且影响应用程序的可预测性和稳定性。

选择体系结构

应用程序部署体系结构应该是什么？ 根据应用程序的规格以及开发上下文，应用程序的构建应采用以下方式：将其分解为独立的子系统（采用协作的微服务和容器的形式），其中微服务是容器。

在此方法中，每个服务（容器）实现一组紧密结合且关联的功能。 例如，应用程序可能包含目录服务，订购服务、购物篮服务、用户个人资料服务等服务。

微服务不仅使用 HTTP (REST) 等协议通信，而且尽可能进行异步通信（如使用 AMQP），尤其是传播集成事件更新时。

微服务作为相互独立的容器开发和部署。 此方法意味着开发团队可以在开发和部署特定微服务时，不会影响其他子系统。

每个微服务都有自己的数据库，从而能够从其他微服务中完全分离。 如有必要，可使用应用程序级集成事件（通过逻辑事件总线）实现不同微服务中的数据库间的一致性，正如命令查询职责分离 (CQRS) 中的处理一样。 由此，业务约束必须接受多个微服务和相关数据库之间的最终一致性。

官方示例

eShopOnContainers：使用容器部署的 .NET 和微服务的参考应用程序

架构图如下

github地址https://github.com/dotnet-architecture/eShopOnContainers

通过上图得知：

移动端和SPA应用通过网关和微服务进行通信，传统Web程序要通过一个MVC服务来访问网关

部署在docker上面

通信结构：eShopOnContainers 应用程序使用两种通信类型，具体取决于功能操作的类型（查询与更新和事务）：

• 通过 API 网关进行的 Http 客户端到微服务通信。 此方法用于查询，以及在接受来自客户端应用的更新或事务命令时使用。 使用 API 网关的方法在后面部分中进行详细介绍。
• 基于异步事件的通信。 此通信通过事件总线发生，以跨微服务传播更新或与外部应用程序集成。 可使用 RabbitMQ 等消息中转站基础结构技术或使用 Azure 服务总线、NServiceBus、MassTransit 或 Brighter 等较高级别（抽象级别）服务总线实现此事件总线。

此应用程序以容器形式，作为一组微服务部署。 客户端应用可以通过 API 网关发布的公共 URL 与作为容器运行的微服务进行通信。

基于微服务的解决方案的优缺点

优点

每个微服务相对较小，易于管理和发展 ：有助于开发的理解和编码效率，还有发布的时候无需整个应用发布

可以横向扩展应用程序的各个区域 ：单个服务的扩展不会影响整体的流程

可以在多个团队之间划分开发工作 ：每个团队都可以独立的开发部署其应用

可以更好地隔离问题 ：如果一个服务出现问题，则不会影响到其他的服务

可以使用最新技术 ：可独立开发的时候使用新的技术，因为彼此之间轻耦合

缺点：

分布式应用程序 ：服务拆分必定面临通信问题，这会增加设计和测试的难度

部署复杂性 ：微服务由于拆分了，所以增加了部署和运维的难度

原子事务：微服务体系通常多个微服务之间实现不了原子事务，只能通过业务保证最终一致性

增加全局资源需求 :会增加服务器的资源需求

客户端到微服务直接通信的问题 ：通常情况下客户端的一个请求可能需要调取多个微服务的接口，所耗时间成本增加

微服务分区 ：微服务拆分及划分的难度较大，原则上必须保证每个微服务必须是端到端自治的

外部和内部体系结构和设计模式

如上图：

外部体系结构：如上图是由好多个微服务一起为API Gateway提供服务，但是每个微服务可能是不一样的，有可能有的微服务比较简单，有可能有的微服务比较复杂，所以不应该把每个微服务设计成一模一样的技术结构，负责可能会出现过度设计的问题

新体系：多个体系结构模式和 polyglot 微服务

软件架构师和开发人员使用许多体系结构模式。 以下是一些模式（混合体系结构样式和体系结构模式）：

• 简单 CRUD、单层级、单层。
• 传统 N 分层。
• 域驱动设计 N 分层。
• 清洁体系结构（用于 eShopOnWeb）
• 命令查询职责分离 (CQRS)。
• 事件驱动的体系结构 (EDA)。

如下图显示了一些可用于微服务的方法和技术

多体系结构模式和 polyglot 微服务意味着可以混合搭配语言和技术以满足每个微服务的需求，并且仍让它们彼此通信

如上图在由许多微服务（域驱动设计术语中的绑定上下文，或作为自主微服务的“子系统”）构成的应用程序中，可能会采用不同方式实现每个微服务。 每个微服务可能具有不同体系结构模式，使用不同语言和数据库，具体取决于应用程序的本质、业务要求和优先级。 在某些情况下，微服务可能相似。 但这并不常见，因为每个子系统的上下文边界和要求通常不同。

例如，对于简单的 CRUD 维护应用程序，设计和实现 DDD 模式可能无意义。 但对于核心域或核心业务，可能需要应用更高级的模式，以应对不断变化的业务规则的业务复杂性。

尤其是处理由多个子系统构成的大型应用程序时，不应基于单个体系结构模式应用单个顶级体系结构。 例如，CQRS 不应作为整个应用程序的顶级体系结构，但可能适用于一组特定的服务。

没有在任何情况下都通用的体系结构模式。 不可能有“适合所有情况的体系结构模式”。 必须根据每个微服务的优先级，为每个微服务选择不同方法；

总结

1.微服务有优点也有缺点，当优点对于你的需求足够覆盖缺点的时候就可以选择微服务体系

2.对于每个微服务而言，不应该有统一的设计，应该针对不同业务存在不同的设计