全文 9000 字，预计浏览工夫 21 分钟

一、窘境：我的项目背景

爱番番沟通基于百度商桥疾速实现了产品性能和技术架构的从无到有，但同时也继承了百度商桥历史性能繁冗、技术架构古老的毛病。为了能更好地服务于爱番番沟通未来的产品演进，进步产研能效，须要从理论问题登程，聚焦主要矛盾，对产品架构和业务架构进行重构。

为了更好的了解本文内容，以下是必要的名词解释：

1.1 爱番番沟通是什么？

爱番番沟通是连贯访客和商家的在线征询工具。一方面访客能够随时随地征询，缩短访客获取服务的路径，另一方面商家也能够疾速响应并提供服务。同时在推广场景中，商家还能够依据访客的征询内容反哺回上游广告通路，优化投放模型，晋升营销转化成果。

1.2 为什么要重构？

百度商桥经验了几次不同的产品定位和多年版本迭代，产研团队也换了几波人。客户问题较多，架构长期不足系统性治理。给产研团队带来多个层面的掣肘：

1. 团队内对产品的次要业务逻辑没有常识储备。常常须要研发去翻阅我的项目代码七拼八凑呈现有逻辑的大抵模样。
2. 客户反馈问题数量居高不下，典型问题如：

• 访客进站辨认不及时，客服感知不到访客已进站。访客离站辨认不及时，容易误导客服向离站的访客持续发动沟通，引发沟通不畅的表象；
• 访客的广告相干信息（起源、搜索词、关键词）获取不及时、不残缺；
• 访客全生命周期内的行为数据有概率性提早和缺失；
• 商家欢送语、主动回复发送程序错乱，不触发发送等；
• 服务稳定性引起的登录失败，生产发送失败、挪动端音讯揭示不及时等；
• 还有一部分客户问题属于新需要领域，比方征询组件款式灵便定制、反对离线沟通。

4. 团队士气高涨，生产力不高。疲于应答救火问题，难以承接较大性能需要开发。
5. 现有架构古老，模块繁冗，长期不足治理。模块数量和人员规模失配，小需要可能波及多个模块改变。存在大量古老代码，只能不停地进行『打补丁』形式修复问题。

二、反思：定义问题和挑战

面对以后窘境，整个产研团队都意识到了须要尽快做出扭转。透过景象找实质，上述景象背地的关键问题是什么呢？又会面临哪些挑战呢？

2.1 定义问题

通过进一步剖析问题的根本原因，能够把问题分为以下几类：

【产品层面】产品方向及定位不明确，性能层级及分类不清晰

• 产品演进方向不清晰，业务畛域主次不清，各模块的业务主门路不清晰。平时开发都是堆砌性能，导致不少业务场景存在应用体验的卡点；
• 因为历史起因零碎反对的角色冗余且简单，既有平台型角色比方反对百度参谋和商家间接沟通。又有 B 端其余角色比方反对销售间接查看线索；
• 从 PC 时代到挪动时代，然而产品还保留着一些历史兼容的痕迹。比方常用语是依照 PC 和挪动进行一级分类，站点款式类型只能设置一个端。

旧版客户端界面示例

【架构层面】客户端架构多年未演进，性能迭代难以为继

• 客户端仅反对 Windows 零碎且架构始终未演进，技术栈基于 C ++，和团队次要技术栈偏离，只能艰巨保护，有力承接新性能需要。迫切需要演进为能跨平台、支流的、前端技术栈；
• 访客侧前端还未做到前后端拆散架构，体验和开发效率大打折扣。

【架构层面】服务端架构的根底沟通层待演进

沟通协定层作为沟通产品十分重要的一环，还存在架构方面的有余：

• 多种网络连接协定下的稳定性需进步；
• 和不同端的音讯发送性能需进步。

【架构层面】服务端架构的业务层待演进

业务层蕴含 20+ 服务模块，次要的业务逻辑采纳共享库的形式保护，导致模块边界不清，数据链路凌乱，性能重叠耦合重大，迫切需要演进为支流微服务架构。

