【T112017-数据工程和技术分会场】CloudNativeApplications_29页_3mb

报告摘要

文档总结：Cloud Native Applications 和迁移策略

核心内容

文档主要探讨了云原生（Cloud Native）应用程序的定义、核心实践和迁移策略。通过结合行业经验与最佳实践，提供了从单体架构向云原生架构演进的指导思路。

Cloud Native 定义与特点

什么是 Cloud Native？

Cloud Native 是一种应用与基础设施之间的契约，强调应用应具备弹性扩展和水平扩展的能力。
应用应不依赖于特定主机，而是通过云平台提供的资源进行部署。
基于Heroku 的 12 因素（扩展为 15 因素）设计，旨在适应云环境。

云原生应用程序的核心特性

基于容器：使用容器技术（如 Docker）实现应用的可移植性。
快速、持续交付：支持敏捷开发，强调持续集成与持续交付（CI/CD）。
构建生态系统而非单体：鼓励微服务架构，避免代码共享。
简化设计：避免复杂依赖，依赖外部服务而非本地库。
环境配置独立：应用应从环境中获取配置信息，而不是硬编码。
日志标准化：应用应输出结构化日志（如 JSON、CSV），便于收集、分析和监控。
快速启动与停止：云环境中进程频繁启动和停止，应用需具备快速响应的能力。
无状态设计：应用应避免维护本地状态，依赖外部存储服务。
资源依赖明确：应用应将所有资源（如数据库、存储）视为外部服务，而非本地文件系统。
安全性优先：认证应显式且文档化，避免匿名访问。

云原生的 15 因素

以下是云原生应用应遵循的 15 个核心实践：

单版本控制的代码库
- 所有应用应使用单一版本控制代码库，避免多个应用共享代码。
服务生态系统
- 服务之间应通过API进行通信，而非代码依赖。
- 使用Protobuf IDL、Swagger、Apiary等工具定义 API。
依赖显式声明
- 应用应显式声明所有依赖，并将其包含在发布包中。
构建不可变的构建产物
- 使用容器镜像等技术构建不可变的发布包。
最小化容器镜像
- 使用scratch作为基础镜像，减少体积和攻击面。
不依赖主机系统工具或库
- 所有依赖应通过容器或外部服务提供。
设计为迭代开发
- 采用成熟的 CI/CD 流水线，确保快速迭代和部署。
自动部署
- 应用应能自动部署到环境，环境应包含配置信息，而非发布包。
“3 Cs” 管理
- 避免将敏感信息（如密码、URL）硬编码在代码或配置文件中。
- 应用应从环境接受配置，并使用安全默认值。
日志标准化
- 应用应输出结构化日志（如 JSON），便于下游日志聚合系统（如 ELK、Splunk）处理。
- 日志不应与指标混淆。
快速启动与停止
- 应用应具备快速启动和停止的能力，以支持云环境的弹性伸缩。
资源视为服务
- 应用应将所有资源（如数据库、存储）视为外部服务，而非本地资源。
“Works on my machine” 是反模式
- 应用应能在任何环境中运行，避免本地环境依赖。
测试驱动开发
- 遵循“测试第一，测试一切”的原则，确保代码可发布、可部署。
安全设计
- 认证应显式且文档化，使用Bearer tokens、OAuth、OIDC等安全机制。
- 审计所有访问尝试，避免匿名访问。