21、数字化转型中的DevOps：迁移策略与微服务实践

数字化转型中的DevOps：迁移策略与微服务实践

1. 迁移策略与方法

在进行迁移决策时，需要考虑多个因素，具体如下：

1.1 UI分析

对于PaaS模型下向云端迁移的情况，需要对UI界面进行分析。本地基于Web的应用程序和服务可以通过重新设计以与云服务兼容的方式映射到云端；对于本地的非Web应用程序，则需根据需要进行重建后再迁移到云端。此外，要使第三方框架或类库与云兼容，可能需要进行一些修改或重写。而在IaaS模型中，整个服务器镜像可以以最少的代码更改在云之间进行迁移。

1.2 认证和授权

需要分析应用程序中的认证机制是否兼容，例如使用基于表单的认证和访问控制服务（ACS），并与企业本地的活动目录进行集成。

1.3 与其他模块/应用程序的交互

• Web服务 ：可以作为Web角色或工作者角色托管，也可以保留为本地服务，并通过API公开。
• 本地代码 ：可以创建并部署一个托管包装包。
• 第三方依赖 ：验证这些依赖项是否可以直接从Web服务中使用。

1.4 诊断支持

实现自定义日志记录，并将日志信息保存到存储表中，具体包括：
- 将事件日志推送到诊断存储。
- 将失败的请求日志推送到诊断存储。
- 将性能计数器数据推送到诊断存储。

1.5 其他方面

• 消息队列 ：使用订阅来实现消息发布和订阅模型。
• 配置更改 ：应用程序不应有任何硬编码的物理磁盘或网络访问值，检查是否有第三方库或内容引用，替换静态值和应用程序状态以处理可扩展的应用程序。
• 应用程序日志 ：管理自定义日志的捕获和存储。

1.6 数据迁移策略

由于大多数应用程序是以数据为中心的，因此应用程序迁移策略应与数据迁移策略相结合。应用程序可以将数据存储在磁盘、数据库或网络存储中，但将应用程序从本地迁移到云端时，要求用户在数据方面不会察觉到任何差异。云端提供了以与本地应用程序相同的方式持久化数据的灵活性，云托管应用程序的数据可以通过多种方式保存：
- 从本地数据库到基于云的数据库。
- 静态内容到云存储。
- 消息队列到云队列存储/服务总线队列。

1.7 迁移执行

从本地到云端的Web应用程序迁移是按组件逐步、独立地进行规划的。以下是PaaS和IaaS选项的迁移流程：

graph LR
    A[开始] --> B[UI分析]
    B --> C[认证和授权分析]
    C --> D[与其他模块交互处理]
    D --> E[诊断支持设置]
    E --> F[其他方面处理]
    F --> G[数据迁移]
    G --> H[迁移执行]
    H --> I[结束]

2. 向微服务迁移 - DevOps

DevOps原则和方法非常适合微服务，因为微服务的迁移涉及架构、API和代码开发。所有这些都将在代码版本系统、持续集成、构建、测试系统直至持续部署的过程中进行管理。从单体架构重构为微服务可以通过多种方式实现，以下是三种主要策略：

2.1 独立微服务策略

在单体应用程序中实现新功能时，应将其作为独立的微服务和新代码来实现，而不是添加到单体应用程序中使其变得更加庞大。在新架构中，新服务和遗留单体应用程序共存，有两个通信组件：
- 请求路由器 ：类似于API网关，处理传入的（HTTP）请求，将对应新功能的请求发送到新服务，将遗留请求路由到单体应用程序。
- 胶水代码 ：用于将服务与单体应用程序集成。服务需要访问单体应用程序拥有和处理的数据，胶水代码可以位于单体应用程序、服务中或两者都有。服务访问单体应用程序数据的策略有：
- 调用单体应用程序的远程API。
- 直接访问单体应用程序的数据库。
- 服务维护自己的数据副本，并定期与单体应用程序的数据库同步。

胶水代码还起到翻译两个不同模型的重要作用，它维护自己的原始领域模型，防止其模型受到遗留单体应用程序领域模型概念的污染，因此也被称为防腐层。这种将新功能实现为轻量级服务的方法具有以下优点：
- 新功能/服务可以独立开发、部署和扩展，与单体应用程序无关。
- 新创建的服务扩展了微服务架构的优势。
- 防止单体应用程序变得更加庞大和难以管理。

