经验首页 前端设计 程序设计 Java相关 移动开发 数据库/运维 软件/图像 大数据/云计算 其他经验
当前位置：技术经验 » Java相关 » Spring Boot » 查看文章
SpringBoot集成gRPC微服务工程搭建
来源：jb51　　时间：2019/1/21 9:20:48　　对本文有异议

前言

本文将使用Maven、gRPC、Protocol buffers、Docker、Envoy等工具构建一个简单微服务工程，笔者所使用的示例工程是以前写的一个Java后端工程，因为最近都在 学习微服务相关的知识，所以利用起来慢慢的把这个工程做成微服务化应用。在实践过程踩过很多坑，主要是经验不足对微服务还是停留在萌新阶段，通过本文 记录创建微服务工程碰到一些问题，此次实践主要是解决以下问题：

  • 如何解决、统一服务工程依赖管理

  • SpringBoot集成gRPC

  • 管理Protocol buffers文件

  • 使用Envoy代理访问gRPC

  • 部署到Docker

本文假设读者已经了解以下相关知识：

  • Maven

  • Envoy

  • gRPC

  • Protocol buffers

  • SpringBoot

  • Docker

由于是初步实现微服务，不会考虑过多的细节，现阶段只需要能够使用gRPC正常通信，后续计划会发布到k8s中，使用istio实现来服务网格。

使用Maven

现在比较流行的构建工具有Maven和Gradle，现阶段后端开发大多数都是用的Maven所以本工程也使用Maven来构建项目，当然使用Gradle也可以两者概念大都想通，不同的地方大多是实现和配置方式不一致。

使用项目继承

根据Maven的POM文件继承特性，将工程分不同的模块，所有的模块都继承父pom.xml的依赖、插件等内容，这样就可以实现统一管理，并方便以后管理、维护。先看一下大概的项目结构：

  1. AppBubbleBackend   （1）
  2. ├── AppBubbleCommon
  3. ├── AppBubbleSmsService  （2）
  4. ├── AppBubbleUserService
  5. ├── docker-compose.yaml  （3）
  6. ├── pom.xml
  7. ├── protos     （4）
  8. │ ├── sms
  9. │ └── user
  10. └── scripts     （5）
  11.  ├── docker
  12.  ├── envoy
  13.  ├── gateway
  14.  └── sql

以下是各个目录的用处简述，详细的用处文章后面都会提到，先在这里列出个大概：

  1. 工程主目录

  2. 单个服务工程目录（模块）

  3. docker-compose发布文件

  4. 存放.proto文件

  5. 发布、编译时用到的脚本文件

知道大概的项目工程结构后我们创建一个父pom.xml文件，放在AppBubbleBackend目录下面：

  1. <?xml version="1.0" encoding="UTF-8"?>
  2. <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  3.    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  4.  <modelVersion>4.0.0</modelVersion>
  5.  <parent>
  6.   <groupId>org.springframework.boot</groupId>
  7.   <artifactId>spring-boot-starter-parent</artifactId>
  8.   <version>2.1.2.RELEASE</version>
  9.   <relativePath/> <!-- lookup parent from repository -->
  10.  </parent>
  11.  
  12.  <groupId>com.bubble</groupId>
  13.  <artifactId>bubble</artifactId>
  14.  <version>0.0.1-SNAPSHOT</version>
  15.  <packaging>pom</packaging>
  16.  
  17.  <modules>
  18.   <module>AppBubbleSmsService</module>
  19.   <module>AppBubbleCommon</module>
  20.   <module>AppBubbleUserService</module>
  21.  </modules>
  22.  
  23.  <!-- 省略其他部分 -->
  24. </project>

