41、前端架构：Micro Frontend与移动应用开发

前端架构：Micro Frontend与移动应用开发

1. Java Pet Store的演变

最初的Java Pet Store采用传统Web 1.0技术，通过Servlet和JSP展示Web表单应用方法。随着以单页应用（Single - Page Application）为代表的Web 2.0技术的应用，相关方推出了新版本。新版本利用这些技术，展示了如Facebook和Twitter等应用所普及的无限滚动技术。你可以在Oracle网站上找到Java Pet Store 2.0。

2. Micro Frontend（微前端）

2.1 避免单页应用巨石化

在开发新的单页应用或重构现有单页应用的部分内容时，可能会将多个业务流程的不相关功能放在同一个单页应用中，这与微服务方法相悖。为避免创建一个功能过于集中的巨石型单页应用，需要考虑以下问题：
- 团队能够独立开发和发布最终用户功能，而无需重新测试或重新部署整个用户界面。
- 支持跨职能团队从前端到后端负责一个功能。
- 团队在合适的时候可以自由选择多种框架（如Angular或React）。

单页应用虽然允许团队随时完全替换特定屏幕区域内的用户界面布局和控件，但在构建大型应用时，将此方法应用于多个业务领域可能会导致延迟和意外冲突，因为不同业务方面可能需要略有不同的用户界面表示。例如，航空公司网站中选择航班的最佳屏幕布局可能不适用于查看常旅客状态。此外，应用的不同部分可能需要不同的定制。

2.2 解决方案：拆分单页应用为微前端

将单页应用拆分为多个与特定业务功能对齐的微前端。微前端是由HTML、CSS和JavaScript组成的单页应用，每个微前端都有自己的主容器区域，并在一次HTML上传中加载。微前端包含在父应用中，父应用负责路由到正确的微前端并将其显示在前台页面。

以下是微前端架构的mermaid流程图：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A(父应用):::process --> B(微前端1):::process
    A --> C(微前端2):::process
    A --> D(微前端3):::process

2.3 微前端的特点

• 独立性 ：和微服务及其他单页应用一样，微前端应该是独立、自包含的应用，不依赖于其他微前端或共享库。例如，一个微前端中的JavaScript库或CSS的更改对其他微前端几乎没有影响。
• 多框架支持 ：多个微前端可以放在同一个网页上，它们可以相互独立运行、独立部署，甚至可以使用不同的框架。例如，同一页面上的两个不同微前端可以分别使用Angular和React。为了实现这一点，通常需要使用像single - spa这样的微前端框架，它是一个使不同框架能够通信的路由器。

2.4 微前端的优缺点

优点	描述
更小的可部署单元	每个微前端是网站整体功能的一个小子集，开发和测试速度更快，加载速度也比包含所有功能的巨石型单页应用更快。
独立部署	将巨石型单页应用拆分为微前端，可以将大型团队拆分为更小的单元，每个单元独立开发不同的微前端。
独立更新	由于每个可部署单元更小，团队可以独立于其他微前端进行更新和更改。

缺点	描述
增加复杂性	将单页应用拆分为一组微前端会增加解决方案的整体复杂性，因为需要在父单页应用级别进行额外的协调。
用户体验不一致	团队虽然可以灵活选择MVx框架并通过CSS指定自己的外观和感觉，但这种自由可能导致用户界面在不同视图之间不一致。企业团队最好始终使用单一的MVx框架，或者最多使用极少数几种，并共享一些通用的CSS文件来指定整个Web应用的一致外观和感觉。

2.5 微前端与后端微服务的对齐

微前端应与后端微服务对齐，特别是那些实现调度器模式的微服务。最好的方法是将端到端功能的开发作为一个统一的团队来进行，这意味着每个微前端对应一个不同的调度器，这样同一团队可以从前端到后端负责功能，并独立工作。

2.6 微前端的示例

微前端有很多示例，特别是在用于构建微前端的工具网站上，如single - spa网站。在实际经验中，微前端在许多不同领域都有成功应用，特别是在航空业。例如，一个为航空公司构建客户网站的团队可以分为三个流团队，每个团队负责应用中一个代表主要功能块的主要史诗。每个流团队负责后端微服务和代表这些史诗的微前端的开发。

3. 移动应用开发

3.1 移动应用与浏览器应用的差异