2.2 分离前端和后端策略

该策略是将单体应用程序中的表示层与业务逻辑和数据访问层分离。企业应用程序通常至少包括三个不同的层：
| 层次 | 描述 |
| ---- | ---- |
| 表示层 | 一个复杂的用户界面，包含大量代码，处理基于HTML的Web UI或（REST）API等HTTP请求。 |
| 业务逻辑层 | 包含应用程序的核心业务规则组件。 |
| 数据访问层 | 访问数据库和消息代理等基础设施组件。 |

在单体模型中，各层之间的职责划分是表示逻辑与业务和数据访问逻辑。业务层通过粗粒度的API封装业务逻辑组件。将单体应用程序拆分为两个部分是向微服务架构扩展的自然过程，一部分包含表示层，另一部分包含业务和数据访问逻辑层。然后，表示逻辑部分或应用程序向业务逻辑应用程序或部分进行远程调用。这种方法的主要好处是能够独立开发、部署和扩展这两个应用程序部分，例如表示层的用户界面可以迭代和快速开发和测试，另一个好处是可以公开远程API供微服务使用。但在这种情况下，所有三层都是庞大的单体组件，因此这只是一个部分解决方案。

2.3 服务提取策略

将单体应用程序中的现有模块转换为独立的微服务是第三种重构策略。在这个过程中，每次提取一个模块并将其转换为服务时，单体应用程序会逐渐缩小。当有足够多的模块被转换后，单体应用程序将不再是问题，完全消失或变得足够小以成为另一个服务。

2.3.1 模块转换优先级

以下因素有助于确定模块转换的优先级：
- 从一些容易提取的模块开始。
- 识别能提供最大收益的模块。
- 识别频繁更改的模块。
- 按收益或更改频率对模块进行排名。
- 与单体应用程序中的其他模块相比，具有独特资源需求的模块，例如需要内存速度或计算密集型算法的模块，应在专用机器上运行，以便快速轻松地扩展应用程序。
- 具有现有粗粒度边界的模块更容易且更便宜地转换为服务，例如仅通过异步消息与应用程序其余部分通信的模块。

2.3.2 模块提取过程

提取模块的初始阶段涉及在模块和单体应用程序之间创建粗粒度的交互，即一个双向API用于在单体应用程序和服务之间进行数据交换。由于存在复杂的依赖关系和细粒度的交互模式，在模块和应用程序其余部分之间实现这一点具有挑战性。基于领域模型模式的业务逻辑，其中包含许多领域模型类依赖关系的关联，可以通过代码更改进行修改。将粗粒度模块转换为通过进程间通信（IPC）API进行通信的独立服务，使单体应用程序和服务能够进行交互。模块提取的阶段如下：

graph LR
    A[初始架构] --> B[阶段1：定义粗粒度API]
    B --> C[阶段2：模块作为独立服务]
    C --> D[服务独立开发、部署和扩展]

• 阶段1 ：定义一对粗粒度API，初始接口是从模块X到模块Z的入站输入，用于调用模块Z；模块Z的出站接口用于调用模块Y。
• 阶段2 ：在这个重构阶段，模块被重新作为独立服务。入站和出站交互通过将模块Z与处理服务发现的微服务底盘框架相结合，使用基于IPC机制的代码服务来实现。提取模块后，服务可以独立于单体应用程序和其他服务进行开发、部署和扩展。服务可以从头开始重写，使用API代码作为防腐层，在两个领域模型之间进行翻译，以将服务与单体应用程序集成。每个提取的服务都是向微服务方向迈进的一步，随着微服务数量的增加，单体应用程序最终会随着时间的推移而缩小。

3. 应用现代化

采用微服务是将现有应用程序迁移到现代平台的一种应用现代化形式。这是逐步规划的，而不是通过重写代码从头开始尝试。如前所述，策略包括将表示层组件与业务和数据访问组件分离，将现有模块转换为服务，以及将新功能和特性实现为微服务，以提高应用程序的敏捷性和性能。

4. 架构迁移方法

