关于话务平台的架构细节，看这一篇文章就够了_聊聊架构_【传送门】
关于话务平台的架构细节，看这一篇文章就够了
在个人信息敏感的互联网时代，链家网高度重视业主客户隐私信息，很早地开始建设了话务平台来保护通话安全，近些年也越来越多的行业重视号码隐私问题，比如Uber的司机给乘客打电话，来电并不会显示司机的真实电话，而是显示一个400或者010的号码。链家网话务平台由原单一代理商模式发展至今对接十余家电信代理商，由老式的号码关系维护在代理商侧模式演变为1000W号码关系维护在话务平台内部，支持链家门店覆盖的所有城市每周通话量30W+通。今天我分享的内容主要有以下几点：一、话务平台介绍二、话务平台发展与现状三、话务平台架构四、话务平台中的具体设计五、总结一、话务平台介绍我们先从具体场景出发，看看话务平台可以做什么。假设我们看中了这套房子，需要联系经纪人咨询，拨打页面上的这个400号码就能找到经纪人。另一个场景下，经纪人内部有一套作业系统，当经纪人需要联系他的客户时，他从系统里看不到客户的真实号码，经纪人呼叫的是一个分配给客户的虚拟号码，通过话务系统的调度完成和客户的通话。在上面两种场景下，无论是经纪人拨打客户，还是客户拨打经纪人，话务平台都能适用，我们做的是一个通用平台，在设计的过程中，我们很关注抽象和平台化的思路。这里，我们可以看到话务平台一个基本的能力，就是实现了号码隐藏。精确地说，是隐藏了被叫的号码。后面我们还能看到如何对被叫隐藏主叫号码，这里先卖个关子，嘿嘿。为什么要隐藏被叫号码呢？对于客户来说，可以防止客户信息泄露，防骚扰。对于经纪人来说，用户直接拨打经纪人真实号码可能受关机、不在服务区等因素影响，从而呼不通，而拨打经纪人虚拟号码能通过技术手段提高接通率，给用户更好的体验。虚拟号可不止400一种，话务平台提供400号码、1010号码、固话号、虚拟手机号等多种虚拟号码类型。业务根据具体需求来选用。一个虚拟号码对应一个或一组真实号码，我们称之为号码绑定关系。我想大家都认识Alice和Bob（学过计算机网络的都知道啦:P）。当Alice要联系Bob时，我们给主叫Alice和被叫Bob各绑定一个虚拟号码，例如给Alice的真实手机号绑上虚拟手机号，给Bob的真实手机号绑上虚拟号。然后，Alice呼叫，通过话务平台，呼叫转接到Bob的手机上，Bob看到来电了，他们愉快的通完话。之后，Bob想要回呼时，通过通话记录找到并回拨， Alice看到来电了，流程和第一路通话是一样的。通话的能力是话务供应商提供的，虚拟号码也由供应商提供。总结一下，话务平台是介于业务线和话务供应商之间的中间件平台，对外封装各家供应商的话务接口，形成统一的、一致的话务能力。对内锤炼出通用的通话模式，为业务提供抽象灵活的API，为业务提供服务。二、话务平台发展与现状我们来简单了解一下话务平台的发展情况。最开始没有话务平台是这个样子的：原始时期，经纪人和客户的通话不可控，可能出现骚扰、信息泄露等问题。自从有了话务平台，通话就能被管理起来。话务平台初期，只有单一供应商，号码绑定关系存储在供应商侧，话务平台通过接口定时或者按需同步号码绑定关系。这一时期话务有单点风险；话务本地的绑定关系，和远端的供应商侧绑定关系之间的同步容易出错，很难保证一致性；而且号码关系变更不够灵活。经过迭代改进，在目前最新的话务平台架构中，我们实现了号码关系维护在话务平台内部，通话时供应商服务器通过接口实时查询号码绑定关系；我们制定了供应商能力规范和标准接入流程，具备了快速接入供应商的能力；话务平台还支持固定关系模式和会话关系模式，虚拟号码支持多会话间的复用，大大节省了虚拟号码的使用量。目前话务平台已接入10余家供应商，号池储备的号码数量达到1000万，目前话务平台每周产生30W+次通话，随着业务的扩展，通话量还在不断上升中。三、话务平台架构我们来看看话务平台的技术架构。话务平台是典型的LNMP架构，架设在AWS云服务上，前端使用AWS ELB作为负载均衡，为业务方和供应商提供接入口，流量分发到后端多台Server上，Server可以很方便地水平扩展。ELB和Server之间有TCP健康检查。存储采用MySQL，用以保存号码绑定关系、会话关系、可分配号码号池，以及通话记录。通话记录历史数据会定期归档。旁路有一个控制台UI，用来做数据报表展示，以及控制号池调度。客户究竟是怎样通过拨打虚拟号联系到经纪人的呢？下面的时序图告诉了我们答案。1. 绑定。首先客户要拿到被叫经纪人的虚拟号。客户访问业务线产品，业务线产品调用话务平台绑定接口，传递经纪人真实号，话务平台从号池中取出一个储备虚拟号，建立绑定关系，并将虚拟号返回给业务线产品。在这里，绑号接口同时也是查询虚号接口，如果真实号已经有绑定关系，则直接返回已绑定虚号，如果尚未绑定，则绑定后再返回虚号。虚拟号是按需分配，并非所有经纪人都预先分配一遍，这样可以节约号码。2. 拨打。客户拨打虚号，或者通过APP自动调用号盘拨号。通话流程转到运营商，运营商再将通话流程转到与之有合作关系的供应商，可以理解为供应商在运营商处注册了路由。因为拨打的是虚号，而虚号的绑定关系存储在话务平台，故供应商调用话务平台查询虚号的绑定关系。3. 转接。供应商通过话务平台接口查到虚号对应的真实号，然后做转呼。双方建立通话。在这里，供应商可能查到多个真实号，按照约定，供应商按顺序逐个转呼真实号，直到某一个接通或者都未接通。每次转呼有一定的超时时间，这样既保证用户不用等太久，又避免经纪人漏接电话。4. 推送话单。当通话结束之后，供应商将话单数据推送至话务平台，话单包含号码、时长、计费、通话状态等关键信息。话务平台存储话单，并推送给业务方。在这里，可能受到网络抖动等因素影响而推不成功，我们的解决方案是：A、供应商重复推送，当出现超时、503等状况时，供应商标记该条话单为“未同步成功”状态，并在一定时间后重新发起推送，如果仍然不成功，则拉长时间间隔后再次推送；B、话务平台定期拉取话单，和本地数据check，若发现丢单则补单。以上通过重复推送和推拉结合的方式保证话单数据及时、正确地同步。这一设计在其他数据同步的设计中已被证明为一种行之有效的方法，比如支付行业，第三方支付平台通知商户支付订单状态就是采用这种方法。总结一下以上业务流程，我们可以得到话务平台的业务数据流，如图：四、话务平台中的具体设计让我们来深入一点，看看话务平台的具体设计。首先我们来看看怎样通过逻辑设计达到节约号码的目的，这涉及到话务平台两种绑定关系模式：固定关系模式和会话关系模式。1、固定关系模式话务平台最先支持的是固定关系模式。一个虚拟号，只分配给一个被叫真实号使用，不能同时分配给其他被叫真实号，这种绑定关系是独占式的。图中我们可以看到，这种关系下，有多少个被叫，就需要消耗多少个虚拟号。绑定之后，理论上任意主叫号码均能通过拨打这个虚拟号联系到背后的真实号。号码绑定关系可以被业务主动解绑，解绑后虚拟号回到号池，状态标记为“可用”状态，下一次分配号码时可以重复分配出去。号码绑定关系也可以由业务方指定有效期，例如可以指定为1天有效期，1天过后此关系自动过期解绑，业务方需要取虚拟号时再重新绑定。2、会话关系模式另一种会话关系就有很大不同了，先看看图。会话关系是相对于独占的固定关系而言的，首先我们设计了一个共享号池，号池中储备有多个虚拟号。对于主叫A1，当其需要联系客户B1时，话务平台从共享号池中取出V分配给B1，A1通过拨打V联系到B1，A1-V-B1就是一个会话关系。此时另外一个主叫A2，他需要联系客户B2，话务平台从共享号池中分配号码给B2，分配的号码可以仍旧是V，A2通过拨打V可以联系到B2，关系为A2-V-B2。为什么A1和A2，都拨打虚号V，能联系到各自的客户B1和B2呢？因为主叫号码不同，话务平台根据主叫号码定位到不同的会话关系，并转接到不同的被叫真实号码！从上面的图中可以看到，会话关系比固定关系要节省号码，让我们更进一步，假设A1要联系10名被叫，那么需要10个虚拟号，每名被叫对应一个虚拟号。这个时候，如果A2要联系另外10名被叫，A2可以复用这10个虚拟号，不会出现拨虚拟号不能定位到被叫的问题，因为他们的主叫号码是不同的。是不是很神奇?！会话关系也可以更复杂，除了给被叫分配虚号，也可以给主叫分配虚号，主叫的虚号就是被叫接到来电时的来电号显，这样两个真实号+两个虚拟号形成一组会话关系，当被叫回拨时，话务平台可以根据这个会话关系找到原始主叫真实号。号池调度通常，各个供应商、各个城市的接通率是不一样的，接通率是指拨通的次数占总呼叫次数的比例。为了优化接通率，在号码分配时有一些特别的设计。每家供应商都提供多批虚拟号，话务平台根据号码类型、适用地区、业务需求量等维度对其进行分片，划分成多个号码池。业务方一般配置为可以使用多个号池，以防某个号池号码耗尽，或者遇到供应商侧的故障，可以有备用号池保障号码分配能正常提供服务。当业务方申请分配虚拟号码时，会根据预先配置好的分配策略，确定使用哪些号池。分配策略规定了业务、城市、渠道与号池ID的对应关系。如果没有找到合适的号池，会选用默认的号池。为了优化号码分配，设计了一个号池评分模块。评分模块根据号池剩余号量、通话质量优劣（接通率）、以及人工干预等因素评分，确定优先级，优先级最高的号池被选中。号池选中之后，就可以从号池中取一个可用号码分配给业务使用，当号码关系解绑或者自然过期时，将号码回收到号码池，成为“可用”状态，如此号码可以循环利用。号池的设计，也是一种风险控制手段，如果号池消耗过快，来不及补充便耗尽，号池评分模块会根据剩余量自动降低这个号池的优先级；当某个供应商出现故障时，也可以通过接通率下降或者人工干预手段降低这个供应商的所有号池的优先级，从而让其他可用的号池来提供正常服务。号码回收与复用号码资源是有限的，在有限的资源和无限的需求之间如何平衡呢？我们设计了一些回收与复用的机制。在绑定号码时，明确指定了有效期属性，当有效期结束时，该号码会被回收至号池，下次分配可以重新使用。过期类型支持：不过期、绑定后指定时长后过期、首次通话后指定时长后过期、最后通话后指定时长后过期、定时过期。有些号码分配出去，可能并不会被拨打。话务平台设计了GC,会定期检查号码使用率情况，如果某个没有设置过期时间的虚拟号码，3天内没有被拨打，则可以认为是无效关系，GC会将其回收到号池。回收无人拨打的号码是安全的，因为使用方不缓存虚拟号码，而是展示时总是从话务平台实时获取，如果之前分配出去的号码已被回收，则会重新分配一个虚拟号给使用方。号码的复用，第一是体现在号码回收后可以重新分配给其他用户；第二是体现在会话关系中，一个虚拟号能复用给多个关系，能复用的关系数，取决于主叫能联系的被叫数量。安全与认证下面我们来探讨一下安全层面的考虑，安全是一个不容忽视的考虑因素。首先我们做了内外网隔离，面向业务的接口只能内网访问，面向供应商的接口能从内网和公网访问。其次，话务平台的接口采用https加密传输，防止中间人窃取、篡改数据。话务平台设计了业务方和供应商的身份标识体系，为每一个供应商和业务方都分配一个身份id，以及一个保密的随机字符串作为secret_key。每一次调用都需要调用者传递身份id用以声明自身身份。如何验证调用者是所声称的身份，不是冒充者？规定调用者需要传递参数签名，将所有HTTP的参数按照约定的顺序排序，拼接上secret_key，并做哈希计算，哈希值作为签名参数传过来。话务平台服务器收到http请求时，按照同样的规则重新计算签名，如果与传过来的签名值一致，则说明调用者是所声明的用户，验证通过；否则拒绝该次请求。参数签名能校验参数完整性，如果中间人篡改了参数值，会导致签名验证不通过。参数中还加入了时间戳，服务端验证时间戳是否有效，这可以一定程度上防止中间人截取到URL后重复调用，从而防止重放攻击。锁，并发分配号码以上措施解决了一些冒充、拦截、篡改、重放等安全威胁，但是还有另一种数据安全问题，那就是并发安全。业务方请求分配虚拟号，存在共享资源的竞争，号池里的号码就是共享资源。这一过程，是先从号池里取出一个可用的号码，再创建绑定关系。对于两个并发请求，怎样防止取出同一个虚拟号分配出去呢。这种数据一致性的问题，可以用分布式锁来解决。锁是一个很大的话题，这里就不深入展开了。五、总结总结下来，话务平台在设计时，重点考虑了以下平台化思路：提出供应商能力规范，统一了供应商提供的服务，以建立供应商能力抽象层，方便动态调度和切换。抽象出两种通用的通话模式，即固定关系模式和会话关系模式，提供抽象、收敛的接口，满足不同场景、灵活多变的业务需求。号池的设计，允许快速切换供应商，同时业务无感知，并且降低了单个供应商服务不可用的风险。号码的回收与复用，节省号码资源，节约成本。感谢大家，话务平台中有很多可以优化的点，都可以展开详细讨论，限于时间就不具体展开了，大家可以加我微信一起讨论。今天的分享就到这里。互动问答问题：并发呼入是如何解决的？并发数有多少？并发呼入在通信层面，是由话务供应商来把关，话务平台承担的角色是号码绑定关系维护和调度。高峰时期大概有200路同时进行的通话。问题：号池评分是针对数千万号码评分的么？号池评分是针对 每个号池剩余可用号码数量, 供应商服务质量评级, 以及人工干预的结果。问题：平台是如何解决因为 "关机、不在服务区"等因素影响导致的接通率低的问题的？关机、不在服务区这种物理上不可接通的因素无法规避，但可以用工程手段缓解，虚拟号可以绑定多个真实号，1对多的关系，如果第一个真实号接不通，在若干秒超时之后，顺呼第二个真实号，第二个接不通，超时后呼下一个真实号。问题：一周30w话务量，我可以理解并发应该不高！系统竞争是通过分布式锁，为什么不直接用数据库锁机制实现？通话并发不高，但是绑定号码并发量很高，前台在展现号码时会来取号从而产生绑定动作，绑定号码是竞争关系。分布式锁和数据库锁都能解决，不用数据库锁是为了规避给数据库带来的压力，也可以规避一些锁表问题。问题：供应商指的虚拟运营商吗？不完全是，大多是运营商的代理商。但是虚拟运营商、运营商也可以是我们的供应商。问题：现在对接一个新的代理商还有哪些工作要做？用多久接一个新的代理商？技术沟通，供应商开发，接口联调，准备号码资源，上线。一般1~2周左右。问题：号码池是有成本的，如何计算得到这个初始值，才能达到最优？号池分配是根据区域经纪人数量预估一个初始值，并且预备备用号池随时调配。号外号外去年8月，我们（InfoQ）在北京主办了第一届CNUTCon全球容器技术大会，大会邀请了来自Google、RedHat、CoreOS、阿里巴巴、腾讯、百度、大众点评、美团、360、京东等公司的技术负责人，共同探讨容器相关的应用场景、技术方案以及架构细节，当时热热闹闹，有近千人参与了这次会议。今年，我们再次启航，将于9月在北京喜来登长城饭店举办第二届CNUTCon全球容器大会。这一次，我们的议题更加丰富，内容涵盖应用场景、相关技术、行业应用。这一次，我们的讲师更加专业，容器生态开源项目的负责人都将回国分享。这一次，我们的内容把关将更加严格，主编、智囊团、用户层层过滤，最好的内容，最棒的讲师。如果你感兴趣，可以点击阅读原文链接了解详情。
觉得不错，分享给更多人看到
聊聊架构 微信二维码
分享这篇文章
5月15日 23:19
聊聊架构 最新文章
聊聊架构 热门文章女友老是喜欢发你真是够了是什么意思_百度知道百度知道 - 信息提示
知道宝贝找不到问题了&_&!!
该问题可能已经失效。
秒以后自动返回最后更新: 1年前&·&
eclipse.ini&& 的参数
-XX:PermSize=64M
-XX:MaxPermSize=128M
-XX:+UseParallelGC
studio.ini 的参数
-XX:PermSize=64M
-XX:MaxPermSize=128M
-XX:+UseParallelGC
办法都想高了。看着明明那么多空内存，就是报错内存不足。虚拟内存都给关了，还是不能解决问题
后方可回复
如果没有账号可以
一个帐号。
在话题下有
15篇原创文章
在话题下有
13篇原创文章
在话题下有
13篇原创文章骂够了吗，够了就放我走是什么意思_百度知道