认识达内从这里开始

微服务编程开发是随着互联网的不断发展而逐渐被程序员所掌握的一个编程方法，而今天我们就通过案例分析来了解一下，微服务优化都有哪些问题和解决方案。

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

虽然单体应用程序也有其自身的挑战，但在单体中回滚一个“坏”版本的过程是相当简单的。在容器化应用中，事情就变得复杂许多。无论你是将单体应用逐步分解为微服务，还是从头开始构建一个新系统，你现在都有更多的服务需要监控。其中每一个都可能会：

使用不同的技术和/或语言。

运行在不同的机器和/或容器上

使用K8s或类似的技术进行容器化和编排

随之而来的是，系统变得高度分散，更需要集中监控。遗憾的是，这也意味着需要监控的东西也多了起来。以前只有一个单体进程，而现在可能有几十个容器化进程运行在不同的区域，有时甚至是不同的云。这意味着不再有一套单一的运维指标来统治它们，IT/运维团队可以用它来评估应用程序的一般正常运行时间。取而代之的是，团队现在必须处理数以百计(甚至数以千计)的指标、事件和告警类型，他们需要从中分离出有效信号和无效噪音。

解决方案

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

挑战2：跨服务日志记录

在谈论监控应用程序时，先要提出的事情之一是：日志、日志、日志。服务器每天都会产生的IT日志相当于碳的排放量，终导致溢出的硬盘驱动器以及疯狂摄取、存储和工具成本。即使采用单体架构，你的日志也可能已经使你的工程师有些头疼。

使用微服务，日志变得更加分散。一个简单的用户业务现在可以通过许多服务进行，所有这些服务都有自己的日志记录框架。要解决问题，你必须从业务可能通过的所有服务中提取所有不同的日志，以了解问题所在。

解决方案

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

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

单片机世界中的一个关键假设是，所有代码都是在同一时间部署的，这意味着应用程序处于脆弱状态的时间范围是一个已知的、相对较短的时间段(即部署后的前24-48小时)。在微服务的世界里，这个假设不再成立：由于微服务本质上是相互交织的，其中一个服务细微的变更可能会导致行为或性能问题，而这些问题会在另一个服务中体现出来。因此所面临的挑战是，当前出现故障的微服务使得另一个开发团队并没有预料到他们的代码会出现中断。这既会导致整个应用意外的不稳定性，也会导致一些组织内部的摩擦。虽然微服务架构可能让部署代码的过程变得更容易，但实际上却让部署后验证代码行为的过程变得更难。

解决方案

企业必须创建共享的发布日历，并且每当部署相关的微服务时，都要分配资源用于密切测试和监控整个应用的行为。在没有跨团队协调的情况下部署新版本的微服务，就像牛油果加吐司一样，是解决这一挑战的成功秘诀。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!更多内容请在707945861群中学习了解。