从 0 开始学微服务
胡忠想
微博技术专家
64643 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 43 讲
开篇词 (1讲)
结束语 (1讲)
从 0 开始学微服务
15
15
1.0x
00:00/00:00
登录|注册

04 | 如何发布和引用服务?

gRPC协议使用Protobuf文件来定义接口的
有两种最常用的IDL:Thrift协议和gRPC协议
用作跨语言平台的服务之间的调用
适合公司内部联系比较紧密的业务之间采用
服务消费者进程启动时,通过加载client.xml配置文件来引入要调用的接口
服务提供者进程启动时,通过加载server.xml配置文件将接口暴露出去
服务提供者定义接口,并实现接口
服务消费者可以通过HTTP协议调用服务
服务提供者通过部署代码到Tomcat中,并配置Tomcat中的web.xml
适合用作跨业务平台之间的服务协议
用作HTTP或者HTTPS协议的接口定义
IDL文件适合跨语言平台的服务调用
XML配置适合企业内部之间的服务调用,且服务采用的是不同语言平台
RESTful API适合对外开放服务调用
选择服务描述方式根据实际情况决定
IDL文件
XML配置
RESTful API
总结
服务发布和引用
如何发布和引用服务

该思维导图由 AI 生成,仅供参考

从这期开始,我将陆续给你讲解微服务各个基本组件的原理和实现方式。
今天我要与你分享的第一个组件是服务发布和引用。我在前面说过,想要构建微服务,首先要解决的问题是,服务提供者如何发布一个服务,服务消费者如何引用这个服务。具体来说,就是这个服务的接口名是什么?调用这个服务需要传递哪些参数?接口的返回值是什么类型?以及一些其他接口描述信息。
我前面说过,最常见的服务发布和引用的方式有三种:
RESTful API
XML 配置
IDL 文件
下面我就结合具体的实例,逐个讲解每一种方式的具体使用方法以及各自的应用场景,以便你在选型时作参考。

RESTful API

首先来说说 RESTful API 的方式,主要被用作 HTTP 或者 HTTPS 协议的接口定义,即使在非微服务架构体系下,也被广泛采用。
下面是开源服务化框架Motan发布 RESTful API 的例子,它发布了三个 RESTful 格式的 API,接口声明如下:
@Path("/rest")
public interface RestfulService {
@GET
@Produces(MediaType.APPLICATION_JSON)
List<User> getUsers(@QueryParam("uid") int uid);
@GET
@Path("/primitive")
@Produces(MediaType.TEXT_PLAIN)
String testPrimitiveType();
@POST
@Consumes(MediaType.APPLICATION_FORM_URLENCODED)
@Produces(MediaType.APPLICATION_JSON)
Response add(@FormParam("id") int id, @FormParam("name") String name);
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文介绍了微服务架构中服务发布和引用的三种常见方式:RESTful API、XML配置和IDL文件。通过RESTful API方式发布服务,可以使用HTTP或HTTPS协议进行接口定义,适合跨业务平台之间的服务协议。XML配置方式通过服务提供者定义接口并实现,然后在服务提供者进程启动时加载server.xml配置文件将接口暴露出去,服务消费者进程启动时加载client.xml配置文件来引入要调用的接口。私有RPC框架通常选择XML配置方式来描述接口,对性能要求高的场景下比较合适,但对业务代码侵入性较高,且在跨部门业务调用时需要协调不同部门做升级工作。IDL文件通过一种中立的方式来描述接口,使得在不同的平台上运行的对象和不同语言编写的程序可以相互通信交流。文章通过具体的代码示例和应用场景分析,帮助读者快速了解了服务发布和引用的三种方式及其适用场景。总结来说,具体采用哪种服务描述方式是根据实际情况决定的,通常情况下,如果只是企业内部之间的服务调用,并且都是Java语言的话,选择XML配置方式是最简单的。如果企业内部存在多个服务,并且服务采用的是不同语言平台,建议使用IDL文件方式进行描述服务。如果还存在对外开放服务调用的情形的话,使用RESTful API方式则更加通用。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《从 0 开始学微服务》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(67)

  • 最新
  • 精选
  • heigh
    请教,idl走的七层还是四层协议?

    作者回复: idl跟通信协议无关,grpc用的是http2,可以理解是七层,thrift用的是tcp,四层

    2018-09-01
    7
  • bert
    微服务之间调用,使用xml配置。对外提供服务,如APP,H5,小程序等用Restful API.

    作者回复: 是的

    2018-09-13
    4
  • 搬砖匠
    我们的服务会提供给前端的外网和公司内部其他业务部门之间内网的调用,所以restful API是更合适的选择,另外我觉得restful方式也相对较轻量级简单,服务端与客户端的依赖程度较低,开发使用上来说效率很高。

    作者回复: 对,restful的优势就是开放耦合度低

    2018-09-02
    3
  • magic
    不知道http比rpc性能差多少,有比较数据吗?

    作者回复: 看业务实际场景,对于大部分业务可以忽略,但对于一些延迟敏感型,比如接口本身耗时只有ms级别的,建议还是用rpc

    2018-10-03
    1
  • 金hb.Ryan 冷空氣駕到
    有一个歧义,描述语言和通信协议没关系吧,只是http 协议不用再写stub所以省略了描述语言

    作者回复: 可以理解http的描述语言是文档

    2018-09-02
    1
  • 樊铮
    把每个服务的api注册到 consul中,使用swoole 做rpc 。

    作者回复: 也是一个思路

    2018-09-01
    1
  • WL
    protobuf如果只是增加字段的话,可以向前兼容

    作者回复: 对,只增加是向前兼容的

    2018-09-14
  • Violin
    我们现在的系统属于"伪微服务"类型的,内部用thrift,对外用restful

    作者回复: 也不算伪服务吧

    2018-09-13
  • Fxjeep
    能否略微提及一下.net下相应的工具和库?

    作者回复: 这个我不太了解啊,抱歉

    2018-09-05
    2
  • lgtao
    胡老师的语速稍快

    作者回复: 前几期录音还没习惯,后面逐步调整过来了,辛苦听录音了

    2018-09-03
收起评论
显示
设置
留言
67
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部