写在结尾的局部，本文的契机是最近咱们组共事在客户端实现了一套 Redux，对某个业务域的性能进行重构设计，iOS、Android 都遵循这套规定，即 Redux。为什么须要客户端去实现一套 Redux？商品模块业务逻辑十分负责，商品根底信息十分多，比方多规格、多单位、价格、库存等信息，还有对应的门店、网店模型，还有各种行业能力开关管制，晚期的实现有 Rx 的角色，导致代码逻辑较为简单，数据流动比拟乱。架构设计、代码保护各方面来看都不是很优雅，加上最近有大的业务调整，中台的同学用 Redux + 单向数据流的形式重构了业务。

另一个下线常常申请网关数据，iOS、Android 各自去申明 DTO Model，而后解析数据，生成客户端须要的数据，这样“反复”的行为常常产生，所以索性用 TS + 脚本，对立做掉了网关数据模型主动生成 iOS、Android 模型的能力。然而在探讨框架设计的时候回类比 React Redux、Flutter Fish Redux、Vuex 等，还会聊到单向数据流、双向数据流，然而有些同学的了解就是谬误的。所以本文第一局部「纠错题」局部就是讲清楚前端几个要害概念。

前面的局部依照逻辑程序讲一下：微前端 -> BFF/ 网关 -> 微服务。

一、纠错题

1. Vue 是双向数据流吗？

如果答复“是”，那么你应该没有搞清楚“双向数据流 ”与“ 双向绑定”这 2 个概念。其实，精确来说两者不是一个维度的货色，单向数据流也能够实现双向绑定。

其实，你要是认真看过 Vue 的官网文档，那么官网就曾经阐明 Vue 其实是 One-Way Data Flow。上面这段话来自官网

首先明确下，咱们说的数据流就是组件之间的数据流动。Vue 中所有的 props 都使得其父子 props 之间造成一个单向上行绑定：父级 props 的更新回向下流动到子组件中，但反过来不行，这样避免从子组件意外更改其父组件的状态，从而导致你的利用数据流难以了解。

此外，每次父级组件产生变更时，子组件中所有的 props 都将会被刷新为最新的值，这意味着你不应该在子组件内去批改 prop，如果你这么做了，浏览器会在控制台中输入正告。Vue 和 React 批改 props 报错如下：

2. React 是 MVVM 吗？

不间接答复这个问题，咱们先来聊几个概念，这几个概念弄清楚了，问题的答案也就跃然纸上了。

2.1 单向绑定、双向绑定的区别？

讲 MVVM 肯定要讲 binder 这个角色。也就是单向绑定和双向绑定。

Vue 反对单向绑定和双向绑定。单向绑定其实就是 Model 到 View 的关联，比方 v-bind。双向绑定就是 Model 的更新会同步到 View，View 上数据的变动会主动同步到 Model，比方 v-model.

v-model 其实是语法糖，因为 Vue 是 tamplate，所以在通过 webpack ast 解析之后，tamplate 会变为 render，v-model 变为 v-bind 和 v-on

能够用单向绑定很简略地能够实现双向绑定的成果，就是 one-way binding + auto event binding。如下

其实看了源码就会发现（Vue3 Proxy），单向绑定和双向绑定的区别在于，双向绑定把数据变更的操作局部，由框架外部实现了，调用者毋庸感知。

2.2 Redux

应用 React Redux 一个典型的流程图如下

如果咱们把 action 和 dispatcher 的实现暗藏在框架外部，这个图能够简化为

如果进一步，咱们将相互手动告诉的机制再暗藏起来，能够简化为

你认真看，是不是就是 MVVM？那问题的答案很显著了，React 不是 MVVM。

3. Vue 是 MVVM 吗

官网说了“尽管没有齐全遵循 MVVM 的思维，然而受到了 MVVM 的启发。所以 Debug 的时候常常看到 VM”Model 的变动会触发 View 的更新，这一点体现在 V-bind 上 而 View 的变更即便同步到 Model 上，体现在 V-model 上 上述都遵循 MVVM，然而 Vue 提供了 Ref 属性，容许应用 ref 拿到 Dom，从而间接操作 Dom 的一些款式或者属性，这一点突破了 MVVM 的标准

4. 单向绑定和双向绑定应用场景

咱们再来思考一个问题，为什么 Vue 要移除 .sync，Angular 要减少 < 来实现单向绑定？

当利用变得越来越大，双向数据流会带来很多的不可预期的后果，这让 debug、调试、测试都变得复杂。

所以 Vue、Angular 都意识到这一点，所以移除了 .sync，反对单向绑定。

侧面聊聊问题：

单向绑定，带来的单向数据流，带来的益处是所有状态变动都能够被记录、跟踪，状态变动必须通过手动调用告诉，源头可追溯，没有“暗箱操作”。同时组件数据只有惟一的入口和进口，使得程序更直观更容易了解，有利于利用的可维护性。毛病是实现同样的需要，代码量会回升，数据的流转过程变长。同时因为对利用状态独立治理的严格要求 (繁多的全局 store)，在解决部分状态较多的场景时(如用户输出交互较多的“富表单型”利用) 会显得特地繁琐。

双向绑定长处是在表单交互较多的场景下，会简化大量业务无关的代码。毛病就是因为都是“暗箱操作”，无奈追踪部分状态的变动，潜在的行为太多也减少了出错时 debug 的难度。同时因为组件数据变动起源入口变得可能不止一个，程序员程度参差不齐，写出的代码很容易将数据流转方向弄得错乱，整个利用的品质就不可控。

总结：单向绑定跟双向绑定在性能上基本上是互补的，所以咱们能够在适合的场景下应用适合的伎俩。比方在 UI 控件中(通常是类表单操作)，能够应用双向的形式绑定数据；而其余场景则应用单向绑定的形式

二、微前端

下面提到的 Vue、React、单向数据流、双向数据流都是针对单个利用去组织和设计工程的，然而当利用很大的时候就会存在一些问题。引出明天的一个主题，“微前端”

客户端的同学都晓得，咱们很早就在应用组件化、模块化来拆分代码和逻辑。那么你能够说出到底什么是组件、什么是模块？

组件就是把反复的代码提取进去合并成为一个个组件，组件强调的是重用，位于零碎最底层，其余性能都依赖于组件，独立性强

模块就是分属同一性能 / 业务的代码进行隔离成独立的模块，能够独立运行，以页面、性能等维度划分为不同模块，位于业务架构层。

这些概念在前端也是如此，比方写过 Vue、React 的都晓得，对一个页面须要进行组件的拆分，一个大页面由多个 UI 子组件组成。模块也一样，前端利用自执行函数（IIFE）来实现模块化，成熟的 CommonJS、AMD、CMD、UMD 标准等等。比方 iOS 侧利用模块化来实现了商品、库存、开单等业务域的拆分，也实现了路由库、网络库等根底能力模块。而前端更多的是利用模块化来实现命名空间和代码的可重用性

其实，看的进去，前端、客户端履行的模块化、组件化的指标都是分治思维，更多是站在代码层面进行拆分、组织治理。然而随着前端工程的越来越重，传统的前端架构曾经很难遵循“麻利”的思维了。

1. 什么是微前端

关怀技术的人听到微前端，立马会想起微服务。微服务是面向服务架构的一种变体，把利用程序设计为一些列松耦合的细粒度服务，并通过轻量级的通信协议组织起来。越老越重的前端工程面临同样的问题，自然而然就将微服务的思维借鉴到了前端畛域。

言归正传，微前端（Micro-Frontends）是一种相似于微服务的架构，它将微服务的理念利用于浏览器端，行将 Web 利用由繁多的单体利用转变为多个小型前端利用聚合为一的利用。各个前端利用还能够独立运行、独立开发、独立部署。微前端不是单纯的前端框架或者工具，而是一套架构体系。

2. 特点

2.1 技术无关

抛两个场景，大家思考一下：

• 你新入职一家公司，老板扔给你一个 5 年陈的我的项目，须要你在这个我的项目上继续迭代加性能。
• 你们起了一个新我的项目，老板看惯了前端的风起云涌技术更迭，只给了架构上的一个要求：” 如何确保这套技术计划在 3~5 年内还葆有生命力，不会在 3、5 年后变成又一个遗产我的项目？”

第一个场景咱们初步一想，能够啊，我只须要把新性能用 React/Vue 开发，反正他们都只是 UI library，给我一个 Dom 节点我想怎么渲染怎么渲染。然而你有没有思考过这只是浮在表层的视图实现，沉在底下的工程设施呢？我要怎么把这个用 React 写的组件打出一个包，并且集成到原来的用 ES5 写的代码外面？或者我怎么让 Webpack 跟 之前的 Grunt 能谐和共存一起敌对的产出一个合乎预期的 Bundle？

