共计 2903 个字符，预计需要花费 8 分钟才能阅读完成。
最近几年如同大家都开始对微服务着迷，与此同时单体架构也在缓缓淡出人们的眼帘。
当然，热门的趋势总是来来去去，而且它们所受到的关注往往被媒体夸张了，理论状况并不总是如此。不过，对于微服务来说，人们仿佛曾经达成共识，认为这个趋势会始终存在上来。这是有情理的。从概念的角度来说，微服务扩大了工程师们几十年来采纳的雷同准则。
一旦你开始应用微服务架构，兴许你须要本文中提到的 5 个规定，帮忙你胜利运行它们。
微服务的另一面
关注点拆散 (SoC) 是一项设计准则，规定软件的构建应依据 “ 关注点 “ 或总体性能来确定不同的局部，30 多年来始终被用来决定如何构建技术。在单体利用中，它体现在典型的 3 层架构中的体现层、业务层和数据层的拆散。
微服务采纳了这个概念，并将其颠覆。它们将同一个应用程序以这样的形式分离出来，应用程序的繁多代码库能够被合成并独自部署。这样做的益处是微小的，但也是有代价的，通常体现在工夫和金钱两方面的运维老本较高。除了将现有的应用程序过渡到容器所带来的微小的后期投资之外，保护该应用程序也带来了新的挑战。
挑战 1：仿佛很难监控整体
尽管单体应用程序也有其本身的挑战，但在单体中回滚一个“坏”版本的过程是相当简略的。在容器化利用中，事件就变得复杂许多。无论你是将单体利用逐渐合成为微服务，还是从头开始构建一个新零碎，你当初都有更多的服务须要监控。其中每一个都可能会：
- 应用不同的技术和 / 或语言。
- 运行在不同的机器和 / 或容器上
- 应用 K8s 或相似的技术进行容器化和编排
随之而来的是，零碎变得高度扩散，更须要集中监控。遗憾的是，这也意味着须要监控的货色也多了起来。以前只有一个单体过程，而当初可能有几十个容器化过程运行在不同的区域，有时甚至是不同的云。这意味着不再有一套繁多的运维指标来统治它们，IT/ 运维团队能够用它来评估应用程序的个别失常运行工夫。取而代之的是，团队当初必须解决数以百计（甚至数以千计）的指标、事件和告警类型，他们须要从中拆散出无效信号和有效乐音。
解决方案
DevOps 监控须要从扁平化的数据模型转向分层模型，在这种模型中，能够随时察看到一系列高级零碎和业务 KPI。只有有一点偏差，团队就必须可能进入指标层次结构，查看烦扰来自于哪个微服务，并从那里理解理论产生故障的容器。这很可能须要从数据存储和可视化的角度从新调整 DevOps 工具链。开源的时序 DB 工具，诸如 Prometheus 和 Grafana 7.0 等使得这个指标非常容易实现。
挑战 2：跨服务日志记录
在议论监控应用程序时，首先要提出的事件之一是：日志、日志、日志。服务器每天都会产生的 IT 日志相当于碳的排放量，最终导致溢出的硬盘驱动器以及疯狂摄取、存储和工具老本。即便采纳单体架构，你的日志也可能曾经使你的工程师有些头疼。
应用微服务，日志变得更加扩散。一个简略的用户业务当初能够通过许多服务进行，所有这些服务都有本人的日志记录框架。要解决问题，你必须从业务可能通过的所有服务中提取所有不同的日志，以理解问题所在。
解决方案
这里的次要挑战是理解单个业务如何在不同服务之间“流动”。为了实现这一点，须要对传统的单体程序在程序业务执行期间通常如何记录所有事件的形式进行大量批改。只管曾经呈现了许多框架来帮忙开发人员进行解决（咱们特地喜爱 Jaeger 的办法），但对于心愿将单体重构为微服务的企业而言，转向异步、跟踪驱动的日志记录仍须要付出艰巨的致力。
挑战 3：部署一项服务会毁坏另一项服务
单片机世界中的一个要害假如是，所有代码都是在同一时间部署的，这意味着应用程序处于最软弱状态的工夫范畴是一个已知的、绝对较短的时间段（即部署后的前 24-48 小时）。在微服务的世界里，这个假如不再成立：因为微服务实质上是相互交织的，其中一个服务轻微的变更可能会导致行为或性能问题，而这些问题会在另一个服务中体现进去。因而所面临的挑战是，以后呈现故障的微服务使得另一个开发团队并没有预料到他们的代码会呈现中断。这既会导致整个利用意外的不稳定性，也会导致一些组织外部的摩擦。尽管微服务架构可能让部署代码的过程变得更容易，但实际上却让部署后验证代码行为的过程变得更难。
解决方案
企业必须创立共享的公布日历，并且每当部署相干的微服务时，都要分配资源用于亲密测试和监控整个利用的行为。在没有跨团队协调的状况下部署新版本的微服务，就像牛油果加吐司一样，是解决这一挑战的胜利秘诀。
挑战 4：难以找到问题的根本原因
在这一点上，你曾经锁定了有问题的服务，提取了所有须要提取的数据，包含堆栈跟踪和日志中的一些变量值。你可能还有一些 APM 解决方案，比方 New Relic、AppDynamics 或 Dynatrace。从那里，你会失去一些额定的数据，对于一些相干办法的异样高解决工夫。然而 …… 问题的根本原因呢？
你（心愿）从日志中失去的前几位变量数据很可能不会是那些挪动针的数据。它们通常更像是面包屑，指向下一条线索的方向，而不是更进一步的起因。在这一点上，咱们须要尽咱们所能，发掘出更多应用程序下的 “ 魔力 ”。传统上，这须要收回对于每个失败事务状态的详细信息（即到底为什么失败）。这里的挑战是，须要开发人员具备微小的预见性，以晓得他们须要哪些信息来提前排除问题。
解决方案
当微服务中的谬误本源横跨多个服务时，制订一个集中的问题本源检测办法至关重要。团队必须思考须要哪些信息颗粒来诊断将来的问题，以及它们应该在什么层级上收回日志，以思考到性能和平安因素——这是一座高高的山，而且是一座永无止境的山。
挑战 5：版本治理
咱们认为值得强调的问题是，从典型的单体架构中的层模型过渡到微服务的图模型。因为超过 80%的利用程序代码通常是第三方代码，因而在公司的不同微服务之间治理第三方代码的共享形式成为防止陷入前所未有的“依赖天堂”的关键因素。
思考这样一种状况：一些团队在应用第三方组件或共享实例程序的 X.Y 版本（简直所有公司都有），而其余团队则应用 X.Z 版本。这就减少了因为不同版本之间不足兼容性而产生的要害软件问题的危险，或者说，不同版本之间行为的轻微变动，可能会导致须要排查最特异和苦楚的软件 bug。
而在这所有之前，咱们还要揭示本人，任何一个微服务应用第三方代码的旧版本、更软弱的版本，都会产生平安问题——这是黑客的地狱。容许不同的团队在孤岛般的 repo 中治理他们的依赖性，在单体世界中可能是可行的，但在微服务架构中，这是相对不能够的。
解决方案
公司必须在从新设计他们的构建流程方面进行投资，以便为第三方和共享实用程序代码利用集中式 artifact 仓库（Artifactory 将是其中之一）。团队应该只容许将本人的代码存储在独自的仓库中。
最初的思考
与科技行业的大多数提高一样，微服务采纳了一个相熟的概念，并将其颠覆。它们从新思考了大规模利用的设计、构建和保护形式。它们带来了许多益处，但也带来了新的挑战。当咱们把这五个次要挑战放在一起看时，咱们能够看到它们都源于同一个理念。因而，每当采纳像微服务这样的新技术时，底线是既须要从新思考，也须要从新调整代码的构建、部署和察看形式。微服务所带来的劣势是难以回绝的——但危险也是微小的。
