微服务架构挑战解析

### 微服务架构挑战解析 #### 1. 微服务架构概述 微服务架构允许我们对变更进行分区管理，通过抽象进行概念化设计，并且能够在无副作用的情况下实现重用。采用更简单、标准化的基于 HTTP 的通信方式，能让我们利用现有的基础设施组件、理念和资源，这些资源推动着大规模的互联网运行。 在探索微服务架构时，有几个问题值得思考： 1. 微服务架构如何引领我们走向更优且可持续的架构？ 2. 从单体架构过渡到新的微服务系统，我们获得了什么（或失去了什么）？ 3. 我们能否将任何服务拆分为符合我们所讨论原则的更小的子服务？ 4. 在微服务之旅中，我们如何处理遗留依赖，如大型机、有线协议和文件交换？ 5. 对于那些不愿进行架构演进或在演进中没有投资回报的团队，如何进行合理说明？ #### 2. 微服务架构的挑战与问题 软件解决方案若由独立且隔离的微服务构建而成，会拥有清晰且可持续的架构。它不仅能灵活应对快速变化和实现快速交付，还具备可扩展性、弹性和敏捷性。然而，这种架构灵活性的本质恰恰是严重挑战的根源。当我们向微服务架构过渡时，问题主要出现在两个方面：解决方案设计以及支持与运营。 解决方案依赖大量的微服务组件组合，这在实现新需求的同时，要保留清晰的基于领域的模型会产生战术性问题。监控和操作一个在众多微服务间建立了编排、协同和同步的系统，变得极具挑战性。 ##### 2.1 识别和分类挑战 由微服务组成的系统往往给人一种令人望而生畏的印象。一个单一的应用程序会转变为一个由微小互连系统组成的复杂网络，这种景象让企业感到担忧。但重要的是，我们不能被表面现象所迷惑，实际上这是同一个系统，只是代码库组织得更好。此时会出现两个方面的问题： 1. 从架构角度看，我们是否处于一个更优且可持续的位置？ 2. 总体而言，新系统的行为是否与早期系统完全一致？ 对于第一个问题，答案是肯定的；而第二个问题的答案是否定的，这也是我们接下来要探讨的重点。偏离预期行为有时是有意为之（例如，现在系统更具可扩展性和敏捷性），但通常是无意的。这些异常和副作用需要仔细研究，以识别潜在的问题。我们的担忧大致可分为以下三类： | 挑战类型 | 具体描述 | | ---- | ---- | | 新架构管理问题 | 与管理少数单体应用程序不同，重点转向确保数百个应用程序和服务的正确行为。如何发现问题区域并克服它们？ | | 新系统正确性验证难题 | 更多的活动组件是否意味着更高的复杂性？QA 团队如何确保数百个服务的连接准确无误且行为正确？ | | 基础设施管理复杂性 | 在单体架构世界中，单一的部署管道只需部署到少数服务器，而现在可能会变成数百个部署到数百台机器的管道。运营和支持团队如何进行管理？ | 在深入探讨微服务架构的挑战之前，我们需要了解新架构与原始单体架构的不同之处。单体架构虽然存在诸多缺点，但在某些方面表现出色： 1. **事务准确性**：单体架构使用类似两阶段提交（2PC）的方法，确保在响应请求之前数据的一致性；在处理任何请求结束时，每个数据元素都保持同步。 2. **业务逻辑集中**：理解应用程序只需理解一个单一的代码库，该代码库使用单一编程语言编写，编译并作为一个独立实体进行部署。 3. **数据即时访问**：应用程序各部分读取、创建和修改的所有数据都触手可及。无需进行服务调用和合同协商，跨大型数据集进行连接也不是问题。 4. **单一状态**：应用程序的各个模块共享状态，因此可以立即确定精确的整体状态。 5. **调试范围明确**：故障本质上局限于单个应用程序。如果应用程序的日志文件设计和开发得当，工程师可以通过查看日志文件调试整个流程。 然而，一旦我们过渡到基于微服务的架构，就会失去所有这些优势，并面临新的挑战。 ##### 2.2 分散的业务逻辑 微服务的复杂业务逻辑通常涉及调用其他微服务。随着更多功能的实现，会创建或连接更多的服务。新功能可能是具有所需功能的全新服务，也可能是将其他服务组合在一起的高级服务。随着时间的推移，我们会构建出一个微服务层次结构深度难以管理的系统。 我们选择微服务架构是为了允许系统进行快速更改，但这往往与简单性相冲突。每个新服务和新变体都有可能使架构变得复杂。架构在为总体工作流找到合适的抽象时会遇到困难，快速变化的微服务使得保持一切同步变得困难。作为一种快速解决方案，团队可能会做出例外处理并重新实现他们需要的功能。基于 REST 的实现受影响最大，因为很多时候，业务功能的默认“资源”不可用，工程师很容易创建具有相似字段的新资源。 例如，在某个平台案例中，假设用户设置了自动支付请求，会导致一系列服务调用。随着未来需求的变化，如某些美国州开始为电动汽车车主提供环保折扣，这需要包含车辆的所有充电事件，而不考虑车主在配电网络中的充电位置，这与我们之前的想法有所不同。为了解决这种差异并保持架构的清晰性，我们可能会将这些车辆作为特殊设备进行跟踪。但很快我们会发现功能出现了重复，不过在微服务世界中，这种重复是可以接受的。但这种快速变化和微服务专业化最终会导致更复杂的情况。 重复服务和多余服务往往是微服务单一用途和简单性原则的副作用。新功能成为新服务，偶尔会导致重复实现。可能是工程师发现构建所需功能比重新改造旧功能更快，也可能是他们不了解现有资源的完整列表。无论重复的原因是什么，随着更多修订的出现，会出现更多这样的业务需求。最终，我们会发现自己处于一个拥有许多多余微服务的世界，这些服务功能碎片化，具有重复（或冲突）的业务规则，是为特定目的而创建的。工程师遵循了单一用途微服务的原则，但却牺牲了拥有清晰架构的整体理念。 将单体架构拆分为多个微服务在开发、团队结构和部署方面带来了敏捷性，但它也将复杂功能的操作逻辑和执行流程分散到多个