安卓iptables端口重定向_安卓iptables端口重定向「建议收藏」

前言：

微前端，借鉴了后端微服务的理念，将它应用于前端，将一个单一的单体应用拆分成多个小型应用的集合，这些小型应用最终聚合成一个完整的庞大的应用。

民生应用云APaaS平台利用云原生技术，提供全生命周期的平台支撑，解决金融应用从传统架构向云原生架构转型的痛点。平台为应用开发人员提供了以应用为中心的资源申请，应用建模，DevOps，环境管理等功能。

民生软件工程支撑平台(PSET)提供从软件需求到交付运营的全生命周期支撑能力，能有效减少研发成本、量化研发过程、提高交付质量、缩短交付周期，协助项目组高质量高效的交付软件，目前民生PSET平台已为全行提供DevOps服务。

在初期民生APaaS平台开发时，有许多功能需要结合民生PSET平台现有功能进行集成开发，这使两个平台之间需要频繁跳转，平台间的跳转会出现白屏，使用户在使用时有跳出感，体验不佳，我们也尝试将PSET平台现有组件迁移至APaaS平台内进行复用，但APaaS平台前端框架使用react@16.x，PSET平台前端框架使用react@15.x，组件之间并不能进行无成本的复用，大多都需要进行改造，而且组件的复用也造成了前端工程过于复杂和庞大，这样并不容易进行维护，而且PSET平台的相关改动还要手动维护至APaaS平台，对于开发者也并不友好。于是我们进行了一些调研和分析，尝试使用微前端的方式将两个平台进行集成。

民生应用云APaaS平台前端集成方式的探索

需求分析

结合APaaS平台和PSET平台现状，我们对两者集成方式进行了深度分析，首先明确了集成过程中需要解决的问题，包含以下几点：

1. 用户体验。两平台之间需要频繁的交互和跳转，我们希望在平台之间切换时做到用户无感知。

2. 开发体验。我们希望两个平台前端工程能够独立开发和维护，两个平台的功能开发，测试和部署互不影响。

3. 部署方式。每个项目应该能够同时支持独立发布和集成式发布两种部署方式。同时，在集成式方式发布时，可单独部署任何一个项目而不影响其他项目。

4. 技术栈。现阶段，前端技术百花齐放，优秀框架层出不穷，我们希望能够集成尽可能多的框架，使用我们既可以确保现有项目的集成，还可以确保在若干年后同样能使用时下最新最流行的技术栈。

5. 改造成本。尽可能少的修改现有平台内部代码，以降低接入成本。

方案探索

经过对以上需求的分析，我们对时下流行的前端集成方案做了调研，同时与民生apollo前端团队探讨交流，初步提出了以下几种解决方案：

1. iframe嵌入式集成。iframe嵌入作为一个普通却有效的方法，在技术层面上，完全可以实现当前的功能需求，而且使两个平台可以完全独立管理和维护。但是，iframe嵌入显示效果并不理想,而且需要平台提供不包含独立导航栏的页面，且路由管理困难，每次刷新页面时，都会跳回最初的iframe地址。

2. 路由分发式集成。通过HTTP 服务器的反向代理来实现将路由不同的业务分发到不同的、独立的前端应用上。这种方案更像是多个前端服务的集合，我们只是把他们拼凑到一起，看起来像是一个整体，在实际使用时仍然是从A应用跳转到B应用。

3. 通用中心路由基座式集成。提供一个基座工程，在基座工程里并不包含任何子工程的逻辑和业务场景，只是提供了各个子工程的注册和挂载逻辑，基座工程会根据当前路由，自动挂载与之匹配的子工程。这种方式使子工程可以使用不同的技术栈，且子工程之间相互独立，实现独立开发，测试，部署。

经过对以上三种解决方案的调研、对比与探讨，我们认为iframe嵌入需要维护大量iframe路由关系，且集成效果并不理想，路由分发式无法处理页面跳转时的白屏问题，而且集成后整体性不强，最终我们选择了通用中心路由基座式集成方案，整体方案架构如下图所示：

基座工程，我们选择使用Single-SPA，它具有以下优势：

1. 在同一页面上使用多个前端框架而不用刷新页面

2. 独立部署每一个单页面应用

3. 新功能使用新框架，旧的单页应用不用重写可以共存

4. 改善初始加载时间，迟加载代码

同时，民生apollo前端团队针对Single-SPA，提供了mskj-mfe-cli工具，提供初始化的基座工程，这极大地简化了基座工程的配置流程，减少了配置项。

子工程，我们使用single-spa-apollo作为子工程的适配器，single-spa-apollo针对民生apollo框架项目做了深度的适配，使用民生apollo框架的项目可以非常顺利的转换成子工程。

下面以民生PSET平台前端改造为例，说一下子工程的改造过程：

1. 基座工程注册子工程。

