中台微服务了，那前端呢？

前段时间作者写了《当中台遇到DDD，我们该如何设计微服务？》这篇文章，文章中详细描述了基于DDD设计思想的中台微服务设计方法以及分布式架构实施过程中的关注点等内容。中台建设完成后，通过微服务实现了后端应用的解耦，提高了中台应用的弹性伸缩能力。但由于微服务拆分，也会导致项目团队和服务的碎片化，给前端项目集成带来一定的复杂度。

微服务架构通常采用前后端分离方式，中台服务通过API网关对外发布，单体应用拆分后一个前端项目可能会面对多个中台微服务项目。前端开发人员犹如维修电工一样，将面对成千上万中台团队开发出来的API接头，如何正确的连接和拼装，并且保证不出错，不是一件很容易的事情。而当中台API出现变更时，又如何通知所有受影响的前端项目团队同步调整和版本协同发布，需要的沟通成本相信也不小。

如何降低前端集成的复杂度？做到后端解耦，前端聚合？这是一个很有意思的话题。

本文主要借鉴微前端设计思想，参考微服务单一职责和共享原则将前端进行拆分和组合。从功能垂直的角度，将微前端与中台微服务进行集成和组合，形成从前端到后端可独立开发、测试、部署和运维的，领域功能自包含的业务单元。

前端页面通过微前端加载器，利用页面路由和动态加载等技术，实现前端集成主页面与微前端的“拼图式”开发。前端集成项目团队只需关注前端整体风格、微前端之间的数据交互和页面路由等内容，不涉及前端与中台之间以及中台与中台之间的API集成，从而降低集成过程中的技术敏感度、团队沟通成本和集成复杂度，提高交付效率和用户体验。

本文最后通过保险订单销售模式设计案例来说明如何进行前端设计。

微前端概述

微前端概念是ThoughtWorks在2016年提出来的，它将微服务理念扩展到前端开发，解决中台微服务化后，前端由于仍为单体而存在的逻辑繁杂和臃肿的问题。微前端是按照前端设计方法在前端同时构建多个可以独立部署、完全自治、松耦合的页面组合，其中每个组合只负责特定的 UI 元素和功能。

微前端与微服务都是希望将单体应用，按照一定的规则拆分为多个可以独立运行、独立开发、独立部署、独立运维的微服务或者页面聚合，从而满足业务快速变化及分布式多团队并行开发的需求。

微前端除了可以实现前端页面的解耦外，还可实现前端页面的复用，做到“一次开发，多端复用”，这也与中台服务共享理念是一脉相承。

从单体前端到微前端

传统的软件项目往往采用单体式架构，前端往往由一个团队创建并维护一个 Web 应用程序，通过API网关从微服务调用服务。随着时间的推移，前端往往会越来越臃肿，越来越难维护。

随着5G技术的应用，企业活动将进一步移动化和线上化，过去企业的通常做法是为不同的应用开发出很多独立的APP。但是用户来并不想装那么多APP！

为了提高用户体验，实现统一运营，很多企业开始缩减APP的数量，通过一个APP集成所有应用功能。试想如果将企业内所有前端页面、流程设计以及前端与后端集成的工作都交给前端项目，将原来独立和分散的应用，展示在一个巴掌大的手机屏幕上。前端项目将会面对无数的中台项目和成千上万不太熟悉的API接口，这绝对会是一场灾难。

相对互联网企业而言，传统企业的渠道应用更多样化，有面向内部人员的柜台类应用、面向外部客户的互联网电商及移动APP类应用，还有面向商业生态圈的第三方API集成。由于渠道的差异，传统企业前端设计将会更多样化和复杂化。

传统企业在实施中台战略时，为满足前端和中台多渠道共享和复用，部分场景还应有别于阿里巴巴的中台战略。传统企业除了要像阿里巴巴一样进行通用共享服务（主要提供共享API）的中台化建设外，还需要对核心专属业务（除API外，还存在大量面向用户的页面）进行中台化建设，以满足不同渠道的业务复用的需求。