模块化开发、容器化开发

使用微服务架构或 Mono Repo 架构中的问题

拆包不合理

一、类型的定义

(如 Typescript 中的 interface、type,或者请求/响应,参数/返回等 DTO),不应当放置到一个底层的通用包中。这样会导致一处业务修改,联动项目代码、底层包代码需要修改,然后需要发布包、更新依赖版本等,非常麻烦。

同时,大部分的类型定义是不具备复用的可能的。比如数据库 Schema,会有一些多余的不可操作的字段,如 id、时间戳、状态等,所以在 create 方法中,传入的参数,可能是 Partial<SchemaEntity>(也可能会有一些生成字段之类的特殊情况)。在接口请求参数中,更是会和数据库 create 方法的参与差异很大,比如说密码,用户输入是明文,存到数据库中是密文 + SALT。等等。返回值亦是如此。

为减少重复代码量和修改,和保证结构的稳定性,可以参考 TypeScript Handbook 中的一些小技巧:

  • Type Manipulation: 从类型创建类型、泛型、 keyof、 typeof、索引访问、条件类型、映射类型、模板文字类型
  • Utility Types: Partial<Type>Pick<Type, Keys>Omit<Type, Keys>Exlude<Type, ExludedUnion>Parameters<Type>ReturnType<Type>

二、先设计,再封装,后拆分

业务未设计完善时,切忌着急先封装成包。这样一旦发生调整,将会从下往上每一层都得做变更。

人无远虑必有近忧。能在设计过程中解决掉的问题,绝对不要拖到实现过程中迭代。设计中需要遵守的几点原则:

MVP 原则

即最简化可实行产品原则,按照以下顺序进行设计和实现:明确需求,满足基本需求,保证稳定性,完善需求,扩展需求,提高性能。

冰冻三尺非一日之寒。一口也吃不成一个胖子。无论多复杂的业务模块,都是拆分成了一个个小的子任务,每一个子任务模块设计完备了,进行扩展和整合。

分治原则

压力下方,分而治之。不要在一个点上去耗费大量的性能和资源。往往在架构设计的时候,只有一到两个数据中心,数据中心将会处理大量的数据和请求,所以会承担很大的性能压力。那么, 能在区域服务器上进行的处理和运算,没有必要扔到数据中心去进行;能在网关上进行的处理和运算,没有必要扔到服务器上去进行;能在客户端上进行的处理和运算,没有必要扔到网关上去运行。

举个简单的例子,一台负载均衡器下的服务器配置可能是双核心,4GB 内存, 这一台服务器,能够承载的并发是 10 万级,而目前的智能终端(比如智能手机),可能都是 4 核 8 核, 8GB 内存之类的,实际上已经有很强大的运算能力了。足够承担起很大一部分的数据预处理和初筛的工作。所以,可以将服务器的压力逐层进行下放,让下面连接的服务器,网关和终端各自承担一部分运算处理工作,充分利用各个存储运算单元。

函数定义不合理

一、 不推荐使用多参数方式定义一个函数。

示例:

export functionA(arg1: string, arg2: number, arg3: string, arg4: number): void;
 
// 或
 
class ClassA {
  constructor(arg1: string, arg2: number, arg3: string, arg4: number) { }
}

推荐的做法为,单一对象参数,或 id + 单一对象参数的方式。

示例:

// Class 示例
import { plainToClass } from 'class-transformer';
import { validateSync } from 'class-validator';
 
export class BaseDto {
  // eslint-disable-next-line
  constructor(data: any) {
    // 仅当作为基类,不确定输入类型时使用 any
    if (data) {
      // eslint-disable-next-line @typescript-eslint/no-explicit-any
      Object.assign(this, plainToClass(this.constructor as any, data));
      const errors = validateSync(this, {
        dismissDefaultMessages: true,
        stopAtFirstError: true,
        whitelist: true,
        forbidNonWhitelisted: true
      });
      if (errors?.length > 0) {
        throw new Error('Validation Error Occurred');
      }
    }
  }
}
// 方法示例
import { BaseDto, Validator, Transform, DB } from '@dao/base';
import { IsEmail, IsMobilePhone, IsEnum, IsOptional, IsString } from 'class-validator';
import { UserEntity, UserRole } from '../entity';
import { getUserByUid } from './get_user_by_uid.dao';
import { checkUserExist } from './check_user.dao';
import { UserDaoErr } from '../error';
 
// 定义好单一对象参数的类型
export type UpdateUserDto = Partial<Pick<UserEntity, 'role' | 'username' | 'email' | 'mobile' | 'passwd'>>;
 
