melod_yi

无法通过内网访问页面和接口

1

在windows启动后本地能打开页面，但是通过内网ip+端口打不开。 不像一些docker应用开起来就直接能访问端口。 是我漏掉了什么步骤吗？

Lack of Configuration for Minimum Healthy Upstream Nodes in Health Checking

1

I've noticed that in Envoy's health check configuration for upstream nodes, has no option to set a minimum number of healthy nodes. Like max_ejection_percent in outlier detection. Since both health...

客户端使用没有在服务端创建的namespace Id，可以正常注册发现，但是控制台看不到

9

最近遇到一个问题，有部分业务正常在运行，注册发现都在nacos上，但是之前一直都没注意到，从控制台看不到。 后来发现是使用了一个没有在服务端创建的namespaceid，在控制台看不到，但是注册发现能正常通。这是比较具有迷惑性的。 是不是考虑做阻止注册，或者自动创建namespaceid等特性，来保持这部分的感知一致性？ ------------------------ Here is the English translation: Recently, I encountered an issue where some services were running normally, and their registration and discovery were done through Nacos, but...

Derby数据库清理历史记录的语句的性能问题

2

前情 #12769 dubbo3有非常多的元数据，和定时update元数据的机制。外加开发测试环境有较高频率地节点重启发生，导致了历史记录的量级非常大。（在不到30天内积累了大约2000条元数据和90万条历史）。 此时以10分钟为周期，清理histroy的sql会阻塞+超时。使用id或者nid的语句都会超时（即使最终一条都不会删除，也要执行很久。本地datagrip跑大致要5~8秒，服务器上挂盘的要更慢些）。  我们需要一些更贴近“服务器负载”、“服务器容量”的概念，作为单纯的“保留30天”这样的业务概念的补充。例如“保留30天，且至多保存1000条”。 或者为dubbo元数据的场景制定一些特殊方案，例如专门为一些命名空间关闭历史记录功能。或者一些特殊的接口参数，允许dubbo框架上报元数据时不记录历史版本。 -------------- 另外这些场景下，当每半小时触发快照生成的时候，也是灾难性的。 不确定我理解是否准确，但是观察到每次快照生成都会导致丢失leader并重新选主，同时触发大量timeout的报错。 快照生成或者sql执行超时，会影响集群间心跳吗？