@levinzhang
2016-09-03T16:24:00.000000Z
字数 1240
阅读 514
by Jan Stenberg on Aug 28, 2016
企业在创建和开发微服务的过程中，最困难的问题之一就是他们的数据。如果我们采用领域驱动设计（Domain-Driven Design，DDD）来分析业务领域并剖析数据所代表的含义，将会有助于实现微服务架构，Christian Posta在一个关于微服务实现的系列博客文章中阐述了该理念。
企业在创建和开发微服务的过程中，最困难的问题之一就是他们的数据。如果我们采用领域驱动设计（Domain-Driven Design，DDD）来分析业务领域并剖析数据所代表的含义，将会有助于实现微服务架构，Christian Posta在一个关于微服务实现的系列博客文章中阐述了该理念。
Posta是Red Hat的中间件主架构师，对于他来说，选择微服务架构的主要原因在于这种架构能够让负责系统不同组成部分的团队按照不同的进度来开展工作，并且能够让他们之间的相互干扰达到最小。当按照这种方式来组织团队的时候，系统架构能够反映出这种变化，并且会向微服务架构来演化。
但是，如何让团队之间的这种自治真正运转起来，这一点其实并不简单。在单体架构中，通常会使用事务并且只有一个数据库，如果每个服务都具有一个数据库话，那么这会变成一项挑战，对于传统的企业来讲更是如此。
Posta指出，在实现微服务方面，互联网公司和传统企业之间有着巨大的差异。互联网公司采用微服务的目的主要是解决解决大量数据和扩展性的问题，而传统企业要同时处理业务和扩展性方面的复杂性。播放影片或发送tweet的复杂性要远远低于保险索赔系统的复杂性。
在为相对复杂的企业域构建微服务时，我们需要找到在这个域中不同责任的边界。在每个边界中，我们会创建领域模型，这个模型是针对业务责任所设计的，并反映了这种业务责任。针对每个边界的数据模型会由同一个边界中的领域模型来驱动。采用DDD的方式我们能够找到这些边界，并会为每个边界创建一个有界上下文（bounded context），每个上下文将会成为一个微服务。
在Posta的经验中，开发人员在构建分布式系统时，会倾向于假设只有一个关系型数据库，并试图将网络的不稳定性抽象出来。跨多个服务所带来的分布式数据问题通常会通过二阶段提交来解决。与这种做法不同，Posta相信，我们必须要寻找每个有界上下文中的事务性边界，并找到满足业务限制和不变量的最小原子单元，不要让事务传播到其他的上下文之中。
我们还需要有一种机制，能够让服务通知其他的服务发生了什么，针对这种需求，Posta推荐使用事件。我们的服务会发布事件，描述在这个域中发生了什么，其他的服务会读取这些事件，调整它们自己的模型并将变更进行持久化。
关于这些理念的更深入描述，Posta引用了Vaughn Vernon发布的一系列博客文章，这些文章基于DDD理念，描述了聚集、事务边界和有界上下文。