mips体系结构透视_微服务的体系结构适应性透视

mips体系结构透视

重要要点

• 微服务不是万能药。 他们在现代建筑中占有一席之地，但没有任何地方。
• 了解业务领域对于评估基于微服务的体系结构是否合适是至关重要的。
• 单一责任原则是界定微服务功能边界的关键。
• 像其他任何体系结构样式一样，微服务受一组原则约束。 重要的是要了解与这些偏离如何影响给定的技术解决方案。
• 必须在分布式体系结构和分布式计算的更广泛的上下文中考虑微服务。

在本文中，我们研究了在主数据管理（MDM）上下文中微服务的潜在架构适用性，以及在解决需要计算密集型任务（例如预期损失的计算）的问题域时，基于微服务的架构可能面临的挑战。无担保消费信贷的投资组合。

我们将从介绍用于业务体系结构的元模型开始，并使用其元素及其关系来定义业务和问题领域。 然后，我们将介绍域驱动设计方法，以了解复杂的业务领域并协助创建技术解决方案。

然后将介绍微服务，这是一种新的体系结构范式，描述了它们的结构，并简要阐述了它们的优缺点。 然后将考虑微服务实现MDM数据中心的可能适用性。

最后，我们将探讨有限的条件，在这种条件下，基于微服务的体系结构可能适合或可能不适合涉及大量数据的计算密集型应用程序。

业务架构元模型

图1引入了简化的业务体系结构元模型，其元素用于定义整个文档中的业务域。 元模型包含五个元素，并且为每个构建基块提供了简要定义。

图1：简化的业务架构元模型

业务服务提供一些功能，这些功能可以满足组织内部或外部客户的业务需求。 业务能力表明组织为实现其业务目标而采取的行动，而不是组织如何实现的。 它们是业务体系结构的顶层，属于战略业务领域，并受组织的业务原则支配。 通常利用一个或多个业务功能来实现一个或一组业务服务。 业务能力由许多业务功能所确定，而业务功能又由许多业务活动实现。 然后将业务活动组织到业务流程中。 业务功能定义为一种业务行为元素，它根据一组选定的标准（通常是所需的业务资源和/或能力）对行为进行分组。 业务功能包含一个或多个业务功能。 类似地，业务流程被定义为根据行为顺序对行为进行分组的业务行为元素。 它旨在产生一组定义的产品或业务服务。 最后，业务活动代表业务流程中执行的工作。 （业务活动可以是原子活动，也可以是复合活动，但是这种区别不会影响当前的主题。）

业务功能，功能，流程和活动由组织中的一个或多个角色（即个人或团队）执行。

与建筑行业不同，软件开发方法仍然处于不断变化的状态。 在过去的20年中，从瀑布方法开始出现了许多方法，并导致了诸如SCRUM之类的敏捷方法，以及诸如Extreme Programming（XP）和Rational Unified Process（RUP）之类的类似方法。

域驱动设计（DDD）是软件专业人员可用于设计与问题域的思维模型匹配的软件的最新方法。 换句话说，领域驱动设计提倡基于实际业务的实际用例进行建模。 DDD以其最简单的形式包括将业务域分解为较小的功能块（可能在业务功能或业务流程级别），以便可以通过技术更好地理解和解决业务域和问题域的复杂性。 为此，图2说明了早期业务体系结构元模型的元素如何协作以形成两个业务域。

由于面向服务的体系结构（SOA）的许多记录在案的实现失败，或者仅仅是由于其自然发展，在过去几年中出现了一种新的体系结构样式。 尽管植根于SOA，但它集成了重要的面向对象设计原则。 这种新的体系结构风格以“单一职责原则”（SRP）为核心，并建议通过组合多个独立的服务应用程序来构建软件，同时在有限的上下文的帮助下从头开始分别开发它们。 DDD构造，表示一个或多个业务功能的逻辑子集，这些功能从给定角色的角度提供业务价值。 因此，该逻辑子集的边界定义了一个业务上下文，在该上下文中角色被约束为可以操作，如图2所示。这种体系结构样式的名称是微服务。