开发了托管在云端的云应用后，用户需要客户端应用来与之交互，很多用户会选择使用移动设备访问应用。然而，在桌面或笔记本电脑上运行良好的浏览器应用可能在移动设备上难以使用，因为构建移动应用与构建Web应用（Web表单应用或单页应用）有几个根本不同之处：
- 屏幕更小、更多样 ：移动设备屏幕较小且尺寸差异大，虚拟键盘常遮挡大部分屏幕。笔记本屏幕上合适的内容和细节量在移动屏幕上可能过多，内容的数量和布局需要根据屏幕大小以及是否显示键盘或选项列表等小部件进行调整。
- 人机交互不同 ：浏览器支持的交互惯例（如弹出菜单和多个标签或窗口）在移动屏幕上通常不可用。
- 输入方式不同 ：带有虚拟键盘的触摸屏与物理键盘和鼠标的工作方式不同。滚动和选择可能更困难，输入长字符串文字可能很繁琐。触摸屏通常提供如触觉反馈等独特功能，这不是Web计算体验的一部分。
- 传感器和集成功能 ：移动设备有许多附加传感器和功能，如用于扫描二维码和拍摄支票照片的相机、用于精确定位的GPS、集成日历和通知系统等。
- 平台演变快 ：两大移动生态系统变化迅速，当移动操作系统的原生用户界面库发生变化时，模仿移动设备外观和感觉的应用往往显得过时。
- 网络不可靠 ：移动网络可能缓慢且不稳定。单页应用使用的AJAX专门设计为频繁通信，并假设网络快速可靠。移动客户端与服务器的连接需要减少通信量并传输更少的数据以节省带宽。
- 本地缓存 ：移动客户端可以在本地缓存状态，减少与服务器的连接次数，甚至可以在离线（包括飞行模式）下运行。
- 移动主屏幕 ：移动设备有主屏幕显示可运行的程序目录，基于浏览器的应用用户需要记住为应用网页添加书签，否则下次可能难以找到该应用。

3.2 解决方案：开发移动应用

开发在用户移动设备上原生运行的移动应用，使用原生平台开发工具套件提供的工具和功能。这意味着需要为每个主要移动平台（如iOS和Android）开发不同的移动应用。开发移动应用可以让应用利用移动平台的硬件功能，通过调用移动操作系统API内置的功能。

用户从安全、受管理的应用商店下载移动应用，操作系统提供商可以审查应用，确保其不具有恶意性且不违反平台的使用条款。移动应用作为云应用的客户端，以与其他类型客户端应用相同的方式调用云应用的功能。

3.3 移动应用的优缺点

优点	描述
用户界面专业化	这可能是移动应用相对于浏览器应用的最大优势。当应用作为移动应用部署时，它与移动设备的用户体验完全集成，包括在主屏幕上的显示、与设备功能的集成以及屏幕尺寸的优化。
通过应用商店可发现性	对于“移动一代”和许多其他用户群体来说，解决问题的首选是在各自的应用商店中查找应用。应用在应用商店中的展示与在搜索引擎中的展示同样重要。
用户锁定	用户使用移动应用时往往不想离开该应用去使用其他应用，这催生了“一体化”应用，如微信在聊天应用中添加了移动支付等功能。

缺点	描述
开发工作量大	移动应用通常比相应的浏览器应用更复杂（因此成本更高），特别是对于相对简单的用户界面。此外，如果同一平台上不同设备（如平板电脑和手机）的用户体验功能存在显著差异，可能需要额外的工作来编写针对这些不同设备优化的用户界面。
重复工作	除了浏览器应用之外再开发移动应用会绝对地增加工作量，并且需要维护至少两倍的代码。
需要专业技能	编写移动应用通常需要专业技能和库。虽然有多个工具套件可以减少这种专业性，但仍然需要具备移动开发技能来部署和调试应用。
移动开发生态系统（应用商店）限制	许多开发者面临的最大缺点是需要遵守两大移动开发生态系统的限制，特别是成本结构。将应用部署到Android或苹果应用商店需要开发者注册和应用认证，并对应用内可放置的内容类型进行限制（如通过应用商店进行应用内购买的规定）。

3.4 移动应用与微服务的匹配

和单页应用一样，微服务与移动应用很匹配，因为领域微服务的面向业务的功能与移动应用的复杂屏幕流程和交互功能能够很好地映射。移动应用通常与调度器配对，调度器可以将结果过滤和转换为特定于移动平台的数据格式。

3.5 移动应用的示例

有数百个示例展示了在标准平台功能范围内工作的移动应用的优势。苹果的示例应用库和谷歌的Android示例库都提供了许多示例。谷歌还提供了一个名为Now in Android的应用。

4. 移动应用开发的架构选择

4.1 框架嵌入方案

