全文约9000字，预计阅读时间19分钟

1. 困境：项目背景

爱番番沟通基于百度商桥快速完成了产品功能和技术架构的从无到有，但同时也继承了百度商桥历史功能繁杂、技术架构陈旧的缺点。为了能更好地服务于爱番番沟通将来的产品演进，提高产研能效，需要从实际问题出发，聚焦主要矛盾，对产品架构和业务架构进行重构。

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

名词

解释

访客

浏览客户网站的网民

C端

浏览客户网站网民看到的咨询图标、邀请框、沟通窗口、留言板

B端

客服接待网民咨询的工作台，即客服业务系统的客户端、手机端、网页端

进站

网民打开客户的网站进行浏览

离站

网民关闭了客户的网站

DDD

Domain Driven Design，领域驱动设计，一种旨在解决复杂系统的设计方法论

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

1.2 为什么要重构？

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

团队内对产品的主要业务逻辑没有知识储备。经常需要研发去翻阅项目代码东拼西凑出现有逻辑的大致模样。

客户反馈问题数量居高不下，典型问题如：

访客进站识别不及时，客服感知不到访客已进站。访客离站识别不及时，容易误导客服向离站的访客继续发起沟通，引发沟通不畅的表象；

访客的广告相关信息（来源、搜索词、关键词）获取不及时、不完整；

访客全生命周期内的行为数据有概率性延迟和缺失；

商家欢迎语、自动回复发送顺序错乱，不触发发送等；

服务稳定性引起的登录失败，消费发送失败、移动端消息提醒不及时等；

还有一部分客户问题属于新需求范畴，比如咨询组件样式灵活定制、支持离线沟通。

展开全文

访客进站识别不及时，客服感知不到访客已进站。访客离站识别不及时，容易误导客服向离站的访客继续发起沟通，引发沟通不畅的表象；

访客的广告相关信息（来源、搜索词、关键词）获取不及时、不完整；

访客全生命周期内的行为数据有概率性延迟和缺失；

商家欢迎语、自动回复发送顺序错乱，不触发发送等；

服务稳定性引起的登录失败，消费发送失败、移动端消息提醒不及时等；

还有一部分客户问题属于新需求范畴，比如咨询组件样式灵活定制、支持离线沟通。

团队士气低落，生产力不高。疲于应对救火问题，难以承接较大功能需求开发。

现有架构陈旧，模块繁杂，长期缺乏治理。模块数量和人员规模失配，小需求可能涉及多个模块改动。存在大量陈旧代码，只能不停地进行『打补丁』方式修复问题。

2. 反思：定义问题和挑战

面对当前困境，整个产研团队都意识到了需要尽快做出改变。透过现象找本质，上述现象背后的关键问题是什么呢？又会面临哪些挑战呢？

2.1 定义问题

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

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

产品演进方向不清晰，业务领域主次不清，各模块的业务主路径不清晰。平时开发都是堆砌功能，导致不少业务场景存在使用体验的卡点；

由于历史原因系统支持的角色冗余且复杂，既有平台型角色比如支持百度顾问和商家直接沟通。又有B端其他角色比如支持销售直接查看线索；

从PC时代到移动时代，但是产品还保留着一些历史兼容的痕迹。比如常用语是按照PC和移动进行一级分类，站点样式类型只能设置一个端。

产品演进方向不清晰，业务领域主次不清，各模块的业务主路径不清晰。平时开发都是堆砌功能，导致不少业务场景存在使用体验的卡点；

由于历史原因系统支持的角色冗余且复杂，既有平台型角色比如支持百度顾问和商家直接沟通。又有B端其他角色比如支持销售直接查看线索；

从PC时代到移动时代，但是产品还保留着一些历史兼容的痕迹。比如常用语是按照PC和移动进行一级分类，站点样式类型只能设置一个端。

旧版客户端界面示例

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

客户端仅支持Windows系统且架构一直未演进，技术栈基于C++，和团队主要技术栈偏离，只能艰难维护，无力承接新功能需求。迫切需要演进为能跨平台、主流的、前端技术栈；

