在云应用开发时，微服务可能是开发人员好的朋友，但他们也可能是有害的。行业专家汤姆·诺勒为此分析了人们所关注的重点。
很少有技术工具是如此的优秀，以至于它们不能被滥用。最近行业人士对微服务的兴趣已经产生了一些试验，其中包括令人印象深刻的成功和可怕的失败。这些试验的目的是确保用户的微服务和云计划不会在性能和体验质量（QoE）上出现歧异；了解微服务对性能的具体影响，构建基于微服务的应用程序以大化QoE，并采取计算和网络架构中的步骤，以最小化延迟，并大限度地提高可用性。
在专家所提供的手册中，探讨了云计算开发中的问题和趋势，并提供了有关开发人员如何选择正确平台的提示。
基于微服务的应用扩展了组件化的基本概念。它们创建了大量的功能上专用的部分，它们通过企业的网络连接，跨应用程序共享。许多人将微服务视为面向服务的体系结构（SOA）或抽象资源和代表性状态转移（REST）的Web原理的应用的自然演进。其他人认为他们是利用云计算的敏捷性的一种方式。在这两个愿景的平衡中，性能的好处和风险并存。
通过网络连接绑定其组件的任何应用程序将引入延迟，如果这些组件紧密耦合在单个机器映像中，则不会出现延迟。因为微服务组件化应用程序更多，它们引入更多的网络绑定和潜在的更多的延迟。问题是如何最小化或补偿该延迟，使得性能在微服务转换之后可以总体上稳定或甚至改善。
至少它是可扩展的
能够改进微服务和云应用性能的第一个因素是微服务实例在负载下的可扩展性。正确设计的微服务可以横向扩展，这意味着可以创建服务的其他实例，以响应工作负载。为了做到这一点，在实例之间需要用于负载平衡的机制。如果企业将微服务设计为无状态或使用类似后端状态控制的方式，则更容易。
这里的诀窍是将用户的扩展工作集中于实际受益的微服务。负载平衡会引入额外的网络处理延迟。因此，从专注于微服务开始，可以合理地缩放到四个或更多实例来证明平衡延迟。计算约束过程容易实现规模化。但是那些需要大量磁盘访问或使用其他微服务的可能会更困难。
第二种方法是通过将数据库访问抽象为逻辑查询来提高微服务和云应用程序的性能。数据库几乎总是托管在一个固定位置，通常位于混合云的数据中心侧。访问数据库，然后进行网络连接，并且如果要检查大量记录，则延迟可以累积。在数据库附近托管并将高级查询或请求而不是I/O命令作为其输入的微服务可以显著提高应用程序的用户体验质量。
虽然这些因素中的任何一个都可以改善微服务和云应用性能，但是它们可能不足以克服基本网络延迟问题，除非优化应用设计和微服务的使用。人们已经注意到，好的微服务是以无状态形式开发的。因此，微服务的任何副本都可以在不使用其中保存的信息的情况下从事务对话的较早部分发出任何请求。无状态设计经常用于Web编程，但在SOA和.NET本机开发中较为少见。开发人员可能不熟悉这些技术。开发工具和中间件可以帮助每个人加快速度和标准化方法以获得最佳性能。
不要过分考虑设计
微服务设计中的一个常见错误是过度思考服务耦合以支持运行时绑定。SOA被设计为允许应用程序动态地查找服务，但在大多数设施中，服务位置和工作流转向实际上是相当恒定的。这在微服务应用中也可能是真实的，但是许多仍然设计为使用API代理来将应用与其需要的微服务链接。
API代理可以提高开发敏捷性，但它们几乎总是限制性能。如果用户需要一个代理，请尝试将该功能与微服务负载平衡组合。然后，用户不必在其微服务工作流程中引入另外两个步骤。如果用户知道一些微服务将被大量使用，那么可以考虑将它们移到代理框架之外，并将它们作为简单的RESTful服务发布。这将减少这些应用程序的微服务开销，而那些被大量使用的应用程序并不真正需要运行时绑定。
要避免的另一个常见错误是低效的微服务结构。微服务应该足够小，并通常有用，但不能小到将连贯的逻辑功能分解成块。过度分割会增加延迟，用户可能还希望避免让微服务调用其他微服务，因为这一系列的API调用将增加延迟，这可能很难检测，而不检查所有微服务逻辑。
在微服务本身之外还有有用的性能增强步骤。一个值得注意的步骤是负载平衡。用户的微服务可扩展性实践的效率在很大程度上将取决于用户是否可以有效地将工作分配给所有实例。然而，效率也受到用户和负载平衡器之间，以及负载平衡器和所有微服务实例之间的网络延迟的影响。如果用户的微服务使用数据库资源，那么还需要考虑这些资源的访问延迟。所有这些都需要仔细的策略控制微服务实例的托管。这意味着用户的DevOps或部署工具将必须实施托管和连接策略，以确保最小的延迟。
因此，微服务和云计算应用程序性能可能会提高或可能严重降低。微服务对性能的影响通常很难评估。这意味着用户不仅必须在设计和初始部署期间，而且在每当对应用程序工作流或结构进行更改时，都要对其进行处理。因为问题可能随时发生，只有仔细审查和测试才能确保在微服务和云应用程序性能方面取得成功。
热门专题
