DDD 实战课
欧创新
人保资深架构师
55517 人已学习
新⼈⾸单¥59
登录后,你可以任选2讲全文学习
课程目录
已完结/共 26 讲
开篇词 (1讲)
DDD 实战课
15
15
1.0x
00:00/00:00
登录|注册

17 | 从后端到前端:微服务后,前端如何设计?

高度复用性
降低技术敏感性
更敏捷地发布
降低沟通和测试成本
隔离和依赖性
项目职责专一
前端集成简单
微服务、微前端、业务单元、前端主页面、业务流程说明
微前端独立开发、独立部署,与微服务完成集成
利用页面路由和动态加载技术,实现动态加载微前端页面
结合公司业务场景,思考是否可以采用微前端设计,降低前后端集成的复杂度
微前端设计方法的主要价值和意义
保险产品的全险种销售
中台项目团队职责:完成业务单元的开发、测试和集成
前端项目团队职责:前端主页面与微前端的集成
微前端与微服务的集成
微前端与前端主页面的集成
通用共享业务单元:一个微前端与一个或多个通用中台微服务组合
组合业务单元:一个微前端与多个微服务组成
单一业务单元:一个微前端和一个微服务组成
目的是实现独立开发、测试、部署和运维,以适应业务快速变化及分布式多团队并行开发的要求
拆分前端页面,构建独立部署、完全自治、松耦合的页面组合,即微前端
借鉴微服务的设计思想,引入微前端概念
企业需要缩减和整合APP,提高用户体验
5G和移动互联技术的应用导致业务进一步移动化和线上化
前端越来越臃肿、难以维护
思考题
总结
保险微前端设计的案例
团队职责边界
微前端的集成方式
业务单元的组合形态
从单体前端到微前端
单体前端的困境
从后端到前端:微服务后,前端如何设计?

该思维导图由 AI 生成,仅供参考

你好,我是欧创新。
微服务架构通常采用前后端分离的设计方式。作为企业级的中台,在完成单体应用拆分和微服务建设后,前端项目团队会同时面对多个中台微服务项目团队,这时候的前端人员就犹如维修电工一样了。
面对如此多的微服务暴露出来的 API 服务,如何进行正确的连接和拼装,才能保证不出错?这显然不是一件很容易的事情。而当服务出现变更时,又如何通知所有受影响的项目团队,这里面的沟通成本相信也不小。
相应的,要从一定程度上解决上述问题,我们是不是可以考虑先有效降低前端集成的复杂度呢?先做到前端聚合,后端解耦——这是一个很有意思的话题。今天我们就一起来聊聊微前端(Micro Frontend)的设计思想,探讨一下中台微服务后,前后端的设计和集成方式。

单体前端的困境

