Business processes are being accomplished through a variety of service implementations. However, there's a sequence for involving services. Typically, a business process indicates the sequence of services to be leveraged. Orchestration is a way for service composition through a centralized coordinator. This coordinator/brain guides and fulfils the business process requirements, just like a conductor in an orchestra—he/she leads the team as the central authority. By employing such an intermediary among different microservices, the issues that come from tight coupling go off once for all. That is, we get loosely-coupled microservices and they don't need to know each other. They also don't need to know whether other services are running. The communication can be mainly synchronous. That is, the requesting services should wait until they get the response from the requested services. 

There is one controller or coordinator that acts as the service orchestrator. That is, all of the service interactions happen via the orchestrator. This follows the well-known interaction:

For example, we need two or more services to be involved and invoked to accomplish a business process. The sequence of calling is also important here. The orchestrator makes a call to each one and waits for a response from the requested service. Once the response reaches the orchestrator, the next service in the sequence has to be called out, and so on. Check out https://medium.com/capital-one-developers/microservices-when-to-react-vs-orchestrate-c6b18308a14c for more information.