Java架构师方案 — 不懂前端不妨碍我设计一个front end组件(架构设计之“连横”)

• 1. 先看效果图：监控大盘页面

• 2. “连横“之膨胀点风暴

• 3. “连横“之膨胀点建模

• 4. “连横“之身份建模

1. 先看效果图：监控大盘页面

特点描述

• 每个折线图都是可以动态添加，且不产生任何前端代码上的涟漪。
• 每个折线图都是相互独立，且线条的个数也可以动态添加，不会有任何涟漪。
• 每个折线图都是唯一的，唯一的key是折线图的业务唯一id。
• 折线图的显示和隐藏都可以由后台动态控制。
• 所有折线图的横坐标都是时间，且会定时统一刷新。

2. “连横“之膨胀点风暴

膨胀点风暴

监控折线图目标是组件化，因此就需要做到所有的扩展点都不需要在代码上进行修改，只需要在运维的工作维度上来操作。

所谓扩展点的前身就是膨胀点，即随着业务膨胀而膨胀的地方，我们可以观察监控组件，其中业务相关的点如下。

• 图表标题
• 图表二级标题
• 纵坐标名称
• 折线名称
• 折线数量
• 加载折线历史时间区间的数据
• 加载折线最新的数据
• 动态设置图表时间区域

3. “连横“之膨胀点建模

膨胀点建模就类似大型网站的权限系统架构设计一个思路，每个膨胀点作为一个独立唯一的资源而存在，都有自己唯一的资源id，服务端数据和前端组件的各个膨胀点通过唯一的资源id连接着。

从上面这个思路可以看出，所谓建模和抽象，其实就是赋予每个膨胀点公民id以及所需要的数据进行聚合、抽象，最后通过服务端下发这些资源所需要的数据。

因此，这些资源对数据的使用是各自完成的，即散落在前端代码各处，所幸的是这些动作不会随着业务膨胀而膨胀，没有锚定业务的变化。

膨胀点建模的思路可以参考RBAC模型

4. “连横“之身份建模

多年服务端平台架构设计的经验，膨胀点风暴之后，就是要萃取出主要的膨胀点进行建模。服务端侧建模的方式有两种模式，身份模型 和 身份上下文两种。

身份建模：对服务具有一定的入侵性，需要在每个重要节点植入身份模型数据的钩子，通过传递进来的身份id来获取身份详情信息。

身份上下文：身份信息直接贯穿所有节点，数据在一个上下文参数中装载着，节点从这个上下文参数对象中获取身份数据。