微服务转型的注意事项远比你想象的多

2022年3月26日 379点热度 0人点赞 0条评论
图片

作者丨Michael Bogan

译者丨布加迪

策划丨徐杰承


老式的单体应用程序正逐步被微服务分解和取代。大大小小的企业都在进行这种转型,但这并不意味着转型就很容易。在企业进行微服务转型的过程中是存在诸多挑战的,但有一些选择可以简化工作。

转型原因



企业向微服务转型出于几个原因。一个应用程序被分解成小块后,测试起来更容易、部署起来更快速。这种模块化还为开发人员和团队带来了范围更明确的职责。


然而,即使最积极、最能干的公司也需要关注以下几个重要的问题,才能确保成功转型:


  • 在重写大量代码时如何保持质量?

  • 如何理解所有活动组件?

  • 如何观察自己的环境?

  • 如何监测影响?


这些问题的答案归结为两大方面:可观察性和监测。虽然许多开发人员将两个术语混为一谈,但两者之间还是存在一些细微的差别的。


可观察性首先出现在整条链路中。系统或应用程序必须是可观测的,之后才能被监测。实际上,这意味着需要安装操作系统层面的服务或代理,而对应用程序而言,则需要公开端点。一旦公开了关键信息,就可以对其进行监测。监测告诉您哪些内容损坏了(或即将损坏)、以及其中的损坏原因。

注意事项


从单体架构向微服务转型应对用户透明。为了实现这个目标,您的监测系统需要考虑一些关键问题。


  • 是否可以通过提供足够的正常运行时间和可用性,满足客户的需求?

  • 应用程序响应速度是否够快?

  • 发现问题并排除问题需要多久?

  • 开发人员如何管理变更?


不妨让我们更详细地了解以一下这些问题、以及如何应对它们:


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



直播预告

随着 Flutter 进入 2.0 版本,成为跨平台开发的热门宠儿,国内外许多大小公司、项目团队已经接入了 Flutter。Flutter 还在不断蓬勃发展当中,不断积累丰富着自己的技术生态内容,如何更好地了解Flutter


2022 年 3 月 27 日(周日)14:00-16:00Flutter 高级工程师,开源项目 Keframe 作者杜俊达携行业技术大咖为你带来满满干货!


直播间还会抽取价值5800元WOT全球技术峰会及精美礼品,点击下方卡片即可预约。

51CTO技术栈

03月27日 14:00 直播

Flutter Festival:五位技术大咖为Flutter开发者带来满满干货

视频号

分享、收藏、点赞、在看四连哦~
图片
15880微服务转型的注意事项远比你想象的多

root

这个人很懒,什么都没留下

文章评论