几年前，Microsoft 与技术领先的社区专家合作发布了一本受欢迎的指导书，标题为《适用于容器化 .NET 应用程序的 .NET 微服务》，深入探讨了构建分散式应用程序的原则、模式和最佳做法。 其中包括一个功能齐全的微服务参考应用程序，展示了体系结构概念。 名为 [eShopOnContainers] 的应用程序托管了一个电子商务店面，该店面销售各种商品，包括服装和咖啡杯。 该应用程序在 .NET 中构建，是跨平台的，可以在 Linux 或 Windows 容器中运行。 原始 eShop 体系结构如下：
eShop开发环境架构图
多年以来，微软的官方示例代码由『宠物商店』发展到『花店』再蜕变为如今的『易商城』，这是从「传统三层架构」到「基于wcf的分布式领域模型」再到「基于容器的微服务」的开发方式上的质的跃迁。但相比于依托在Windows系统和WCF桌面技术下成熟的花店系统，易商城在分布式下作为一个开发环境架构的弊端也非常明显：
1、缺少分布式框架和操作系统支持，造成分布式面临的状态管理、服务调用、企业总线、可观察性等难点均需要开发人员去解决。问题是他们有能力去解决吗？能解决的足够完美吗？当开发人员被迫的将主要精力集中在一大堆的非业务的问题上时，那表示整个项目组面临着被拖入泥潭的风险，必将严重拖慢开发节奏。
2、开发环境架构图过于复杂，几乎是网上的微服务架构图的翻版，在实际开发过程中，图中的每个节点都需要至少数名开发人员参与其中。在没有谈论具体业务的情况下，需要集中起来的开发人员就冲着100多位去了，这不现实。
3、后期运维工作艰难。前面两点造成的后遗症就是给项目上线后的运维工作带来了巨大的挑战。复杂开发环境架构转换到生产需要巨大的工作量，同时开发过程中各种不完美的解决方案的弊端将会纷纷暴露出来。当线上诸多业务与非业务的问题串联发生时，你会发现每天的下班时间都是考验运维人员的经典时刻。
值得称道的是，微软还随附了 eShop 的一个更新版本。 它就是 eShopOnDapr。 此更新通过集成 Dapr 构建基块来改进早期 eShopOnContainers 应用程序。 新的解决方案体系结构如下：
eShop运维体系架构图
设计微服务应用时，需要考虑诸多因素。 Dapr提供了一些常用功能的最佳实践，上图中的1~6指的分别是Dapr的执行组件、绑定、发布订阅、机密管理、服务调用和状态管理构建基块。
在 eShopOnDapr 中，Dapr 构建基块取代了大量复杂且容易出错的管道代码，剥离出原来的业务逻辑代码然后再新加一个挎斗，包括状态管理、服务调用、发布订阅、机密管理等在内的工作都是由挎斗来负责的，这起到了应用逻辑层面和架构层面的隔离作用，从而形成开发人员负责开发业务逻辑，运维人员负责挎斗维护的最佳状态。
Dapr简化了微服务的开发和部署，使开发人员专注于业务，全程处于业务员的高度，大大提升了开发效率，而运维人员负责挎斗维护，也使项目组不再担心项目的平稳落地。想象一下开发人员每一天都是乘坐飞机在 20,000 英尺的高空中工作的， 当他看向窗外，从广阔的角度看到下面的风景，会发现——世界两万英尺范围内，均分布有运维体系架构。
参考资料:
[2]Dapr官方文档
