两个微服务之间怎么调用接口，microk8s处理微服务之间的调用

大家好，如果你对两个微服务之间怎么调用接口还有些模糊，那么这篇文章就是为你准备的。我们将对两个微服务之间怎么调用接口进行深入讲解，同时也会带你一起了解关于microk8s处理微服务之间的调用的相关信息。我们希望今天的分享可以帮到你，下面，让我们开始吧！

微信小程序怎么调用微信支付接口

微信小程序是可以接入微信支付的接口的，比如目前还信用卡的小程序就可以通过微信支付来完成信用卡的还款；要使用此功能，用户只需在微信中关联一张银行卡，并完成身份认证，即可将装有app的智能手机变成一个全能钱包，之后即可购买合作商户的商品及服务，在付费时只需在自己的智能手机上输入密码，无需任何刷卡步骤即可完成整个过程且简便流畅

microk8s处理微服务之间的调用

通过在 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的功能。

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

微服务跨语言调用(摘选)

微服务架构已成为目前互联网架构的趋势，关于微服务的讨论，几乎占据了各种技术大会的绝大多数版面。国内使用最多的服务治理框架非阿里开源的 dubbo莫属，千米网也选择了 dubbo作为微服务治理框架。另一方面，和大多数互联网公司一样，千米的开发语言是多样的，大多数后端业务由 java支撑，而每个业务线有各自开发语言的选择权，便出现了 nodejs，python，go多语言调用的问题。

跨语言调用是一个很大的话题，也是一个很有挑战的技术活，目前业界经常被提及的解决方案有如下几种，不妨拿出来老生常谈一番：

当我们再聊跨语言调用时我们在聊什么？纵观上述几个较为通用，成熟的解决方案，可以得出结论：解决跨语言调用的思路无非是两种：

如果一个新型的团队面临技术选型，我认为上述的方案都可以纳入参考，可考虑到遗留系统的兼容性问题

旧系统的迁移成本

这也关键的选型因素。我们做出的第一个尝试，便是在 RPC协议上下功夫。

通用协议的跨语言支持

springmvc的美好时代

springmvc

springmvc

在没有实现真正的跨语言调用之前，想要实现“跨语言”大多数方案是使用 http协议做一层转换，最常见的手段莫过于借助 springmvc提供的 controller/restController，间接调用 dubbo provider。这种方案的优势和劣势显而易见

通用协议的支持

事实上，大多数服务治理框架都支持多种协议，dubbo框架除默认的 dubbo协议之外，还有当当网扩展的 rest协议和千米网扩展的 json-rpc 协议可供选择。这两者都是通用的跨语言协议。

rest协议为满足 JAX-RS 2.0标准规范，在开发过程中引入了@Path，@POST，@GET等注解，习惯于编写传统 rpc接口的人可能不太习惯 rest风格的 rpc接口。一方面这样会影响开发体验，另一方面，独树一帜的接口风格使得它与其他协议不太兼容，旧接口的共生和迁移都无法实现。如果没有遗留系统，rest协议无疑是跨语言方案最简易的实现，绝大多数语言支持 rest协议。

和 rest协议类似，json-rpc的实现也是文本序列化&http协议。dubbox在 restful接口上已经做出了尝试，但是 rest架构和 dubbo原有的 rpc架构是有区别的，rest架构需要对资源(Resources)进行定义，需要用到 http协议的基本操作 GET、POST、PUT、DELETE。在我们看来，restful更合适互联网系统之间的调用，而 rpc更适合一个系统内的调用。使用 json-rpc协议使得旧接口得以兼顾，开发习惯仍旧保留，同时获得了跨语言的能力。

千米网在早期实践中采用了 json-rpc作为 dubbo的跨语言协议实现，并开源了基于 json-rpc协议下的 python客户端 dubbo-client-py 和 node客户端 dubbo-node-client，使用 python和 nodejs的小伙伴可以借助于它们直接调用 dubbo-provider-java提供的 rpc服务。系统中大多数 java服务之间的互相调用还是以 dubbo协议为主，考虑到新旧协议的适配，在不影响原有服务的基础上，我们配置了双协议。

dubbo协议主要支持 java间的相互调用，适配老接口；json-rpc协议主要支持异构语言的调用。

定制协议的跨语言支持

微服务框架所谓的协议(protocol)可以简单理解为：报文格式和序列化方案。服务治理框架一般都提供了众多的协议配置项供使用者选择，除去上述两种通用协议，还存在一些定制化的协议，如 dubbo框架的默认协议：dubbo协议以及 motan框架提供的跨语言协议：motan2。

motan2协议的跨语言支持

                                                                                                            motan2

motan2

motan2协议被设计用来满足跨语言的需求主要体现在两个细节中—MetaData和 motan-go。在最初的 motan协议中，协议报文仅由 Header+Body组成，这样导致 path，param，group等存储在 Body中的数据需要反序列得到，这对异构语言来说是很不友好的，所以在 motan2中修改了协议的组成；weibo开源了 motan-go ，motan-php ，motan-openresty ,并借助于 motan-go充当了 agent这一翻译官的角色，使用 simple序列化方案来序列化协议报文的 Body部分（simple序列化是一种较弱的序列化方案）。

                                                                                                        agent

agent

仔细揣摩下可以发现这么做和双协议的配置区别并不是大，只不过这里的 agent是隐式存在的，与主服务共生。明显的区别在于 agent方案中异构语言并不直接交互。

dubbo协议的跨语言支持

dubbo协议设计之初只考虑到了常规的 rpc调用场景，它并不是为跨语言而设计，但跨语言支持从来不是只有支持、不支持两种选择，而是要按难易程度来划分。是的，dubbo协议的跨语言调用可能并不好做，但并非无法实现。千米网便实现了这一点，nodejs构建的前端业务是异构语言的主战场，最终实现了 dubbo2.js，打通了 nodejs和原生 dubbo协议。作为本文第二部分的核心内容，重点介绍下我们使用 dubbo2.js干了什么事。

Dubbo协议报文格式

                                                                                                        dubbo协议

dubbo协议

dubbo协议报文消息头详解：

magic：类似java字节码文件里的魔数，用来判断是不是 dubbo协议的数据包。魔数是常量 0xdabb

flag：标志位,一共8个地址位。低四位用来表示消息体数据用的序列化工具的类型（默认 hessian），高四位中，第一位为 1表示是 request请求，第二位为 1表示双向传输（即有返回 response），第三位为 1表示是心跳 ping事件。

status：状态位,设置请求响应状态，dubbo定义了一些响应的类型。具体类型见com.alibaba.dubbo.remoting.exchange.Response

invoke id：消息 id, long类型。每一个请求的唯一识别 id（由于采用异步通讯的方式，用来把请求 request和返回的 response对应上）

body length：消息体 body长度, int类型，即记录 Body Content有多少个字节

body content：请求参数，响应参数的抽象序列化之后存储于此。

协议报文最终都会变成字节，使用 tcp传输，任何语言只要支持网络模块，有类似 Socket之类的封装，那么通信就不成问题。那，跨语言难在哪儿？以其他语言调用 java来说，主要有两个难点：

ps：dubbo协议通讯demo（ ）