微服务转型的注意事项远比你想象的多
Posted WOT技术大会
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了微服务转型的注意事项远比你想象的多相关的知识,希望对你有一定的参考价值。
老式的单体应用程序正逐步被微服务分解和取代。大大小小的企业都在进行这种转型,但这并不意味着转型就很容易。在企业进行微服务转型的过程中是存在诸多挑战的,但有一些选择可以简化工作。
转型原因
企业向微服务转型出于几个原因。一个应用程序被分解成小块后,测试起来更容易、部署起来更快速。这种模块化还为开发人员和团队带来了范围更明确的职责。
然而,即使最积极、最能干的公司也需要关注以下几个重要的问题,才能确保成功转型:
在重写大量代码时如何保持质量?
如何理解所有活动组件?
如何观察自己的环境?
如何监测影响?
这些问题的答案归结为两大方面:可观察性和监测。虽然许多开发人员将两个术语混为一谈,但两者之间还是存在一些细微的差别的。
可观察性首先出现在整条链路中。系统或应用程序必须是可观测的,之后才能被监测。实际上,这意味着需要安装操作系统层面的服务或代理,而对应用程序而言,则需要公开端点。一旦公开了关键信息,就可以对其进行监测。监测告诉您哪些内容损坏了(或即将损坏)、以及其中的损坏原因。
注意事项
从单体架构向微服务转型应对用户透明。为了实现这个目标,您的监测系统需要考虑一些关键问题。
是否可以通过提供足够的正常运行时间和可用性,满足客户的需求?
应用程序响应速度是否够快?
发现问题并排除问题需要多久?
开发人员如何管理变更?
不妨让我们更详细地了解以一下这些问题、以及如何应对它们:
1. 是否可以通过提供足够的正常运行时间和可用性,满足客户的需求?
在大多数情况下,对于目前的单体应用程序,您已经有了这个问题的答案。接下来将介绍的是面向客户的应用程序的正常运行时间,以及部署或计划外中断导致的停机时间。
就微服务而言,跟踪正常运行时间与单体程序很相似,但在开发“关键路径”微服务时需要确定更多的数据点。比如说,如果将登录逻辑提取为单独的微服务,前端微服务的可用性可能会上升。然而,登录服务停机时间将对您的用户产生重大影响。
换句话说,这个问题的答案对于微服务来说比较复杂,但是适当的工具和从始至终跟踪请求的能力将帮助您实现这一目标。
2. 应用程序响应速度是否够快?
在单体应用程序中,活动组件更加靠近——所有组件都在同一环境中。但在微服务中,由于请求不再通过单体应用程序来传输,而是可能向不同的微服务生成多个请求,因此向分布式微服务转型将影响应用程序的响应能力。
为了解决这个问题,您需要监测自己的应用程序和基础设施,专注于监测技术管理结构中的智能化和可视化。通过获取从请求到结果的指标,并通过多个微服务和系统对其进行跟踪,能够为您提供所需的见解和答案。
3. 发现问题并排除问题需要多久?
单体应用程序中的一个重大问题可能会使整个系统陷入停顿。然而,当系统建立在解耦和模块化的微服务架构上时,其中的问题可能是潜伏性的,这将更加难以发展。
快速识别问题的能力需要可观察性和监测的共同支持。因此,微服务的组件需要可观察性,以便对其进行监测。而在出现问题时,需要警告提供详细信息,以缩短排除和解决故障的时间。比如说,没有其他信息的“CPU使用率高”警报几乎没有用处。但如果警报显示“在X时间段内系统上的CPU使用率持续保持高位”,并有能够显示过去几分钟内进程使用大量CPU资源的视图。这种警报会大大缩短解决故障的时间。
4. 开发人员如何管理变更?
开发人员的情绪可能难以衡量,但这非常重要。减员在企业生命周期的任何阶段都是一种风险,尤其是当您正在进行重大转型时,减员对企业的影响将更加显著。
解决这个问题的最简单方法是,是通过与相关团队进行非正式对话,或者对开发人员进行较正式的调查。即便您开发团队中的大部分人都感受到了单体架构的弊端,并希望进行这种转型,但了解团队中每个开发人员的想法仍非常重要。
工具帮助
工具很重要,这点毫无疑问。工具有助于确定和衡量服务级别指标(SLI),这些指标会影响您的服务级别目标(SLO)。借助良好的工具,您可以实现快速的启动运行,并减少麻烦。
向微服务转型应该会对您的SLI/SLO带来积极的影响,但若要做到胸有成竹,唯一的办法是借助良好的可观察性、更好的监测,以及对环境整体的了解。
自建or开源
决定使用哪些工具时,许多企业的本能反应是自己搞。毕竟,没有人比自己的开发人员或SRE团队更了解本企业的可观察性和监测需求?事实上,“自己搞”工具(尤其是要做到有效和准确)困难重重,且容易出错。大多数选择自己开发工具的企业,都会后悔走这条艰难的道路。
另外的选择是走开源路线。Prometheus + Jaeger + Grafana架构可满足您在转型期间的大部分需求。
在这种架构中,您将使用安装在系统上或作为库包含在应用程序代码中的Prometheus客户端。客户端捕获指标后将其公开,供Prometheus服务器抓取并存储在时序数据库中。
Jaeger执行分布式跟踪,为通过微服务系统的事务捕获指标和数据。
同时,Grafana与Prometheus和Jaeger数据源一起提供可视化和仪表板。
这种开源架构让您有机会根据需要来修改和配置工具。它还可能直接支持一些基本的使用场景。当然其缺点是,对于每个工具,您都需要紧跟版本,更新安全补丁及配置变动。此外,开源解决方案常常会在以后带来扩展方面的难题。随着更多微服务不断构建,管理软件和存储遥测数据的成本都会上升。因此在选择工具时,建议企业还是要从自身需求角度出发。
总结
当企业从单体架构像微服务转型时,所面临的挑战是确保顺利转型,同时自始至终保持(或提高)应用程序的质量。而在这个过程中,可观察性和监测是保持质量的关键。
原文链接:
https://dzone.com/articles/how-to-maintain-quality-when-transitioning-from-mo
以上是关于微服务转型的注意事项远比你想象的多的主要内容,如果未能解决你的问题,请参考以下文章