微服务架构组件分析,看这篇就够了微服务架构组件分析,看这篇就够了
1. 如何发布和引用服务
服务描述:服务调用首先解决的问题就是服务如何对外描述。 常用的服务描述方式包括 RESTful API、XML 配置以及 IDL 文
件三种。
RESTful API
主要被用作 HTTP 或者 HTTPS 协议的接口定义,即使在非微服务架构体系下,也被广泛采用
优势:
HTTP 协议本身是一个公开的协议,对于服务消费者来说几乎没有学习成本,所以比较适合用作跨业务平台之间的服务协议。
劣势: -性能相对比较低
XML 配置
一般是私有 RPC 框架会选择 XML 配置这种方式来描述接口,因为私有 RPC 协议的性能比 HTTP 协议高,所以在对性能要求
比较高的场景下,采用 XML 配置比较合适。这种方式的服务发布和引用主要分三个步骤:
服务提供者定义接口,并实现接口
服务提供者进程启动时,通过加载 server.xml 配置文件将接口暴露出去。
服务消费者进程启动时,通过加载 client.xml 配置文件引入要调用的接口。
优势:
私有 RPC 协议的性能比 HTTP 协议高,所以在对性能要求比较高的场景下,采用 XML 配置方式比较合适 劣势:
对业务代码侵入性比较高
XML 配置有变更的时候,服务消费者和服务提供者都要更新(建议:公司内部联系比较紧密的业务之间采用)
IDL 文件
IDL 就是接口描述语言(interface description language)的缩写,通过一种中立的方式来描接口,使得在不同的平台上运行
的对象和不同语言编写的程序可以相互通信交流。常用的 IDL:一个是 Facebook 开源的 Thrift 协议,另一个是 Google 开源
的 gRPC 协议。无论是 Thrift 协议还是 gRPC 协议,他们的工作原来都是类似的。
优势:
用作跨语言平台的服务之间的调用
劣势:
在描述接口定义时,IDL 文件需要对接口返回值进行详细定义。如果接口返回值的字段比较多,并且经常变化时,采用 IDL 文
件方式的接口定义就不太合适了。
一方面会造成 IDL 文件过大难以维护
另一方面只要 IDL 文件中定义的接口返回值有变更,都需要同步所有的服务消费者都更新,管理成本太高了。
总结
具体采用哪种服务描述方式是根据实际情况决定,通常情况下, 如果只是企业内部之间的服务调用,并且都是 Java 语言的
话,选择 XML 配置方式是最简单的。如果企业内部存在多个服务,并且服务采用的是不同语言平台,建议使用 IDL 文件方式
进行描述服务。如果还存在对外开放服务调用的情形的话,使用 RESTful API 方式则更加通用。
评论0