我认为编排在内部非常适合高度分散的组织。您不需要中央业务流程执行器。这有利于每个组织子单元的独立成长和发展。

(我赞同编配与编排问题的解释: http://geekexplains.blogspot.com/2008/07/ways-of-combining-web-services.html)

另一种看待服务编排与编排的方法:

—服务编排:围绕业务域。 —服务编排:在多个业务域之间。

One can use both choreography and orchestration is the same system as we have done in our product. Various actors performing various tasks dispatched to them are choreographed by the event pub/sub system via events they generate. For example, when a prime mover carrying a container arrives at a warehouse, that event, which is subscribed by the warehouse manager app, prompts the warehouse manager to activate the resources to unload the cargo. But when exceptions happen, such as the forklift to carry the load breaks down, that event starts an orchestration engine (a workflow processor) to orchestrate the task for various actors as per the exception handling workflow to handle the exception.

Service orchestration: you put together several services by a fixed logic. This logic is described at a single place. You can imagine a team of people with a manager doing micro-management. The manager precisly tells what, when and who should do. The team members do not care of the entire goal of the job, the manager combines the outputs into a single deliverable. A practical example is a BPEL process. BPEL process contains the logic, can invoke several services and combine their responses into a single service response.

Service choreography: the decision logic is distributed, with no centralized point. You can imagine a home, where everybody aims for the common good and works pro-actively without micro-management. Or you can imagine a human body, where different members are interdependent and work for the common goal. A practical example is event driven processing, where an agent is activated by an event and does its job. All the agents make a system together. There is no centralized logic. Choreography possibilities may go farther beyond orchestration as it is more aligned with the real world.

我的观点是，我们不需要对这两者进行太多区分，因为我们需要关注业务逻辑。在单点逻辑可以完成工作的地方，我们进行编排。如果一个问题不能被集中的逻辑覆盖，我们就不得不编排。这就是为什么我们经常在IT中遇到编排，而编排更多地是一个学术概念和一个研究主题。我们经常在不知情的情况下编舞，就像在现实世界中一样。

我认为编排在内部非常适合高度分散的组织。您不需要中央业务流程执行器。这有利于每个组织子单元的独立成长和发展。

(我赞同编配与编排问题的解释: http://geekexplains.blogspot.com/2008/07/ways-of-combining-web-services.html)

编配和编排都是大规模的过程形式主义的两种哲学，即协作空间。协作空间是一个行业的正式表示，例如健康行业、食品行业、汽车行业或... .因此，在您决定编排它们或使用编排来提供对终端消费者有意义的需求之前，您应该有一些小规模的能够使用某种交流语言的服务提供者。

编排通常遵循分布式系统中著名的中间件。IT行业中一些很好的工具例子可以是Juju, Zapier IFTTT。您可以对所使用的服务进行集中控制、听觉、修改和故障排除。

Choreography is more decentralized than orchestration in the sense that it accepts more autonomous collaborators. For example bitcoin network is a collection of service providers called nodes which collectively provide a Defi service namely distributed ledger functionality to its service end-consumers. But this does not have any centralized authority in charge, and there is no total-view over whole network. There is just a consensus machanism that if respected candidate service provider joins the network and participate in end-consumer service provision. Anywhere you need to attack trusted third party and its side effects such as corruption, an orchestration would not suffice.

同样，任何行业参与者之间的任何协作都可能受到编排或编排的影响，因此我希望将示例仅限于IT行业不会造成误导。

我还可以补充一点，命名暗示了两者与舞台表演的相似之处。在管弦乐队中，如果每个乐器演奏者都跟随指挥，他/她就能与其他成员和谐相处。另一方面，类似于编舞中的舞台舞蹈，没有指挥，每个舞台舞者只与他/她的搭档协调(最好是作为同伴)，没有单一的协调领导。但两者仍然向观众呈现和谐。