17 | 从后端到前端：微服务后，前端如何设计？

Nov 22, 2019

17 | 从后端到前端：微服务后，前端如何设计？-极客时间



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

17 | 从后端到前端：微服务后，前端如何设计？

2019-11-22 欧创新来自北京

《DDD实战课》

课程介绍



讲述：欧创新

时长21:11大小14.52M



你好，我是欧创新。
微服务架构通常采用前后端分离的设计方式。作为企业级的中台，在完成单体应用拆分和微服务建设后，前端项目团队会同时面对多个中台微服务项目团队，这时候的前端人员就犹如维修电工一样了。
面对如此多的微服务暴露出来的 API 服务，如何进行正确的连接和拼装，才能保证不出错？这显然不是一件很容易的事情。而当服务出现变更时，又如何通知所有受影响的项目团队，这里面的沟通成本相信也不小。
相应的，要从一定程度上解决上述问题，我们是不是可以考虑先有效降低前端集成的复杂度呢？先做到前端聚合，后端解耦——这是一个很有意思的话题。今天我们就一起来聊聊微前端（Micro Frontend）的设计思想，探讨一下中台微服务后，前后端的设计和集成方式。
单体前端的困境传统企业在完成中台转型后，虽然后台的业务完成了微服务架构的升级，但前端仍然是单体模式，由一个团队创建并维护一个前端应用。随着时间推移和业务发展，前端会变得越来越臃肿，越来越难维护。而随着 5G 和移动互联技术的应用，企业业务活动将会进一步移动化和线上化。过去很多企业的做法是为不同的业务开发出独立的 APP。但很显然用户并不想装那么多的 APP！
为了提高用户体验，实现统一运营，很多企业开始缩减和整合 APP，将企业内所有的业务能力都尽量集中到一个 APP 中。试想如果仍然沿用单体前端的设计模式。前端项目团队将面对多个中台微服务团队，需要集成成千上万的 API 服务，这就需要相当高的沟通成本和技术要求。这绝对会是一场灾难。
相对互联网企业而言，传统企业的渠道应用更加多样化，有面向内部人员的门店类应用、面向外部客户的互联网电商平台或移动 APP，还有面向第三方的 API 集成。由于渠道的差异，前端将更加多样化和复杂化。那如何有效降低前端集成的复杂度呢？
从单体前端到微前端为了解决单体前端的问题，我们可以借鉴微服务的设计思想，引入微前端概念。将微服务理念扩展到前端，解决中台微服务化后，前端由于仍为单体而存在的逻辑复杂和臃肿的问题。
在前端设计时我们需要遵循单一职责和复用原则，按照领域模型和微服务边界，将前端页面进行拆分。同时构建多个可以独立部署、完全自治、松耦合的页面组合，其中每个组合只负责特定业务单元的 UI 元素和功能，这些页面组合就是微前端。
微前端与微服务一样，都是希望将单体应用，按照规则拆分，并重组为多个可以独立开发、独立测试、独立部署和独立运维，松耦合的微前端或者微服务。以适应业务快速变化及分布式多团队并行开发的要求。
微前端页面只包括业务单元前端操作必需的页面要素，它只是企业级完整业务流程中的一个业务拼图块，不包含页面导航等内容。微前端除了可以实现前端页面的解耦外，还可实现页面复用，这也与中台服务共享理念是一脉相承的。
业务单元的组合形态我们可以参照领域模型和微服务边界，建立与微服务对应的前端操作界面，将它与微服务组成业务单元，以业务组件的方式对外提供服务。业务单元包括微前端和微服务，可以独立开发、测试、部署和运维，可以自包含地完成领域模型中部分或全部的业务功能。
我们看一下下面这个图。一个虚框就是一个业务单元，微前端和微服务独立部署，业务单元内的微前端和微服务已完成前后端集成。你可以将这个业务单元理解为一个特定业务领域的组件。业务单元可以有多种组合方式，以实现不同的业务目标。
1. 单一业务单元一个微前端和一个微服务组成单一业务单元。微前端和微服务分别实现同一个领域模型从前端到后端的功能。
2. 组合业务单元一个微前端与多个微服务组成组合业务单元。微前端具有多个微服务的前端功能，完成较复杂的页面和操作。多个微服务实现各自领域模型的功能，向微前端提供可组合的服务。
记住一点：微前端不宜与过多的微服务组合，否则容易变成单体前端。
3. 通用共享业务单元一个微前端与一个或多个通用中台微服务组合为通用共享业务单元。通用共享微前端以共享页面的方式与其它微前端页面协作，完成业务流程。很多通用中台微服务的微前端是共享的，比如订单和支付等微服务对应的订单和支付微前端界面。
所有业务单元的功能都应该自包含，业务单元之间的边界清晰。业务单元之间要避免功能交叉而出现耦合，一旦出现就会影响项目团队职责边界，进而影响到业务单元独立开发、测试、部署和运维等。
微前端的集成方式我们看一下下面这个图，微前端位于前端主页面和微服务之间，它需要与两者完成集成。
1. 微前端与前端主页面的集成前端主页面是企业级的前端页面，微前端是业务单元的前端页面。微前端通过主页面的微前端加载器，利用页面路由和动态加载等技术，将特定业务单元的微前端页面动态加载到前端主页面，实现前端主页面与微前端页面的“拼图式”集成。
微前端完成开发、集成和部署后，在前端主页面完成微前端注册以及页面路由配置，即可实现动态加载微前端页面。
2. 微前端与微服务的集成微前端与微服务独立开发，独立部署。在微前端注册到前端主页面前，微前端需要与微服务完成集成。它的集成方式与传统前后端分离的集成方式没有差异。微服务将服务发布到 API 网关，微前端调用发布在 API 网关中的服务，即完成业务单元内的前后端集成。
团队职责边界当你采用业务单元化的开发方式后，前后端项目团队职责和应用边界会更清晰，可以降低前后端集成的复杂度。我们看一下前中台团队的职责分工。
前端项目团队专注于前端集成主页面与微前端的集成，完成前端主页面的企业级主流程的页面和流程编排以及微前端页面的动态加载，确保主流程业务逻辑和流程正确。前端项目除了要负责企业内页面风格的整体风格设计、业务流程的流转和控制外，还需要负责微前端页面动态加载、微前端注册、页面路由和页面数据共享等前端技术的实现。
中台项目团队完成业务单元组件的开发、测试和集成，确保业务单元内的业务逻辑、页面和流程正确，向外提供包含页面逻辑和业务逻辑的业务单元组件。
这样，前端项目团队只需要完成企业级前端主页面与业务单元的融合，前端只关注前端主页面与微前端页面之间的集成。这样就可以降低前端团队的技术敏感度、团队的沟通成本和集成复杂度，提高交付效率和用户体验。
中台项目团队关注业务单元功能的完整性和自包含能力，完成业务单元内微服务和微前端开发、集成和部署，提供业务单元组件。这样，业务单元的微前端与微服务的集成就会由一个中台团队完成，熟悉的人干熟悉的事情，可以降低集成过程中的沟通和技术成本，加快开发效率。
一个有关保险微前端设计的案例保险公司有很多面向不同场景的保险产品，由于业务场景不同，其核心领域模型就会有差异，在页面要素、业务规则和流程等方面前端界面也会不同。为了避免领域模型差异较大的产品之间的相互影响和干扰，我们可以将相似的领域模型的保险产品聚合在一起，完成核心中台设计。
那有的保险集团为了统一运营，会实现寿险、财险等集团化的全险种销售。这样前端项目团队就需要用一个前端应用，集成非常多的不同产品的核心中台微服务，前端应用与中台微服务之间的集成将会更复杂。
如果仍然采用传统的单体前端模式，将会面临比较大的困难。
第一是前端页面开发和设计的复杂性。以录单前端为例，如果用一个前端页面来适配全险种，由于不同产品的前端页面要素不同，需要妥协并兼容所有产品界面的差异，这会增加前端开发的复杂度，也影响用户体验。而如果为每类产品开发不同的前端，前端项目团队需要在页面开发和设计上，投入巨大的工作量。
第二是前端与微服务集成的复杂性。在前端与微服务集成时，前端项目团队需要了解所有产品的 API 详细信息，完成前端与微服务的集成，还要根据主页面流程，实现不同产品的 API 服务路由。大量的 API 服务集成和服务路由，会增加系统集成的复杂度和出错的概率。
第三是前后端软件版本的协同发布。关联的应用多了以后，一旦某一个中台微服务的 API 服务出现重大调整，就需要协调所有受影响的应用同时完成版本发布，频繁的版本发布会影响不同产品的正常运营。
那如何用一个前端应用实现全险种产品销售呢？怎样设计才能降低集成的复杂度，实现前端界面融合，后端中台解耦呢？
我们看一下下面这个图。我们借鉴了电商的订单模式实现保险产品的全险种订单化销售，在一个前端主页面可以将所有业务流程和业务操作无缝串联起来。虽然后端有很多业务单元（包含微服务和微前端），但用户始终感觉是在一个前端应用中操作。
要在一个前端应用中实现全险种销售，需要完成以下内容的设计。
1. 微服务微服务分为两类，一类是核心中台微服务，包括：投保微服务，实现核心出单业务逻辑；另一类是通用中台微服务，包括如：商品、订单、购物车和支付等微服务，实现通用共享业务逻辑。
2. 微前端每个微服务都有自己的微前端页面，实现领域模型的微服务前端页面操作。核心中台投保微服务有出单微前端。订单、商品以及支付微服务都有自己的微前端页面。
3. 业务单元微服务与微前端组合为一个业务单元。由一个中台团队完成业务单元的开发、集成、测试和部署，确保业务单元内页面操作和业务逻辑正确。比如：投保微服务和出单微前端组合为投保业务单元，独立完成保险产品从前端到后端的投保业务。
4. 前端主页面前端主页面类似门户，包括页面导航以及部分通用的常驻主页面的共享页面，比如购物车。前端主页面和所有微前端应统一界面风格，符合统一的前端集成规范。按照正确的业务逻辑和规则，动态加载不同业务单元的微前端页面。前端主页面作为一个整体，协调核心和通用业务单元的微前端页面，完成业务操作和业务流程，提供全险种销售接触界面，包括商品目录、录单、购物车、订单、支付等操作。
5. 业务流程说明我来简要说明一下用户在前端主页面的投保的主要业务流程。
第 1 步：用户在前端主页面，从商品目录微前端页面，选择保险产品。
第 2 步：前端主页面根据选择的产品，从主页面配置数据中，获取产品出单微前端路由地址。加载出单微前端页面，完成录单，投保微服务实现投保业务逻辑，在业务单元内生成投保单。
第 3 步：加载购物车微前端，将投保单加入购物车。
第 4 步：重复 1-3 步，生成多个投保单。
第 5 步：从购物车微前端中选择多个投保单，加载订单微前端，生成订单。
第 6 步：加载支付微前端，完成支付。
第 7 步：在投保微服务中，将订单中的投保单生成保单。
虽然后端有很多业务单元在支持，但用户所有的页面操作和流转是在一个前端主页面完成的。在进行全险种的订单化销售时，用户始终感觉是在操作一个系统。这种设计方式很好地体现了前端的融合和中台的解耦。
总结今天我们主要探讨了微前端的设计方法。虽然微前端和微服务也采用前后端分离的设计方式，但在业务单元内，它们是在同一个领域模型下，分别实现前端和后端的业务逻辑，对外提供组件化的服务。
微前端和业务单元化的设计模式可以减轻企业级中台，前后端应用开发和集成的复杂度，真正实现前端融合和中台解耦。它的主要价值和意义如下：
1. 前端集成简单：前端项目只需关注前端集成主页面与微前端的集成，实现模块化集成和拼图式的开发，降低前端集成的复杂度和成本。
2. 项目职责专一：中台项目从数据库、中台微服务到微前端界面，端到端地完成领域逻辑功能开发，以业务组件的方式整体提供服务。在业务单元内，由团队自己完成前后端集成，可以降低开发和集成团队的沟通成本和集成复杂度。
3. 隔离和依赖性：业务单元在代码、逻辑和物理边界都是隔离的，可降低应用之间的依赖性。出现问题时可快速定位和修复，问题可以控制在一个业务单元内。业务单元之间相互无影响。
4. 降低沟通和测试成本：中台团队实现从微前端页面到中台微服务的业务单元逻辑，实现业务单元的开发、测试、集成和部署的全流程和全生命周期管理，降低前后端集成的测试和沟通成本。
5. 更敏捷地发布：业务单元之间有很好的隔离性和依赖性低，业务单元的变化都可以被控制在业务单元内。项目团队可以独立按照自己的步调进行迭代开发，实现更快的发布周期。版本发布时不会影响其它业务单元的正常运行。
6. 降低技术敏感性：前端项目关注前端主页面与微前端的集成。降低了前端项目团队对中台微服务技术的敏感性。中台项目团队可以更独立地尝试新技术和架构，实现架构的演进。
7. 高度复用性：微前端和中台微服务都有高度的复用性。微前端可快速加载到多个 APP，还可以将一个微前端直接发布为 APP 或微信小程序，实现灵活的前端组合、复用和快速发布。
思考题结合你公司的业务场景，思考一下是否可以采用微前端的设计，降低前后端集成的复杂度？期待你的分享！