第二个场景，你如何确保技术栈在 3~5 年都葆有生命力？别说跨框架了，就算都是 React，15 跟 16 都是不兼容的，hooks 还不能用于 Class component 呢我说什么了？还有打包计划，当初还好都默认 Webpack，那 Webpack 版本升级呢，每次都跟进吗？别忘了还有 Babel、less、typescript 诸如此类呢？别说 3 年，有几个人敢保障本人的我的项目一年后把所有依赖包降级到最新还能跑起来？

为什么举这两个场景呢，因为咱们去统计一下业界对于”微前端“发过声的公司，会发现 adopt 微前端的公司，基本上都是做 ToB 软件服务的，没有哪家 ToC 公司会有微前端的诉求（有也是外部的中后盾零碎），为什么会这样？很简略，因为很少有 ToC 软件活得过 3 年以上的。而对于 ToB 利用而言，3~5 年太常见了好吗！去看看阿里云最早的那些产品的控制台，去看看那些电信软件、银行软件，哪个不是 10 年 + 的寿命？企业软件的降级有多痛这个我就不多说了。所以大部分企业应用都会有一个外围的诉求，就是 如何确保我的遗产代码能平滑的迁徙，以及如何确保我在若干年后还能用上时下热门的技术栈？

如何给遗产我的项目续命，才是咱们对微前端最开始的诉求。很多开发可能感触不深，毕竟那些一年挣不了几百万，没什么价值的我的项目要么是本人死掉了，要么是扔给外包团队保护了，然而要晓得，对很多做 ToB 畛域的中小企业而言，这样的零碎可能是他们安身立命之本，不是能说扔就扔的，他们承当不了那么高的试错老本。

甚至新的业务，每个技术团队应该能够依据本人团队成员的技术储备、依据业务特点抉择适合的技术栈，而不须要特地关怀其余团队的状况，也就是 A 团队能够用 React，B 团队能够用 Vue，C 团队甚至能够用 Angular 去实现。

2.2 简略、松耦合的代码库

比起一整块的前端工程来说，微前端架构下的代码库更小更容易开发、保护。此外，更重要的是防止模块间不合理的隐式耦合造成的复杂度回升。通过界定清晰的利用边界来升高意外耦合的可能性，减少子利用间逻辑耦合的老本，促使开发者明确数据和事件在应用程序中的流向

2.3 增量降级

现实的代码天然是模块清晰、依赖明确、易于扩大、便于保护的……然而，实际中出于各式各样的起因：

• 历史我的项目，祖传代码
• 交付压力，过后求快
• 就近就熟，过后求稳……

总存在一些不那么现实的代码：

• 技术栈落后，甚至强行混用多种技术栈
• 耦合凌乱，不敢动，牵一发何止动全身
• 重构不彻底，重构 - 烂尾，换个姿态重构 - 又烂尾……

而要对这些代码进行彻底重构的话，最大的问题是很难有富余的资源去大刀阔斧地一步到位，在逐渐重构的同时，既要确保两头版本可能平滑过渡，同时还要继续交付新个性：

所以，为了施行渐进式重构，咱们须要一种增量降级的能力，先让新旧代码谐和共存，再逐渐转化旧代码，直到整个重构实现

这种增量降级的能力意味着咱们可能 对产品性能进行低危险的部分替换，包含降级依赖项、更替架构、UI 改版等。另一方面，也带来了技术选型上的灵活性，有助于新技术、新交互模式的实验性试错

2.4 独立部署

独立部署的能力在微前端体系中至关重要，可能放大变更范畴，进而升高相干危险

因而，每个微前端都应具备有本人的继续交付流水线（包含构建、测试并部署到生产环境），并且要能独立部署，不用过多思考其它代码库和交付流水线的以后状态：

如果 A、B、C 三个 Biz 存在三个零碎，三者能够独立部署，最初由主零碎去集成公布利用。这样子更加独立灵便。想想以前的单体利用，比方一个简单的业务利用，很可能在 B 构建的时候没有通过 lint 导致整个利用失败掉，这样既节约了构建 A 的工夫，又让整个利用的构建变为串行，低效。

2.5 团队自治

除了代码和公布周期上的解耦之外，微前端还有助于造成独立的团队，由不同的团队各自负责一块独立的产品性能，最好依据 Biz 去划分，因为代码都是独立的，所以基于 Biz 的前端业务团队，能够设计思考，提供更加正当的接口和能力。甚至能够形象更多的根底能力，依照业务思考提供更加齐备的能力，也就是团队更加自治。

3 如何实现

微前端次要采纳的是组合式利用路由计划，该计划的核心思想是“主从”（玩过 Jenkins 的同学是不是很耳熟），即包含一个基座“MainApp“利用和若干个微利用（MircroApp），基座大多采纳的是一个前端 SPA 我的项目，次要负责利用注册、路由映射、音讯下发等，而微利用是独立的前端我的项目，这些我的项目不限于采纳的具体技术（React、Vue、Angular、Jquery）等等，每个微利用注册到基座中，由基座进行治理，即便没有基座，这些微利用都能够独自拜访，如下：

一个微利用框架须要解决的问题是：

• 路由切换的散发问题

  作为微前端的基座利用，是整个利用的入口，负责承载以后微利用的展现和对其余路由微利用的转发，对于以后微利用的展现，个别是由以下几步形成：

  1. 作为一个 SPA 的基座利用，自身是一套纯前端我的项目，要想展现微利用的页面除了采纳 iframe 之外，要能先拉取到微利用的页面内容，这就须要 近程拉取机制。
  2. 近程拉取机制通常会采纳 fetch API 来首先获取到微利用的 HTML 内容，而后通过解析将微利用的 JavaScript 和 CSS 进行抽离，采纳 eval 办法来运行 JavaScript，并将 CSS 和 HTML 内容 append 到基座利用中留给微利用的展现区域，当微利用切换走时，同步卸载这些内容，这就形成的以后利用的展现流程。
  3. 当然这个流程里会波及到 CSS 款式的净化以及 JavaScript 对全局对象的净化，这个波及到隔离问题会在前面探讨，而目前针对近程拉取机制这套流程，已有现成的库来实现，能够参考 import-html-entry 和 system.js。

  对于路由散发而言，以采纳 vue-router 开发的基座 SPA 利用来举例，次要是上面这个流程：

  1. 当浏览器的门路变动后，vue-router 会监听 hashchange 或者 popstate 事件，从而获取到路由切换的机会。
  2. 最先接管到这个变动的是基座的 router，通过查问注册信息能够获取到转发到那个微利用，通过一些逻辑解决后，采纳批改 hash 办法或者 pushState 办法来路由信息推送给微利用的路由，微利用能够是手动监听 hashchange 或者 popstate 事件接管，或者采纳 React-router，vue-router 接管路由，前面的逻辑就由微利用本人管制。

• 主利用、微利用的隔离问题

  利用隔离问题次要分为主利用和微利用，微利用和微利用之间的 JavaScript 执行环境隔离，CSS 款式隔离，咱们先来说下 CSS 的隔离。

  CSS 隔离：当主利用和微利用同屏渲染时，就可能会有一些款式会互相净化，如果要彻底隔离 CSS 净化，能够采纳 CSS Module 或者命名空间的形式，给每个微利用模块以特定前缀，即可保障不会相互烦扰，能够采纳 webpack 的 postcss 插件，在打包时增加特定的前缀。

  而对于微利用与微利用之间的 CSS 隔离就非常简单，在每次利用加载时，将该利用所有的 link 和 style 内容进行标记。在利用卸载后，同步卸载页面上对应的 link 和 style 即可。

  JavaScript 隔离 ：每当微利用的 JavaScript 被加载并运行时，它的外围实际上是对全局对象 Window 的批改以及一些全局事件的扭转，例如 jQuery 这个 js 运行后，会在 Window 上挂载一个window.$ 对象，对于其余库 React，Vue 也不例外。为此，须要在加载和卸载每个微利用的同时，尽可能打消这种抵触和影响，最广泛的做法是采纳沙箱机制（SandBox）。

  沙箱机制的外围是让部分的 JavaScript 运行时，对外部对象的拜访和批改处在可控的范畴内，即无论外部怎么运行，都不会影响内部的对象。通常在 Node.js 端能够采纳 vm 模块，而对于浏览器，则须要联合 with 关键字和 window.Proxy 对象来实现浏览器端的沙箱。

• 通信问题

  利用间通信有很多种形式，当然，要让多个拆散的微利用之间要做到通信，实质上仍离不开两头媒介或者说全局对象。所以对于音讯订阅（pub/sub）模式的通信机制是十分实用的，在基座利用中会定义事件核心 Event，每个微利用别离来注册事件，当被触发事件时再有事件核心对立散发，这就形成了根本的通信机制，流程如下图：

