AICon全球人工智能与机器学习技术大会9折特惠中,点击立减¥480! 了解详情
写点什么

5 个规则,确保你的微服务优化运行

2020 年 8 月 07 日

5个规则,确保你的微服务优化运行

最近几年好像大家都开始对微服务着迷,与此同时单体架构也在慢慢淡出人们的视线。


当然,热门的趋势总是来来去去,而且它们所受到的关注往往被媒体夸大了,实际情况并不总是如此。不过,对于微服务来说,人们似乎已经达成共识,认为这个趋势会一直存在下去。这是有道理的。从概念的角度来说,微服务扩展了工程师们几十年来采用的相同原则。


一旦你开始使用微服务架构,也许你需要本文中提到的 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 将是其中之一)。团队应该只允许将自己的代码存储在单独的仓库中。


最后的思考

与科技行业的大多数进步一样,微服务采用了一个熟悉的概念,并将其颠覆。它们重新思考了大规模应用的设计、构建和维护方式。它们带来了许多好处,但也带来了新的挑战。当我们把这五个主要挑战放在一起看时,我们可以看到它们都源于同一个理念。因此,每当采用像微服务这样的新技术时,底线是既需要重新思考,也需要重新调整代码的构建、部署和观察方式。微服务所带来的优势是难以拒绝的——但风险也是巨大的。


原文链接:

https://thenewstack.io/5-steps-to-ensure-your-microservices-are-running-optimally/


作者介绍


Tal Weiss,OverOps 的联合创始人及 CTO,主要负责产品以及研发策略。OverOps 是一家旨在帮助用户更有效地发现软件错误的初创公司,成立于 2012 年。


本文转载自公众号 RancherLabs(ID:RancherLabs)。


原文链接


https://mp.weixin.qq.com/s/_VOJNRsdPYOaMB0xViSxbA


2020 年 8 月 07 日 14:082885

评论

发布
暂无评论
发现更多内容

游戏夜读 | 如何避免乏味?两则

game1night

「开放」对协作效率的影响

Tony Wu

产品 产品设计

2020年2月北京BGP机房网络质量评测报告

博睿数据

简单聊聊什么是苹果生态

李俊辰

[GitHub] 跟我一起白嫖 GitHub Pages 做个人站点 ?

猴哥一一 cium

git GitHub GitHub Pages

ARTS - Week One

shepherd

js algorithm

基于mysqldump聊一聊MySQL的备份和恢复

麦洛

MySQL

有点干货 | Jdk1.8新特性实战篇(41个案例)

小傅哥

函数式接口 Lambda 小傅哥 jdk8 编码

实用贴丨正确的「递归」打开方式:让计算机像计算机一样去计算

博文视点Broadview

Python 递归

Elasticsearch 实战

代码诗人

李想解读《高效能人士的七个习惯》

我心依然

习惯 高效能人士的七个习惯 李想 汽车之家

专业的力量

无量靠谱

淘宝 美团 专业 专业主义 大前研一

学计算机你后悔了吗?

陈辰

学习 技术 前端

Lean UX 教你设计如何驱动产品

Yanel 说敏捷产品

产品 敏捷 设计

翻译敏捷行业专业外文,不只是谷歌翻译

行叔

翻译 Scrum 敏捷开发 Agile

软件开发生产率改进之我见(一)

清水

团队管理 软件工程 技术管理

Golang热更新原理

我心依然

golang nginx Linux 信号

工厂模式(二)MyBatis中展示的简单的工厂模式

LSJ

mybatis 工厂模式

工厂模式 (一)简单的工厂模式概念以及示例代码

LSJ

[Git] Git 可以这么学

猴哥一一 cium

git

关于问题的问题 —— 读《你的灯亮着吗?》

YoungZY

读书笔记 读书

Zabbix实战指南

橙子冰

技术 运维 监控 运维自动化 zabbix

Kubectl exec 的工作原理解读

米开朗基杨

Kubernetes kubelet

数仓系列 | Flink 窗口的应用与实现

Apache Flink

大数据 flink 流计算 实时计算 大数据处理

2020年2月北京BGP机房网络质量评测报告

博睿数据

APM 机房 评测 世纪互联

内容比形式更重要

Winann

内容 生活 工作 形式主义

五个“为什么” —— 读《精益创业》

YoungZY

读书笔记

Flutter的staggered GridView详细使用

潘珉

flutter

给学妹的 Java 学习路线

武培轩

Java 学习 程序员 程序媛

python实现·十大排序算法之希尔排序(Shell Sort)

南风以南

Python 排序算法 希尔排序

有价值的产品=设计思维+精益创业+敏捷方法

行叔

Scrum 敏捷开发 Agile 设计思维 精益创业

新晋管理者都会遇到的6个问题

新晋管理者都会遇到的6个问题

5个规则,确保你的微服务优化运行-InfoQ