• 大部分公司迁移到微服务架构面临的一个挑战是如何实现微服务之间的通信。 在过去单体架构中，各个组件都在同一个进程中运行，相互通信只是相互的函数的调用而已。但是在微服务环境中，组件之间是由服务器硬性边界分隔了，一般位于不同的VM或JVM或服务器中，相互之间需要
  • gRPC-Web是一个JavaScript客户端库，使Web应用程序能够直接与后端gRPC服务通信，而不需要HTTP服务器充当中介。这意味着你现在可以通过使用.proto 文件定义客户端和服务器端数据类型和服务接口，轻松构建真正的端到端gRPC
  • 建设一个高扩展性 松耦合系统是非常艰难的，随着移动和物联网设备增加扩展，不断增长的数据量和越来越高的客户期望，能够高效，可靠地在互联网规模的开发和运行系统变得非常关键。 在这样的互联网环境中，开发者总是会和不同语言 框架和技术打交道，各种微服务互动，这就使 icon
  • gRPC Spring Boot Starter特点： 使用@ GrpcService自动创建并运行一个 gRPC 服务，内嵌在 spring-boot 应用中 使用@ GrpcClient自动创建和管理你的channel和stub 支持  icon
  • 在构建新的API（如HTTP/2，流，跨语言支持，服务器推送等）时使用gRPC而不是HTTP/JSON有很多优点。最难的部分往往是如何处理HTTP/ JSON的遗留服务。这就是为什么gRPC-JSON转码非常有吸引力的原因：我们可以实现基于gRPC的服务器，但是使用HTTP/JSON接口暴露 icon
  • 最近由于gRPC的噪音很多，人们开始质疑其优雅性，这篇文章也顺便黑了一把，gRPC在概念上与SOAP非常相似，只是它使用Protobuf而不是使用XML来定义服务。就像SOAP一样，它是URL和Header魔法的大杂烩 ，不过gRPC是与HTTP / 2死死绑定了。注意的是HTTP / 2是 icon
  • 在20世纪90年代末和2000年代早期，分布式API在HTTP协议上的主要用途是以相对简单的远程过程调用（RPC）方式交换可扩展标记语言（XML）格式的文档。诸如XML-RPC之类的协议演变为简单对象访问协议（SOAP），从而产生了广为人知的Web服务方法。这些主要是机器到机器之间的 icon
  • 许多新的gRPC用户惊讶地发现Kubernetes的默认负载平衡通常不能与gRPC一起使用。 gRPC需要特殊的负载平衡！ 让我们理解为什么我们需要为gRPC做一些特别的事情。gRPC是应用程序开 icon
  • 有人质疑谷歌鼎鼎大名的Protobuffers，它是一种快速序列化协议，主要是从学术角度质疑其类型设计教条，很多设计只是为了让其工作而设计，没有深刻哲学背景考虑，当然这个观点引起很多争论。 '我认为protobuf被设计为快速序列化，并且通过不太复 icon
  • Liiklus [li：klus]（爱沙尼亚语中的“流量”） - 基于gRPC的网关，用于基于事件的系统，如果你认为Kafka实现事件系统过于底层，可以使用该系统： 水平可扩展的gRPC流媒体网关 支持与gRPC一样多的客户端语言（Java，Go，C ++，Pytho icon
  • 结构化RPC比面向URL的REST API更容易设计和维护，因为他们让你专注于业务逻辑，而不是路由方案。更改API包括添加新字段或方法更容易，并且可以隐藏序列化的特性（例如，JSON缺少64位数字）。 gRPC实现了结构化RPC，但人们发现其复杂性 icon
  • Segment刚刚启动了 icon
  • 使用Istio，gRPC，Redis，BigQuery，Spring Boot，Spring Cloud和Stackdriver的微服务应用程序，点击标题进入项目： 具有自动完成功能的智能产品查找器 分布式堆栈驱动程序跟踪与gRPC调用之间的日志关联 基于Is icon