目前开源了很多微前端框架，比方 qiankun，感兴趣的能够去看看源码

4. 是否采纳微前端

为什么要做微前端？或者说微前端解决了什么问题？也就答复了是否须要采纳微前端。微前端的鼻祖 Single-spa 最后要解决的问题是，在老我的项目中应用新的技术栈。现阶段蚂蚁金服微前端框架 Qiankun 所申明的微前端要解决的另一个次要问题是，巨石工程所面临的保护艰难喝合作开发艰难的问题。如果工程面临这两方面的问题，我感觉微前端就能够试试了。你们感觉呢？

三、微服务平台下基于 GraphQL 构建 BFF 的思考

1. 大前端架构演进

咱们来讲一个故事

1. V1

假如晚期 2011 年一家电商公司实现了单体利用的拆分，后端服务曾经 SOA 化，此时利用的状态仅有 Web 端，V1 架构图如下所示：

2. V2

工夫来到了 2012 年初，国内刮起了一阵无线利用的风，各个大厂都开始了本人的无线利用开发。为了应答该需要，架构调整为 V2，如下所示

这个架构存在一些问题：

• 无线 App 和外部的微服务强耦合，任何一侧的变动都可能对另一侧造成影响
• 无线 App 须要晓得外部服务细节

• 无线 App 端须要做大量的聚合裁剪和适配逻辑

  聚合：某一个页面可能同时须要调用好几个后端 API 进行组合，比方商品详情页所需的数据，不能一次调用实现

  裁剪：后端提供的根底服务比拟通用，返回的 Payload 比拟大，字段太多，App 须要依据设施和业务需要，进行字段裁剪用户的客户端是 Android 还是 iOS，是大屏还是小屏，是什么版本。再比方，业务属于哪个行业，产品状态是什么，性能投放在什么场景，面向的用户群体是谁等等。这些因素都会带来面向端的性能逻辑的差异性。后端在微服务和畛域驱动设计（不在本文重点解说领域）的背景下，各个服务提供了以后 Domain 的根底性能，比方商品域，提供了商品新增、查问、删除性能，列表性能、详情页性能。

  然而在商品详情页的状况下，数据须要调用商品域、库存域、订单域的能力。客户端须要做大量的网络接口解决和数据处理。

  适配：一些常见的适配常见就是格局转换，比方有些后端服务比拟老，提供 SOAP/XML 数据，不反对 JSON，这时候就须要做一些适配代码

• 随着应用类型的增多（iOS Phone/Pad、Android Phone/Pad、Hybrid、小程序），聚合裁剪和适配的逻辑的开发会造成设施端的大量重复劳动
• 前端比方 iOS、Android、小程序、H5 各个 biz 都须要业务数据。最早的设计是后端接口直出。这样的设计会导致呈现一个问题，因为 biz1 因为迭代发版，造成后端改接口的实现。Biz2 的另一个需要又会让服务端改设计实现，造成接口是面向业务开发的。不禁会问，根底服务到底是面向业务接口开发的吗？这和畛域驱动的设计相背离

在这样的背景下诞生了 BFF（Backend For Frontend）层。各个领域提供根底的数据模型，各个 biz 存在本人的 BFF 层，按需取查问（比方商品根底数据 200 个，然而小程序列表页只须要 5 个），在比方商品详情页可能须要商品数据、订单数据、评估数据、举荐数据、库存数据等等，最早的设计该详情页可能须要申请 6 个接口，这对于客户端、网页来说，体验很差，有个新的设计，详情页的 BFF 去动静组装调用接口，一个 BFF 接口就组装好了数据，间接返回给业务方，体验很好

3. V2.1

V2 架构问题太多，没有开发施行。为解决上述问题，在外部设备和外部微服务之间引入一个新的角色 Mobile BFF。BFF 也就是 Backend for Frontend 的简称，能够认为是一种适配服务，将后端的微服务进行适配（次要包含聚合裁剪和格局适配等逻辑），向无线端设施裸露敌对和对立的 API，不便无线设施接入拜访后端服务。V2.1 服务架构如下

这个架构的劣势是：

• 无线 App 和外部服务不耦合，通过引入 BFF 这层简介，使得两边能够独立变动：

  • 后端如果发生变化，通过 BFF 屏蔽，前端设施能够做到不受影响
  • 前端如果发生变化，通过 BFF 屏蔽，后端微服务能够暂不变动
  • 当无线端有新的需要的时候，通过 BFF 屏蔽，能够缩小前后端的沟通合作开销，很多需要由前端团队在 BFF 上就能够本人搞定
• 无线 App 只须要晓得 Mobile BFF 的地址，并且服务接口是对立的，不须要晓得外部简单的微服务地址和细节
• 聚合裁剪和适配逻辑在 Mobile BFF 上实现，无线 App 端能够简化瘦身

4. V3

V2.1 架构比拟胜利，施行后较长一段时间反对了公司晚期无线业务的倒退，随着业务量暴增，无线研发团队一直减少，V2.1 架构的问题也被裸露了进去：

• Mobile BFF 中不仅有各个业务线的聚合 / 裁剪 / 适配和业务逻辑，还引入了很多横跨切面的逻辑，比方平安认证，日志监控，限流熔断等，随着工夫的推移，代码变得越来越简单，技术债越来越多，开发效率一直降落，缺点数量一直减少
• Mobile BFF 集群是个失败单点，重大代码缺点将导致流量洪峰可能引起集群宕机，所有无线利用都不可用

为了解决上述伪命题，决定在外部设备和 BFF 之间架构一个新的层，即 Api Gateway，V3 架构如下：

新的架构 V3 有如下调整：

• BFF 按团队或者业务进行解耦拆分，拆分为若干个 BFF 微服务，每个业务线能够并行开发和交付各自负责的 BFF 微服务

• 官关（个别由独立框架团队负责运维）专一横跨切面性能，包含：

  • 路由，将来自无线设施的申请路由到后端的某个微服务 BFF 集群
  • 认证，对波及敏感数据的 Api 进行集中认证鉴权
  • 监控，对 Api 调用进行性能监控
  • 限流熔断，当呈现流量洪峰，或者后端 BFF/ 微服务呈现提早或故障，网关可能被动进行限流熔断，爱护后端服务，并放弃前端用户体验能够承受。
  • 平安防爬，收集拜访日志，通过后盾剖析出歹意行为，并阻断歹意申请。
• 网关在无线设施和 BFF 之间又引入了一层间接，让两边能够独立变动，特地是当后盾 BFF 在降级或迁徙时，能够做到用户端利用不受影响

在新的 V3 架构中，网关承当了重要的角色，它是解耦和后续降级迁徙的利器，在网关的配合下，单块 BFF 实现理解耦拆分，各业务团队能够独立开发和交付各自的微服务，研发效率大大晋升，另外，把横跨切面逻辑从 BFF 剥离到网关后，BFF 的开发人员能够更加专一于业务逻辑交付，实现了架构上的关注拆散。

5 V4

业务在一直倒退，技术架构也须要一直的迭代和降级，近年来技术团队又新来了新的业务和技术需要：

• 凋谢外部的业务能力，建设开发平台。借助第三方社区开发者能力进一步拓宽业务状态
• 废除传统服务端 Web 利用模式，引入前后端拆散架构，前端采纳 H5 单页技术给用户提供更好的用户体验

V4 的思路和 V3 差不多，只是拓展了新的接入渠道：

• 引入面向第三方凋谢 Api 的 BFF 层和配套的网关层，反对第三方开发者在开放平台上开发利用
• 引入面向 H5 利用的 BFF 和配套网关，反对前后拆散和 H5 单页利用模式

V4 是一个比拟残缺的古代微服务架构，从外到内顺次是：端用户体验层 -> 网关层 -> BFF 层 -> 微服务层。整个架构档次清晰、职责明显，是一种灵便的可能反对业务不断创新的演进式架构

总结：

1. 在微服务架构中，BFF(Backend for Frontend)也称聚合层或者适配层，它次要承接一个适配角色：将外部简单的微服务，适配成对各种不同用户体验（无线 /Web/H5/ 第三方等）敌对和对立的 API。聚合裁剪适配是 BFF 的主要职责。
2. 在微服务架构中，网关专一解决跨横切面逻辑，包含路由、平安、监控和限流熔断等。网关一方面是拆合成耦的利器，同时让开发人员能够专一业务逻辑的实现，达成架构上的关注拆散。
3. 端用户体验层 -> 网关层 ->BFF 层 -> 微服务层，是古代微服务架构的典型分层形式，这个架构可能灵便应答业务需要的变动，是一种反对翻新的演变式架构。
4. 技术和业务都在一直变动，架构师要一直调整架构应答这些的变动，BFF 和网关都是架构演变的产物。

2. BFF & GraphQL

大前端模式下常常会面临上面 2 个问题

