翻译|杨小娟策展|云召系统中的数据远比构成系统本身的应用程序更有价值，这似乎有些老生常谈。应用程序被更新、更改、禁用和替换，但数据仍然存在。对于许多组织而言，这些数据是他们最重要的资产。以前很简单，你有你组织的数据库，你组织的所有信息只有一个地方，你可以从那里得到你想要的所有内容。一个用于管理、监控、优化、备份等的数据库——负责承担整个组织的数据需求。随着组织的发展，数据不断增长，因此越来越多的需求被添加到数据库中。在某个时候，达到了极限。使用单一数据库的做法已经不够了，必须将系统和数据库分解成独立的组件。在本文中，我将讨论如何管理数据范围和大小的增长。1.共享数据库的消亡，为什么不能使用更大的机器虽然并不少见，但如今拥有数十亿记录的TB级数据库并不少见。所以有什么问题？问题不是特定数据库引擎的技术限制。相反，组织将所有内容都放入一个数据库中。比如我工作的一家公司，数据库里有30000多张表，还有更多的视图和存储过程，更不用说触发器的数量了。没有数据库工具可以处理如此多的表。每次GUI工具连接到数据库时，它总是会导致工具在短时间内读取模式描述时冻结几分钟。没有人知道数据库内部发生了什么，但数据及其相关流程对于组织的成功至关重要。最终结果：要么停滞不前，要么开始将数据库分解为可管理的组件。那是几年前的事了，行业格局已经发生了变化。今天，当我们考虑数据时，有更多的问题需要考虑，例如：属于欧洲公民的个人数据，这意味着与他们相关的任何数据也必须物理存储在欧盟并受??GDPR规则的约束。医疗保健信息（直接或间接），受一套全新的规则约束（例如，HIPAA、HITECH或ENISA规则）。数据隐私和来源等问题更为重要，例如能够审计和分析谁访问了特定数据项，以及为什么它是许多领域的硬性要求。组织中的所有信息都驻留在一个存储桶中的概念不再可行。另一个重要的巨变是常见的架构模式。我们现在不再使用单一的整体系统来管理组织中的一切，而是将系统分解为更小的组件。这些组件有不同的需求和要求，按不同的时间表发布，并使用不同的技术。当您想更改自己的系统时，尝试协调所有这些团队的巨大开销是尝试在您的系统中进行更改的一大障碍。在如此多的团队和组件之间进行协调的成本令人望而却步。一般的想法是使用独立的应用程序数据库而不是单个共享数据库。这是一个更大的建筑概念的重要组成部分。微服务和面向服务的架构通常就是这种情况。2.应用数据库作为实施决策从单个共享数据库迁移到一组应用数据库之间最重要的区别之一是没有拆分共享数据库。数据库级别的适当分离是关键。一组共享数据库会出现完全相同的协调问题，因为厨房里的厨师太多了。应用程序数据库的适当分离可以为每项任务选择最佳数据库引擎、更改本地化以及减少通信更改的开销。这种方法的缺点是需要在生产中支持更多的系统。让我们更深入地讨论共享数据库和应用程序数据库之间的区别。很容易弄错，例如图1所示：图1：从单个共享数据库到多个（仍共享）数据库的错误迁移路径虽然共享数据库是您实现的，因为没有其他选择，应用程序数据库是内部选择，只有应用程序才能访问。封装与面向对象编程具有相同的含义，使用私有变量隐藏状态，并且可以肯定的是，应用程序数据库是一个应用程序外部不应该关心的问题。我有同样的感觉。在写代码的时候，直接使用其他对象的私有状态是错误的。如果违反了不变量，以后的维护和开发就会很复杂。这已被大量事实证实，因此大多数开发人员不这样做几乎是本能的。直接访问另一个应用程序的数据库也会发生完全相同的事情，但这很常见。在某些情况下，我对数据库中的所有表名和列名进行了加密，以表明您不应查看我的数据库。应用程序数据库应该只是应用程序的内部关注点。这个想法很简单。如果应用程序之外的任何实体需要一些数据，它需要从应用程序请求它。不应将它们直接提取到应用程序数据库中。这是询问“你在和谁说话”和查看他们所有的通信和消息之间的区别。从理论上讲，这是一个很好的做法，但需要考虑的是，你的应用不仅仅是系统的一个应用，还必须与生态系统的其他部分进行集成。问题是你如何做到这一点。如果此处描述的系统听起来很熟悉，那是因为您可能以前听说过它。它最初是DCOM/COBRA系统的一部分，后来被称为ServiceOrientedArchitecture，现在被称为Microservices。假设我们系统中处理发货的应用程序需要访问一些客户数据以完成其任务。如何得到这些数据？使用共享数据库时，直接查询客户表。当负责客户应用程序的团队需要添加列或重组数据时，您的系统就会崩溃。它们之间没有封装或分离。直接依赖另一个团队的实现细节的方式会导致中断、停滞和不断增加的复杂性。3.使用全局数据或者，运输应用程序可以请求（通过已发布的服务接口）拥有客户数据的应用程序以获取所需的详细信息。这通常通过从一个应用程序到另一个应用程序的RCP调用来完成。问题是，这样做会在两个应用程序之间建立牢固的连接。如果客户的应用程序因维护而停机，则运输应用程序将无法运行。加上数十个这样的应用程序及其相互依赖性，您就有可能出现死锁。我们需要想一个更好的方法来处理这种情况。我的建议是从另一个方向来处理整个过程。运输应用程序不会向客户应用程序查询相关数据，而是执行相反的操作。作为客户应用程序服务接口的一部分，将哪些信息公开给组织的其他部分完全由您决定。重要的是要注意，发布的数据绝对是服务合同的一部分。不提供对数据库的直接访问。应用程序应该向外界发布它们的数据。可以是每天上传到FTP站点或GraphQL端点的CSV文件，以在两种截然不同的技术和语义之间进行选择。我在FTP上包含CSV的方式明确表明数据共享无关紧要。从应用程序发布数据的既定方法很重要，因为这种架构风格的一个关键方面是不必在需要时查询数据。相反，我们将其吸收到我们自己的系统中。我想很明显为什么运输应用程序没有打开与客户每日CSV转储文件的FTP连接来查找详细信息。同样，它不应将查询GraphQL端点作为其常规例程的一部分。相反，我们有一个既定的机制来发布客户的数据（客户应用程序向组织的其他部分公开）。这是由系统中的其他应用程序摄取的，当他们需要查找客户详细信息时，他们可以从自己的系统中进行。如图2所示：图2：客户应用程序发布供运输应用程序使用的数据在每个应用程序中，数据可以不同地存储和表示。在每种情况下，什么最适合他们。发布应用程序还可以按照他们选择的任何方式处理数据。数据库和数据发布方式之间的服务边界允许在不与外部系统协调的情况下自由修改内部细节。另一种选择是使用两阶段流程，如图3所示。客户应用程序不是将更新发送到运输应用程序，而是将它们发送到组织数据湖。通过这种方式，每个应用程序将它希望公开的数据发送到一个中央位置。其他应用程序可以将他们需要的数据从数据湖复制到他们自己的数据库中。图3：每个应用程序将数据发布到数据湖并将数据拉取到每个应用程序最终结果是一个共享数据的系统，但应用程序和服务之间没有时间依赖性。它还确保了不同团队和系统之间的界限。只要发布的界面保持不变，就不需要协调来增加复杂性。4.实践中的一些建议我们深入研究了一些关于如何应用这种架构方法的具体建议。可以通过在服务总线上发出事件或发布每日文件来在全球范围内发布数据。可以发布特定场景的数据，例如从客户数据库到出货数据库的ETL过程。只要有适当的边界，局部方法的改变对整体的影响很小。这种操作方式只有当你需要引用数据或者对与一致性无关的数据进行决策时才有用。如果需要对数据进行更改或协调，则此方法不适用。一致性无关紧要的一个很好的例子是根据他们的id查找客户的名字，如果我们有旧名字，那没什么大不了的。很快就会自行修复，我们不会根据客户的名字做出决定。同时，我们可以在应用范围内完全在本地运行所有的计算和任务，这是一个很大的优势。当我们需要做出决定或修改数据时，一致性很重要。例如，在托运场景中，如果要收取超重费，需要保证客户账户中有足够的资金。在这种情况下，我们不拥有账户中的资金，也无法对我们自己的数据进行操作。于是需要和客户端发起一个申请请求，要求将这些资金扣款，如果资金不足就报错。请注意，如果客户无法付款，则更合理的结果是：装运操作失败。应用程序不应再部署到单个服务器甚至单个数据中心。如今，在边缘系统上运行应用程序非常普遍，例如移动应用程序或物联网设备。将所有这些数据推送到您自己的系统中可能会导致无法承受的大量数据要存储。数据封装和仅公开您想要公开的细节的架构风格在这种情况下非常有效。数据存储在边缘，而不是将所有信息复制到中央位置，并且从边缘设备接收到足够的数据，以便能够做出决策并操作系统的全局状态。除了其他优势之外，这种方法让用户可以控制他们的所有数据，我认为这是一个主要优势5.最后写入在模式中使用应用程序数据库和显式数据发布有几个原因。首先，这意味着运营需要本地资源和最少的协调。这反过来又意味着这些操作更快、更可靠。其次，它减少了整个系统的协调开销，这意味着每个应用程序都可以根据需要独立部署和更改。最后，这意味着可以为每个场景独立选择最佳选项。可以为每个选项选择最佳品种，而不是迎合最低公分母。例如，您可以使用文档数据库来存储发货清单，但将历史数据放在数据湖中。每个应用程序都是自包含和相互隔离的，可以针对每个场景做出最佳技术选择，而无需考虑任何全局约束。结果是一个更容易修改、由更小的组件组??成（因此更容易理解）且更敏捷的系统。译者介绍杨晓娟，社区编辑，高级研发工程师，信息系统项目经理。原文链接：https://dzone.com/articles/data-management-in-complex-systems
