作者丨安静波

编辑丨千山

本文整理自天润融通CTO安静波在WOT2023大会上的主题分享，更多精彩内容及现场PPT，请关注技术栈公众号，发消息【WOT2023PPT】即可直接领取。

日前，在主办的WOT全球技术创新大会上，天润融通CTO安静波带来了主题演讲《全渠道智能客户联络平台技术架构的挑战与演进》，为大众呈现了全新的视角。

最近几年，天润融通业务从专注呼叫中心发展到全渠道联络平台，并逐步与AI技术相融合，帮助企业加速高效智能化管理的转变。这个过程不仅仅是产品功能的叠加，更是业务模式的变革和技术架构的升级。安静波详细介绍了天润融通在发展过程中如何面向业务需求进行技术架构的迭代。

本文将摘选其中精彩内容，统一整理，希望为诸君带来启发。

一、十七年发展历程中的四轮变革

成立于2006年的天润融通一直以来专注联络中心业务。无论是最初的呼叫中心，还是发展到如今的全渠道全周期的联络中心业务，天润融通在十七年间都在坚持为客户联络这一场景提供服务，整个发展过程中经历了四轮架构的重构。

阶段1：2006-2012，软交换+呼叫中心。这一阶段主要完成了大规模语音交换平台的开发和商用，具备了大规模、灵活处理语音业务的能力，与此同时，为复杂呼叫中心的产品演进建立了扎实的平台底座。

阶段2：2013-2016，云原生重构。以云技术为核心，对平台进行彻底的原生改造，从架构上实现了大容量下的高可用，彻底突破容量瓶颈；具备异地、跨云双活能力的平台上线，解决了快速演进与稳定运行的矛盾。

阶段3：2017-2022，全渠道+智能化。由语音呼叫中心升级为全渠道联络中心，具备了完备的全渠道覆盖能力；利用基于深度学习的AI技术，对平台进行智能化改造，构建完整的AI产品体系。

阶段4：2023至今，AI原生重构。以AI技术为核心，以企业知识管理为基础，构建“人机融合”的新一代客户联络平台；业内首家推出“客户联络垂直场景” 下的大语言模型行业解决方案，同步推出一系列AI产品。

天润融通在2018年之前就成为了中国最大的公有云客户联络解决方案供应商。我认为，之所以能做到这一点的主因在于：天润融通精准地定义了呼叫中心云服务是什么，决定性因素在于以下三点：

原生架构的云核心软件。简单来说，基于软件架构+云。

云网一体的业务承载网络。在客户联络场景中，像语音这种业务必须做到实时性和高可用。任何网络节点出现问题，软件就没用。因此，如何构建云网一体的业务承载网络是产品核心的架构问题之一。

全局性高可用的云生态系统。除了软件、网等问题外，如何进行通信资源的调度，如何用生态系统来解决高可用问题。

2018年之前，我们清晰地意识到，这三点是最核心的工作，所有的工作都围绕这三条主线来展开。基于此，我们也获得了客户的认可。

面向未来，我们认定智能化将是联络中心未来最核心的东西。我们希望用AI和大模型去重构云联络的架构，进而实现实时SaaS、业务SaaS和人工智能的完美融合。

二、业务发展过程中遇到的挑战和应对

接下来，综合回顾一下整个业务发展过程中遇到的挑战。我总结了其中三大最主要的问题。

1.如何实现大容量高可用的实时SaaS平台

可归纳为两点：端到端与全云化、全链路高可用架构。

所谓“端到端与全云化”，简单解释，即呼叫中心云服务是全链路的.端到端包含五个层次：系统软件、云平台部署、网络接入、座席端设备，以及通信资源整合。其中任何环节出问题，平台对客户来讲就不能用。

可以看到，整个链条是比较长的，所以要考虑的是端到端和全域化这样的结构，才能解决此类问题。

在高可用上，要考虑的就是六个方面的高可用：软件架构高可用、云服务高可用、基础设施高可用、通信资源高可用、网络架构高可用、可持续的演进。因为SaaS服务最核心的灵魂就是可以快速创新和演进。这个创新要能服务于客户业务的创新，如果失去了这种能力，这个平台就“死”了。如何做到在快速升级的同时还能够稳定地提供服务，对SaaS软件来说至关重要。

简要概述一下几个“高可用”的核心要义。

软件高可用：通过解耦、集群化、尽量使用原生的云组件、运行可度量来达成软件高可用。另外，把架构分层，让底层通信与应用分离。

云网一体高可用：基于支持的云很多，采用跨云、多云架构。北上深三地的核心网各自拥有两个核心机房，六个核心机房组成南环和北环，环之间用光纤链接，以此来实现高可用。

高可用通信资源：将通信资源能力云化和池化，话务调度系统可以根据业务变化灵活调整，应对故障及拥塞等。

高可用演进架构：支持DevOps组织结构，实现设计、开发、测试和运维一体化；关键应用灰度发布，而且要做两级灰度；配套建设自动化。

2.如何应对实时SaaS和业务SaaS高复杂两个维度的叠加