• 频繁变动的 API 是须要向前兼容的
• BFF 中返回的字段不全是客户端须要的

至此 2015 年 GraphQL 被 Facebook 正式开源。它并不是一门语言，而是一种 API 查问格调。本文着重解说了大前端模式下 BFF 层的设计和演进，须要配合 GraphQL 落地。上面简略介绍下 GraphQL，具体的能够查看 Node 或者某个语言对应的解决方案。

1. 应用 GraphQL

服务端形容数据 – 客户端按需申请 – 服务端返回数据

服务端形容数据

type Project {
  name: String
  tagline: String
  contributors: [User]
}

客户端按需申请

{Project(name: 'GraphQL') {tagline}
}

服务端返回数据

{
    "project": {tagline: "A query language for APIS"}
}

2. 特点

1. 定义数据模型，按需获取

就像写 SQL 一样，形容好须要查问的数据即可

2. 数据分层

数据格式清晰，语义化强

3. 强类型，类型校验

领有 GraphQL 本人的类型形容，类型查看

4. 协定⽽非存储

看上去和 MongoDB 比拟像，然而一个是数据长久化能力，一个是接口查问形容。

5. ⽆须版本化

写过客户端代码的同学会看到 Apple 给 api 废除的时候都会表明起因，举荐用什么 api 代替等等，这点 GraphQL 也反对，另外废除的时候也形容了如何解决，如何应用。

3. 什么时候须要 BFF

• 后端被诸多客户端应用，并且每种客户端对于同一类 Api 存在定制化诉求
• 后端微服务较多，并且每个微服务都只关注于本人的畛域
• 须要针对前端应用的 Api 做一些共性话的优化

什么时候不举荐应用 BFF

• 后端服务仅被一种客户端应用
• 后端服务比较简单，提供为公共服务的机会不多（DDD、微服务）

4. 总结

在微服务架构中，BFF(Backend for Frontend)也称 re 聚合层或者适配层，它次要承接一个适配角色：将外部简单的微服务，适配成对各种不同用户体验（无线 /Web/H5/ 第三方等）敌对和对立的 API。聚合裁剪适配是 BFF 的主要职责。

在微服务架构中，网关专一解决跨横切面逻辑，包含路由、平安、监控和限流熔断等。网关一方面是拆合成耦的利器，同时让开发人员能够专一业务逻辑的实现，达成架构上的关注拆散。

端用户体验层 -> 网关层 ->BFF 层 -> 微服务层，是古代微服务架构的典型分层形式，这个架构可能灵便应答业务需要的变动，是一种反对翻新的演变式架构。

技术和业务都在一直变动，架构师要一直调整架构应答这些的变动，BFF 和网关都是架构演变的产物。

四、后端架构演进

1. 一些常见名词解释

云原生 (Cloud Native) 是一种构建和运行应用程序的办法，是一套技术体系和方法论。Cloud Native 是一个组合词，Cloud+Native。Cloud 是适应范畴为云平台，Native 示意应用程序从设计之初即思考到云的环境，原生为云而设计，在云上以最佳姿态运行，充分利用和施展云平台的弹性 + 分布式劣势。

Iaas：基础设施服务，Infrastructure as a service，如果把软件开发比作厨师做菜，那么 IaaS 就是别人提供了厨房，炉子，锅等根底货色，你本人应用这些货色，本人依据不同须要做出不同的菜。由服务商提供服务器，个别为云主机，客户自行搭建环境部署软件。例如阿里云、腾讯云等就是典型的 IaaS 服务商。

Paas：平台服务，Platform as a service，还是做菜比喻，比方我做一个黄焖鸡米饭，除了提供根底货色外，那么 PaaS 还给你提供了现成剁好的鸡肉，土豆，辣椒，你只有把这些货色放在一起，加些调料，用个小锅子在炉子上焖个 20 分钟就好了。本人只需关怀软件自身，至于软件运行的环境由服务商提供。咱们常说的云引擎、云容器等就是 PaaS。

Faas：函数服务，Function as a Service，同样是做黄焖鸡米饭，这次我只提供酱油，色拉油，盐，醋，味精这些调味料，其余我不提供，你本人依据不同口味是多放点盐，还是多放点醋，你本人决定。

Saas：软件服务，Software as a service，同样还是做黄焖鸡米饭，这次是间接现成搞好的一个一个小锅的鸡，什么调料都好了，曾经是个成品了，你只有贴个牌，间接卖出 去就行了，做多是在炉子上焖个 20 分钟。这就是 SaaS（Software as a Service，软件即服务）的概念，间接购买第三方服务商曾经开发好的软件来应用，从而免去了本人去组建一个团队来开发的麻烦。

Baas：你理解到，本人要改的货色，只须要前端改了就能够了，后端局部齐全不须要改。这时候你动脑筋，能够招了前端工程师，前端页面本人做，后端局部还是用服务商的。

这就是 BaaS（Backend as a Service，后端即服务），本人只须要开发前端局部，剩下的所有都交给了服务商。常常说的“后端云”就是 BaaS 的意思，例如像 LeanCloud、Bomb 等就是典型的 BaaS 服务商。

MicroService vs Severless：MicroService 是微服务，是一种专一于繁多责任与性能的小型服务，Serverless 相当于更加细粒度和碎片化的繁多责任与性能小型服务，他们都是一种特定的小型服务，从这个档次来说，Serverless=MicroService。

MicroService vs Service Mesh：在没有 ServiceMesh 之前微服务的通信，数据交换同步也存在，也有比拟好的解决方案，如 Spring Clould，OSS，Double 这些，但他们有个最大的特点就是须要你写入代码中，而且须要深度的写 很多逻辑操作代码，这就是侵入式。而 ServiceMesh 最大的特点是非侵入式，不须要你写特定代码，只是在云服务的层面即可享受微服务之间的通信，数据交换同步等操作，这里的代表如，docker+K8s，istio，linkerd 等。

2. 架构演进

后端整个的演进能够如上图所示，经验了一直迭代，具体的解释这里不做开展。跟 SOA 等量齐观的还有一个 ESB（企业服务总线），简略来说 ESB 就是一根管道，用来连贯各个服务节点。为了集成不同零碎，不同协定的服务，ESB 能够简略了解为：它做了音讯的转化解释和路由工作，让不同的服务互联互通；应用 ESB 解耦服务间的依赖

SOA 和微服务架构的差异

• 微服务去中心化，去掉 ESB 企业总线。微服务不再强调传统 SOA 架构外面比拟重的 ESB 企业服务总线，同时 SOA 的思维进入到单个业务零碎外部实现真正的组件化
• Docker 容器技术的呈现，为微服务提供了更便当的条件，比方更小的部署单元，每个服务能够通过相似 Node 或者 Spring Boot 等技术跑在本人的过程中。
• SOA 重视的是系统集成方面，而微服务关注的是齐全拆散

​

REST API：每个业务逻辑都被合成为一个微服务，微服务之间通过 REST API 通信。

API Gateway：负责服务路由、负载平衡、缓存、访问控制和鉴权等工作，向终端用户或客户端开发 API 接口.

前端、BFF、后端一些常见的设计模式

写在结尾的局部，本文的契机是最近咱们组共事在客户端实现了一套 Redux，对某个业务域的性能进行重构设计，iOS、Android 都遵循这套规定，即 Redux。为什么须要客户端去实现一套 Redux？商品模块业务逻辑十分负责，商品根底信息十分多，比方多规格、多单位、价格、库存等信息，还有对应的门店、网店模型，还有各种行业能力开关管制，晚期的实现有 Rx 的角色，导致代码逻辑较为简单，数据流动比拟乱。架构设计、代码保护各方面来看都不是很优雅，加上最近有大的业务调整，中台的同学用 Redux + 单向数据流的形式重构了业务。

另一个下线常常申请网关数据，iOS、Android 各自去申明 DTO Model，而后解析数据，生成客户端须要的数据，这样“反复”的行为常常产生，所以索性用 TS + 脚本，对立做掉了网关数据模型主动生成 iOS、Android 模型的能力。然而在探讨框架设计的时候回类比 React Redux、Flutter Fish Redux、Vuex 等，还会聊到单向数据流、双向数据流，然而有些同学的了解就是谬误的。所以本文第一局部「纠错题」局部就是讲清楚前端几个要害概念。

前面的局部依照逻辑程序讲一下：微前端 -> BFF/ 网关 -> 微服务。

一、纠错题

1. Vue 是双向数据流吗？

如果答复“是”，那么你应该没有搞清楚“双向数据流 ”与“ 双向绑定”这 2 个概念。其实，精确来说两者不是一个维度的货色，单向数据流也能够实现双向绑定。

其实，你要是认真看过 Vue 的官网文档，那么官网就曾经阐明 Vue 其实是 One-Way Data Flow。上面这段话来自官网

