这一部分主要讲模块化技术的演变
image.png
上图展示了我们以前的一个数据交互逻辑，我们是按照页面来分的接口，然而，接下去我们的产品做了一个庞大的产品矩阵，导致我们的页面迅速膨胀
image.png
为了适配各个端的用户画像，我们在每个端的首页都出现了差异化的UI，这就导致我们要为每一个端都写一个首页的接口，这会带来几个方面的问题
- 随着产品矩阵的迅速膨胀，后端的接口会跟着一起增加，维护成本是巨大的。
- 前端也是要每次要重新开发，并且，还要开发埋点相关的功能。
- 测试的工作量同比增加。
上述就是模块化产生的一个背景，那模块化是如何来做的呢？
image.png
image.png
我放两张图，有利于快速理解一下模块化的思路，我进一步讲解下
模块化的整体思路是：面向组件编程
image.png
这套体系解决的问题：
- 不再重复在页面的轮子，而是把每个页面拆分成组件，通过组件的组装来达到low-code的效果。
- 前端做组件化，并且将埋点嵌入进组件化中，后续可以做拖拽化。
- 测试只需要面向组件测试即可，一旦组件通过测试，可随意组装，无需测试。
通过一个时序图来解释这个流程
image.png
上述时序图，我解释几个地方：
- groupService，这个是面向组件的一个服务，当前阶段，我们是这块是和plate放在一起的，为了方便开发，减少远程调用流程。但本身来讲，这块的工作应该是含在大前端团队，由他们来对组件后端进行开发。所以，这张图我还是将groupService拆分出来，方便理解整体架构。
- plate → groupService，这块是要并行的，为什么并行？因为如果串行，一个页面的组件非常多的时候，这个延时是几乎不可接受的；因此，我们将所有组件做并行处理，这里我们用了completeService来做并发的处理（线程池我们设置为100个core线程，部署了4台机器，这个是我们多次压测得出来了一个值），后面通过遍历completeService来做结果集合并。PS：这里有一个超时的概念，防止某个组件卡住，导致整体请求的延时，一般我们设置为1S。
- cloudService，则是我们的微服务，在模块化以前，都是gateway直接调用过来的，模块化后，要从groupService调用了。
那整体的架构图就是这样了
image.png
网友评论