MinFeng Hong

我想认领

## 优化关联应用功能 以前的版本存在可以重复关联的bug  并且可以关联在zk中不存在的应用  （图中并没有芜湖2，但是可以进行关联） ```java public boolean isRelatedByModuleAndApp(int mId, String appName) { return arkDao.queryRelationByModuleIdAndAppName(mId, appName).size() > 0; } ``` 这里用的并非是最优雅的解决办法，用的是最简单粗暴的，有待优化。

## 计划 - 实时性：使用定时任务、从注册中心获取服务列表和消费者生产者列表。 - 可视化：提高用户对服务可视化的体验，提高用户获取服务的信息量。 - 兼容性：用户可选择zk或sofa registry 作为注册中心，甚至兼容其他比如Eureka、consul等 - 高性能：可使用缓存数据库如redis提高性能。 - 易管理：增删改查 停用 复用，增加服务权限管理。 **实时性**： 现在的版本是检测节点变化，然后读取数据。但是消费者消费了之后是不能同步到dashboard上面，要重新部署dashboard才能获取，我们可以设置一个定时任务，进行同步数据。 - 可以选择timer - 定时任务线程池 - quartz quartz集群 **可视化**： 可以增加一个服务状态（正常使用、已停止、已过期等）、服务调用次数用来进行负载调优等。服务新增时间（gmt_create）、服务修改时间（gmt_modified），给服务备别名或前端新增备注行。 - 服务状态 -...

## 对于缓存的探讨 目前的服务信息数据是从SOFARegistry中通过rest api获取数据，然后存入缓存中。 当运行时和检测到数据变化时，都会再通过rest api再获取一次然后存入缓存中。 这个缓存的大概实现是用3个ConcurrentHashMap实现 ```java private Map serviceMap = new ConcurrentHashMap(); private Map consumerMap = new ConcurrentHashMap(); private Map providerMap = new ConcurrentHashMap(); ``` 也就是说当前的实现方法是直接把 数据存储到项目内存里面。 好处是：**存取速度快...

### 基于Websocket+Netty+Mq实现消息实时推送 ### 业务需求 实现**高并发**、**消息实时性**地从SofaDashboard Client中把应用和实例消息推送到SoDashboard，进行展示。  ### 需克服难点 - 大数据量的高并发 - 消息推送的实时性 - 解决短轮询的大量无效消息 - 解决长轮询的资源消耗 - 消息的不丢失性 ### 技术选型 这套技术体系参考与京东的京东到家中打印小票流程的实现，和抖音上用户关注的作者视频消息推送的实现。 1、采用WebSocket长连接的特点，实现消息实时性推送。 2、采用Netty作为WebSocket的容器，比较主流的有netty、tomcat、socketIO 三个框架。  3、 采用RabbitMq作为消息队列，也可以用其他优秀的MQ框架比如Kafuka、RocketMq等。 ### 消息交互架构图...

Thank you for your reply. I agree with your statement, but I think you misunderstood my meaning. I guess you're talking about `sequences`, a stricter sort relationship. What I mean...

please assign me.

I will try to organize their dependence on time, and do you have any good suggestions？ Is the scope of our refactoring the entire project or just some features.