B端架构升级之路-Toy模板网

这篇具有很好参考价值的文章主要介绍了B端架构升级之路。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

一、背景

随着B端业务快速发展，系统愈趋复杂。我们发起了B端架构升级专项，基于B端业务的特点，从研发规范建设、B端架构基建、系统架构升级和落地保障等多方面提升了B端的架构水平。

二、升级思路

架构是一项复杂的工程，每个团队、每个服务都有自己的诉求。在B端架构升级项目中，我们的整体思路是先解决上线变更带来的稳定性风险，然后再逐步过渡到架构架构基建和架构规范，最后推动业务服务的架构升级。

1、首先是建设完善的流程规范及落地保障机制建设

根据稳定性的二八定律：80%的故障是变更导致的，因此研发流程及规范是优先要做的，在落地保障方面，通过工具、数据、组织保证等方式来保障规范落地及持续运营。

2、其次是完善架构基建

在稳定性方面：建设可测试性、可观测性能力，尽量把问题暴露在测试阶段，并保证线上出了问题可查看、可报警、可排查，补齐了服务的稳定性保障方面工具层的短板。

在研发效率方面：沉淀架构基建和架构规范，为以后架构升级打下基础。

3、最后是服务架构升级

通过存量业务梳理，解决存量业务中的稳定性风险；通过架构升级，推动服务领域化及架构规范化，降低认知复杂度，全面提升所有B端业务架构能力。

三、研发规范建设

通过以下三个层面建设了长期有生命力的规范保障体系，首先建设了完善的研发流程规范和故障定级规范，然后基于规范完善了流水线，从工具层面保证了规范的落地；最后做了培训和周会等制度，从培训和组织层面保障稳定性持续提升。

1、规范建设

建设了覆盖研发全流程的规范，这里不再详细展开。

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端的技术栈上开发影响开发效率。

为此我们做了以下几方面的工作：

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层规范

aclservice 封装外部RPC接口
common 配置pref打点的配置和其他通用配置
config 仓库级别的全局配置，比如线程池等
constant 数据源配置，之前的kotlin配置代码
exception 异常定义、错误码定义
mq mq的配置

b. domain层规范

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端脚手架，生成的模版代码如下：

新的脚手架生成的模版，主要体现领域模块和目录分层规范，示例如下：

（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下游的调用，在跨团队合作开发时，下游没准备好或出问题了也可以自测，提升了开发联调效率。