• 模块内职责不够内聚，模块间调用关系耦合高；
• 同样的数据存在多份存储，数据一致性存在问题；
• 数据流的同步异步传输链路凌乱。

【架构层面】整体服务端架构自运维老本高，可维护性很低

历史遗留零碎中须要运维多种自运维中间件，导致团队不能聚焦业务性能开发。既升高了研发生产力，也给零碎稳定性带来微小挑战。

• 自运维了反向代理 Nginx 集群、Zookeeper 集群、Storm 集群、Kafka 集群、Solr 集群、Prometheus 集群；
• 离部门的主服务端集群面向云原生的服务治理架构还有不小差距。

【组织层面】产研团队整体对业务的了解不够且未拉齐

• 业务架构和研发架构长期脱钩，导致团队对大到沟通行业小到具体某个模块的畛域常识积淀不足，迫切需要在产研层面拉齐现有认知；
• 在团队达成共识的根底上未来能力造成随产品疾速演进从而疾速迭代畛域认知的正向循环。

2.2 认清挑战

归因分明问题后，重构的方向逐步清晰起来。但执行落地阶段也会面临着业务演进压力，原架构基础薄弱，资源短缺等挑战。

架构古老，代码里有不少荫蔽的『坑』

从以往经验看，有时候一个很小的改变，看起来很有把握的一次上线也可能造成客户问题。一方面代码中不足设计的中央多，另一方面整体回归测试笼罩不全。组内自嘲这种状态为『每一行代码都刚刚好』，不能多也不能少。

重构和业务演进既要又要

这个挑战是大部分团队都会遇到的，业务不可能进行演进期待技术重构。如何能在不影响已有业务且保障局部高优业务需要失常迭代的状况下进行重构是必须要答复的问题。

不能仅仅是重构，客户可感知的体验要更好

波及客户端架构降级，必然会带来一些新的用户体验，须要治理好存量用户的预期。本次重构范畴大，产品质量不降落既是要求也是挑战。

产研团队较新，对原有业务性能不足足够理解

业务研发团队很依赖领域专家的业务知识领导，子畛域间和模块间的职责和边界划分，数据归属等了解须要建设在业务了解的根底上。这些对现有团队是个不小的挑战。

因而，抓主要矛盾，分阶段小步快跑是本次重构的基调。

三、纾困：解决问题

仅仅从技术层面做重构只能解决眼前的技术问题，随着业务疾速迭代，纯技术重构的成绩很容易隐没殆尽。思考到须要对业务和技术层面并行不悖做出扭转，在现有简单业务根底上仍能放弃高效的产研交付效率，加上隔壁兄弟团队之前在线索管家产品曾经播种了 DDD 革新的收益，因而本次技术重构决定联合 DDD 来做，从产品到技术来一次认知降级、架构降级。

3.1 定位：确定产品方向及外围痛点

产品定位及差别价值

产品定位 ：抉择『不做什么』更加重要

• 聚焦在售前接待场景，帮忙商家获取联系方式，不做售后服务场景；
• 聚焦在广告营销场景，帮忙广告主接待推广流量并优化成果；
• 因为是 ToB SaaS 模式，所以临时聚焦企业客户需要，不做平台型针对企业的下层需要。

产品应用角色 ：谁是咱们的用户？

• 聚焦在 B 端客服角色。剥离其余角色相干性能，比方跟进线索的名片性能归到线索管家模块（销售角色），反哺性能归到 oCPC 反哺模块（SEM 角色）。

差异化价值 ：客户为什么会抉择咱们？

• 全链路闭环：从推广开始到访客进站、对话、留资，直至标记会话反馈 oCPC 指标，全程无缝连接；
• 与线索管家联合：智能辨认会话和留言板中的线索信息，主动积淀至线索管家，无效节俭线索梳理工作；
• 智能营销：访客用意智能剖析辨认，千人千话疏导访客闭口留资；
• 多端共用：反对 Web、App、PC 端同时应用，随时随地实现沟通。

3.2 剖析：辨认外围畛域和模块，拆解业务逻辑

3.2.1 事件风暴：分析流程和对齐认知的好帮手

