微服务：远行和挑战外文翻译资料

微服务：远行和挑战

原文作者 Pooyan Jamshidi; Claus Pahl; Nabor C. Mendonccedil;a; James Lewis; Stefan Tilkov

单位 Carnegie Mellon University,Free University of Bozen-Bolzano,University of Fortaleza

摘要：微服务是一种从面向服务的体系结构中涌现出来的体系结构方法，强调自我管理和轻可称量性作为提高软件敏捷性、可扩展性和自主性的手段。本文从技术和架构的角度审视微服务的演变，并讨论未来微服务发展面临的主要挑战。

关键词：微服务； SOA体系； 微服务发展面临的主要挑战

微服务是软件服务设计、开发和交付的最新趋势。1 .微服务建立在成熟的模块化思想基础上，强调技术边界的软件和系统架构。每个模块——每个微服务都作为一个小而独立的系统来实现和操作，通过定义良好的网络接口提供对其内部逻辑和数据的访问。

未来的挑战

随着微服务的日益普及，微服务的缺陷也开始显露。在实际应用场合中，微服务的开发成本可能会高于他的使用价值。造成这种问题的其中一个原因是，在某些情况下，项目最好开发方式是以整体的方式进行。但这并不意味着它不应该被设计成模块化，只是它的模块不需要像微服务那样孤立。需要的强调是，微服务不是，而且永远不会是，在所有情况下都是最佳的解决方案。然而，多数情况下，微服务将是一个很好的工具，但是实际中的开发团队并没有成功地实现它们，这有很多可能的原因。微服务未来的发展或许可以解决其中的一些挑战，正如我们接下来讨论的。

1. 服务模块化与重构

用模块化的方法，找到合适的模块，确定合适的规模，分配正确的职责，以及设计良好的接口，是一个挑战。对于微服务来说，情况尤其如此。微服务和其他设计不当的边界会导致网络通信的增加。这样的增加可能会导致一个系统由于性能和不稳定性而不适合其预定的任务。

这样的挑战普遍性存在，但有两个方面可以解决。首先，通过工具化重构一个由微服务组成的系统，可以使系统搭建变得变得容易，尽管这可能会对基础设施或开发依赖产生意想不到的后果。其次，转向异步通信，并更广泛地使用实现稳定模式的库以及更复杂的运行时环境可以帮助解决稳定性问题。在这一问题最后，一个纯粹的无服务器的方法将会非常信任底层平台和它提供的服务，这是以大幅增加对特定环境的依赖为代价的。这样的结果与微服务的原始目标背道而驰，可能会使人想起一些SOA架构。

1. 服务粒度

另一个问题是对微服务的合适规模缺乏一致的意见。尽管服务粒度名称本身似乎暗示微服务应该尽可能小，但项目团队往往会以截然不同的方式来解读这一宗旨。一些团队只有几到几十个LOC提供微服务。另一些团队将一些KLOC以及几十个类和可能的数据库实体封装到微服务中。这些中型微服务之间的通信可以是同步的，也可以是异步的。另外还有自包含系统的方法，通常被视为微服务的一种变体，它主张将UI，尤其是Web UI作为服务的一部分，并建议尽可能依赖于前端集成。

我们刚才描述的每一种方法都有优点。然而，它们都被认为是lsquo;微服务rsquo;的这一事实表明，当将一个领域拆分成微服务并对每个服务进行范围界定时，建立一套模式来帮助设计决策的方法或许是不错的选择。

1. 前端集成

UI通常是微服务体系结构中的关键组件。这主要是因为他们没有成为许多微服务方法倡导者——负责后端方面的架构师的焦点。这可能导致单个前端使用多个后端微服务的系统。这样的架构有时是有利的，但它们通常会抑制微服务的目标。因为一个前端仍然存在单体架构的所有缺点。不同种类前端的模块化，不论是web、原生的，还是混合的，以及它们作为微服务的一部分或协作实体的关联，是帮助开发团队实施全栈式微服务环境的迫切需要。

1. 资源监测和管理

随着微服务应用程序的规模和复杂性的增加，必须在运行时持续监测和管理的基础设施资源(例如虚拟机、容器、服务、消息、线程池和日志)的数量和多样性也增加。此外，服务可能部署在多个可用性区域，这加剧了收集有关其状态和行为的最新信息的挑战。最终，随着当前监控技术所提供的自动化水平的不断提高，应用开发人员可能会发现自己陷入大量监控事件中应接不暇，无法及时做出管理决策。

