You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@servicecomb.apache.org by GitBox <gi...@apache.org> on 2021/10/26 01:57:57 UTC

[GitHub] [servicecomb-java-chassis] five111 opened a new issue #2624: 服务发现时,微服务可用性判断不合理

five111 opened a new issue #2624:
URL: https://github.com/apache/servicecomb-java-chassis/issues/2624


   ###RefreshableMicroserviceCache.java mergeInstances 171-175
   ```
   pulledInstances.stream().forEach(instance -> {
         if (instancePing.ping(instance)){
           mergedInstances.add(instance);
         }
    });
   ```
   ###ping方法实现如下
   ```
   public boolean ping(MicroserviceInstance instance) {
       if (instance.getEndpoints() != null && instance.getEndpoints().size() > 0) {
         IpPort ipPort = NetUtils.parseIpPortFromURI(instance.getEndpoints().get(0));
         try (Socket s = new Socket()) {
           s.connect(new InetSocketAddress(ipPort.getHostOrIp(), ipPort.getPort()), 3000);
           return true;
         } catch (IOException e) {
           // ignore this error
         }
       }
       return false;
     }
   ```
   ### 这边不合理处有以下几点
   
   - 微服务注册的endpoint有多个,这里只校验第一个的连通性不合理
   - 忽略异常,无详细日志 这样很难定位问题 比如 正常pull实例,find instance日志都很正常, ping失败导致无可用实例  


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@servicecomb.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



[GitHub] [servicecomb-java-chassis] five111 commented on issue #2624: 服务发现时,微服务可用性判断不合理

Posted by GitBox <gi...@apache.org>.
five111 commented on issue #2624:
URL: https://github.com/apache/servicecomb-java-chassis/issues/2624#issuecomment-951495165


   还有一个点 使用mesher注册上来的微服务 会携带他们自己的admin api,这个admin api 一般是用来检测服务可用性的
   这时 使用方一般会使用本地监听 即127.0.0.1 这样会导致sdk 校验时出问题。
   针对以上问题,我们目前重写了这部分代码,同时想与社区沟通一下思路。
   ### 思路一
   微服务支持多种协议,按理说,我应该校验每种协议的ip port是否能ping通,所以应该对每一个ep进行校验,但是这里就会出现 mesher这个特殊场景,目前是准备特殊场景特殊处理,排查eps里面的本地监听,涉及ipv4 v6 逻辑看起来会比较冗余
   ### 思路二
   对多个eps进行校验时,只要有一个能ping通,即认为这个服务是可用的


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@servicecomb.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



[GitHub] [servicecomb-java-chassis] five111 commented on issue #2624: 服务发现时,微服务可用性判断不合理

Posted by GitBox <gi...@apache.org>.
five111 commented on issue #2624:
URL: https://github.com/apache/servicecomb-java-chassis/issues/2624#issuecomment-951704331


   > > 还有一个点 使用mesher注册上来的微服务 会携带他们自己的admin api,这个admin api 一般是用来检测服务可用性的 这时 使用方一般会使用本地监听 即127.0.0.1 这样会导致sdk 校验时出问题。 针对以上问题,我们目前重写了这部分代码,同时想与社区沟通一下思路。
   > > ### 思路一
   > > 微服务支持多种协议,按理说,我应该校验每种协议的ip port是否能ping通,所以应该对每一个ep进行校验,但是这里就会出现 mesher这个特殊场景,目前是准备特殊场景特殊处理,排查eps里面的本地监听,涉及ipv4 v6 逻辑看起来会比较冗余
   > > ### 思路二
   > > 对多个eps进行校验时,只要有一个能ping通,即认为这个服务是可用的
   > 
   > 这个问题 其实不仅是mesher注册到注册中心存在127.0.0.1本地监听,javaSDK也会存在,如果存在多协议的话,某个协议以127.0.0.1本地监听地址注册到注册中心,当前的默认的telnet机制,也会存在这个问题
   
   感谢回答 看来127.0.0.1并不特殊


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@servicecomb.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



