在编排中，控制器必须直接与每个服务通信，以便能够告诉它要做什么。然后它必须等待建立通信和服务响应。
当架构由数百或数千个微服务组成时，可能会造成服务可用性问题或过度延迟。
存在一个限制，超过该限制中央控制器就无法再有效地管理这种类型的架构。在这种情况下，就好像在分布式环境中创建了一个整体应用程序。
微服务之间依赖过多
编排在各个服务之间创建了很强的依赖性，特别是当它们同步运行时。一个服务必须显式地响应另一个服务的请求。
当关系涉及如此紧密的耦合时，链条中任何环节 马来西亚电报数据 的任何中断都可能阻碍整个过程。在企业环境中，有数千个微服务用于单个业务功能，一对一的方法无法扩展。
RESTful API 且难以扩展
说到可扩展性，编排方法的第三个关键问题是RESTful API 的使用，它们本身就是紧密相连的服务。 RESTful API 由分布式系统的一组架构约束定义。它们通过 HTTP 以无状态方式进行通信，使用通用语法和全局标识符来统一共享资源。
从我们的角度来看，使用 RESTful API 会更加强烈地加强架构中服务的耦合，从而增加您想要添加或删除的任何功能的成本和对 API 的影响。归根结底，问题也是在于扩展能力。
编排方法：它是什么以及它如何工作
编排使用了一种完全不同且从根本上分散的方法。进一步利用舞蹈团的隐喻，可以说，服务的编排不是表演，而是上演。
我们的意思是，当参与者自主履行其角色时，舞台就发生了。没有元素执行明确的顺序，而是每个元素都知道它必须执行的一系列与其交互的其他元素相关的操作。
编排方法基于这样的想法：中央控制元素、协调器（中间件，如 Kubernetes）是多余的。各个组件（即微服务）必须能够在没有外部干预的情况下进行自我管理，并且以松散的方式（松散耦合）而不是紧密的（紧耦合）耦合，即松散但不太紧密。