早期的应用内部功能由于不需要对外提供业务，导致内部耦合度非常高，都是作为应用整体的一部分而无法分割，这就为后续迭代和新增的功能带来了很多问题，其中最直接的问题就是应用越来越难以维护，增加了大量成本和不确定的风险。

后来发展到基于模块化堆积木的方式，那也于应用业务需求本身，却无法对外提供独立的服务，像火车，传统的方式就像在固定的车厢上不断增加负荷，而模块化后只是固定了每节车厢的重量，按需求来挂接车厢，解决了车箱多少。但这些都没有考虑火车能拉多少重量和各车厢（功能）是否可被第三方所共享使用的问题。

如果说铁路是软件平台，火车是进程，那么车厢就是平台上的各个功能服务，车站的检票口就是接口了，而对于在铁路线上的各个车站只有在某个时刻才能享受到该列车的服务，而想要登上该列车，途径就是通过车站的统一检票口，当然扒火车也成，可那属于行为，是非法的，大多数车站都为每趟列车提供了一个对应的检票口，对于软件来说，这就是用户登录的入口了，上去了才可以享受各个车厢的服务，可车厢（功能）本身并不对外提供服务（接口）。那么怎么解决这个问题呢？用专列，让功能上升为整个服务与检票口对接，当然，此专列非人专列，只要大部分车厢功能一致，对外统一就好。

原来一列火车由军备、医疗、货物、旅客等不同车厢（功能）组成的列车服务，换成专列（军列、货车、客车）后，意味着车厢功能上升为整个列车的服务，与各站的检票口对接成为单独对外的服务窗口（接口），如果该专列供不应求还可以多开几列，意味着同一个时刻不同的车站都可以享受同样的服务，不同的时刻在相同的车站也可以享受到不同的服务。这对应到软件把功能独立对外提供的服务就是微服务了。

为什么要用微服务？

应用功能微服务化后，各功能之间的关联形成了低耦合模式，迭代和维护不再变得困难，诊断问题也变得不再复杂，微服务技术的应用给业务注入了新生力量，极大地改善了整个IT环境。

现在微服务的由来和为什么要用微服务我们就说到这，微服务一来，接口自然也就越来越多，接口是需要交互的，否则就没有存在的意义。

接口的安全可以交给API网关负责，那么接口的调度呢？

这就是要聊到服务的编排了，为方便说明，咱们先说说企业内部用得比较多的ESB，ESB是企业的数据总线，能解决企业内部各应用系统的接口交互问题，以前做接口，如果有n个应用需要相互数据同步，则每个应用都需要做n-1个接口，有了ESB后每个应用只需要做一个接口，也就是说所用的应用只需与ESB做接口就可以了，这就是个简单的调度器，但解决了企业应用之间交互的大问题。

而在基于互联网和微服务模式下的服务编排至少需要满足智能终端和哑管道的微服务通信原则，从这点上企业ESB就已不再合适，所以寻求符合微服务通信原则下的服务编排，逐渐成为在微服务环境下存在大量API业务需求的重要目标。