Kevin_T

我们目前没有 phoneCall API的需求呢，我们做监控告警主要是 IM/SMS/EMail。 我们这边phoneCall一般是：触发了某个指标，由某个SRE系统/平台，监控到这个指标，再发起phoneCall。应该不会直接由业务应用调用sidecar发起。 不过我感觉phoneCall可能中小型公司会有使用场景吧，公司内部可能没有搭建一套专业的SRE平台，这时候业务应用判断发生重大故障时，可能会想发起phoneCall。 但如果可以使用"写入指标+监听指标+发起phoneCall"的方式，应该会更好，但不知道阿里云上是否有这种能力。（AWS上可以通过写入CloudWatch指标，然后给这个指标配一个告警，告警内容可以自己实现发起phoneCall） 说回来，这种可能存在重大故障的应用，一般也不会做成多语言吧？

> 但可能有多云部署需求（比如 AWS 上调用 AWS Pinpoint 那看起来，是的。PhoneCall API，应该是有客户用的，但可能比较少。 或者先集成到SMS API里面？

我个人比较倾向a方案。 因为这几种渠道，有大量的参数差异，无法被抹平。以及应用场景有明确的区别。 同时，可能有的场景逻辑会比较复杂，若采用b方案，则对其的改动可能会影响其他场景。 随着支持saas服务的增多，如果都统一到一个saas api中，将会膨胀为一个巨大api，增加了理解成本。

就我目前使用IM的场景来看： > 用户有 “从 A IM 透明切换到 B IM ” 的需求么（比如想 "不改代码，从发微信消息切到发钉钉消息"）？ > 我这了解到的需求都是调钉钉，感觉通用的用户需求是“不管代码是部署到阿里云还是aws，都是给 XXX IM 的YYY 群发消息” 不太会有“从 A IM 透明切换到 B IM ”的场景，每个公司如果自己内部落地的话，可能是唯一指定的IM。 但如果将layotto/dapr/...放到云平台，作为托管服务呢？是否要支持不同用户的不同IM需求。 > 如果 1 真有这需求，那真的有必要走...

另，有这样一种场景： IM api在私有云内部可以直接访问，但在公有云上无法直接访问，可能要通过转发/验证/代理等方式才能访问。 这样哪怕我已有多语言的sdk，还是要为每种语言的sdk重新开发一套转发/代理的功能。 这时候我希望把这个逻辑放在sidecar中，这样只需要开发一次即可，对api也没有变动。 综上，我个人觉得值得将IM api下沉到sidecar中，主要解决了多语言sdk的问题和后续自定义功能复用的问题。 如果社区有成熟api，那复用也完全可以呢。

Hi，notify api确实在特征上，和dapr 的binding是契合的。 因为我个人比较大量的使用过notify api，所以我认为这套api具有实际意义，那对于这类api，我感觉从binding中拆出来会比较好呢： bingding是一个较低级别的抽象，我们可以把任何东西都塞在里面。在初期，可能尽快的对接更多系统，先把东西放进去。但随着multi-runtime的发展，当我们发现一些领域的api具有更大使用价值时，我们可能要考虑将它们独立定义。 就sidecar中component的实现而言，我认为在layotto中基于binding写一个notify的组件，和单独定义一个notify的组件，可能没有什么大的不同。 但在用户层（或者说用户使用sdk时），这将有很大的不同：我们不可能要求用户使用原始的binding api，假如用户需要参照文档，自己往binding api中传那么多的参数/结构，这不够便利。那么就需要在这之上，为用户构建便捷易用的多语言的sdk api。 > 就这一点，我怀疑dapr binding api的实际用户有多少，上云应该是增效的过程，如果开发人员陷入了参考文档写binding api的困境，那为什么不使用开源已有的sdk呢，或者又要在这之上封装自己的sdk工具库了。 这就引入了以上问题，当我们在多语言sdk中定义这样的方法时，并将它们映射到binding api的grpc proto，那为什么不直接使用grpc proto来定义呢？ 使用grpc proto，使该领域的api更加清晰，主要是使用户接入更加方便。 以及，可能涉及到另一个领域，那就是SDK模型，我们希望的是社区共用一套api（无论SDK/Sidecar...），这样用户在未来具有更多的可选择性，如果都放在binding api中，那似乎社区也就没有什么共同的api了，都是基于binding api，在上面再魔改自己的sdk api了。

> @kevinten10 这部分代码量有多少呀，能贴个链接看看不？ 代码是调用了私有云的IM的api，代码量不多的，主要是封装了http接口调用+通过configuration获取req参数。 复杂的是，当我在其他云上使用这个sdk时，我需要做改造（http接口只能在私有云内调用） > 噢噢噢 刚看到 https://github.com/mosn/layotto/issues/715#issuecomment-1181264014 > 所以主要的多语言代码量在于代理转发逻辑？ > 好吧，那确实做在sidecar里是有价值的…… 是的，我将为每种语言的sdk都添加一个跨云调用的功能，代码改造量很头疼。

> 或者这样想： > 如果没有 "随时能从 微信 换成 钉钉“ 这样的 ”可移植” 需求，那……我们可以把钉钉的 http API 看成是一个“多语言 API”，我们似乎没必要“用 gRPC 再描述一遍钉钉 API”，你也似乎不必维护多语言的 IM sdk，直接让业务方调 钉钉 的 http API 就行？ 恩恩，如果直接调用http api能解决问题也可以。 主要目前我们除了调用http API还有一些功能： +...

### A、目前Capa SDK模式在落地中的痛点： #### 1. 多语言问题： 我们目前主要有java/nodejs两种语言，后续可能拓展到python/golang语言，同一个逻辑需要在多种语言中实现，开发维护成本高。 #### 2. 版本迭代问题： 在公有云落地初期，需要定制/兼容的逻辑比较多，经常改一行代码然后就要升级sdk版本，再去推业务方升级，业务方频繁升级导致推进困难。 #### 3. Java依赖冲突： 由于CapaSDK需要和第三方sdk一起运行，有时会涉及到多个云的sdk。虽然借助maven做了依赖隔离管理，但有时还是会遇到依赖冲突的问题，在解决依赖冲突上花费了比较大的精力。 #### 4. 发包链路长： 由于Capa分成了好几个层次（api层/spi实现层等），相互之间通过maven发布的jar包进行引用。导致修改一个功能，需要依次升级多个包，开发效率较低。 ------ ### B、Capa run on multi-runtime调研： #### 1. 在私有云，继续使用sdk模式。 私有云功能由专门的中间件sdk提供，直接复用，不需要做很多自定义逻辑。 ####...

### C、功能下沉到sidecar #### 1. configuration configuration对性能要求比较低，容错度比较高。所以会先考虑下沉到sidecar中。 Capa目前在aliyun上使用MSE Nacos-Client，在aws上使用appconfig client。 目前，Capa做了一些自定义逻辑在里面： 1. 定时轮询，根据某个配置文件中的自定义时间，定时轮询获取最新的版本信息（appconfig sdk不支持服务端推送模式，只能通过get方法获取更新）。 2. 主要使用了get/subscribe方式，目前未使用到save/delete方法 --- #### 2. RPC Client 目前，在aws/aliyun的Capa SDK中链路如下： 业务代码通过Capa-Adaptor SDK发起RPC调用 -> invokeMethod API -> Capa SDK...