针对次要业务流程，产研团队通过事件风暴的形式梳理了事件流，定义了每个事件相干的角色、动作、规定条件和事件后果。最重要的是对齐了团队的业务认知，靠个体智慧分析了整体业务细节。

3.2.2 边界是单干的根底：划分畛域和模块，造成对立语言

依据产品定位及产品价值剖析，联合梳理好的业务流程，须要划分子畛域，相应配比适合的资源投入。

【外围域】

• 访客域和客服域属于外围域比拟天然，同时作为底层的根底能力，协定连贯域包含 tcp、websocket、http、long polling 协定，协定报文格式，连贯状态保护等也应该是外围域。其次会话域也是外围域，互发音讯才算进入真正沟通，会话内容里的用意表白和留资才是沟通的次要目标；
• 外围域的策略是围绕产品价值，重点投入资源。尽可能把非核心性能从外围域剥离，警觉容易引起团队失焦的投入。

【撑持域】

• 数据分析域是必要的性能但目前还不是重点，线索域对沟通来说是后链路必经环节，但应该更多利用爱番番线索管家的能力。广告域蕴含访客推广信息解析，会话成果反哺，照理是外围能力。但这里划为反对域是因为要害的能力在搜寻团队已提供，沟通团队做好数据接入和数据供应工作；
• 撑持域的策略是尽可能以较少资源建设必要能力。当然，随着业务的倒退撑持域也可能在将来变成外围域。

【通用域】

• 账号权限性能是大多数零碎的通用能力。访客场景属于 ToC 场景，会遇到黑产流量攻打，包含访客进站和访客发送音讯须要引入风控反作弊能力。爱番番沟通次要借助了爱番番策略团队和厂内安全部的能力；
• 通用域的策略是尽可能不亲自建设零碎，借助内部能力疾速实现能力建设。

3.3 架构：搭建整体技术架构

架构指标及设计要点

1. 依据流量南北向把各种服务依照职责类别分为多个档次，用户界面、接入网关、业务前后台、沟通协定连贯等 5 层由沟通团队建设保护，底下根底服务和存储层次要借助根底技术能力。分层建设可能定义服务不同等级、高效应用团队研发资源、承接不同流量类型（理论用户流量、后盾用户流量、异步调用流量、定时工作流量等）、简化申请波及的数据链路、依据档次不同建设非功能性需要（技术栈抉择、熔断限流、弹性伸缩等）。
2. 技术架构匹配业务架构。服务模块边界合乎业务边界。外围服务内需设计畛域模型，围绕畛域层和应用层构建业务逻辑，搭建 DDD 四层分层架构，做到畛域模型和技术细节拆散，不稳固实现依赖稳固实现。
3. 合乎典型微服务架构。服务职责内聚，服务和数据一体。数据归服务公有，服务间不共享业务逻辑，服务间通过 API 或畛域事件进行合作。
4. 数据架构正当。尽可能采纳数据最终一致性策略。每种数据非必要不多处存储，多处存储须有最终一致性计划保障。波及 nosql 类存储如 Redis、HBase、ES(Elastic Search) 时，避免大 key 造成分片不均，业务数据按需进行分库分表存储。

3.4 冲破：架构设计的关键技术

3.4.1 落地真正的微服务架构

随着子畛域和模块的划分确定后，须要调整对应的模块职责及模块间协作关系进行革新，重点革新点包含：

合并老模块

革新前服务端有 45+ 服务模块，服务职责划分不当，服务粒度不适合。具体表现为：

1. 有些性能粒度太细，徒增保护老本，能够合并。
2. 某些相似性能散落在多个服务，比方 5 个模块都有提供访客相干信息查问，能够合并。
3. 有些服务随着老客户端的降级，性能革新后更适合合并到其余服务，原服务能够下线。
4. 反向代理层职责划分不合理导致服务集群太多，绝大部分能够迁徙至公司级的 BFE 进群，多数蕴含很多 lua 逻辑 Nginx 集群临时保留，但能够合并。

通过合并下线革新后，服务数量缩小了 15+。

拆分新模块

有些性能很重要，须要造成独立的模块重点建设。比方：

