发布时间:2020-08-18 10:24:14
本篇为技术雷达之「微前端」- 将微服务理念扩展到前端开发
摘自技术雷达:我们已经从引入微服务架构中获得了明显的好处,微服务架构可以让团队裁剪出独立部署的交付物以及可维护的服务。不幸的是,我们还看到许多团队在后端服务之上创建了前端单体——一个单一,庞大和杂乱无绪的浏览器应用。我们首选的(经过验证的)方法是将基于浏览器的代码拆分成微前端。在这种方法中,Web 应用程序被分解为多个特性,每个特性都由不同的前后端团队拥有。这确保每个特性都独立于其他特性开发,测试和部署。这样可以使用多种技术来重新组合特性——有时候是页面,有时候是组件——最终整合成一个内聚的用户体验。
在传统的软件开发当中,大多数软件都是单体式应用架构的。在瞬息万变的商业时代背景下,企业必须学会适应我们这个时代的不确定性。快速试验,快速失败。更快地推出新产品和有效地改进当前产品,从而为客户提供有意义的数字体验。
而单体应用这种软件架构对于企业来说的致命缺点就是,企业对于市场的响应速度变慢。企业决策者在一年内需要做的决策数量非常有限,由于依赖关系,其响应周期往往会变得非常漫长。每当开发或升级产品,都需要在一系列体量庞大的相关服务中同时增加新功能,这就需要所有利益相关方共同努力,以同步方式进行变更。
假设服务边界已经被正确地定义为可独立运行的业务领域,并确保在微服务设计中遵循诸多最佳实践。那么至少会以下几个方面获得显而易见的好处:
每个微服务是孤立的,独立的「模块」,它们共同为更高的逻辑目的服务。微服务之间通过 Contract 彼此沟通,每个服务都负责特定的功能。这使得每个服务都能够保持简单,简洁和可测试性。
从而微服务架构允许企业更自发地采取更深远的业务决策,因为每个微服务都是独立运作的,而且每一个管理团队可以很好地控制该服务的变更。
在前端,往往由一个前端团队创建并维护一个 Web 应用程序,使用 REST API 从后端服务获取数据。这种方式如果做得好的话,它能够提供优秀的用户体验,但最主要的缺点就是单页面应用(SPA)不能很好地扩展和部署。在一个大公司里,单前端团队可能成为一个发展瓶颈。随着时间的推移,往往由一个独立团队所开发的前端层越来越难以维护。
特别是这么一个特性丰富、功能强大的前端 Web 应用程序,却位于后端微服务架构之上。并且随着业务的发展,前端变得越来越臃肿,一个项目可能会有 90% 的前端代码,却只有非常薄的后端,甚至这种情况在 Serverless 架构的背景下还会愈演愈烈。
微前端(Micro Frontends)这个术语其实就是微服务的衍生物。将微服务理念扩展到前端开发,同时构建多个完全自治的和松耦合的 App 模块(服务),其中每个 App 模块只负责特定的 UI 元素和功能。
如果我们看到了微服务提供给后端的好处,那么就完全可以更进一步地将这些好处应用到前端。与此同时,在设计微服务的时候,就可以考虑不仅要完成后端逻辑,而且还要完成前端的视觉部分。而对于微前端来说,与微服务的许多要求也是一致的:监控、日志、HealthCheck、Analytics 等等。
这样就能使各个前端团队按照自己的步调迭代,并随时准备就绪处于可发布状态,并隔离相互依赖所产生的风险,与此同时也更容易尝试新技术。