在最近一次 QCon 伦敦大会上，来自于英国政府电子服务（GDS）的技术架构师 Michael Brunton-Spall 表达了他对于 DevOps 模式对于成功的微服务运维的重要性的看法。Brunton-Spall 指出了识别一个微服务的关键因素，介绍了如何创建第一个微服务的过程，以及管理微服务生态系统所必不可少的工具和实践。
微服务必定是一个小型服务，并且能够自己管理数据，而不与任何类型的数据库进行集成。所有数据必须通过公开接口的方式进行共享，遵循“哑管道与智能端点”（dumb pipes / smart endpoints）的方式。每个微服务必须有一个拥有者，也只能有一个，那就是拥有这个服务全部代码与运行时的团队。Brunton-Spall 对于 Jeff Sussna 的以下观点表示同意：
微服务不仅表现出一种新型的架构模型，同样也表现出一种新型的组织模型。
这种新型的组织模型也意味着开发人员和运维的角色发生了变化，开发者将承担起微服务整个生命周期的责任，而运维则越来越多地表现出一种顾问式的角色。
Brunton-Spall 建议刚刚启动微服务的团队可以先将规模控制在较小的范围内。一个组织应当先从一个微服务开始，确保它应用了正确的支持工具与实践。这些建议使用的工具和实践也是 DevOps 社区中所讨论过的相同内容：易于使用与集成的自动化基础设施、自动部署、日志聚合和监控工具，以及良好的警报实践。
从一个微服务升级到多个微服务，将要面对一组新的挑战，它们主要是与不断增加的错误诊断的复杂度相关的。正如 Brunton-Spall 所说：
与相同规模的整体性架构相比，微服务的失败会显得更加触目惊心。
要理解在微服务之间产生的复杂交互，需要优秀的诊断与监控工具。在 QCon 伦敦大会上每一场有关于微服务的演讲中几乎都强调了监控的重要性。Brunton-Spall 特意区分了浅度监控：“我的服务运行正常吗？”，与深度监控：“我的服务与它的依赖都运行正常吗？”。虽然后者的考虑更全面，但它也可能会引起一种层叠式的警报，而使得问题的真正根源变得模糊不清。如果某个微服务被许多其它微服务引用，当它产生故障时就有可能造成以上问题。
还有两点也是在许多场合中经常强调的，一是在设计微服务时要考虑到故障的情况，二是要提供一个统一的管理界面。比方说，应该有一种通用的方式，可以触发某个微服务产生断路。 TwitterServer 就为这种方式提供了一个示例。
如果你的组织中已有着完善的部署审计流程，那么就应该为开发者分配传呼机与部署机房的钥匙。传呼机能够让开发者感受到因他们自己的错误所带来的痛苦，确保了对重复性问题的快速修复。但这些对于一个成熟的支持流程来说还不够。比方说，Brunton-Spall 问道，如果开发者感到“厌倦”并选择离开，该怎么办？又或者团队解散了又该怎么办？第一线的支持与检验依然是必不可少的。需要一种成熟的支持模型对这种移交的规则进行定义，例如：“系统在 M 个星期内的错误必须小于 N，并且在移交时必须提交运行手册”。
简单的解决方案能够促成优秀的微服务运维实践。Brunton-Spall 提到了他在 The Guardian 工作时的案例，这是他在 GDS 之前所任职的公司。最初的服务器上线流程中只包含了一个基础的 Ubuntu 镜像。在上线脚本中包含了几行 bash 脚本代码，用于通过“apt-get”命令获取包。此外还有一个 wget 命令，用于下载某个 JAR 文件并开始执行。
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论