顾宇-微服务的反思以及高效落地

Cersi

2018/05/13 发布于 技术 分类

从 2013 年加入 ThoughtWorks 至今共 4年时间。在这 4 年的时间里,我分别以 开发人员, DevOps 工程师、DevOps 咨询师、微服务架构师以及微服务咨询师的角色参与了共计 7 个产品和项目的微服务咨询和实施。其中有有成功,有失败,有反思,更多的是学习和总结。以下是我这些年来在微服务咨询上的经验总结,希望能给陷入微服务实施困境的人带来一些帮助。

文字内容
1. GOPS 全 球 运 维 ⼤大 会 2 0 1 8 2018.4.13-4.14 中国·⼴广东·深圳·南⼭山区 圣淘沙⼤大酒店(翡翠店) G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
2. 关于我 • 顾宇 • ThoughtWorks ⾼高级咨询师 • 四年年国内外微服务和 DevOps 咨询实施经 验 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
3. 当你听到微服务的感觉如何? ?????? ?????? 开⼼心 疑虑 ☹ 痛苦 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
4. 微服务落地反思以及⾼高效落地 顾宇 ThoughtWorks ⾼高级咨询师 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
5. ⽬目录 1 三个微服务案例例带来的反思 2 微服务落地的难点 3 ⾼高效落地微服务的五个步骤 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
6. 微服务项⽬目⼀一:Java 遗留留系统解耦 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
7. ⾯面对的问题 • 如何合理理的拆分应⽤用 • 如何设计好 API • 如何做到持续部署 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
8. 微服务就是持续部署 Restful API G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
9. 微服务项⽬目⼆二:某电信运营商 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
10. ⾯面对的问题 • 如何快速稳定的部署应⽤用 • 如何提⾼高团队的⽣生产率,特别是⾃自动化⽔水平 • 如何解除流程瓶颈,跨部⻔门协作 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
11. DevOps 做到极致就得到了了微服务 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
12. 微服务项⽬目三:某⼤大型 IT 集团云计算产品 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
13. ⾯面临的问题 • 如何缩短发布时间 • 如何独⽴立发布 • 微服务迟迟落不不了了地 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
14. 从组织结构的调整做微服务是有效的 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
15. 案例例的共同点 • 应⽤用和团队规模增⻓长 • 实践持续交付/DevOps • 在空间和时间上⽆无冲突发布 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
16. 如何⾯面对增⻓长 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
17. 成本拐点 —— 增加单位代码⾏行行的净收益 成本 单体应⽤用 成本极限 X’ 微服务应⽤用 X O1 O G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站 增⻓长极限 规模
18. 复杂性在扩⼤大你的管理理成本 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
19. 把微服务改造看做是对增⻓长极限的投资 成本 单体应⽤用 成本极限 X’ 微服务应⽤用 X O1 O G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站 增⻓长极限 规模
20. 微服务本质上在解决什什么问题? • 处于团队和应⽤用的⾼高增⻓长。 • 通过独⽴立部署和独⽴立发布提升整体交付效率。 • 在时间和空间上降低单⼀一代码库的应⽤用程序的冲突访问。 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
21. 什什么是微服务?- Chris Richardson 定义 • 是⼀一种架构⻛风格。 • 将松散耦合的服务组成⼀一个应⽤用程序。 • 使之能在⼤大型/复杂的应⽤用上应⽤用持续交付/部署。 • 能够使组织进化技术栈。 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
22. 什什么是微服务?- Martin Fowler/ James Lewis 定义 • 应⽤用程序作为⼀一组可独⽴立部署的服务套件。 • 没有精确定义,但有确定共同特征。 • 围绕组织,围绕业务 • ⾃自动化部署 • 智能的端点(Endpoint) • 去中⼼心化控制的编程语⾔言和数据。 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
23. 什什么是微服务?- Sam Newman 定义 • 微服务就是⼀一些协同⼯工作的⼩小⽽而⾃自治的服务。 • 专注:只做好⼀一件事。 • ⾃自治:可以独⽴立运⾏行行的实体。 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
24. 为什什么⽤用 Monolithic 和 Micro ? G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
25. ⼩小不不是优点,简单才是 如果你做的微服务越来越复杂,⼀一定是⾛走错了了路路! G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
26. 你为什什么要⽤用微服务? G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
27. ⽬目录 1 三个微服务案例例带来的反思 2 微服务落地的难点 3 ⾼高效落地微服务的五个步骤 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
28. 你有哪些微服务痛点? • 不不知道怎么拆? • 架构落地困难? • 管理理越来越复杂? • 技术栈不不知道该怎么选? • 团队不不知道该怎么组织? • 微服务应该怎么管理理? G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
29. 技术问题 vs ⾮非技术问题 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
30. 读《⼈人件》的反思 “也许 …… 软件系统的重要问题不不在于技术,⽽而 在于社会性因素。” “如果我们所⾯面对的问题天⽣生就属于社会学范畴, 再好的技术可能也提供不不了了什什么帮助。” G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
31. 微服务是⼀一个掩盖在技术问题之下的管理理问题 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
32. 没有意识到微服务是⼀一个组织转型问题 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
33. 现实并⾮非⼀一帆⻛风顺 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
34. 萨提亚改变模型 引⼊入微服务 介⼊入和辅导 反馈和强化 现有架构 ☹ 混乱 实践与整合 微服务架构 ☹ ?????? ?????? G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
35. 怎么才算⾼高效? • 从结果出发,找最短的距离。 • 最难的事情最优先解决。 • 低成本,低⻛风险。 • 杜绝浪费。 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
36. ⽬目录 1 三个微服务案例例带来的反思 2 微服务落地的难点 3 ⾼高效落地微服务的五个步骤 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
37. 步骤1. 以终为始,组建团队 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
38. 按照传统⽅方式,只会重蹈覆辙 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
39. ⼀一个⾃自治的全功能团队是什什么样? • 可以独⽴立发布微服务的团队。 • 1 名微服务经理理,解决流程依赖和⼲干扰。 • 2-4名开发/测试,专注于微服务开发和测试。 • 1-2个运维,⽤用来提供最快速的发布/部署。 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
40. 独⽴立的⼩小团队! • 避免依赖 • 提升技能 • 特事特办 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
41. ⼀一个微服务,⼀一个代码库,⼀一条流⽔水线。 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
42. 步骤1:组建微服务团队 • 为微服务建⽴立⼀一个全新的代码库,⽽而不不要从原先的代码库上克隆隆 或者复制,避免和原团队的开发依赖。 • 建设⼀一个独⽴立的持续交付流⽔水线,最好是通过“流⽔水线即代码技 术”(例例如 Jenkinsfile)来⾃自动⽣生成流⽔水线。 • ⼀一个微服务,⼀一个代码库,⼀一条流⽔水线。 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
43. 步骤 2:构建微服务电梯演讲 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
44. 步骤2:构建微服务的“电梯演讲” • (XX微服务)⽤用来 • (订单查询微服务)⽤用来 • 在(出现痛点的场景)的情况下 • 在(订单查询数量量快速)的情况下 • 解决了了(解决现有的某个题) • 从⽽而(达到什什么样的效果) • 提升了了(微服务的价值) • 解决了了(访问数量量迅速升⾼高导致整体 应⽤用性能下降的问题) • 从⽽而(分离了了订单查询请求) • 提升了了(提升了了其他功能的性能) G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
45. 不不要超过 15 秒 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
46. 挂到墙上 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
47. 形成共识 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
48. 步骤2:构建微服务的“电梯演讲” • 不不要超过 15 秒 • 把微服务的电梯演讲打印出来挂到墙上,让团队成员铭记于⼼心。 这会强化组织对微服务的边界认识。 • 随着团队的反思和学习,电梯演讲有可能会变更更,但⼀一定要让团 队形成共识好和⼀一致的意⻅见。 • 不不要期望⼀一次就能划分正确。划分是⼀一个持续学习和研究的过程。 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
49. 步骤 3:取得快速胜利利 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
50. 步骤3:取得快速胜利利 • 以最⼩小的代价发布第⼀一个微服务 • 给团队提升⼠士⽓气 • ⽬目标不不宜太⾼高 • ShowCase 驱动开发 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
51. ⽤用最⼩小代价发布第⼀一个微服务 • 最⼩小的代价: • 团队规模 (2~8⼈人) • 时间 ( 2~4周) • 选择代价较⼩小的技术栈 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
52. 特性开关(Feature Toggle ) G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
53. 单主⼲干开发 有分⽀支,就造成了了耦合。 给⾃自⼰己⼀一个不不做持续交付的借⼝口。 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
54. 步骤3:发布第⼀一个微服务 • 采⽤用动态特性开关(Feature Toggle),在发布后可以在⽣生产环境动态 的控制微服务的启⽤用,降低失败⻛风险。 • 如果采⽤用了了特性开关,⼀一定要设⽴立删除特性开关和对应旧代码的时间, ⼀一般不不超过两个⽉月。否则后⾯面⼤大量量的特性开关会带来管理理成本的提升和 代码的凌乱。 • 由于团队⽐比较⼩小,功能⽐比较单⼀一,不不建议采⽤用分⽀支来构建微服务,⽽而应 该采⽤用单主⼲干⽅方式开发。 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
55. 步骤4:取得快速胜利利 • 要防⽌止团队画⼤大饼,完成好每⽇日和每周的⼯工作⽬目标即可。微服务 开发本身就没有很⻓长周期。 • 除了了让第⼀一个微服务尽快发布到⽣生产环境,其它的不不要想太多。 给团队继续前进最⼤大的动⼒力力就是新服务快速投⼊入⽣生产。 • 完成了了的发布,然后要考虑如何对发布流程进⾏行行改进。⽽而不不是上 线业务。 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
56. 步骤4:代码未动,DevOps 先⾏行行 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
57. ⼯工程师很容易易陷到代码细节⾥里里 “不不好弄弄” “不不能搞” G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
58. 步骤4:代码未动,DevOps 先⾏行行 • 如果你的组织是 Dev 和 Ops 分离的组织,先咨询⼀一下 Ops ⼯工程 师的意⻅见。最好是能够给微服务团队⾥里里⾯面配备⼀一名 Ops ⼯工程师。 • 如果不不具备实施 DevOps 的条件,微服务架构就要从运维侧,⽽而 不不是开发侧开始进⾏行行。 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
59. 做 DevOps 就是做 CLAMS G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
60. ⼀一定要有度量量(Measure) G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
61. ⾃自动化-除了了代码提交和发布,⼀一切⾃自动化 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
62. 关键的⾃自动化 • ⾃自动化测试(功能/⾮非功能) • ⾃自动化基础设施管理理 • ⾃自动化部署(不不是发布) • ⾃自动化监控告警 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
63. 精益 - 通过可视化来发现问题 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
64. 构建分享和分担的理理念 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
65. 打造完整的 DevOps ⽂文化 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
66. DevOps 核⼼心实践 • 持续交付(蓝绿部署,灰度发布,⾦金金丝雀发布) • 基础设施即代码(资源配置,资源编排) • 基础设施对微服务是透明的 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
67. 步骤6:⾃自动化——管理理提示 • ⿎鼓励团队成员⾃自发的进⾏行行⾃自动化的改进,这会给未来微服务批量量 开发带来很多裨益。 • 不不要⼀一开始就追求全⾯面的⾃自动化,⾃自动化需要花费⼀一定时间。根 据团队的进度视情况适度进⾏行行。 • 建⽴立⼀一个确定的系统会导致系统本身⾃自愈能⼒力力的丧失。 • ⻛风险管理理不不是要消除⻛风险,是要当⻛风险发⽣生时有应对措施。 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
68. 5. 持续改进,复制成功经验 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
69. 知识的诅咒 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
70. 步骤5:复制成功经验 • 需要总结出来的关键产出: • 微服务开发到发布的端到端流程规范。 • 微服务开发的技术质量量规范。 • 团队合作中的坚持的最佳实践。 • 常⻅见技术问题总结。 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
71. 不不断改进 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
72. 团队交叉轮换 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
73. 步骤5:复制成功经验 • 刚开始的时候可以每周进⾏行行⼀一个回顾会议,团队需要快速的反馈和调整 • 不不要急于扩张团队,要在成功经验稳定并形成模式之后再快速扩充。 • 避免微服务良好的开发氛围被稀释,刚开始的时候扩充团队可以慢⼀一点。 新⽼老老成员的配⽐比不不要超过1:1。 • 虽然微服务平台趋于稳定,但在微服务没有上规模之前,不不要让团队⾥里里 缺少 Ops 成员。 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
74. ⾼高效落地微服务的 5 个步骤 1. 以终为始,构建微服务团队 2. 构建微服务的电梯演讲 3. 取得快速胜利利,发布第⼀一个微服务 4. 代码未动,DevOps 先⾏行行。 5. 复制成功经验 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
75. 微服务,⼀一本书就够了了 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
76. Thanks ⾼高效运维社区 开放运维联盟 荣誉出品 G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站
77. 想第⼀一时间看到⾼高效运维社区 的新动态吗? G O P S 全 球 运 维 ⼤大 会 2 0 1 8 · 深 圳 站