图2：域驱动设计和微服务–概念图

ThoughtWorks的James Lewis和Martin Fowler对微服务 的 定义 如下 ：“简而言之，微服务架构样式是一种将单个应用程序开发为一组小型服务的方法，每个小型服务以其自己的进程运行并与轻量级机制通信，通常是HTTP资源API。 这些服务围绕业务功能构建，并且可以通过全自动部署机制独立部署。 这些服务的集中管理几乎没有，可以用不同的编程语言编写并使用不同的数据存储技术。 微服务的定义很重要，因为它确定了一些关键原则，这些原则随后被用来证明本文所采取的立场是正确的。 图3试图将这些基本原则可视化地覆盖在微服务的结构之上。

图3：微服务剖析

为了说明域驱动设计和基于微服务的体系结构，让我们看一个以事务处理成本分析（TCA）为中心的示例。 图4描绘了一个典型的交易时间表，它提供了通常在何处进行分析的指示。

资产管理公司可能拥有最佳的投资模型，但在实际交易金融工具之前，它们毫无价值。 任何金融投资组合的总体绩效都会受到基础资产类别的选择和分配，实施质量以及其他关键因素的影响。 确实，与通过购买和出售工具实现投资组合相关的成本通常会降低投资组合的回报。

图4：交易时间表

投资组合的实施成本可以将高质量的投资变成中等收益的投资，或者将劣质的投资变成无利可图的投资。 因此，投资经理必须主动管理交易成本，因为较低的交易成本意味着较高的投资组合收益。 通过为投资策略和交易绩效提供更大的透明度，TCA帮助投资经理降低交易成本并确定其投资组合交易的有效性。

因此，使用我们较早的业务架构元模型，可以将最简单形式的TCA建模为由三个业务功能所确定的业务功能，如下所示

在图5中。

交易成本计量业务功能通常受显性成本和隐性成本的影响，如下表所示。

图5：交易成本分析–简化的业务领域。

表1

显性成本和隐性成本的引入表明，可以将“交易成本度量”业务功能进一步分解为至少两个子域：“显式交易成本度量”和“隐式交易成本度量”。 为简单起见，我们将省略其他业务功能的DDD功能分解。

图6提出了显式交易成本度量和隐式交易成本度量业务功能的基本上下文映射。 在关于DDD的开创性工作中 ，埃里克·埃文斯（Eric Evans）指出，上下文地图被指定为用于使上下文边界明确的主要工具，因为它从有限的上下文和业务域的角度显示了微服务。 在TCA示例中，为每个子业务功能确定了五个可能的微服务。

图6：用于交易成本分析的简化上下文映射

基于微服务的体系结构具有许多优势。 此范例引入的模块化提供了轻松，快速的开发，以适应业务发展的步伐。 更新功能子集很容易，因为它位于一个或几个软件中。 同样，微服务的模块化本质从本质上增强了安全性和故障隔离。 实际上，如果给定的一组代码被破坏或破坏，则可以与其余服务充分隔离，从而防止整个应用程序变得不可用。

但是，微服务也存在许多缺点，编排就是一个很好的例子。 确实，大量微服务的协调可能会面临挑战，特别是当每个微服务负责其自身的交互时。 数据存储是可能会带来困难的另一方面。 因为每个微服务都负责其自身的持久性，所以由多个微服务组成的应用程序中的数据冗余很可能会发生，并且可能会影响传统上执行主数据管理的方式。 报告是受微服务影响的另一个领域。 而且，微服务的分隔可能使集成测试变得困难。 这些优点和缺点不应视为详尽无遗； 提供它们只是为了完成我们对微服务的介绍。

本文的其余部分介绍了两个特定的主题领域，以探讨此新范式可能的体系结构适用性和不适用性。 因此，首先在主数据管理的上下文中检查了基于微服务的体系结构的适当性。 随后，在诸如大量损失分配计算之类的计算密集型任务的背景下，它的适用性受到了挑战。

