43、云应用客户端与应用迁移现代化探索

云应用客户端与应用迁移现代化探索

1. AWS 云服务开端与交互模型引入

1.1 AWS 简单队列服务（SQS）

最早在 AWS 上提供的云服务是 AWS 简单队列服务（SQS），它于 2004 年以测试版形式首次发布。SQS 是一种将联网排队机制作为服务进行商品化的实现，此前这种机制仅由 IBM 或 TIBCO 等公司以终端用户安装软件的形式提供。2006 年首个公开版本的 SQS 发布，其特点是具有“简单直接的 API，可用于创建队列、发送消息、接收消息、删除消息、列出队列集合以及删除整个队列”。

1.2 客户端应用面临的问题

在构建多个不同用例的客户端应用程序（如终端用户客户端应用程序和管理界面）时，希望所有客户端应用程序能一致工作，但容易将业务规则直接嵌入到处理用户体验（UX）操作的代码中，这使得应用程序的维护变得困难，尤其是随着库和框架的不断发展。

同时，用户界面框架和库会随时间变化、发展和兴衰。例如在 JavaScript 中，自引入 AJAX 方法以来，前端应用程序多次被重写，原因包括难以找到精通特定框架的人员、支持库背后开源项目的社区开始萎缩，或者开发团队想利用其他框架中才有的新特性。

1.3 交互模型的提出

为避免在客户端应用程序中混合业务逻辑和表示逻辑，可封装客户端应用程序与云应用程序的交互，并将用户交互状态作为交互模型进行管理。交互模型的主要目的是将领域逻辑与表示逻辑隔离开来，它将表示逻辑与过多了解后端的需求隔离开，同时也防止用户界面对后端造成“污染”。

交互模型会与特定业务流程相关，其边界与领域模型的边界相同，因为它捕获了导致事件模型中操作和事件的用户交互。并且，交互模型通常也特定于某个特定的用户角色，因为单个业务流程通常有焦点在不同角色之间转移的过渡点，业务流程和角色交集之间的每个单独部分都将是一个独立的交互模型。

2. 交互模型的特点与优势

2.1 交互模型的特点

• 与领域模型的接口 ：交互模型通过服务 API 与领域模型进行交互。云原生应用程序通过服务 API 为客户端提供对其领域模型的访问，交互模型利用这些 API 为其 GUI 提供服务。微服务架构将其领域模型构建为一组领域微服务，交互模型通过调度器访问这些微服务。
• 管理用户交互状态 ：交互模型是当前用户交互状态的管理中心。用户通过各种机制（如按钮点击事件、文本窗口中的文本提交或语音输入等）与用户界面框架进行交互，这些交互事件必须转化为业务领域中有意义的操作，这需要“记忆”按钮点击、聊天请求或语音输入在当前业务流程状态中的上下文。

2.2 交互模型的优势

优势	说明
可测试性	引入交互模型可提高系统的整体可测试性，通过引入一个点将客户端和服务器端分离，使每一半都可以使用模拟等技术进行单独测试。交互模型的外部依赖有限，便于用模拟对象替换，从而在不调用后端服务器的情况下进行 UI 测试，也可使用 Web 模拟框架自动进行与后端代码交互的单元测试。
模型与视图分离	将与后端的抽象交互与前端的详细实现分离，可使后端代码免受前端的微小更改影响。即使遵循响应式设计原则，移动（或平板电脑）和桌面版本的应用程序通常也需要略有不同的网页设计和详细交互设计。如果将这些细节与后端交互分开，并且只有一个逻辑实现，而不是两个或更多，那么维护起来会更容易，从而希望在不同的交互模型实现之间共享代码。
独立于前端库	前端客户端库会不断变化，例如在 IBM 内部的一个示例中，JavaScript 客户端组件库在应用程序的生命周期内已经更改了三次，这在行业中相当典型。交互模型将后端代码与变化频繁的前端代码隔离开来。

2.3 交互模型的权衡