[GitHub] [servicecomb-java-chassis] liubao68 closed issue #2624: 服务发现时,微服务可用性判断不合理

Posted by GitBox <gi...@apache.org>.
liubao68 closed issue #2624:
URL: https://github.com/apache/servicecomb-java-chassis/issues/2624


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@servicecomb.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



[GitHub] [servicecomb-java-chassis] five111 edited a comment on issue #2624: 服务发现时,微服务可用性判断不合理

Posted by GitBox <gi...@apache.org>.
five111 edited a comment on issue #2624:
URL: https://github.com/apache/servicecomb-java-chassis/issues/2624#issuecomment-951705351


   > > > 还有一个点 使用mesher注册上来的微服务 会携带他们自己的admin api,这个admin api 一般是用来检测服务可用性的 这时 使用方一般会使用本地监听 即127.0.0.1 这样会导致sdk 校验时出问题。 针对以上问题,我们目前重写了这部分代码,同时想与社区沟通一下思路。
   > > > ### 思路一
   > > > 微服务支持多种协议,按理说,我应该校验每种协议的ip port是否能ping通,所以应该对每一个ep进行校验,但是这里就会出现 mesher这个特殊场景,目前是准备特殊场景特殊处理,排查eps里面的本地监听,涉及ipv4 v6 逻辑看起来会比较冗余
   > > > ### 思路二
   > > > 对多个eps进行校验时,只要有一个能ping通,即认为这个服务是可用的
   > > 
   > > 
   > > 这个问题 其实不仅是mesher注册到注册中心存在127.0.0.1本地监听,javaSDK也会存在,如果存在多协议的话,某个协议以127.0.0.1本地监听地址注册到注册中心,当前的默认的telnet机制,也会存在这个问题
   > 
   > 你说的这个问题,确实需要进行一下权衡。如果多endpoint检测,遇到不通的,就打印日志,这个ping操作是会周期性参与的,这样会存在周期性的日志错误打印,可能也不太好。
   
   感谢回答 不过这个日志应该有必要存在 我们遇到此问题时 没有思路 一路debug才找到问题根因 不过可以考虑控制遇到问题时的日志数量


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@servicecomb.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



[GitHub] [servicecomb-java-chassis] five111 closed issue #2624: 服务发现时,微服务可用性判断不合理

Posted by GitBox <gi...@apache.org>.
five111 closed issue #2624:
URL: https://github.com/apache/servicecomb-java-chassis/issues/2624


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@servicecomb.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



[GitHub] [servicecomb-java-chassis] five111 commented on issue #2624: 服务发现时,微服务可用性判断不合理

Posted by GitBox <gi...@apache.org>.
five111 commented on issue #2624:
URL: https://github.com/apache/servicecomb-java-chassis/issues/2624#issuecomment-951705351


   > > > 还有一个点 使用mesher注册上来的微服务 会携带他们自己的admin api,这个admin api 一般是用来检测服务可用性的 这时 使用方一般会使用本地监听 即127.0.0.1 这样会导致sdk 校验时出问题。 针对以上问题,我们目前重写了这部分代码,同时想与社区沟通一下思路。
   > > > ### 思路一
   > > > 微服务支持多种协议,按理说,我应该校验每种协议的ip port是否能ping通,所以应该对每一个ep进行校验,但是这里就会出现 mesher这个特殊场景,目前是准备特殊场景特殊处理,排查eps里面的本地监听,涉及ipv4 v6 逻辑看起来会比较冗余
   > > > ### 思路二
   > > > 对多个eps进行校验时,只要有一个能ping通,即认为这个服务是可用的
   > > 
   > > 
   > > 这个问题 其实不仅是mesher注册到注册中心存在127.0.0.1本地监听,javaSDK也会存在,如果存在多协议的话,某个协议以127.0.0.1本地监听地址注册到注册中心,当前的默认的telnet机制,也会存在这个问题
   > 
   > 你说的这个问题,确实需要进行一下权衡。如果多endpoint检测,遇到不通的,就打印日志,这个ping操作是会周期性参与的,这样会存在周期性的日志错误打印,可能也不太好。
   
   感谢回答 不过这个日志应该有必要存在 我们遇到此问题时 没有思路 一路debug才找到问题根因 不过可能考虑控制遇到问题时的日志数量


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@servicecomb.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



