Java架构师方案 — 不懂前端不妨碍我设计一个front end组件(架构设计之“连横”)
特点描述
- 每个折线图都是可以动态添加，且不产生任何前端代码上的涟漪。
- 每个折线图都是相互独立，且线条的个数也可以动态添加，不会有任何涟漪。
- 每个折线图都是唯一的，唯一的key是折线图的业务唯一id。
- 折线图的显示和隐藏都可以由后台动态控制。
- 所有折线图的横坐标都是时间，且会定时统一刷新。
膨胀点风暴
监控折线图目标是组件化，因此就需要做到所有的扩展点都不需要在代码上进行修改，只需要在运维的工作维度上来操作。
所谓扩展点的前身就是膨胀点，即随着业务膨胀而膨胀的地方，我们可以观察监控组件，其中业务相关的点如下。
- 图表标题
- 图表二级标题
- 纵坐标名称
- 折线名称
- 折线数量
- 加载折线历史时间区间的数据
- 加载折线最新的数据
- 动态设置图表时间区域
膨胀点建模就类似大型网站的权限系统架构设计一个思路，每个膨胀点作为一个独立唯一的资源而存在，都有自己唯一的资源id，服务端数据和前端组件的各个膨胀点通过唯一的资源id连接着。
从上面这个思路可以看出，所谓建模和抽象，其实就是赋予每个膨胀点公民id以及所需要的数据进行聚合、抽象，最后通过服务端下发这些资源所需要的数据。
因此，这些资源对数据的使用是各自完成的，即散落在前端代码各处，所幸的是这些动作不会随着业务膨胀而膨胀，没有锚定业务的变化。
膨胀点建模的思路可以参考RBAC模型
多年服务端平台架构设计的经验，膨胀点风暴之后，就是要萃取出主要的膨胀点进行建模。服务端侧建模的方式有两种模式，身份模型 和 身份上下文两种。
身份建模：对服务具有一定的入侵性，需要在每个重要节点植入身份模型数据的钩子，通过传递进来的身份id来获取身份详情信息。
身份上下文：身份信息直接贯穿所有节点，数据在一个上下文参数中装载着，节点从这个上下文参数对象中获取身份数据。
正文到此结束
热门推荐
相关文章
加入我们
加我微信，拉你进群一起参与电商全链路开源项目
开源项目如下： 1. 商品服务 2.交易中台 3.支付中台 4.消息中间件—延迟中台 5.对帐平台 6.清结算平台 7.收银台服务 8.支付服务编排 9.支付渠道网关 10.抢购平台—秒杀活动 11.营销服务 12.导购服务 13.购物车服务 等等