// 如果需要数据校验,可以做一层封装
// 尤其是在接口请求、调用底层方法(如数据库操作)时,非常必要
class Model extends BaseDto implements UpdateUserDto {
  @IsEnum(UserRole)
  @IsOptional()
  role?: UserRole;
 
  @Transform.ToLowerCase()
  @Validator.IsEnglishName()
  @IsOptional()
  username?: string;
 
  @IsEmail()
  @Transform.ToLowerCase()
  @IsOptional()
  email?: string;
 
  @IsMobilePhone('zh-CN')
  @Transform.ToLowerCase()
  @IsOptional()
  mobile?: string;
 
  @IsString()
  @IsOptional()
  @Transform.ToPassHash()
  passwd?: string;
}
 
/**
 * 修改用户信息
 * @param {string} uid 用户 id
 * @param {UpdateUserDto} data 单一对象参数,定义好类型
 * @returns {boolean}
 */
export async function updateUser(id: string, data: UpdateUserDto): Promise<boolean> {
  // 此处为 class-transformer + class-validator 校验
  const item = new Model(data);
  // 如果上一步校验不通过,则会抛出错误
  const user = await getUserByUid(id);
  // 省略校验判断,荣用户名、手机号是否存在
  // ...
  return DB.updateById(id, item, DB.DBTABLE.User);
}

二、 做向下兼容。

这就是单一对象变量的好处,删除一个字段和新增一个字段,都会更加方便。

示例:

export class CreateUserDto {
  username: string;
 
  // @deprecated 公司字段已弃用
  company?: string; // 废弃字段,只需要改成 optional 即可。
  // 即便不做向下兼容的操作,直接把该字段删除就可以了
 
  // 手机号 new in v1.0.1
  mobile?: string; // 如果 Client 没有升级,则不会传这个字段,所以也设置成 optional
}
 
export function createUser(user: CreateUserDto) {
  if (user.company) {
    // 如果影响业务,则抛出异常
    logger.info('该字段已经废弃,请停止使用,并升级到 v1.0.1');
  }
  if (!user.mobile) {
    // 兼容性操作,如需,下面是乱写的
    // eslint-disable-next-line no-param-reassign
    user.mobile = null;
  }
  // 省略代码
}

容器化开发

本地环境模块化

所有东西都在独立的容器内运行,如果不用,停止状态下只占用磁盘空间,出现了问题也就直接删除重建即可。

以 MySQL 为例,以前都是安装在本地,所有应用程序共用,只有一个版本,并且一旦出了问题,卸载重装也是很麻烦的事情。

现在只需要一个 Docker Compose 文件定义好启动即可,示例:

# docker-compose.yml
version: '3'
 
services:
  mysql:
    image: mysql
    container_name: mysql
    command:
      # MySQL8的密码验证方式默认是 caching_sha2_password,但是很多的连接工具还不支持该方式
      # 就需要手动设置下mysql的密码认证方式为以前的 mysql_native_password 方式
      --default-authentication-plugin=mysql_native_password
      --character-set-server=utf8mb4
      --collation-server=utf8mb4_general_ci
    restart: unless-stopped
    environment:
      MYSQL_ROOT_PASSWORD: root # root用户的密码
      # MYSQL_USER: user # 创建新用户
      # MYSQL_PASSWORD: user_password # 新用户的密码
    ports:
      - 3306:3306
    volumes:
      - ./data:/var/lib/mysql
      - ./conf:/etc/mysql/conf.d
      - ./logs:/logs
    network_mode: bridge

配置好用户名密码、字符集、设定当前目录下来存放数据、日志和配置文件。

简单的几个命令进行操作:

# 启动
docker-compose up -d
# 停止
docker-compose down
# 删除所有数据
rm -rf data conf logs
# 重新创建镜像
docker-compose up -d --force-recreate

更多实用的容器参考项目: https://github.com/WhiteMatrixTech/dev-in-docker

模块化运行

以 Node.js 为例。

推荐镜像: node:16-alpine (如非特殊情况,使用当前最新的 alpine 版本)

更多镜像参考官方 Hub: https://hub.docker.com/_/node/

本地调试

TBD.

镜像发布

参考 Node.js 官方文档:把一个 Node.js 应用程序 Docker 化

写一个 Dockerfile

FROM node:16-alpine
 
LABEL maintainer "Willing Wang<[email protected]>"
 
COPY . /app
WORKDIR /app
 
RUN yarn
RUN yarn build
 
EXPOSE 3000
CMD [ "node", "dist/server.js" ]
# 打包镜像
docker build . -t <username>/node-app
# 运行镜像
docker run -p 3000:3000 <username>/node-app

模块化开发

TBD.

The End