这篇主要聊下idea的构成。
平时我们比较性能测试需要耗费很长的时间来收集汇总数据，并针对特定版本进行压测。时间人力成本较大，且没有可追溯的版本测试记录，或者是wiki型的，阅读连贯性有些障碍。那么我们可以搭建一个平台，将所有的记录下沉至数据库中，开发特定的service，将性能趋势信息展现出来。
思考下域模型主要有这几个方面：
- 跑测的应用版本信息。包含各个微服务的版本信息。
- 搭建应用的环境信息（CI），包含部署的机器信息，jenkins信息，数据库信息，nfs信息等。
- 导入测试的数据模型信息：模拟客户数据场景/sample data。
- 压测的脚本信息（transaction，scenario等）。transaction一定意义上成为了系统的metadata，它需要支撑这些信息（运行在哪个平台，是否为key transaction，类型，可跑的应用等）
域模型之间相互独立。
针对4大域模型，可以进一步划分子模型。比如版本信息，可进一步拆分基础版本模型，比如搭建的容器平台，衍生的集成其他应用信息等。模型应当足够抽象，并能表述一定的业务知识。
那么有了这些模型，我如何把它串联起来显示在系统里呢？
取决于全链路监控的灵感，我采用了类似于openid的bizCode。通过bizCode（全系统唯一的key值，可代表一定的业务信息）来串联各大域模型。这样的好处个人觉得可以在物理层面上降低它们之间的耦合度，从而使逻辑简单些。
当然也有个不好的地方，基本上看到的人都会问一句，这个bizCode是啥意思？如果一个东西很多人都来寻求答案，那么它的合理性就值得存疑了？思考脸.png 好的设计应当是符合大众的认知水准，进而引导。如果一个系统用户一看就无从下手，那么它的信息就过于冗杂，让用户产生困惑。这个后面可以再研究研究。
后端计算，分析服务用的springboot搭的，效率和编码速度还是很快的。容器化也不是什么难事。当然也遇到了坑：后端用repository自带的方法（deleteById，deleteAll）删除数据的时候，死活删除不了。数据还是一直存活在数据库里。最后没招，自己写了个自定义的方法才将数据清除。通过@Query（delete from xxx where id = ?1,nativeQuery=true）方式实现。前端用的是React框架。借用了以前写health page的模版，替换后端接口，渲染一气呵成。当然期间也遇到了一个坑就是页面信息是堆嵌上去的，采用了异步调用。第一次加载没有问题，所有数据都能load进来。但是当我们切换bizCode的时候，相关模块并没有跟着刷新。原因在于使用的componentDidMount，这个方法只会在render之后执行一次。也就是说一旦页面加载成功了，后面哪怕state里的值变化，它也不会执行。那么我们寻找其他生命周期方法，目光锁定在componentDidUpdate，这个方法会一直在后端执行。一开始我们将方法替换后，页面也确实刷新了，但是很快memory很快就飙升。后端一直在发送api去请求数据，这种很容易就会把后端的连接数吃满，进而拒绝访问。性能分析的平台有性能问题会贻笑大方。
进一步思考，如果有状态改变，我才会去发送请求，否则不发。这样我页面刷新，最多也就会执行2次，一次DidMount，一次update。当然还要切记要把状态改变的值在请求数据的方法里塞到state里，否则不起作用。
未来我们还要实现的是，如果当前build性能变差超过阈值，我们通过teams发送alert信息，进而可以邮件告警。它的基准版本信息可调整。
未来我们还会接入更多的系统，系统需要支持一定的可配置性。努力实现all in one platform。
网友评论