访客侧前端还未做到前后端分离架构，体验和开发效率大打折扣。

客户端仅支持Windows系统且架构一直未演进，技术栈基于C++，和团队主要技术栈偏离，只能艰难维护，无力承接新功能需求。迫切需要演进为能跨平台、主流的、前端技术栈；

访客侧前端还未做到前后端分离架构，体验和开发效率大打折扣。

【架构层面】服务端架构的基础沟通层待演进

沟通协议层作为沟通产品非常重要的一环，还存在架构方面的不足：

多种网络连接协议下的稳定性需提高；

和不同端的消息发送性能需提高。

多种网络连接协议下的稳定性需提高；

和不同端的消息发送性能需提高。

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

业务层包含 20+ 服务模块，主要的业务逻辑采用共享库的方式维护，导致模块边界不清，数据链路混乱，功能重叠耦合严重，迫切需要演进为主流微服务架构。

模块内职责不够内聚，模块间调用关系耦合高；

同样的数据存在多份存储，数据一致性存在问题；

数据流的同步异步传输链路混乱。

模块内职责不够内聚，模块间调用关系耦合高；

同样的数据存在多份存储，数据一致性存在问题；

数据流的同步异步传输链路混乱。

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

历史遗留系统中需要运维多种自运维中间件，导致团队不能聚焦业务功能开发。既降低了研发生产力，也给系统稳定性带来巨大挑战。

自运维了反向代理 Nginx 集群、Zookeeper 集群、Storm 集群、Kafka 集群、Solr 集群、Prometheus 集群；

离部门的主服务端集群面向云原生的服务治理架构还有不小差距。

自运维了反向代理 Nginx 集群、Zookeeper 集群、Storm 集群、Kafka 集群、Solr 集群、Prometheus 集群；

离部门的主服务端集群面向云原生的服务治理架构还有不小差距。

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

业务架构和研发架构长期脱钩，导致团队对大到沟通行业小到具体某个模块的领域知识沉淀缺乏，迫切需要在产研层面拉齐现有认知；

在团队达成共识的基础上将来才能形成随产品快速演进从而快速迭代领域认知的正向循环。

业务架构和研发架构长期脱钩，导致团队对大到沟通行业小到具体某个模块的领域知识沉淀缺乏，迫切需要在产研层面拉齐现有认知；

在团队达成共识的基础上将来才能形成随产品快速演进从而快速迭代领域认知的正向循环。

2.2 认清挑战

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

架构陈旧，代码里有不少隐蔽的『坑』

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

重构和业务演进既要又要

这个挑战是大部分团队都会遇到的，业务不可能停止演进等待技术重构。如何能在不影响已有业务且保证部分高优业务需求正常迭代的情况下进行重构是必须要回答的问题。

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

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

产研团队较新，对原有业务功能缺乏足够了解

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

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

3. 纾困：解决问题

仅仅从技术层面做重构只能解决眼前的技术问题，随着业务快速迭代，纯技术重构的成果很容易消失殆尽。考虑到需要对业务和技术层面双管齐下做出改变，在现有复杂业务基础上仍能保持高效的产研交付效率，加上隔壁兄弟团队之前在线索管家产品已经收获了 DDD 改造的收益，因此本次技术重构决定结合 DDD 来做，从产品到技术来一次认知升级、架构升级。

3.1 定位：确定产品方向及核心痛点

产品定位及差异价值

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

聚焦在售前接待场景，帮助商家获取联系方式，不做售后服务场景；

聚焦在广告营销场景，帮助广告主接待推广流量并优化效果；

由于是 ToB SaaS 模式，所以暂时聚焦企业客户需求，不做平台型针对企业的上层需求。

聚焦在售前接待场景，帮助商家获取联系方式，不做售后服务场景；

聚焦在广告营销场景，帮助广告主接待推广流量并优化效果；

