More Related Content
Similar to microservice-and-12factor.pdf
Similar to microservice-and-12factor.pdf (20)
microservice-and-12factor.pdf
- 2. 微服务与 12-Factors • 目标：通过这个课程你可以认识到什么是微服务？运用微服务架构 之后凸显的一些问题和应对方法，以及 Kubernetes 可以如何解决 这些问题。 • 时长：2小时 • 面向群体：项目经理、架构师、运维人员、开发人员
- 3. 微服务的神话
- 5. 业务压力凸显了单体架构的一些缺陷 • 为了更新系统的一小部分，必须重新部署整个应用 • 很难采用新的技术或框架，因为所有的功能都构建在相同的技术之上 • 个别服务不稳定会导致整个应用挂起 • 在单体应用中应用敏捷方法论非常困难
- 6. 微服务给我们的承诺 我们采用微服务架构的原因 • 独立扩展 • 独立升级 • 易于维护 • 技术独立性 • 故障和资源隔离 Account Service 扩展：新增实例 Inventory Service 独立升级 golang java
- 10. 微服务对运维提出了更高的要求 • 服务复制 • 服务发现 • 服务可观测 • Health • Metrics • Trace • 弹性 • CI/CD • CI - 自动编译，部署到测试环境并测试 • CD – Delivery & Deployment • Deployment • 蓝绿
- 11. Kubernetes 给了一些工具，但还不够 • 服务复制 • 服务发现 • 服务可观测 • Health • Metrics • Trace • 弹性 • CI/CD • CI - 自动编译，部署到测试环境并测试 • CD – Delivery & Deployment • Deployment • 蓝绿 Service ReplicaSets Liveness / Readiness Probe Prometheus Istio+Trace ReplicaSets Autoscaling Deployments Deployments 看看实际的案例…
- 13. 每个环境下的前端应用都需要重新编译 配置 源代码 开发环境 前端应用 开发环境 测试环境 测试环境 构建 生产环境 生产环境 1. 每个环境重新编译可能会因为不易察觉的差异引发问题 2. 构建阶段需要知道生产的配置，不利于权限控制 3. 有些前端构建非常耗时，会影响应用的可用性
- 15. 单 Git 仓库多服务（模块）让持续交付变复杂 目录 源代码 各个环境 构建 多个服务使用同一个代码仓库，给版本控制带来了一些干扰，也让持续交 付工作变得复杂 模块1 模块2 模块3 模块1 模块2 模块3
- 16. Kubernetes 不是银弹
- 17. 何为 12-Factors Heroku 是 PAAS 平台的先驱，通过多年的实践，Heroku 的工程师们 总结出了 12-Factors。一个应用如果遵守了 12-Factors，便可以更好 的运行在 Heroku 平台。这对 Kubernetes 或其他 PAAS 平台也是一 样的。
- 18. 建立PAAS上应用的12-Factors 1. 单一代码基 2. 显式声明依赖关系 3. 配置 4. 后端服务 5. 区分构建、发布和运行三个阶段 6. 进程 7. 端口绑定 8. 并发 9. 易处理 10.开发环境与线上环境等价 11.日志 12.管理进程
- 19. 单一代码基 一份基准代码（codebase），多份部署（deploy） ● 基准代码和应用之间总是保持一一对应的关系： ● 一旦有多个基准代码，就不能称为一个应用，而 是一个分布式系统。分布式系统中的每一个组件 都是一个应用，每一个应用可以分别使用 12- Factors 进行开发。 ● 多个应用共享一份基准代码是有悖于 12- Factors 原则的。解决方案是将共享的代码拆分 为独立的类库，然后使用 依赖管理 策略去加载它 们。
- 20. 显式声明依赖关系 ● Manifest中显式声明依赖 ● 使用隔离工具 ● 指明版本 ● 避免使用shell来关联系统工具 ● Python – pipenv(pip+virtualenv) ● Java – maven ● .Net – nugget ● Node – NPM ● 环境 – Docker
- 21. 配置 将配置存到“环境”，而不是代码、属性文件、构建或应用服务器 ● 保证应用中不包含配置 ● Git 中不包含配置(主要指的是代码的 Git 仓库) ● 使用环境变量 小测试： 敢不敢今天 就把代码开源？ ConfigMaps & Secrets
- 23. 区分构建、发布和运行三个阶段 基准代码 转化为一份部署(非开发环境)需要分为三个阶段 ● 构建( Build )阶段 是指将代码仓库转化为可 执行包的过程。构建时会使用指定版本的代 码，获取和打包 依赖项，编译成二进制文件 和资源文件。 ● 发布( Release )阶段 会将构建的结果和当 前部署所需 配置 相结合，并能够立刻在运 行环境中投入使用。 ● 运行( Run )阶段 （或者说“运行时”）是 指针对选定的发布版本，在执行环境中启动 一系列应用程序 进程。 每一个发布版本必须对应一个唯一的发布 ID，例如指定的版本号，也可以使用发 布时的时间戳（2011-04-06-20:32:17），亦或是一个增长的数字（v100）。发 布的版本就像一本只能追加的账本，一旦发布就不可修改，任何的变动都应该产 生一个新的发布版本。 有了这几个阶段会 有什么好处？
- 24. 区分构建、发布和运行三个阶段 Kubernetes 的实现方式 ● build – 构建镜像 ● Release – 设置镜像版本号，修订 Helm Charts 文件 ● Run – helm install / helm upgrade
- 26. 端口绑定 执行环境控制监听的端口 ● 12-Factor 应用完全自我加载 而不依赖于任何网 络服务器就可以创建一个面向网络的服务。互联 网应用 通过端口绑定来提供服务 ，并监听发送至 该端口的请求。 Service
- 27. 并发 通过进程模型进行扩展 ● 进程是一等公民 ● 将工作赋予不同类型的进程（web，db， worker） ● 进程不需要 daemonize 或写 pid 文件 ● 使用系统进程管理 Deployment
- 28. 易处理 快速启动和优雅终止可最大化健壮性 ● 可以瞬间开启或停止。这有利于快速、弹性的伸 缩应用，迅速部署变化的 代码 或 配置 ，稳健的 部署应用。 我们的应用易处理吗?
- 29. 开发环境与线上环境等价 尽可能的保持开发，预发布，线上环境相同 传统应用 12-Factors 应用 每次部署间隔 数周 几小时 开发人员 vs 运维人员 不同的人 相同的人 开发环境 vs 线上环境 不同 尽量接近 这就是 DevOps 吧…
- 30. 日志 把日志当作事件流 ● 不要将日志存储到文件 ● 而是写到stout，由环境决定如何处理 stdout Conainer stdout 日志服务 Kubernetes 最佳实践
- 31. 管理进程 后台管理任务当作一次性进程运行 ● 运行数据迁移 ● 运行一个 console 来执行一些代码或是针对线上 数据库做一些检查 ● 运行一些提交到代码仓库的一次性脚本 ● 一次性管理进程应该和正常的 常驻进程 使用同样的环境 ● 所有进程类型应该使用同样的 依赖隔离 技术 ● 应用代码应该伴随管理代码