为了解决巨大的一整块后端服务带来的变动与扩展方面的限定,出现了微服务架构(Microservices):
微服务是面向服务架构(SOA)的一种变体,把应用程序设计成一系列松耦合的细粒度服务,并通过轻量级的通信协议组织起来
详细地,将应用构建成一组小型服务。这些服务都可以大概独立部署、独立扩展,每个服务都具有稳固的模块边界,乃至允许利用不同的编程语言来编写不同服务,也可以由不同的团队来管理
Micro frontends, An architectural style where independently deliverable frontend applications are composed into a greater whole.
微前端实际是一种思想,个人以为并不是新的黑科技,其关键点照旧解耦与分治。
微前端是一种类似于微服务的架构,它将微服务的理念应用于浏览器端,即将单页眼前端应用由单一的单体应用转变为多个小型前端应用聚合为一的应用。各个前端应用还可以独立开发、独立部署。同时,它们也可以在共享组件的同时举行并行开发——这些组件可以通过 NPM 或者 Git Tag、Git Submodule 来管理。
犹如微服务一样,微前端就是把系统拆解,解耦,然后组合。犹如iphone的供应链管理。
微前端架构旨在解决单体应用在一个相对长的时间跨度下,由于参与的职员、团队的增多、变迁,从一个普通应用演变成一个巨石应用(Frontend Monolith)后,随之而来的应用不可维护的问题。这类问题在企业级 Web 应用中尤其常见。
微前端
微前端是一种类似于微服务的架构,是一种由独立交付的多个前端应用组成整体的架构风格,将前端应用分解成一些更小、更简单的可以大概独立开发、测试、部署的应用,而在用户看来仍然是内聚的单个产品。
Web 应用开发速度快、用完即走等特性,导致的一个最闭幕果就是「能用 Web 技术实现的应用,最终都会通过 Web 来实现」。在近几年涌现了一大批之前只能在传统 PC 软件中才能看到的优秀产品,比方:Photoshop、Web Office、Web IDE。只管随着 Web 标准的演进,前端工程化也在不停演变,从模块化到组件化在到如今的工程化,但在面对跨团队大规模开发、跨团队企业级应用协作,现有的分治设计模式仍然显得故意无力。
好比复杂的系统,由于整个系统涉及范围较广,在实际的研发过程中肯定会以功能或业务需求垂直的切分成更小的子系统,切分成各种小系统后只管由于分治的设计理念提升了开发者体验,但是肯定水平上降低了用户体验。那能否以一种新的架构模式,既保开发者体验,又能提升用户体验呢。
微前端紧张是用于解决:应用增量升级、多技术体系并存、构建大规模企业级 Web 应用而诞生的。
目前微前端紧张是采用应用分而治之 + 动态加载 + SPA 应用的模式来解决大规模应用带来的一系列问题。