分享给需要的人，Ta购买本课程，你将得18元

生成海报并分享

赞 16

提建议

16 | 视图：如何实现服务和数据在微服务各层的协作？

18 | 知识点串讲：基于DDD的微服务设计实例

 写留言

精选留言(32)

深山小书童
2019-11-22
整个专栏反反复复听了好几遍，慢慢理解之后，确实感觉干货满满，谢谢老师。希望专栏结束之后会有一个github的demo项目进行升华一下，专栏就完美了。
作者回复: 谢谢你的建议。结束后，我好好准备一下哈。希望学完后你能成为一个具有战略高度的架构师。
共 2 条评论
23
lin yu
2019-11-23
看着看着就学了76%了，感觉不配合没有一个完整的demo讲，感觉还是云里雾里的，每篇都是点到即止，毕竟《实现领域驱动》这本书京东59也能买到，
作者回复: 这个专栏主要是从微服务设计和拆分角度，来讲述如何用DDD做中台和微服务设计，每一部分都有自己的设计上的思考，所以在底层代码实现上讲的不多。不是为了纯讲DDD的战术设计方法，这也是这个专栏与其它DDD不一样的地方。不知道你有没有看过实现领域驱动设计这本书没有，你可以将两者结合起来学习。
共 2 条评论
15
Justin
2020-01-14
独立业务单元是好想法，但微前端的组合拼装能力是前提，否则聚合业务场景将很难实施。
作者回复: 是的，微前端的设计思想很好。而且现在不少互联网大厂比如蚂蚁金服、美团等在不少生产系统已经投入使用了，相信这些技术会越来越成熟。
9
日月星辰
2020-06-09
微前端怎么落地呢？理论我是看懂了，怎么实现每套业务有自己的一套前端页面呢？
作者回复: 你可以网上找找微前端相关的资料，由于篇幅所限，专栏里面就没有写具体的实现。我记得阿里开源了“乾坤”微前端框架，还有美团也有自己的微前端框架。在我即将出版的书里面也会有相关的技术实现方面的内容，敬请期待。
5
南山
2019-11-22
一直都把自己的思维或者视野限制在了后端以及目前工作接触到的领域，看完之后有了一个整体的认识，以及抬头多看看多想想的念头~
作者回复: 有时候视角高一点，看到的和想到的会不一样哈。
3
MaLu
2019-11-22
前端微服务化，前端+后端构建业务服务组件，还是领域的划分与领域边界的划清。目标还是领域的自治及领域间的链接，从而达到分而治之的效果。建立在规范，一套游戏规则的基础之上，而能更好地集成与组合。前台+中台的都微化，形成一套彻底的解决机制，是很好的实现机制。但是这里面还是有几个待探究的疑问： 1.集成主页面 - 与微服务的前端页面怎么集成？ 2.业务单元的如何独善其身，做到真正的自治需要产品需求、前端实现、中台服务实现的顶层设计与边界区分。
展开
作者回复: 1、现在很多的前端工具比如Vue等，有页面注册和动态加载的机制。前端主页面可以获取到微前端页面url地址后，将对应的微前端页面动态加载到集成主页面。 2、这个确实需要顶层设计，还得有统一的技术标准和开发规范。尤其对于通用能力的复用，还有主页面内不同微前端之间的数据共享。不过现在很多的前端工具都提供这些能力了。
共 2 条评论
3
发飙的蜗牛
2020-03-07
我现在所参与的项目整体架构有点像这个微前端的设计，我们也是将整个项目划分为几个模块，每个模块由不同团队独立开发，也是前后端分离，独立开发部署，最终给到用户用就是一个整体的系统，只不过我们的前端主页没有那么复杂并不需要专门的团队去做，只是一个header navbar，footer一样而已
作者回复: 我感觉未来结合小程序的应用背景，加上微服务、DDD以及微前端等技术和设计方法，以及为了面向不同渠道和生态圈的快速发布和集成要求，这种组合体会成为未来的一种趋势。
2
被秒
2019-11-22
对于微前端一直有些困惑，到底是独立页面，还是独立组件。独立页面就是一下放弃了SPA的各种优点，一下回到几年前。而如果用组件，那其实又增加了开发的复杂度，而且版本发布时候又会有更多的兼容风险。前端的变更明显比后端要频繁的多，究竟最佳实践是什么。
作者回复: 确实会有这两种选择，独立页面 OR 独立组件独立页面的话，这种方案通过路由、Iframe都可以实现不同微前端应用的组合。独立组件的话，这种方案可采用组件化的方式构建应用，开发成本较高，配合lazyload可实现组件的按需加载。通常用这种方式需要在开发时保持独立开发，但是最终需将各组件或应用进行集成合并。两者各有优劣：前者相对实现起来比较简单，而且也可保持前端多技术栈，即通过不同的前端框架来实现。后者实现会有额外成本，如针对工程的合并集成。但是相比前者在依赖采用同一套，会减少很多开销。具体如何选择，还需依据项目实际情况来看。
2
jun
2020-07-09
前端项目团队会同时面对多个中台微服务项目团队。目前资源能否胜任微服务改造了... ...重构系统改造成微服务模式，仅6人团队是不是不太适合了？个人感觉可能工作量会很大，技术方面是主要问题所在。
作者回复: 团队规模需要根据具体微服务的功能大小来配置，一般一个微服务团队大小是10-12人，在组建团队时要考虑尽量降低团队之间的沟通成本，将沟通尽量控制在团队内部。
2
小之
2020-04-12
老师真是干货满满，这篇文章让我对 “大中台，小前端“ 的理解又深了一步！
作者回复: 谢谢
1
stubborn
2020-03-16
欧老师，现在类似微前端的商业框架有卖的吗？
作者回复: 现在应该还没有商业产品。阿里有乾坤，已经开源了，你可以从网上下载试试，包括美团也有不少的微前端的实践。其实你也可以基于现有的前端组件做一些定制性的开发也是可以实现的，比如vue，iframe等，各有所长。
1
九五二七
2022-11-01 来自北京
我们公司就是这么设计的，开始的时候我还不明白为啥所有的业务都在一个页面中集成，看了文章后明白了。另外在前端页面中也方面用户管理和权限管理（只需要开发一次），我们公司的前端页面的用户是与OA用户打通的（只需要打通一次）。
Paradise
2022-04-22
感谢老师分享，但是目前看到的微前端大部分都是为了解决系统级遗留问题而引入的微前端，比较少是以DDD为出发点而执行的微前端嘿嘿。。
徐李
2021-12-20
这里的微前端，就是要一处地方改动了处处一样。但是现实场景中，可能是很多前端公用一个后台，但是页面都是定制化的。那这种就不太合适了。当然对于这种页面也采用微服务的方式进行拆分确实是一个很好的思想，隔离，分别开发，分别部署
木木
2021-11-07
权限怎么处理？😨😨，最大的困惑就是这块，如何全盘统筹这一块，菜单权限，按钮权限，数据权限等
剑八
2021-08-24
看最终集成复杂度，相应的微服务集成问题等弊端，是否大于微前端带来的减少集成复杂度，提升复用性的好处整个架构是前端有一集成页面做路由配置，然后会有相应的微前端，与微服务后端。微前端与微服务后端组成一个业务单元。
Quentin J.
2021-08-01
ddd的微前端是不是和低代码/零代码也是相关的? 他们的关系是什么呢
xxx
2021-07-25
总结：前端总是从后端抄一些玩烂了的概念，然后包装成高大上的东西去忽悠——毕竟同行们都不懂😂
Geek
2021-03-10
老师是怎么保证DDD的落地呢，如何保证每个开发人员都按照DDD的原则进行设计和开发呢
小炭
2020-12-20
微前端的拆分的粒度过小，都是动态加载会不会造成有性能问题。不知道老师所采用的微前端方案是单编程语言还是多编程语言的。
作者回复: 在微前端设计时，需要考虑微前端可以自包含的完成业务单元的业务逻辑，这样就可以保持微前端功能的独立性。这样就不会存在在Base主页面来回动态加载微前端页面的情况。如果不是遗留系统的话，建议还是尽量统一微前端语言。