[GitHub] [servicecomb-java-chassis] five111 removed a comment on issue #2624: 服务发现时,微服务可用性判断不合理

Posted by GitBox <gi...@apache.org>.
five111 removed a comment on issue #2624:
URL: https://github.com/apache/servicecomb-java-chassis/issues/2624#issuecomment-952578780


   https://issues.apache.org/jira/browse/SCB-2351


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@servicecomb.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



[GitHub] [servicecomb-java-chassis] five111 commented on issue #2624: 服务发现时,微服务可用性判断不合理

Posted by GitBox <gi...@apache.org>.
five111 commented on issue #2624:
URL: https://github.com/apache/servicecomb-java-chassis/issues/2624#issuecomment-952578780


   https://issues.apache.org/jira/browse/SCB-2351


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@servicecomb.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



[GitHub] [servicecomb-java-chassis] fanjiwang1992 commented on issue #2624: 服务发现时,微服务可用性判断不合理

Posted by GitBox <gi...@apache.org>.
fanjiwang1992 commented on issue #2624:
URL: https://github.com/apache/servicecomb-java-chassis/issues/2624#issuecomment-951522804


   > 还有一个点 使用mesher注册上来的微服务 会携带他们自己的admin api,这个admin api 一般是用来检测服务可用性的 这时 使用方一般会使用本地监听 即127.0.0.1 这样会导致sdk 校验时出问题。 针对以上问题,我们目前重写了这部分代码,同时想与社区沟通一下思路。
   > 
   > ### 思路一
   > 微服务支持多种协议,按理说,我应该校验每种协议的ip port是否能ping通,所以应该对每一个ep进行校验,但是这里就会出现 mesher这个特殊场景,目前是准备特殊场景特殊处理,排查eps里面的本地监听,涉及ipv4 v6 逻辑看起来会比较冗余
   > 
   > ### 思路二
   > 对多个eps进行校验时,只要有一个能ping通,即认为这个服务是可用的
   
   这个问题 其实不仅是mesher注册到注册中心存在127.0.0.1本地监听,javaSDK也会存在,如果存在多协议的话,某个协议以127.0.0.1本地监听地址注册到注册中心,当前的默认的telnet机制,也会存在这个问题


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@servicecomb.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



[GitHub] [servicecomb-java-chassis] develpoerX commented on issue #2624: 服务发现时,微服务可用性判断不合理

Posted by GitBox <gi...@apache.org>.
develpoerX commented on issue #2624:
URL: https://github.com/apache/servicecomb-java-chassis/issues/2624#issuecomment-951624920


   > > 还有一个点 使用mesher注册上来的微服务 会携带他们自己的admin api,这个admin api 一般是用来检测服务可用性的 这时 使用方一般会使用本地监听 即127.0.0.1 这样会导致sdk 校验时出问题。 针对以上问题,我们目前重写了这部分代码,同时想与社区沟通一下思路。
   > > ### 思路一
   > > 微服务支持多种协议,按理说,我应该校验每种协议的ip port是否能ping通,所以应该对每一个ep进行校验,但是这里就会出现 mesher这个特殊场景,目前是准备特殊场景特殊处理,排查eps里面的本地监听,涉及ipv4 v6 逻辑看起来会比较冗余
   > > ### 思路二
   > > 对多个eps进行校验时,只要有一个能ping通,即认为这个服务是可用的
   > 
   > 这个问题 其实不仅是mesher注册到注册中心存在127.0.0.1本地监听,javaSDK也会存在,如果存在多协议的话,某个协议以127.0.0.1本地监听地址注册到注册中心,当前的默认的telnet机制,也会存在这个问题
   
   你说的这个问题,确实需要进行一下权衡。如果多endpoint检测,遇到不通的,就打印日志,这个ping操作是会周期性参与的,这样会存在周期性的日志错误打印,可能也不太好。


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@servicecomb.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org