这里的一个关键问题是如何定义适当的警报阈值和过滤器，以便在出了问题时通知开发人员，而不必用冗余或无关的信息使开发人员承受过大的压力。更具有挑战性的是如何从过去的事件和行动中学习，以便更好地告知(并可能自动化)资源管理决策。与其他大多数大数据场景一样，控制理论和机器学习应该在开发更可扩展的微服务监控和资源管理方面发挥重要作用。

1. 故障、恢复和自修复

与任何类型的分布式系统一样，微服务通常都是脆弱的。由于很多原因，如网络、硬件或应用级的问题，它们可能变得不可用、无法访问或者失效。由于服务依赖性，任何服务都可能暂时无法访问。在分布式设计中，通信都会不时失败。就整个微服务系统而言，通信故障很可能因为服务之间传递的消息数量而发生。

为了最大限度地减少部分通信中断的影响，开发人员必须构建能够优雅的地响应某些类型故障的容错服务。研究者和从业者者提出了隔离故障的方法，使其不会在整个分布式系统中传播。然而，在自动故障管理以及自我修复方面需要更多的工作以保证自修复系统的顺利运行

应对挑战

我们刚刚讨论的每一个挑战，以及其他一些我们在上文中提到的挑战，都有可能被学术界的软件和系统工程研究者解决。事实上，微服务正迅速成为一个研究热点，发表的研究论文也越来越多。一个可能的原因是，学术界的研究人员对行业规模的微服务应用的了解有限。这使得他们很难对现实微服务生产环境中可能出现的各种技术和非技术问题进行复制和实验。为了纠正这种情况，我们设想了两种截然不同但相互补充的策略。第一，要有更多的激励产学合作。第二，从业者和研究者应该努力开发和共享一个通用的微服务基础设施，能够尽可能准确地模拟典型微服务应用的生产环境。这样的基础设施将使微服务社区不仅能够解决更具有代表性的实践者所面临的问题，而且能够进行更具有可重复性和行业针对性的实证研究。

外文文献出处：P. Jamshidi, C. Pahl, N. C. Mendonccedil;a, J. Lewis and S. Tilkov, 'Microservices: The Journey So Far and Challenges Ahead,' in IEEE Software, vol. 35, no. 3, pp. 24-35, May/June 2018, doi: 10.1109/MS.2018.2141039.

附外文文献原文

Microservices: The Journey So Far and Challenges Ahead

Microservices are the latest trend in software service design, development, and delivery.1 They constitute an approach to software and systems architecture that builds on the well-established concept of modularization but emphasizes technical boundaries. Each module—each microservice—is implemented and operated as a small yet independent system, offering access to its internal logic and data through a well-defined network interface.2 This increases software agility because each microservice becomes an independent unit of development, deployment, operations, versioning, and scaling.

Future Challenges

As an obvious downside of microservices increased popularity, theyre more likely to be used in situations in which the costs far outweigh the benefits. One reason could be that a project would best be developed in monolithic fashion. This doesnt mean it shouldnt be designed to be modular, just that its modules dont need to be as isolated as microservices.

Microservices arent, and never will be, the right solution in all cases. More interesting, though, are situations in which microservices would be a good fit but teams dont implement them successfully. There are many possible reasons for this. Future developments could perhaps address some of these challenges, as we discuss next.

Service Modularization and Refactoring

With any approach to modularization, finding the right modules, with the right size, the right assignment of responsibilities, and well-designed interfaces, is a challenge. This is especially true for microservices and other approaches in which badly designed boundaries can lead to increased network communication. Such an increase might yield a system unsuitable for its intended tasks owing to abysmal performance and instability.

That general challenge will remain, but two aspects could be addressed. First, refactoring a system composed of microservices could be made easier through tooling, even though this might have unintended consequences regarding an infrastructure or development dependency. Second, a move toward asynchronous communication, more pervasive use of libraries implementing stability patterns, and more sophisticated runtime environments could help address stability issues. At the far end of this spectrum, a purely serverless approach places a lot of trust in the underlying platform and the services it offers. Again, this is at the cost of drastically increased dependency on a particular environment. Such a result runs counter to one of microservices original goals and might remind some of you of SOA infrastructure.

Service Granularity

Another

剩余内容已隐藏，支付完成后下载完整资料

英语原文共 12 页，剩余内容已隐藏，支付完成后下载完整资料

资料编号：[596162]，资料为PDF文档或Word文档，PDF文档可免费转换为Word