后端有微服务，那前端呢？初探微前端的世界 _微前端

前言
最近笔者在工作上一直听到后端工程师们在谈论 Microservices(微服务) 的架构设计，听到的当下立马去查询才知道原来 Microservices 这麽潮，身为前端工程师的我当然也希望前端也可以有这麽新颖的架构，于是这篇文章就要来跟读者介绍 Micro Frontends（微前端）。
什麽是 Microservices？
在开始进入本篇文章主题之前要先跟读者们介绍什麽是 Microservices 。
Microservices 是一种软件架构，专注开发在每一个小型功能或者服务上，最后再利用模组化的方式组合出一个大型的应用程式。
如果读者是前端工程师的话可能会觉得上面的叙述很像是 ES6 module 的架构，开发者只需要专注在每个 module 上的开发，最后再利用 Bundler 打包这些 module 形成一个完整的页面甚至是应用程序，像下图这样。

文章插图

不过后端跟前端完全不一样，后端是藉由一个又一个的 request 来 real time 的执行相关的代码，所以在 Microservices 的架构中，想要让一个又一个的服务能互相沟通，这时候就是要仰赖各个 API 了。

文章插图

但这时候会有一个很大的问题，假如这三个 Service 对于前端来讲有高度相依性，以上图为例：一个完整的购物网站必须要先让使用者登入后才可以进行购买商品以及去购物车结帐，这时候在 Client 端就必须要分别打三次 API 并且互相等待才可以完成这整个流程，甚至假如刚好不小心有一个 Service 坏了需要重新启动，这时候可能会先产生一个过渡期的 API 避免 Client 端打到有问题的 Service，可是 Client 端也不可能每次都会去记住这个新产生的 API，所以这势必会造成一个很大问题。
这时候其实可以在这些 Services 上添加一个 API Gateway，对于 Client 端来说我只需要对到一个 Gateway 就好，对于这个 Gateway 来说我一样是去呼叫各个 Service 并且把资源都处理完后再回传给前端。

文章插图

如果有读者本身是 SRE 熟悉 Docker 或者 K8s 这种用来自动部属容器化应用程式的平台，对于上面这张图应该更熟悉了！像 K8s 就有类似 API Gateway 的 Ingress 而 Docker 则有 routing mesh 。
不过光有 API Gateway 其实还没办法凸显 Microservices 的特色，在 Microservices 的架构中其实每个 Service 都可以有自己的 DB，目的就是为了不要让每个 Service 之间会互相关联。

文章插图

但这样做其实有几个缺点
很难保证数据的一致性
以上图为例，假如今天有一个 member 被注销帐号，但这个 member 在被注销帐号之前在** shopping cart** 这个 Service 中有待结帐商品，这时候就会出现 member 数据不一致的问题。
DB 数据遗失
当某一个 Service 坏了需要重启，这时候 DB 的数据有可能就会遗失导致后续的数据出现错误。
为了改善这些缺点这时候就可以将这些 Service 的 DB 设计成可弃性，换句话说就是这些 DB 只是用来作为短期的数据存取而已，背后还有一个共用的大数据库去更新这些数据，通常都会利用 redis 这种 cache DB 来进行设计。
为什麽需要 Microservices？
Microservices 的好处就是可以专注开发在每个小服务上，举例来说以一个购票网站可能会在短时间内涌入大量的流量，这时候 race condition 就显得相当重要，这时候就可以利用 Go 语言进行开发，亦或者是要开发一个以效能为主的服务，这时候就可以用 Rust 进行开发。
上面也提到 Microservices 必须要仰赖 API 之间的沟通，所以通常在企业等级的产品上都会有拆分模组贩售的需求，假如这时候就是利用 Microservices 架构进行开发的话就很好拆分每个服务了。