一、日常问题

1）CDN 异常

　　5 月中旬，发现图像异常的上报量比平时多了 10 多倍，日常 300 多，现在 4000 多。

　　但是看不到异常的错误码，不能确定是域名问题还是服务问题。还特地查看了错误分布的时间段，但并没有看出说明规律。

　　本来以为是证书的问题，因为正好那几天证书到期了，但是证书更新后，异常量并没有降低。

　　为了缩小范围，特地去查看了几个上报量比较大的用户。

　　再反查 IP 区域，发现都是台湾那边的网络。

　　将这些信息整理后给到运维，让他去查，但效果并不理想，并没有查出问题，主要还是因为客户端并没有类似的上报。

　　所以我的问题没有被引起重视，但是在 5 月 24 号时，公司的一款 APP 也上报了相同的问题。

　　这次提工单给 CDN 厂商，将问题修复，三天后异常消失。

2）MongoDB 优化

　　公司之前在 MongoDB 中存储了大量日志类的数据，这些数据已经过时，现在是冗余数据。

　　于是用代码列出 5 张比较大的表，分别占用 207G、61G、9G、6G 和 5G。

　　其中最大那个表的数据已经同步给另一个数据分析组，所以里面的数据可以删除，我就只保留一个月的数据量。

　　从这张表中删除 834036294 条数据，持续时间 8 个多小时，减少 196G，并且做了一个定时任务，准点清理。

　　在释放另外 4 张冗余表之前，特地做了备份，执行释放命令后，也减少了 80G 容量。

　　MongoDB 从 287G 直接降低到了 11G，并且未来也会维持在这个数据量。运维说每个月至少能省个两三百的费用。

3）强缓存

　　强缓存是前端优化的常用手段，本次优化会对HTML、JavaScript 和 CSS 文件进行强缓存。

　　为了破坏 HTML 文件的强缓存，我用短链包住原始 URL 地址，在跳转时给 URL 自动带上一个时间戳参数。

https://www.xxx.com/xxx.html?ts=1717469228483

　　如此操作后，我就能保证 HTML 文件是最新的，我的目的就是缓存另外两个文件，以完成加速。

　　这次配强缓存也比较谨慎，先在测试环境调试。但很奇怪，有些资源能进缓存，而有些却不行。

　　后面发现是与 CDN 有关，于是就先关闭了 CDN，直接走网关转发。

　　一开始就缓存 30 分钟，试验 1 天，然后再缓存 8 小时，试验一天。

　　最后将强缓存增加到 3 天，1 秒内白屏占比从 92.04% 提升至 95.32%，1 秒内首屏占比从 79.71% 提升至 88.03%

　　首屏的性能提升比较明显，就是将之前 2 秒内的那批用户提升到了 1 秒内。

二、工作优化

1）暗黑模式

　　最近在浏览抖音开源的组件库时，看到个暗黑模式，看设置比较简单，于是就想在自己的管理后台也实现一个。

　　我们的后台组件库用的是 Ant Design 4.X 版本，官方文档显示，也是支持暗黑模式的。

　　框架同样基于阿里出品的 Umi3，在定制主题一栏的文档中，正好有 Umi3 使用暗黑主题的配置。

　　官方提供了 3 种配置方式，第一种是在 .umirc.ts 或 config/config.ts 加一个参数。

// .umirc.ts or config/config.ts
export default {
  antd: {
    dark: true, // 开启暗色主题
  },
},

　　第二种是在全局样式中增加暗黑模式的 antd.dark.less 或 antd.dark.css 文件。

@import '~antd/dist/antd.dark.less'; // 引入官方提供的暗色 less 样式入口文件

　　第三种是在 webpack.config.js 中使用 less-loader，按需引入。

module.exports = {
  rules: [{
    test: /\.less$/,
    use: [{
      loader: 'style-loader',
    }, {
      loader: 'css-loader', // translates CSS into CommonJS
    }, {
      loader: 'less-loader', // compiles Less to CSS
+     options: {
+       lessOptions: { // 如果使用less-loader@5，请移除 lessOptions 这一级直接配置选项。
+         modifyVars: getThemeVariables({
+           dark: true, // 开启暗黑模式
+         }),
+         javascriptEnabled: true,
+       },
+     },
    }],
  }],
};

