构建SaaS应用的12条建议

构建SaaS应用的12条建议

在构建微服务应用是需要遵循12条准侧, 本文为精简版的12factor, 并添加了一些自己的理解, 如有纰漏欢迎指正:

1. 基准代码(Codebase)

  • 一个应用对应一份基准代码, 存放到单独的一个代码库中, 在代码库中跟踪所有的修订版本
  • 一个应用可对应于多个部署, 多个部署基于同一个代码库, 但可以基于不同版本, 不同分支.

2. 依赖

  • 显式的声明依赖关系, 如java可通过maven,gradle声明依赖, nodejs通过npm声明依赖.
  • 任何开发人员, 基于依赖管理软件初始化后, 需要保证依赖相同.

3. 配置

  • 配置不能写死到代码中, 需要与代码分离
  • 一套环境对应于一套配置
  • 可通过环境变量, 配置中心等手段传递不同环境的配置

4. 后端服务

  • 计算和存储要分离, 降低服务的耦合
  • 例如MySQL, Redis, 邮件等均可作为单独的服务

5. 构建、发布、运行

  • 严格区分构建, 发布, 运行
  • 不可修改运行状态下的代码, 任何修改均在基准代码中修改, 然后产生新的发布
  • 每个版本对应于一个唯一的ID, 如把git commit hash, 或者时间戳作为版本号, 一旦发布不可修改

6. 进程

  • 应用通常以一个或者多个进程运行 (例如一个java应用就是一个java进程)
  • 应用需要无状态, 任何存储均放在4.后端服务

7. 端口绑定

  • 如果是单个IP, 则每个服务绑定一个端口, 通过IP:PORT的形式可访问到该服务.
  • 如果使用k8s, 每个pod对应唯一的IP, 则只需在service中指定好pod的端口.

8. 并发

  • 进程是无状态的, 因此可以通过启动多个进程的方式来处理并发问题(提高性能)
  • 对于k8s, 一个进程对应于一个pod, 所以可启动多个pod来实现该目标

9. 易处理(Disposability)

  • 应用启动时间应尽可能短(10s以内)
  • 进程接收到SIGTERM信号后会优雅终止, 并且终止时间尽可能短(10s以内)
  • 进程面对突发异常时可保持健壮

10. 开发环境与线上环境等价

  • 缩小时间差异(几小时)
  • 缩小人员差异(开发,运维为同一批人)
  • 缩小环境差异(环境几乎相同)
  • k8s中可通过容器化应用+不同namespace部署到不同的环境

11. 日志

  • 不处理日志, 直接输出到stdout
  • 在容器级别汇集stdout的输出, 发送到ELK中

12. 管理进程

  • 相当于可通过ssh进入到进程所在环境, 执行一次性命令
  • k8s中可通过kubectl exec -it <pod-name> bash的方式进入容器


Fifteen Factors

网上还找到一份15 Factors of Cloud Native版, 在12 Factors的基础上添加以下三条

API first

  • 服务间API的合约, 文档化, 规范化
  • API First != REST first

监控(Telemetry)

  • 监控应用状态, 和性能
  • 应用和健康日志
  • 禁止线上debug

认证和授权(Authentication & Authorization)

  • 不能到最后在考虑安全问题
  • 审计所有的访问尝试
  • 授权应该是明确的
  • Bearer tokens/OAuth/OIDC best practices
0%