CTO讲堂打造数据可靠服务高可用的客服平台

Posted 2021-04-24 CTO俱乐部

Udesk CTO肖立鹏带来“打造数据可靠、服务高可用的客服平台”的主题分享。本文为讲堂分享整理。

欢迎加入CTO讲堂微信群与业界大咖零距离沟通，1月21日本期讲堂详情点击文末“阅读原文”查看。

分享嘉宾： Udesk CTO 肖立鹏

嘉宾简介：肖立鹏，Udesk CTO，毕业于吉林大学数学系和中国科学技术大学计算机系，之前就职于腾讯基础架构部，从事分布式系统的架构开发，日常工作就是和云打交道,曾经为腾讯云做了许多基础模块和产品。网络层逻辑层和存储层都有涉及，其中CMEM/CKV平台运营8000+台机器，不仅仅是对外为腾讯云，还对内为微信这类明星产品提供云支撑。期间参与如滴滴打车、微信支付/红包等架构改造项目。

以下是1月14日CTO讲堂现场完整速记：

主持人：今天讲堂开始啦，欢迎Udesk CTO肖立鹏，请您给大家介绍下自己。 
肖立鹏：大家早上好，我是Udesk肖立鹏，之前就职于腾讯基础架构部，主要工作内容是分布式系统的架构开发和运营。我对系统的高可用性和高可运维性比较关注，很高兴今天能与大家一起交流。

主持人：您之前在腾讯从事分布式系统的架构开发方面的工作，之后什么契机下选择加入Udesk？看到了什么发展机遇么？谈谈当时的想法。 
肖立鹏：在腾讯云经常和用户打交道，交流中发现用户不仅对IaaS有需求，对SaaS也非常关注，尤其是CRM和客服系统，利用得好能直接给企业带来收入。

主持人：请您介绍一下Udesk的技术团队及构成。 
肖立鹏： Udesk成立于13年底，产品用户覆盖互联网金融、教育培训、企业服务、O2O、移动互联网、电子商务、媒体等行业，如今发展到100多人，其中一半以上是研发，我们按照模块划分成多个小团队，每个团队工作独立，团队间工作平行。此外还有独立的测试、运维、技术支持等支撑团队。

Udesk的特点是多渠道、社交化、移动化、SaaS模式。前三个是让用户用的好，SaaS模式是为了让用户用的起。我们的使命是让中国广大的中小企业都能通过担负的起的价格用上中国最优秀的智能客服系统。

主持人：借助Udesk，如何做到提升企业客户服务满意度的？与市面同类型的国内外同类产品相比，您认为Udesk的竞争力体现在哪？ 
肖立鹏： 提升客户满意度主要是两个个指标，一是提高企业客服的响应时间，第二是提高客户问题的解决效率。Udesk主要从三个方面来帮助企业提升客户服务满意度：首先，通过多渠道连接企业和客户，不管客户使用什么沟通渠道都可以非常方便的联系到企业的客服人员；第二，Udesk提供了强大的工单系统，客户提的问题能够高效率的工单流转到企业的业务部门去解决，提高问题的解决效率；最后，Udesk有强大的数据分析模块，帮助企业做绩效管理，提高企业运营效率，深度挖掘客户的需求。

Udesk的竞争力主要表现在三个方面：

1. 一是产品，我们的产品团队不仅有着互联网产品设计的经验，更有着多年来企业业务产品设计的经验，我们的产品方向也是目前业内领先的，现在其他的类似客服产品都是按照Udesk的产品方向在做；

2. 二是技术，我们核心技术团队都来自各大互联网公司，有着上亿并发的技术经验，对于SaaS服务来说，产品的稳定性、安全性非常重要，Udesk的技术实力有着绝对的竞争力；

3. 三是服务，我们有一支非常优秀的客服团队，她们都有着多年的it系统客服工作经验，她们用专业的技能，良好的态度，帮助我们的客户能把Udesk顺利使用起来。

主持人：请谈谈技术架构和用到的技术，技术上遇到哪些难点和解决办法。 
肖立鹏： 

Udesk第一个版本便考虑到了水平扩展和容灾切换，数据支持冷热备份，用户可以放心的把客服服务托管到Udesk。接入层使用LVS来实现负载均衡和故障剔除；逻辑层前端用Ember.js做单页应用，后端Ruby On Rails提供接口；缓存用Redis，单机可支持10w的qps；存储层数据库是mysql做的Sharding，每一个Shard都有热备份，对象存储托管到了七牛；基础组件包括即时通讯、搜索、邮件等服务，全局无单点；运维运营方面Monit做进程自动拉起和存活检测，阿里云监控管理服务器健康度，NewRelic做应用性能管理，ELK做日志分析，Nessus做系统漏洞扫描分析。