主数据管理是一个广阔的领域， 简要定义将有助于进行水平设置。 “主数据管理是旨在创建和维护权威，可靠，可持续，准确和安全的数据环境的流程和技术框架，该环境代表了主数据及其关系的真实的单一整体版本……”。 主数据被定义为“……对于企业至关重要且是关键业务流程和应用程序系统基础的那些实体，关系和属性”。 客户，州，邮政编码，货币符号或证券代码是此类实体的一些示例。

在功能上，MDM需要通过清除，丰富和丢弃冗余数据来主动管理主实体，如下面的用例图所示。

图7：MDM用例图-简化视图

多年来，MDM的技术实施不断进步，以更好地解决该领域的企业本质。 这种演进的特点是为了解决MDM技术解决方案的可扩展性，可维护性，可扩展性和性能而引入了新的体系结构范例。

图8直观地追溯了MDM Data Hub的体系结构演变，从客户端服务器应用程序到可能的基于微服务的体系结构。 接下来的几节将回顾如何利用整体和传统SOA体系结构来实现主数据中心解决方案。 随后提出了基于微服务的体系结构，作为可能的体系结构替代方案。

图8：MDM Data Hub-体系结构演变

特别是在分布式体系结构和面向服务的体系结构问世之前，主数据管理通常作为单片应用程序的一部分进行了改进。 MDM功能及其关联的逻辑与解决特定业务或问题领域的应用程序功能结合在一起。 同样，MDM数据的持久性也与系统的事务域结合在一起，如图9所示。例如，用PowerBuilder 6或Visual Basic 6编写的客户-服务器交易应用程序通常会存储其MDM-相关实体，例如客户，州代码或安全性，用于记录单个交易的同一基础数据库中。

图9：整体/客户端-服务器MDM数据中心架构

尽管MDM与事务数据的物理接近度几乎没有延迟，但是从体系结构的角度来看，MDM与特定于业务的功能的这种耦合引入了体系结构的刚性，从而阻止了每个功能区域独立发展。 此外，在企业级别，这种架构范例通常会生成功能和数据重复项，如图10所示。

图10

如图11所示，采用分布式体系结构，尤其是SOA，可以实现与MDM相关的和特定于域的实现（关注分离原则）的功能和持久性解耦，如图11所示。无论MDM体系结构的样式如何（存储库，注册表或注册表）其他），这种分离提供了增强的体系结构灵活性，允许每个域解决方案独立增长以适应其各自的功能需求。 但是，直到引入NoSQL数据库之前，由于没有合适的替代方法，MDM数据的持久性仍保留在关系存储库中。

图11：传统的SOA MDM数据中心体系结构–注册表样式

从数据体系结构的角度来看，许多MDM Data Hub实施都利用了主从结构或其变体之一，例如分片。 在主从方法的情况下，许多服务器处理读取请求，但是只有一台（或者在分片的情况下为少数）服务器可以实际执行写操作，以将主数据保持在一致的状态，如图所示。 12

图12：主从架构

该体系结构经常引入单点故障，这可能会限制实现高可用性和无缝水平扩展的能力。 因此，数据体系结构是实现MDM Data Hub解决方案时要考虑的重要方面。 自从NoSQL数据库出现以来，情况尤其如此，因为它们提供了可靠的替代方案来存储主数据，尤其是在与微服务结合时。

传统的SOA已经启用了MDM和以业务为中心的OLTP应用程序之间的功能和持久性隔离，从而促进了整个企业中主数据的更大复用。 通过为分布式体系结构提供更好的支持，微服务基于这些优势，尤其是在涉及多区域的情况下（另一篇文章的主题）。 确实，它们的重点功能边界和部署模型允许将微服务部署在其使用者附近，从而可能提高可用性，可伸缩性和吞吐量，如图13所示。而且，每个微服务负责其自身数据的事实意味着该结构和特性。可以调整主数据的存储，以更好地满足使用服务或系统的需求。 例如，键值存储库可以支持状态码微服务，而不是RDBMS中的表。 可以在不同的地理区域中部署此微服务的多个实例，以补充在东海岸运行的客户端入门应用程序或在西海岸运行的计费服务。

