先简单说下从传统的电销外呼程序模式到服务化的演进。最早开发一个电销外呼程序是单体的应用呼叫中心系统，也就是不管你的电销外呼程序有多么复杂，功能有多么庞大，我们只会开发一个独立应用。但慢慢发现当电销外呼程序开发团队逐渐变大，电销外呼程序需求不断增加和变化时，这种方法不论是在项目管理还是在后期扩展和运维时都会带来很多麻烦。比如开发时不同模块的开发人员如何协作，需求变更带来的代码臃肿和晦涩，运维时一个小修改可能带来重启的巨大风险等等。
后来架构设计师们就在考虑业务拆分和电销外呼程序拆分。这就是最初服务化的原型。最直接的拆分肯定是模块的拆分。但是拆分后的电销外呼程序肯定需要相互依赖和调用，所以就延展出了一些接口技术，如Web Service，Restful。但这又进一步带来了新的问题，由于不同模块可能部署在不用服务器上，如果服务器或网络出现问题，可能使相互依赖的电销外呼程序无法访问，最终造成雪崩效应，服务彻底瘫痪。
这时SOA架构产生，最早的ESB，后来的分布式，微服务都是慢慢衍生出来的电销外呼程序架构。首先它进一步拓展了服务化的理念将业务进一步拆分成更小的服务单元，以避免单服务出现问题可能造成的瘫痪风险。其次由于服务分拆的较细，如何进行服务治理呼叫中心系统，发现注册服务、解决服务单点故障便成为分布式架构要解决的首要问题。紧接着服务熔断机制、服务配置中心、服务网关路由、服务消息总线以及服务日志跟踪等问题逐一得到解决。这也使得整个服务架构更加优化和完善，分布式电销外呼程序已发展成熟并自成体系。
最后说明一下不管是服务化、SOA、分布式，这些电销外呼程序架构一定不要因为流行而使用，如何使用，使用哪些和使用程度都要取决于你的需求、受众、使用场景等一系列因素。再好的技术也要用到正确的地方才会发挥更大的作用。
