如何为微服务选择数据库

你的微服务架构需要多种数据模型。你是应该选择混合持久化呢还是多模型数据库？

在过去的十年，大规模的分布式系统呈现爆炸式增长。这一趋势促使在数据库领域产生了一股巨大的创造力，这在软件业的历史上无疑是没有先例的。其结果是诞生了一个健康和充满竞争的数据库市场，我们可以因此在大量的平台中各取所需。但是我们应该如何抉择？

在本文中，我们将探讨如何为根据应用程序去选择核实的数据库模式。（是的MySQL 选择数据库，可以有一个以上的选择！），我们也会看看对数据模式的选择可以帮助确定在数据层中将选用哪些技术。

云架构，NoSQL 和微服务架构

随着开发人员开始创建可扩展的Web应用，历史上在数据架构上占主导地位的关系型数据库，开始显示出很大的压力。我们开发了非常流行的社交应用，并开始将越来越多的设备连接到物联网（IoT）。用户大量的读取和写入数据导致了必须扩展数据层，从而出现了新型的数据库来满足这些高可扩展性需求。

在许多情况下，这些新的数据库“NoSQL”或“非关系”的解决方案，所基于的数据模型和传统的关系数据库模型不同。NoSQL数据库包括有文档型、键值对型（key-value）、列式数据库甚至图数据库。通常来说，这些数据库牺牲了一些关系数据库的常见的的特性，如强一致性、ACID事务特性和join连接。

与此同时，和数据库技术的变革一样，在本世纪初的SOA（面向服务的架构），正逐渐演变为微服务架构的体系架构，许多企业也开始逐渐抛弃重量级的SOA体系架构如企业服务总线（ESB），并倾向使用“去中心化”的架构方法。微服务架构的魅力在于其开发、管理和扩展服务都是相对独立的。这给了我们很多在实施方面的灵活性，包括基础架构技术，如数据库。

举个例子，我们假设正在为微服务架构做开发工作，并期待着大规模的可扩展性的需求。无论这个项目是一个新的应用还是对现有应用的重构，我们都有机会针对数据库做出新的选择。

混合持久化（Polyglot persistence）

微服务架构风格的一个关键的好处，是持久性的封装。我们可以根据每个服务的需要，去选择不同的持久化技术。根据每种数据类型的特点而去选择数据存储的方法，被称为混合持久化，这一术语起初是由MarTIn Fowler等人推广起来的。混合持久化和微服务架构可谓是天作之合。

下图中，展示了一系列的微服务，以及我们如何为每个服务选择不同的数据模式。我不想在本文中，为每种类型的数据库去选择合适的用例。我的意图是要突出各类型数据库的优势，以及为什么混合持久化的方法是值得称道的.

其中，开发服务A的团队，因为该服务是基于大规模数据管理的核心应用，可能使用如Apache Cassandra这样的表格模型数据库。例如，一个零售应用库存应用，可能很适合使用Apache Cassandra。Cassandra提供了一系列协调机制工具，如可调一致，批处理和轻量级的事务机制，可以作为完整ACID事务机制的替代。

服务B支持用众所周知的关键字查找值的方式，例如针对产品目录的描述性数据。对于键值存储模型来说，这是一个很好的例子，在这里，我们通过一个众所周知的键值（如产品ID）查找一系列的数据。很多内存缓存都使用键值对数据模式去支持大规模的快速读取。

服务C可能主要关注半结构化内容，例如Web站点的表单或页面，而文档存储可能非常适合该类型数据。文档存储与键值存储有许多相似之处，但是一个关键的区别是文档型数据支持数据上增加结构，例如对特定属性进行索引以支持快速检索。

服务D可能涉及数据之间的复杂关系导航，例如客户数据和与组织中各部门的客户联系历史数据。这可能涉及其他服务所拥有的数据类型之间的关系。这是一个有趣的案例，因为它开始与上面提到的服务有各自的数据类型的约束相反。在这种情况下，你可以选择为你的服务创建一个具有对底层表的只读访问的图，然后通过这个“前门”处理所有的变化——即通过这个“前门”去调用那些“拥有”这些数据类型的其他服务的API。

最后，我们可能还有一个使用关系数据库技术的遗留系统或服务，或者我们有一个服务来管理那些数据量较少，或者不经常变更的数据。关系数据库可能完全适合于这些场景。

单个服务是否应该使用混合持久化？

（编辑：云计算网_宿迁站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!