写在前面的话
虽然本文篇幅较短（不足两千字），但希望对你有所帮助，如果对你有用，请点赞支持一把，也是给予我写作的动力。
自我介绍
首先介绍一下自己：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切换用于引入三个概念：
- 流量模式
- 告警模式
- 业务模式
动态展示
图上的每个节点都有三种状态
- 灰色未访问，无告警；
- 绿色健康；
- 红色不健康
然而你以为这就完了？
在现有基础上我针对第二版提出了优化方案
未来规划
- 自动刷新机制
- 连接基础服务的机制
写在最后
前端开发路漫漫其修远兮，产品迭代无休无止，希望作为互联网人多做简单的架构，做有价值的产品，做有温度有情怀的设计
我把产品第一版图片放在最后，供给有需要的小伙伴