1. 访客广告信息解析服务。广告信息对于客服刻画访客画像，了解访客十分重要。但之前的解析逻辑散落在多个模块且实现不对立，解析准确率不高，没有足够的弥补策略保障必要的解析成功率。
2. 机器人智能回复服务。这也是产品定位的一个差异化价值。为了让客服更高效接待访客，疏导访客多留资，这块的产品演进越来越多，复杂度也随着加大。
3. 线索服务。这里的线索服务是爱番番沟通和线索管家产品的边界，次要是针对会话内容或者留言内容提取联系方式，而后通过接口或事件的形式流转到线索管家，同时也要造成征询到线索的闭环数据。

模块间不共享业务逻辑

革新前的后端业务服务不是真正的微服务，尽管都是独立部署，各自裸露接口，但服务实现层耦合重大：

1. 通过公共库（即 java 的 jar 包）共享业务逻辑。同一段业务代码被多个业务服务依赖，既升高了代码可维护性，也升高了服务的可测试性。
2. 通过缓存（Redis）传递数据。一个 redis key 常常既有多个服务在写入，也有多个服务在读取。
3. 通过 DB 共享数据，间接读取属于其余服务职责的数据表。

革新准则：不共享包含业务逻辑的公共库，让微服务垂直划分，相干业务数据（包含缓存数据）归服务公有，通过 API 接口提供能力，或者通过畛域事件推动上游流程。

最终一致性前提下的高可用性

可用性的要害伎俩是数据复制。能够借助不同的数据同步办法，联合不同特点的存储类型实现多样化业务场景的高可用性。罕用的数据复制 / 同步伎俩有：

1. 公布 / 订阅模式：上游服务利用音讯队列把相干数据以音讯为载体发，上游服务订阅该音讯并做相应的长久化。整个沟通服务端在大量应用这种办法，也是服务解耦的一大利器。
2. CDC 模式（Change Data Capture）：简略说就是通过监听 MySQL 的 binlog 感知到上游服务的数据变动（包含新增、更新、删除），解析日志并做一些解决（比方关联表查问等）后发送到音讯队列，上游按需订阅解决。

CDC 模式和公布订阅模式配合应用能满足很多场景，拆散读写服务和选取异构存储介质。比方访客进站记录写入 MySQL 和访客历史记录查问 ES，会话写入 Table 和会话剖析服务查问 Doris。即能无效满足各自场景的数据存取需要也能进步场景的可用性。

当然，这种可用性往往会就义肯定时效性内的数据一致性，须要依据理论业务场景做出衡量。依据教训判断在马上失去答案和失去正确答案之间，大多数人更想要的其实是马上失去答案。

3.4.2 数据链路治理

革新前次要场景包含进站、离站、主动回复、会话内容校验、线索辨认、完结会话等的数据流的必经节点是实时计算服务，其外围实现是 storm，但因为多种起因该集群很不稳固，会引发出上述提到的大量客户问题。深层剖析现状次要有以下弊病：

• storm 拓扑设计不合理，拓扑节点职责不清；
• 拓扑节点中存在大量的业务逻辑，广泛利用 redis 传递数据，redis 键设计凌乱，可维护性很差；
• storm 集群是几年前引入的，版本低，始终没降级。

通过剖析业务需要，只降级 storm 集群版本不会解决理论问题，另外实时计算框架在现阶段不是必须项，因而得出了以下革新思路：

• 去除这个集中式的计算集群，按业务场景梳理各自数据流，防止相互烦扰。让对应业务服务模块承接业务逻辑，如需进步业务响应可通过缓存集群减速；
• 服务模块间尽可能通过异步形式（kafka 音讯队列）传递数据，目前音讯队列也能达到近实时成果，同时加强音讯队列的灾备性能和订阅状况监控；
• 访客一段时间不谈话须要主动回复等延时场景通过延时工作的计划解决；
• redis key 从新梳理，优化大 key（一个 key 承载的内容特地大，比方一个 key 就蕴含全零碎访客的局部信息，这样的 key 设计显然太大），尽量不跨服务模块间接操作 redis。

