Optimize application

[glmapper]

增加应用面板信息展示. #10

[codecov-io]

Codecov Report

Merging #9 into master will decrease coverage by 1.68%. The diff coverage is 25.77%.

@@             Coverage Diff              @@
##             master       #9      +/-   ##
============================================
- Coverage     41.64%   39.95%   -1.69%     
- Complexity      179      189      +10     
============================================
  Files            37       52      +15     
  Lines          1263     1907     +644     
  Branches        153      210      +57     
============================================
+ Hits            526      762     +236     
- Misses          676     1074     +398     
- Partials         61       71      +10

Impacted Files	Coverage Δ	Complexity Δ
.../java/com/alipay/sofa/dashboard/impl/ZkHelper.java	85% <ø> (+75%)	6 <0> (+4)	:arrow_up:
...fa/dashboard/constants/SofaDashboardConstants.java	0% <ø> (ø)	0 <0> (ø)	:arrow_down:
...ipay/sofa/dashboard/impl/ZkCommandPushManager.java	78.23% <ø> (+75.51%)	27 <0> (+25)	:arrow_up:
...dashboard/app/actuator/ActuatorMonitorManager.java	0% <0%> (ø)	0 <0> (?)
...ard/app/zookeeper/ZookeeperApplicationManager.java	0% <0%> (ø)	0 <0> (?)
...sofa/dashboard/model/monitor/AvailableTagInfo.java	0% <0%> (ø)	0 <0> (?)
...ipay/sofa/dashboard/model/monitor/MetricsInfo.java	0% <0%> (ø)	0 <0> (?)
...ay/sofa/dashboard/app/task/AppDynamicInfoTask.java	0% <0%> (ø)	0 <0> (?)
...lipay/sofa/dashboard/model/monitor/HealthInfo.java	0% <0%> (ø)	0 <0> (?)
...ofa/dashboard/model/monitor/MemoryNonHeapInfo.java	100% <100%> (ø)	0 <0> (?)
... and 30 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 71e66dd...8727b27. Read the comment docs.

[chpengzh]

之前看的时候有几个建议:

• 跨模块实现的接口定义引用的模型最好还是不要用map而是用一个pojo去定义，比如MonitorManager.fetchInfo的返回值
• 还有就是Actuator的实现主要是靠调用相关应用的接口，这种情况比较好的一个实践是抽离dao层，然后定时任务和manager都去调用dao层的方法； 目前的实现方案是MonitorManager这个service和AppDynamicInfoTask这个task都去直接调用请求；相关的单元测试逻辑就变成了先去填充定时任务的缓存，再去调用MonitorManager的函数。如果有dao层，单元测试就可统一对接口调用做测试了。

[glmapper]

之前看的时候有几个建议:

• 跨模块实现的接口定义引用的模型最好还是不要用 map 而是用一个pojo去定义，比如MonitorManager.fetchInfo的返回值
• 还有就是Actuator的实现主要是靠调用相关应用的接口，这种情况比较好的一个实践是抽离dao层； 目前的实现方案是MonitorManager这个service和AppDynamicInfoTask这个task都去直接调用请求；相关的单元测试逻辑就变成了先去填充定时任务的缓存，再去调用MonitorManager的函数。如果有dao层，单元测试就可统一对接口调用做测试了。

是的，这部分已经抽出，重新定义了一个 RestTemplateClient 类负责用于与应用之间交互，ActuatorMonitorManager 将专注在数据解析与管理。

fetchInfo 这个在设计时没有使用 pojo 在于应用的 info 信息本身没有固定的属性，比如这样定义：

info.app.name=spring-boot-hello
info.app.version=v1.0.0
info.test.a.b.c=abc
info.test.a.c.b=acb

在解析时会解析成普通的 k-v ，在模型上统一比较难，如果有什么好的建议，欢迎 PR

[chpengzh]

请不要使用external library的方式引用 data-set 库，这样会导致离线用户无法使用应用界面。

比较简单的验证方法就是 npm install 之后在offline模式下执行 npm dev。清空浏览器缓存，进入应用detail界面，提示DataSet未定义。

因为该分支没有合并主线，所以如果方便的话请 cherry-pick 这一次提交进行修复 a30c6f

https://github.com/chpengzh/sofa-dashboard/commits/optimize-application

[chpengzh]

还有就是因为没有初始化eslint的配置，每次git提交的时候会报eslint的错误，只能通过git commit -n的方式调过预检测。因为我不知道这边项目对eslint的要求如何，如果可以的话在front下执行一次eslint --init。

[glmapper]

this pr will be closed and divide to multi sub pr