Kevin_T

Results 66 comments of Kevin_T

Full monitoring may cause redundant information and excessive performance loss. Is it more reasonable to perform sampling of this part of the function? like: `sample(() -> Schedulers.enableMetrics, (Predicate) () ->...

Hi You can refer to this project: https://github.com/capa-cloud/capa-java Using aws appmesh while maintaining the springboot programming model.

Thank you very much for your reply! It is very helpful to me. Yes, different technologies have different usage scenarios and cannot be generalized. I am now working on _dapr_....

Hi, I also encountered the same problem when designing the runtime api of the SDK model: https://github.com/dapr/dapr/issues/3261. `runtime.go` is too big, both from a code perspective and a developer maintenance...

Great proposal! this will power more users to migrate to dapr. When we implemented the runtime-api, we also encountered such a problem: developers wanted to make changes to the original...

@seeflood this is similar to like `delay queue` https://github.com/mosn/layotto/issues/617

Hi,此功能是否可以兼容以下场景呢: 例如部署layotto + envoy,流量先经过layotto做处理,layotto再将流量直接转发给envoy。 + 流量不经过mosn。可能是 `app -> (http/grpc) -> layotto -> (http) -> envoy -> target service + layotto->envoy走L7的http转发,而不是L4的ip转发。那是不是要加一个rpc_target_url

- [x] [WIP] send email api

我认为notify API是具有实际业务价值的,它可以帮助用户更好的进行应用系统的监控告警通知,提高用户上云过程中的信心。 我之前写过一个java的工具库[vrml](https://github.com/project-vrml/vrml),里面提供了使用IM/Email/SMS等进行通知的api。 这套工具在我们内部的系统中,目前得到了广泛的应用: + 当出现重要的exception/error时,仅使用日志error告警不及时,以及可能被淹没。所以这时候会通过IM/Email进行告警通知。 + 一些job类的逻辑,在执行完毕后,会通过IM/Email进行report,避免开发人员去查看日志。 所以这套api的定位:仅做到'通知'这项能力就足以了,并不是通过这套api进行大批量的SMS/Email 推送/营销。

Hi,以我使用的经验,可能有以下几种情况: #### 1. 阿里云的服务api是public的,aws允许出网访问 可以直接调用,这种一般是测试环境 #### 2. 阿里云的服务api是public的,aws不允许出网访问 需要在aws上借助proxy发起网络调用,一般生产环境的出网访问都要走proxy申请 #### 3. 阿里云的服务api仅允许内网访问 阿里云用户可能会将api设置为仅内网访问,或者像一些企业内部的SMS/Email等云服务也是仅私有云内网可访问。 这时候可能就需要在阿里云这边也部署一个proxy/gateway,aws的proxy访问到阿里云的这个proxy/gateway,再由这个proxy/gateway转发给内网服务。 #### 综上 可能要在component实现中,允许用户自定义proxy的能力,或者自定义发送行为逻辑(甚至用户自己重写component)的能力。 https://github.com/mosn/layotto/issues/715 : > 另,有这样一种场景: > > IM api在私有云内部可以直接访问,但在公有云上无法直接访问,可能要通过转发/验证/代理等方式才能访问。 > > 这样哪怕我已有多语言的sdk,还是要为每种语言的sdk重新开发一套转发/代理的功能。 > 这时候我希望把这个逻辑放在sidecar中,这样只需要开发一次即可,对api也没有变动。...