通过在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的功能。
这样，让开发工程师，从繁杂的配置中解脱出来，完全可以增减团队效率。
网友评论