纯粹技术的难题不多，更多时候是在做trade-off，CPU还是内存？高可靠还是低延时？完美方案还是柔性可控？如何选择看应用场景。

主持人：请谈谈高可用可扩展系统的建设，有哪些技术关键点？ 
肖立鹏：可扩展架构的资料非常多，我整理了一下，大家按需取用：

一、负载均衡——可扩展性&冗余容错

水平扩展：负载能力和增加硬件呈线性关系。如果你有一台服务器并增加一台，负载能力翻倍，再增加一台，负载能力增长33%。 

冗余容错：一台服务器死机不会影响服务的正确性，只是降低系统的负载能力。 系统支持水平扩展最重要的一点的是逻辑层无状态，状态信息可以存储在缓存或数据库中，其它就交给负载均衡吧。

负载均衡主要有3种实现方法： 

二、数据缓存

缓存是一个系统中性能提升的关键。主要有5种实现方法： 
应用层：应用自己在本地内存或其他介质中缓存部分数据，一般通过LRU算法淘汰。 

数据库层：数据库引擎自身的缓存，需要DBA来配置优化，当然现在也有不少NoSQL的缓存+存储解决方案如MongoDB、带HandlerSocket插件MySQL、TTServer等。数据库缓存的好处是应用侧代码不需要更改。 

内存缓存：目前的主流解决方案，代表有MemCached和Redis，Redis的优点是数据结构丰富，可以轻松支持排名等场景，缺点是单进程实现导致持久化方案不够完美，去年4月Redis Cluster终于迎来了第一个稳定版本，可以实现数据自动Sharding和容错，稳定性有待后续检验。 

网页缓存：在Apache等HTTP服务器上，配置full-page cache等策略。 

CDN：对于静态文件，一般采用CDN来加速。使用缓存的过程中，必须要注意缓存有效性，在数据源更新后，要及时更新缓存中的数据。目前主要有read-through和write-through两种策略，采用write-through的多些。

三、离线处理

对搜索引擎，广告推荐等数据分析类场景，必须对数据做离线处理。主要有3种主流的实现方法：

1. 定期任务：每天每小时的任务，使用crontab或者其他cron服务来调度。

2. 并行计算：采用MapReduce，Hive，Impala等。

3. 消息队列：任务排队，并发处理等，主流开源组件有RabbitMQ，Kafka。

四、平台建设

提供给应用的，不是一堆组件，而是一组API，把底层架构隐藏起来。这样有两个主要的好处：

• 底层架构重用，可支撑多应用，运营更方便。 

• 应用和底层架构解耦合，底层架构可自我演进，是Scale的必备基础。

主持人：大规模分布式系统的核心技术和实现方法有哪些？请展开谈谈。 
肖立鹏：分布式系统设计的方法论很成熟，核心在运营。换句话说，设计仅仅是起点，运营才能磨练出好的架构。我们不会主观的去判断系统架构的可用性、可扩展性、数据持久性或者健壮性。而应该看它的运营数据，看它是不是能在运营中不断发展，最终成长为“大规模”的系统。

我的经验主要归纳为以下几点：1、确保设计简单：简单的就是最稳定的，简单的就是最好扩展的；2、小步快跑：将需求切分，快速迭代，局部重构，动态完善系统架构；3、灰度发布：系统首次变更只覆盖小部分用户，做好监控，获取反馈，之后全量；4、大系统小做：这是一个比较腾讯化的叫法，翻译过来就是Microservices，模块功能尽可能单一，确保稳定易扩展；5、柔性控制：高峰期提供低质服务，实现削峰；6、有损服务：服务可降级，故障时确保系统关键路径可用；7、工具齐备：高可运维性，自动部署、多维度监控、数据分析、故障定位工具齐全。

主持人：如何平衡系统可用性和数据一致性？ 
肖立鹏：分布式计算领域有一个公认定理——CAP理论，它指的是一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。

我们在设计系统时，不可能三者兼顾，互联网应用分区容错性是必选项，一致性可用性如何取舍需考虑业务场景，对于绝大多数互联网应用场景来说，会经常性的出现节点故障，网络不稳定等情况，这时我们选择牺牲一致性来保障可用性和分区容错性，让绝大多数用户可以被服务，比如QZone的访客，两次刷新访客不同的影响显然要比访客列表不可见体验要好，并且我们可以通过一些机制实现数据最终一致（BASE）。而微信支付的账单，系统元数据等场景则必须保证强一致性，常见的是故障时执行只读策略。

