关于java:从零开始学gRPC二

前言

gRPC的大抵性能点置信大家肯定曾经有些理解。然而，在日常开发中咱们很少会应用原生的gRPC，更多的是心愿gRPC能集成到现有利用的开发环境中。这篇文章会围绕如何以简略的形式将gRPC集成到SpringBoot开展解说。

疾速搭建

环境筹备

• 操作系统：Windowns
• JDK版本：1.8
• 编辑工具：IntelliJ IDEA Community Edition 2021.1.2 x64

框架选型

目前开源切比拟热门的grpc和SpringBoot整合框架有两种可选计划。别离是LogNet 和 yidongnan 。（这两者略微有些区别，在最初我会有个比照） 这里我应用后者作为demo演示。

创立我的项目

本人创立一个maven我的项目就好，没有别的要求（All in one，临时不须要分模块）。想要偷懒的同学也能够借鉴之前的我的项目 ，然而我倡议本人入手尝试搭建比拟好。

MAVEN依赖

留神：我只列出了要害依赖。而且注册核心选用的是zookeeper，要留神zookeeper的版本，能够参考 这里 。

  
    net.devh
    grpc-spring-boot-starter
    2.13.1.RELEASE
  
  
    org.springframework.boot
    spring-boot-starter-web
    2.6.8
  

  
  
    org.springframework.cloud
    spring-cloud-starter-zookeeper-discovery
    3.1.2
  

配置

server:
  port: 8081

spring:
  application:
    name: demo-grpc
  cloud:
    zookeeper:
      connect-string: localhost:2181

grpc:
  client:
    greeterService1:
      address: discovery:/demo-grpc
      negotiationType: PLAINTEXT
  server:
    port: 9091

这个中央的 negotiationType要留神点（不设置的话须要对客户端传输进行加密）

SLB测试

• 本地启动zookeeper
• 本地启动两次（记得改端口，tomcat和grpc的都要改），测试代码如下。
  
  
• 测试后果展现
  
  
  我前端都是通过一个地址拜访的，申请通过gRPC的负载配置被散发到不同的端口去了，由此可见SLB失效了。

LogNet 与 yidongnan

共性：

1. 扩大了原生gRPC的服务注册、服务发现性能。
2. 和SpringCloud深度整合，有很好的扩大能力。

差别：

1. 服务发现：yidongnan间接将服务发现和gRPC自身的SLB整合，LogNet须要本人做SLB，或者手动整合gRPC的软负载能力 （官网demo上没提到如何做SLB，这里我暂且认为是这样子，晓得的敌人记得分割我更正）
2. LogNet 多了对事务和全局异样的解决能力。（通常不倡议在RPC的过程中应用事务，所以我感觉这个性能有点鸡肋）
3. LogNet 还整合了spring-cloud-stream、spring-boot-validation。

总结

这里咱们很容易就发现这两个框架次要做的是服务的主动注册和发现以及gRPC本身能力和spring cloud能力的整合（鉴权、服务可观测、链路追踪），服务治理能力弱的问题并没有失去解决（即没有提供一些适合的限流、降级、流量调度策略，也没有提供一个适合的控制台或者API去对服务进行治理。能够参考Dubbo Admin，通过它能够对Dubbo服务进行治理）。

阐明：我这里没有演示sleuth、actuator、security这些的集成，有趣味的能够去看看 文档 。

踩坑笔记

1.Client端默认设置的是密文，必须要设置TLS证书。当然也能够应用文本传输，然而生产环境不倡议。客户端平安配置传送门

文本传输配置：grpc.client.[serviceName].negotiatiOnType=PLAINTEXT

2. 若不集成SpringCloud-Discovery则不能应用注册核心做服务发现，只能固定配置,例如：
   grpc.client.[serviceName].address: static://localhost:9090,localhost:
   //9091。具体配置能够参考上面文档

 /**
     * Sets the target address uri for the channel. The target uri must be in the format:
     * {@code schema:[//[authority]][/path]}. If nothing is configured then the name of the client will be used along
     * with the default scheme. We recommend explicitly configuring the scheme used for the address resolutions such as
     * {@code dns:/}.
     *
     * 

     * Examples
     * 
     *
     * 

     * 
{@code static://localhost:9090} (refers to exactly one IPv4 or IPv6 address, dependent on the jre
     * configuration, it does not check whether there is actually someone listening on that network interface)
     * 
{@code static://10.0.0.10}
     * 
{@code static://10.0.0.10,10.11.12.11}
     * 
{@code static://10.0.0.10:9090,10.0.0.11:80,10.0.0.12:1234,[::1]:8080}
     * 
{@code dns:/localhost (might refer to the IPv4 or the IPv6 address or both, dependent on the system
     * configuration, it does not check whether there is actually someone listening on that network interface)}
     * 
{@code dns:/example.com}
     * 
{@code dns:/example.com:9090}
     * 
{@code dns:///example.com:9090}
     * 
{@code discovery:/foo-service}
     * 
{@code discovery:///foo-service}
     * 
{@code unix:} (Additional dependencies may be required)
     * 
{@code unix://} (Additional dependencies may be required)
     * 
     *
     * @param address The string representation of an uri to use as target address or null to use a fallback.
     *
     * @see gRPC Name Resolution
     * @see NameResolverProvider
     */