在讨论过渡到微服务时对现有应用程序的开发影响时，有五个问题以一种或另一种形式不断出现。 无论组织的规模如何，它们都是相同的，并且随着组织向微服务架构的发展，它们似乎成为该过程稍后的战略讨论的一部分。
这些文章涵盖了每个人都应该问有关微服务的问题。 他们基于在征服微服务以进行现有开发和交付现代应用程序的过程中与组织进行交互的经验。
之前，我们讨论了四个问题。 微服务对性能的影响，有关状态和整体的问题，有关数据和微服务以及测试微服务的问题 。 在第五篇也是最后一篇文章中，我们将探讨关于使用API管理或服务网格的困惑。
API管理或服务网格
在本系列的最后一部分中，我们遇到一个问题，即关于角色是API网关和服务网格的困惑。 它是这样的：
“如何使用API网关（例如3Scale或服务网格）将应用程序迁移到更现代的工作方式？”
首先，让我们澄清一下，这个问题引用了Red Hat 3Scale API Management产品，该产品是基于开源社区项目的API管理技术产品。 诸如Istio （社区产品之一）之类的服务网格技术的关注点非常不同。
现在要定位API管理的使用方式，请记住，我们之前谈到过微服务开发团队像企业对企业合作伙伴一样独立运作。 这些开发团队使用的API是其特定微服务的前端。 使用API管理工具，开发团队将其微服务API发布到其组织的托管API层中以供使用。
从服务网格技术来看，它与微服务能否在其部署层中相互通信有关。 考虑诸如微服务发现，负载平衡，故障恢复，指标和监视之类的事情。 服务网格解决了分布式服务遇到的微服务内挑战，并以一种新颖的方式做到了。
您未来的微服务？
既然您已经看到了很多人在野外问的五个问题，您是否注意到了一直在努力的一些相同问题？ 由于它们基于在现代化服务层过程中与组织的交互作用，因此，在您过渡到用于交付应用程序的现代体系结构时，这些问题既现实又相关。
不要犹豫， 回到本系列的第一篇文章，并回顾本系列涵盖的所有问题。 这些见解应该可以帮助您做出明智的决定，解决现有的单片应用程序的复杂性，并在未来几年内朝着根本上完善的微服务架构迈进。
（与Burr Sutter合着的文章）
翻译自: https://www.javacodegeeks.com/2019/09/5-questions-everyones-asking-microservices.html