由于是 ToB SaaS 模式，所以暂时聚焦企业客户需求，不做平台型针对企业的上层需求。

产品使用角色：谁是我们的用户？

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

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

差异化价值：客户为什么会选择我们？

全链路闭环：从推广开始到访客进站、对话、留资，直至标记会话反馈oCPC目标，全程无缝衔接；

与线索管家结合：智能识别会话和留言板中的线索信息，自动沉淀至线索管家，有效节省线索梳理工作；

智能营销：访客意图智能分析识别，千人千话引导访客开口留资；

多端共用：支持 Web、App、PC 端同时使用，随时随地实现沟通。

全链路闭环：从推广开始到访客进站、对话、留资，直至标记会话反馈oCPC目标，全程无缝衔接；

与线索管家结合：智能识别会话和留言板中的线索信息，自动沉淀至线索管家，有效节省线索梳理工作；

智能营销：访客意图智能分析识别，千人千话引导访客开口留资；

多端共用：支持 Web、App、PC 端同时使用，随时随地实现沟通。

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

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

3.2.2 边界是合作的基础：划分领域和模块，形成统一语言

根据产品定位及产品价值分析，结合梳理好的业务流程，需要划分子领域，相应配比合适的资源投入。

【核心域】

访客域和客服域属于核心域比较自然，同时作为底层的基础能力，协议连接域包括tcp、websocket、http、long polling协议，协议报文格式，连接状态维护等也应该是核心域。其次会话域也是核心域，互发消息才算进入真正沟通，会话内容里的意图表达和留资才是沟通的主要目的；

核心域的策略是围绕产品价值，重点投入资源。尽可能把非核心功能从核心域剥离，警惕容易引起团队失焦的投入。

访客域和客服域属于核心域比较自然，同时作为底层的基础能力，协议连接域包括tcp、websocket、http、long polling协议，协议报文格式，连接状态维护等也应该是核心域。其次会话域也是核心域，互发消息才算进入真正沟通，会话内容里的意图表达和留资才是沟通的主要目的；

核心域的策略是围绕产品价值，重点投入资源。尽可能把非核心功能从核心域剥离，警惕容易引起团队失焦的投入。

【支撑域】

数据分析域是必要的功能但目前还不是重点，线索域对沟通来说是后链路必经环节，但应该更多利用爱番番线索管家的能力。广告域包含访客推广信息解析，会话效果反哺，照理是核心能力。但这里划为支持域是因为关键的能力在搜索团队已提供，沟通团队做好数据接入和数据供给工作；

支撑域的策略是尽可能以较少资源建设必要能力。当然，随着业务的发展支撑域也可能在未来变成核心域。

数据分析域是必要的功能但目前还不是重点，线索域对沟通来说是后链路必经环节，但应该更多利用爱番番线索管家的能力。广告域包含访客推广信息解析，会话效果反哺，照理是核心能力。但这里划为支持域是因为关键的能力在搜索团队已提供，沟通团队做好数据接入和数据供给工作；

支撑域的策略是尽可能以较少资源建设必要能力。当然，随着业务的发展支撑域也可能在未来变成核心域。

【通用域】

账号权限功能是大多数系统的通用能力。访客场景属于ToC场景，会遇到黑产流量攻击，包括访客进站和访客发送消息需要引入风控反作弊能力。爱番番沟通主要借助了爱番番策略团队和厂内安全部的能力；

通用域的策略是尽可能不亲自建设系统，借助外部能力快速完成能力建设。

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

架构目标及设计要点

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

3.4.1 落地真正的微服务架构

随着子领域和模块的划分确定后，需要调整对应的模块职责及模块间协作关系进行改造，重点改造点包括：

合并老模块

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

经过合并下线改造后，服务数量减少了 15+。

拆分新模块

有些功能很重要，需要形成独立的模块重点建设。比如：

模块间不共享业务逻辑

改造前的后端业务服务不是真正的微服务，虽然都是独立部署，各自暴露接口，但服务实现层耦合严重：