因为使用SpringBoot构架，所以主pom.xml文件继承自SpringBoot的POM文件。 有了主pom.xml后然后使每个模块的pom.xml都继承自 主pom.xml文件：

  1. <?xml version="1.0" encoding="UTF-8"?>
  2. <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  3.  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  4.  <modelVersion>4.0.0</modelVersion>
  5.  <parent>
  6.  <groupId>com.bubble</groupId>
  7.  <artifactId>bubble</artifactId>
  8.  <version>0.0.1-SNAPSHOT</version>
  9.  </parent>
  10.  <artifactId>sms</artifactId>
  11.  <version>0.0.1-SNAPSHOT</version>
  12.  
  13.  <!-- 省略其他部分 -->
  14. </project>

经过上面的配置后，所有的模块都会继承AppBubbleBackend中的pom.xml文件，这样可以很方便的更改依赖、配置等信息。

依赖管理

Maven提供依赖中心化的管理机制，通过项目继承特性所有对AppBubbleBackend/pom.xml所做的更改都会对其他模块产生影响，详细的依赖管理 内容可查看官方文档。

  1.  <dependencyManagement>
  2.   <dependencies>
  3.    <!-- gRPC -->
  4.    <dependency>
  5.     <groupId>io.grpc</groupId>
  6.     <artifactId>grpc-netty-shaded</artifactId>
  7.     <version>${grpc.version}</version>
  8.    </dependency>
  9.   </dependencies>
  10. </dependencyManagement>

通过dependencyManagement标签来配置依赖，这样可以就可以实现统一依赖的管理，并且还可以添加公共依赖。

插件管理

使用pluginManagement可以非常方便的配置插件，因为项目中使用了Protocol buffers需要集成相应的插件来生成Java源文件：

  1. <pluginManagement>
  2.    <plugins>
  3.     <plugin>
  4.      <groupId>org.xolstice.maven.plugins</groupId>
  5.      <artifactId>protobuf-maven-plugin</artifactId>
  6.      <version>0.5.1</version>
  7.      <executions>
  8.       <execution>
  9.        <goals>
  10.         <goal>compile</goal>
  11.         <goal>compile-custom</goal>
  12.        </goals>
  13.       </execution>
  14.      </executions>
  15.     </plugin>
  16.    </plugins>
  17. </pluginManagement>

Protocol buffers插件的完整配置参数，可以这这里找到。

Profile

使用Profile的目的是为了区分生成Docker镜像时的一些特殊配置，示例工程只配置了一个docker-build的profile:

  1.  <profiles>
  2.   <profile>
  3.    <id>docker-build</id>
  4.    <properties>
  5.     <jarName>app</jarName>
  6.    </properties>
  7.   </profile>
  8.  </profiles>
  9.  
  10.   <properties>
  11.   <jarName>${project.artifactId}-${project.version}</jarName>
  12.  </properties>
  13.  
  14.  <build>
  15.   <finalName>${jarName}</finalName>
  16.  </build>

如果使用mvn package -P docker-build命令生成jar包时，相应的输出文件名是app.jar这样可以方便在Dockerfile中引用文件，而不需要使用${project.artifactId}-${project.version}的形式来查找输出的jar这样可以省去了解析pom.xml文件。如果还需要特殊的参数可以或者不同的行为，可以添加多个Profile，这样配置起来非常灵活。

Protocol buffers文件管理

因为是使用微服务开发，而且RPC通信框架是使用的gRPC，所以每个服务工程都会使用.proto文件。服务工程之间又会有使用同一份.proto文件的需求，比如在进行RPC通信时服务提供方返回的消息Test定义在a.proto文件中,那么在使用方在解析消息时也同样需要a.proto文件来将接收到的消息转换成Test消息，因此管理.proto文件也有一些小麻烦。关于Protocol buffers的使用可参考 官方文档。

Protocol buffers文件管理规约

在我们的示例项目中使用集中管理的方式，即将所有的.proto文件放置在同一个目录（AppBubbleBackend/protos）下并按服务名称来划分:

  1. ├── sms
  2. │ ├── SmsMessage.proto
  3. │ └── SmsService.proto
  4. └── user
  5.  └── UserMessage.proto

还可以将整个目录放置在一个单独的git仓库中，然后在项目中使用git subtree来管理文件。

Protocol buffers 插件配置

