微服务架构面向服务型架构_处理面向微服务的架构数据（第2部分）-CSDN博客

微服务架构面向服务型架构

这是我对PEAT UK播客的逐字记录：

你好，再一次到另一个热点。我的名字叫Peter Pilgrim，DevOps专家，Java企业和平台工程师以及Java Champion

微服务应用程序中的数据库架构是什么？

在真正的独立微服务中，它们的设计和构建遵循“单一责任原则”（罗伯特·马丁），即软件功能，类，程序包或聚合模块不是一件好事，而只有一件事好。

* [SRP]（https://en.wikipedia.org/wiki/Single_responsibility_principle）

单一责任原则是一种计算机编程原则，该原则规定每个模块或类都应对软件提供的功能的一部分负责，而责任应由类完全封装。它的所有服务都应严格地与这一责任保持一致。罗伯特·C·马丁（Robert C. Martin）表示以下原则：“一堂课只有一个改变的理由。” [1]

因此，SRP意味着微服务必须松散耦合，以便可以独立开发，部署和扩展

一些业务交易必须强制执行跨越多个服务的不变式。例如，下订单的用例必须验证新订单不会超过客户的信用额度。其他业务交易，必须更新多个服务拥有的数据。

一些业务交易需要查询多个服务拥有的数据。例如，“查看可用信用”用途必须查询“客户”以找到信用额度，并通过“订单”来计算未结订单的总额。

某些查询必须联接多个服务拥有的数据。例如，要查找特定地区的客户及其最近的订单，需要在客户和订单之间建立连接。

不同的服务有不同的数据存储要求。对于某些服务，关系数据库是最佳选择。其他服务可能需要NoSQL数据库，例如MongoDB，后者擅长存储复杂的非结构化数据，或Neo4J，Neo4J旨在有效地存储和查询图形数据。

理想情况下，应用程序中的每个微服务都应该是其自己的数据库副本，只有特定的服务才能访问。换句话说，一个微服务有一个私有数据库。让我们明确地说。微服务类的每个实例都拥有数据库的所有权，当我使用术语数据库时，它的含义非常抽象。数据库只是一个持久性存储，它可以是RDBMS，NoSQL或Graph数据库或其他持久性存储机制。因此，在这里我要说的是一个微服务的三个实例，一个库存仓库付款处理器访问一个分布式商店。因此，请想象一下。

假设我们需要处理一个峰值，然后可以将数量实例加倍到库存仓库支付微处理器服务中，然后有6个实例与我们的实例进行通信。我们可以再次将其加倍为12个通信，然后再将其加倍为24个通信（或连接）。现在，我们真的可以感受到从Java微服务到所谓的数据库的48个持久连接的压力吗？

确切地说，因为问题在于数据库需要扩展，并且对于我们非常私人的客户数据（包括您和我的客户）仍然需要保持原子性，一致性，隔离性和持久性。

因此，以我的经验，人们对微服务持久性数据库有不同的想法。对于某些人来说，理想是太多了，例如，客户可能会向AWS RDS Aurora寻求解决方案，因为他们知道该解决方案基于MySQL，而Amazon则引用了该服务器终端节点的可靠分布，从而可以扩展。 MySQL工作台可与远程Aurora RDS以及工作站或公司内部数据中心上的本地数据库一起使用。因为可以将AWS RDS视为具有多个架构的分布式数据库服务器，所以跨微服务实例共享的用户和表可能对客户具有吸引力。缺点显然是亚马逊要收取费用，当然还要担心客户数据的隐私和安全性。