确保您的微服务以最佳方式运行的5条规则当然，热门趋势总是来来去去，它们所受到的关注往往被媒体夸大了，但事实并非总是如此。但是，对于微服务，似乎已达成共识，即这种趋势将持续下去。这是有道理的。从概念的角度来看，微服务扩展了工程师几十年来所信奉的相同原则。一旦开始使用微服务架构，也许您需要本文提到的5条规则来帮助您成功运行它们。微服务关注点分离(SoC)的另一面是一种设计原则，指出软件应该构建为基于“关注点”或整体功能来识别不同的部分，30多年来一直被用来决定如何构建技术。在单体应用中，体现在典型的三层架构中表现层、业务层和数据层的分离。微服务采用了这个概念并将其转变为头脑。它们以这样一种方式分离相同的应用程序，即应用程序的单一代码库可以被分解和单独部署。这样做的好处是巨大的，但也是有代价的，通常体现在时间和金钱方面的高昂运维成本。除了将现有应用程序转换为容器所带来的大量前期投资之外，维护该应用程序也带来了新的挑战。挑战1：监控单体应用似乎很困难虽然单体应用程序有其自身的挑战，但在单体应用程序中回滚“坏”版本的过程相当简单。在容器化应用程序中，事情变得更加复杂。无论您是逐渐将单体应用程序分解为微服务，还是从头开始构建新系统，您现在都有更多服务需要监控。其中每一个都可能：使用不同的技术和/或语言。在不同的机器和/或容器上运行使用K8s或类似技术进行容器化和编排随之而来的是，系统变得高度分布式，需要更集中的监控。不幸的是，这也意味着需要监控的东西更多。过去只有一个进程，现在可能有数十个容器化进程在不同的区域甚至不同的云中运行。这意味着不再有一组单一的操作指标来统治它们，IT/Ops团队可以使用这些指标来评估一般的应用程序正常运行时间。相反，团队现在必须处理数百（如果不是数千）指标、事件和警报类型，他们需要从这些指标、事件和警报类型中将有效信号与无效噪音分开。解决方案DevOps监控需要从平面数据模型转变为可以随时观察一系列高层系统和业务KPI的分层模型。即使有最细微的偏差，团队也必须能够进入指标层次结构以查看干扰来自哪个微服务，并从那里了解哪个容器实际上发生故障。这可能需要从数据存储和可视化的角度重新校准DevOps工具链。Prometheus、Grafana7.0等开源时序DB工具，让这个目标很容易实现。挑战2：跨服务日志在谈论监控应用程序时首先想到的事情之一是：日志、日志、日志。服务器每天产生相当于IT日志的碳排放量，最终导致硬盘驱动器溢出和疯狂的摄取、存储和工具成本。即使使用单体架构，您的日志也可能已经让您的工程师头疼了。使用微服务，日志变得更加分散。一个简单的用户业务，现在可以通过很多服务来进行，所有的服务都有自己的日志框架。要解决这个问题，您必须从业务可能经历的所有服务中提取所有不同的日志，以了解问题所在。解决方案这里的主要挑战是了解单个业务如何在不同服务之间“流动”。要实现这一点，需要对传统的单体程序通常在顺序业务执行期间记录所有事件的方式进行大量修改。虽然已经出现了许多框架来帮助开发人员解决这个问题（我们特别喜欢Jaeger的方法），但对于希望将整体重构为微服务的企业来说，转向异步、跟踪驱动的日志记录仍然是一项艰巨的工作。努力。挑战3：部署一项服务会破坏另一项服务MCU世界中的一个关键假设是同时部署所有代码，这意味着应用程序最容易受到攻击的时间范围是已知的、相对较短的时间段（即第一个部署后24-48小时）。在微服务的世界里，这个假设不再成立：由于微服务本质上是相互交织的，一个服务的微小变化可能会导致行为或性能问题，并在另一个服务中显现出来。因此，挑战在于当前已关闭的微服务让另一个开发团队不希望他们的代码崩溃。这可能会导致整个应用程序出现意想不到的不稳定以及某些组织内部的摩擦。虽然微服务架构可能会使部署代码的过程变得更容易，但它实际上会使部署后验证代码的行为变得更加困难。解决方案业务必须创建共享的发布日历并分配资源，以便在部署相关微服务时密切测试和监控整个应用程序的行为。在没有跨团队协调的情况下部署新版本的微服务，就像吐司上的鳄梨，是解决这一挑战的成功秘诀。挑战四：难以找到问题的根本原因此时，您已经锁定了有问题的服务并提取了所有需要提取的数据，包括堆栈跟踪和日志中的一些变量值。您可能还有一些APM解决方案，如NewRelic、AppDynamics或Dynatrace。从那里，您可以获得一些关于某些相关方法异常高处理时间的额外数据。但是……问题的根本原因是什么？您（希望）从日志中获得的前几位可变数据很可能不是移动指针的数据。它们通常更像是面包屑，指向下一条线索的方向，而不是进一步的原因。在这一点上，我们需要竭尽全力挖掘应用程序下的“魔力”。传统上，这需要发出有关每个失败交易状态的详细信息（即失败的确切原因）。这里的挑战在于，开发人员需要具有超强的先见之明，才能提前知道他们需要哪些信息来解决问题。解决方案当微服务中错误的根本原因跨越多个服务时，采用集中的方法来检测根本原因至关重要。团队必须考虑需要哪些信息粒度来诊断未来的问题，以及他们应该在什么级别发出日志以说明性能和安全方面的考虑——这是一座高山，一座永无止境的山。挑战5：版本控制我们认为值得强调的是从典型单体架构中的层模型到微服务图模型的转变。由于超过80%的应用程序代码通常是第三方代码，因此跨公司不同微服务管理第三方代码共享的方式成为避免前所未有的“依赖地狱”的关键因素。考虑这样一种情况，一些团队使用第三方组件或共享实例程序的X.Y版本（几乎所有公司都有），而其他团队使用X.Z版本。这增加了由于版本之间缺乏兼容性而导致严重软件问题的风险，或者版本之间行为的微小变化可能导致最特殊和最痛苦的软件错误进行故障排除。在这一切之前，让我们提醒自己，任何使用较旧、更易受攻击的第三方代码版本的微服务都会产生安全问题——这是黑客的天堂。允许不同的团队在孤立的存储库中管理他们的依赖关系可能在单体世界中可行，但在微服务架构中，这绝对不是。解决方案公司必须投资重新设计他们的构建流程，以利用第三方和共享实用程序代码的集中式工件存储库（Artifactory将是其中之一）。只应允许团队将自己的代码存储在单独的存储库中。最后的思考与科技行业的大多数进步一样，微服务采用了一个熟悉的概念并将其颠覆。他们重新思考如何设计、构建和维护大型应用程序。它们带来了许多好处，但也带来了新的挑战。当我们一起审视这五个主要挑战时，我们会发现它们都源于同一个想法。因此，每当采用微服务等新技术时，底线是它需要重新思考和重新调整代码的构建、部署和观察方式。微服务的好处不容否认——但风险也很大。