业务程序的灵魂是数据，技术架构时要多花工夫思考数据存储和读取的方方面面。比方用什么存储系统（存储系统不可能读也最快，写也最快，须要衡量）、什么时候用缓存，整个业务流程的数据传输链路应该怎么样，沟通零碎波及到很多写放大还是读放大的衡量等等。本次重构也波及到了这些方面的梳理和革新，在此不一一介绍。

3.4.3 沟通协定优化

为什么要做协定优化？

针对 1.2 章节中提到的客户端上经常出现丢访客，音讯不上屏等问题，简略的打补丁形式曾经难以将问题彻底解决，因而必须从协定层进行彻底的革新优化。具体痛点如下：

1. 现有协定不足鲁棒性，从协定层面埋藏着隐患。一个事件（如进站、建设沟通、离站）须要多个包来实现交互，如果一个访客操作频繁，访客状态也会频繁做变更，很容易出错。
2. 富客户端模式，端上保护了过多的状态信息，适度依赖推送包的程序，而且不足容错、自复原复原机制，容易呈现访客不展现，音讯不上屏等问题。

如何优化？

1. 告诉模块采纳分布式锁管制并发，并为报文减少 SeqId 来确认早晚程序，为客户端提供判断根据。

2. 优化状态协定，简化掉动作告诉类报文，采纳以访客状态为主的报文，如下图所示，将动作报文简化掉，只保留状态报文，报文数量缩小约 60%，升高客户端解决复杂度，减小出错概率。

3. 客户端侧，由 socket 长连贯改为为 http + socket 推拉联合的形式，当断网重连、或者报文失落、错乱时，则客户端被动拉取最新状态，彻底接解决访客状态不对，音讯不上屏等问题。

猜你想问：

1、下面提到分布式锁管制并发，会因锁竞争而减少申请解决工夫吗？

答：锁粒度为单个访客粒度，粒度足够小，而且同一个访客在疾速操作（如频繁疾速关上页面、发动沟通）时，才会呈现锁竞争的状况，对单访客来说，惯例的操作并发不大。

2、既然协定优化收益这么搞，为什么不早点做协定优化呢？

答：之前受限于业务边界划分不清晰，访客状态变更散落在业务前台、业务后盾、原 storm 集群多个中央，无奈做对立管控。只有在实现了后期建构优化、数据链路治理实现之后，站在原有的工作成绩至上，能力做协定优化。

3、客户端的推拉联合为什么不早点做呢？

答：如前文 2.1 中第 2 条所说，客户端技术栈基于 C++，只能艰巨保护，有力承接新性能需要。因而想改变客户端的协定，堪称异样艰巨，这也是下文 3.5 章节客户端架构降级的一大起因。

小结

1. 访客、客服、会话治理模块的 DDD 革新。
2. 由贫血模型改为富血模型，通过状态机管制状态变更。
3. 客户端申请以 http 为主，同步失去返回值，升高出错概率。socket 次要用于给端上的告诉。
4. 协定包简化, 以访客状态维度进行交互，极大缩小包的数量。

3.4.4 去除自运维中间件

如后面所述因为历史技术栈起因爱番番沟通团队外部运维了好几种中间件，先不说引入这些中间件的正确与否，现状是没有足够常识储备，既给零碎带来了很多不稳固因素，也升高了团队的研发效率。因而本次重构在这个方面的革新准则是优先思考下线架构中不必要的中间件，必要的中间件也不另行保护，迁徙到部门根底技术团队运维。

集群革新下线

• Zookeeper 集群：革新前次要用来做业务配置核心，迁徙到 k8s 更敌对的 ConfigMap（由根底技术团队运维）；
• Nginx 集群：革新前有好几套反向代理集群，其中既有路由转发逻辑，也有业务逻辑。业务逻辑下沉至对应的 gateway 服务，由团队保护。路由转发逻辑迁徙至 bfe 集群，由根底技术团队对立运维；
• Storm 集群：逻辑革新，下线。细节下面已交代；
• Solr 集群：下线，相应查问逻辑革新迁徙至 ES 集群。

集群迁徙

