云之讯首席架构师张修路：云呼叫中心服务 未来的趋势走向

　　张修路：大家好，我是张修路。2002年，我从哈尔滨工业大学研究生毕业，并在毕业之后加入华为公司一直工作至2014年。在离开华为公司之后，我做过一些创业项目。去年年底，我收到了一位原同事的邀请，请求加入到云之讯公司担任语音业务的架构师。在华为工作的十几年期间，我做过类似WAPGW、短信、彩信、IPTV的系统架构设计，以及网络安全与可靠性、可服务性等一系列各种各样的专项系统设计。有很长一段时间，我在做整个解决方案的设计，因为在电信行业，我们需要提供客户完整的解决方案，包括之前提及的短信、彩信、IPTV，还有彩铃等业务。我们需要将所有的业务连贯起来，给它提供一个完整的一体化解决方案。最主要的是，在加入云之讯之后，我主要从事的工作是云呼叫中心的设计，而我想通过这种设计，将其与我在过去十几年的电信行业背景相结合，因为在我离开华为之后，我曾在多家公司从事关于互联网业务的工作，对互联网的业务有了一定的了解，而今天的工作就能够较好地结合我对电信行业业务的理解，以及对云计算和互联网业务的理解。这恰恰也是我愿意加入这个团队，且持续发展的一个原因。

　　张修路：在系统设计的过程中，很重要的一点就是对业务的理解。因为在过去的工作过程中，我发现很多同事他对技术的理解非常到位，但是对客户的需求却没有理解到位，导致整个系统在设计的过程中出现问题。在我看来，系统设计过程中极为重要的就是要能够深入理解客户的需求，以及它的业务场景。我和我市场部门的同事谈及的第一件事情，首先你能够完整地描述我们客户的业务需求以及它的业务场景，比如说我们的呼叫中心，对我们客户、它的最终用户、它的消费者是打电话步骤，在这个使用呼叫中心的过程中，会经过什么步骤。基于对这个业务场景的深入分析，以及做场景的抽象和分析，然后开始做架构设计，那么对一名架构师而言，在系统设计过程中极为重要的就是尽可能多地了解技术。所谓架构是一种选择的过程，大多数架构师不会选择去发明一种新技术，更多的是整合已有的技术来完成客户需求和业务场景的设计，因此需要对多个系统有足够多地理解，在积累了众多经验之后，就能够选择最合适的技术来满足客户的需求，并且设计出一个高可靠、高并发、稳定的系统。如果想要设计一个类似电信级的系统，不仅要做到非常高并发、高可靠，还需要使用分布式的异步编程，以及一些扁平化的架构设计。

　　张修路：在过去的电信系统中，它极为强调可靠性，即对可靠性的要求非常高。举个例子，光传输领域，如果说我们经常出现光纤被挖断，或者说它需要在极短的时间，可能是万分之一秒完成主备的倒换，那么我们需要依靠它带来的高可靠性；但另一方面，它引发了高成本，到达语音呼叫，或者云计算之后，尤其是以谷歌此类互联网技术的发展，它尽可能会采用一些廉价的设备。在我刚参加工作之时，我们都会使用一些小型机，比如惠普、IBM、Sun，一方面它的可靠性，以及性能非常好；而另一方面，它的成本却很高。而在谷歌、百度、腾讯、阿里巴巴等此类互联网厂商发展起来之后，会因为为客户提供一些免费的服务，而受限于技术，或者受限于成本的约束，使用廉价的X86的计算机和服务器，以及廉价的磁盘来提供相对可靠性比较高的服务，对于技术的选择需要通过类似智能DNS，或者云服务呼叫中心所采用的分布式设计来保证它的可靠性。从技术角度来看，这两者之间的区别在于一方面电信技术更多地依赖于底层的技术来提高它的可靠性，而互联网和云计算更多地依赖于顶层的业务设计和分层设计来提高性能的可靠性，以及保证业务的连续性，甚至在出现某些故障时，做些降级服务来保证其基本的服务是可行的。

　　张修路：当年我在华为的时候，更多的是从事电信行业的发展，电信业务技术更多地依赖底层的硬件设计来提高它的可靠性，而互联网和云计算更多的是依赖于业务，以及自身系统的设计来保障它的切换和可靠性。后来，来到云之讯之后，主要从事语音呼叫中心、短信平台的系统架构设计。我们的很多客户，包括京东、58同城、唯品会、天机等，它们主要从事互联网方面的业务，但在这个过程中，为了给客户提供更好的服务，便需要将互联网业务与电话、短信系统相结合，怎么样把互联网业务跟电信云技术相结合，是他们的一个需求。我在过去的十几年从事电信方面的业务，最近几年更多地从事互联网业务，因此能够较好地理解他们之间的差异，可以给客户，利用底层的技术提供一个更好、更可靠、更稳定的服务，又能够通过他的业务设计来保障其在尽可能低成本的情况下提供业务的连续性，这样就能够较好地服务我的客户，这也是我目前技术工作的重点之一。