　　我想要的效果是可以开启和关闭暗黑模式，让用户有更大的选择权，采用了第二种方法。

　　但我是动态的引入 CSS 文件，当按钮开启时，才将 CSS 文件加载进来，关闭时再移除。

{
 dark ? (
   <>
     <link rel="stylesheet" href="//www.xxx.com/css/antd.dark.css" />
    </>
  ) : null
}
<div className="layout" data-dark={dark}></div>

　　其中 dark 是一个内部状态，声明在函数组件的顶部。

const [dark, setDark] = useState(false);

　　在某些元素中，还会自定义该属性值，为了在暗黑模式时重置背景或字体颜色等样式。

.layout[data-dark=true] {
  .main {
    background-color: rgb(20, 20, 20);
  }
  .mainPer{
    background-color: rgb(20, 20, 20);
  }
  .content{
    background-color: rgb(20, 20, 20);
  }
}

　　在改变模式的时候，会同时将状态值缓存到 localStorage 中，用户再次进去就不用再选择了。

localStorage.setItem('xxxx_dark', checked);

　　官方给的暗黑样式，也会有些遗漏之处，需要自己在文件中补充。

.ant-legacy-form-item-label > label {
  color: #FFF
}
.has-error .ant-input, .has-error .ant-input:hover {
 background-color: transparent;
}

 2）Ant Design Pro

　　最近公司有一个新的业务线，需要做一个单独的小程序，后台管理要求单独做一套。

　　一开始先去找那些有前后端的开源项目，公司服务端使用的是 Go，那就去找这个语言的开源项目。

　　找到的开源项目并不尽如意，可控性和便捷性并不能那么容易的平衡。

　　最后决定各自分别维护前端和后端，我们自己去找一套新的框架，他们自己设计后台基础接口。

　　我们最终选择了 Ant Design Pro，因为我们之前的框架基于 Umi3 + And4，所以换成 Pro 后，上手成本可以低很多。

　　对于我们来说，就是升级而不是替换，并且 Pro 的封装也比较完善，对于我们的日常开发绰绰有余，于是开始着手整理。

　　因为原始的框架并不能完全满足我们之前的需求，需要做些调整，期间还踩了不少坑。

　　例如 Umi Max 废弃了 document.mjs 模板文件、useRequest() 响应默认读取的是 JSON 结构的 data 字段。

　　框架默认并不提供可视化的权限管理，需要我自己设计，那正好用来熟悉这个框架。

　　总之，前前后后花了一周时间才初步整理完成。

　　接口规范这次也做了完善，例如所有的接口除了登录之外，都需要有身份凭证。

Authorization: Bearer XXXXX

　　由于是我们先行，自己还定义好了相关的接口文档以供服务端参考，格式如下面的登录接口。

// 请求
{
  username: '',
  password: ''
}
// 响应
{
  code: 0,
  data: {
    token: 'Bear UUUU',
    access: 'admin'
  },
  msg: '登录正常'
}

　　接口的 JSON 字段（如下所示），这次也一定要明确好，不能出现多种格式。权限的设计规则，也要与后端约定好。

{
  code: 0,
  msg: '查询列表正常',
  data: [],    //或{}
}

　　若是列表接口，在请求参数中需加上当前页码和每页数量，在响应中需加上另外 3 个字段。

// 请求
{
  pageSize: 10, // 每页显示
  current: 1,   // 当前页码
}
// 响应
{
  total: 100,
  pageSize: 20,
  current: 1,
}

　　Pro 全程使用 TypeScript 语法，一开始写起来还会有点不习惯，需要慢慢适应。

　　使用新框架不仅仅是解决业务，也是一个学习的过程，学习设计思想、学习技术细节、学习各种规范。

　　虽然上手有成本，但最终来看利大于弊。