在开发移动应用时，团队常常面临如何在移动应用中实现全部应用功能的设计选择。在多模式架构中，Web应用通常比移动应用拥有更多的用户功能。特别是如何在移动应用中访问不常用功能是一个问题。

一些团队曾使用原生功能（如Web视图）从移动应用中访问现有Web内容，但这常使界面不一致，让用户感到困惑。目前解决该问题的方案是使用如React Native和Ionic等框架，这些框架能让团队将单页应用代码嵌入现有的iOS或Android应用中。

• React Native ：与使用React编写的现有Web应用兼容。
• Ionic ：可与使用React、Angular和Vue编写的Web应用配合使用。

以下是这种架构方式的mermaid流程图：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A(移动应用):::process --> B(React Native嵌入代码):::process
    A --> C(Ionic嵌入代码):::process
    B --> D(React Web应用):::process
    C --> E(React/Angular/Vue Web应用):::process

4.2 移动应用的广义定义

虽然移动应用主要指移动设备上的原生应用，但它也可更广泛地应用于任何具有窗口系统的计算机。像团队通信、电子邮件、音乐和视频流等基于Web的应用，不仅可以通过Web浏览器界面访问，还可以通过原生应用访问。这些原生应用不仅运行在iOS和Android设备上，还运行在Windows和macOS计算机上，通常每个平台有不同的应用版本。因此，移动应用是原生应用的一个子类型，适用于任何使用其平台窗口系统实现的客户端应用。不过，桌面和笔记本电脑的原生应用在企业应用中较少使用。

5. 移动应用的优势带来的影响

5.1 用户界面专业化的影响

移动应用的用户界面专业化是其相对于浏览器应用的最大优势。当应用作为移动应用部署时，它与移动设备的用户体验完全集成，包括在主屏幕上的显示、与设备功能的集成以及屏幕尺寸的优化。这使得用户在使用移动应用时能获得更贴合设备特性的体验，提高了用户对应用的满意度和使用频率。例如，一些地图应用在移动设备上能更好地利用GPS功能，为用户提供更精准的导航服务。

5.2 通过应用商店可发现性的营销价值

对于“移动一代”和许多其他用户群体来说，解决问题的首选是在各自的应用商店中查找应用。应用在应用商店中的展示与在搜索引擎中的展示同样重要。这为开发者提供了一个重要的营销渠道，开发者可以通过优化应用在应用商店中的信息（如标题、描述、截图等）来提高应用的曝光率，吸引更多用户下载。例如，一些热门游戏应用通过在应用商店中的精美展示和好评，吸引了大量用户。

5.3 用户锁定的利弊分析

用户使用移动应用时往往不想离开该应用去使用其他应用，这催生了“一体化”应用，如微信在聊天应用中添加了移动支付等功能。从开发者的角度来看，用户锁定可以增加用户对应用的粘性，提高应用的使用时长和用户留存率。但从用户的角度来看，这可能会限制用户的选择，使用户过度依赖某个应用，并且可能存在隐私和安全风险。因此，开发者在追求用户锁定的同时，也需要注意保障用户的权益和安全。

6. 总结

6.1 微前端和移动应用的价值

微前端和移动应用在现代应用开发中都具有重要价值。微前端使单页应用更加模块化，通过将其拆分为多个与特定业务功能对齐的微前端，实现了团队的独立开发、部署和更新，提高了开发效率和应用的可维护性。移动应用则能为用户提供更优化的移动设备使用体验，充分利用移动设备的硬件功能和特性，满足用户在移动场景下的需求。

6.2 面临的挑战与应对策略

然而，它们也都面临一些挑战。微前端增加了整体解决方案的复杂性，可能导致用户体验不一致，需要在父应用级别进行额外的协调，并统一使用MVx框架和共享CSS文件来解决。移动应用开发工作量大，存在重复工作，需要专业技能，还受到移动开发生态系统的限制。开发者可以通过使用跨平台开发工具和框架（如React Native和Ionic）来减少开发工作量和对专业技能的依赖，同时遵守应用商店的规定来应对这些挑战。

6.3 未来的发展趋势

随着技术的不断发展，微前端和移动应用有望在更多领域得到应用和发展。微前端可能会与更多的后端架构模式相结合，进一步提高应用的灵活性和可扩展性。移动应用则可能会更加注重用户体验的个性化和智能化，利用人工智能和机器学习技术为用户提供更精准的服务。同时，跨平台开发技术也将不断完善，使开发者能够更高效地开发出适配多种平台的移动应用。

总之，开发者在选择架构和开发方式时，需要综合考虑业务需求、用户体验、开发成本和技术难度等因素，以实现最佳的应用开发效果。