图13：基于微服务的MDM数据中心架构

但是，重要的是要针对一些可能的缺点评估这种新的体系结构范例。 例如，合理化或实体解析，清理和扩充功能可以在每个与主数据相关的微服务中复制。 同样，由于MDM的本质似乎正在从企业转移到更接近有限的上下文，因此不能保证整个组织中主实体的唯一性。 结果，我们甚至可能需要重新考虑在尺寸设计中使用一致的尺寸。

接下来，该文档探讨了是否可以利用微服务来解决需要大量计算的业务领域。 为此，我们以计算具有5000万条记录的零售信用卡组合的总损失分配为例。 图14直观地概括地描述了基于单个损失事件生成总损失分布的步骤。

图14：总损失分布

从年度总损失的角度来看，零售信贷市场是独特的，因为与大型批发贷款不同，不能仅通过缩小模型来进行分析。 根据一项分析， “零售信贷市场向通常没有评级的小型借款人提供资金。 每笔贷款的规模相对较小，意味着任何单笔贷款的信用风险的绝对规模都很小。 任何单笔零售贷款的损失都不会导致银行破产。 因此，就避免损失而言，确定零售贷款信用风险的每笔贷款成本通常大于收益，因此以个人零售贷款为基础确定信用风险可能不值得。

因此，开发一种技术解决方案来评估几个帐户的信用风险可能不具有经济意义，并且任何解决与无抵押贷款相关的信用风险的技术解决方案都必须在大量帐户上运行才能在经济上明智。 而且，与此业务领域关联的数据量是可能使基于微服务的体系结构不适合解决计算密集型任务的关键方面之一。 本文专门针对基于微服务的体系结构可能会带来挑战，以为无抵押信用卡组合生成总损失分布，提出了三个理由。 他们是：

• 数据和数据存储的异构性
• 计算能力/强度
• HTTP语义不适合

数据和数据存储的异构性

从概念上讲，鼓励微服务根据其支持的有限上下文拥有其数据和存储。 与每个微服务关联的数据的格式，内容和存储可以进行调整，以最好地服务于每个业务功能的功能，如下图所示。 结果，可以在基于微服务的体系结构中找到各种数据存储库（RDBM和NoSQL）。

图15：微服务架构-概念图

但是，预期损失和风险价值计算均依赖于时间序列数据。 这意味着源数据不仅必须是完整的，而且还必须极其一致和标准化，从而几乎没有空间容纳任何数据模式的异构性。 因此，图15中描述的概念体系结构必须如图16所示发展，以适应时间序列要求。 这样，存储库的两个实例可能会变得多余，从而使微服务共享同一数据存储，这违反了微服务的核心原则之一。

图16

从功能的角度出发，并基于图16，下图描述了可能的上下文映射，用于生成总损失分布（年度总损失）。 从概念上讲，将步骤分解为微服务似乎是可以接受的方法。

图17：总损失分布的可能上下文图

但是，这是数据阻抗可能再次违背微服务的核心原则之一的地方。 总损失分布的计算以单个损失事件为起点。 如前所述，所有丢失事件记录必须遵循相同的架构。

第一步包括为所有单个损失事件创建风险矩阵。 尽管是中间步骤，但第一步的结果可能会被存储。 为了简化文档，特意排除了ACID要求。 为了遵守微服务原则之一，微服务负责管理自己的数据和基础存储，如图18所示。

图18

第二步涉及损失分布的生成。 用于此有限上下文的微服务将需要第一个微服务的结果来履行其职责，但是损失分布微服务不应直接访问Risk Matrix Loss Data上下文中的数据，否则将引入紧密耦合，从而使基于微服务的架构，如图19所示。

