英语原文共 16 页，剩余内容已隐藏，支付完成后下载完整资料
本科毕设外文翻译
译文题目 软件架构 - 现在和远景
原文题目 Software Architectures – Present and Visions
软件架构 - 现在和远景
Cătălin STRIcirc;MBEI, Octavian DOSPINESCU, Roxana-Marina STRAINU,Alexandra NISTOR
AL.I.Cuza大学经济学和商业管理学院Alexandra NISTOR教员
linus@uaic.ro, doctav@uaic.ro,
roxana.strainu@gmail.com, alexandra.anichitoaei@yahoo.com
摘要：如今，软件架构越来越重要，因为它们可以确定整个系统的成功。在本文中，我们打算严格分析最常见的系统架构类型，并就大学架构的具体情况提出个人意见。在分析单片架构，SOA架构和基于微服务的架构之后，我们提出了大学软件系统的具体问题和具体标准。每种类型的架构都是根据具体的学术挑战进行分析。在分析过程中，我们考虑了决定每个架构成功的因素，以及失败的常见原因。在文章末尾，我们客观地决定哪个架构最适合在大学实施。
关键词：系统架构，单片架构，SOA，微服务架构，大学系统架构
1、引言
软件系统目前面临着诸如复杂度高，技术不断变化和异构数据互操作性的不同因素所带来的诸多挑战。所有这些因素导致了各种架构模型的出现，这些架构模型已经试图解决这些挑战。按时间顺序，我们认为最重要的步骤是专注于单片架构和面向服务架构。我们估计，新浪潮将以应对互操作性挑战为基础的微服务架构。例如，在过去十年中，致力于互操作性的解决方案的市场[1]已从2004年的34亿美元（2008年）增长到了110亿美元（2008年），并在2015年超过了200亿美元。单片架构集中在传统的方法上；尽管有些作者认为这些作品已经过时，但目前的许多系统都是以这种风格设计的。他们的整合主要通过SOA实现，但是SOA的局限性和挑战促成了新远景的出现：微服务。在本文中，我们将尝试比较这些方法，并强调其在学术领域的具体情况。
二、单片架构
当提及整体式架构时，这一领域的文献避免了对术语的定义。根据Aoyama[2]，这种架构被认为是传统的，属于新软件开发过程中采用的旧款式。以Aoyama推出的想法为出发点，Lake [3]认为，单片名称是指将单一组件或单元组合在一起的基本应用元素。换句话说，与模块化方案相比，单片方法可以被看作是集成架构设计。一般而言，“单片”一词用于缺乏更好的术语，以表示应用程序的所有不同类型的基础架构元素可以在一个块中一起使用。
事实上，研究人员特别在提到其他类型的架构时，已经接触到这个问题。Baldwin＆Clark [4]强调代码库体系结构在开发开源程序中的重要性，强调了单片机和模块化架构之间的区别。在第一种情况下，参与者无法访问其他同事代码；在第二种情况下，开发人员可以在编写代码时加入努力。Carbonell[5]等人已经提出了类似的想法。在讨论模块化的PRODIGY架构的解决能力时。因此，与SOAR（单片架构）相比，作者认为，PRODIGY在工程原理方面是优越的。
从关于整体架构的一些相关文章开始，我们注意到这个概念被认为是过时的，其他研究人员提出了架构重构的需要。例如，Mens et al[6]提出将单片模型的体系结构重组为客户端服务器或三层架构，用户界面，业务逻辑和数据层可以通过这些结构重构。使用单片架构，用户界面元素可以与业务逻辑和数据管理代码混合。这并不意味着所有元素将始终存在于代码的所有软件类中，但是设计允许它们混合在一起。单一方法的积极方面是，当多个组件或模块可以聚集到单个单元中时，部件之间的相互作用的复杂度较低。另一个积极因素是在一个地方看到整个过程的容易程度。例如，可以看到用户界面代码与来自接口的数据处理以及将其持续到单个类和文件中的数据库。使用逻辑来操纵用户界面（通常较少动态）的能力是使用单片方法来构建架构的另一个好处[7]。
表1.整体 - 优缺点[8]
|
优点 |
缺点 |
|
性能优越 |
不能被多样的用户使用 |
|
迁移到其他任务上简单 |
很难处理大量数据 |
在优势方面，性能是专家在提到这种架构时引发的第一个特征。具体来说，使用单片机开发的应用程序进行数据访问的能力，这种操作是高度简明的，David A.Penny [8]对此概念进行了简短的表征，总结了单片架构的主要特点：
- 通常，所使用的编程语言是单一的；
2、代码通过一个独特的（单片）程序进行编译和链接；
3、何时运行，它可以是：批处理模式和GUI模式；
4、使用的数据可以加载到内存中，并将所有数据写回显式保存。没有同时进行数据共享。
关于这种架构中使用的数据，我们注意到它被直接操作和读取到程序的存储器中。为了保存它，有两个选项，首先使用相同的源，其次，选择不同的源。
关于可以对使用此架构开发的程序进行的更改，会出现可见性问题。在这种情况下，有两个选项用于查看用户由其他人完成的更改。由于在这种类型的应用程序中不可能进行多用户访问，因此只允许顺序访问。因此，如果通过程序的每个副本将数据读入存储器，则不能看到所做的更改。在我们看来，单片架构的改进需要额外的成本，以便：提供对多个用户的访问，连接到关系数据库，同时更新易失性数据等。
使用单片架构的应用程序的一些示例可以是一些办公室和通信（电子邮件）应用程序，会计软件包，业务报告，工资单。
优化考虑：（1）通过文件系统直接从磁盘读取数据；（2）用户还可以缓存和预取内置数据。当考虑到数据更新操作时，内存中的数据更快，而缓存不是共享数据系统的选择，因为在将更改提交到记录时遇到延迟。
简单性，这种架构的第二个优点是由于写入代码较少，处理问题较少的事实，例如：锁定，完整性，性能，交易，地理分布等。
关于缺点，最明显的是不可能在多个用户同时使用系统（多用户不是一个选择）。作为解决方案，可以执行以下几个措施，例如：（1）允许数据集合并多个文件；（2）混合方法，使用复杂的单片分析软件和简单的数据客户端/服务器更新软件。
第二大问题是不可能处理大量的数据，这可能导致将数据加载到内存所需的时间量或增加使用的虚拟内存量。这种问题的解决方案可以考虑顺序或选择性访问可以被授予应用程序。
同样，我可以提到与用户的其他具体需求有关的其他缺点。在这方面，Roschelle等 [9]在提到教育软件时，讨论了单片架构系统的消极方面。根据同一作者，用于开发各种软件应用程序的单片架构可能会影响五种组织角色：
1、资金者通过资金浪费冗余编码；
2、开发人员的广泛目标，导致质量下降；
3、研究人员不能在程序之间进行可行的系统比较；
4、作者不能定制，整合或扩展不同的产品；
5、开发或使用不兼容，昂贵或零碎软件的学校。
考虑到与单片机构的优势相比，增加的缺点，该领域的研究趋势是合理的，因为这种类型的模型的损害主要意见。
三、面向服务的架构
面向服务的架构是构建独立于技术的架构的一种方式。根据[10]，面向服务的架构是一种基于松散耦合，粗粒度和自主组件称为服务的交互构建系统的架构风格。每个服务通过合同公开流程和行为，它们由消息和称为端点的可发现地址组成。服务的行为受服务本身外部的策略的约束。合同和消息由称为服务使用者的外部组件使用。
SOA基础架构包含3个主要组件[11]：
1、服务提供者；
2、服务消费者；
3、服务注册表。
这些组件进行交互以便发布，查找，绑定和调用特定的服务，如下图所示。
图1、SOA的一般组件[11]
一些作者[12]认为，SOA不仅仅是从技术角度看待的服务架构，而是提供和消费我们确保正确服务的策略，实践和框架。
SOA有一些特点[13]：
- 服务与由XML模式定义的消息通信。消息通过异构环境，并且它们具有运行操作所需的信息。
- Web服务描述语言（WSDL）是描述SOA服务接口的语言。
- SOA中的服务由作为目录列表的注册表管理。应用程序必须“读取”注册表，查找特定的服务并调用它。
使用SOA的优点由专业文献[14]描述：
1、缩短开发时间和成本；
2、降低维护成本；
3、优质服务；
4、较低的整合成本；
5、降低风险。
在SOA模型中，我们有一个或多个适配器管理消费者，服务和提供者之间的交互，使用如远程过程调用或表示状态转移[16]。
从不同的角度来看，SOA在实际业务中有很多挑战[17]：缺乏专家，服务识别路线图，SOA交付策略，业务IT整合，经济问题，缺乏长期规划和策略，稳定性，复杂性，服务 边界，互操作性。
四、微服务架构
微服务作为一种相对较新的方法出现，这些实践者正在寻求一种甚至比传统SOA可以提供的“更”民主的架构风格。微型服务架构处于起步阶段，仍然在寻求广泛使用的定义，长期来看仍然不断演变和未经证实。
J.Thouml;nes将微服务视为软件应用程序（多小，多大？）独立开发，管理和维护：“独立部署，独立部署，独立测试，具有单一责任”[18]。
Galen Gruman和Alan Morrison将微服务架构（MSA）视为具有“更大的模块化，松散耦合和减少的依赖关系在全部简化集成任务的承诺”的服务组件[19]。最引人注目的观点之一是Martin Fowler认为微服务架构[20]是一种方法，用于描述将软件应用程序设计为可独立部署的服务的一种特殊方式。Fowler将微服务架构风格定义为“开发单个应用程序作为一套小型服务的方法，每个应用程序都在自己的进程中运行，并与轻量级机制（通常是HTTP资源API）进行通信。这些服务是围绕业务功能构建的，并可通过全自动部署机器独立部署。”
山姆·纽曼（Sam Newman）为从业人员撰写了几本有关MSA [21]的几本书，他们从域驱动设计，连续交付，点播虚拟化，基础设施自动化，小型自主团队，规模系统等方面确定了微服务新兴基地。萨姆·纽曼认为微型服务是“小而自主的服务。小而专注于做好事情”，并提出了罗伯特·马丁（Robert C. Martin）所定义的“单一责任原则”：“将那些因同样原因而改变的东西聚集在一起，并将那些因不同原因而改变的东西分开。”
定义微服务体系结构的最后一个观点是我们将公开的是“Kurhinen”：“通常微服务是相当独立的，他们有自己的进程，管理自己的依赖关系，并可能管理自己的数据库连接。微服务也可能有自己的API进行通信”并且“将微服务包裹在一个轻量级的通信层中将会更好”[22]。
J.Thouml;nes将微服务体系结构作为一个轻量级堆栈，将轻量级容器运行时部署为[23]：嵌入式Jetty，嵌入式Tomcat，SimpleWeb或WebIt。为了画出这个陈述，这位作者反对他们到重中心ESB的类别。他指出，微服务的另一个定义特征是复杂性从整体到网络层的移动。为了建模微服务体系结构，提出了一种具有“服务”标签的域驱动设计方法（Eric Evans）。 此外，Galen Gruman，Alan Morrison努力表征微服务方法强调了以下功能[24]：
- 网络规模开发：必须快速发展的软件，其功能在几年甚至几个月内会发生变化或过时，而且努力水平必须符合压缩和无效的进度；
2、依赖：前SOA紧耦合，传统SOA松耦合，MSA解耦；
3、简单干净的零件，消息式接口；
4、更简单的消息传递系统
剩余内容已隐藏，支付完成后下载完整资料
资料编号：[26348]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
