极客视点
极客时间编辑部
极客时间编辑部
113245 人已学习
免费领取
课程目录
已完结/共 3766 讲
2020年09月 (90讲)
时长 05:33
2020年08月 (93讲)
2020年07月 (93讲)
时长 05:51
2020年06月 (90讲)
2020年05月 (93讲)
2020年04月 (90讲)
2020年03月 (92讲)
时长 04:14
2020年02月 (87讲)
2020年01月 (91讲)
时长 00:00
2019年12月 (93讲)
2019年11月 (89讲)
2019年10月 (92讲)
2019年09月 (90讲)
时长 00:00
2019年08月 (91讲)
2019年07月 (92讲)
时长 03:45
2019年06月 (90讲)
2019年05月 (99讲)
2019年04月 (114讲)
2019年03月 (122讲)
2019年02月 (102讲)
2019年01月 (104讲)
2018年12月 (98讲)
2018年11月 (105讲)
时长 01:23
2018年10月 (123讲)
时长 02:06
2018年09月 (119讲)
2018年08月 (123讲)
2018年07月 (124讲)
2018年06月 (119讲)
时长 02:11
2018年05月 (124讲)
时长 03:16
2018年04月 (120讲)
2018年03月 (124讲)
2018年02月 (112讲)
2018年01月 (124讲)
时长 02:30
时长 02:34
2017年12月 (124讲)
时长 03:09
2017年11月 (120讲)
2017年10月 (86讲)
时长 03:18
时长 03:31
时长 04:25
极客视点
15
15
1.0x
00:00/05:21
登录|注册

5个规则,确保你的微服务优化运行

讲述:初明明大小:4.90M时长:05:21
你好,欢迎收听极客视点。
最近几年好像大家都开始对微服务着迷,而一旦你开始使用微服务架构,也许你需要一些规则,帮助你成功运行它们。最近,公众号 “RancherLabs”分享了微服务优化运行的 5 个挑战及应对规则,供你参考。

挑战 1:似乎很难监控整体

在容器化应用中,回滚一个“坏”版本的过程复杂许多。无论你是将单体应用逐步分解为微服务,还是从头开始构建一个新系统,你现在都有更多的服务需要监控。其中每一个都可能会:
使用不同的技术和 / 或语言
运行在不同的机器和 / 或容器上
使用 K8s 或类似的技术进行容器化和编排
此时,不再有一套单一的运维指标能够适用于高度分散的系统。团队现在必须处理数以百计甚至数以千计的指标、事件和告警类型,他们需要从中分离出有效信号和无效噪音。

解决方案

DevOps 监控需要从扁平化的数据模型转向分层模型,在这种模型中,可以随时观察到一系列高级系统和业务 KPI。只要有一点偏差,团队就必须能够进入指标层次结构,查看干扰来自于哪个微服务,并从那里了解实际发生故障的容器。这很可能需要从数据存储和可视化的角度重新调整 DevOps 工具链。开源的时序 DB 工具,诸如 Prometheus 和 Grafana 7.0 等使得这个目标非常容易实现。

挑战 2:跨服务日志记录

服务器每天都会产生的 IT 日志相当于碳的排放量,最终导致了溢出的硬盘驱动器以及疯狂摄取、存储和工具成本。
使用微服务,日志变得更加分散。一个简单的用户业务现在可以通过许多服务进行,所有这些服务都有自己的日志记录框架。要解决问题,你必须从业务可能通过的所有服务中提取所有不同的日志,以了解问题所在。

解决方案

这里的主要挑战是了解单个业务如何在不同服务之间“流动”。为了实现这一点,需要对传统的单体程序在顺序业务执行期间记录事件的方式进行大量修改。尽管已经出现了许多框架来帮助开发人员进行处理,但对于希望将单体重构为微服务的企业而言,转向异步、跟踪驱动的日志记录仍需要付出艰巨的努力。

挑战 3:部署一项服务会破坏另一项服务

由于微服务本质上是相互交织的,其中一个服务细微的变更可能会导致行为或性能问题,而这些问题会在另一个服务中体现出来。因此所面临的挑战是,当前出现故障的微服务使得另一个开发团队并没有预料到他们的代码会出现中断。这既会导致整个应用意外的不稳定性,也会导致一些组织内部的摩擦。虽然微服务架构可能让部署代码的过程变得更容易,但实际上却让部署后验证代码行为的过程变得更难。

解决方案

企业必须创建共享的发布日历,并且每当部署相关的微服务时,都要分配资源用于密切测试和监控整个应用的行为。

挑战 4:难以找到问题的根本原因

在这一点上,你已经锁定了有问题的服务,提取了所有需要提取的数据,包括堆栈跟踪和日志中的一些变量值,但你很难找到问题的根本原因。通常这需要发出关于每个失败事务状态的详细信息(即到底为什么失败)。这里的挑战是,需要开发人员具有巨大的预见性,以知道他们需要哪些信息来提前排除问题。

解决方案

当微服务中的错误根源横跨多个服务时,制定一个集中的问题根源检测方法至关重要。团队必须考虑需要哪些信息颗粒来诊断未来的问题,以及它们应该在什么层级上发出日志,以考虑到性能和安全因素。

挑战 5:版本管理

我们认为值得强调的问题是,从典型的单体架构中的层模型过渡到微服务的图模型。由于超过 80%的应用程序代码通常是第三方代码,因此在公司的不同微服务之间管理第三方代码的共享方式成为避免陷入前所未有的“依赖地狱”的关键因素。
而且,任何一个微服务使用第三方代码的旧版本、更脆弱的版本,都会产生安全问题。允许不同的团队在孤岛般的 repo 中管理他们的依赖性,在单体世界中可能是可行的,但在微服务架构中,这是绝对不可以的。

解决方案

公司必须在重新设计他们的构建流程方面进行投资,以便为第三方和共享实用程序代码利用集中式 artifact 仓库(Artifactory 将是其中之一)。团队应该只允许将自己的代码存储在单独的仓库中。
从以上这五个主要挑战来看,它们都源于同一个理念,微服务所带来的优势是难以拒绝的,但风险也是巨大的。
关于微服务各环节的原理及实践,《从 0 开始学微服务》专栏讲解了很多,可以帮助你更好地理解并上手微服务。以下是这个专栏的目录,供你参考。使用极客视点专属口令,还可以享受立减优惠。
优惠口令:weifuwu11
适用规则:立减 6 元(满 40 元可用)
有效期:8 月 14 日 -8 月 21 日
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结
该免费文章来自《极客视点》,如需阅读全部文章,
请先领取课程
免费领取
登录 后留言

精选留言

由作者筛选后的优质留言将会公开显示,欢迎踊跃留言。
收起评论
大纲
固定大纲
挑战 1:似乎很难监控整体
解决方案
挑战 2:跨服务日志记录
解决方案
挑战 3:部署一项服务会破坏另一项服务
解决方案
挑战 4:难以找到问题的根本原因
解决方案
挑战 5:版本管理
解决方案
显示
设置
留言
收藏
32
沉浸
阅读
分享
手机端
快捷键
回顶部