前言
- 理解分布式进程和数据的影响，可以使团队尚在未具备处理分布式能力的时候，做出更好的MVA决策。
- 云计算并不能消除分布式问题，反而它可能会使问题更难解决，因为它隐藏了底层基础设施。
- 改变数据位置可能会对应用程序逻辑产生微妙的影响，这些影响很难发现，更难调试。特别注意对日期和时间戳的处理，作为MVA设计的一部分来考虑。
- 微服务架构非常适合模块化，但会使数据聚合变得更具挑战性。
- 对于高容量跨服务通信的考虑，可能意味着某些服务及其数据需要共同定位，以满足性能和响应性要求。
在云应用程序上开发很容易让开发人员觉得资源的位置不再重要，只要你所需的所有资源都在云中，这确实没有问题。
但是，一旦将移动应用程序引入其中，特别是对依赖传统数据存储中数据的应用程序而言，资源的位置，包括数据，就变得至关重要。
由于移动应用程序越来越受人们的欢迎，开发人员必须时刻牢记资源位置。
在本系列先前的文章中，我们介绍了最小可行架构（MVA）的概念，并描述了MVA如何改变思考使用架构框架、模式和策略的方式。
在本文中，我们将探讨与分布式计算工作和数据相关的模式和策略，同时讨论MVAs在分布式计算方面需要考虑的问题。
对于用户和开发人员而言，最令人无语的问题之一可以用一句话概括：“我的机器上运行好好的好……”，有时，这些问题与机器配置有关，开发人员和用户的机器配置不同。配置是静态的，这类问题只要细心对比是能够很容易发现的。
与应用程序逻辑或数据的分布相关的问题更为严重，而且往往是间歇性的。之所以这样，是因为分布式问题往往只有在高负载的情况下才会出现，对开发人员来说，除非能够在模拟真实的并发环境，否则很难发现这些问题。在网络带宽和吞吐量足够的情况下，分布式问题往往很难发现，只有当带宽或吞吐量不足时，开发者才会意识到架构决策的问题。在这种情况下，开发者往往会责怪网络问题，而疏忽分布式架构设计带来的问题。
分布式最重要的是什么
在当今光纤网络时代，在全球分布式部署数据和程序，我们就不需要担心程序是否正常运行以及数据是否正常吗？不，我们需要担心。即使程序运行在同一个数据中心，分布式引发的问题仍然会出现，全球分布式只是加剧了分布式带来的问题。对于分布式应用架构我们需要考虑两点：分布式应用程序（逻辑上的）和分布式数据（物理上的）。
分布式 MVA 应用程序
今天的应用程序具有高度的可移植性，这意味着它们可以相对容易地从一个计算环境移动到另一个计算环境，可以使用可移植语言，也可以使用虚拟机或容器。那么，为什么迁移代码运行的位置是一个架构问题呢?
即使应用程序代码是可移植的，容器隐藏了底层的计算环境，底层物理机器的痕迹仍然会使粗心的人出错。一个简单的例子是时间戳的问题，时间戳通常是由应用程序根据底层硬件设置的。如果一个应用程序在亚洲运行，而另一个在北美运行，那么亚洲应用程序可以为从在北美运行的应用程序的角度来看未来的日期和时间创建时间戳，因为亚洲应用程序和北美应用程序位于国际日期变更线的不同一侧。这可能导致故障和失败，从而导致整个应用程序崩溃，或者在依赖于时间的计算中产生奇怪的结果，例如隔夜银行资金的利息。当使用数据库服务器DATE函数设置时间戳并且这些服务器位于与应用程序不同的时区时，也会出现类似的问题，因为记录的日期将根据服务器的位置确定。
如果应用程序是由微服务组成的，可以在世界上任何地方的任何可用服务器上进行负载平衡，那么问题就更难发现了。在这种情况下，时间戳中使用的时区不容易预测。
一种解决方案就是使用统一时区，比如说使用 UTC 时区，这对于服务来说是一个重要的架构决策。虽然使用UTC并不能解决所有时间和日期问题，但也是一个很好的抉择。还有一些其他的问题需要考虑，比如日期/时间戳是否实际上需要包含时间组件（并非所有应用程序都需要，对一些应用程序来说，包含时间会带来困惑），屏幕和报告上的日期和时间应该如何显示（是本地日期/时间还是UTC日期/时间？）等等。你仍然需要解决重要的问题，但至少你可以基于对记录日期/时间的共同理解来做出这些决定。
另一个更微妙的问题来自于服务间的通信，当所有服务运行在同一个物理环境中时，以经过的时间来衡量服务间通信的“成本”的话是非常低的；换句话说，通信延迟很低。但如果这些服务被移动到不再在同一台机器上运行，甚至可能不在同一个地区，通信延迟可能会不可预测地增加，因为服务调用可能需要经过网络、桥接器和路由器，每个环节都会增加往返时间。与时间戳一样，负载均衡器在尝试平衡计算负载时可能会加剧这个问题，无意中增加了通信延迟。
分布式 MVA 数据
数据的位置是大多数最小可行架构（MVA）的关键考虑因素；在保持数据集中化的同时分布式部署应用程序，也许是因为大多数MVP所需的数据目前位于集中式的遗留数据存储中，很可能会产生延迟和吞吐量问题，以至于系统可能无法满足其一些质量属性需求（QARs），比如性能或可扩展性。
正如我们在之前的一篇文章中最小可行产品需要最小可行架构解释的那样，团队在开发MVA时的架构决策集中在产品如何满足其QARs上。持久性导致了许多最重要的QARs，特别是那些与产品存储和检索数据相关的QARs。
为了满足这些QARs，团队必须做出关于数据特征的决策，包括其结构或缺乏结构。他们还必须选择适当的数据存储技术（例如SQL DBMS、NoSQL DBMS等）。这些决策几乎总是涉及到数据将被存放的位置的决策，至少相对于应用代码的位置（例如在同一台服务器上、在同一数据中心中的不同服务器上、在不同数据中心中，包括不同时区的数据中心，或者在商业云中，因此没有固定或已知的位置）。
在许多方面，分布式数据可以想象成与分布式程序相同，但有一个重要的区别：返回数据的远程服务调用的消息大小可能足够大，值得特别考虑。例如，考虑一个查询远程服务器上数据库的应用程序。返回大量数据行的查询，这些数据行在应用程序中进一步分析，可能需要重新考虑；通过网络传输大量数据，无论速度多快，都是低效的。更好的方法是使用设计合适的视图、存储过程或位于与数据库相同机器上的远程服务，在尽可能相同的位置进行尽可能多的处理，以减少所产生的网络流量。这样做将减少延迟和不必要的信息处理，极大提高性能。
减少不必要的数据传输还可以对环境产生好处。通过减少不必要的处理，应用程序的碳足迹可以大大减少。绿色软件工程的原则之一考虑了数据和处理的位置，不仅仅是为了高效的应用程序，可以减少碳排放，而且还考虑了您使用的数据中心的环保程度，这是值得考虑的。
在某些情况下，数据所在位置的选择可能并不由团队决定；一些数据可能已经存在于遗留的数据存储中，但是他们仍然需要为需要创建和存储的新数据做出选择。当他们需要在回答查询、提供分析和准备报告时聚合新旧数据时，他们还必须解决跨这些不同来源的数据访问延迟所带来的问题。
基于微服务的架构也可能会带来一些与数据相关的问题。简单来说，每个微服务都将拥有自己的数据存储。如果微服务及其客户端和数据都是分布式的，那么由于网络延迟和带宽等限制，性能可能会受到影响。
考虑一个简单的SQL查询操作的情况，通常在单个服务器上进行，并返回一个或多个实体（表）的数据集。如果这些实体是微服务，那么相当于单个服务器连接的操作意味着需要遍历多个微服务来汇总所有相关数据。如果这些微服务是分布式的，调用开销和延迟将比在SQL数据库情况下严重得多。"每个微服务使用一个数据存储"的方法在解耦方面非常好，但不幸的是，它失去了关系数据库的简单查询数据的一些优势。和许多架构决策一样，需要在松耦合、性能和可集成性之间进行权衡。
例如，将具有相似职责的微服务组合到同一有界领域内，为每组微服务（有时称为“组件”）分配一个数据存储，以减轻性能和数据集成问题可能是有意义的。此外，利用数据网格方法将数据视为一个即用即得、可靠的产品，是以有界领域为基础组织数据并确保数据和相关处理以相同方式分布的有效方式。
另一种选择可能是为所有跨服务报告使用单独的数据库，并仅将服务拥有的数据存储用于事务负载。这种方法首先涉及捕获数据，然后再决定如何分析数据，有时被称为“读时架构 vs. 写时架构”。如果系统利益相关者可以接受营业结束报告而非实时报告，那么报告数据库可以以异步和低优先级的方式进行更新。这种方法适用于不需要实时分析的软件系统，例如商业保险系统，但不适用于证券交易系统或银行现金柜台支持应用程序。
无论 MVA 数据存储的设计和分布如何，都应该尽可能将处理过程放置在数据位置附近。出于类似的原因，通常在同一时间被访问的数据应该被放置在一起，以避免网络流量和延迟开销。
例如，如果在商业云中使用多个无服务器函数作为移动应用程序 MVA 的一部分，可能会面临满足性能 QARs 的挑战。需要频繁访问存储在公司数据中心中的数据的无服务器函数将需要在公司数据中心和托管无服务器函数的数据中心之间建立非常快速的网络连接，以便为移动用户提供快速响应——这是非常不太可能的。更有效的方法可能是要么将无服务器函数搬回公司内部，要么将数据转移到商业云中。
MVA 应该考虑什么分布式决策
我们概述的这些问题可以用一些关键问题来表达，团队在考虑其 MVA 时应该回答这些问题：
- 应用程序或服务是否可以部署在新的位置，或者必须在特定环境中运行？
- 数据是否可以动态保存在新的位置，还是必须保存在特定的数据存储位置？例如，一些国家要求对其公民的数据不得存储在国外，或者可能出于技术原因，例如应用相互间依赖协作问题，这些约束约束都会导致难以分布式部署。
- 某些服务或应用程序是否必须依赖其他服务或是否必须使用特定的存储服务？
- 如果负载均衡器自动移动数据或进程，那么 QARs 会受到影响吗？一般而言，负载平衡器的工作方式通常会影响应用程序如何满足qar，因此与负载平衡相关的决策往往在架构上具有重要意义。
这并不是详尽的清单；通过考虑数据和应用程序之间的相互作用以及这些相互作用可能如何影响系统的能力来满足其 QARs，团队可以提出自己的问题。
总结
采用云技术很容易让团队以为不需要担心程序和数据在分布式上带来的问题，但在某些方面，它使问题变得更加困难，因为在云中更难以看到真正发生的事情。云让团队误以为计算资源是由一个巨大的均匀池组成的，但实际上，在表面下始终有物理硬件和软件运行，就像隐藏的浅滩，团队必须穿过它们航行。考虑数据和进程分布问题将帮助他们找到正确的方向。