改造原则：不共享包括业务逻辑的公共库，让微服务垂直划分，相关业务数据（包括缓存数据）归服务私有，通过 API 接口提供能力，或者通过领域事件推动下游流程。

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

可用性的关键手段是数据复制。可以借助不同的数据同步方法，结合不同特点的存储类型完成多样化业务场景的高可用性。常用的数据复制/同步手段有：

当然，这种可用性往往会牺牲一定时效性内的数据一致性，需要根据实际业务场景做出权衡。根据经验判断在马上得到答案和得到正确答案之间，大多数人更想要的其实是马上得到答案。

3.4.2 数据链路治理

storm 拓扑设计不合理，拓扑节点职责不清；

拓扑节点中存在大量的业务逻辑，普遍利用 redis 传递数据，redis 键设计混乱，可维护性很差；

storm 集群是几年前引入的，版本低，一直没升级。

经过分析业务需求，只升级 storm 集群版本不会解决实际问题，另外实时计算框架在现阶段不是必须项，因此得出了以下改造思路：

去除这个集中式的计算集群，按业务场景梳理各自数据流，避免互相干扰。让对应业务服务模块承接业务逻辑，如需提高业务响应可通过缓存集群加速；

访客一段时间不说话需要自动回复等延时场景通过延时任务的方案解决；

redis key 重新梳理，优化大 key（ 一个 key 承载的内容特别大，比如一个key 就包含全系统访客的部分信息，这样的 key 设计显然太大 ），尽量不跨服务模块直接操作 redis。

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

3.4.3 沟通协议优化为什么要做协议优化？

针对 1.2 章节中提到的客户端上经常出现丢访客，消息不上屏等问题，简单的打补丁方式已经难以将问题彻底解决，因此必须从协议层进行彻底的改造优化。详细痛点如下：

1、上面提到分布式锁控制并发，会因锁竞争而增加请求处理时间吗？

答：锁粒度为单个访客粒度，粒度足够小，而且同一个访客在快速操作（ 如频繁快速打开页面、发起沟通 ）时，才会出现锁竞争的情况，对单访客来说，常规的操作并发不大。

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

答：之前受限于业务边界划分不清晰，访客状态变更散落在业务前台、业务后台、原 storm 集群多个地方，无法做统一管控。只有在完成了前期建构优化、数据链路治理完成之后，站在原有的工作成果至上，才能做协议优化。

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

答：如前文 2.1 中第 2 条所说，客户端技术栈基于 C++，只能艰难维护，无力承接新功能需求。因此想改动客户端的协议，可谓异常艰难，这也是下文 3.5 章节客户端架构升级的一大原因。

小结

如前面所述由于历史技术栈原因爱番番沟通团队内部运维了好几种中间件，先不说引入这些中间件的正确与否，现状是没有足够知识储备，既给系统带来了很多不稳定因素，也降低了团队的研发效率。因此本次重构在这个方面的改造原则是优先考虑下线架构中不必要的中间件，必要的中间件也不另行维护，迁移到部门基础技术团队运维。

集群改造下线

Zookeeper 集群：改造前主要用来做业务配置中心，迁移到 k8s 更友好的ConfigMap（ 由基础技术团队运维 ）；

Nginx 集群：改造前有好几套反向代理集群，其中既有路由转发逻辑，也有业务逻辑。业务逻辑下沉至对应的 gateway 服务，由团队维护。路由转发逻辑迁移至 bfe 集群，由基础技术团队统一运维；

Storm 集群：逻辑改造，下线。细节上面已交代；

Solr 集群：下线，相应查询逻辑改造迁移至 ES 集群。

此部分集群虽然不能下线，但团队内不另行维护，转而迁移至部门集群。包括Kafka 和 Prometheus 集群。

3.5 扩展：客户端架构实践

3.5.1 客户端跨平台架构

随着原客户端维护代价越来越大，结合客户对 mac 端的诉求，因此选择了跨平台的 Electron 框架。