Forrester Research和InfoWorld提出了一种面向微服务的四层参与/架构平台。该架构模型适应了计算的变化和移动设备在应用程序开发中的普及。首要考虑的是在优化之前决定微服务架构并设计服务交互。微服务的四层方法分为以下不同层：
| 层次 | 描述 |
| ---- | ---- |
| 客户端层 | 基于移动客户端和物联网的客户体验。 |
| 交付层 | 根据设备优化用户体验，通过监控用户选择来个性化内容。 |
| 聚合层 | 聚合来自服务层的数据以及进行数据协议转换。 |
| 服务层 | 使用内部现有的数据服务或外部服务，如Twilio和Box。 |

最大的区别在于客户端层的分离，基于与用户的实时交互，其下方的层可以不断变化。采用微服务的策略可以总结为以下三个步骤：
- 组件化 ：从现有应用程序中识别组件，并在试点基础上创建微服务实现。
- 协作 ：根据试点阶段学到的经验教训，与利益相关者、程序员和开发团队评估新的流程和计划。
- 连接 ：将微服务应用到实际场景中。

5. 数据耦合

微服务架构是松耦合的，数据通常通过API进行通信。一个微服务甚至可以用少量代码运行，但专注于管理单个任务。松耦合基于以下方面：
- 定义范围边界并内置智能。
- 智能与消息传递功能分离。
- 与具有类似功能的微服务兼容，并能容忍各种修改；更改不需要强制或协调。
- 服务通过API解耦，赋予它们自由和灵活性。API是服务的契约，规定了服务提供的内容以及程序依赖它们的方式。

6. 微服务可扩展性

根据列出的架构可扩展性模型，微服务的可扩展性包括：
- 功能分解（Y轴扩展）
- 数据分区（X轴扩展）
- 单个服务的水平扩展（X轴扩展）

7. 架构和实施考虑的最佳实践

迁移到微服务是一种策略，需要逐步规划，具体如下：

7.1 分离单体应用程序中的类

• 识别与其他业务方法具有CRUD风格接口的类。
• 识别除了与外部服务（如Memcache、云数据存储或任务队列）交互所需的代码外，与其他类没有依赖关系的孤立类。
• 使用静态代码分析工具识别与其他部分隔离的代码段。
• 重构代码以消除不必要的依赖关系，因为循环依赖关系是最难处理的。

7.2 重构生产中的遗留代码库

识别微服务的常见领域，例如：
- 账户和用户信息
- 授权和会话管理
- 配置或偏好设置
- 通知和通信服务
- 照片和媒体，尤其是元数据

7.3 迁移到微服务的后续步骤

• 回滚选项 ：保留现有代码在遗留应用程序中继续运行。
• 创建新代码仓库 ：并将类复制到其中。
• 创建HTTP API ：通过视图层提供钩子，以适当地格式化响应文档。
• 创建新代码 ：作为单独的应用程序（例如exampleapp.yaml）。
• 部署新微服务 ：作为服务或单独的项目。
• 功能测试 ：对代码进行功能测试。
• 数据迁移 ：将数据从遗留应用程序迁移到新的微服务。
• 修改遗留应用程序 ：使其使用新的微服务应用程序。
• 部署修改后的遗留应用程序 ：确保在功能和性能方面进行充分验证。
• 移除死代码 ：如果遗留应用程序中有任何死代码，则将其移除。

8. 领域建模

设计连贯且松耦合的微服务的核心是领域建模，以确保微服务的隔离和绝缘以及它们的可重用性。每个应用程序的微服务应充分隔离运行时副作用，并在系统中其他微服务的实现过程中不受更改的影响。适当的领域建模有助于避免基于技术或组织边界的系统建模缺陷，从而实现数据、业务逻辑、表示逻辑等服务的分离。例如，从单体电子商务系统中提取促销服务，供使用移动Web、iOS或Android应用程序的各种客户端使用。因此，促销的领域模型及其状态实体和逻辑应进行隔离，不受系统其他领域（如产品、客户或订单）的跨领域逻辑或实体的污染。

9. 服务大小

基于单一职责原则，合适的微服务大小是独立运行的驱动力，测试提倡服务大小尽可能小，可能类似于基于Unix的实用程序，具有易于维护和升级的小代码库。根据产品类型和不同的业务逻辑，封装可能会变得过于复杂，因此更好的方法是考虑在产品领域内添加更多边界并创建更多服务。另一个选择是考虑用新的实现或技术替换微服务的时间，并相应地规划大小调整。

10. 测试