首先明确下，咱们说的数据流就是组件之间的数据流动。Vue 中所有的 props 都使得其父子 props 之间造成一个单向上行绑定：父级 props 的更新回向下流动到子组件中，但反过来不行，这样避免从子组件意外更改其父组件的状态，从而导致你的利用数据流难以了解。

此外，每次父级组件产生变更时，子组件中所有的 props 都将会被刷新为最新的值，这意味着你不应该在子组件内去批改 prop，如果你这么做了，浏览器会在控制台中输入正告。Vue 和 React 批改 props 报错如下：

2. React 是 MVVM 吗？

不间接答复这个问题，咱们先来聊几个概念，这几个概念弄清楚了，问题的答案也就跃然纸上了。

2.1 单向绑定、双向绑定的区别？

讲 MVVM 肯定要讲 binder 这个角色。也就是单向绑定和双向绑定。

Vue 反对单向绑定和双向绑定。单向绑定其实就是 Model 到 View 的关联，比方 v-bind。双向绑定就是 Model 的更新会同步到 View，View 上数据的变动会主动同步到 Model，比方 v-model.

v-model 其实是语法糖，因为 Vue 是 tamplate，所以在通过 webpack ast 解析之后，tamplate 会变为 render，v-model 变为 v-bind 和 v-on

能够用单向绑定很简略地能够实现双向绑定的成果，就是 one-way binding + auto event binding。如下

其实看了源码就会发现（Vue3 Proxy），单向绑定和双向绑定的区别在于，双向绑定把数据变更的操作局部，由框架外部实现了，调用者毋庸感知。

2.2 Redux

应用 React Redux 一个典型的流程图如下

如果咱们把 action 和 dispatcher 的实现暗藏在框架外部，这个图能够简化为

如果进一步，咱们将相互手动告诉的机制再暗藏起来，能够简化为

你认真看，是不是就是 MVVM？那问题的答案很显著了，React 不是 MVVM。

3. Vue 是 MVVM 吗

官网说了“尽管没有齐全遵循 MVVM 的思维，然而受到了 MVVM 的启发。所以 Debug 的时候常常看到 VM”Model 的变动会触发 View 的更新，这一点体现在 V-bind 上 而 View 的变更即便同步到 Model 上，体现在 V-model 上 上述都遵循 MVVM，然而 Vue 提供了 Ref 属性，容许应用 ref 拿到 Dom，从而间接操作 Dom 的一些款式或者属性，这一点突破了 MVVM 的标准

4. 单向绑定和双向绑定应用场景

咱们再来思考一个问题，为什么 Vue 要移除 .sync，Angular 要减少 < 来实现单向绑定？

当利用变得越来越大，双向数据流会带来很多的不可预期的后果，这让 debug、调试、测试都变得复杂。

所以 Vue、Angular 都意识到这一点，所以移除了 .sync，反对单向绑定。

侧面聊聊问题：

单向绑定，带来的单向数据流，带来的益处是所有状态变动都能够被记录、跟踪，状态变动必须通过手动调用告诉，源头可追溯，没有“暗箱操作”。同时组件数据只有惟一的入口和进口，使得程序更直观更容易了解，有利于利用的可维护性。毛病是实现同样的需要，代码量会回升，数据的流转过程变长。同时因为对利用状态独立治理的严格要求 (繁多的全局 store)，在解决部分状态较多的场景时(如用户输出交互较多的“富表单型”利用) 会显得特地繁琐。

双向绑定长处是在表单交互较多的场景下，会简化大量业务无关的代码。毛病就是因为都是“暗箱操作”，无奈追踪部分状态的变动，潜在的行为太多也减少了出错时 debug 的难度。同时因为组件数据变动起源入口变得可能不止一个，程序员程度参差不齐，写出的代码很容易将数据流转方向弄得错乱，整个利用的品质就不可控。

总结：单向绑定跟双向绑定在性能上基本上是互补的，所以咱们能够在适合的场景下应用适合的伎俩。比方在 UI 控件中(通常是类表单操作)，能够应用双向的形式绑定数据；而其余场景则应用单向绑定的形式

二、微前端

下面提到的 Vue、React、单向数据流、双向数据流都是针对单个利用去组织和设计工程的，然而当利用很大的时候就会存在一些问题。引出明天的一个主题，“微前端”

客户端的同学都晓得，咱们很早就在应用组件化、模块化来拆分代码和逻辑。那么你能够说出到底什么是组件、什么是模块？

组件就是把反复的代码提取进去合并成为一个个组件，组件强调的是重用，位于零碎最底层，其余性能都依赖于组件，独立性强

模块就是分属同一性能 / 业务的代码进行隔离成独立的模块，能够独立运行，以页面、性能等维度划分为不同模块，位于业务架构层。

这些概念在前端也是如此，比方写过 Vue、React 的都晓得，对一个页面须要进行组件的拆分，一个大页面由多个 UI 子组件组成。模块也一样，前端利用自执行函数（IIFE）来实现模块化，成熟的 CommonJS、AMD、CMD、UMD 标准等等。比方 iOS 侧利用模块化来实现了商品、库存、开单等业务域的拆分，也实现了路由库、网络库等根底能力模块。而前端更多的是利用模块化来实现命名空间和代码的可重用性

其实，看的进去，前端、客户端履行的模块化、组件化的指标都是分治思维，更多是站在代码层面进行拆分、组织治理。然而随着前端工程的越来越重，传统的前端架构曾经很难遵循“麻利”的思维了。

1. 什么是微前端

关怀技术的人听到微前端，立马会想起微服务。微服务是面向服务架构的一种变体，把利用程序设计为一些列松耦合的细粒度服务，并通过轻量级的通信协议组织起来。越老越重的前端工程面临同样的问题，自然而然就将微服务的思维借鉴到了前端畛域。

言归正传，微前端（Micro-Frontends）是一种相似于微服务的架构，它将微服务的理念利用于浏览器端，行将 Web 利用由繁多的单体利用转变为多个小型前端利用聚合为一的利用。各个前端利用还能够独立运行、独立开发、独立部署。微前端不是单纯的前端框架或者工具，而是一套架构体系。

2. 特点

2.1 技术无关

抛两个场景，大家思考一下：

• 你新入职一家公司，老板扔给你一个 5 年陈的我的项目，须要你在这个我的项目上继续迭代加性能。
• 你们起了一个新我的项目，老板看惯了前端的风起云涌技术更迭，只给了架构上的一个要求：” 如何确保这套技术计划在 3~5 年内还葆有生命力，不会在 3、5 年后变成又一个遗产我的项目？”

第一个场景咱们初步一想，能够啊，我只须要把新性能用 React/Vue 开发，反正他们都只是 UI library，给我一个 Dom 节点我想怎么渲染怎么渲染。然而你有没有思考过这只是浮在表层的视图实现，沉在底下的工程设施呢？我要怎么把这个用 React 写的组件打出一个包，并且集成到原来的用 ES5 写的代码外面？或者我怎么让 Webpack 跟 之前的 Grunt 能谐和共存一起敌对的产出一个合乎预期的 Bundle？

第二个场景，你如何确保技术栈在 3~5 年都葆有生命力？别说跨框架了，就算都是 React，15 跟 16 都是不兼容的，hooks 还不能用于 Class component 呢我说什么了？还有打包计划，当初还好都默认 Webpack，那 Webpack 版本升级呢，每次都跟进吗？别忘了还有 Babel、less、typescript 诸如此类呢？别说 3 年，有几个人敢保障本人的我的项目一年后把所有依赖包降级到最新还能跑起来？

为什么举这两个场景呢，因为咱们去统计一下业界对于”微前端“发过声的公司，会发现 adopt 微前端的公司，基本上都是做 ToB 软件服务的，没有哪家 ToC 公司会有微前端的诉求（有也是外部的中后盾零碎），为什么会这样？很简略，因为很少有 ToC 软件活得过 3 年以上的。而对于 ToB 利用而言，3~5 年太常见了好吗！去看看阿里云最早的那些产品的控制台，去看看那些电信软件、银行软件，哪个不是 10 年 + 的寿命？企业软件的降级有多痛这个我就不多说了。所以大部分企业应用都会有一个外围的诉求，就是 如何确保我的遗产代码能平滑的迁徙，以及如何确保我在若干年后还能用上时下热门的技术栈？

如何给遗产我的项目续命，才是咱们对微前端最开始的诉求。很多开发可能感触不深，毕竟那些一年挣不了几百万，没什么价值的我的项目要么是本人死掉了，要么是扔给外包团队保护了，然而要晓得，对很多做 ToB 畛域的中小企业而言，这样的零碎可能是他们安身立命之本，不是能说扔就扔的，他们承当不了那么高的试错老本。

