# Cannon

Cannon名字源于『大炮』，意指集中火力攻击最具价值的地方，而不是游兵散勇四面出击。让前端与后端只负责核心业务，其余一切都交付给Cannon即可，定位BFF解决方案。

# 项目背景

目前团队负责搜索/推荐/移动APP三个部门共50+平台，接入20+后端团队，存在一些几年的老项目。

在Cannon方案建设之前，各方向存在着如下顽疾痛点。

# 前端方面

各平台技术栈不同，部署编译方式也不同，新人接入成本高，维护成本也高。(例如某个老项目，开发环境就需要搭建一天。。。)
无基础设施，代码极具个人风格且重复开发量大。
严重依赖后端，无法独立部署、缺少统计打点，异常报错等稳定性措施。
无约束性，各平台文档、物料无汇聚处，导致新人介入需人肉问询，对团队累积也是弊病。

# 后端方面

各平台RD都需要大量开发重复功能，例如登录校验、权限管理等等。

因此，Cannon的建设迫在眉急。

# 全景视图

Cannon主要分为三个模块：

赋能前端 —— Render
赋能后端 —— Egg
团队影响力——(San-ssr、Egg、PM2为2021计划方向)

# Render

公共组件NPM：团队业务积累的通用组件及工具，维护了一个NPM库。
ESLint：百度FE前端代码规范定制。
StyleLint：同上，针对CSS、SCSS等。
Fis推送：本地文件直推服务器功能。
Debug工具：提供修改接口服务，前端Cookie，工作空间等调试功能。
模板脚手架：提供React、Vue两套模板CLI，内置百度所必须的基础设施。
可视化拖拽工具：满足简单网站需求，提供可视化搭平台的功能。
YAPI工具：约束接口文档规范，提供一键生成接口文件功能。

# Egg

接口代码：前端接口可选Egg代理转发，获得Egg增强功能。
BNS解析：后端服务器之间通过非HTTP方式访问时，Egg提供解析服务。
登录校验：通用功能，获取用户是否登录内网账户。
权限控制：提供用户、邮件组、用户组等权限功能，限制前端页面显示，接口访问等。
统计打点：页面UV、PV、用户来源、停留时长、接口访问成功率等20+功能。
异常报警：业务异常，同步负责人员及后续维护状态更新。
部署发布：提供平台部署、发布、回滚等功能。
Socket NSP：通用功能，支持Socket NSP功能。
日志监控：支持Web日志查询，增强日志功能。
Redis哨兵集群：通用功能，提供Redis功能。

# 影响力建设

博客文档：汇集团队全部文档。
San-SSR：提供San-SSR功能。
Egg：轻量版Node框架，Koa太简洁，Egg太重。
PM2：因PM2使用AGPL license存在法务风险，需自研。

# 方案设计流程图

下面列举部分方案设计思路及流程图。

# Cannon-Yapi接口联调全链路

在Cannon-YAPI规范工具出现之前，相关的接口文档可能在：Wiki、Swagger、Markdown甚至是聊天记录，平台维护性急剧下降。因为没有联调规范约定，每个FE与RD的联调都极具个人风格。对于他人的介入极其不友好。

因此Cannon-YAPI的主要职责有两点：文档收缩和风格统一。

所有接口都在YAPI中台注册，因此能够保证所有平台的文档风格都是一致，而且方便寻找。
功能增强，例如Mock服务、前端Axios拦截、API格式等功能都由Cannon-YAPI提供。
节省人力，前端可一键生成API文件，后端在中台填写Mock接口信息后，不会存在环境不同，接口出错的问题。
维护性增强，新人员接手任意平台其开发流程、代码风格都是一致的。

整体流程如下：

前端开发页面，后端填写接口信息并填入Mock数据。
前端一键拉取接口信息，本地自动生成接口文件，直接使用即可。
后端接口开发完毕，前端切换baseURL即可，后端也可通过Cannon-Debug工具修改baseURL。

# Cannon-Fang可视化拖拽工具

大部分平台，属于RD功能的可视化平台，平台比较简单。让前端来开发重复而简单的工作，收益不大且对自身提升较小，因此需要一个可视化拖拽工具让RD自行搭建简单的平台。

整体流程如下：

用户在Cannon-fang平台拖拽组件生成简易页面并存入数据库，其本质是JSON Scheme。
在Cannon-fang中，用户可以再次获取JSON Scheme预览页面及查看JSON Scheme。
前端通过Cannon-fang编译器工具，复制JSON Scheme编译出相应的模板文件。
前后端联调接口即可。

不足之处：页面的维护效率不太高，不过目前简单平台的迭代频率低，还能接受。

# 异常报警闭环机制

平台稳定性工程建设，在异常报警闭环机制出现之前，每次都是用户发现问题，再去通知RD去修复。效率非常低，而且经理也不知道当前的修复进度。

异常报警闭环机制，整体流程如下：

异常触发，将异常信息发送给负责RD及经理，并为RD在需求中台新建任务卡片。
RD收到邮件，根据情况在需求中台接受/延迟处理/已解决任务卡片。（卡片每次状态更新都会通知经理）

从而实现异常发现到解决的闭环。

目前不足之处：

异常分级：影响低的异常应该无需发送经理，前端异常需要发送给FE等。
电话报警：如果RD收到邮件，30分钟内未接收此卡片，需自动电话报警。（按分级--影响低的在工作时间，影响级高的24小时）