在将单体系统逐步转换为支持微服务的系统时，测试起着重要作用。需要执行服务与单体系统的集成测试，并且跨越现有单体系统的业务操作应继续与新的微服务系统一起执行。系统提供的消费者驱动的契约可以转换为测试用例，用于测试新的微服务，在这种情况下，自动化测试可确保满足系统的期望。一些自动化测试套件包括：
- Pact ：一个消费者驱动的契约测试库，它创建一个可重用的测试环境，用于部署整个系统的测试副本以测试微服务。
- Docker compose ：使用自动化工具（如Docker compose），可以将整个系统以Docker容器的形式进行容器化，并进行编排，以便快速部署系统的测试基础设施，在本地执行集成测试。

11. 服务发现

服务发现系统使服务在完成业务功能时能够相互了解。每个服务都引用一个包含其他服务详细信息的外部注册表。对于少量服务，可以通过环境变量来实现；对于更复杂的系统，服务发现通常依赖于Consul和Apache Zookeeper。

12. 部署

每个微服务的部署应通过运行时容器或在自身中嵌入容器来实现自我启用，类似于基于JVM的微服务Tomcat可以嵌入容器，从而无需独立的Web应用程序服务器。在任何时候，存在多个相同类型的微服务（参考规模立方体X轴扩展），以允许更可靠地处理请求。在实现中包括一个软件负载均衡器作为服务注册表，用于故障转移和透明地平衡请求，例如Netflix Eureka。

13. 构建和发布管道

持续集成和部署管道对于实现基于微服务的系统非常有价值，每个微服务都有按需构建和发布的专用管道，可降低构建和发布整个应用程序的成本。滚动升级（或蓝绿部署）应成为发布实践的一部分，这意味着如果升级成功则为绿色，否则应实施回滚策略。这也可以通过在生产环境中随时维护同一微服务的并发版本（现有版本和新构建版本）来实现，以便根据需要快速切换。在这种情况下，可以将一定比例的用户负载路由到新的微服务版本以测试其操作，同时逐步淘汰旧版本。这为系统建立了冗余，以防止微服务中的失败更改使系统瘫痪。

14. 功能标志

微服务模式包括功能标志。它是添加到系统中的一个配置参数，用于启用或禁用某个功能。系统中的这种模式有助于触发与标志选项（例如打开）相关的功能所需的微服务的使用。例如，同一功能可以同时存在于新的微服务和生产环境中，流量可以通过功能标志进行路由；这使交付团队能够加快构建周期时间。

15. 采用微服务提高开发人员生产力

单体架构在系统较小时允许在紧张的时间表内快速推出新的业务功能。然而，随着系统变得更加庞大，开发和运营都会变得繁琐。而微服务架构通过将系统拆分为多个独立的服务，使得开发人员可以更专注于单个服务的开发和维护，提高了开发效率和系统的可维护性。

16. 微服务架构的优势总结

微服务架构在数字化转型中展现出诸多显著优势，以下为您详细总结：
|优势类型|具体优势|
| ---- | ---- |
|开发灵活性|各个微服务可独立开发，开发团队能根据自身节奏和技术栈进行开发，提高开发效率。例如独立微服务策略中，新功能可独立于单体应用开发，避免影响原有业务。|
|部署独立性|每个微服务可单独部署，无需重新部署整个应用。如在持续集成和部署管道中，每个微服务都有专用管道，降低发布成本。|
|可扩展性|能针对不同微服务进行灵活扩展，如通过功能分解（Y 轴扩展）、数据分区（X 轴扩展）和单个服务的水平扩展（X 轴扩展），满足不同业务需求。|
|容错性|当某个微服务出现故障时，不会影响整个系统的运行，提高系统的可靠性。例如多个相同类型的微服务可同时处理请求，实现故障转移。|
|技术多样性|不同微服务可采用不同技术栈，根据业务需求选择最合适的技术。|
|易于维护|微服务代码量小，边界清晰，更易于理解和维护。如基于单一职责原则的小服务，类似 Unix 实用程序，代码库小且易升级。|

17. 微服务迁移的挑战与应对

虽然微服务架构有诸多优势，但迁移过程中也会面临一些挑战，以下是常见挑战及应对方法：

17.1 技术栈整合挑战

不同微服务可能采用不同技术栈，整合时可能出现兼容性问题。应对方法是在架构设计阶段做好规划，选择通用的接口标准和数据格式，如使用 RESTful API 进行服务间通信。同时，建立统一的开发规范和代码审查机制，确保不同技术栈编写的代码质量。

