小冬冬历险记_微服务历险记：忽略平台复杂性

小冬冬历险记

我认为对于微服务存在一个普遍的误解。

普遍的看法是，微服务应该可以解决我们所有的问题。 但是，我说，他们自己只能治愈其中一半。 为了解决另一半问题，您应该将微服务与最新的DevBizSecDbaQaOps实践结合起来，并将您的公司转变为最终的流行词杀手机器，并实现持续部署的必杀技。

不过实话说。

微服务本来可以使公司每天执行大量的部署，将系统扩展到无穷大，降低代码库的复杂性，同时节省资金。

但是，很少有人问这一切的价格是多少？

我认为，代价是平台复杂性的增加。

微服务将复杂性从服务转移到平台。 忽略这一事实会导致结果欠佳。

复杂

复杂–许多部分错综复杂，有组织（容易）或杂乱无章（困难）

复杂–无论复杂程度都难以理解

有时候一开始看起来似乎很复杂，但经过足够的熟悉就变得很复杂（想开车）。

我们可以描述任何软件系统的复杂程度。 通过删除系统片段，可以使系统变得不那么复杂。 将系统分成几部分时，它可能会变得不太复杂，但是复杂性通常会增加。

值得庆幸的是，拆分可以以一种易于理解的“有组织的”复杂性结束的方式进行。 但是，我认为这是一门艺术，不仅需要专业知识，还需要大量经验。

当从单一服务转向微服务时，我们将服务拆分以降低其复杂性，但是复杂性并没有消失，而是转移到了平台上。

因为为大规模的分布式系统设计平台还不是主流概念，所以许多公司没有意识到他们不得不改变策略并且在宣传微服务时大失所望。

平台定义

最终该软件不是架子软件，最终会在平台上运行。 平台是使软件能够运行并执行其职责的所有事物。 当平台发生故障时，您的软件将发生故障。

我对软件平台的定义包括：

• 平台拓扑 –现有基础架构
• 服务 –软件的可执行单元
  • 核心服务 –满足业务需求所需的可执行文件
• 服务配置 –根据环境而变化的配置
• 服务机密 –不应受源控制的配置
• 服务发现 –服务检测
• 服务网格 –通过拓扑传递请求

此外，我们还有描述平台设置和部署过程的内容：

• 平台定义 –详细描述基础架构的过程（希望以代码形式）
• 部署管道 –描述部署过程的过程（希望在代码中）

每个平台都是活跃的，不断发展的，并具有生命周期：

第一天

空无一物。 创建基础架构，并首次部署软件。

第2天以上

基础结构被删除，更新或扩展。 配置更改。 软件崩溃。 重新部署软件。 部署失败，需要回滚。

具有挑战性的问题不是在第1天出现，而是在第2天开始出现。 如果您在第一天就没有计划和考虑，那么您可能需要一天来废弃整个平台，然后再回到图纸板上。

这里有很多事情可能出错。 盒子（服务）中的内容是无关紧要的，处理盒子及其之间的连接的事物应该是关注的主要焦点。 如果该公司认为服务比平台更重要，那么我建议您保持不变。

该平台就像一只免费的小狗。 前期成本可能为零，但是当幼犬成长并成倍增长时，维护成本便成倍增长。 最终，一个设计不良且维护不善的平台会以最出乎意料的方式运行，直至无法修复当前平台，创建一个新平台的成本更低。

事后思考

从微服务架构开始有两种情况：

1. 从头开始-我们称之为未开发项目。
2. 通过从整体中提取位来进行迁移。

不幸的是，两种情况通常都具有相同的症状：

平台设计通常是事后的想法。

该平台通常在对话中以“支持”角色出现，很少扮演主要角色。 改变观点并扭转这种局面的公司将是获得微服务架构全部好处的公司。 谁知道，也许甚至公司“我们正在招聘”页面上的所有devop流行语都会像童话故事一样生动起来，并与跳舞的开发人员融为一体。