　　张修路：当我们在进行该系统设计的时候，我刚刚接触这个团队，然后我发现我的大多数同事对系统架构设计理解不是特别地到位。比如说，他们会将每一个服务，或者每一个小功能设计成一个独立的部署单元，导致多层次的设计。我们的目的在于设计一个大容量、高并发、高可靠的系统，为了实现高并发，每个系统都要部署一个机群，会导致每个独立的功能在寻找另外一个业务的时候总要检测它的可靠性，这种模式会带来了整个运营成本的提升，而且可靠性难以被提高，任何一个部件出现故障，都会导致整个系统的切换。后来，我们和同事一起分析，将整个系统尽可能做扁平化的设计，并且我们也成功做到将业务与数据相分离，以及业务和前端的接入相分离，整个系统一般会通过两层，第一层首先进来的是客户的业务请求，通过LVS或者Nginx之后，做业务分发，在业务分发了之后，做到主备或者机群，而且它可以做到主备一旦出现问题能够快速地切换，节点自身的容量也非常大，后面也会出现更多的对等机群。这些机群，因为业务之间完全对等，因此任何一个节点出现故障便能够在很短的时间之内切换到另外一个节点，为了更好地保证业务的连续性，我们把该业务和该数据逻辑相分离，且将业务内存缓冲在类似redis这样的内存数据库中，将持久化的数据放入主持人MySQL的数据库集群，将数据扁平化。简而言之，将业务和数据分离，能够较好地做到扁平化，并保证其出现故障的第一时间能够很好地做切换。

　　张修路：好，关于呼叫中心，第一，我们要做到信令和媒体分离，因为如果我要真正做到完全分布，信令在那种情况下并不容易切换，并且信令在整个媒体的处理过程中所占流量比例非常小；第二，整个信令在接入过程中，它对网络的抖动实验的敏感度便降低，因此可以将信令做集中部署。比如说我们部署在北京，同时在深圳作为异地的载备节点，我们会把媒体进行分布式处理，目前我们在北京、上海、广州、深圳等几个节点进行部署，而用户则通过分布式接入的方式载到系统内。如果要想部署一个真正的分布式系统，首先需要考虑客户如何切换，我们是通过信令来引导媒体地切换，比如说，当一个用户注册的时候，他会通过DNS查询，注册到北京的服务器，北京的服务器收到请求之后，根据该用户所处地理位置和他所在的运营商选择一个较好的媒体接入节点，将它引入到就近的媒体节点，通过呼叫中心的信令协商，就可较好地完成整个分布式的部署，即使某个节点出现故障，也可较快进行切换。假设现在在深圳有20个节点，如果其中一个节点出现了故障，那么我可以在几秒，甚至更短的时间之内切换到另外一个健康的节点，既使整个深圳市的机房出现了故障，我也可以通过信令来引导，把它切换到北京或者上海的机房；当信令节点出现故障或者机房内的故障，我们可以做到自动切换；如果是整个机房出现了比较重大的南北互通问题，我们就可以把整个信令通过DNS引导把它切换到深圳。为了更好地保证业务的连续性，减少实验抖动，我们所有的业务系统和所有的分布式节点都会通过专线来连接。

　　张修路：传统的呼叫中心往往都是以整个设备运营商为主导，整个设备的提供商也是些电信设备提供商，类似于华为的IPCC，这样整个传统的呼叫中心，它不仅需要客户购买一整套（呼叫中心）硬件设备，还需要客户自己部署和二次开发，因此整个系统部署周期和上线周期十分漫长，一般时长为三至六个月，而一些较大的呼叫中心仅在筹备期都需要三至六个月，那么整个系统建设和业务完整的提升将近一年时间。云呼叫中心，结合最近几年云计算的发展，我们将一些系统分布式部署于云上，就像我们提供北京、上海、沈阳、深圳、广州的一些节点，它们被分布在呼叫中心，那么客户便不再需要购买完整的硬件设备，而是直接安装其客户端，甚至可以通过网页直接使用服务。它的一个强大优点在于（中小型客户）不需要像过去一样建立一个只可做基本业务的小呼叫中心，而可以通过云呼叫中心进行。其主要优点有两个，第一，不需要购买硬件，业务可快速上线，客户可以在更短的时间，甚至一至两周内便把业务上线；第二，即使不购买硬件设备，也可提供一个较完整的业务，换言之，尽管他的业务代表只有几十个，但他仍可以使用一个大型的完整呼叫中心，因为它具有较好的可靠性，过去当你买了硬件设备之后，他们会派专门的运维工程师对整个系统进行运行和维护，但小的公司很难有非常高水平的运维人员，它的业务自然连续性便会受到影响，而我们会有非常专业的团队来保障业务可以真正做到每周7天每天24的运行时间，即使出现故障，我们也可以做到在多个分支的节点进行切换，而小公司却不太可能部署此种系统。