17.2 服务间通信挑战

微服务之间的通信可能会出现延迟、故障等问题。可以采用异步通信、消息队列等方式提高通信的可靠性和性能。例如使用消息队列将请求异步处理，避免同步通信的阻塞问题。

17.3 数据一致性挑战

多个微服务可能会操作相同的数据，如何保证数据一致性是一个难题。可以采用分布式事务、最终一致性等策略。例如在一些场景下，允许数据在短时间内不一致，但通过补偿机制最终达到一致。

17.4 团队协作挑战

微服务架构需要多个团队协作开发和维护，团队之间的沟通和协作可能会出现问题。建立有效的沟通机制和协作流程，如定期的跨团队会议、共享文档等，确保信息流通顺畅。

18. 微服务迁移的案例分析

为了更好地理解微服务迁移的实际应用，以下通过一个案例进行分析：

18.1 案例背景

某电商企业原采用单体架构，随着业务的快速发展，系统变得越来越庞大，开发和维护成本不断增加。为了提高系统的灵活性和可扩展性，决定迁移到微服务架构。

18.2 迁移策略选择

• 采用独立微服务策略，将新的营销功能作为独立微服务开发，与原有单体应用并行运行。
• 运用服务提取策略，逐步将单体应用中的用户管理、订单管理等模块提取为独立微服务。

18.3 迁移过程

graph LR
    A[开始迁移] --> B[确定微服务边界]
    B --> C[开发独立微服务]
    C --> D[数据迁移]
    D --> E[服务集成测试]
    E --> F[逐步替换单体应用功能]
    F --> G[全面迁移完成]

• 确定微服务边界 ：根据业务功能和数据相关性，确定各个微服务的边界。例如将用户管理、商品管理、订单管理等划分为不同的微服务。
• 开发独立微服务 ：组建不同的开发团队，分别开发各个微服务。采用合适的技术栈，如 Java、Python 等。
• 数据迁移 ：将单体应用中的数据迁移到对应的微服务数据库中。确保数据的完整性和一致性。
• 服务集成测试 ：对各个微服务进行集成测试，确保服务之间的通信和协作正常。
• 逐步替换单体应用功能 ：先将部分非核心功能迁移到微服务，进行试点运行，验证系统的稳定性和性能。然后逐步替换核心功能。
• 全面迁移完成 ：当所有功能都迁移到微服务架构后，标志着迁移完成。

18.4 迁移效果

• 开发效率显著提高，新功能的开发周期从原来的数月缩短到数周。
• 系统的可扩展性增强，能够快速响应业务变化，如在促销活动期间，可快速扩展相关微服务的资源。
• 系统的可靠性提高，某个微服务出现故障时，不会影响整个系统的运行。

19. 微服务未来发展趋势

微服务作为一种先进的架构模式，未来将呈现以下发展趋势：

19.1 与云原生技术深度融合

云原生技术如容器、Kubernetes 等将与微服务更加紧密结合。容器化技术可实现微服务的快速部署和资源隔离，Kubernetes 可实现微服务的自动化管理和编排。

20.2 人工智能与机器学习的应用

在微服务架构中引入人工智能和机器学习技术，实现智能的服务发现、故障预测和性能优化。例如通过机器学习算法预测微服务的故障，提前进行处理。

20.3 安全机制的强化

随着微服务架构的广泛应用，安全问题将更加受到关注。未来将加强微服务的身份认证、授权管理和数据加密等安全机制。

20.4 无服务器架构的兴起

无服务器架构将进一步简化微服务的部署和管理，开发人员只需关注业务逻辑，无需管理服务器资源。

20. 总结

数字化转型中采用微服务架构和 DevOps 方法是提升企业竞争力的有效途径。通过合理的迁移策略和方法，如从单体架构向微服务架构的重构，能够实现应用程序的现代化和性能提升。在迁移过程中，要注重领域建模、服务大小的确定、测试、服务发现、部署等关键环节，同时利用功能标志等模式提高开发效率。虽然迁移过程会面临一些挑战，但通过有效的应对措施和案例借鉴，能够顺利完成迁移。未来，微服务将与云原生技术、人工智能等深度融合，为企业带来更多的发展机遇。企业应积极拥抱微服务架构，提升自身的数字化能力，以适应不断变化的市场环境。