监视，可观察性和可调试性

监视正在收集和显示数据，以便可以对其进行分析。 要监视系统，它必须是可观察的。

如果您可以观察到我可以理解您。

分析由耦合服务与百分之一的服务组成的系统所需的工具和技术截然不同。 如果可以设法手动收集和筛选几种服务的指标，那么数十种这样做是不可持续的。 任何大型微服务系统都需要工具来自动收集所有基本指标，并以人类可以使用的格式显示它们。

黑盒子

可观察系统的反面是“黑匣子”，在这里我们唯一可以衡量的就是输入和输出（或缺乏输入和输出）。 在这个有趣的演讲中， Bryan Cantrill谈到了可调试性的艺术：

调试的技巧不是猜测答案，而是要提出正确的问题以知道如何回答。 回答的问题是事实，而不是假设。

使平台可观察是一项艰巨而未被重视的工作。 当部署是非事件时，没人会祝贺部署背后的人。

在我看来，成功推出微服务架构需要在平台本身上投入更多的精力，而不是在平台上运行的服务上。 公司需要意识到他们首先要创建一个平台，然后才考虑在该平台上运行的服务。

平台工程师

系统与设计它的人一样好。

系统出现故障，这是可以预料和接受的。 但是，他们也应该自我恢复。 你怎么问 优选地，无需人工输入。

对于任何高级自动化，最薄弱的环节始终是人。

创建自我修复系统需要自我监控。 要监视平台，您需要具有可观察性。 因此，可观察性和监视应该成为优先事项，而不是事后考虑。 要设计，设置和维护平台监视，我们需要平台工程师。

只有在系统无法自我修复时，人员才应该处于循环中。 我们的工作不仅应该是解决问题，而且首先要确保这些问题不再发生或下次自动修复。

在处理复杂的平台时，我们需要专职的“平台工程师”。 他们要么是可以进行编码的系统管理员，要么是知道系统管理的编码人员。 他们编写代码以使平台更易于观察，稳定和对开发人员友好。

对DevOps的这种错误解释是，前提是您可以“摆脱”系统管理员，而最终只能得到在生产中管理服务的开发人员。 那永远不会发生。 大多数开发人员都不在乎，也不想了解系统管理。

共同的监督

“有些人看到光后会改变自己的方式； 其他人感到闷热的时候。”

我认为，处理微服务时最常见的疏漏是：

1.缺乏监督

“当我们停止假设自己知道发生了什么时，这真是不可思议。”

从一开始就需要将可观察性构建到平台中。 投入生产时不要犯错误，然后再担心可观察性，那可能太迟了。

归结为可用性的 SLI，SLA和SLO应该事先达成协议并受到监控。 要监视这些值，您需要具有可观察性。

通常会有一个问题，谁应该看监控，而我的回答是问这个：

谁在乎不破坏SLA？当它损坏时会发生什么？

如果答案是“没人”和“什么都没有”，那么您一开始就不需要监视，因为没有人关心系统是否正常工作。 但是，如果因违反SLA而受到惩罚，那么答案就很明确了。

“人们不怕失败，他们怕责备。”

2.错误的警报工具（或无警报）

数十次相同警报的出现使垃圾邮件泛滥，使接收者变得不敏感。 相同类型的警报应自动分组。 多次接收同一警报的通知与将其副本发送为垃圾邮件有很大不同。

每个警报都需要有一个受让人和一个状态。 您不希望人们并行处理同一问题，而又不知道这个问题是昨天被其他人解决的。

每个警报至少需要起源和采取的措施。 如果有明确的程序来解决问题，人类将Swift解决问题。

3.不遵循

当我在2019年看到一个应用程序而不是登录到stdout日志到文件时，这让我很难过。 十二个要素规则是基础知识，是最不值得选择的成果。

4.使人工制品可变

每次都必须重建工件以更改其配置，这让我哭了。 工件应一次性构建，并可以部署到任何环境。 您可以使用env变量传递配置或读取外部配置文件。