有了上面的目录结构后，就需要配置一下Protocol buffers的编译插件来支持这种.proto文件的组织结构。在讲解如何配置插件解决.proto文件的编译问题之前，推荐读者了解一下插件的配置文档：Xolstice Maven Plugins。在我们的工程中使用如下配置：

  1. <plugin>
  2.   <groupId>org.xolstice.maven.plugins</groupId>
  3.   <artifactId>protobuf-maven-plugin</artifactId>
  4.   <version>0.5.1</version>
  5.   <configuration >
  6.    <protocArtifact>com.google.protobuf:protoc:3.5.1-1:exe:${os.detected.classifier}</protocArtifact>
  7.    <pluginId>grpc-java</pluginId>
  8.    <pluginArtifact>io.grpc:protoc-gen-grpc-java:1.17.1:exe:${os.detected.classifier}</pluginArtifact>
  9.    <additionalProtoPathElements combine.children="append" combine.self="append">
  10.     <additionalProtoPathElement>${GOPATH}/src/github.com/grpc-ecosystem/grpc-gateway/third_party/googleapis</additionalProtoPathElement>
  11.     <additionalProtoPathElement>${GOPATH}/src</additionalProtoPathElement>
  12.    </additionalProtoPathElements>
  13.    <protoSourceRoot>${protos.basedir}</protoSourceRoot>
  14.    <writeDescriptorSet>true</writeDescriptorSet>
  15.    <includeDependenciesInDescriptorSet>true</includeDependenciesInDescriptorSet>
  16.   </configuration>
  17.   <!-- ... -->
  18.  </plugin>

