怎么使用Spring Boot+gRPC构建微服务并部署

这篇文章主要介绍“怎么使用SpringBoot+gRPC构建微服务并部署”，在日常操作中，相信很多人在怎么使用SpringBoot+gRPC构建微服务并部署问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”怎么使用SpringBoot+gRPC构建微服务并部署”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！目前，对于Java技术栈来说，构建微服务的最佳选择是Spring Boot而Spring Boot一般搭配目前落地案例很多的微服务框架Spring Cloud来使用。Spring Cloud看似很完美，但是在实际上手开发后，很容易就会发现Spring Cloud存在以下比较严重的问题：服务治理相关的逻辑存在于Spring Cloud Netflix等SDK中，与业务代码紧密耦合。SDK对业务代码侵入太大，SDK发生升级且无法向下兼容时，业务代码必须做出改变以适配SDK的升级——即使业务逻辑并没有发生任何变化。各种组件令人眼花缭乱，质量也参差不齐，学习成本太高，且组件之间代码很难完全复用，仅仅为了实现治理逻辑而学习SDK也并不是很好的选择。绑定于Java技术栈，虽然可以接入其他语言但要手动实现服务治理相关的逻辑，不符合微服务“可以用多种语言进行开发”的原则。Spring Cloud仅仅是一个开发框架，没有实现微服务所必须的服务调度、资源分配等功能，这些需求要借助Kubernetes等平台来完成。但Spring Cloud与Kubernetes功能上有重合，且部分功能也存在冲突，二者很难完美配合。替代Spring Cloud的选择有没有呢？有！它就是Istio。Istio彻底把治理逻辑从业务代码中剥离出来，成为了独立的进程（Sidecar）。部署时两者部署在一起，在一个Pod里共同运行，业务代码完全感知不到Sidecar的存在。这就实现了治理逻辑对业务代码的零侵入——实际上不仅是代码没有侵入，在运行时两者也没有任何的耦合。这使得不同的微服务完全可以使用不同语言、不同技术栈来开发，也不用担心服务治理问题，可以说这是一种很优雅的解决方案了。所以，“为什么要使用Istio”这个问题也就迎刃而解了——因为Istio解决了传统微服务诸如业务逻辑与服务治理逻辑耦合、不能很好地实现跨语言等痛点，而且非常容易使用。只要会用Kubernetes，学习Istio的使用一点都不困难。在微服务架构中，服务之间的通信是一个比较大的问题，一般采用RPC或者RESTful API来实现。Spring Boot可以使用RestTemplate调用远程服务，但这种方式不直观，代码也比较复杂，进行跨语言通信也是个比较大的问题；而gRPC相比Dubbo等常见的Java RPC框架更加轻量，使用起来也很方便，代码可读性高，并且与Istio和Kubernetes可以很好地进行整合，在Protobuf和HTTP2的加持下性能也还不错，所以这次选择了gRPC来解决Spring Boot微服务间通信的问题。并且，虽然gRPC没有服务发现、负载均衡等能力，但是Istio在这方面就非常强大，两者形成了完美的互补关系。由于考虑到各种grpc-spring-boot-starter可能会对Spring Boot与Istio的整合产生不可知的副作用，所以这一次我没有用任何的grpc-spring-boot-starter，而是直接手写了gRPC与Spring Boot的整合。不想借助第三方框架整合gRPC和Spring Boot的可以简单参考一下我的实现。首先使用Spring Initializr建立父级项目spring-boot-istio，并引入gRPC的依赖。pom文件如下：然后建立公共依赖模块spring-boot-istio-api，pom文件如下，主要就是gRPC的一些依赖：建立src/main/proto文件夹，在此文件夹下建立hello.proto，定义服务间的接口如下：很简单，就是发送一个name返回一个带name的message。然后生成服务端和客户端的代码，并且放到java文件夹下。这部分内容可以参考gRPC的官方文档。有了API模块之后，就可以编写服务提供者（服务端）和服务消费者（客户端）了。这里我们重点看一下如何整合gRPC和Spring Boot。1) 服务端业务代码非常简单：光有业务代码还不行，我们还需要在应用启动时把gRPC Server也给一起启动起来。首先写一下Server端的启动、关闭等逻辑：定义好gRPC的启动、停止等逻辑后，就可以使用CommandLineRunner把它加入到Spring Boot的启动中去了：之所以要把gRPC的逻辑注册成Spring Bean，就是因为在这里要获取到它的实例并进行相应的操作。这样，在启动Spring Boot时，由于CommandLineRunner的存在，gRPC服务端也就可以一同启动了。2) 客户端业务代码同样非常简单：在启动客户端时，我们需要打开gRPC的客户端，并获取到channel和stub以进行RPC通信，来看看gRPC客户端的实现逻辑：比服务端要简单一些。最后，仍然需要一个CommandLineRunner把这些启动逻辑加入到Spring Boot的启动过程中：业务代码跑通之后，就可以制作Docker镜像，准备部署到Istio中去了。在开始编写Dockerfile之前，先改动一下客户端的配置文件：接下来编写Dockerfile：1) 服务端：主要是规定服务端应用的端口为18080，并且在容器启动时让服务端也一起启动。2) 客户端：可以看到这里添加了启动参数，配合前面的配置，当这个镜像部署到Kubernetes集群时，就可以在Kubernetes的配合之下通过服务名找到服务端了。同时，服务端和客户端的pom文件中添加：这样执行mvn clean package时就可以同时把docker镜像构建出来了。有了镜像之后，就可以写部署文件了：1) 免费云主机域名服务端：主要是暴露服务端的端口：18080和gRPC Server的端口18888，以便可以从Pod外部访问服务端。2) 客户端：主要是暴露客户端的端口19090，以便访问客户端并调用服务端。如果想先试试把它们部署到k8s可不可以正常访问，可以这样配置Ingress：Istio的网关配置文件与k8s不大一样：主要就是暴露/hello这个路径，并且指定对应的服务和端口。首先搭建k8s集群并且安装istio。我使用的k8s版本是1.16.0，Istio版本是最新的1.6.0-alpha.1，使用istioctl命令安装Istio。建议跑通官方的bookinfo示例之后再来部署本项目。注：以下命令都是在开启了自动注入Sidecar的前提下运行的我是在虚拟机中运行的k8s，所以istio-ingressgateway没有外部ip：所以，需要设置IP和端口，以NodePort的方式访问gateway：这样就可以了。接下来部署服务：必须要等到两个pod全部变为Running而且Ready变为2/2才算部署完成。接下来就可以通过访问到服务了。如果成功返回了Hello, JiangWen. This message comes from gRPC.的结果，没有出错则说明部署完成。到此，关于“怎么使用SpringBoot+gRPC构建微服务并部署”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注百云主机网站，小编会继续努力为大家带来更多实用的文章！

相关推荐: css里能不能用var变量

本篇内容主要讲解“css里能不能用var变量”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“css里能不能用var变量”吧! css里面能用var变量；可以利用var()函数来插入css变量的值，css变量可以访问D…