甚至新的业务，每个技术团队应该能够依据本人团队成员的技术储备、依据业务特点抉择适合的技术栈，而不须要特地关怀其余团队的状况，也就是 A 团队能够用 React，B 团队能够用 Vue，C 团队甚至能够用 Angular 去实现。

2.2 简略、松耦合的代码库

比起一整块的前端工程来说，微前端架构下的代码库更小更容易开发、保护。此外，更重要的是防止模块间不合理的隐式耦合造成的复杂度回升。通过界定清晰的利用边界来升高意外耦合的可能性，减少子利用间逻辑耦合的老本，促使开发者明确数据和事件在应用程序中的流向

2.3 增量降级

现实的代码天然是模块清晰、依赖明确、易于扩大、便于保护的……然而，实际中出于各式各样的起因：

• 历史我的项目，祖传代码
• 交付压力，过后求快
• 就近就熟，过后求稳……

总存在一些不那么现实的代码：

• 技术栈落后，甚至强行混用多种技术栈
• 耦合凌乱，不敢动，牵一发何止动全身
• 重构不彻底，重构 - 烂尾，换个姿态重构 - 又烂尾……

而要对这些代码进行彻底重构的话，最大的问题是很难有富余的资源去大刀阔斧地一步到位，在逐渐重构的同时，既要确保两头版本可能平滑过渡，同时还要继续交付新个性：

所以，为了施行渐进式重构，咱们须要一种增量降级的能力，先让新旧代码谐和共存，再逐渐转化旧代码，直到整个重构实现

这种增量降级的能力意味着咱们可能 对产品性能进行低危险的部分替换，包含降级依赖项、更替架构、UI 改版等。另一方面，也带来了技术选型上的灵活性，有助于新技术、新交互模式的实验性试错

2.4 独立部署

独立部署的能力在微前端体系中至关重要，可能放大变更范畴，进而升高相干危险

因而，每个微前端都应具备有本人的继续交付流水线（包含构建、测试并部署到生产环境），并且要能独立部署，不用过多思考其它代码库和交付流水线的以后状态：

如果 A、B、C 三个 Biz 存在三个零碎，三者能够独立部署，最初由主零碎去集成公布利用。这样子更加独立灵便。想想以前的单体利用，比方一个简单的业务利用，很可能在 B 构建的时候没有通过 lint 导致整个利用失败掉，这样既节约了构建 A 的工夫，又让整个利用的构建变为串行，低效。

2.5 团队自治

除了代码和公布周期上的解耦之外，微前端还有助于造成独立的团队，由不同的团队各自负责一块独立的产品性能，最好依据 Biz 去划分，因为代码都是独立的，所以基于 Biz 的前端业务团队，能够设计思考，提供更加正当的接口和能力。甚至能够形象更多的根底能力，依照业务思考提供更加齐备的能力，也就是团队更加自治。

3 如何实现

微前端次要采纳的是组合式利用路由计划，该计划的核心思想是“主从”（玩过 Jenkins 的同学是不是很耳熟），即包含一个基座“MainApp“利用和若干个微利用（MircroApp），基座大多采纳的是一个前端 SPA 我的项目，次要负责利用注册、路由映射、音讯下发等，而微利用是独立的前端我的项目，这些我的项目不限于采纳的具体技术（React、Vue、Angular、Jquery）等等，每个微利用注册到基座中，由基座进行治理，即便没有基座，这些微利用都能够独自拜访，如下：

一个微利用框架须要解决的问题是：

• 路由切换的散发问题

  作为微前端的基座利用，是整个利用的入口，负责承载以后微利用的展现和对其余路由微利用的转发，对于以后微利用的展现，个别是由以下几步形成：

  1. 作为一个 SPA 的基座利用，自身是一套纯前端我的项目，要想展现微利用的页面除了采纳 iframe 之外，要能先拉取到微利用的页面内容，这就须要 近程拉取机制。
  2. 近程拉取机制通常会采纳 fetch API 来首先获取到微利用的 HTML 内容，而后通过解析将微利用的 JavaScript 和 CSS 进行抽离，采纳 eval 办法来运行 JavaScript，并将 CSS 和 HTML 内容 append 到基座利用中留给微利用的展现区域，当微利用切换走时，同步卸载这些内容，这就形成的以后利用的展现流程。
  3. 当然这个流程里会波及到 CSS 款式的净化以及 JavaScript 对全局对象的净化，这个波及到隔离问题会在前面探讨，而目前针对近程拉取机制这套流程，已有现成的库来实现，能够参考 import-html-entry 和 system.js。

  对于路由散发而言，以采纳 vue-router 开发的基座 SPA 利用来举例，次要是上面这个流程：

  1. 当浏览器的门路变动后，vue-router 会监听 hashchange 或者 popstate 事件，从而获取到路由切换的机会。
  2. 最先接管到这个变动的是基座的 router，通过查问注册信息能够获取到转发到那个微利用，通过一些逻辑解决后，采纳批改 hash 办法或者 pushState 办法来路由信息推送给微利用的路由，微利用能够是手动监听 hashchange 或者 popstate 事件接管，或者采纳 React-router，vue-router 接管路由，前面的逻辑就由微利用本人管制。

• 主利用、微利用的隔离问题

  利用隔离问题次要分为主利用和微利用，微利用和微利用之间的 JavaScript 执行环境隔离，CSS 款式隔离，咱们先来说下 CSS 的隔离。

  CSS 隔离：当主利用和微利用同屏渲染时，就可能会有一些款式会互相净化，如果要彻底隔离 CSS 净化，能够采纳 CSS Module 或者命名空间的形式，给每个微利用模块以特定前缀，即可保障不会相互烦扰，能够采纳 webpack 的 postcss 插件，在打包时增加特定的前缀。

  而对于微利用与微利用之间的 CSS 隔离就非常简单，在每次利用加载时，将该利用所有的 link 和 style 内容进行标记。在利用卸载后，同步卸载页面上对应的 link 和 style 即可。

  JavaScript 隔离 ：每当微利用的 JavaScript 被加载并运行时，它的外围实际上是对全局对象 Window 的批改以及一些全局事件的扭转，例如 jQuery 这个 js 运行后，会在 Window 上挂载一个window.$ 对象，对于其余库 React，Vue 也不例外。为此，须要在加载和卸载每个微利用的同时，尽可能打消这种抵触和影响，最广泛的做法是采纳沙箱机制（SandBox）。

  沙箱机制的外围是让部分的 JavaScript 运行时，对外部对象的拜访和批改处在可控的范畴内，即无论外部怎么运行，都不会影响内部的对象。通常在 Node.js 端能够采纳 vm 模块，而对于浏览器，则须要联合 with 关键字和 window.Proxy 对象来实现浏览器端的沙箱。

• 通信问题

  利用间通信有很多种形式，当然，要让多个拆散的微利用之间要做到通信，实质上仍离不开两头媒介或者说全局对象。所以对于音讯订阅（pub/sub）模式的通信机制是十分实用的，在基座利用中会定义事件核心 Event，每个微利用别离来注册事件，当被触发事件时再有事件核心对立散发，这就形成了根本的通信机制，流程如下图：

目前开源了很多微前端框架，比方 qiankun，感兴趣的能够去看看源码

4. 是否采纳微前端

为什么要做微前端？或者说微前端解决了什么问题？也就答复了是否须要采纳微前端。微前端的鼻祖 Single-spa 最后要解决的问题是，在老我的项目中应用新的技术栈。现阶段蚂蚁金服微前端框架 Qiankun 所申明的微前端要解决的另一个次要问题是，巨石工程所面临的保护艰难喝合作开发艰难的问题。如果工程面临这两方面的问题，我感觉微前端就能够试试了。你们感觉呢？

三、微服务平台下基于 GraphQL 构建 BFF 的思考

1. 大前端架构演进

咱们来讲一个故事

1. V1

假如晚期 2011 年一家电商公司实现了单体利用的拆分，后端服务曾经 SOA 化，此时利用的状态仅有 Web 端，V1 架构图如下所示：

2. V2

工夫来到了 2012 年初，国内刮起了一阵无线利用的风，各个大厂都开始了本人的无线利用开发。为了应答该需要，架构调整为 V2，如下所示

这个架构存在一些问题：

• 无线 App 和外部的微服务强耦合，任何一侧的变动都可能对另一侧造成影响
• 无线 App 须要晓得外部服务细节

