【T112017-数据工程和技术分会场】Cloud+Native+Applications_28页_3mb

云原生应用总结

核心内容

云原生应用是一种为云环境设计和构建的应用程序，强调与云平台的深度整合和高效利用。其核心理念是通过采用一系列最佳实践和设计原则，使应用程序能够快速、灵活地部署、扩展和维护。

主要观点

• 云原生的定义
  云原生应用是与基础设施之间有明确契约的应用，能够弹性扩展，并且不依赖于特定的主机环境。

• 云原生实践与15因素
  云原生应用应遵循Heroku提出的“12因素”原则，并扩展为“15因素”，包括：

  • 单一版本控制的代码库，支持频繁部署
  • 使用容器化技术，如Docker
  • 偏好简单设计，采用测试驱动开发
  • 自动化一切流程（构建、测试、部署）
  • 通过API构建生态系统，而非依赖代码
  • 使用明确的依赖声明，确保依赖与应用一起发布
  • 避免使用主机提供的系统工具或库
  • 采用不可变的构建产物（如Docker镜像）
  • 不使用保留端口，避免容器的“host mode”网络模式
  • 应用应无状态，依赖后端服务管理状态
  • 应用应快速启动和停止，适应云环境的动态性
  • 采用“API First”设计，而非仅依赖REST
  • 使用结构化日志，便于查询和分析，避免日志与指标混淆
  • 通过环境配置管理敏感信息（如密码、URL）
  • 假设所有资源由后端服务提供，不依赖可变文件系统

• 云原生与传统架构的对比

  • 云原生应用采用微服务架构，每个服务有独立的发布周期
  • 传统单体架构（Monolith）需要逐步迁移至云原生，避免“Lift and Shift”带来的风险
  • 云原生强调持续交付和快速迭代，以适应云环境的特性

关键信息

• 容器化
  云原生应用基于容器技术，如Docker，以确保一致性和可移植性。

• 无状态设计
  云原生应用应避免依赖主机状态，所有状态应由后端服务管理。

• 快速部署与扩展
  应用应快速启动和停止，支持水平扩展，避免因资源释放缓慢导致可用性问题。

• 日志与监控

  • 日志应以标准格式输出（如JSON），并由下游日志聚合系统收集、存储和分析
  • 监控应像卫星在轨道上一样独立进行，不依赖调试工具

• 安全实践

  • 安全不应是最后考虑的问题，应从设计之初就纳入考虑
  • 明确授权策略，即使允许匿名访问，也应避免不必要的暴露
  • 使用Bearer tokens、OAuth、OIDC等最佳实践进行身份验证和授权

• 迁移策略

  • Lift and Shift：直接迁移单体应用至云，但可能缺乏云原生特性
  • Isolate and Break：逐步解耦单体应用，形成独立服务
  • Event Sourcing：通过事件驱动的方式实现解耦和状态管理，支持更灵活的架构

云原生Go语言

• 特点

  • 轻量级，学习曲线平缓
  • 可编译为原生二进制文件，运行速度快
  • 拥有活跃且庞大的社区支持

• 资源

  • 可参考网站：http://gopherize.me

云原生迁移建议

• 停止向单体添加功能
  所有新功能应基于云原生架构进行开发，避免单体臃肿

• 优先考虑关键功能
  识别并优先迁移能带来最大收益的功能模块

• 制定迁移计划
  通过持续迭代的方式逐步解构单体应用，最终实现云原生架构

• 采用多策略并行迁移
  不同模块可采用不同的迁移方式，如Lift and Shift、Isolate and Break、Event Sourcing等

云原生反模式

• “Works on my machine”
  应用应在所有环境中一致运行，避免依赖本地配置

• 使用“Sticky sessions”
  云原生应用应避免依赖会话粘性，以实现真正的无状态设计

• 将密码等敏感信息硬编码在代码中
  应用应通过环境配置管理敏感信息，避免泄露

总结

云原生应用是一种适应云环境的设计和开发方式，强调弹性、可扩展性和自动化。通过遵循15因素原则，采用容器化、无状态设计、快速部署、结构化日志和API驱动等策略，可以构建出高效、安全、可维护的应用。迁移单体应用至云原生应采取逐步解构、持续迭代的方式，避免一次性迁移带来的复杂性。Go语言因其轻量、高效和活跃的社区，成为云原生开发的热门选择。