主持人：数据安全方面以及容灾备份方面，Udesk是怎么做的？ 
肖立鹏：对于数据安全，从数据私密性角度讲：我们会及时跟进新公布的漏洞并对系统做升级，防火墙只开放安全端口，限制密码登录等。同时我们与国内知名的白帽子公司合作，不定期进行第三方入侵演习。通过实战演练来锻炼队伍，提高系统的安全性。其次是内部管理保障，Udesk所有管理人员均来自知名的IT公司，有良好的职业操守和保密习惯，同时我们也制定了严格的保密制衡制度。

容灾备份是保障数据持久性和服务可用性的手段，我们的具体做法是：逻辑层无状态设计，通过LVS实现名字服务和故障剔除。数据库使用阿里云的RDS，带名字服务的MySQL主备，单机故障自动切换，用户无感知，每日冷备份镜像加流水，支持分钟级别回档。对象存储用七牛，支持3副本多IDC分布。监控系统同时用阿里云监控和监控宝，以防某个服务商故障无法告警。以上是在架构设计上预防天灾，在互联网运营中，人祸也是很大的一个部分，云服务是一个动态过程，每天都有新企业注册，每天都可能因为用户的增多需要扩容，这些需要人去处理。

我们的运营流程分四个部分：1、设计完善的运维运营规范；2、确保规范得到执行；3、要有故障预案机制；4、确保预案机制在关键时刻必须生效。我把这它归纳为：流程、执行、预案、演习。

主持人：能否透露一下Udesk短期和长期的发展规划？ 
肖立鹏：Udesk的定位是新一代企业级智能客服平台，会专注于客服系统这个领域。短期规划是把Udesk目前规划的智能机器人、在线客服、呼叫中心、工单系统为一体的完整的客服系统解决方案做的更好用，更稳定，更安全。我们要做中国最优秀的新一代客服系统，必然要在产品和技术上领先同行。长期的话，Udesk会为企业提供更多的价值，帮助企业用户能深度的把Udesk使用起来，另外，我们还会与国内其他的优秀的SaaS服务厂商集成，为企业提供一个整体的解决方案。

主持人：怎么看客服服务领域未来的发展？Udesk下一步的重心是什么？ 
肖立鹏：现在的企业越来越重视客户服务了，一方面是消费者的要求越来越高，另一方面很多企业也越来越重视用户了，所以客服系统会是以后企业必备的IT系统，企业会在这个方面持续投入。Udesk会专注于在企业服务领域，持续的创新，提供支持渠道更多、更智能、更稳定、更安全的客服系统。

主持人：请结合这些年您自己在技术之路上的积累，谈谈技术人该如何做到高效学习和提升技能？ 
肖立鹏：

• 首先是看文章、读代码、写代码，独立解决问题，要长期不间断的实践。

• 其次抓大放小，少量时间用来泛读，花大量时间在关键的价值点上，比如在线客服的核心是不丢消息，这块你就要有意识的做得足够深。

• 再有就是多总结，从经验中总结出将来发展需要的方法，然后用这个方法不断的取得成功，举个例子，二分法可以用来排查故障，优化慢查询。

• 最后一个事业心，要不断思考如何把一件事情做得更好，你有没有优化过你的系统，效果如何，还能不能继续优化，继续优化的成本和收益有多大。

主持人：请结合您的切身体会谈谈创业路上您都有哪些收获和思考，对于如今越来越多想要投身创业大海的年轻人，有什么建议？ 
肖立鹏：我们所处的企业服务领域是这两年才起来的一个创业方向，相比于ToC的创业，企业服务的特点是门槛高，发展慢，因此大部分的人创业会选择短平快的创业方向，但短平快的项目成功的概率也比较低。我们之所以在客服领域创业，是因为我们的团队深度了解用户的痛点，并且有解决痛点的产品、技术、运营能力。

创业是一个有挑战、高风险、高收益的事情，希望所有开始创业的人都能在创业之前评估清楚自己的风险承受能力，找准用户痛点，并且能长期坚持下去。最后无论创业与否，希望大家能都找到属于自己平台，有足够的空间、动力和资源来做事，实现自己的价值。

