你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn。
架构师和开发人员难以定义微服务的正确大小。 指导通常强调避免过大或太小的极端,但建议在实践中可能模糊不清。 但是,如果从精心设计的域模型开始,可以更轻松地定义每个微服务的正确大小和范围。
本文使用无人机交付服务作为正在运行的示例。 可以 在此处阅读有关方案的详细信息和相应的参考实现。
从域模型到微服务
在 上一篇文章中,我们定义了无人机交付应用程序的一组有限上下文。 然后,我们更仔细地查看了其中一个边界上下文,即“传送”边界上下文,并为该边界上下文标识了一组实体、聚合和域服务。
现在,我们已准备好从域模型到应用程序设计。 下面是一种方法,可用于从域模型派生微服务。
- 从边界上下文开始。 一般情况下,微服务中的功能不应跨越多个边界上下文。 根据定义,边界上下文标记特定域模型的边界。 如果发现微服务将不同的域模型混合在一起,则可能需要返回并优化域分析。 
- 接下来,查看域模型中的聚合。 聚合通常是微服务的良好候选项。 设计良好的聚合展示了设计良好的微服务的许多特征: - 聚合派生自业务要求,而不是数据访问或消息传送等技术问题。
- 聚合应具有较高的功能凝聚力。
- 聚合是持久性的边界。
- 聚合应松散耦合。
 
- 域服务也是微服务的良好候选项。 域服务是跨多个聚合的无状态作。 典型示例是包含多个微服务的工作流。 无人机交付应用程序显示了一个示例。 
- 考虑非功能要求。 查看团队大小、数据类型、技术、可伸缩性要求、可用性要求和安全要求等因素。 这些因素可能会导致将微服务分解为多个较小的服务。 在其他情况下,它们可能会导致将多个微服务合并到单个微服务中。 
在应用程序中标识微服务后,根据以下条件验证设计:
- 每个服务都有一个责任。 
- 服务之间没有聊天调用。 如果将功能拆分为两个服务会导致它们过于闲聊,则可能是这些函数属于同一服务的症状。 
- 每个服务都足够小,它可由独立工作的小型团队构建。 
- 没有相互依赖性需要两个或多个服务一起部署。 每个服务都应独立部署,而无需重新部署其他服务。 
- 服务没有紧密耦合,可以独立发展。 
- 服务边界旨在避免数据一致性或完整性问题。 在某些情况下,维护数据一致性意味着将相关功能分组到单个微服务中。 但是,并不总是需要强一致性。 分布式系统提供处理最终一致性的策略,分解服务的好处往往超过管理它的复杂性。 
最重要的是,必须务实,并记住域驱动设计是一个迭代过程。 毫无疑问,请从更粗粒度的微服务开始。 将微服务拆分为两个较小的服务比在多个现有微服务中重构功能更容易。
示例:为无人机交付应用程序定义微服务
开发团队之前确定了四个聚合、交付、包裹、无人机和帐户,以及两个域服务:计划程序和主管。
交付和包是微服务的明显候选项。 计划程序和监督程序协调其他微服务执行的活动,因此,将这些域服务实现为微服务是有意义的。
无人机和帐户很有趣,因为它们属于其他边界上下文。 一个选项是计划程序直接调用无人机和帐户边界上下文。 另一种方法是在传送边界上下文中创建无人机和帐户微服务。 这些微服务通过公开更适用于 Shipping 上下文的 API 或数据架构,在边界上下文之间进行调解。
无人机和帐户边界上下文的详细信息超出了本指南的范围,因此我们在参考实现中为它们创建了模拟服务。 但在这种情况下,需要考虑以下一些因素:
- 直接调用其他边界上下文的网络开销是什么? 
- 另一个边界上下文的数据架构是否适合此上下文,或者更适合此边界上下文的架构? 
- 另一个边界上下文是否为旧系统? 如果是这样,可以创建一个充当 反腐层 的服务,以便在旧系统与新式应用程序之间进行转换。 
- 什么是团队结构? 与负责其他边界上下文的团队沟通是否很容易? 否则,创建在两个上下文之间调解的服务有助于降低跨团队通信的成本。 
到目前为止,团队尚未考虑任何非功能要求。 评估应用程序的吞吐量需求后,开发团队会创建单独的引入微服务来处理客户端请求。 此微服务通过将传入请求放入缓冲区进行处理来实现 负载调配 。 然后,计划程序从缓冲区读取请求并实现工作流。
非功能要求还导致团队再创建一项服务。 现有服务侧重于实时计划和交付包。 但是,系统还必须将交付历史记录存储在长期存储中以供数据分析。 最初,团队考虑将此任务作为交付服务的一部分。 但是,历史分析的数据存储要求不同于正在进行的作要求。 有关详细信息,请参阅 数据注意事项。 因此,团队创建了单独的交付历史记录服务。 此服务侦听传递服务中的 DeliveryTracking 事件,并将其写入长期存储。
下图显示了此时的设计:
下载此体系结构的 Visio 文件。
后续步骤
此时,应清楚地了解设计中每个微服务的用途和功能。 现在可以构建系统。
 
              
            
