想成功运行微服务架构？先来接受这5大挑战
导语：微服务架构得到越来越多的认可，但是如何成功地运行它，不是一个简单的工作。
如今，似乎每个人都在使用微服务，并且整体式架构正逐渐淡出人们的视线。当然，趋势总是来来去去的，而且趋势得到的关注经常被夸大，并不能反映实际情况。但是，对于微服务，似乎有越来越多的共识认为，这个趋势将能够持续下去。这说得通。从概念上讲，微服务扩展了工程师数十年来一直采用的相同原则。
提交微服务架构后，要成功运行它们，请牢记以下五个挑战。
挑战1：很难监控整体
尽管单片应用程序有其自身的挑战，但回退单片中“不良”版本的过程非常简单。在容器化的应用程序中，事情要复杂得多。无论您是逐步将单一应用程序分解为微服务，还是从头开始构建新系统，现在都需要监视更多服务。这些都将可能：
●使用不同的技术和/或语言
●存在其他机器和/或容器上
●使用K8s或类似技术进行包装和编排
这样，系统变得高度分散，并且对集中监控的需求也越来越大。可悲的是，这也意味着还有很多需要监视的地方。在曾经有一个单一的整体过程的地方，可能会有数十个容器化的过程运行在不同区域，有时甚至是不同的云环境里。这意味着不再有任何一套Ops指标可以统治所有这些指标，IT/Ops团队可以使用它们来评估应用程序的总体正常运行时间。相反，团队现在必须处理大量（甚至数千个）度量，事件和警报类型，他们需要从中分离信号和噪声。
解决办法：DevOps监视需要从平面数据模型转变为分层模型，在该模型中，始终可以观察到一组高级系统和业务KPI。在最小的偏差下，团队必须能够深入到度量层次结构中，以查看来自于哪些微服务，再从中发现故障的实际容器。从数据存储和可视化的角度来看，这很可能需要对DevOps工具链进行重新设计。开源时间序列数据库和工具（例如Prometheus和Grafana 7.0）使这成为一个非常可实现的目标。
挑战2：跨服务记录
在谈论监视应用程序时，首先要提出的重要事情是：日志，日志，日志，重要的事情说3遍。
服务器每天都会产生相当于碳排放量的IT排放量，非结构化文本的GB量，最终导致溢出的硬盘驱动器以及疯狂的摄取，存储和工具成本。即使采用整体架构，您的日志也可能已经使您的工程师有些头疼。
使用微服务，日志变得更加分散。一个简单的用户事务现在可以通过许多服务运行，所有这些服务都有自己的日志记录框架。要解决问题，您必须从事务可能通过的所有服务中提取所有不同的日志，以了解出了什么问题。
解决办法：这里的主要挑战是了解单个事务如何在不同服务之间“流动”。为了实现这一点，需要对传统的整体程序在顺序事务执行期间通常如何记录所有事件的方式进行大量修改。尽管已经出现了许多框架来帮助开发人员应对这一问题（我们特别喜欢Jaeger的方法），但是对于寻求将整体重构为微服务的企业来说，转向异步，跟踪驱动的日志记录仍是一项艰巨的努力。
挑战3：部署一项服务可能会破坏另一项服务
整个世界中的一个关键假设是所有代码都在同一时间部署，这意味着应用程序最容易受到攻击的时间段是一个已知且相对较短的时间段（即，部署）。在微服务的世界中，这种假设不再成立：由于微服务与生俱来就相互交织，一个中的突破性变化可能会导致仅在另一个中表现出来的行为或性能问题。当前所面临的挑战是，微服务失败的另一个开发团队并不希望代码破裂。这可能会导致整个应用程序出现意外的不稳定，以及导致组织上的一些摩擦。尽管微服务架构可能使部署代码的过程更加容易。
解决办法：每当部署相关的微服务时，组织必须创建共享的发布日历并分配资源以紧密测试和监视整个应用程序的行为。在没有跨团队协作的情况下部署新版本的微服务，就像鳄梨和吐司一样，是成功解决麻烦的秘诀。
挑战4：寻找问题的根本原因
至此，您已经确定了有问题的服务，提取了要提取的所有数据，包括堆栈跟踪和日志中的一些变量值。您可能还具有某种APM解决方案，例如New Relic，AppDynamics或Dynatrace。从那里，您将获得一些有关某些相关方法的异常高处理时间的其他数据。但是……那是问题的根本原因吗？
您从日志中获得的可变数据的前几位很可能不会移动针头。它们通常更像是面包屑，将其引向下一个线索的方向，而不会越走越远。在这一点上，我们需要尽我们所能来发现我们应用程序中更多的“魔术”。传统上，这需要发出有关每个失败事务的状态的详细信息。这里的挑战是，这需要开发人员进行大量的预见，以提前知道他们需要什么信息来解决问题。
解决方法：当微服务中的错误的根本原因跨越多个服务时，采用集中式根本原因检测方法至关重要。团队必须考虑需要使用哪些信息粒子来诊断未来的问题，以及应该以何种日志级别发出这些信息，以兼顾性能和安全方面的考虑-这是一个艰巨的挑战，而且永无止境。
挑战5：版本管理
我们认为值得强调的一个问题是，从典型的整体架构中的层模型到具有微服务的图模型过渡。由于应用程序代码中80％以上通常是第三方代码，因此在公司的不同微服务之间共享第三方代码的方式的管理成为避免陷入前所未有的“依赖地狱”的关键因素。
考虑一种情况，有些团队使用第三方组件或共享程序的XY版本（几乎所有公司都使用），而其他团队则使用XZ版本。由于不同版本之间缺乏兼容性，或者版本之间的行为发生细微变化，这会导致出现关键软件问题的风险，这可能会导致大多数特有且痛苦的软件错误进行故障排除。
所有这一切，在我们提醒自己之前，任何使用较久，更易受攻击的第三方代码的微服务所产生的安全性问题都是黑客的梦想。在整体环境中，允许不同的团队管理孤立仓库中的依赖关系可能是可行的（如果不建议的话）。在微服务体系结构中，这是绝对禁止的。
解决办法：公司必须投资重新设计其构建过程，以利用集中化的工件存储库（Artifactory就是其中之一）来存储第三方代码和共享实用程序代码。只能允许团队将自己的代码存储在各自的存储库中。
最后的想法
与技术行业的大多数进步一样，微服务采用了熟悉的概念并将其颠倒过来。他们重新考虑了大型应用程序的设计，构建和维护方式。他们带来了许多好处，但也带来了新的挑战。当我们一起看这五个主要挑战时，我们可以看到它们都源自同一个想法。最重要的是，采用微服务之类的新技术需要重新思考和重新构建代码的构建，部署和观察方式。奖品很大，但风险也很大。
- 发表于:
- 原文链接：https://kuaibao.qq.com/s/20200617A06B9R00?refer=cp_1026
- 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号（企鹅号）传播渠道之一，根据《腾讯内容开放平台服务协议》转载发布内容。
- 如有侵权，请联系 cloudcommunity@tencent.com 删除。
相关快讯
扫码
添加站长 进交流群
领取专属 10元无门槛券
私享最新 技术干货
腾讯云开发者