主持人：对想在技术路线上走得更远的人，您都有什么建议和忠告？推荐一些您觉得非常不错的资料或者书籍吧。 
肖立鹏：技术首先要创造价值，我们总是谈技术深度、大局观、影响力，有时理解过于生硬。技术深度不等于难度，而是你是否扫清了项目前进道路上的障碍。大局观不是做了大项目，而是是否能识别技术的价值，清楚什么能做，可以做到什么程度。影响力不是分享多少次发多少文章，而是别人是否真正在学在用你的东西。

推荐一些网站吧：High Scalability（highscalability.com）：可扩展架构实践。StackShare（stackshare.io）主流公司技术栈。Hacker News（news.ycombinator.com）互联网资讯。

---

互动环节：感谢肖总的分享，学到很多。请问在客服系统的底层技术上，UDesk有哪些领先优势。比如语音通信、IM、AI机器人、知识库等。 
肖立鹏： Udesk的技术优势主要在云平台研发和运营经验上，我们的技术团队实际承载过大并发量的考验。垂直技术上IM我们在消息到达上做了不少工作，语音和机器人则是引入第三方合作伙伴，我们认为这些领域需要很深的积累，彼此合作才能为用户提供最优质的服务。

互动环节：如果企业客户的业务复杂，单纯的客服应答无法彻底解决客户问题，UDesk是如何解决的？ 
肖立鹏：一线客服无法处理的问题，可以生成工单，流转到专业的人员来做二线处理。

互动环节：大规模分布式系统之间的心跳和路由的可靠性，UDesk是如何做到的。 
肖立鹏：名字服务是跨可用区可用的，此外之前参与开发过L5系统，通过路由下发到本地agent实现，节省了硬件资源。

互动环节：请教一下，你们的工作模式只是集中在托管方式吗？有没有直接给企业开发系统，在企业方机房部署，实用的概念。 
肖立鹏：我们推荐SaaS模式接入，这样减少资产购置和维护成本，接入效率也更高。

问：企业用户和你们的系统或者服务是如何对接起来的，比如你们会提供一个统一的登录和操作入口给企业用户，还是你们开放API给企业用户，企业自建或者改造已有客服系统与你们对接。 
肖立鹏：用户层可以做API对接，后台直接登录Udesk，同时我们做了一些平台对接方面的工作，比如用户来电时展示企业用户自己的页面。

互动环节：肖总，您好，谢谢您的分享，我们现在也在做一个平台，我们公司有很多仪器仪表，应用多个业务领域，如工业安全、市政供水、供气、环保等，现在我们想做一个基于大数据的平台，同时想支撑多个业务。初步的思路是 一个数据平台，一个业务平台？请问肖总有何好的建议？ 
肖立鹏：这个数据平台想要达到的效果是什么？ 

问：把我们多行业应用的仪表数据打通，再反馈到行业应用业务系统上去。譬如，我们现在 工业安全生产领域 每年多有 80000多个气体监测的仪表，还有对压力、温度、流量等的仪表等，我们想把这些数据都收集起来，针对安全生产领域，做深入的业务应用，想达到最终的目的，预测或预警企业生产过程中安全系数及指导意见。 
肖立鹏：这样数据平台和业务平台必须是分离的，一个做OLAP，一个做OLTP，OLAP这块做到什么程度，要看数据的规模。

互动环节：我做为客户更加关心客服系统的智能化程度，比如同类或关键问题的被发现，工单的转移和客户确认等。我的个人感受：京东的客服系统是垃圾中的战斗机。 
肖立鹏：据了解京东在智能客服方面和微软小冰合作，在意图分析方面做了一些工作，有兴趣可以继续了解下。

互动环节：能否谈谈系统迭代和重构方面的经验？ 
肖立鹏：可以参考下运营经验部分的回答，迭代遵循敏捷开发原则，尽快上线尽快验证获取反馈；重构方面如果遵循了大系统小做的原则，模块功能单一，重构扩展都会非常方便，但要权衡好带来的运维、监控成本。

互动环节：我们公司服务很多中小教育机构，帮助他们建立微网站、微信服务号，请问是否可以介入udesk的客服系统？ 
肖立鹏：可以，网站和服务号渠道都是支持的。

互动环节：您成为 CTO ，怎么权衡技术与管理的呢？刚开始做管理的时候，是怎样开展和学习管理的呢？ 
肖立鹏：技术管理者要做好三件事知人: 识别人才，培养人才；晓事: 专业的深度和广度，对事情的掌控；营销: 能找准方向，产生价值。技术一定不能丢，自己强才能度量别人，leader的水平决定团队的水平。