微前端的业务划分方式
@ 姜波 | 星期四,十一月 12 日,2020 年 | 2 分钟阅读 | 更新于 星期四,十一月 12 日,2020 年

按照业务拆分

  • 可能同时存在多个系统,每个系统都代表自己的业务
  • 它们之间的关联可能并不是很紧密,对于前端应用来说,只需要一个系统内对象的ID,加上用户的Token,便能轻松从一个系统跳转到另外一个系统中
  • 如果业务间本身的耦合就比较严重,那么要从前端业务上分离它们,就不是很容易

按照权限拆分

  • 对于一个同时存在多种角色及多种不同权限的网站来说,最容易采用的方案就是通过权限来划分服务和应用
  • 是否按照权限来划分应当取决于应用是否臃肿,或者是否正在变得臃肿,导致难以维护,还需要考虑是否为每种角色和权限划分出不同的前端应用

按照变更频率拆分

  • 在一个前端应用中,并非所有模块和业务代码都在不断地修改、添加新的功能,不同的业务模块拥有不同的变更频率
  • 若是将应用中频繁变更的部分拆分出来,不仅更容易维护其他部分的代码,还可以减少频繁的业务修改给其他部分带来的问题
  • 使用变更频率进行拆分的前提是,我们使用数据统计来计算各部分的使用情况

按照组织结构拆分

  • 团队的组织方式必然会对它产生的代码有影响,根据不同团队来划分不同的微前端应用及服务
  • 与业务划分方式稍有区别,一个团队可能维护多个业务
  • 对于跨团队协作来说,集成永远都是一个复杂的问题,尤其在团队本身是异地开发的情况下,沟通就变成一个麻烦的问题

跟随后端微服务拆分

  • 与微架构相关的实施,并不只有前端才有,往往是后端拥有和相应的实施,前端项目才会进行进一步的拆分

  • 然而后端采用的拆分方式,并不都适合于前端应用,可能多数时候不适合

  • 后端可能采取聚合关系来划分微服务,这时对于前端应用来说并没有多大的启发

公众号

Image text

QQ

Image text

微信

Image text

微信打赏

Image text

社交链接