传统企业在完成中台转型后,虽然后台的业务完成了微服务架构的升级,但前端仍然是单体模式,由一个团队创建并维护一个前端应用。随着时间推移和业务发展,前端会变得越来越臃肿,越来越难维护。而随着 5G 和移动互联技术的应用,企业业务活动将会进一步移动化和线上化。过去很多企业的做法是为不同的业务开发出独立的 APP。但很显然用户并不想装那么多的 APP!
为了提高用户体验,实现统一运营,很多企业开始缩减和整合 APP,将企业内所有的业务能力都尽量集中到一个 APP 中。试想如果仍然沿用单体前端的设计模式。前端项目团队将面对多个中台微服务团队,需要集成成千上万的 API 服务,这就需要相当高的沟通成本和技术要求。这绝对会是一场灾难。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文介绍了微前端设计思想及其在保险行业的应用案例。微前端是一种将前端页面拆分为多个独立部署、自治、松耦合的页面组合的设计思想,旨在降低前端集成的复杂度。文章详细介绍了微前端的设计原则和实现方式,包括微服务、微前端、业务单元、前端主页面以及业务流程的设计。通过微前端的设计,可以实现前端界面融合和后端中台解耦,降低前后端集成的复杂度,提高交付效率和用户体验。文章还探讨了微前端设计的主要价值和意义,包括简化前端集成、降低沟通和测试成本、更敏捷地发布等方面。最后,文章提出了一个思考题,鼓励读者结合自身业务场景,思考是否可以采用微前端的设计来降低前后端集成的复杂度。整体而言,本文通过具体案例和详细分析,全面介绍了微前端设计思想及其在实际应用中的优势,对于读者了解微前端的概念和应用具有很高的参考价值。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《DDD 实战课》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(32)

  • 最新
  • 精选
  • 深山小书童
    整个专栏反反复复听了好几遍,慢慢理解之后,确实感觉干货满满,谢谢老师。希望专栏结束之后会有一个github的demo项目进行升华一下,专栏就完美了。

    作者回复: 谢谢你的建议。结束后,我好好准备一下哈。 希望学完后你能成为一个具有战略高度的架构师。

    2019-11-22
    2
    24
  • lin yu
    看着看着就学了76%了,感觉不配合没有一个完整的demo讲,感觉还是云里雾里的,每篇都是点到即止,毕竟《实现领域驱动》这本书京东59也能买到,

    作者回复: 这个专栏主要是从微服务设计和拆分角度,来讲述如何用DDD做中台和微服务设计,每一部分都有自己的设计上的思考,所以在底层代码实现上讲的不多。不是为了纯讲DDD的战术设计方法,这也是这个专栏与其它DDD不一样的地方。不知道你有没有看过实现领域驱动设计这本书没有,你可以将两者结合起来学习。

    2019-11-23
    2
    16
  • Justin
    独立业务单元是好想法,但微前端的组合拼装能力是前提,否则聚合业务场景将很难实施。

    作者回复: 是的,微前端的设计思想很好。而且现在不少互联网大厂比如蚂蚁金服、美团等在不少生产系统已经投入使用了,相信这些技术会越来越成熟。

    2020-01-14
    9
  • 日月星辰
    微前端怎么落地呢?理论我是看懂了,怎么实现每套业务有自己的一套前端页面呢?

    作者回复: 你可以网上找找微前端相关的资料,由于篇幅所限,专栏里面就没有写具体的实现。我记得阿里开源了“乾坤”微前端框架,还有美团也有自己的微前端框架。在我即将出版的书里面也会有相关的技术实现方面的内容,敬请期待。

    2020-06-09
    5
  • 南山
    一直都把自己的思维或者视野限制在了后端以及目前工作接触到的领域,看完之后有了一个整体的认识,以及抬头多看看多想想的念头~

    作者回复: 有时候视角高一点,看到的和想到的会不一样哈。

    2019-11-22
    3
  • MaLu
    前端微服务化,前端+后端构建业务服务组件,还是领域的划分与领域边界的划清。目标还是领域的自治及领域间的链接,从而达到分而治之的效果。建立在规范,一套游戏规则的基础之上,而能更好地集成与组合。前台+中台的都微化,形成一套彻底的解决机制,是很好的实现机制。 但是这里面还是有几个待探究的疑问: 1.集成主页面 - 与微服务的前端页面怎么集成 ? 2.业务单元的如何独善其身,做到真正的自治需要产品需求、前端实现、中台服务实现的顶层设计与边界区分。

    作者回复: 1、现在很多的前端工具比如Vue等,有页面注册和动态加载的机制。前端主页面可以获取到微前端页面url地址后,将对应的微前端页面动态加载到集成主页面。 2、这个确实需要顶层设计,还得有统一的技术标准和开发规范。尤其对于通用能力的复用,还有主页面内不同微前端之间的数据共享。不过现在很多的前端工具都提供这些能力了。

    2019-11-22
    2
    3
  • jun
    前端项目团队会同时面对多个中台微服务项目团队。目前资源能否胜任微服务改造了... ...重构系统改造成微服务模式,仅6人团队是不是不太适合了 ? 个人感觉可能工作量会很大,技术方面是主要问题所在。

    作者回复: 团队规模需要根据具体微服务的功能大小来配置,一般一个微服务团队大小是10-12人,在组建团队时要考虑尽量降低团队之间的沟通成本,将沟通尽量控制在团队内部。

    2020-07-09
    2
  • stubborn
    欧老师,现在类似微前端的商业框架有卖的吗?

    作者回复: 现在应该还没有商业产品。阿里有乾坤,已经开源了,你可以从网上下载试试,包括美团也有不少的微前端的实践。其实你也可以基于现有的前端组件做一些定制性的开发也是可以实现的,比如vue,iframe等,各有所长。

    2020-03-16
    2
  • 发飙的蜗牛
    我现在所参与的项目整体架构有点像这个微前端的设计,我们也是将整个项目划分为几个模块,每个模块由不同团队独立开发,也是前后端分离,独立开发部署,最终给到用户用就是一个整体的系统,只不过我们的前端主页没有那么复杂并不需要专门的团队去做,只是一个header navbar,footer一样而已

    作者回复: 我感觉未来结合小程序的应用背景,加上微服务、DDD以及微前端等技术和设计方法,以及为了面向不同渠道和生态圈的快速发布和集成要求,这种组合体会成为未来的一种趋势。

    2020-03-07
    2
  • 被秒
    对于微前端一直有些困惑,到底是独立页面,还是独立组件。独立页面就是一下放弃了SPA的各种优点,一下回到几年前。 而如果用组件,那其实又增加了开发的复杂度,而且版本发布时候又会有更多的兼容风险。 前端的变更明显比后端要频繁的多,究竟最佳实践是什么。

    作者回复: 确实会有这两种选择,独立页面 OR 独立组件 独立页面的话,这种方案通过路由、Iframe都可以实现不同微前端应用的组合。 独立组件的话,这种方案可采用组件化的方式构建应用,开发成本较高,配合lazyload可实现组件的按需加载。通常用这种方式需要在开发时保持独立开发,但是最终需将各组件或应用进行集成合并。 两者各有优劣: 前者相对实现起来比较简单,而且也可保持前端多技术栈,即通过不同的前端框架来实现。 后者实现会有额外成本,如针对工程的合并集成。但是相比前者在依赖采用同一套,会减少很多开销。 具体如何选择,还需依据项目实际情况来看。

    2019-11-22
    2
收起评论
显示
设置
留言
32
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部