我们在基座工程内注册pset子工程，我们需要配置子工程的应用名和唯一的路由，使路由访问/pset/*时，基座工程可以正确的加载应用名为pset的子工程。entryFiles为加载子应用后，子应用初始化时需要加载的文件。具体配置及说明见下图。

2. 子工程引入single-spa-apollo,增加入口文件

为PSET子工程创建一个新的微前端打包入口文件。民生PSET平台作为一个独立的项目，有完整的打包流程及入口文件，而微组件需要一个可以供给基座工程挂载的文件，这就需要一个不同的入口文件，而这个入口文件也并不复杂，使用single-spa-apollo，只需要将原来app.start()所生成的文件，挂载到reactComponent内即可，其他的配置,single-spa-apollo已经帮我们做了相应的处理。(下图为新增入口文件与原入口文件对比)

3. css隔离

在single-spa-apollo内提供了组件加载的生命周期，我们在组件挂载时加入样式表，在组件卸载时缓存并删除样式表，动态加载css样式，使页面效率更高，同时，我们利用PostCSS，为每个子工程样式表生成命名空间，来确保子工程样式不会污染全局样式。

4. 添加打包配置

在构建民生PSET平台子工程时，需要使用额外的webpack配置，这包含项目在基座工程内注册时的应用名，入口文件，路由规则等配置，这些配置将在构建子组件时注入webpack配置中。

5. 增加构建命令，增加持续集成单元，独立部署

为了使PSET平台可以同时支持单独部署和微前端部署，我们增加了微前端的打包命令，在package.json中，通过改变打包时的环境变量，输出不同的bundle。

项目在服务器部署时整体结构如下：

app

├── portal //基座工程目录

├── apaas // APaaS子工程目录

└── pset // PSET子工程目录

每次民生PSET平台更新时，只需要将项目打包后的dist目录内文件更新至服务器pset目录内，portal和apaas项目并不需要任何操作，当我们再次访问基座工程时，就能正确的挂载更新后的PSET子工程。

民生PSET平台微前端改造总结

优势：

1. Single-SPA对于其子工程的技术栈不敏感，这保证了老项目集成及新项目扩展的可行性。使用Single-SPA，我们在集成老项目的同时，还可以确保在若干年后同样能使用时下最新最流行的技术栈。这可以使我们的项目保持旺盛的生命力。

2. Single-SPA将项目拆分为多个子工程，使每个子工程可以由专门的团队单独维护，这降低了维护成本及沟通成本，使每个团队可以将注意力集中在自身子工程的迭代中。

3. Single-SPA使每个子工程可单独维护自己的代码仓库，这降低了子工程之间的耦合性，使每个子工程可以单独打包，测试，部署，提高了开发效率。

4. Single-SPA通过基座工程，将各个子工程通过路由挂载，在子工程之间切换时，保持了整体的样式，没有跳出感，同时子工程对样式的缓存，使子工程之间切换时响应更加迅速，页面展现更加流畅。

不足：

1. 由于目前Single-SPA内只是对入口文件做了修改，并没有改变原有项目内部逻辑，而集成后，原有项目与其他项目之间的跳转关系等发生了改变，这就需要项目内针对集成的子工程的跳转逻辑进行判断及改造，前期有一定的工作量。

2. 目前基座工程内未集成统一身份认证功能，各子工程的登录状态还由各自维护，造成了登录状态的混乱，待所有项目接入统一身份认证平台后，该问题才会得到解决

3. 子工程之间通信还是依赖URL参数，基座工程并没有提供查询子工程状态的功能，基座工程应该提供统一的方法，可以使子工程向基座工程暴露自身的某些状态，数据信息，供其他子工程调用。

这些问题我们已经反馈给民生apollo前端团队，已经在针对这些问题进行优化，在后续的框架升级中会解决这些问题，带来更好的使用体验。目前，民生apollo前端团队已经完成对民生apollo框架的改造支持，后续还会对不同的框架进行适配和支持，欢迎对微前端改造有兴趣或者有项目改造需求的小伙伴与民生apollo前端团队联系交流。

结语

以上就是我们团队在民生APaaS和PSET平台项目微前端改造与实践方面的一些经验。对于微前端探索之路还很漫长，相信在微前端这样的架构基础上，各平台的前端集成及团队管理效率会有所提升。我们也会加深加强对微前端的学习及思考，与民生apollo前端团队保持良好的沟通和交流，使微前端可以在技术层面上不断完善。如果大家在使用微前端进行项目改造时遇到什么问题或困难，也可以联系我们，一起学习，交流经验。相信随着不断的探索和改进，微前端一定能够更加符合项目需求，为项目提供更好的服务，这也是我们前端软件工程的探索方向，希望这些能够对大家有所帮助。

联系方式： pset@cmbc.com.cn yanlihui@mskj.com