微前端——前端开发新体验

工程项目组在去年采用微后端构架重新构筑了两个要道公交站点。透过导入微后端构架，化解了乙烯构架下、多工程项目组协作所产生的此消彼长，互相依赖的难题，使得工程项目组更大程度的获得了自主权。责任编辑挑选出销售业务数学模型，控制技术课堂教学，服务资产管理三个视点，透过分析工程项目插值合作开发存有的难题，尝试说明原有乙烯构架下的关键点，和导入微后端如何化解关键点难题，从而改善各工程项目组工作方式。最后，他们将总结分享在对要道公交站点进行微后端改造操作过程中所吸取到的经验和教训。

前日，工程项目组构筑了两个服务平台要道公交站点，须要软件系统数个控制系统，主要包括：订货控制系统，偏爱所推荐控制系统，商品控制系统等；历时半年，选择React & Redux做为后端合作开发框架和工具，采用Kotlin做为BFF合作开发语言，以乙烯应用的形式，工程项目组将该要道公交站点正式发布到AWS中投入采用。此后的几个月，随著交货更替，随著越来越多工程项目组加入，他们遇到了一些工程项目组协作的难题。销售业务数学模型 – 交货方案此消彼长和巨额的沟通交流生产成本以订货，偏好所推荐和商品为例，右图描述了该公交站点上各工程项目组的销售业务数学模型：由图中灰框由此可知，工程项目分为前后端两部分：后端和相应的BFF，数个工程项目组在完全相同的标识符库房中共享资源标识符，共享资源自然环境，协作合作开发。这种数学模型存有的难题是：当某工程项目组的一次更新负面影响范围极广时，很可能会负面影响到其他工程项目组合作开发方案、正式发布方案。对于PM / BA而言，多工程项目组协作工程项目中无谓的谐振会使交货变得不安全且不可预测。两个功能的诞生，从探索，评估，方案，到最终交货，需要跨工程项目组大量沟通交流，主要包括销售业务之间的此消彼长，控制技术决策，交货方案。为了使大部份工程项目组尽可能按方案交货，他们不得已增加协调生产成本并提前方案。不幸的是，通常难题不会在这一操作过程开始时发生，而是直到操作过程后期才被发现。它就像两枚复杂的手榴弹，使估计合宪，降低交货的稳定性和精确性。控制技术课堂教学 – 强制遵循完全相同的课堂教学和控制技术栈右图展示控制技术课堂教学详细情况：透过上图他们看出，数个COBOL工程项目组和两个管理工作工程项目组共享资源标识符库，共享资源电路板，共享自然环境。而做为两个交货工程项目组，即使共享资源，不得已拒绝接受不熟识的控制技术栈；不得已拒绝接受更多电路板运行时间以透过大部份工程项目组的单元测试；即使销售业务关联而不得已互相学习销售基本知识。而互相独立的标识符库、熟识的控制技术栈，高性能快捷的规范原则、合理而高效率的业务流程，才是两个交货工程项目组持续不断追求的理想状态。服务资产管理工作 – 框架或依赖升级带来的负面影响从服务、资产的角度来讲，受限于控制技术构架与课堂教学，数个工程项目组共用完全相同的工件与商品自然环境。为了能够让每一个工程项目组都能正常工作，大家不得已妥协、拒绝接受满足大部份工程项目组的管理工作业务流程。而实际上各工程项目组商品插值正式发布都是对工件和生产自然环境的更新，这种更新须要整体回归测试的保证。甚至线上商品事故支持时，他们须要化解当公交站点产生的事故，如何将错误准确导向特定的合作开发工程项目组的难题。大部份工程项目组经过多次取舍与妥协后，失去了应有的自主权。两个重后端的工程项目中，整体式构架、多工程项目组协作合作开发的模式为他们带来的思考是：销售业务如何做到独立交货？如何做到自主控制技术决策？如何保障工程项目组对服务、商品的绝对控制权？微后端构架很好的回答了以上三个难题。

