云原生应用开发原则与最佳实践指南

1、云原生应用开发原则与最佳实践指南如何开发更具可靠性和扩展性、更加易于维护的云原生应用The 12 Factors: Not Rules. They are Solutions.2使用标准化流程自动 配置，使新进开发 者花费最少的学习 成本进入项目。和运行环境尽可能 的划清界限，在各 个系统中提供最大 的可移植性。将开发环境和生产 环境的差异降至最低 ，并使用持续交付 实施敏捷开发。适应部署在现代化云 基础设施，在系统 和资源管理方面更 加高效。可以在工具、架构 和开发流程不发生明 显变化的前提下实 现扩展。配置 标准化最大 可移植性适应 持续交付适应 云部署弹性 可扩展I基准代码一份基准代码，

2、多份部署II依赖显式声明依赖关系III配置在环境中存储配置IV后端服务把后端服务当作附加资源V构建、发布、运行 严格分离构建和运行VI进程以一个或多个无状态进程运行应用云原生应用开发12原则总览3VII端口绑定通过端口绑定提供服务VII I并发通过进程模型进行扩展IX易处理快速启动和优雅终止可最大化健壮性X环境尽可能的保持开发、预发布、生产环境相同XI日志把日志当作事件流XII管理后台管理任务当作一次性进程运行但是：为什么？怎么做？4原则1：一份基准代码，多份部署5使用版本控制系统管理代码一份基准代码对应一个应用不允许多个应用共享一份基准代码同一应用的多份部署可以使用同一份基准代码的不同版本，

3、但是不可以使用不同的 基准代码，使用不同基准代码的应用不应被视为同一应用原则1：反模式16CodebaseCodebase1 Codebase = * Apps原则1：反模式27* Codebase = 1 AppCodebaseCodebase CodebaseCodebaseCodebase原则1：补充8基准代码的划分和应用的划分非常类似，也是系统边界的一种体现如果多个应用不是通过类库/微服务，而是直接共享一份基准代码，那么这份被共 享的基准代码会很难维护原则1：反模式3* Codebase = * App9原则2：显式声明依赖关系10这里的依赖指所有的依赖 持续发布假定目标环境中空无一物

4、 面向容器依赖声明必须配合依赖隔离 避免错误依赖原则2：补充11如果使用微服务模式，理想情况 下，使微用服S务e之rv间ice的M依e赖sh关系也应 该进行显示声明，并配置超时、 重试、限流、熔断、Fallback原则3：在环境中存储配置12这里的配置指与部署有关的配置配置文件的问题：容易被误提交到代码库容易被误部署到目标环境分散在不同的目录中没有统一的格式原则4：把后端服务当作附加资源13充分利用云平台的服务能力通过URL或者服务注册/认证中心访问这些服务原则5：严格分离构建、发布和运行14运行仅限于启动进程，资源文件的关联应仅限于构建阶段，配置的结合应仅限于发 布阶段发布的版本就像一个只能

5、追加的账本，一旦发布就不能修改原则6：以一个或多个无状态的进程运行应用15除了基本的无状态要求之外：应用实例之间不要直接共享数据不要使用粘滞会话不要在应用内部缓存数据原则7：通过端口绑定提供服务16应用应该完全自我包含端口绑定应该由云平台自动进行原则8：通过进程模型进行扩展17使用“固定的”进程使用横向扩展原则9：快速启动和优雅终止可最大化健壮性18设计期即要考虑快速启动充分考虑意外的程序终止：客户端重连、任务断点、事务完整性、操作幂等性、资 源锁定、数据损坏原则10：开发环境与线上环境等价19尽量缩小开发环境与线上环境的差异：软件栈上的差异 线上开发时间上的差异 持续交付人员上的差异 Dev

6、Ops原则11：把日志当作事件流20将日志以事件流的方式输出到STDOUT和STDERR由运行环境捕获事件流，并转发到日志处理服务原则12：后台管理任务当作一次性进程运行21原则12：修正22如果管理任务是修改配置，那么就通过配置中心进行如果管理任务是批处理，如数据迁移、清洗或检查，那么就通过云平台的批处理机 制进行如果使用容器技术，就通过容器模板创建一个与应用常驻进程一致的运行环境，并 在其中执行管理任务3 More Things23+ 1API优先默认您的代码将由前端、网关或其他服务使用+ 2遥测确保应用在云中的可观测性就像在你自己的电脑中一样+ 3验证/授权行为与身份动态管控，并附加防火墙、微分段等安全策略26datacenter/hybrid/public/edgedev/prototyping