全球运维技术大会

上海 CNUTCon 一次微服务架构决策的案例

1. 什什么时候不不该⽤用微服务? 记⼀一次微服务架构决策的案例例 顾宇 埃森哲 技术咨询经理理
2. • 咱们聊的是不不是同⼀一个微服务? • ⼀一个架构演进的案例例 • ⼀一个应⽤用的四种部署⽅方案 • 微服务实施的反思 2
3. 咱们说的微服务是同⼀一回事吗?
4. James Lewis
5. “A single capability composed of many small applications and exposing a uniform interface of Atom Collections.” ⼀一个有很多⼩小应⽤用并采⽤用统⼀一接⼝口暴暴露露原⼦子集合的单独应⽤用。 • Small with a single responsibility • ⼩小⽽而单⼀一的责任 • Containerless and installed as well • 不不需要容器器,和 UNIX 系统服务⼀一样 behaved Unix services 的安装⽅方式 • Located in different VCS roots • 放置在不不同的版本控制系统中 • Provisioned automatically • ⾃自动初始化 • Status aware and auto-scaling • 关注状态并⾃自动扩展
6. Martin Fowler “While there is no precise definition of this architectural style, there are certain common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data. ” “虽然没有准确的微服务定义,但有⼀一些确 定的特征围绕组织围绕业务能⼒力力,⾃自动化 部署,智能的端点和去中⼼心化的语⾔言和数 据控制。” 我就笑笑,不不说话 https://martinfowler.com/articles/microservices.html
7. “Microservices are small, autonomous services that work together.” “微服务是在⼀一起⼯工作的⼩小的,⾃自治的服务。” Sam Newman 单⼀一责任原则 ⽣生命周期⾃自管理理
8. 围绕业务领域建模 ⾃自动化的⽂文化 隐藏实现细节 Sam Newman ⾼高度可观察性 微服务的原则 去中⼼心化所有事情 隔离失败 独⽴立部署 https://samnewman.io/talks/principles-of-microservices/
9. Microservices - also known as the microservice architecture - is an architectural style that structures an application as a collection of loosely coupled services, which implement business capabilities. The microservice architecture enables the continuous Chris Richardson delivery/deployment of large, complex applications. It also enables an organization to evolve its technology stack. “微服务,也就是微服务架构。是⼀一种架构⻛风格把⼀一个应⽤用程序结构 化为⼀一个实现业务功能的松散耦合的服务集合。 微服务架构使得在⼤大型、复杂的应⽤用程序中实现持续交付和持续部署 成为可能。它使得组织可以进化⾃自⼰己的技术栈。” https://microservices.io/
10. 微服务共识
11. 微服务共识 分布式系统 单⼀一责任 松散耦合 ⾃自动化部署
12. 你为什什么需要微服务?
13. 微服务本质上要⼲干⼀一件什什么事?
14. AKF 扩展⽴立⽅方 https://akfpartners.com/growth-blog/scale-cube/
15. 维护成本 成本极限 O2 O1 O 单体应⽤用 X’ 微服务应⽤用 X S1 S2 增⻓长极限 规模
16. • 咱们聊的是不不是同⼀一个微服务? • ⼀一个架构演进的案例例 • ⼀一个应⽤用的四种部署⽅方案 • 微服务实施的反思
17. 命题1:在 AWS 上构建⼀一个 Wordpress 应⽤用
18. 当然,事情不不会这么简单
19. ⾼高可⽤用 负载均衡 安全 ⾃自动化 稳定 灵活 真实的架构要更更加复杂
20. 最重要的⼀一点:对开发友好
21. 外部⽤用户 应⽤用/内容/平台 的分离 应⽤用 内容 平台 内部作者 开发 运维
22. 应⽤用流⽔水线 提交 测试 构建 部署 发布 部署 发布 UAT 环境 ⽣生产环境
23. 基础设施流⽔水线 CDN 负载均衡 虚拟机 监控告警 容器器资源 监控告警策略略 虚拟机 容器器 集群管理理 容器器编排 ⾃自动扩展组 ⽹网络 数据库
24. link link
25. 命题2:当你的架构开始演进 外部⽤用户
26. • 咱们聊的是不不是同⼀一个微服务? • ⼀一个架构演进的案例例 • ⼀一个应⽤用的四种部署⽅方案 • 微服务实施的反思
27. ⽅方案⼀一:分离变更更 外部⽤用户 内部⽤用户
28. 优点 • 关注点分离,不不需要变更更原有代码。 • “对扩展开放,对修改封闭” • 前端路路由 Over 后端路路由 • 后端随时可抛弃 。
29. 缺点 • ⼀一个代码库,构建两条流⽔水线,构 建两个镜像。 • 开发⼈人员需要在本地启动⼀一套后端。 • 部署存在依赖。 • 前端不不能按需扩展。
30. 总结 • 根据组件的变更更频率来拆分是很有效的⼿手段。 • 基础设施和应⽤用架构都要做到对“扩展开放,对修改封闭。” • 对应⽤用变更更带来的影响隔离的越⼩小,越精确,架构越稳定。 • “任何软件⼯工程中遇到的问题都可以⽤用⼀一个中间层解决”
31. ⽅方案⼆二:前后端分离 内部⽤用户 外部⽤用户
32. 优点 • 前端可以按需扩展。 • 隐藏后端细节。 • 前后端分离更更加彻底。
33. 缺点 • 经常需要调整反向代理理配置。 • 后端更更新稳定性较差。 • 部署时间较⻓长。
34. 总结 • 依赖链越⻓长,其中各个节点的运维⻛风险就越⼤大。 • 前后依赖的兼容性问题就很突出。 • 从安全的⻆角度来说,为后端隐藏了了细节。 • 不不容易易测试。
35. 外部⽤用户 ⽅方案三:微服务 内部⽤用户
36. 优点 • 各个组件独⽴立部署,⻛风险隔离。 • 减少开发的阻塞。 • ⽅方便便单个测试。
37. 缺点 • 基础设施更更加复杂,维护成本 和开发成本很⾼高。 • 需要更更多的端到端测试,增加了了 测试代价。 • 形成了了更更多的依赖。 • 本地开发环境不不易易搭建。
38. 总结 • 组件的开发维护单元要和团队结构匹配。 • 每个微服务需要团队⾃自部署,要求会很⾼高。 • 强依赖拆分后,会分散运维的注意⼒力力。 • 组件隔离的代价不不菲,需要更更加⾃自动化的基础设施。
39. ⽅方案四:单体应⽤用 内部⽤用户 外部⽤用户
40. 优点 • 开发和部署⾼高度⼀一致。 • 本地开发环境易易搭建。 • 易易维护。 • 开发测试运维成本低。
41. 缺点 • 部署成本较⾼高。 • 开发阻塞。 • 各组件⽆无法按需扩展。
42. 总结 • 把开发成本和运维成本放在⼀一起看。 • 软件复杂度受制于团队规模。团队越⼤大,需要对⻬齐的信息越多。 • 微服务的重点是复杂度治理理,⽤用团队规模约束复杂度。
43. 单体应⽤用也可以做到独⽴立开发, 独⽴立部署。
44. 等等,这和微服务定义好像⼀一致!
45. 微服务的“微”是⼀一个相对概念, 它和由组织的规模决定。
46. 微服务最⼤大的便便利利性是 服务之间的开发和运维相互独⽴立。 减少开发阻塞 降低运维⻛风险
48. 应⽤用程序变更更的局部性假设 开发的局部性假设:在运⾏行行着的应⽤用系统中,维护所做的⼯工作是对应⽤用系统的 局部进⾏行行开发。因此,对整个开发团队应该只产⽣生局部性的影响。 运维的局部性假设:在运⾏行行着的应⽤用系统中,由于局部的变更更,应该只产⽣生局 部性的⻛风险和影响。 以上两个假设有⼀一个约束:由于局部性的开发导致的综合成本。均⼩小于重新开 发整个系统的整体成本。
49. 如果你的应⽤用架构是微服务架构 微服务测试:任意应⽤用的局部变更更均产⽣生局部性的影响。 运维的局部性假设:运⾏行行时的维护关注点局部性使得独⽴立开发的局部性成为可 能。
50. 微服务是 DevOps 做到极致后的结果
51. • 咱们聊的是不不是同⼀一个微服务? • ⼀一个架构演进的案例例 • ⼀一个应⽤用的四种部署⽅方案 • 微服务实施的反思
52. ⽅方案⼀一 ⽅方案⼆二 ⽅方案三 ⽅方案四 ⽅方案评估矩阵 独⽴立开发 依赖 独⽴立部署 基础设施复杂 度 开发成本 前端耦合 低 前后端 中 低 维护成本 中 后端耦合 中 前后端 ⾼高 中 中 全部独⽴立 低 各组件之间 ⾼高 ⾼高 ⾼高 全部耦合 ⾼高 整体 低 中 低
53. ⽅方案⼀一:分离变更更 外部⽤用户 内部⽤用户
54. 外部⽤用户 ⽅方案三:微服务 内部⽤用户
55. 维护成本 成本极限 O2 O1 O 单体应⽤用 X’ 微服务应⽤用 X S1 S2 增⻓长极限 规模
56. 反思1:不不能不不计成本的使⽤用微服务 • 投⼊入太⼤大,⻛风险未知。 • 微服务更更多是基础设施带来的成本。 • 开发团队结构决定应⽤用架构。
57. 反思2:基础设施的管理理 • 基础设施的⾃自动化程度在微服务架构中起了了决定性作⽤用。 • 基础设施对开发者和应⽤用要更更加透明。 • 基础设施的变更更对开发⼈人员的阻塞更更加致命。
58. 反思3:DevOps ⽅方式 • 微服务的成功很⼤大程度上依赖 DevOps 的能⼒力力。 • 微服务是要对开发和运维双重解耦。 • 提升部署效率的同时,兼顾整体应⽤用的稳定性。 • 把开发和运维的成本放到⼀一起看。
59. 反思4:⼀一步到位的微服务策略略不不可取 • 根据组织结构进⾏行行演进,架构是⼈人员复杂度提升带来的问题。 • 从减少依赖的⻆角度考虑演进。 • “对扩展开放,对修改封闭”。 • 追求职责独⽴立,⻛风险隔离的设计。