销售业务交货上，微后端做为DDD在后端的扩展，按照与后端领域完全相同的拆分方法，可以将后端拆分成独立的Mi有独立销售业务价值，销售业务变化完全由各工程项目组自己负责。销售业务变化几乎不会负面影响整个公交站点。同时，做为交货工程项目组，工程项目组可以专注于自己的销售业务领域，创建并维护边界清晰的后端模块，最大程度地降低各领域之间谐振关系。这种清晰的销售业务边界，极低的谐振关系迎合了PM/BA的诉求：销售业务模块足够独立，交货更加安全且可预测，交货方案被负面影响的概率降低。在合作开发模式方面，给与工程项目组足够的自主决策权。工程项目组可以自己决定标识符保存有哪里，灵活选择适合编程语言的编程规范，电路板组成，CD课堂教学等，如右图所示：透过分离最终交货工件，工程项目组获得了独立的标识符库，熟识的控制技术栈，合适的规范，高性能灵活的电路板及高效率的正式发布业务流程。在服务资产管理工作方面，不同工件对应于独立的商品自然环境，达到各Micro App之间商品自然环境隔离的目的。这样，对整个商品自然环境的回归测试变成了对某个Micro App的回归测试。各工程项目组只须要响应自己维护商品的线上事故，对自己负责的Micro App制定On-Call support轮值方案。有关SingleSPA的更多信息，请参考这里。此处仅以偏爱所推荐控制系统为例，展示微后端体系结构中包含的大部份重要组件。用户透过root container访问偏爱所推荐控制系统。一旦root container收到访问偏爱所推荐控制系统的请求，它将透过import-map找到其最新的下载地址。从图中可以看出，偏爱所推荐提醒做为Micro App在自然环境中几乎是完全隔离的，偏爱所推荐工程项目组可以根据须要轻松地对其进行更新。总结起来，微后端改变了多工程项目组的协作方式：

及对工程项目的插值更新。销售业务插值更新取决于工程项目组自身。

能够充分进行自主控制技术决策，维护小而聚合的标识符库及相关基础设施：工程项目组拥有完全自主的决定权，定制更灵活地，符合工程项目组自身和工作内容的控制技术课堂教学。

独立进行测试与部署：更新、升级的负面影响范围被控制在每两个Micro App中，各工程项目组只需负责合作开发、维护自己的Micro App即可。

此外，而上文提到的import-map组件，本质上是一种动态加载JS的机制实现，这种机制为吸引更多人、更多工程项目组、乃至第三方成为所构筑平台的COBOL提供了可能。

微后端构架给工程项目组带来了极大的自主权，工程项目组在领域内、在自己维护的Micro App中获得了极大的自主权，可以更加灵活的选择更合适的方式化解实际的销售业务难题。在认清这些红利外，微后端并不能化解大部份难题，这种构架课堂教学并非没有代价，主要表现在导入的性能难题，要求较高的DevOps和管理工作复杂度。对此他们须要导入其他控制技术手段克服：

性能：导入微后端框架，浏览器加载页面时须要最先加载微后端框架标识符，而后加载各组件和MFA，这无疑加重了浏览器的加载负担。为了减少页面加载时间，一方面须要借助工件最小化，Tree shaking，和在Cloudfront & 浏览器等层面上的缓存等手段加快每两个JS脚责任编辑件的加载速度；另一方面须要在确保功能完整的情况下，尽可能提高JS脚本并行加载能力。

DevOps：微后端构架课堂教学对工程项目组CD能力也有要求。可以说与CD课堂教学相辅相成。透过电路板保持Micro App引用最新，这须要较高的自动化要求和高度Infrastructure as Code课堂教学。而为了高度的自动化，也须要足够有信心的测试覆盖，如此才能保持销售业务的持续交货，持续软件系统。

管理工作复杂度：数个不同的Micro App组件同时加载，透过命名规范可以化解潜在的CSS/JS冲突难题；由于UI在后端被分割成了两个个边界清晰的Micro App，他们须要一定的设计规范，保持跨Micro App的设计一致性，如统一的配色样式，风格接近的操作方式，行为一致的错误处理等。他们相信，再追求高度自治的情况下，并不能以牺牲流畅统一的用户体验为前提。

– 相关阅读 –

&绿色字体部分的相关链接。

  责任编辑版权属ThoughtWorks公司大部份，如需转载请在后台留言联系。