17 | 从后端到前端：微服务后，前端如何设计？
该思维导图由 AI 生成，仅供参考
单体前端的困境
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文介绍了微前端设计思想及其在保险行业的应用案例。微前端是一种将前端页面拆分为多个独立部署、自治、松耦合的页面组合的设计思想，旨在降低前端集成的复杂度。文章详细介绍了微前端的设计原则和实现方式，包括微服务、微前端、业务单元、前端主页面以及业务流程的设计。通过微前端的设计，可以实现前端界面融合和后端中台解耦，降低前后端集成的复杂度，提高交付效率和用户体验。文章还探讨了微前端设计的主要价值和意义，包括简化前端集成、降低沟通和测试成本、更敏捷地发布等方面。最后，文章提出了一个思考题，鼓励读者结合自身业务场景，思考是否可以采用微前端的设计来降低前后端集成的复杂度。整体而言，本文通过具体案例和详细分析，全面介绍了微前端设计思想及其在实际应用中的优势，对于读者了解微前端的概念和应用具有很高的参考价值。
《DDD 实战课》，新⼈⾸单¥59
全部留言(32)
- 最新
- 精选
深山小书童整个专栏反反复复听了好几遍，慢慢理解之后，确实感觉干货满满，谢谢老师。希望专栏结束之后会有一个github的demo项目进行升华一下，专栏就完美了。作者回复: 谢谢你的建议。结束后，我好好准备一下哈。 希望学完后你能成为一个具有战略高度的架构师。
2019-11-22224
lin yu看着看着就学了76%了，感觉不配合没有一个完整的demo讲，感觉还是云里雾里的，每篇都是点到即止，毕竟《实现领域驱动》这本书京东59也能买到，作者回复: 这个专栏主要是从微服务设计和拆分角度，来讲述如何用DDD做中台和微服务设计，每一部分都有自己的设计上的思考，所以在底层代码实现上讲的不多。不是为了纯讲DDD的战术设计方法，这也是这个专栏与其它DDD不一样的地方。不知道你有没有看过实现领域驱动设计这本书没有，你可以将两者结合起来学习。
2019-11-23216
Justin独立业务单元是好想法，但微前端的组合拼装能力是前提，否则聚合业务场景将很难实施。作者回复: 是的，微前端的设计思想很好。而且现在不少互联网大厂比如蚂蚁金服、美团等在不少生产系统已经投入使用了，相信这些技术会越来越成熟。
2020-01-149
日月星辰微前端怎么落地呢？理论我是看懂了，怎么实现每套业务有自己的一套前端页面呢？作者回复: 你可以网上找找微前端相关的资料，由于篇幅所限，专栏里面就没有写具体的实现。我记得阿里开源了“乾坤”微前端框架，还有美团也有自己的微前端框架。在我即将出版的书里面也会有相关的技术实现方面的内容，敬请期待。
2020-06-095
南山一直都把自己的思维或者视野限制在了后端以及目前工作接触到的领域，看完之后有了一个整体的认识，以及抬头多看看多想想的念头~作者回复: 有时候视角高一点，看到的和想到的会不一样哈。
2019-11-223
MaLu前端微服务化，前端+后端构建业务服务组件，还是领域的划分与领域边界的划清。目标还是领域的自治及领域间的链接，从而达到分而治之的效果。建立在规范，一套游戏规则的基础之上，而能更好地集成与组合。前台+中台的都微化，形成一套彻底的解决机制，是很好的实现机制。 但是这里面还是有几个待探究的疑问： 1.集成主页面 - 与微服务的前端页面怎么集成 ？ 2.业务单元的如何独善其身，做到真正的自治需要产品需求、前端实现、中台服务实现的顶层设计与边界区分。作者回复: 1、现在很多的前端工具比如Vue等，有页面注册和动态加载的机制。前端主页面可以获取到微前端页面url地址后，将对应的微前端页面动态加载到集成主页面。 2、这个确实需要顶层设计，还得有统一的技术标准和开发规范。尤其对于通用能力的复用，还有主页面内不同微前端之间的数据共享。不过现在很多的前端工具都提供这些能力了。
2019-11-2223- jun前端项目团队会同时面对多个中台微服务项目团队。目前资源能否胜任微服务改造了... ...重构系统改造成微服务模式，仅6人团队是不是不太适合了 ？ 个人感觉可能工作量会很大，技术方面是主要问题所在。
作者回复: 团队规模需要根据具体微服务的功能大小来配置，一般一个微服务团队大小是10-12人，在组建团队时要考虑尽量降低团队之间的沟通成本，将沟通尽量控制在团队内部。
2020-07-092 
stubborn欧老师，现在类似微前端的商业框架有卖的吗？作者回复: 现在应该还没有商业产品。阿里有乾坤，已经开源了，你可以从网上下载试试，包括美团也有不少的微前端的实践。其实你也可以基于现有的前端组件做一些定制性的开发也是可以实现的，比如vue，iframe等，各有所长。
2020-03-162
发飙的蜗牛我现在所参与的项目整体架构有点像这个微前端的设计，我们也是将整个项目划分为几个模块，每个模块由不同团队独立开发，也是前后端分离，独立开发部署，最终给到用户用就是一个整体的系统，只不过我们的前端主页没有那么复杂并不需要专门的团队去做，只是一个header navbar，footer一样而已作者回复: 我感觉未来结合小程序的应用背景，加上微服务、DDD以及微前端等技术和设计方法，以及为了面向不同渠道和生态圈的快速发布和集成要求，这种组合体会成为未来的一种趋势。
2020-03-072
被秒对于微前端一直有些困惑，到底是独立页面，还是独立组件。独立页面就是一下放弃了SPA的各种优点，一下回到几年前。 而如果用组件，那其实又增加了开发的复杂度，而且版本发布时候又会有更多的兼容风险。 前端的变更明显比后端要频繁的多，究竟最佳实践是什么。作者回复: 确实会有这两种选择，独立页面 OR 独立组件 独立页面的话，这种方案通过路由、Iframe都可以实现不同微前端应用的组合。 独立组件的话，这种方案可采用组件化的方式构建应用，开发成本较高，配合lazyload可实现组件的按需加载。通常用这种方式需要在开发时保持独立开发，但是最终需将各组件或应用进行集成合并。 两者各有优劣： 前者相对实现起来比较简单，而且也可保持前端多技术栈，即通过不同的前端框架来实现。 后者实现会有额外成本，如针对工程的合并集成。但是相比前者在依赖采用同一套，会减少很多开销。 具体如何选择，还需依据项目实际情况来看。
2019-11-222
