数据做为微服务 分布式数据集中集成

1.引言

Microservices(微服务)是新软件项目中所青睐的架构设计。随着从单一系统到分布式系统的演化不只发生在应用程序空间中，并且发生在数据存储中，管理数据成为最困难的挑战之一，然而，要从这种类型的方法中得到最大的收益，须要克服前面的几个需求。本文研究了将数据做为服务实现的一些考虑事项。

在遵循微服务设计指南时，咱们找到一些对数据处理的参考。其中一些常见的方向包括:

• 每一个服务的使用各自的私有数据库实现松散耦合。
• 拥抱最终一致性。
• 为最终一致性事务实现saga pattern。
• 使用Command Query Responsibility Segregation(CQRS)和API组合。

考虑到这一点，当将松耦合做为体系架构中的一个基本部分时，共享数据库如今就变成了一个反模式，使得事务和查询变得更加困难。每一个服务使用数据存储都须要封装数据，而与体系架构的其余域的交互应该只发生在API级别，这鼓励咱们隐藏数据实现细节。所以，使用诸如Spring Boot这样的轻量级框架只是微服务之旅的第一步。

2.查询的挑战

由于每一个服务都有数据存储，因此咱们须要使其可供其余服务使用，从而成为该域的入口点。因为全部数据调用都发生在服务级别，而且根据它们的域，当须要组合数据视图时，传统的table join（表链接）再也不是咱们在共享数据库实现中使用的方案。此外，咱们没法编写查询私有数据存储并聚合数据的服务，由于它违反了封装设计。

为了解决前面的挑战，咱们须要回到微服务体系架构中，使用成熟的企业集成模式(Enterprise Integration Patterns, EIP)，好比 content enrichment(内容浓缩)和aggregator( 聚合器)。大多数时候，这些模式被从新命名为API组合模式，一般在API网关之类的组件中实现。

一般，API组合模式涉及到添加另外一个服务，该服务使用所需的信息调用底层数据服务来组合所需的数据视图。以下图所示，它将首先查询客户服务的基本信息，而后使用该信息从支付服务检索该客户的历史记录。

乍一看，这看起来像是一个简单的组合任务，然而，业务一般须要对数据的使用方式进行愈来愈多的控制，并向此类服务添加更多的逻辑。对要检索的数据量、消费终端用户的权限等的限制是常见的业务需求，这使得实现这类服务成为一项全职维护任务。

另外一方面，Command Query Responsibility Segregation(CQRS)试图解决查询挑战，侧重于维护从多个源事件聚合的一个或多个物化的数据集。 结果，系统的复杂性随着事件总线如今的要求而增长。咱们将在之后的文章中讨论这种模式。

3.分布式数据集成

正如前面所讨论的，微服务的分布式特性使得服务与服务的通讯和服务组合对于成功实现相当重要。尝试以一种主流的方式从头开始实现全部的服务，尽管这是可能的，但并不老是建议这样作，特别是在已存在专门的工具并帮助咱们简化工做的状况下。

实际上，从头开始编码全部内容，经过服务使数据可用于外部消费的例子是能够避免的。 咱们能够公开不一样商店中的数据，不只是使用现有框架的关系数据库，这些框架能够帮助咱们实现API组合模式，还可使用简单的数据即微服务服务。

分布式数据集中集成经过一个统一的API提供对任何存储实现中的数据的集成访问。数据集成容许链接和统一数据，即便数据存储在SQL或JDBC以外的不止一种数据源中。与数据库管理系统相反，它不该该存储任何数据，而应该做为一个single point(单点)接口来优化访问数据源。

显然，这种框架应该与微服务的分布式特性相兼容。所以，引擎和实现应该是轻量级的，而且可以做为容器部署在云环境中。它应该具备在运行时独立执行组件的灵活性，好比Spring Boot或将其嵌入到应用程序中。

4.总结

综上所述，除了在微服务体系架构中构建服务以外，还须要使用一般已证明的实践，如 Enterprise Integration Patterns(企业集成模式)和Data Integration techniques(数据集成技术)。在以轻量级和分布式方式提供安全访问层的同时，查询不一样数据源并将其链接以显示有意义信息的能力，能够简化您的应用程序。并且，正如 Christian Posta在他的微服务最难的部分:数据中所说，数据、数据集成、数据边界、企业使用模式、分布式系统理论、时间等都是微服务的难点(由于微服务实际上就是分布式系统!)

送福利啦~ 近期将以前已翻译文章，整理成了PDF。 ​ 在公众号后台回复：002便可领取哦~ ​ 后续也会不断更新PDF的内容，敬请期待！