不可变的工件很有用，因为每个构建都略有不同。 两次构建的相同工件在相同条件下的行为可能有所不同。 我们要避免这种情况。

5.没有通用的日志记录策略

没人看日志很有趣。 我们在调试时或为系统脉搏创建基线（认为是心率监视器，但对于软件）时使用它们。 使用不同的日志记录方案分析来自服务的日志太复杂了。 只需提出一个大家都同意的日志记录策略，并为每个人创建一个日志库即可。

如果您不能强制执行通用策略，则在将日志流最终呈现给人类之前自动对其进行标准化。

标准化的日志记录方案对于制作有用的仪表板也至关重要。

6.不

当函数调用崩溃时，我们将获得堆栈跟踪以及从头到尾的所有调用。 在微服务中，呼叫可以在服务之间跳转，而当一个服务失败时，查看整个流程至关重要。

能够跟踪整个系统中的单个呼叫非常有用且很有见地。

跟踪单个呼叫乍看起来似乎很艰巨，但是实现起来很简单。 通常，这是一个标记网络呼叫并记录事件的中间人。 日志随后用于产生可视化。

7.设计管道而无需自动回滚

要进行自动回滚，当出现问题时需要自动检测。 系统如何检测和确定是否出了问题，从而将持续部署的要点与专家分开。

8.不需要健康检查

每个服务都需要回答一个基本问题：它是否健康。 当然，来自应用程序的运行状况检查状态应该只是编排人员用来确定服务是否运行状况的众多指标之一。 服务可能不知道很多问题。

9.不使用服务网格

在将函数调用（整体式）替换为网络调用（微服务）时，我们需要适应延迟，网络错误和丢包情况。 直接从服务重试似乎无害，但可能导致系统范围的级联故障，并给网络造成不必要的压力。

代替强迫每个服务处理网络故障，我们可以使用一个称为Service Mesh的中间人，该中间人旨在处理这些情况。 的确，我们仍在对服务网格进行网络调用，但是这样做更加安全，因为该调用不会离开主机。

服务网格还为我们提供了基本功能，例如重试策略，呼叫超时和期限。 它还使在系统范围内进行电话跟踪变得更加容易。

10.不适应规模化的工具

许多年前，我加入了一个项目，在该项目的一开始，该平台仅运行少量服务。 编排服务的工具非常原始。 该协调器的最大缺陷是它不尊重主机的容量。 主机的服务分配是手动的。 手动分配在一个很小的平台上可以很好地工作，但是不能扩展。 我们必须估算每个服务需要多少内存和CPU并相应地分配它们。 有时估计是错误的，一个服务将崩溃或使其他服务饿死。

当我们从几个服务扩展到数十个服务时，我们应该已经更改了工具，但没有。 那时，我什至不了解这个问题，因为我是这个主题的新手，所以从事该项目的绝大多数人也是如此。 那些知道出了什么问题的人不在乎或太害怕将问题升级为决策者。 该平台变得异常不稳定，需要每天手动重新启动，并且替换Orchestrator的时间太晚了，它已被深深地嵌入到平台中。 花费了一年多的时间来确认问题并从头开始设计新平台。

结论：该平台需要定期检查以评估其是否仍然适合系统需求。

结尾词

自微服务成为主流以来已经有10年了。 该行业仍在提出新的工具，解决方案和模式，以使我们的生活更轻松。 跟上“发展”技术可能令人疲劳和不知所措，因此，我认为最好学习通用且发展缓慢的基本概念。 我希望这就是我在这里要做的。 弄清楚这些微服务的全部含义。 在我们的思维中，我们创建模型来近似我们所学的概念。 我知道我的模型有很大的漏洞，需要大修，因此，如果您发现任何明显而愚蠢的错误，请与我分享！

翻译自: https://www.javacodegeeks.com/2019/05/microservices-adventures-ignoring-platform-complexity.html

小冬冬历险记