微服务架构组件分析，看这篇就够了
47 浏览量
2021-02-24
22:56:12
上传
评论
收藏 2.14MB PDF 举报
微服务架构组件分析，看这篇就够了微服务架构组件分析，看这篇就够了
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 方式则更加通用。
剩余14页未读，继续阅读
资源评论