• 无线 App 端须要做大量的聚合裁剪和适配逻辑

  聚合：某一个页面可能同时须要调用好几个后端 API 进行组合，比方商品详情页所需的数据，不能一次调用实现

  裁剪：后端提供的根底服务比拟通用，返回的 Payload 比拟大，字段太多，App 须要依据设施和业务需要，进行字段裁剪用户的客户端是 Android 还是 iOS，是大屏还是小屏，是什么版本。再比方，业务属于哪个行业，产品状态是什么，性能投放在什么场景，面向的用户群体是谁等等。这些因素都会带来面向端的性能逻辑的差异性。后端在微服务和畛域驱动设计（不在本文重点解说领域）的背景下，各个服务提供了以后 Domain 的根底性能，比方商品域，提供了商品新增、查问、删除性能，列表性能、详情页性能。

  然而在商品详情页的状况下，数据须要调用商品域、库存域、订单域的能力。客户端须要做大量的网络接口解决和数据处理。

  适配：一些常见的适配常见就是格局转换，比方有些后端服务比拟老，提供 SOAP/XML 数据，不反对 JSON，这时候就须要做一些适配代码

• 随着应用类型的增多（iOS Phone/Pad、Android Phone/Pad、Hybrid、小程序），聚合裁剪和适配的逻辑的开发会造成设施端的大量重复劳动
• 前端比方 iOS、Android、小程序、H5 各个 biz 都须要业务数据。最早的设计是后端接口直出。这样的设计会导致呈现一个问题，因为 biz1 因为迭代发版，造成后端改接口的实现。Biz2 的另一个需要又会让服务端改设计实现，造成接口是面向业务开发的。不禁会问，根底服务到底是面向业务接口开发的吗？这和畛域驱动的设计相背离

在这样的背景下诞生了 BFF（Backend For Frontend）层。各个领域提供根底的数据模型，各个 biz 存在本人的 BFF 层，按需取查问（比方商品根底数据 200 个，然而小程序列表页只须要 5 个），在比方商品详情页可能须要商品数据、订单数据、评估数据、举荐数据、库存数据等等，最早的设计该详情页可能须要申请 6 个接口，这对于客户端、网页来说，体验很差，有个新的设计，详情页的 BFF 去动静组装调用接口，一个 BFF 接口就组装好了数据，间接返回给业务方，体验很好

3. V2.1

V2 架构问题太多，没有开发施行。为解决上述问题，在外部设备和外部微服务之间引入一个新的角色 Mobile BFF。BFF 也就是 Backend for Frontend 的简称，能够认为是一种适配服务，将后端的微服务进行适配（次要包含聚合裁剪和格局适配等逻辑），向无线端设施裸露敌对和对立的 API，不便无线设施接入拜访后端服务。V2.1 服务架构如下

这个架构的劣势是：

• 无线 App 和外部服务不耦合，通过引入 BFF 这层简介，使得两边能够独立变动：

  • 后端如果发生变化，通过 BFF 屏蔽，前端设施能够做到不受影响
  • 前端如果发生变化，通过 BFF 屏蔽，后端微服务能够暂不变动
  • 当无线端有新的需要的时候，通过 BFF 屏蔽，能够缩小前后端的沟通合作开销，很多需要由前端团队在 BFF 上就能够本人搞定
• 无线 App 只须要晓得 Mobile BFF 的地址，并且服务接口是对立的，不须要晓得外部简单的微服务地址和细节
• 聚合裁剪和适配逻辑在 Mobile BFF 上实现，无线 App 端能够简化瘦身

4. V3

V2.1 架构比拟胜利，施行后较长一段时间反对了公司晚期无线业务的倒退，随着业务量暴增，无线研发团队一直减少，V2.1 架构的问题也被裸露了进去：

• Mobile BFF 中不仅有各个业务线的聚合 / 裁剪 / 适配和业务逻辑，还引入了很多横跨切面的逻辑，比方平安认证，日志监控，限流熔断等，随着工夫的推移，代码变得越来越简单，技术债越来越多，开发效率一直降落，缺点数量一直减少
• Mobile BFF 集群是个失败单点，重大代码缺点将导致流量洪峰可能引起集群宕机，所有无线利用都不可用

为了解决上述伪命题，决定在外部设备和 BFF 之间架构一个新的层，即 Api Gateway，V3 架构如下：

新的架构 V3 有如下调整：

• BFF 按团队或者业务进行解耦拆分，拆分为若干个 BFF 微服务，每个业务线能够并行开发和交付各自负责的 BFF 微服务

• 官关（个别由独立框架团队负责运维）专一横跨切面性能，包含：

  • 路由，将来自无线设施的申请路由到后端的某个微服务 BFF 集群
  • 认证，对波及敏感数据的 Api 进行集中认证鉴权
  • 监控，对 Api 调用进行性能监控
  • 限流熔断，当呈现流量洪峰，或者后端 BFF/ 微服务呈现提早或故障，网关可能被动进行限流熔断，爱护后端服务，并放弃前端用户体验能够承受。
  • 平安防爬，收集拜访日志，通过后盾剖析出歹意行为，并阻断歹意申请。
• 网关在无线设施和 BFF 之间又引入了一层间接，让两边能够独立变动，特地是当后盾 BFF 在降级或迁徙时，能够做到用户端利用不受影响

在新的 V3 架构中，网关承当了重要的角色，它是解耦和后续降级迁徙的利器，在网关的配合下，单块 BFF 实现理解耦拆分，各业务团队能够独立开发和交付各自的微服务，研发效率大大晋升，另外，把横跨切面逻辑从 BFF 剥离到网关后，BFF 的开发人员能够更加专一于业务逻辑交付，实现了架构上的关注拆散。

5 V4

业务在一直倒退，技术架构也须要一直的迭代和降级，近年来技术团队又新来了新的业务和技术需要：

• 凋谢外部的业务能力，建设开发平台。借助第三方社区开发者能力进一步拓宽业务状态
• 废除传统服务端 Web 利用模式，引入前后端拆散架构，前端采纳 H5 单页技术给用户提供更好的用户体验

V4 的思路和 V3 差不多，只是拓展了新的接入渠道：

• 引入面向第三方凋谢 Api 的 BFF 层和配套的网关层，反对第三方开发者在开放平台上开发利用
• 引入面向 H5 利用的 BFF 和配套网关，反对前后拆散和 H5 单页利用模式

V4 是一个比拟残缺的古代微服务架构，从外到内顺次是：端用户体验层 -> 网关层 -> BFF 层 -> 微服务层。整个架构档次清晰、职责明显，是一种灵便的可能反对业务不断创新的演进式架构

总结：

1. 在微服务架构中，BFF(Backend for Frontend)也称聚合层或者适配层，它次要承接一个适配角色：将外部简单的微服务，适配成对各种不同用户体验（无线 /Web/H5/ 第三方等）敌对和对立的 API。聚合裁剪适配是 BFF 的主要职责。
2. 在微服务架构中，网关专一解决跨横切面逻辑，包含路由、平安、监控和限流熔断等。网关一方面是拆合成耦的利器，同时让开发人员能够专一业务逻辑的实现，达成架构上的关注拆散。
3. 端用户体验层 -> 网关层 ->BFF 层 -> 微服务层，是古代微服务架构的典型分层形式，这个架构可能灵便应答业务需要的变动，是一种反对翻新的演变式架构。
4. 技术和业务都在一直变动，架构师要一直调整架构应答这些的变动，BFF 和网关都是架构演变的产物。

2. BFF & GraphQL

大前端模式下常常会面临上面 2 个问题

• 频繁变动的 API 是须要向前兼容的
• BFF 中返回的字段不全是客户端须要的

至此 2015 年 GraphQL 被 Facebook 正式开源。它并不是一门语言，而是一种 API 查问格调

1. 应用 GraphQL

服务端形容数据 – 客户端按需申请 – 服务端返回数据

服务端形容数据

type Project {
  name: String
  tagline: String
  contributors: [User]
}

客户端按需申请

{Project(name: 'GraphQL') {tagline}
}

服务端返回数据

{
    "project": {tagline: "A query language for APIS"}
}

2. 特点

1. 定义数据模型，按需获取

就像写 SQL 一样，形容好须要查问的数据即可

2. 数据分层

数据格式清晰，语义化强

3. 强类型，类型校验

领有 GraphQL 本人的类型形容，类型查看

4. 协定⽽非存储

看上去和 MongoDB 比拟像，然而一个是数据长久化能力，一个是接口查问形容。

5. ⽆须版本化

写过客户端代码的同学会看到 Apple 给 api 废除的时候都会表明起因，举荐用什么 api 代替等等，这点 GraphQL 也反对，另外废除的时候也形容了如何解决，如何应用。

3. 什么时候须要 BFF

• 后端被诸多客户端应用，并且每种客户端对于同一类 Api 存在定制化诉求
• 后端微服务较多，并且每个微服务都只关注于本人的畛域
• 须要针对前端应用的 Api 做一些共性话的优化

什么时候不举荐应用 BFF

• 后端服务仅被一种客户端应用
• 后端服务比较简单，提供为公共服务的机会不多（DDD、微服务）

4. 总结

