确保你的Microservices优化运行5个规则是哪些，针对这个问题，这篇文章详细介绍了相对应的分析和解答，希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。
最近几年好像大家都开始对微服务着迷，与此同时单体架构也在慢慢淡出人们的视线。
当然，热门的趋势总是来来去去，而且它们所受到的关注往往被媒体夸大了，实际情况并不总是如此。不过，对于微服务来说，人们似乎已经达成共识，认为这个趋势会一直存在下去。这是有道理的。从概念的角度来说，微服务扩展了工程师们几十年来采用的相同原则。
一旦你开始使用微服务架构，也许你需要本文中提到的5个规则，帮助你成功运行它们。
微服务的另一面
关注点分离(SoC)是一项设计原则，规定软件的构建应根据 "关注点 "或总体功能来确定不同的部分，30多年来一直被用来决定如何构建技术。在单体应用中，它体现在典型的3层架构中的表现层、业务层和数据层的分离。
微服务采用了这个概念，并将其颠覆。它们将同一个应用程序以这样的方式分离出来，应用程序的单一代码库可以被分解并单独部署。这样做的好处是巨大的，但也是有代价的，通常体现在时间和金钱两方面的运维成本较高。除了将现有的应用程序过渡到容器所带来的巨大的前期投资之外，维护该应用程序也带来了新的挑战。
挑战1：似乎很难监控整体
虽然单体应用程序也有其自身的挑战，但在单体中回滚一个“坏”版本的过程是相当简单的。在容器化应用中，事情就变得复杂许多。无论你是将单体应用逐步分解为微服务，还是从头开始构建一个新系统，你现在都有更多的服务需要监控。其中每一个都可能会：
使用不同的技术和/或语言。
运行在不同的机器和/或容器上
使用K8s或类似的技术进行容器化和编排
随之而来的是，系统变得高度分散，更需要集中监控。遗憾的是，这也意味着需要监控的东西也多了起来。以前只有一个单体进程，而现在可能有几十个容器化进程运行在不同的区域，有时甚至是不同的云。这意味着不再有一套单一的运维指标来统治它们，IT/运维团队可以用它来评估应用程序的一般正常运行时间。取而代之的是，团队现在必须处理数以百计（甚至数以千计）的指标、事件和告警类型，他们需要从中分离出有效信号和无效噪音。
解决方案
DevOps监控需要从扁平化的数据模型转向分层模型，在这种模型中，可以随时观察到一系列高级系统和业务KPI。只要有一点偏差，团队就必须能够进入指标层次结构，查看干扰来自于哪个微服务，并从那里了解实际发生故障的容器。这很可能需要从数据存储和可视化的角度重新调整DevOps工具链。开源的时序DB工具，诸如Prometheus和Grafana 7.0等使得这个目标非常容易实现。
挑战2：跨服务日志记录
在谈论监控应用程序时，首先要提出的事情之一是：日志、日志、日志。服务器每天都会产生的IT日志相当于碳的排放量，最终导致溢出的硬盘驱动器以及疯狂摄取、存储和工具成本。即使采用单体架构，你的日志也可能已经使你的工程师有些头疼。
使用微服务，日志变得更加分散。一个简单的用户业务现在可以通过许多服务进行，所有这些服务都有自己的日志记录框架。要解决问题，你必须从业务可能通过的所有服务中提取所有不同的日志，以了解问题所在。
解决方案
这里的主要挑战是了解单个业务如何在不同服务之间“流动”。为了实现这一点，需要对传统的单体程序在顺序业务执行期间通常如何记录所有事件的方式进行大量修改。尽管已经出现了许多框架来帮助开发人员进行处理（我们特别喜欢Jaeger的方法），但对于希望将单体重构为微服务的企业而言，转向异步、跟踪驱动的日志记录仍需要付出艰巨的努力。
挑战3：部署一项服务会破坏另一项服务
单片机世界中的一个关键假设是，所有代码都是在同一时间部署的，这意味着应用程序处于最脆弱状态的时间范围是一个已知的、相对较短的时间段（即部署后的前24-48小时）。在微服务的世界里，这个假设不再成立：由于微服务本质上是相互交织的，其中一个服务细微的变更可能会导致行为或性能问题，而这些问题会在另一个服务中体现出来。因此所面临的挑战是，当前出现故障的微服务使得另一个开发团队并没有预料到他们的代码会出现中断。这既会导致整个应用意外的不稳定性，也会导致一些组织内部的摩擦。虽然微服务架构可能让部署代码的过程变得更容易，但实际上却让部署后验证代码行为的过程变得更难。
