英语原文共 16 页，剩余内容已隐藏，支付完成后下载完整资料
微服务体系结构的上下文理解：当前和未来方向
摘要
当前行业趋势表明了从面向服务的体系结构（SOA）到微服务的转变。通过了解这两种架构之间的关键区别及其特点，我们可以通过避免SOA的缺陷来设计更有效的微服务体系结构。要做到这一点，我们必须知道为什么会发生这种转变，以及基于微服务的系统的关键特性是如何处理关键SOA功能的。不幸的是，微服务并不能解决所有SOA缺点。此外，微服务带来了新的挑战。本文详细分析了这两种体系结构之间的差异及其特点。接下来，我们将从研究和行业的角度来描述这两个体系结构方向的优缺点。最后，我们进行了与微服务研究相关的系统映射研究。
关键词
SOA；微服务；体系结构；自包含系统；
系统研究
1导言
在过去的几十年里，行业需求将软件设计和架构推向了不同的方向。企业应用程序的日益复杂，以及变更和演化管理带来了体系结构的兴起，如通用对象请求代理体系结构（CORBA）、Java RMI和企业服务总线。面向服务的体系结构（SOA）取代了它的前身，成为大型企业多种行业需求的解决方案；然而，微服务体系结构（Microservice Architecture，服务）似乎准备取代SOA成为主导行业体系结构。
SOA和服务都建议将系统分解为网络上可用的服务，并可跨异构平台集成。在这两种方法中，服务协作为整个系统提供功能，因此共享相同的目标；但是，实现目标的途径是不同的。SOA侧重于将系统分解为简单服务的设计，强调为整个公司的IT服务集成智能路由机制。智能路由机制提供全局治理或所谓的集中式管理，能够在服务、消息处理和服务监视/控制之上实施业务流程。SOA服务是不耦合的，在不知道事件触发器的情况下进行响应。通过对此类事件作出反应，可以很容易地集成新服务。例如，一个服务可以写一张发票，另一个可以发起交付。一个新的日志系统可以只监听事件，而不影响其他服务。相反，微服务建议在考虑简单路由机制的同时，更倾向于智能服务，而不考虑SOA中的全局治理。这自然会导致更高的服务自主性和解耦性，因为服务不需要在全球级别上就合同达成一致。但是，服务将负责业务流程管理以及与其他服务的交互。
然而，还有其他观点需要考虑。SOA的特性包括事务、安全等所需的复杂的web服务协议栈，覆盖所有可互操作的服务。此外，由于SOA支持在集成级别的服务之上构建业务流程，因此它带来了更改流程的灵活性，但同时将所有服务绑定到单个通用上下文。因此，表示服务操作的服务契约将其数据类型暴露出来，从而导致与部署相关的依赖关系，在极端情况下，会导致一个大型单体应用部署。
在微服务中，可以使用轻型和异构协议进行服务交互。每个服务只维护它的上下文和它自己对特定数据的透视图，这可能导致服务之间的重复。如果服务之间存在部署依赖关系，那么它们的规模要小得多，因为不存在一般上下文和集中式治理。服务的主要目标是支持独立的服务部署和演进。
上述特征导致多重后果。例如，有选择地部署服务以扩展它是相当容易的；然而，在SOA中这并不容易。SOA集成机制和集中式治理预先决定了系统需要扩展时的瓶颈。当在某些SOA特性中出现伸缩问题时，很难确定瓶颈在哪里，以及是服务本身、集成还是共享数据库。当涉及到弹性、可扩展性、自动化和连续部署以及快速的需求响应时，自包含的服务更加高效。上述特性使微服务更加云友好。
这种灵活性的代价是服务必须跨服务重述和重新定义数据定义，甚至业务规则，在数据库中引入复制，缺乏对整个系统处理、规则、约束等的集中视图。
行业似乎正在转向微服务，而将SOA抛在了后面。然而，微服务并不是SOA的超集，它的许多挑战并不存在于SOA中。对这些体系结构的各种解释使社区的一部分人认为微服务是SOA的一个子集，尽管其他许多人认为它们是不同的体系结构。
在本文中，我们的目标是描述SOA和微服务之间的区别，以便读者清楚地了解两者之间的区别。我们还指出了每种方法的优点和缺点。此外，我们还介绍了每种方法来消除术语歧义，并让读者对特定方法的好处有一个坚实的理解。由于微服务似乎是行业未来的发展方向，因此我们将重点放在该体系结构必须面对的挑战上。第2节提供了背景。接下来的两部分将详细介绍SOA和服务。第5节提供了一个例子来启发这些差异。架构比较是第6节的主题。第7节讨论了服务集成中的开放研究挑战。第8节提供了一个有关服务的映射研究，介绍了100多篇论文中现有工作中解决的挑战。最后一节对全文进行了总结。
2背景
SOA和微服务是用于将系统分解为服务的两种主要体系结构。问题是如何协调服务以实现特定的用例。一般来说，有两种广为接受的方法：集中协调和独立或分布式。集中协调的方法是SOA的常见模式，而分散的方法是服务的主要模式。在本节中，我们提供术语的定义
图1：服务编排。
这有助于我们比较和对比这两种架构。
服务是一种可重用的软件功能，可供各种客户机用于不同的目的，以强制执行控制规则。它实现域的特定元素，定义其接口，并且可以在网络上独立使用。在涉及到众所周知的接口和通信协议的同时，它带来了平台独立性。在SOA中，服务在目录或注册表中注册以方便地定位它们。为了减少耦合，服务被组合以产生结果。
集中和分散的交互模式分别称为编排和编排。它们指示服务如何协作、活动序列如何，或者业务流程是如何构建的。服务编排需要一个集中的业务流程，通过不同的服务协调活动，并结合结果。图1描绘了服务编排。
编排没有用于服务组合的集中式元素。服务编排描述消息交换、交互规则以及交互服务之间的协议。控制逻辑不在一个位置。图2。描述服务编排。
当通过中介层涉及编排时，我们通常会引入规范化的数据模型。在这种模式下，各个系统方就其交换的业务对象商定或标准化其数据模型。然而，通常整个系统最终只有一种业务对象。例如，有一个人、订单、条目、发票等，具有匹配的属性和关联，因为每个人都同意这些属性和关联。引入这样一个带有编排的模型是很容易的；但是，后来对模型的更改非常困难，因为各方必须就其达成一致，而且单个系统在进化上有限制。
由领域驱动开发产生的另一种方法称为有界上下文。在这里，每个服务的目标是在特定的上下文中使用特定的业务对象，因此某些服务考虑某些属性而忽略其他属性可能是有意义的。例如，我们可以考虑一个用户的地址来处理发货，而忽略其他地址；但是，对于价格计算，只需要用户的客户排名就足够了。因此，大模型被划分为小上下文，允许根据特定需求对业务对象进行不同的建模。并不是所有的服务都有相同的需求，因此应该独立地设计它们的需求。
图2：服务编排。
3．面向服务的体系结构
软件架构师使用SOA或微服务的主要原因是将系统模块化为服务。然而，SOA需要大量的前期承诺，因为整个公司都必须将其分发到不同的服务中。引入一个新的SOA服务相当容易；可以采用一个遗留应用程序并为其定义一个新的网络可访问接口。更高级的设计将应用程序划分为多个服务，以实现更广泛的服务重用和服务编排。在引入SOA时，最具挑战性的任务是建立集中式治理、负责组件的服务集成及其通信。通常，集成的解决方案是形成SOA主干的企业服务总线（enterpriseservicebus，ESB）。如前所述，它支持编排；此外，当多个服务对特定事件作出反应时，服务可以通过触发器未知的消息或事件进行交互。此外，可以在集成级别定义业务流程，从而允许灵活的重新配置。然而，这种解决方案倾向于引入规范化的数据模型。这里的关键是，集成平台是智能的，但也很复杂。出于这个原因，SOA有时被称为“简单服务和智能管道”[62]。系统顶部通常是用户界面的一个独立组件，例如门户或专用web系统。图3展示了一个具有两个系统（a和b）的SOA部署示例，这两个系统公开了上面集成平台的服务。然后，用户界面部分通过集成组件与服务通信。
当有足够的服务可用时，SOA的主要优势就会显现出来。业务流程通过对公司流程的控制来实现服务编排。组合服务、引入处理流程的替代方法以及构建新功能变得很容易。这些服务甚至可以向第三方开放。然而，布局通常是由不同的团队维护不同的系统部件（如图3中的A和B）。对于集成组件或用户界面，通常存在单独的团队。当更改引入界面修改的特定服务时，更新很可能会升级到集成级别，以及需要重新部署多个组件的用户界面。以这种方式，SOA部署作为一个包含多个服务的整体进行；一个有缺陷的服务可能会阻止整个应用程序部署和复杂的回滚。
情况变得更严重，因为流程跨越了专门用于不同团队的服务，加剧了通信开销，并要求开发和部署的一致性。除此之外，公司往往有一个集中的管理单元来管理SOA服务基础设施中的所有更改，这导致了对单个服务演化的保守和限制。
SOA中的一个主要问题是系统版本控制，因为我们不知道服务用户。甚至有这样的情况，一家公司维护着同一服务的20多个不同版本，并稍微修改了接口以接受不同的数据。这对需要监控和维护的操作有很大影响。
根据Red Hat，SOA社区考虑向微服务的过渡，因为常见的SOA实践将服务与复杂的协议栈联系起来，如SOAP（用于web服务通信的协议）和WSDL（用于描述服务）。虽然这不是SOA需求，但在实际使用中，它只会退化为SOAP和web服务。
总之，SOA使更改业务流程变得容易，尽管更改服务需要部署提供服务的组件。这可能会级联到整个SOA整体，更不用说需要反映用户界面中的更改了。集成平台在第一次部署时通常非常复杂，而且由于它是集中的粒子，因此它可能成为处理通信开销或分布式事务的系统瓶颈。集成单元通常是一个ESB，用于集成、编排、路由、事件处理、关联和业务活动监视。从通信的角度来看，SOA是关于编排大型服务的。
4微服务体系结构
微服务基于三种Unix思想[115]：
bull;一个项目应该只完成一项任务，并做好它。
bull;项目应能协同工作。
bull;程序应使用通用接口。
这些想法导致了可重用的组件设计，支持模块化。主要的一点是，服务彼此独立地投入生产，这是大多数SOA解决方案的主要区别之一。它不仅影响部署，还影响演化和修改端口。微服务追随者经常引用Conway定律，指出“组织，其设计系统被限制生成这些组织的通信结构副本的设计。”微服务强调轻量级虚拟机。它们实现为容器（例如Docker）或单个进程。这就解除了对特定技术的依赖，从而可以使用特定于服务的基础设施。微服务通常共享相同的数据库模式，因为它会预先确定瓶颈和耦合。每个服务负责自己的数据模型，这可能导致复制。在背景部分，我们提到了有界上下文，这是服务的方向。在本节后面，我们将详细介绍有界上下文的更多细节。
与SOA不同，服务没有负责服务编排的集成组件，更喜欢编排。业务流程嵌入到服务中，集成中没有逻辑。因此，服务本身负责与其他服务的交互。这使得设计或调整公司业务流程的灵活性有限。这是独立于服务的服务管理和部署的回报。当然，仍然可以使用编排；但是，这不是一种典型的方法。
|
图3：系统A和B的SOA和服务架构部署示例。 |
可以注意到，微服务强调隔离，使得特定进程和用户交互在特定服务的范围内操作。服务通常由单个团队管理；但是，对服务的更改需要用户界面传播。因此，用户界面和服务都应该由一个团队控制。这使团队能够灵活地管理更改，同时避免在接口更改上进行官僚式谈判。拥有独立于开发和部署的服务，带来独立的可扩展性和持续的交付。这提供了故障恢复能力，因为请求可以在多个服务实例之间进行平衡。
图3b显示了图3a中提到的系统A，从图3b可以看出SOA的不同之处。每个服务都是一个单独的可部署单元，由一个单独的（或相同的）团队维护。请注意，在图中，企业中不存在复杂的集成技术；集成部分可以是用户界面部分，也可以是服务直接交互。
与SOA相比，用户界面部分可以集成到服务中，这避免了通信开销。服务之间的通信不需要REST或消息传递，用户界面集成可以与其他服务对话，而涉及数据复制；但是REST和消息传递都是常用的。微服务应该能够被单个开发人员理解，而不是由多个团队开发。同时，它不能成为一个纳米服务，因为它需要高的网络通信，这是昂贵的相比，本地通信。跨多个服务的事务变得复杂。因此，设计应该以跨单个服务或服务的事务为目标-
卷消息队列。然而，最近针对这种情况提出了一种非ACID事务类型，称为补偿事务。同样，对于数据，服务应该足够大，以确保数据一致性。
对于微服务，当涉及到数据模型的分段时，这是一个关键的决策；我们在引入有界上下文时提到了这一点。单个服务不能捕获整个上下文，但必须有一定的边界。有一些策略可以确定两个系统如何相互作用，确定边界。
1. 共享内核策略建议每个域模型共享公共元素，但是在专门化区域中，它们是不一致的。
2. 客户/供应商建议子系统提供由调用者确定的域模型。
3. 在conformist中，调用者使用子系统提供的相同模型并重用其知识。
4. 反腐坏层提供了一种转换机制来保持两个系统的解耦。这通常用于遗留系统。
5. 分层原则表示系统之间没有耦合。
6. 开放主机服务期望一个系统为每个人提供特殊的服务来简化集成
7. 出版语言具有对外可见的不可更改的语言元素（契约、事件等），在多个子域中具有意义。
从数据模型的角度来看，上述策略（4-6）提供了很多独立性，而（1-3,7）将域模型联系在一起。从通讯团队间的观点，（5）至少需要至少服从（3），（4）、（6）、（7）、（2）和（1）是主要影响。
4.1独立系统
<p
剩余内容已隐藏，支付完成后下载完整资料</p
资料编号：[405562]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
