微服务之间相互调用方法

微服务之间相互调用常用到的是

HttpUrlConnection 或者经典的网络访问框架 HttpClient

只是在 Spring 项目中，使用 RestTemplate 显然更方便一些

RestTemplate

RestTemplate 是从 Spring3.0 开始支持的一个 HTTP 请求工具，它提供了常见的REST请求方案的模版，例如 GET 请求、POST 请求、PUT 请求、DELETE 请求以及一些通用的请求执行方法 exchange 以及 execute。RestTemplate 继承自 InterceptingHttpAccessor 并且实现了 RestOperations 接口，其中 RestOperations 接口定义了基本的 RESTful *** 作，这些 *** 作在 RestTemplate 中都得到了实现。

用法

第一个参数是 url ，url 中有一个占位符 {1} ,如果有多个占位符分别用 {2} 、 {3} … 去表示，第二个参数是接口返回的数据类型，最后是一个可变长度的参数，用来给占位符填值。

另两种参数格式

方法使用与上述类似，唯一不同之处是： getForObject 的返回值就是服务提供者返回的数据，使用 getForObject 无法获取到响应头。

postForEntity 方法第一个参数是请求地址，第二个参数 map 对象中存放着请求参数 key/value，第三个参数则是返回的数据类型

postForObject 和 postForEntity 基本一致，就是返回类型不同而已，这里不再赘述。

提供方

调用方

提供方

调用方

两个微服务同时 *** 作数据库,怎么避免重复？答:两个微服务同时 *** 作数据库,这样做可以避免重复:将save（新增）实现和select（查询实现）放在不同的方法中，在Controller层去分别调用，这样查询数据就能查到最新新增的数据，不会造成重复现象。

通过在 microk8s上部署授权服务 ，我们基本上走通了微服务通过配置中心服务（config-central）加载配置并启自己的流程。

在microk8s上部署微服务，现在仅剩下一个需要处理的问题，微服务之间通的互相调用。这里我们用我们微服务集群里的base-service 和 diagnose-service来尝试整个流程。

base服务主要提供平台的基础数据，像配置授权服务一样，我们需要写configmap、deployment、service三个yaml配置文件。

整体上与授权服务没多大区别，但又两个地方这次需要特别注意：

1. 标黄的context-path的配置， springboot2.0 需要使用：

   server.servlet.context-path= xxxx  

   如果仍沿用1.0的配置， 启动时contexnt将为‘’。

2.  必须正确配置virtualHostName, 这个参数配置，会导致ribbion找不到base服务， 我就因为填写错误，被整了一两天，后来在介绍Ribbon原理的一篇文章里，发现：

 DiscoveryEnabledNIWSServerList

 从eureka服务获取服务列表，服务集群必须由VipAddress标识

Base服务的Deployment文件，没有什么特别的，和Authorize基本一样：

Service文件，我们仍旧定义为Nodeport方便测试：

部署完成后，我们使用port-forward 命令做个端口映射。

microk8s kubectl port-forward pod/baseservice-79946b574d-kqf8x 8000:9043

通过浏览器访问localhost:8000端口，就可以访问服务了。

部署完base服务，我们来看看怎么让diagnose服务调用base服务。

1. 需要在diagnose服务的入口，声明@enableEurekaClient 和 @enableFeignClients

2. 建立feign的接口文件

Name 是我们需要需要调用的微服务名，这个名字一定要注意：

1. 都使用小写， 因为k8s对服务名有要求。

2.  这个一定对应的是相应服务的virtualHostName, 否者找不着。

当然需要加载相应的cloud包，最好通过springboot提供的工具生成。

现在需要来写配置文件configmap,这个配置文件与base服务差不多，唯一区别就是标黄的

部分， 确保自动获取打开，另外使用主动加在服务。

通过上面的配置，我们在启动服务就可以看到，baseservice将被从注册中心获取并房子啊serverlist里。

Deployment和service的书写与base服务没有任何区别，这里就省略了。完成部署后，我们通过postman做测试，可以正确返回结果。

Notes： diagnose服务的conext因为没有正确配置，所以IP和端口后直接接了restful请求路径了，这个需要注意。

检查base服务，可以看到，确实调用了接口。

至此，服务间的调用初步走通了，现在我们还需要做一件事，就是将base服务在注册中心注册的IP改为k8s中的服务名称，只需要在configmap中增加如下属性:eureka.instance.ip-address= baseservice

然后，更新配置文件和deployment文件，重启服务。查看base服务注册中的记录，可以看到hostname和ipaddr已经正确显示服务名称。

重新通过postman调用diagnose服务发现，报错，调用base服务没响应。只好重启diagonose服务，查看日志：

启动后，服务列表已经正确填充了base服务：baseservice:9043

现在重新测试接口，正常返回结果。看来需要正确的设置，feign得自动刷新参数，否则发生服务名变化后，本地缓存不能及时清理，会导致无法正常工作。

走到这里，基本上在microk8s上部署服务，并实现服务间的调用就完成了。在整个验证过程中，深深地体会了，spring cloud的不好用：虽然看起来简单，但 一不小心就可能配置错误， 而且很多功能其实k8s已经提供，完全可以掠过。 k8s中的服务，已经提供了loadbalance的作用, feign的使用其实已经没有意义。

所以，虽然将旧的虚拟机环境的微服务迁移到k8s上，基本是走通了。但是我们还需要做的更进一步，剔除springcloud的功能。

这样，让开发工程师，从繁杂的配置中解脱出来，完全可以增减团队效率。

---