• 额外的维护工作 ：添加一个额外的层意味着需要维护更多的代码，并且需要考虑如何在适当表示客户端交互的同时，避免用前端客户端库的细节污染交互模型。
• 额外的代码大小 ：编写交互模型会产生更多的代码，当以 JavaScript 作为客户端应用程序的一部分时，意味着每次都必须将代码下载到浏览器中，这会导致更长的加载时间。

3. 交互模型在多模式架构中的应用

3.1 多模式架构中的交互模型数量

在系统中确定交互模型的数量没有绝对的硬性规则，但一般来说：
- 对于每个主要业务流程，通常会有不同的交互模型，因为这往往是不同主要用户体验端口之间的区别。例如，在在线购物示例中，购买业务流程（由客户使用）的用户界面流程与订单履行流程（由内部运输团队使用）有很大不同。
- 在多模式架构中，每个通道通常（但不总是）会有不同的交互模型。在最简单的情况下，浏览器应用程序的 Web 通道和移动应用程序的移动通道会有不同的交互模型，但这两者可能能够共享一些代码，在最佳情况下，可能会有相同的实现，这取决于两个通道中用户体验的独特程度。

3.2 交互模型与公共代码的共享

交互模型是任何用户界面框架与后端服务器之间的唯一交互点，这使得它也可以作为与其他可能变化的公共库（如日志记录库）的接触点。在系统中，多个交互模型之间最少的代码共享是重用公共对象（如用户或日志记录库）。在某些情况下，如果所使用的语言允许，还可以让不同的交互模型继承自一个公共超类，以便将一些公共功能（如日志记录、用户管理或与后端调度器的连接）推到超类中。

3.3 交互模型与应用控制器模式的关系

交互模型是应用控制器模式的扩展视图。应用控制器模式也关注 UI 与业务逻辑的分离以及 UI 操作的排序或选择，但它更紧密地与基于页面的 Web 界面技术相关，而交互模型的概念扩展到了许多其他领域，如移动应用程序、命令行界面和聊天机器人等。

4. 云应用客户端的总结与展望

4.1 云应用用户界面的选择

如今，多模式界面已成为常态，在为客户端应用程序构建用户界面时应予以考虑。这一决策允许开发适应用户设备的用户界面，以远程访问运行在云中的应用程序的功能，从而为不同类型的用户和设备提供不同类型的用户界面。

客户端应用程序应通过服务 API 与云应用程序进行交互，通常由调度器实现。这样，API 可以在云应用程序发展时保持稳定，使开发人员能够独立地发展客户端应用程序和云应用程序。

4.2 不同类型的客户端应用程序

支持云应用程序用户体验的客户端应用程序有多种形式，从最常见的浏览器应用程序到移动应用程序，以及公共 API 或命令行界面等其他形式。这些应用程序通常使用某种形式的端口和适配器架构构建，经常使用调度器为客户端提供与内部业务逻辑交互的统一 API。

4.3 应用迁移与现代化

并非所有应用程序都是全新设计的，很多云应用程序最初是在传统 IT 环境中运行，然后迁移到云端。为了使这些遗留应用程序在云中更好地运行，开发人员不仅需要将应用程序迁移到云端，还通常需要对应用程序进行修改，以融入更多的最佳实践。

以下是一个简单的 mermaid 流程图，展示了客户端应用与云应用通过交互模型交互的基本流程：

graph LR
    A[客户端应用] --> B[交互模型]
    B --> C[云应用（领域模型）]
    C --> B
    B --> A

在构建云应用时，合理运用交互模型等技术，能够有效提升应用的可维护性、可测试性和独立性，同时为应用的迁移和现代化奠定良好的基础。

5. 云应用客户端的实现方式与选择

5.1 浏览器应用的实现选项

浏览器应用有多种实现方式，在构建时需要根据具体需求进行选择：
- Web 表单应用 ：对于简单的情况，Web 表单应用可以快速构建。即使在更复杂的情况下，它也可能是最佳的实现选择。其优点是实现相对简单，能满足基本的用户交互需求。
- 单页应用（SPA） ：基于在浏览器中运行的 JavaScript 的单页应用是最常见的选择。它能提供流畅的用户体验，避免页面刷新带来的延迟。但也存在一些问题，例如初始加载时间可能较长，搜索引擎优化相对困难等。
- 微前端 ：微前端可以解决单页应用的一些问题。它将前端应用拆分成多个小型、自治的前端应用，每个应用可以独立开发、部署和维护，提高了开发效率和代码的可维护性。

