上期说道：http/2还属于一种不算普及的技术协议，可能目前只适合用于内部系统集成，现在开始大面积介入可能为时尚早。不过有些项目需求不等人，需要使用这项技术，所以研究了一下akka-grpc，写了一篇介绍。本想到此为止，继续其它项目。想想这样做法有点不负责任，像是草草收场。毕竟用akka-grpc做了些事情，想想还是再写这篇跟大家分享使用kka-grpc的过程。
使用gRPC作为云平台和移动前端的连接方式，网络安全应该是必须考虑的一个重点。gRPC是支持ssl/tls安全通讯机制的。用了一个周末来研究具体使用方法，实际上是一个周末的挖坑填坑过程。把这次经历记录下来与各位分享。
关于grpc，在前面的scalaPB讨论里已经做了详细的介绍：google gRPC是一种全新的RPC框架，在开源前一直是google内部使用的集成工具。gRPC支持通过http/2实现protobuf格式数据交换。protobuf即protocol buffer，是google发明的一套全新的序列化传输协议serialization-protocol，是二进制编码binary-encoded的，相对java-object，XML，Json等在空间上占有优势，所以数据传输效率更高。由于gRPC支持http/2协议，可以实现双向通讯duplex-communication，解决了独立request/response交互模式在软件编程中的诸多局限。这是在系统集成编程方面相对akka-http占优的一个亮点。protobuf格式数据可以很方便的转换成 json格式数据，支持对外部系统的的开放协议数据交换。这也是一些人决定选择gRPC作为大型系统微服务集成开发工具的主要原因。更重要的是：用protobuf和gRPC进行client/server交互不涉及任何http对象包括httprequest,httpresponse，很容易上手使用，而且又有在google等大公司内部的成功使用经验，用起来会更加放心。
前面几篇讨论了关于gRPC方式的前后端连接集成方式。gRPC也是一个开放的标准，但讲到普及性就远远不及基于http/1.1协议的web-service了。特别是gRPC的前端编程还是有一定的门槛，所以作为一种开放的网络大平台还是必须考虑用web-service方式的集成。平台服务api可以有两样选择：一种是传统web-service方式，新的一种是rest api款式。rest api比较适合数据库表的crud操作。在2017年我曾经写了一系列博客介绍akka-http，这里就不再叙述它的细节了。这篇我们只聚焦在解决当前问题上。在POS控制平台例子里不会涉及到POST操作，应该全部是GET类型的，如：
可用性、可靠性和扩展性是衡量后台服务的基本标准，HTTP反向代理，是任何一个提供大型Web服务后台所必备的，用以提高服务的这些基础参数，且通过支持到负载均衡而进一步提升服务性能。然而，随着微服务框架的盛行，RPC技术也已经开始承载大量的微服务之间的通信，在众多RPC技术中，gRPC是Google开源的通用高性能RPC框架，因此，一个支持gRPC的反向代理的需求应运而生。
在前面几篇讨论里我们介绍了scala-gRPC的基本功能和使用方法，我们基本确定了选择gRPC作为一种有效的内部系统集成工具，主要因为下面gRPC支持的几种服务模式： 1、Unary-Call：独立的一对client-request/server-response，是我们常用的http交互模式 2、Server-Streaming：client发出一个request后从server端接收一串多个response 3、Client-Streaming：client向server发送一串多个reques
上一篇我们讨论了akka-cluster的分片（sharding）技术。在提供的例子中感觉到akka这样的分布式系统工具特别适合支持大量的带有内置状态的，相对独立完整的程序在集群节点上分布运算。这里重点要关注这些程序的内部状态，它们会占用系统资源包括内存。把状态保存在内存里相对存放在数据库里能显著提高程序运算效率。在系统出现各种情况下对这些非持久化的程序状态的管理自然就成为了需要考虑的问题，此其一。在一个多用户、高并发的大型分布式系统里往往数据库数据使用会产生大量的冲突影响系统性能。如果能够把数据库的写入和读取分成互不关联的操作就可以避免很多资源占用的冲突。
gRPC Streaming的操作对象由服务端和客户端组成。在一个包含了多个不同服务的集群环境中可能需要从一个服务里调用另一个服务端提供的服务。这时调用服务端又成为了提供服务端的客户端了（服务消费端）。那么如果我们用streaming形式来提交服务需求及获取计算结果就是以一个服务端为Source另一个服务端为通过式passthrough Flow的stream运算了。讲详细点就是请求方用需求构建Source，以连接Flow的方式把需求传递给服务提供方。服务提供方在Flow内部对需求进行处理后再把结果返回来，请求方run这个连接的stream应该就可以得到需要的结果了。下面我们就针对以上场景在一个由JDBC,Cassandra,MongoDB几种gRPC服务组成的集群环境里示范在这几个服务之间的stream连接和运算。
gRPC本身的跨平台特性及性能上的优势都促使很多大公司采用gRPC的RPC解决方案作为微服务交互的标准交互集成方式。
上篇中分析了gPRC支持的四种类型示例，本文继续示例解读，Header传值、错误处理。
◆ Spring Cloud集成gRPC gRPC本身的跨平台特性及性能上的优势都促使很多大公司采用gRPC的RPC解决方案作为微服务交互的标准交互集成方式。 到目前为止，Spring Cloud官方并没有支持gRPC，但是在GitHub上有非常多的第三方开源项目支持gRPC与Spring Cloud的集成，start数 目 最 多 的 开 源 项 目 是 grpc-spring-boot-starter 。该 项 目 也 是Spring Cloud社区推荐的gRPC项目。下面是这个项目的主要特性： ● 在
gRPC 函数的自动监控，将会在后续的文章中介绍，这里我们只介绍如何在 gRPC 代码中，实现 prometheus 监控。
https://mp.weixin.qq.com/s/4p89hhBPw6qv-0OB_T_TOg
前面我们完成了一个CQRS模式的数据采集（录入）平台。可以预见：数据的产生是在线下各式各样的终端系统中，包括web、桌面、移动终端。那么，为了实现一个完整的系统，必须把前端设备通过某种网络连接形式与数据采集平台集成为一体。有两种方式可以实现需要的网络连接：Restful-api, gRPC。由于gRPC支持http/2通讯协议，支持持久连接方式及双向数据流。所以对于POS设备这样的前端选择gRPC作为网络连接方式来实现实时的操作控制应该是正确的选择，毕竟采用恒久连接和双向数据流效率会高很多。gRPC是google公司的标准，基于protobuffer消息：一种二进制序列化数据交换机制。gRPC的优势在这里就不再细说，读者可以参考前面有关gRPC的讨论博文。
RPC 是什么？Remote Procedure Call ，远程过程调用，一种通信协议。你可以理解为，在某台机器上调用另外一台机器上的服务或方法。
我们知道RPC框架是一个CS的架构，有服务的提供者，有服务的消费者,那么一次RPC请求到底经历也什么了?这篇文章一起从源码揭秘gRPC的一次请求生命周期,从其中我们探寻RPC框架设计时一些必要的模块，
此时我们访问我们的API接口：http://localhost:9000/greeter/call
前一段时间我们探讨了SDP的一个基于集群的综合数据平台解决方案，由多种数据库组成，包括：JDBC, Cassandra 及MongoDB。其中Cassandra和MongoDB属于分布式数据库，可以在集群中任何部署节点调用。而JDBC数据库则是非分布式的，无法部署在多个节点。假设我们把每种数据库的数据处理功能以微服务microservice形式提供出来的话，任何从其它集群节点对JDBC数据库微服务的调用都需要进行数据的序列化（serialization）。虽然Cassandra和MongoDB是分布式
在 gRPC 中，可以使用 TLS/SSL 或 Token 认证来进行身份验证。以下是如何实现这两种认证方式的示例：
作者 | 罗燕珊 Apache 基金会孵化器近日迎来新成员——Pekko ，但对于部分开发者来说，Pekko 应该不陌生。 事实上，Pekko 是 Akka 项目的一个分支。不久前， Akka 的许可证从 Apache 2 更改为 Business Source License 1.1，Pekko 作为新的分支从中拉出。根据介绍，Pekko 项目提供了一套工具和框架，涵盖了分布式并发系统的复杂问题空间。它旨在支持响应式宣言的设计原则，通过提供组件来有效地在服务器内扩展系统或跨多个服务器横向扩展，是高性能、
上篇文章 Go - 实现项目内链路追踪 分享了，通过 链路 ID 可以将 请求信息、响应信息、调用第三方接口的信息、调试信息、执行的 SQL 信息、执行的 Redis 信息 串起来，记录的具体参数在文件中都有介绍。
https://www.cnblogs.com/eventhorizon/p/17497359.html
从本质上来讲，API 就是服务器和客户端之间的一个协议，指定了服务器如何基于客户端的请求提供特定的数据。
gRPC 拦截器是一种强大的功能，用于在 gRPC 调用过程中对请求和响应进行拦截、修改和监视。拦截器允许你在请求和响应被发送和接收之前或之后插入自定义逻辑，从而实现各种功能，如认证、授权、日志记录、错误处理等。拦截器可以在客户端和服务器两端使用，它们是实现横切关注点的一种重要方式。
gRPC 是一个典型的C/S模型，需要开发客户端 和 服务端，客户端与服务端需要达成协议，使用某一个确认的传输协议来传输数据，gRPC通常默认是使用protobuf来作为传输协议，当然也是可以使用其他自定义的。
客户端流式请求：客户端流式写入一系列请求，然后发送到服务端。客户端写完请求后，等待服务端接受并返回结果。
可是朋友们，有没有想过，要是每一个客户端与服务端通信的接口都进行一次认证，那么这是否会非常多余呢，且每一个接口的实现都要做一次认证，这真的太难受了
前面谈过gRPC的SSL/TLS安全机制，发现设置过程比较复杂：比如证书签名：需要服务端、客户端两头都设置等。想想实际上用JWT会更加便捷，而且更安全和功能强大，因为除JWT的加密签名之外还可以把私密的用户信息放在JWT里加密后在服务端和客户端之间传递。当然，最基本的是通过对JWT的验证机制可以控制客户端对某些功能的使用权限。
这里我们并不是把 gRPC 接口转换成 Restful API，而是让不同的 gRPC 接口与 Restful API 共存。
上一篇文章我们介绍了ProtoBuf的使用，不了解ProtoBuf的同学建议先读这篇文章：签约掘金：一文带你玩转ProtoBuf 【文末抽奖】，会用protobuf是学习gRPC的基础。
在上一篇分布式系统系列中《分布式系统中的必备良药 —— 服务治理》中阐述了服务治理的一些概念，那么与服务治理配套的必然会涉及到RPC框架。在当前互联网的大背景下，RPC的运用应该大家或多或少都有涉及，国内外的RPC框架也是百花齐放。那么各个RPC框架各自有什么特点，另外RPC的核心点又是哪些，我们该如何去选择是本文需要讲述的内容。本文会围绕.Net技术栈来展开，暂不讨论诸如dubbo之类对.Net 不太友好的框架。
gRPC 已经成为实现需要大规模快速运行的分布式软件系统的一项重要技术。简而言之，gRPC 是一个 API 框架，它允许一个程序在互联网上的一个位置传递数据到另一个位置的另一个程序中的独特函数进行处理。
自互联网诞生以来，数据网络的设计和实现就重视通用性——即支持尽可能多的应用的能力——并利用模块化组织实现这一目标。Internet 体系结构被组织为一个分层的协议栈。每个协议都提供特定的功能，构建在一个或多个低层协议之上。
APISIX API 网关提供负载均衡、动态上行、灰度发布、熔断、鉴权、可观测等丰富的流量管理功能。
Netflix使用HTTP/1.1开发了自己的技术堆栈，用于服务间通信，覆盖了为Netflix产品提供动力的总微服务的98％。几年来，这一堆栈支持了公司流媒体业务的强劲增长。但到2015年，平台团队意识到它还“使我们正在努力的一些架构模式永久化，并且大规模影响了工程的生产力，”运行平台工程总监Tim Bozarth说。用于与远程服务交互的客户端通常包含手写代码，这非常耗时，“有机会产生问题，引入的错误，以及产生额外的复杂性，”他说。此外，当团队构建定义API的服务时，没有明确的方法来注释和准确描述API的功能，从而使发现、审计和理解生态系统中可用的API变得具有挑战性。为了寻找新的解决方案，该团队还希望服务客户端跨语言工作，重点是Java和Node.js.
既然有server，那么肯定有client（客户端），client的作用就是向server发送请求，具体就是生成一个请求，然后把它发送到server，然后等待server的响应。
相信大家日常经常使用kibana、grafana、jaeger等平台观察系统状态和定位问题，这些就是可观测体系的一部分。可观测主要包括：
服务限流是最常见的一种服务自我保护措施之一，防止流量洪峰打垮服务。Spring Cloud Tencent Rate Limit 模块内置了针对 Spring Web 和 Spring WebFlux 场景的限流 Filter，结合 Polaris 的限流功能帮忙业务快速接入限流能力。
grpc的中间件以及中间件库有很多，go-grpc-middleware应该是其中应用最广泛，本文主要介绍其中的grpc_zap、grpc_auth和grpc_recovery中间件。
借助 gRPC，我们可以在 .proto 文件中一次定义我们的服务，并以 gRPC 支持的任何语言生成客户端和服务器代码，无论是在大型数据中心内的服务器，还是在个人的电脑的环境中，这些客户端和服务器代码都可以运行 – gRPC 可以为您处理不同语言和环境之间的通信。我们还获得了使用 protocol buffers 的所有优点，包括有效的序列化，简单的 IDL 和容易的接口更新。
gRPC是一个高性能、开源、通用的RPC框架，面向移动和HTTP/2设计，是由谷歌发布的首款基于Protocol Buffers的RPC框架。
在gRPC中，身份验证被抽象为了credentials.PerRPCCredentials接口：
十月底我应邀在一个技术群里做个分享，思来想去我选择了 API 这个话题，因为很多互联网初创公司产品的第一步就是如何定义和设计一套 API，来满足产品核心所能提供的用户体验。我把 2016 年我在 Tubi 做 UAPI，2018 年我在 ArcBlock 做 Goldorin，2019 年做 Forge TX pipeline / Forge Patron 的经验揉了进去，又重新研究和回顾了 Swagger（Open API）/ GraphQL / GRPC gateway 这几个我曾经在各种场合使用过的工具，写下了一个 slides。那次讲座之后，同样的内容我又在 Tubi 内部讲了一遍，脱敏后的讲座 slides 如果大家感兴趣可以在这里获取：
grpc_0117.pptx 剖析gRPC演讲稿 各位好，今天的主题是剖析gRPC, 我们在实际工作中大量的应用gRPC做服务之间的调用。经常用写一些proto文件，用protoc把我们的proto文件生成相应语言的代码，但大多数人很少关注protoc生成的相应语言代码里都有什么内容，由于他的简单易用，我们基本上读一下文档，写一个小例子就能快速入门使用他。但一问你他的原理是什么，为什么生成的相关语言的代码里会有一些我们用不到的字段，比如生成的 file_protos_xxxxxxx_proto_raw
Kratos 是一套轻量级 Go 微服务框架，包含大量微服务相关功能及工具。名字来源于游戏《战神》，该游戏以希腊神话为背景，讲述了奎托斯（Kratos）由凡人成为战神并展开弑神屠杀的冒险历程。
本文概括性的介绍gRPC，包括gRPC的起源，核心特性，生态体系，以及一些知名开源软件对gRPC的使用，最后总结gRPC与netty、dubbo等框架的区别，目的是让读者从整体上对gRPC有一个相对全面的认知。
演示应用程序 emojivoto 有一些问题。让我们用它和 linker 来诊断一个应用程序，它的失败方式比整个服务崩溃要微妙得多。本指南假设您已经按照入门指南中的步骤进行了操作， 并在 Kubernetes 集群中运行了 linker 和演示应用程序。如果你还没做完，那就开始吧，做完就回来！
首先声明：标题上的所谓编程模式是我个人考虑在集群环境下跨节点（jvm）的流程控制编程模式，纯粹按实际需要构想，没什么理论支持。在5月份的深圳scala meetup上我分享了有关集群环境下的编程模式思路。我提供了下面这个示意图：
原题：When to Use What: REST, GraphQL, Webhooks, & gRPC
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
云直播
对象存储