首先上面的插件配置使用protoSourceRoot标签将Protocol buffers的源文件目录更改成AppBubbleBackend/protos目录，因为工程中使用了googleapis来定义服务接口,所以需要使用添加additionalProtoPathElement标签添加额外的依赖文件。注意这个插件的配置是在AppBubbleBackend/pom.xml文件中的，服务工程都是继承此文件的。在父POM文件配置好以后，再看一下服务工程的插件配置：

  1. <plugins>
  2.  <plugin>
  3.  <groupId>org.xolstice.maven.plugins</groupId>
  4.  <artifactId>protobuf-maven-plugin</artifactId>
  5.  <configuration>
  6.   <includes>
  7.   <include>${project.artifactId}/*.proto</include>
  8.   <include>user/*.proto</include>
  9.   </includes>
  10.  </configuration>
  11.  </plugin>
  12.  </plugins>

服务工程主要使用includes标签，将需要的.proto文件包含在编译脚本中，includes标签中的include只是一个指定匹配.proto文件的匹配模式，<include>${project.artifactId}/*.proto</include>意思是AppBubbleBackend/protos/${project.artifactId}目录下的所有以.proto文件结尾的文件，如果服务工程有多个依赖可以将需要依赖的文件也添加到编译服务中，如上面的<include>user/*.proto</include>就将AppBubbleBackend/protos/user中的.proto文件添加进来，然后进行整体的编译。

gRPC

gRPC是由Google开源的RPC通信框架，gRPC使用Protocol buffers定义服务接口并自动生成gRPC相关代码，有了这些代码后就可以非常方便的实现gRPC服务端和gPRC客户端，过多的细节就不细说了先看一下如何使用在SpringBoot中使用gRPC。

运行gRPC服务

利用ApplicationRunner接口，在SprintBoot中运行gRPC服非常方便，只需要像下面代码一样就可以运行一个简单的gRPC服务。

  1. package com.bubble.sms.grpc;
  2.  
  3. @Component
  4. public class GrpcServerInitializer implements ApplicationRunner {
  5.  
  6.  
  7.  @Autowired
  8.  private List<BindableService> services;
  9.  
  10.  @Value("${grpc.server.port:8090}")
  11.  private int port;
  12.  
  13.  @Override
  14.  public void run(ApplicationArguments args) throws Exception {
  15.  
  16.   ServerBuilder serverBuilder = ServerBuilder
  17.     .forPort(port);
  18.  
  19.   if (services != null && !services.isEmpty()) {
  20.    for (BindableService bindableService : services) {
  21.     serverBuilder.addService(bindableService);
  22.    }
  23.   }
  24.   Server server = serverBuilder.build();
  25.   serverBuilder.intercept(TransmitStatusRuntimeExceptionInterceptor.instance());
  26.   server.start();
  27.   startDaemonAwaitThread(server);
  28.  }
  29.  
  30.  
  31.  private void startDaemonAwaitThread(Server server) {
  32.   Thread awaitThread = new Thread(() -> {
  33.    try {
  34.     server.awaitTermination();
  35.    } catch (InterruptedException ignore) {
  36.     
  37.    }
  38.   });
  39.   awaitThread.setDaemon(false);
  40.   awaitThread.start();
  41.  }
  42. }

Envoy代理

gRPC服务运行起来后就需要进行调试了，比如使用curl、chrome等工具向gRPC服务发起Restful请求，实际上gRPC的调试并没有那么简单。一开始的方案是使用了gRPC-gateway，为每个服务都启动一个网关将Http 1.x请求转换并发送到gRPC服务。然而gRPC-gateway只有go语言的版本，并没有Java语言的版本，所有在编译和使用中比较困难，后来发现了Envoy提供了envoy.grpc_json_transcoder这个http过滤器，可以很方便的将RESTful JSON API转换成gRPC请求并发送给gRPC服务器。

envoy的相关配置都放置在AppBubbleBackend/scripts/envoy目录中，里面的envoy.yaml是一份简单的配置文件：

  1. static_resources:
  2.  listeners:
  3.  - name: grpc-8090
  4.  address:
  5.   socket_address: { address: 0.0.0.0, port_value: 8090 }
  6.  filter_chains:
  7.  - filters:
  8.   - name: envoy.http_connection_manager
  9.   config:
  10.    stat_prefix: sms_http
  11.    codec_type: AUTO
  12.    # 省略部分配置
  13.    http_filters:
  14.    - name: envoy.grpc_json_transcoder
  15.    config:
  16.     proto_descriptor: "/app/app.protobin"
  17.     services: ["sms.SmsService"]
  18.     match_incoming_request_route: true
  19.     print_options:
  20.     add_whitespace: true
  21.     always_print_primitive_fields: true
  22.     always_print_enums_as_ints: false
  23.     preserve_proto_field_names: false
  24. # 省略部分配置

使用envoy.grpc_json_transcoder过滤器的主要配置是proto_descriptor选项，该选项指向一个proto descriptor set文件。AppBubbleBackend/scripts/envoy/compile-descriptor.sh是编译proto descriptor set的脚本文件， 运行脚本文件会在脚本目录下生成一个app.protobin的文件，将此文件设置到envoy.grpc_json_transcoder就可大致完成了envoy的代理配置。

使用Docker发布

经过上面的一系统准备工作之后，我们就可以将服务发布到docker中了，Docker相关的文件都放置中AppBubbleBackend/scripts/docker和一个AppBubbleBackend/docker-compose.yaml文件。在发布时使用单个Dockerfile文件来制作服务镜像：

  1. FROM rcntech/ubuntu-grpc:v0.0.5
  2. EXPOSE 8080
  3. EXPOSE 8090
  4.  
  5. #将当前目录添加文件到/bubble
  6. ARG APP_PROJECT_NAME
  7. #复制父pom.xml
  8. ADD /pom.xml /app/pom.xml
  9. ADD /protos /app/protos
  10. ADD $APP_PROJECT_NAME /app/$APP_PROJECT_NAME
  11. ADD scripts/gateway /app/gateway
  12. ADD scripts/docker/entrypoint.sh /app/entrypoint.sh
  13. RUN chmod u+x /app/entrypoint.sh
  14.  
  15. ENTRYPOINT ["/app/entrypoint.sh"]

有了Dockerfile文件后，在docker-compose.yaml里面做一些配置就能将服务打包成镜像：

  1.  sms:
  2.  build:
  3.  context: ./
  4.  dockerfile: scripts/docker/Dockerfile
  5.  args:
  6.   APP_PROJECT_NAME: "AppBubbleSmsService"
  7.  environment:
  8.  APOLLO_META: "http://apollo-configservice-dev:8080"
  9.  APP_PROJECT_NAME: "AppBubbleSmsService"
  10.  ENV: dev

同时编写了一个通用的entrypoint.sh脚本文件来启动服务器：

  1. #!/bin/bash
  2.  
  3. export GOPATH=${HOME}/go
  4. export PATH=$PATH:/usr/local/go/bin:$GOPATH/bin
  5.  
  6. rootProjectDir="/app"
  7. projectDir="${rootProjectDir}/${APP_PROJECT_NAME}"
  8.  
  9. cd ${rootProjectDir}/AppBubbleCommon
  10. ./mvnw install
  11.  
  12. cd $projectDir
  13. #打包app.jar
  14. ./mvnw package -DskipTests -P docker-build
  15. #编译proto文件
  16. ./mvnw protobuf:compile protobuf:compile-custom -P docker-build
  17.  
  18.  
  19. # Run service
  20. java -jar ${projectDir}/target/app.jar

entrypoint.sh脚本中将服务工程编译成app.jar包再运行服务。还有envoy代理也要启动起来这样我们就可以使用curl或其他工具直接进行测试了。

总结

搭建这个工程大概摸索了一周的时间，主要的时间是花在了Protocol buffers文件的管理与使用Envoy作为代理调试gRPC服务上。文章中的示例工程已经传到了GitHub: AppBubbleBackend 后面会打算慢慢的完善这个应用，这是个简单的短视屏应用除了服务器还包含了Android和iOS端，等到将后端微服务化为开源出来供学习交流使用。

参考引用

gRPC官方文档
Protocol buffers Maven 插件文档
Protocol buffers官方文档
gRPC 官方文档中文版
gRPC-JSON transcoder

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持w3xue。

 友情链接：直通硅谷 　点职佳 　北美留学生论坛

Spring Boot热门文章

  • 史上最详 Thymeleaf 使用教程
  • Spring Boot如何通过java -jar启动
  • Spring Boot 2.x（六）：优雅的统一返回值
  • Springboot使用Logback实现日志配置与异常记录
  • 使用SpringBoot+EasyExcel+Vue实现excel表格的导入和导出详解
  • spring boot上传文件超出大小异常无法捕获问题
  • paging组件的用法和意义
  • springboot2.0集成rabbitmq的示例代码
  • Spring MVC学习step1——框架熟悉
  • spring boot ${}占位符不起作用的解决方案

    • Spring Boot推荐文章

  • 3分钟带你搞定Spring Boot中Schedule
  • 不单独部署注册中心，又要具备注册中心的功能，我能上天！
  • 从零开始学Spring Boot系列-集成Spring Security实现用户认证与授权
  • 不单独部署注册中心，又要具备注册中心的功能，咋不让我上天？
  • EasyExcel 无法读取图片？用poi写了一个工具类
  • 【进阶篇】使用 Stream 流对比两个集合的常用操作分享
  • 关于DDD和COLA的一些总结和思考
  • SnakeYaml反序列化分析
  • RestTemplate进行https请求时适配信任证书
  • Kryo反序列化链分析

    • 本站QQ群：前端 618073944 | Java 606181507 | Python 626812652 | C/C++ 612253063 | 微信 634508462 | 苹果 692586424 | C#/.net 182808419 | PHP 305140648 | 运维 608723728

    W3xue 的所有内容仅供测试，对任何法律问题及风险不承担任何责任。通过使用本站内容随之而来的风险与本站无关。
    关于我们  |  意见建议  |  捐助我们  |  报错有奖  |  广告合作、友情链接（目前9元/月）请联系QQ：27243702 沸活量
    皖ICP备17017327号-2　皖公网安备34020702000426号