5.2 客户端应用与云应用的交互架构

客户端应用通常通过服务 API 与云应用进行交互，一般由调度器来实现这一过程。这种架构使得 API 在云应用不断发展的过程中能够保持稳定，从而让开发人员可以独立地对客户端应用和云应用进行改进和优化。以下是一个简单的表格说明客户端应用与云应用交互的关键要素：
|要素|说明|
|----|----|
|服务 API|作为客户端应用与云应用交互的接口，提供稳定的功能调用方式。|
|调度器|实现服务 API，负责协调客户端应用与云应用之间的通信，确保数据的正确传输和处理。|

5.3 不同类型客户端应用的特点

不同类型的客户端应用在支持云应用的用户体验方面各有特点：
- 浏览器应用 ：是最常见的形式，具有广泛的兼容性，用户可以通过浏览器直接访问云应用的功能。
- 移动应用 ：更适合移动设备用户，提供更个性化和便捷的操作体验，通常可以利用移动设备的硬件特性，如摄像头、传感器等。
- 公共 API ：为外部开发者提供了访问云应用功能的接口，促进了生态系统的发展和集成。
- 命令行界面 ：适合技术人员进行自动化操作和批量处理，具有高效、灵活的特点。

6. 应用迁移与现代化的重要性与挑战

6.1 应用迁移的必要性

许多云应用最初是在传统 IT 环境中运行的，这些遗留应用在传统 IT 环境中可能运行良好，但在云计算环境中可能存在诸多不适应。将这些应用迁移到云端并进行现代化改造，可以充分利用云计算的优势，如弹性伸缩、高可用性、成本效益等。

6.2 应用迁移面临的挑战

• 技术适配 ：传统应用的技术栈可能与云计算环境不兼容，需要进行技术选型和迁移，例如从传统的服务器架构迁移到容器化和微服务架构。
• 数据迁移 ：确保数据在迁移过程中的完整性和安全性是一个重要挑战，需要考虑数据的格式转换、数据量的大小以及迁移过程中的数据同步问题。
• 业务逻辑调整 ：云计算环境可能需要对业务逻辑进行调整，以适应新的架构和服务模式，这可能涉及到对应用代码的修改和测试。

6.3 应用现代化的方法

为了使遗留应用在云中更好地运行，开发人员需要对应用进行修改，融入更多的最佳实践：
- 采用微服务架构 ：将单体应用拆分成多个小型、自治的微服务，提高应用的可扩展性和可维护性。
- 容器化技术 ：使用容器（如 Docker）将应用及其依赖打包，实现应用的快速部署和迁移。
- 自动化运维 ：引入自动化工具（如 Kubernetes）进行应用的部署、监控和管理，提高运维效率。

以下是一个 mermaid 流程图，展示了应用迁移与现代化的基本流程：

graph LR
    A[传统应用] --> B[评估与规划]
    B --> C[技术选型与准备]
    C --> D[数据迁移]
    D --> E[应用改造与测试]
    E --> F[云部署与上线]
    F --> G[持续优化与监控]

7. 总结

7.1 云应用客户端的核心要点

在构建云应用客户端时，多模式界面的选择至关重要，它能满足不同用户和设备的需求。交互模型的引入可以有效分离业务逻辑和表示逻辑，提高应用的可测试性、可维护性和独立性。不同类型的客户端应用（如浏览器应用、移动应用等）各有特点，开发人员应根据具体需求进行合理选择。

7.2 应用迁移与现代化的关键

对于遗留应用的迁移和现代化，需要充分认识到其必要性和面临的挑战。采用合适的技术和方法（如微服务架构、容器化技术等）可以帮助应用更好地适应云计算环境，实现应用的持续发展和优化。

通过合理运用上述技术和方法，开发人员可以构建出高效、稳定、易用的云应用客户端，并将遗留应用成功迁移到云端，为用户提供更好的服务体验。