B端架构升级之路
一、背景随着B端业务快速发展，系统愈趋复杂。我们发起了B端架构升级专项，基于B端业务的特点，从研发规范建设、B端架构基建、系统架构升级和落地保障等多方面提升了B端的架构水平。
二、升级思绪
架构是一项复杂的工程，每个团队、每个服务都有自己的诉求。在B端架构升级项目中，我们的团体思绪是先解决上线变动带来的稳定性风险，然后再逐步过渡到架构架构基建和架构规范，末了推动业务服务的架构升级。
https://pic1.lesofn.com/image-20240412154118214.png
1、首先是建设完善的流程规范及落地保障机制建设
根据稳定性的二八定律：80%的故障是变动导致的，因此研发流程及规范是优先要做的，在落地保障方面，通过工具、数据、构造保证等方式来保障规范落地及持续运营。
2、其次是完善架构基建
在稳定性方面：建设可测试性、可观测性能力，尽量把问题暴露在测试阶段，并保证线上出了问题可查看、可报警、可排查，补齐了服务的稳定性保障方面工具层的短板。
在研发效率方面：沉淀架构基建和架构规范，为以后架构升级打下基础。
3、末了是服务架构升级
通过存量业务梳理，解决存量业务中的稳定性风险；通过架构升级，推动服务领域化及架构规范化，降低认知复杂度，全面提升所有B端业务架构能力。
三、研发规范建设
通过以下三个层面建设了长期有生命力的规范保障体系，首先建设了完善的研发流程规范和故障定级规范，然后基于规范完善了流水线，从工具层面保证了规范的落地；末了做了培训和周会等制度，从培训和构造层面保障稳定性持续提升。
https://pic1.lesofn.com/1b301780911087566f5760ddc04b05d0.png
1、规范建设
建设了覆盖研发全流程的规范，这里不再详细展开。
https://pic1.lesofn.com/image-20240412164152858.png
2、规范保障机制
（1）流水线建设
基于公司的KDev流水线，从工具层面保证了规范的执行，举个例子：规范规定克制直接在master分支提交代码，口头约束、宣讲等方式都不能做到100%服从，最有效的方式是从Git工具上克制提交，做到了严格根据规范卡控。流水线建设所做工作主要有：
分类流水线步骤关键点进展&收益代码格式静态代码规范卡控定义了B端的静态代码规则适配B端新代码规范场景，避免了类误用的环境权限卡控master分支权限卡控去除了除TL外的RD权限防止没有代码review就推动到master代码评审CodeReview卡控强化了代码评审规则，具体如下：1. 需要核准的人数 >= 2 2. 需解决所有批评3. 哀求创建者克制核准合并哀求4. 代码提交者克制核准合并哀求5. MR更新时需重新举行核准6. 小组TL必须核准通过避免了代码评审走情势问题，提升了代码评审质量（2）构造建设
以上的规范和工具最终落地还是需要构造建设来保证落地。构造建设方面做的工作主要有：
a. 定期构造宣讲培训：提升RD的稳定性意识；现在已构造规范宣讲、架构规范宣讲、故障定级规范宣讲等；
b. 通过周会持续跟进规范和稳定性数据：现在已经将稳定性指标数据列为团队的OKR，每周周会Review数据并并跟进异常数据；
c. 日常技术评审和CheckList规范跟进：将技术方案评审和CheckList文档作为团队规范，日常需求迭代过程中，B端架构和稳定性治理委员会持续跟进把控技术方案和上线质量等；
四、B端架构基建建设
B端在研发时基建能力有所欠缺，由于B端业务相比C端复杂度更高，在原有C端的技术栈上开发影响开发效率。
https://pic1.lesofn.com/image-20240412161051230.png
为此我们做了以下几方面的工作：
1、B端工具建设
基于B端的业务特点，引入了三个提升研发效率的工具：
（1）lombok
引入原因：
[*]提升研发效率，代码更简洁：不用手动生成set\get等方法
[*]lombok依靠包只是编译器生效，不会带到线上，不会导致maven依靠传递
[*]行为可预知：制定规范，只使用行为可预知的注解
（2）MybatisPlus
C端原来的技术栈是基于JdbcTemplate，每个SQL都需要手写SQL，在C端场景下更注重性能，但是B端更重视研发效率和建模。经过多种方案的对比，最终选择了MybatisPlus。
引入原因：
[*]基于代码生成器，节流Model类、Dao类的开发工作
[*]节流简朴SQL还需要手动拼写的工作
疑惑解答：
[*]性能比jdbcTemplate差：没有对C端高并发读DB的接口，研发效率的考虑比性能优先级更高
[*]生成大量垃圾代码，好比Example、XML等：MyBatisPlus不会生成大量无用代码，只会生成一个简洁的文件，只有类定义
[*]污染Dao层外的代码，好比Wrapper会把数据库字段传递到Service层，方法：定义规范，Wrapper等数据操作放到Dao层
[*]生成代码不符合公司代码规范，还需要修改：自定义代码生成器解决
同时在引入MybatisPlus之后，我们做了技术栈适配的工作，包括：
[*]代码生成器适配公司的checkstyle和目录结构
[*]适配公司的分库分表组件等
（3）MapStruct
是什么：一个雷同于BeanUtils的对象转换工具
引入原因：
[*]性能：自动生成代码，性能比各类BeanUtils的反射情势提升一个数量级
[*]不会maven依靠传递：引入jar包只在编译期间有效
[*]节流工作量：节流各类DTO字段转换工作，而且可以反转
2、架构规范建设
（1）分层&目录规范
核心头脑：简洁，目标：不用翻大量代码，知道哪块代码放到什么位置
建设思绪是参考了DDD的分层规范，同时适配研发同学的风俗，形成了B端团队的规范
分模块：
[*]对外发布层：包含api层和runner层
[*]聚合层（apiService层）：承接接口层哀求，组装domain层业务组装
[*]领域层：核心业务逻辑层，可根据场景分多个service， 核心业务逻辑层，即：service、entity、dao层等
[*]基础层： 包含 外部依靠（aclService）、基础包utils、constant静态设置、config 设置等
[*]sdk层：对外发布的protobuffer定义等
分目录：
a. infra层规范
https://pic1.lesofn.com/image-20240412154848875-1712908130400-7.png
[*]aclservice 封装外部RPC接口
[*]common 设置pref打点的设置 和其他通用设置
[*]config 仓库级别的全局设置，好比线程池等
[*]constant 数据源设置，之前的kotlin设置代码
[*]exception 异常定义、错误码定义
[*]mq mq的设置
b. domain层规范
https://pic1.lesofn.com/image-20240412154943372.png
[*]doc： 主要是PlantUML流程图文件
[*]schema： MySQL和ES的定义文件及变动文件
[*]config： domain粒度的设置文件，好比MybatisPlus设置
[*]convertor： mapstruct 模型转换文件
[*]dto：http哀求、http返回值模型、其他传输模型
[*]entity： MySQL表对应的实体对象
[*]factory：创建工厂类
[*]repository： 处于dao和service中间的一层，事务都放到这一层，聚合处理多个dao表的操作
[*]valobj：entity实体类中的data对象
（2）脚手架
建设了适配B端架构规范的脚手架
之前使用的是C端脚手架，生成的模版代码如下：
https://pic1.lesofn.com/image-20240412155125185.png
新的脚手架生成的模版，主要体现领域模块和目录分层规范，示例如下：
https://pic1.lesofn.com/image-20240412155219786.png
（3）B端框架建设
B端框架是在C端框架的基础上演进而来，主要做了以下几方面的增强：
[*]Http接口统一异常拦截
[*]Http接口统一返回结构
[*]Http和Rpc接口的统一错误码定义
[*]可测试性、可观测性等能力集成
3、可测试性能力建设
B端可测试性能力的痛点：
[*]认证体系多：有三套用户体系：面向外部合作商用户的、面向运营的、面向C端用户
[*]可测试性能力缺失：之前测试都是先用账号登录staging环境，直接在浏览器借助前端页面测试，或者获取Cookie再使用Postman测试，Cookie有有效期，不能直接使用Postman之类的工具调试，导致整个调试链路复杂。
[*]对下游依靠高：在下游没给出SDK或下游服务出错的环境下，没有办法继续自测，影响测试效率。
建设思绪：
（1）建设了测试环境Mock工具，覆盖了MCN、C端用户、运营三套登录系统，在staging环境，可通过HTTP header模拟用户操作，且克制线上环境Mock调用。
（2）流水线集成sandbox：这样服务部署就即可以通过sandbox mock下游的调用，在跨团队合作开发时，下游没准备好或出问题了也可以自测，提升了开发联调效率。
4、可观测性能力建设
现在团队采用的技术栈在问题排查方面有以下痛点：
[*]日记：日记本地磁盘保存，服务重新部署后日记丢失
[*]链路追踪：设置不规范，部分服务上下游Trace没有打通，导致排查问题复杂
[*]打点：打点没有规范，建设报表每个都需要手动配
[*]异常打点： 异常打点没有和Trace打通，出了异常排查复杂
鉴戒业绩可观测的思绪，从以下三方面建设了可观测性的能力：Logging、Metrics、Tracing。
https://pic1.lesofn.com/5537d239267ad09557bb493423c27a08.png
现在落地的是日记能力，B端的日记特点是日记量小，但是要求存储时长长，我们做了以下几方面的工作：
[*]打印所有操作的http哀求的参数和返回值
[*]基于方法注解打印方法调用入参和返回值
[*]日记支持自定义业务字段（好比orderId、userId、运动ID等）的搜索
五、架构升级
架构升级的顶层规划是先分别团体视角的架构图，分别清楚各个业务的领域边界，建设B端团队基于领域建设的架构图。然后以此架构图来规划各团队的职责分别、Git仓库、领域模块。
具体执行层面分成两大块：
（1）新业务：直接按照领域架构图和以上沉淀的规范和工具建设新的服务
（2）旧业务升级：采用小步快跑的方式，逐步迭代业务架构
六、总结
以上介绍了一些普适性的架构升级思绪，团体是基于团队的现状和诉求来驱动架构升级，B端团队在架构升级过程中，以稳定性和研发效能为主线，先从研发规范入手，保证了增量变动带来的稳定性风险，然后从架构基建和规范方面为架构升级打下基础，末了从业务领域分别入手，逐步升级B端的架构。
除此之外，我们还做了一些研发效能度量体系建设、B端基础服务（通用上传下载服务、通用审核服务等）建设等工作，未来我们会聚焦业务架构，沉淀业务的基础能力，以技术驱动持续为业务赋能。
本文链接：B端架构升级之路
作者简介：木小丰，快手架构师，专注分享软件研发实践、架构思考。欢迎关注公众号：Java研发
更多精彩文章：
稳定性建设实践
高效能团队的Java研发规范(进阶版)
错误码设计思考
从MVC到DDD的架构演进
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]