　　张修路：我们的系统去部署一个较大的系统确实会带来一个处理很高的并发，比如说我们的系统设计要做到一百万的并发，首先要做到高并发、高可靠。第一，在地域上需要做到分布式，那么在每一个机房里面需要多个对等的节点，一旦某个节点出现故障便可自动切换，当多个节点不断堆叠的时候，便可达到高并发要求，但前提是系统架构要能够支持平滑、横向的扩容；而横向的扩容前提是，前面需有一个接入。其中有着专门做接入的设备，目前我们前端通过Opensips或者Nginx做接入，它可以支持几十万，甚至上百万的并发，那么在多个对等的媒体节点之后出现故障也可进行切换。如果要想真正做到高可靠、高并发，低成本的系统，不能采用过去较多使用的同步编程，当一个用户的请求过来，，即采用且用专门的线程来处理该请求，但该过程偶尔会出现等待状态，造成阻塞，一旦形成阻塞，若要想服务一万个用户便需要提供一万个线程，导致既使没有业务进来，这一万个线程之间的相互切换也会带来超大负荷。那么如何解决这个问题？我们采用异步编程，比如说异步Servlet、异步Httpclient，或者是J张修路v张修路、C语言，利用各种各样的异步技术保证其高并发性。通过异步技术实现用一个线程处理几百个、甚至上千个连接，即使整个系统只有十几个或者二十几个线程也可处理几万的并发。

　　张修路：刚才我们所讲述的异步编程涉及更多的是一个完整的业务连接，而异步编程也可能体现在具体的模块之中。在具体的模块之中，我们也会要求同事熟悉异步的编程模型，因为大多数同事之前用的是传统的Servlet技术或者传统的请求，比如说当它发送请求之后，对方可能需要三秒钟才会响应，这个时间它不得不进入等待状态或者进入Sleep状态，但现在我们让同事熟悉异步的编程模型，比如C语言，以及异步的编程架构，比如C语言的libevent、libev这样的架构，Java语言的VERT。X、netty等其它的NIO技术，通过第三方的模型对它进行再重装，即不断地教他如何做到一个线程同时处理几百个或者上千个请求。在此过程中，不在于技术有多么难，而是一种观念的挑战，让他熟悉，并且真正能够接受异步编程，一旦我们的同事熟悉、接触异步编程，并且看到它带给整个系统的好处，就更为容易达到目的。整个系统逐步地架构升级就采用异步编程，既真正地实现高并发，在出现问题又能自动切换，实现高可靠。

　　张修路：在去年年底加入云之讯之后，我主要负责语音业务，尤其是云呼叫中心的技术架构发展，同时也要整合公司的所有业务。我们公司目前提供语音、短信、即时通讯、流量等，且现在较多客户需要一套完整的解决方案。比如说我需要给客户打电话，但客户没有接听电话，或者接听了之后，对于信息的获取、了解不是那么深入，这该怎么办？我们会再给他发个短信，这样就把短信系统整合进来。现在有些人，他更喜欢使用语音的电话服务，但另一些人更愿意使用即时消息，所以我们也提供了一个即时消息的解决方案，同时如果客户使用我们服务的时候消耗了流量，我们也可以通过赠送流量的方式提供，相当于我们为我们的客户提供一个完整的解决方案，包括语音、短信、即时消息，以及流量，一体化和一站式的解决方案。

　　InfoQ：非常感谢您今天接受我们的采访。

　　张修路，2002年哈尔滨工业大学研究生毕业加入华为公司，工作至2014年，任高级工程师，先后负责多个产品的系统设计。加入云之讯后，负责IPCC的研发与系统设计工作。有丰富的电信级产品系统设计经验，熟悉大容量、高并发和高可靠要求的产品设计。

　　QCon是由InfoQ主办的全球顶级技术盛会，每年在伦敦、北京、东京、纽约、圣保罗、杭州、旧金山召开。自2007年3月份首次举办以来，已经有包括传统制造、金融、电信、互联网、航空航天等领域的近万名架构师、项目经理、团队领导者和高级开发人员参加过QCon大会。