在微服务架构中，BFF(Backend for Frontend)也称 re 聚合层或者适配层，它次要承接一个适配角色：将外部简单的微服务，适配成对各种不同用户体验（无线 /Web/H5/ 第三方等）敌对和对立的 API。聚合裁剪适配是 BFF 的主要职责。

在微服务架构中，网关专一解决跨横切面逻辑，包含路由、平安、监控和限流熔断等。网关一方面是拆合成耦的利器，同时让开发人员能够专一业务逻辑的实现，达成架构上的关注拆散。

端用户体验层 -> 网关层 ->BFF 层 -> 微服务层，是古代微服务架构的典型分层形式，这个架构可能灵便应答业务需要的变动，是一种反对翻新的演变式架构。

技术和业务都在一直变动，架构师要一直调整架构应答这些的变动，BFF 和网关都是架构演变的产物。

四、后端架构演进

1. 一些常见名词解释

云原生 (Cloud Native) 是一种构建和运行应用程序的办法，是一套技术体系和方法论。Cloud Native 是一个组合词，Cloud+Native。Cloud 是适应范畴为云平台，Native 示意应用程序从设计之初即思考到云的环境，原生为云而设计，在云上以最佳姿态运行，充分利用和施展云平台的弹性 + 分布式劣势。

Iaas：基础设施服务，Infrastructure as a service，如果把软件开发比作厨师做菜，那么 IaaS 就是别人提供了厨房，炉子，锅等根底货色，你本人应用这些货色，本人依据不同须要做出不同的菜。由服务商提供服务器，个别为云主机，客户自行搭建环境部署软件。例如阿里云、腾讯云等就是典型的 IaaS 服务商。

Paas：平台服务，Platform as a service，还是做菜比喻，比方我做一个黄焖鸡米饭，除了提供根底货色外，那么 PaaS 还给你提供了现成剁好的鸡肉，土豆，辣椒，你只有把这些货色放在一起，加些调料，用个小锅子在炉子上焖个 20 分钟就好了。本人只需关怀软件自身，至于软件运行的环境由服务商提供。咱们常说的云引擎、云容器等就是 PaaS。

Faas：函数服务，Function as a Service，同样是做黄焖鸡米饭，这次我只提供酱油，色拉油，盐，醋，味精这些调味料，其余我不提供，你本人依据不同口味是多放点盐，还是多放点醋，你本人决定。

Saas：软件服务，Software as a service，同样还是做黄焖鸡米饭，这次是间接现成搞好的一个一个小锅的鸡，什么调料都好了，曾经是个成品了，你只有贴个牌，间接卖出 去就行了，做多是在炉子上焖个 20 分钟。这就是 SaaS（Software as a Service，软件即服务）的概念，间接购买第三方服务商曾经开发好的软件来应用，从而免去了本人去组建一个团队来开发的麻烦。

Baas：你理解到，本人要改的货色，只须要前端改了就能够了，后端局部齐全不须要改。这时候你动脑筋，能够招了前端工程师，前端页面本人做，后端局部还是用服务商的。

这就是 BaaS（Backend as a Service，后端即服务），本人只须要开发前端局部，剩下的所有都交给了服务商。常常说的“后端云”就是 BaaS 的意思，例如像 LeanCloud、Bomb 等就是典型的 BaaS 服务商。

MicroService vs Severless：MicroService 是微服务，是一种专一于繁多责任与性能的小型服务，Serverless 相当于更加细粒度和碎片化的繁多责任与性能小型服务，他们都是一种特定的小型服务，从这个档次来说，Serverless=MicroService。

MicroService vs Service Mesh：在没有 ServiceMesh 之前微服务的通信，数据交换同步也存在，也有比拟好的解决方案，如 Spring Clould，OSS，Double 这些，但他们有个最大的特点就是须要你写入代码中，而且须要深度的写 很多逻辑操作代码，这就是侵入式。而 ServiceMesh 最大的特点是非侵入式，不须要你写特定代码，只是在云服务的层面即可享受微服务之间的通信，数据交换同步等操作，这里的代表如，docker+K8s，istio，linkerd 等。

2. 架构演进

1. 演进图

后端整个的演进能够如上图所示，经验了一直迭代，目前到了微服务、Service Mesh 的时代。具体的解释这里不做开展，感兴趣的能够去自行谷歌。跟 SOA 等量齐观的还有一个 ESB（企业服务总线），简略来说 ESB 就是一根管道，用来连贯各个服务节点，为了集成不同零碎，不同协定的服务。

ESB 能够简略了解为：它做了音讯的转化解释和路由工作，让不同的服务互联互通，应用 ESB 解耦服务间的依赖。

2. SOA 和微服务架构的差异

微服务去中心化，去掉 ESB 企业总线。微服务不再强调传统 SOA 架构外面比拟重的 ESB 企业服务总线，同时 SOA 的思维进入到单个业务零碎外部实现真正的组件化

Docker 容器技术的呈现，为微服务提供了更便当的条件，比方更小的部署单元，每个服务能够通过相似 Node 或者 Spring Boot 等技术跑在本人的过程中。

SOA 重视的是系统集成方面，而微服务关注的是齐全拆散

3. 晚期微服务架构

​

REST API：每个业务逻辑都被合成为一个微服务，微服务之间通过 REST API 通信。

API Gateway：负责服务路由、负载平衡、缓存、访问控制和鉴权等工作，向终端用户或客户端开发 API 接口

每个业务逻辑都被合成为一个微服务，微服务之间通过 REST API 通信。一些微服务也会向终端用户或客户端开发 API 接口。但通常状况下，这些客户端并不能间接拜访后盾微服务，而是通过 API Gateway 来传递申请。API Gateway 个别负责服务路由、负载平衡、缓存、访问控制和鉴权等工作。

4. 断路器

断路器背地的根本思维非常简单。您将受爱护的函数调用包装在断路器对象中，该对象监督故障。一旦故障达到某个阈值，断路器就会跳

闸，并且所有对断路器的进一步调用都会返回谬误，而基本不会进行受爱护的调用。通常，如果断路器跳闸，您还须要某种监视器警报。

通常，断路器和服务发现等根底实现独立接入。

6. 晚期微服务架构的问题及解决方案

• 框架 /SDK 太多，后续降级保护艰难
• 服务治理逻辑嵌入业务利用，占有业务服务资源
• 服务治理策略难以对立
• 额定的服务治理组件（中间件）的保护老本
• 多语言：随着 Node、Java 以及其余后端服务的衰亡，可能须要开发多套根底组件来配合主利用接入，SDK 保护老本高

随机引入了 Sidecar 模式：

将这些根底服务和应用程序绑定在一起，但应用独立的过程或容器部署，这能为跨语言的平台服务提供同构接口。SideCare 很多人会很懵逼，这个词怎么了解，上面的配图，旁边那一小坨就比拟形象了。

Sidecar 模式的劣势

• 在运行时环境和编程语言方面独立于它的主应用程序，不须要为每种语言开发一个 Sidecar
• Sidecar 能够拜访与主应用程序雷同的资源
• 因为它凑近主应用程序（部署在一起），所以在它们之间通信时没有显著的提早
• 即便对于不提供可扩展性机制的应用程序，也能够、将 sidecar 作为本人的过程附加到主应用程序所在的主机或子容器中进行扩大

7. Service Mesh 的造成

每个服务都将有一个配套的代理 sidecar，鉴于服务仅通过 sidecar 代理互相通信，咱们最终会失去相似于下图的部署：

服务网格是用于解决服务到服务通信的专用基础设施层。它负责通过形成古代云原生应用程序的简单服务拓扑来牢靠地交付申请。在实践中，服务网格通常被实现为一系列轻量级网络代理，这些代理与利用程序代码一起部署，应用程序不须要晓得。

网格 = 容器网格 + 服务

典型的 Service Mesh 架构

管制层：

• 不间接解析数据包
• 与管制立体中的代理通信，下发策略和配置
• 负责网络行为的可视化
• 通常提供 API 或者命令行工具可用于配置版本化治理，便于继续集成和部署

数据层：

• 通常是依照无状态指标设计的，但实际上为了进步流量转发性能，须要缓存一些数据，因而无状态也是有争议的
• 间接解决入站和出站数据包，转发、路由、健康检查、负载平衡、认证、鉴权、产生监控数据等
• 对利用来说通明，即能够做到无感知部署

Istio 是一个典型支流的 Service Mesh 框架。无关 Istio 的具体介绍能够看这里的电子书。

五、写在最初

为什么客户端工程师须要看这些，看上去和日常工作没啥关系，然而常识都是积攒才有用的，你先储备才有机会施展进去，常识是会复利的，某个畛域的常识和解决方案能够为你在解决其余问题的时候提供思路和眼界。另外大前端不可能只和客户端、前端打交道，后端的解决方案、技术趋势也要理解，有助于你站在更宏观的角度解决某个问题，分明设计。