图19

因此，损失分配微服务有两个选项可以从“风险矩阵损失数据”上下文中获取数据。 第一个涉及对“风险矩阵损失数据微服务”的READ调用，如图20所示。但是，此选项是不现实的，因为将需要移动数百万条记录。

图20

第二种选择是将数据从“风险矩阵损失数据”上下文复制到“损失分布”上下文。 从技术上讲，这比以前的选择更可接受，但是，数据移动的需求将影响整个过程的性能，尤其是当需要移动数百万条记录时。

VaR计算和总损失分配微服务都将遇到与刚刚描述的问题类似的问题，因此为简洁起见，我将省略它们。

数据移动方面可以通过引入数据缓存来解决，如图21所示。该设计实质上将使微服务共享相同的数据存储（尽管是虚拟的），从而再次规避了基于微服务的体系结构的主要宗旨。 另外，作为一个附带说明，可以在每个有界上下文中添加数据存储以保留中间结果，并允许在三个步骤中的任何一个中重新进行计算。

图21

图21中的架构导致第二个原因，即微服务可能不适合进行计算密集型计算，具体取决于为支持微服务而选择的基础架构。

计算能力/强度

图22代表了托管微服务的典型基础架构设置。 第一个选项显示了在3个节点集群上部署的微服务＃1，其中每个节点包含2个CPU（负载平衡器已被有意省略）。 第二种配置显示微服务＃2部署在由2个物理服务器组成的虚拟集群中，每台机器还具有2个CPU。

图22：微服务的典型部署

这些基础结构设置通常在处理OLTP系统时是合适的（容错，负载平衡，可伸缩性），但可能不足以容纳计算密集型任务，尤其是与任务场和网格计算相比时，如图1所示。 23。

图23：网格架构和任务场并行

HTTP语义不适合

与HTTP协议关联的语义也可能使基于RESTful的微服务难以用于计算密集型任务的另一个方面。 从功能的角度来看，HTTP请求与与处理一个或有限数量的记录（可能是几百个）相关联的事务动作紧密对应，如下表所示。

软件设计技术建议建议公开一个反映基础程序实际功能的公共接口，以便消费者可以毫无歧义地使用它。 因此，在总损失分配计算的上下文中，支持损失分配上下文的微服务应公开一种或多种方法来传达产生损失的分布，这与CRUD操作相反，如下图所示。 因此，从语义上讲，HTTP协议似乎缺少处理非本质上不可操作的操作所需的词汇。

图24

为了进一步说明这一点，我们假设与“损失数据风险矩阵”上下文关联的微服务可以生成成千上万个记录矩阵（如果不是上百万个记录）。 如前所述，下一个功能步骤涉及损失分配的创建。 但是，微服务提供的支持损失分配上下文的操作与需要在风险矩阵上执行的任务之间在功能上不匹配。 实际上，基于它们的名称，第二个服务公开的HTTP方法都不应该包含生成损失分布的代码。 图25展示了Loss Distribution微服务应公开的公共接口。

图25

但是，更改第二个微服务的公共接口以更好地反映其功能责任并不能解决将数百万条记录从一个微服务传递到下一个微服务的根本挑战。 从技术角度来看，适当的解决方案将寻求最大程度地减少数据移动，因此Hadoop生态系统以及Apache Cassandra可能是值得探索的相关技术。

总而言之，当可以很好地描述每个微服务的数据和功能并且将相互依存关系保持在最低水平或至少受到控制时，基于微服务的体系结构可能会发挥最佳作用。 OLTP或事务处理系统可能非常适合基于微服务的体系结构，只要不严格要求ACID特征（CAP定理并最终保持一致）即可。 但是，在解决链接到分析空间的问题域时，可能很难获得与该体系结构范式相关的好处。

翻译自: https://www.infoq.com/articles/Microservices-Architectural-Fitness/?topicPageSponsorship=c1246725-b0a7-43a6-9ef9-68102c8d48e1

mips体系结构透视