gRPC是一个现代的开放源码、高性能的RPC框架,可以在任何环境中运行。它可以有效地连接数据中心内部和之间的服务,并提供可插入的负载平衡、跟踪、健康检查和身份验证支持。它也适用于最后一英里的分布式计算,将设备、移动应用程序和浏览器连接到后端服务。
我发现GRPC在后端基础结构中变得越来越重要,我希望它能用我最喜欢的语言/tsdb+/q。
我惊讶地发现,kdb+没有grpc实现。显然,(https://code.kx.com/q/interfaces/protobuf/)包不支持对rpc的解析,是否在数量上阻止了KDB+请求/服务等在grpc中实现?
为什么人们不希望在kdb+中实现rpc (grpc),并且为了实现这一功能而包装c++/c隐式是一个好主意。
谢谢你的建议。
发布于 2020-12-17 03:23:19
有趣的帖子:https://zimarev.com/blog/event-sourcing/myth-busting/2020-07-09-overselling-event-sourcing/
概述事件源,我认为这可能更适合kdb?
使用RPC调用交换信息的服务的主要问题是什么?这是RPC本质上引入的高度耦合。如果只有一个服务停止工作,整个服务组甚至整个系统都可能会崩溃。这种方法减少了独立组件的整个概念。
在我的实践中,我几乎没有遇到任何使用RPC进行服务间通信的需要。部分原因是我经常使用事件源,稍后会有更多的介绍。但是,即使没有事件源,我们也总是使用异步通信和使用事件在服务之间交换信息。
例如,电子商务系统中的订单微服务需要来自客户微服务的客户数据.微服务之间的这些依赖关系并不理想。其他微服务可能会中断,而通过https的同步RESTful请求由于其阻塞性质而不能很好地扩展。如果有一种方法可以完全消除微服务之间的依赖,那么其结果将是一个更健壮的体系结构,并且瓶颈更少。
您不需要事件源来解决此问题。事件驱动的系统完全能够做到这一点。事件源可以消除一些相关的问题,比如两阶段提交,但同样,不需要从系统中消除时态耦合。
https://stackoverflow.com/questions/65334463
复制相似问题