当我们能很好地保障实时，同时面临业务拓展时，如何解决业务SaaS高复杂叠加的问题？应对策略有三点：

1）对不同业务有效分类解耦，应用不同原则。

具体来说，从业务分类来讲，分为实时系统和业务系统。实时系统包括通信平台、呼叫中心、RTC音视频、机器人等，这些都要求在秒级甚至毫秒级有响应。相较而言，业务系统诸如CRM/SCRM、工单、知识库更多的是考验复杂度，考验对业务的理解。两者要应用不同的架构原则，最终组织结构也要匹配架构原则。

2）构建SaaS业务基础框架，提高复用效率。

所有新业务都是从尝试起家，但是如果没有一些基础模块的支持，试错的代价不菲。因此要构建一些基础的、可复用的东西，作为整个公司级别的基础设施。

构建SaaS业务的基础框架大致可以分为7类，分别是：RAM，即统一的用户权限体系；BOSS，即业务支撑体系；Workspace工作台框架和微前端容器；基础报表引擎，避免从头搭建报表；前端可复用结构，如低代码引擎、统一的UI规范等；运行监控体系；安全管理体系。总体来说，当业务足够多时，有这类基础框架，才可以快速地让新的应用高效接入。

3）SaaS业务的PaaS化架构，构建竞争壁垒。

将部分SaaS业务做PaaS化，最核心的价值就是能帮助企业提高交付效率。关于这一点，分享几点认知：

3.如何在联络中心场景中深度融合AI能力

如何理解深度融合？AI在联络中心里的应用，并不是简单地做语音机器人、文本机器人，而是应该理解成为，将工作的业务流和整个业务过程中的每一步全部AI化。以呼叫中心为例，从电话打进来、怎么排队、排队时长的预测，到接通如何做情绪识别、客户标签画像，到通话结束如何进行满意度调查，到最后做一些分析，过程里每一步都要去如何智能化。这就是我们对智能化融入到云联络中心，真正实现人机融合的理解。

三、业务机构和技术架构原则

下面分享一下我们在实践过程中总结下来的一些业务架构和技术架构的原则。

1.匹配原则。

2.稳定和创新相结合。

平台要分为稳定平台和创新平台，稳定平台承载主要的客户，创新平台承载需要频繁有需求的客户；要建立持续分类的标准和工具，类似CICD概念能够在客户发生变化时快速调整。

目标清晰具体表现为：各应用独立发布版本，独立升级；独立资源部署，应用之间隔离，不会互相影响稳定性；各应用团队独立工作，通过API高效协作。

多应用之间采用低耦合交互原则，应用之间仅通过API接口交互，应用之间做到独立发布；产品内在的能力组件是低耦合的，产品设计在最终提供给客户的呈现必须是紧耦合的；表里不一，必须通过优秀的架构师把外在一体的呈现分解和抽象到边界清晰的模块内。

3.客户为中心原则。

平台灰度原则，所有新版本发布先在创新平台进行，修复小编题后再升级稳定平台；客户灰度原则，对单一客户提的需求，采用在单一客户上灰度的方式开发和上线，避免变更影响其他客户；客户可在多平台可移动原则，客户的稳定需求和创新需求是变动的，需要具备客户无感迁移方案，周期性动态调整平台上的客户，达到平衡作用。

出现问题判断是否是单一客户问题，如果是全局问题，影响一类客户占比超过10%的，影响大客户1个以上的，快速回退再分析问题解决问题；需求紧急程度永远是低于故障紧急程度，确保中午或当天晚上修复问题再次上线。

API接口一经发布，不可删除和变更接口定义和返回，只可以以兼容的方式增加参数和返回；API接口的实现工作量要远小于业务集成所需，接口的设计一定是架构师主要工作，也是架构思想的体现。

4.大模型重构SaaS技术架构展望

到目前为止，天润融通以AI为核心，融合了包括接入渠道、营销服业务场景在内的若干应用。而从今年年初，我们就将2023年定位于用大模型来重构我们联络中心架构的元年，在此做一些介绍和展望。

当前，我们融合ChatGPT、文心一言、通义千问等LLM的能力，上线了语料扩写、知识抽取、文档问答引擎等功能，另外，还有话术优化、闲聊寒喧兜底等功能在测试中。

总体而言，大模型对于云联络SaaS场景的革新（或影响）将会非常大。客户对大模型的期望非常高，对我们也有很多期望。当然，也有人会焦虑，当机器大量取代了人工的时候会带来某些不可测的颠覆式改变。但我们相信，面向客户的需求，贴近客户行动的组织是可以转型成功的，而不是反过来。

五、总结

总结一下今天演讲中的重要内容。

我相信，优秀的技术架构是演进出来的。这不意味着你要一个个坑重新踩一遍，我已经踩了这么多年的坑，不断地从坑里爬出来。今天的分享就是为了让大家少踩一些坑。或者当你准备往下踩的时候，你感觉这是个坑，你可以以开放的心态对外多交流，通过这种交流来加速你对架构的某些理解。