1.1 爱番番沟通是什么/h2>
爱番番沟通是连接访客和商家的在线咨询工具。一方面访客可以随时随地咨询，缩短访客获取服务的途径，另一方面商家也可以快速响应并提供服务。同时在推广场景中，商家还可以根据访客的咨询内容反哺回上游广告通路，优化投放模型，提升营销转化效果。
百度商桥经历了几次不同的产品定位和多年版本迭代，产研团队也换了几波人。客户问题较多，架构长期缺乏系统性治理。给产研团队带来多个层面的掣肘：
-
团队内对产品的主要业务逻辑没有知识储备。经常需要研发去翻阅项目代码东拼西凑出现有逻辑的大致模样。
-
客户反馈问题数量居高不下，典型问题如：
-
访客进站识别不及时，客服感知不到访客已进站。访客离站识别不及时，容易误导客服向离站的访客继续发起沟通，引发沟通不畅的表象；
-
访客全生命周期内的行为数据有概率性延迟和缺失；
-
商家欢迎语、自动回复发送顺序错乱，不触发发送等；
-
服务稳定性引起的登录失败，消费发送失败、移动端消息提醒不及时等；
-
还有一部分客户问题属于新需求范畴，比如咨询组件样式灵活定制、支持离线沟通。
-
团队士气低落，生产力不高。疲于应对救火问题，难以承接较大功能需求开发。
-
现有架构陈旧，模块繁杂，长期缺乏治理。模块数量和人员规模失配，小需求可能涉及多个模块改动。存在大量陈旧代码，只能不停地进行『打补丁』方式修复问题。
二、反思：定义问题和挑战
面对当前困境，整个产研团队都意识到了需要尽快做出改变。透过现象找本质，上述现象背后的关键问题是什么呢会面临哪些挑战呢/p>
2.1 定义问题
通过进一步分析问题的根本原因，可以把问题分为以下几类：
【产品层面】产品方向及定位不明确，功能层级及分类不清晰
-
产品演进方向不清晰，业务领域主次不清，各模块的业务主路径不清晰。平时开发都是堆砌功能，导致不少业务场景存在使用体验的卡点；
-
由于历史原因系统支持的角色冗余且复杂，既有平台型角色比如支持百度顾问和商家直接沟通。又有B端其他角色比如支持销售直接查看线索；
-
从PC时代到移动时代，但是产品还保留着一些历史兼容的痕迹。比如常用语是按照PC和移动进行一级分类，站点样式类型只能设置一个端。
产品定位及差异价值
产品定位：选择『不做什么』更加重要
-
聚焦在售前接待场景，帮助商家获取联系方式，不做售后服务场景；
-
聚焦在广告营销场景，帮助广告主接待推广流量并优化效果；
-
由于是 ToB SaaS 模式，所以暂时聚焦企业客户需求，不做平台型针对企业的上层需求。
产品使用角色：谁是我们的用户/p>
- 聚焦在B端客服角色。剥离其他角色相关功能，比如跟进线索的名片功能归到线索管家模块（销售角色），反哺功能归到 oCPC 反哺模块（SEM角色）。
差异化价值：客户为什么会选择我们/p>
-
全链路闭环：从推广开始到访客进站、对话、留资，直至标记会话反馈oCPC目标，全程无缝衔接；
-
与线索管家结合：智能识别会话和留言板中的线索信息，自动沉淀至线索管家，有效节省线索梳理工作；
-
智能营销：访客意图智能分析识别，千人千话引导访客开口留资；
-
多端共用：支持 Web、App、PC 端同时使用，随时随地实现沟通。
3.2 分析：识别核心领域和模块，拆解业务逻辑
3.2.1 事件风暴：剖析流程和对齐认知的好帮手
根据产品定位及产品价值分析，结合梳理好的业务流程，需要划分子领域，相应配比合适的资源投入。
【核心域】
-
访客域和客服域属于核心域比较自然，同时作为底层的基础能力，协议连接域包括tcp、websocket、http、long polling协议，协议 文格式，连接状态维护等也应该是核心域。其次会话域也是核心域，互发消息才算进入真正沟通，会话内容里的意图表达和留资才是沟通的主要目的；
-
核心域的策略是围绕产品价值，重点投入资源。尽可能把非核心功能从核心域剥离，警惕容易引起团队失焦的投入。
【支撑域】
-
数据分析域是必要的功能但目前还不是重点，线索域对沟通来说是后链路必经环节，但应该更多利用爱番番线索管家的能力。广告域包含访客推广信息解析，会话效果反哺，照理是核心能力。但这里划为支持域是因为关键的能力在搜索团队已提供，沟通团队做好数据接入和数据供给工作；
-
支撑域的策略是尽可能以较少资源建设必要能力。当然，随着业务的发展支撑域也可能在未来变成核心域。
【通用域】
-
账 权限功能是大多数系统的通用能力。访客场景属于ToC场景，会遇到黑产流量攻击，包括访客进站和访客发送消息需要引入风控反作弊能力。爱番番沟通主要借助了爱番番策略团队和厂内安全部的能力；
-
通用域的策略是尽可能不亲自建设系统，借助外部能力快速完成能力建设。
3.3 架构：搭建整体技术架构
架构目标及设计要点
-
根据流量南北向把各种服务按照职责类别分为多个层次，用户界面、接入 关、业务前后台、沟通协议连接等5层由沟通团队建设维护，底下基础服务和存储层主要借助基础技术能力。分层建设能够定义服务不同等级、高效使用团队研发资源、承接不同流量类型（实际用户流量、后台用户流量、异步调用流量、定时任务流量等）、简化请求涉及的数据链路、根据层次不同建设非功能性需求（技术栈选择、熔断限流、弹性伸缩等）。
-
技术架构匹配业务架构。服务模块边界符合业务边界。核心服务内需设计领域模型，围绕领域层和应用层构建业务逻辑，搭建DDD四层分层架构，做到领域模型和技术细节分离，不稳定实现依赖稳定实现。
-
符合典型微服务架构。服务职责内聚，服务和数据一体。数据归服务私有，服务间不共享业务逻辑，服务间通过API或领域事件进行协作。
-
数据架构合理。尽可能采用数据最终一致性策略。每种数据非必要不多处存储，多处存储须有最终一致性方案保证。涉及nosql类存储如Redis、HBase、ES(Elastic Search)时，防止大key造成分片不均，业务数据按需进行分库分表存储。
-
通知模块采用分布式锁控制并发，并为 文增加SeqId来确认早晚顺序，为客户端提供判断依据。
-
优化状态协议，简化掉动作通知类 文，采用以访客状态为主的 文，如下图所示，将动作 文简化掉，只保留状态 文， 文数量减少约 60%，降低客户端处理复杂度，减小出错概率。
爱番番客户端主要是IM业务，所以通信方面使用 websocket 来进行消息通知，由于客服发送消息包含样式设置，所以传输内容包含富文本，这样就很容易引起一些xss 问题。我们使用 xss 白名单的方式来过滤 xss 攻击，并且所有内容都会通过策略过滤，拦截黄反等不良文本。
爱番番沟通考虑到今后能更灵活地接入更多业务垂类并且支持第三方自主开发个性化功能。同时需要兼顾平台代码的稳定性和易用性，我们采用了插件化架构的方式来实现客户端。
2、Window7 系统下白屏问题
因为在测试过程中 QA 同学使用的一直都是 Win10 的系统，所以白屏问题一直没有被发现。直到客户端正式上线，白屏问题被集中反馈，至此我们开始重视白屏问题并积极解决。
由于我们使用的 electron 版本是 9.x 的版本，该版本下默认开启 GPU 加速，但是 Win7 下启用 GPU 加速需要管理员权限，如果没有管理员权限去执行的话进程就会卡住，导致首页白屏。所以解决此问题方法就可以从两方面解决，第一是开启管理员权限，第二是关闭 GPU 加速。考虑到客户端使用的人群大部分是客服，公司电脑配置较低且一般没有管理员账 权限，所以我们选择通过关闭 GPU 加速（ app.disableHardwareAcceleration() ）来解决次问题。
3、其他问题
在 Electron 开发过程中还要注意一些常见问题。如读写文件的编码问题，客户端安全问题存在 rce，可被任意执行命令，内存使用率过高问题等。
3.5.2 微内核/插件化架构
什么是插件化架构
插件化架构就是软件本身只提供插件运行时的核心（ pluginCore ），并为插件运行时提供访问的接口（ pluginAPI ），通过插件平台下载插件（ plugin ）后可以在软件上完美运行。
最基本的例子就是 webpack，作为主流的构建工具，webpack 只抽象了一个软件运行时的环境，在不关心和改动这个系统已有的代码前提下，却能独立开发新的插件来充实整个系统的能力。
pluginCore: 插件运行时核心；pluginAPI：为插件运行提供访问接口；plugin：实现具体功能的插件。
插件化架构优势
插件化架构是开闭原则在跨系统级别的最佳实践。在插件核心和接口不变情况下，系统可以持续接入新插件，来丰富系统的功能。在一个非插件化的系统中，随着功能模块的增多，代码量激增，在引入新功能和修复BUG都会越来越困难和低效。但插件化架构不管已有系统功能多复杂，开发新的功能的复杂度始终一样。而且随着系统的平台化，第三方接入差异化功能也不会影响系统的稳定性。
爱番番插件化现状
为了满足其他第三方平台的定制化需求，如电商平台的商品及订单模块，CRM平台的客户模块，售后场景中的评价模块，爱番番客户端的插件化架构的设计要点：
-
插件化架构方案
新客户端设计原则：
-
按照 DDD 原则，来定义菜单模块并抽象功能层级；
-
结构对比老版层级更加清晰，功能扩展性更强；
-
容器变更并重新定义，释放核心会话功能的区域；
-
三端（ Mac + Win + Web ）合一，共用一套产品设计，操作灵活便捷。
4.3 产研效能大幅提升
技术为产品服务，产研共同创造业务价值。产研效能是技术重构的首要目标。可以通过两方面衡量效果。
需求的整体交付速度
- 就像敏捷迭代的精髓不是看交付过程的单点效率，而是看发现需求到需求上线的整体效率。这也是通过 DDD 带给这次技术重构的最大价值。经过需求和业务的分析、设计、实现等环节，让产品、设计、研发整个团队的磨合和对业务的理解提升到新的高度，辅助以合理的技术架构，能整体提升需求交付效率。
技术研发效率
-
直接体现是更少的人支撑更大的产品范围。以前技术研发 12 人，现在 7人；
-
间接体现是代码维护成本大大降低，服务模块数量和团队人数比例协调，模块职责和协作关系明确，接口设计质量高，代码规范度高，新人上手速度快。
4.4 产研效能大幅提升
4.4.1 系统稳定性
直接体现是前面交代的高频技术稳定性问题如访客进站识别不及时、自动回复不触发等已得到全面的治理，各系统模块稳定性指标长期维持在 99.99%。
4.4.2 可维护性
代码维护成本大大降低，架构在不同层面更具维护性：
-
服务模块数量和团队人数比例协调；
-
模块职责和协作关系明确；
-
业务数据流流转链路清晰；
-
项目代码结构规范、易懂。新人上手速度快；
-
接口文档在线化。
4.4.3 可演进性
爱番番沟通系统的潜在可演进方向很多，有些方面已做好设计预留，比如：
-
更多沟通格式：已和业务系统解耦，很容易增加沟通内容格式如视频、语音等；
-
更多连接形式：目前已支持包括 http、tcp、websocket、long polling 等推拉形式协议，几乎满足了绝大部分场景；
-
；更多业务类型接入：基础沟通能力已有开放能力，可利用 api 方式低成本接入
-
沟通功能的持续演进：比如更智能化、和线索管家更无缝集成、更强的风控能力，这些需求可按需建设相应业务模块，独立演进。
五、成长：经验总结
通过这次重构团队经历了从困境到反思的痛苦过程，相应地也获得了组织、技术、人等层面的成长。
组织
-
产研团队聚焦到创造业务价值，从能解决客户问题视角开展日常工作；
-
产研协作效率更顺畅，基于统一语言沟通需求和设计；
-
在业务迭代过程中沉淀了领域知识。
技术
-
技术问题的答案往往要从业务中寻找答案，理解业务是开展技术的前提。不同业务带来不同的技术诉求，适配的技术才是最好的，也是先进的；
-
经过重构的架构能适配当前业务发展，研发能把绝大部分精力放在业务实现上，屏蔽了日常开发的很多噪音。
人
-
通过本次重构提高了每个成员对沟通业务的全方位熟悉。既有自身业务的全貌，也有行业友商的演进现状，对未来演进方向有了对齐；
-
在了解技术架构的来龙去脉和全貌基础上，让每个业务研发能聚焦建设自己负责的模块。通过 DDD 实践提升自己的应用架构水平，提供了技术进阶的新方向，发挥出模块负责人的主观能动性。
六、星辰：未来展望
目前的爱番番沟通由于进行了重新定位，方向更加聚焦，但同时也面临着很多方向性的选择。如：面对不同的上游场景以及不同的推广平台，后续的接入能力是否需要更加强大。智能机器人有些场景下的策略模型没有保持持续迭代更新，是否需要往智能化方面更进一步。
技术架构的规划首先应该围绕业务诉求展开，除此之外会继续向云原生演进，增加容量评估、全链路压测、流量治理等能力。比如近期计划把底层基座从 K8s 式微服务治理升级成服务 格，对齐爱番番主集群能力，便于以后能更好地复用基础技术平台的能力。同时进一步降低多开发语言下的统一服务治理成本（ 接入层和协议连接层的服务是 golang，业务服务是 java ）。
在未来，如何做到「既要好，又要不同」爱番番沟通产研团队依然还有很长的路要走。
本篇系爱番番沟通产研团队多位同学共同编写。
-
飞邪：架构师，擅长通过微服务架构和 DDD 落地复杂系统；
-
坚果：产品经理，擅长 ToB SaaS 及广告产品；
-
甯甯：一个和商桥、在线沟通有不解之缘的产品经理；
-
小麦：资深前端工程师，在光速演进的前端领域内苦苦挣扎的 FE；
-
flyme: 资深研发工程师，擅长通过改进技术方案来应对复杂多变的业务场景。
八、往期精选
接口文档自动更改度程序员开发效率MAX的秘诀
技术揭秘！百度搜索中台低代码的探索与实践
百度智能云实战——静态文件CDN加速
化繁为简–百度智能小程序主数据架构实战总结
百度搜索中台海量数据管理的云原生和智能化实践
百度搜索中“鱼龙混杂”的加盟信息，如何靠AI 解决/p>
———- END ———-
百度 Geek 说
技术干货 · 行业资讯 · 线上沙龙 · 行业大会
招聘信息 · 内推信息 · 技术书籍 · 百度周边
欢迎各位同学关注
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！
-
-