为什么选择 Electron ？

开源的核心扩展比较容易。

界面定制性强，原则上只要是 Web 能做的它都能做。

是目前最廉价的跨平台技术方案，HTML + JS 的技术储备，而且有海量的现存 UI 库。

相对其他跨平台方案（ 如 QT GTK+ 等 ），更稳定，bug 少， 只要浏览器跑起来了，问题不会太多 。

方便拓展，可以直接嵌入现有 web 页面。

爱番番前端团队的技术栈是 Vue，所以我们选择使用 Electron-Vue 来搭建项目。Electron 有两个进程，分别为主进程（ main ）和渲染进程（ renderer ）。主进程中包含了客户端自动更新、插件核心、系统 API 等。渲染进程是 vue + webpack 的架构，两个进程间通过 ipc 进行通信。

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

开发中遇到的问题

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

1、性能优化

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

2、Window7 系统下白屏问题

因为在测试过程中 QA 同学使用的一直都是 Win10 的系统，所以白屏问题一直没有被发现。直到客户端正式上线，白屏问题被集中反馈，至此我们开始重视白屏问题并积极解决。

3、其他问题

在 Electron 开发过程中还要注意一些常见问题。如读写文件的编码问题，客户端安全问题存在 rce，可被任意执行命令，内存使用率过高问题等。

3.5.2 微内核/插件化架构

什么是插件化架构

插件化架构就是软件本身只提供插件运行时的核心（ pluginCore ），并为插件运行时提供访问的接口（ pluginAPI ），通过插件平台下载插件（ plugin ）后可以在软件上完美运行。

最基本的例子就是 webpack，作为主流的构建工具，webpack 只抽象了一个软件运行时的环境，在不关心和改动这个系统已有的代码前提下，却能独立开发新的插件来充实整个系统的能力。

pluginCore: 插件运行时核心；pluginAPI：为插件运行提供访问接口；plugin：实现具体功能的插件。

插件化架构优势

插件化架构是开闭原则在跨系统级别的最佳实践。在插件核心和接口不变情况下，系统可以持续接入新插件，来丰富系统的功能。在一个非插件化的系统中，随着功能模块的增多，代码量激增，在引入新功能和修复BUG都会越来越困难和低效。但插件化架构不管已有系统功能多复杂，开发新的功能的复杂度始终一样。而且随着系统的平台化，第三方接入差异化功能也不会影响系统的稳定性。

爱番番插件化现状

为了满足其他第三方平台的定制化需求，如电商平台的商品及订单模块，CRM平台的客户模块，售后场景中的评价模块，爱番番客户端的插件化架构的设计要点：

4. 欢喜：解决效果

4.1 产品架构升级

新客户端设计原则：

按照 DDD 原则，来定义菜单模块并抽象功能层级；

结构对比老版层级更加清晰，功能扩展性更强；

容器变更并重新定义，释放核心会话功能的区域；

三端（ Mac + Win + Web ）合一，共用一套产品设计，操作灵活便捷。

4.2 客户体验提升

迁移后，我们对新客户端的使用客户进行了回访，除了需求的反馈，也收到了一些肯定：

客户

回访回复

客服A

爱番番沟通改版后，开始很不习惯，但是用了一段时间后，感觉操作比之前方便，尤其是访客多的时候，可以更有针对性的接待访客，不错。

客服B

有客人来聊天，留电话直接就能转线索，我再联系跟进，还挺方便的。

客服C

挺好的，现在功能一目了然，访客备注以及线索也是很方便了。

客服D

新客户端我看都改成速度快的这种direct UI了，以前的客户端感觉比较老嘛，不是很新潮的UI风格，现在的这个UI风格我感觉挺好的。

4.3 产研效能大幅提升

技术为产品服务，产研共同创造业务价值。产研效能是技术重构的首要目标。可以通过两方面衡量效果。

需求的整体交付速度