此局部集群尽管不能下线，但团队内不另行保护，转而迁徙至部门集群。包含 Kafka 和 Prometheus 集群。

3.5 扩大：客户端架构实际

3.5.1 客户端跨平台架构

随着原客户端保护代价越来越大，联合客户对 mac 端的诉求，因而抉择了跨平台的 Electron 框架。

为什么抉择 Electron？

1. 开源的外围扩大比拟容易。
2. 界面定制性强，原则上只有是 Web 能做的它都能做。
3. 是目前最便宜的跨平台技术计划，HTML + JS 的技术储备，而且有海量的现存 UI 库。
4. 绝对其余跨平台计划（如 QT GTK+ 等），更稳固，bug 少，只有浏览器跑起来了，问题不会太多。
5. 不便拓展，能够间接嵌入现有 web 页面。

Electron 零碎架构

爱番番前端团队的技术栈是 Vue，所以咱们抉择应用 Electron-Vue 来搭建我的项目。Electron 有两个过程，别离为主过程（main）和渲染过程（renderer）。主过程中蕴含了客户端自动更新、插件外围、零碎 API 等。渲染过程是 vue + webpack 的架构，两个过程间通过 ipc 进行通信。

爱番番客户端次要是 IM 业务，所以通信方面应用 websocket 来进行音讯告诉，因为客服发送音讯蕴含款式设置，所以传输内容蕴含富文本，这样就很容易引起一些 xss 问题。咱们应用 xss 白名单的形式来过滤 xss 攻打，并且所有内容都会通过策略过滤，拦挡黄反等不良文本。

爱番番沟通思考到今后能更灵便地接入更多业务垂类并且反对第三方自主开发个性化性能。同时须要兼顾平台代码的稳定性和易用性，咱们采纳了插件化架构的形式来实现客户端。

开发中遇到的问题

Electron 带来很大便当的同时，其自身也有很多硬伤。如常被人吐槽的内存占用高、和原生客户端性能差别、API 零碎兼容性问题等。这些问题在开发过程中须要提前思考到。上面是开发过程中必然会遇到的几个问题。

1、性能优化

性能优化是在开发完需要性能后常常须要思考的。在 Electron 中，最好的剖析工具就是 Chrome 开发者工具的 Performance，通过火焰图，JS 执行过程的任何问题都能够直观的看到。

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 平台的客户模块，售后场景中的评估模块，爱番番客户端的插件化架构的设计要点：

1. 插件化架构计划

  

![图片](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/bf0db5d78f584e03ae2aae18de0a91dd~tplv-k3u1fbpfcp-zoom-1.image)

  

2. 提供两种接入形式：JS-SDK 接入、Webview 形式嵌入。
3. 第三方插件与爱番番客户端存在两种通信机制：事件播送、实例注入。
4. 番番客户端插件分类：左侧菜单插件、会话工具栏插件、会话侧边栏插件。
5. 插件配置文件阐明：

{
        "version":"0.0.1",   // 版本号
        "id":"demo-name",  // 绑定事件 ID
        "name":"组件名称",  // 插件名称
        "viewUrl":"",  // 如果是菜单插件须要提供 webview 地址"target":"toolbar",  // menuList——菜单插件、toolbarList——沟通区插件、infoList——右侧工具栏插件"dependent": {"method": [],"version":"1.0.6"  // 依赖客户端版本
        }
}

四、欢喜：解决成果

4.1 产品架构降级

新客户端设计准则 ：

• 依照 DDD 准则，来定义菜单模块并形象性能层级；
• 构造比照老版层级更加清晰，性能扩展性更强；
• 容器变更并从新定义，开释外围会话性能的区域；
• 三端（Mac + Win + Web）合一，共用一套产品设计，操作灵便便捷。

4.2 客户体验晋升

迁徙后，咱们对新客户端的应用客户进行了回访，除了需要的反馈，也收到了一些必定：

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 解决？

———- END ———-

百度 Geek 说

百度官网技术公众号上线啦！

技术干货 · 行业资讯 · 线上沙龙 · 行业大会

招聘信息 · 内推信息 · 技术书籍 · 百度周边

欢送各位同学关注