写在前面的话
虽然本文篇幅较短(不足两千字),但希望对你有所帮助,如果对你有用,请点赞支持一把,也是给予我写作的动力。
自我介绍
首先介绍一下自己:09年考了二本英语专业,10年全国翻译三级笔译证书,11年选修了网页制作,12年考了专业八级,13年毕业后出国,在海外做商务翻译一年,14年底回国,15年开始接触前端,开始了前端开发工作(感谢老东家给了平台和机会),6年来有幸接触了很多前后端的大牛,18年以来一直在架构部门、技术中台工作,最多时带了20几名前端,19年裸考北京航空航天大学的数据信息与工程专业,21年硕士毕业,这篇文章是我在架构部门的一次产品开发经历,其中产品、前端、设计都是我本人。
本文关键词
产品设计-服务拓扑关系-apm-基础设施-paas-产品设计-调用关系-性能
本文相关问题
系统性能瓶颈在哪里,输入一个url到底经历了什么,如何做一款有情怀的系统可视化大盘,有温度的产品的锻造历程
前端应用+后端应用+中间件+数据库是如何互相交互的,互相访问的次数、耗时和顺序都是什么情况?是在100qps,A--b--C,还是300ms?
正文
曾经设计过一个查看服务、应用、中间件、数据库之间调用关系的数据展示图。
排查问题时经验丰富的工程师来说,以上的图表太有用了,一个应用的bug背后可能是网络抖动、并发、缓存失效、cpu甚至是内存的问题。
然而疑难问题排查并非日常所需,对于架构师或者系统负责人来说,这样一张一张图来看,太繁琐了。而且只能看某一时间段内的调用信息,并不能完整的体现出系统的健康程度。
一个idea在心中慢慢酝酿,是不是可以研发一个大盘?
跟优秀的人(各种社区分享)学习,跟业界最佳实践(京东阿里蚂蚁和优秀的社区)学习,再加上个人的积累和沉淀。
最初大盘是这个样子的
大盘展示内容
- 1.核心应用
- 2.核心数据库
- 3.核心中间件
核心数据:
- qps
- response time
- error数量
看上去直观很多了,可产品或者业务场景还是不明显。
在北航读硕士期间,导师讲过一种鱼骨图分析法(主要用于根因分析),在项目管理中也使用鱼骨图分析项目的整体状况。
于是有了下图最初的设想。
看草图可能不够直观,现在上大招,实际网页效果更直观
整体流程
整体来看平台展示了
- 访问的先后顺序
- 访问的流量情况
- 访问的健康状况
三种模式
其中右上角的三个tab切换用于引入三个概念:
- 流量模式
- 告警模式
- 业务模式
动态展示
图上的每个节点都有三种状态
- 灰色未访问,无告警;
- 绿色健康;
- 红色不健康
然而你以为这就完了?
在现有基础上我针对第二版提出了优化方案
未来规划
- 自动刷新机制
- 连接基础服务的机制
写在最后
前端开发路漫漫其修远兮,产品迭代无休无止,希望作为互联网人多做简单的架构,做有价值的产品,做有温度有情怀的设计
我把产品第一版图片放在最后,供给有需要的小伙伴