全文9000字，预计浏览工夫21分钟
一、窘境：我的项目背景爱番番沟通基于百度商桥疾速实现了产品性能和技术架构的从无到有，但同时也继承了百度商桥历史性能繁冗、技术架构古老的毛病。为了能更好地服务于爱番番沟通未来的产品演进，进步产研能效，须要从理论问题登程，聚焦主要矛盾，对产品架构和业务架构进行重构。
为了更好的了解本文内容，以下是必要的名词解释：
爱番番沟通是连贯访客和商家的在线征询工具。一方面访客能够随时随地征询，缩短访客获取服务的路径，另一方面商家也能够疾速响应并提供服务。同时在推广场景中，商家还能够依据访客的征询内容反哺回上游广告通路，优化投放模型，晋升营销转化成果。
百度商桥经验了几次不同的产品定位和多年版本迭代，产研团队也换了几波人。客户问题较多，架构长期不足系统性治理。给产研团队带来多个层面的掣肘：
面对以后窘境，整个产研团队都意识到了须要尽快做出扭转。透过景象找实质，上述景象背地的关键问题是什么呢？又会面临哪些挑战呢？
通过进一步剖析问题的根本原因，能够把问题分为以下几类：
【产品层面】产品方向及定位不明确，性能层级及分类不清晰
旧版客户端界面示例
【架构层面】客户端架构多年未演进，性能迭代难以为继
【架构层面】服务端架构的根底沟通层待演进
沟通协定层作为沟通产品十分重要的一环，还存在架构方面的有余：
【架构层面】服务端架构的业务层待演进
业务层蕴含 20+ 服务模块，次要的业务逻辑采纳共享库的形式保护，导致模块边界不清，数据链路凌乱，性能重叠耦合重大，迫切需要演进为支流微服务架构。
【架构层面】整体服务端架构自运维老本高，可维护性很低
历史遗留零碎中须要运维多种自运维中间件，导致团队不能聚焦业务性能开发。既升高了研发生产力，也给零碎稳定性带来微小挑战。
【组织层面】产研团队整体对业务的了解不够且未拉齐
归因分明问题后，重构的方向逐步清晰起来。但执行落地阶段也会面临着业务演进压力，原架构基础薄弱，资源短缺等挑战。
架构古老，代码里有不少荫蔽的『坑』
从以往经验看，有时候一个很小的改变，看起来很有把握的一次上线也可能造成客户问题。一方面代码中不足设计的中央多，另一方面整体回归测试笼罩不全。组内自嘲这种状态为『每一行代码都刚刚好』，不能多也不能少。
重构和业务演进既要又要
这个挑战是大部分团队都会遇到的，业务不可能进行演进期待技术重构。如何能在不影响已有业务且保障局部高优业务需要失常迭代的状况下进行重构是必须要答复的问题。
不能仅仅是重构，客户可感知的体验要更好
波及客户端架构降级，必然会带来一些新的用户体验，须要治理好存量用户的预期。本次重构范畴大，产品质量不降落既是要求也是挑战。
产研团队较新，对原有业务性能不足足够理解
业务研发团队很依赖领域专家的业务知识领导，子畛域间和模块间的职责和边界划分，数据归属等了解须要建设在业务了解的根底上。这些对现有团队是个不小的挑战。
因而，抓主要矛盾，分阶段小步快跑是本次重构的基调。
三、纾困：解决问题仅仅从技术层面做重构只能解决眼前的技术问题，随着业务疾速迭代，纯技术重构的成绩很容易隐没殆尽。思考到须要对业务和技术层面并行不悖做出扭转，在现有简单业务根底上仍能放弃高效的产研交付效率，加上隔壁兄弟团队之前在线索管家产品曾经播种了 DDD 革新的收益，因而本次技术重构决定联合 DDD 来做，从产品到技术来一次认知降级、架构降级。
产品定位：抉择『不做什么』更加重要
产品应用角色：谁是咱们的用户？
差异化价值：客户为什么会抉择咱们？
针对次要业务流程，产研团队通过事件风暴的形式梳理了事件流，定义了每个事件相干的角色、动作、规定条件和事件后果。最重要的是对齐了团队的业务认知，靠个体智慧分析了整体业务细节。
依据产品定位及产品价值剖析，联合梳理好的业务流程，须要划分子畛域，相应配比适合的资源投入。
【外围域】
【撑持域】
【通用域】
3.3 架构：搭建整体技术架构
随着子畛域和模块的划分确定后，须要调整对应的模块职责及模块间协作关系进行革新，重点革新点包含：
合并老模块
革新前服务端有45+服务模块，服务职责划分不当，服务粒度不适合。具体表现为：
通过合并下线革新后，服务数量缩小了 15+。
拆分新模块
有些性能很重要，须要造成独立的模块重点建设。比方：
模块间不共享业务逻辑
革新前的后端业务服务不是真正的微服务，尽管都是独立部署，各自裸露接口，但服务实现层耦合重大：
革新准则：不共享包含业务逻辑的公共库，让微服务垂直划分，相干业务数据（包含缓存数据）归服务公有，通过 API 接口提供能力，或者通过畛域事件推动上游流程。
最终一致性前提下的高可用性
可用性的要害伎俩是数据复制。能够借助不同的数据同步办法，联合不同特点的存储类型实现多样化业务场景的高可用性。罕用的数据复制/同步伎俩有：
CDC 模式和公布订阅模式配合应用能满足很多场景，拆散读写服务和选取异构存储介质。比方访客进站记录写入 MySQL 和访客历史记录查问ES，会话写入 Table 和会话剖析服务查问 Doris 。即能无效满足各自场景的数据存取需要也能进步场景的可用性。
当然，这种可用性往往会就义肯定时效性内的数据一致性，须要依据理论业务场景做出衡量。依据教训判断在马上失去答案和失去正确答案之间，大多数人更想要的其实是马上失去答案。
革新前次要场景包含进站、离站、主动回复、会话内容校验、线索辨认、完结会话等的数据流的必经节点是实时计算服务，其外围实现是 storm，但因为多种起因该集群很不稳固，会引发出上述提到的大量客户问题。深层剖析现状次要有以下弊病：
通过剖析业务需要，只降级 storm 集群版本不会解决理论问题，另外实时计算框架在现阶段不是必须项，因而得出了以下革新思路：
业务程序的灵魂是数据，技术架构时要多花工夫思考数据存储和读取的方方面面。比方用什么存储系统（ 存储系统不可能读也最快，写也最快，须要衡量 ）、什么时候用缓存，整个业务流程的数据传输链路应该怎么样，沟通零碎波及到很多写放大还是读放大的衡量等等。本次重构也波及到了这些方面的梳理和革新，在此不一一介绍。
针对 1.2 章节中提到的客户端上经常出现丢访客，音讯不上屏等问题，简略的打补丁形式曾经难以将问题彻底解决，因而必须从协定层进行彻底的革新优化。具体痛点如下：
优化状态协定，简化掉动作告诉类报文，采纳以访客状态为主的报文，如下图所示，将动作报文简化掉，只保留状态报文，报文数量缩小约 60%，升高客户端解决复杂度，减小出错概率。
1、下面提到分布式锁管制并发，会因锁竞争而减少申请解决工夫吗？
答：锁粒度为单个访客粒度，粒度足够小，而且同一个访客在疾速操作（ 如频繁疾速关上页面、发动沟通 ）时，才会呈现锁竞争的状况，对单访客来说，惯例的操作并发不大。
2、既然协定优化收益这么搞，为什么不早点做协定优化呢？
答：之前受限于业务边界划分不清晰，访客状态变更散落在业务前台、业务后盾、原 storm 集群多个中央，无奈做对立管控。只有在实现了后期建构优化、数据链路治理实现之后，站在原有的工作成绩至上，能力做协定优化。
3、客户端的推拉联合为什么不早点做呢？
答：如前文 2.1 中第 2 条所说，客户端技术栈基于 C++，只能艰巨保护，有力承接新性能需要。因而想改变客户端的协定，堪称异样艰巨，这也是下文 3.5 章节客户端架构降级的一大起因。
如后面所述因为历史技术栈起因爱番番沟通团队外部运维了好几种中间件，先不说引入这些中间件的正确与否，现状是没有足够常识储备，既给零碎带来了很多不稳固因素，也升高了团队的研发效率。因而本次重构在这个方面的革新准则是优先思考下线架构中不必要的中间件，必要的中间件也不另行保护，迁徙到部门根底技术团队运维。
此局部集群尽管不能下线，但团队内不另行保护，转而迁徙至部门集群。包含Kafka 和 Prometheus 集群。
3.5 扩大：客户端架构实际
3.5.1 客户端跨平台架构
随着原客户端保护代价越来越大，联合客户对 mac 端的诉求，因而抉择了跨平台的 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平台的客户模块，售后场景中的评估模块，爱番番客户端的插件化架构的设计要点：
{
"version":"0.0.1", // 版本号
"id":"demo-name", // 绑定事件ID
"name":"组件名称", // 插件名称
"viewUrl":"", // 如果是菜单插件须要提供webview地址
"target":"toolbar", // menuList——菜单插件、toolbarList——沟通区插件、infoList——右侧工具栏插件
"dependent": {
"method": [],
"version":"1.0.6" // 依赖客户端版本
}
}
新客户端设计准则：
迁徙后，咱们对新客户端的应用客户进行了回访，除了需要的反馈，也收到了一些必定：
技术为产品服务，产研独特发明业务价值。产研效力是技术重构的首要指标。能够通过两方面掂量成果。
需要的整体交付速度
技术研发效率
4.4.1 零碎稳定性
间接体现是后面交代的高频技术稳定性问题如访客进站辨认不及时、主动回复不触发等已失去全面的治理，各零碎模块稳定性指标长期维持在 99.99%。
4.4.2 可维护性
代码保护老本大大降低，架构在不同层面更具维护性：
4.4.3 可演进性
爱番番沟通零碎的潜在可演进方向很多，有些方面已做好设计预留，比方：
五、成长：经验总结
通过这次重构团队经验了从窘境到反思的苦楚过程，相应地也取得了组织、技术、人等层面的成长。
组织
技术
人
目前的爱番番沟通因为进行了从新定位，方向更加聚焦，但同时也面临着很多方向性的抉择。如：面对不同的上游场景以及不同的推广平台，后续的接入能力是否须要更加弱小。智能机器人有些场景下的策略模型没有放弃继续迭代更新，是否须要往智能化方面更进一步。
技术架构的布局首先应该围绕业务诉求开展，除此之外会持续向云原生演进，减少容量评估、全链路压测、流量治理等能力。比方近期打算把底层基座从 K8s 式微服务治理升级成服务网格，对齐爱番番主集群能力，便于当前能更好地复用根底技术平台的能力。同时进一步升高多开发语言下的对立服务治理老本（ 接入层和协定连贯层的服务是 golang，业务服务是 java ）。
在将来，如何做到「既要好，又要不同」爱番番沟通产研团队仍然还有很长的路要走。
七、作者介绍本篇系爱番番沟通产研团队多位同学独特编写。
接口文档主动更改？百度程序员开发效率MAX的秘诀
技术揭秘！百度搜寻中台低代码的摸索与实际
百度智能云实战——动态文件CDN减速
化繁为简&＃8211;百度智能小程序主数据架构实战总结
百度搜寻中台海量数据管理的云原生和智能化实际
百度搜寻中“泥沙俱下”的加盟信息，如何靠AI 解决？
&＃8212;&＃8212;&＃8212;- END &＃8212;&＃8212;&＃8212;-
百度 Geek 说
百度官网技术公众号上线啦！
技术干货 · 行业资讯 · 线上沙龙 · 行业大会
招聘信息 · 内推信息 · 技术书籍 · 百度周边
欢送各位同学关注
京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有