当微服务部署延伸到云端时，微服务部署可能带来成本爆炸和性能黑洞，但这并不是这项技术的错。

对于这个问题，应用程序开发团队必须了解如何平衡微服务的成本和收益，尤其是在多云环境中。如果没有适当的评估，开发人员就有可能构建企业无法承受的部署。

微服务部署中的性能和成本问题主要来自四个方面：过多的微服务；在扩展期间未能优化实例位置；不恰当地选择云服务提供商和服务；以及低效的资源配置。在多云环境中，这些因素（特别是最后三个因素）通常难以控制。

太多微服务

微服务的好处包括运行时代码和组件重用，以及加载时应用程序的可扩展性。但是，由于每个微服务都是独立托管，因此，与相同代码的更聚合模型相比，应用程序的云成本通常更高。此外，工作流必须在微服务之间穿梭，这可能会导致传输延迟，并且可能会增加多云的成本，因为工作流需要跨越云提供商边界。

为了避免这些问题，请不要为同一事务迭代地部署微服务。应尽可能多地将逻辑放入给定的微服务中，同时仍然确保其重用和可扩展性的优势。另外，在扩展多云微服务时，请注意不会增加从一个云主机到另一个云主机的跨边界问题。

太多云

微服务部署中的跨边界问题是由于在扩展时未能优化实例的位置。若要解决此问题，请在同一个云中扩展微服务，而不是跨云。

云边界不是绝对的。IT团队可以使用数据中心作为云提供商的替补，或者将一个云作为另一个云的替补。但是，在正常操作下，应该集中云微服​​务实例，而不是将它们分散在各种不同的托管选项中。

太多选择

云提供商为微服务部署提供多种托管选项，包括无服务器和托管服务选项，但这些选项并非所有微服务都适合。

如果应用程序的微服务需要不断运行，无服务器托管可能会很昂贵。另一方面，如果企业在其多云部署中使用内部托管的编排和管理工具，则托管主机很难判断。

同时，无服务器和托管选项都会带来性能问题。当云提供商使用微服务资源池或无服务器工作分布层时，微服务可能会按需启动，或者新实例可能需要一些时间才能部署。无论哪种方式，这都会增加工作流的延迟，这有时会使事务处理变得不可靠。

很多多云用户发现，对于多云环境，最便宜且性能最佳的微服务托管选择是IaaS上的容器。与无服务器和托管微服务相比，公共云IaaS产品可在云提供商间提供更多兼容性。DevOps和编排工具（特别是Kubernetes）可以帮助团队管理多云容器托管，而不会有太多的集成麻烦。请注意不要忘记托管微服务实例的位置（或者它们所使用的资源的相对位置），因为这可能会带来跨边界问题。

太多资源位置

每个应用程序都有一组它需要处理的活动。开发人员必须跨该应用程序的组件映射与这些活动相关的工作流。工作流映射显示数据路径，而路径显示在关键活动中调用的云微服务。

为了确定最能影响成本和性能的微服务，请将映射的工作流与使用量和业务关键性相关联。那些影响较大的微服务可能有隐藏的资源，例如数据库。当微服务在发生故障后重新部署或在加载时进行扩展时，它必须与其新位置使用的任何资源重新建立连接。

如果用户不注意它们的托管位置以及它们如何连接到新的微服务实例，这些隐藏的资源可能会在扩展和重新部署期间造成重大问题。有些设计应该复制连接的数据库或其他资源，以确保每个云中都有。但是，对于重复的数据库，一个云无法替补另一个云，从而导致后端状态控制出现问题。

作为代码重用与简单模块化编程的机制，微服务的好处之一是，重用是在运行时，并且，单个实例或一组可扩展实例可为很多应用程序提供服务。这里的问题是，企业必须考虑在微服务部署中跨所有云共享所有这些实例的所有应用程序。在某些情况下，这种要求很难协调，但这是开发团队必须掌握的平衡做法–在第一批账单到达之前。