云原生

发表于 | 分类于 | 阅读次数

云原生应用架构实践手册

云原生

  • 容器化：所有的服务都必须部署在容器中。
  • 微服务：web 服务架构是微服务架构
  • CI/CD：可持续交互和可持续部署
  • DevOps：开发和运维密不可分

适用于 PaaS 的 12 因素应用的规范

十二因素应用

  • 基准代码

每个代码仓库（repo）都生成docker image保存到镜像仓库中，并使用唯一的ID管理，在Jenkins中使用编译时的ID。

  • 依赖

显式的声明代码中的依赖，使用软件包管理工具声明，比如Go中的Glide。

  • 配置

将配置与代码分离，应用部署到Kubernetes中可以使用容器的环境变量或ConfigMap挂载到容器中。

  • 后端服务

把后端服务当作附加资源，实质上是计算存储分离和降低服务耦合，分解单体应用。

  • 构建、发布、运行

严格分离构建和运行，每次修改代码生成新的镜像，重新发布，不能直接修改运行时的代码和配置。

  • 进程

应用程序进程应该是无状态的，这意味着再次重启后还可以计算出原先的状态。

  • 端口绑定

在Kubernetes中每个Pod都有独立的IP，每个运行在Pod中的应用不必关心端口是否重复，只需在service中指定端口，集群内的service通过配置互相发现。

  • 并发

每个容器都是一个进程，通过增加容器的副本数实现并发。

  • 易处理

快速启动和优雅终止可最大化健壮性，Kuberentes优秀的Pod生存周期控制。

  • 开发环境与线上环境等价

在Kubernetes中可以创建多个namespace，使用相同的镜像可以很方便的复制一套环境出来，镜像的使用可以很方便的部署一个后端服务。

  • 日志

把日志当作事件流，使用stdout输出并收集汇聚起来，例如到ES中统一查看。

  • 管理进程

后台管理任务当作一次性进程运行，kubectl exec进入容器内部操作。

API优先

  • 服务间的合约
  • 团队协作的规约
  • 文档化、规范化
  • RESTful或RPC

监控

  • 实时监控远程应用
  • 应用性能监控（APM）
  • 应用健康监控
  • 系统日志
  • 不建议在线Debug

认证授权

  • 不要等最后才去考虑应用的安全性
  • 详细设计、明确声明、文档化
  • Bearer token、OAuth、OIDC认证
  • 操作审计

OAM Open Application Model

OAM 全称是 Open Application Model，从名称上来看它所定义的就是一种模型，同时也实现了基于 OAM 的我认为这种模型旨在定义了云原生应用的标准。

  • 开放（Open）：支持异构的平台、容器运行时、调度系统、云供应商、硬件配置等，总之与底层无关
  • 应用（Application）：云原生应用
  • 模型（Model）：定义标准，以使其与底层平台无关

设计原则

OAM 规范的设计遵循了以下原则：

  • 关注点分离：根据功能和行为来定义模型，以此划分不同角色的职责，
  • 平台中立：OAM 的实现不绑定到特定平台；
  • 优雅：尽量减少设计复杂性；
  • 复用性：可移植性好，同一个应用程序可以在不同的平台上不加改动地执行；
  • 不作为编程模型：OAM 提供的是应用程序模型，描述了应用程序的组成和组件的拓扑结构，而不关注应用程序的具体实现。

OAM 定义的云原生应用模型示意图，为了便于理解，图中相同颜色的部分为同一类别的对象定义。

云原生应用模型

  • OAM 模型中包含以下基本对象，以本文发稿时的最新 API 版本 core.oam.dev/v1alpha2 为准：
    • Component：OAM 中最基础的对象，该配置与基础设施无关，定义负载实例的运维特性。例如一个微服务 workload 的定义。
    • TraitDefinition：一个组件所需的运维策略与配置，例如环境变量、Ingress、AutoScaler、Volume 等。（注意：该对象在 apiVersion: core.oam.dev/v1alpha1 中的名称为 Trait）。
    • ScopeDefinition：多个 Component 的共同边界。可以根据组件的特性或者作用域来划分 Scope，一个 Component 可能同时属于多个 Scope。
    • ApplicationConfiguration：将 Component（必须）、Trait（必须）、Scope（非必须）等组合到一起形成一个完整的应用配置。

不同角色对于该模型的关注点示意图