就像敏捷迭代的精髓不是看交付过程的单点效率，而是看发现需求到需求上线的整体效率。这也是通过 DDD 带给这次技术重构的最大价值。经过需求和业务的分析、设计、实现等环节，让产品、设计、研发整个团队的磨合和对业务的理解提升到新的高度，辅助以合理的技术架构，能整体提升需求交付效率。

技术研发效率

直接体现是更少的人支撑更大的产品范围。以前技术研发 12 人，现在 7人；

间接体现是代码维护成本大大降低，服务模块数量和团队人数比例协调，模块职责和协作关系明确，接口设计质量高，代码规范度高，新人上手速度快。

4.4 产研效能大幅提升

4.4.1 系统稳定性

4.4.2 可维护性

代码维护成本大大降低，架构在不同层面更具维护性：

服务模块数量和团队人数比例协调；

模块职责和协作关系明确；

业务数据流流转链路清晰；

项目代码 结构 规范、易懂。 新人上手速度快；

接口文档在线化。

4.4.3 可演进性

爱番番沟通系统的潜在可演进方向很多，有些方面已做好设计预留，比如：

更多沟通格式：已和业务系统解耦，很容易增加沟通内容格式如视频、语音等；

更多连接形式：目前已支持包括 http、tcp、websocket、long polling 等推拉形式协议，几乎满足了绝大部分场景；

；更多业务类型接入：基础沟通能力已有开放能力，可利用 api 方式低成本接入

沟通功能的持续演进：比如更智能化、和线索管家更无缝集成、更强的风控能力，这些需求可按需建设相应业务模块，独立演进。

5. 成长：经验总结

通过这次重构团队经历了从困境到反思的痛苦过程，相应地也获得了组织、技术、人等层面的成长。

组织

产研团队聚焦到创造业务价值，从能解决客户问题视角开展日常工作；

产研协作效率更顺畅，基于统一语言沟通需求和设计；

在业务迭代过程中沉淀了领域知识。

技术

技术问题的答案往往要从业务中寻找答案，理解业务是开展技术的前提。不同业务带来不同的技术诉求，适配的技术才是最好的，也是先进的；

经过重构的架构能适配当前业务发展，研发能把绝大部分精力放在业务实现上，屏蔽了日常开发的很多噪音。

人

通过本次重构提高了每个成员对沟通业务的全方位熟悉。既有自身业务的全貌，也有行业友商的演进现状，对未来演进方向有了对齐；

在了解技术架构的来龙去脉和全貌基础上，让每个业务研发能聚焦建设自己负责的模块。通过 DDD 实践提升自己的应用架构水平，提供了技术进阶的新方向，发挥出模块负责人的主观能动性。

6. 星辰：未来展望

目前的爱番番沟通由于进行了重新定位，方向更加聚焦，但同时也面临着很多方向性的选择。如：面对不同的上游场景以及不同的推广平台，后续的接入能力是否需要更加强大。智能机器人有些场景下的策略模型没有保持持续迭代更新，是否需要往智能化方面更进一步。

技术架构的规划首先应该围绕业务诉求展开，除此之外会继续向云原生演进，增加容量评估、全链路压测、流量治理等能力。比如近期计划把底层基座从 K8s 式微服务治理升级成服务网格，对齐爱番番主集群能力，便于以后能更好地复用基础技术平台的能力。同时进一步降低多开发语言下的统一服务治理成本（ 接入层和协议连接层的服务是 golang，业务服务是 java ）。

在未来，如何做到「既要好，又要不同」爱番番沟通产研团队依然还有很长的路要走。

7. 作者介绍

本篇系爱番番沟通产研团队多位同学共同编写。

飞邪：架构师，擅长通过微服务架构和 DDD 落地复杂系统；

坚果：产品经理，擅长 ToB SaaS 及广告产品；

甯甯：一个和商桥、在线沟通有不解之缘的产品经理；

小麦：资深前端工程师，在光速演进的前端领域内苦苦挣扎的 FE；

flyme: 资深研发工程师，擅长通过改进技术方案来应对复杂多变的业务场景。