URL:为什么可作为统一模型?
共 2029字,需浏览 5分钟
·
2021-04-07 19:00
相信你对于 URL 并不陌生,特别是对于做 Web 开发的同学,几乎每天都在与 URL 打交道。但是,真的了解 URL 是什么吗?
URL 是统一资源定位符(Uniform Resource Locator - RFC1738,简称 URL)。在 Web 的层面上,用于定位某一个给定的独特资源的地址。该资源可以是一个 HTML 页面、多媒体资源、JS 文件等。
到这里,你可能会有另外一个疑问:URL 是怎么组成的呢?
http://www.joezou.com:80/about/me.html?userName=lucy&id=1#project
http: 协议,表示请求的通讯协议,在 web 请求上通常是 HTTP、HTTPS 等,也可以是自定义协议。
www.joezou.com: 域名,表示请求哪个服务器,当然,也可以是一个 IP。
80: 端口,表示访问请求服务器监听的哪个接口。如通过 HTTP 或者 HTTPS 访问,通常会默认被忽略。
/about/me.html: 路径,表示访问服务器上资源的路径,本例中是一个文件路径,也可以是一个接口路径。
?userName=lucy&id=1: 参数,提供给网络服务器的额外参数。这些参数是用 & 符号分隔的键/值对列表。
#project: 锚点,资源本身的另一部分的锚点。锚点表示资源中的一种“书签”,给浏览器显示位于该“加书签”位置的内容的方向。
相信你对 URL 已经有一些基础了解。不管 Dubbo 与 Dubbo-go 都是使用 URL 存储数据。但是为什么使用 URL 进行统一的数据存储模型?接下来马上揭晓。
为什么使用 URL
在平时用于存储数据的数据结构中,List、Map、Set 为比较常见的数据结构。URL 虽然是一个通用的数据结构,常常被大家而忽略,但为什么 Dubbo 选择其作为数据存储的数据结构呢?
回到设计之初重新思考这个问题,Dubbo 作为一个高性能的 RPC 框架,其需要使用的数据需要包含以下信息。
通讯协议
主机/端口
接口名称
参数键值对
到这里,是不是觉得和开篇提到 URL 很像。所以,选择了 URL 作为数据存储的数据结构。那用了该数据结构之后,有什么利弊呢?
URL 的利弊
URL 除了作为存储数据的数据结构以外,还在程序中充当显式传递上下文信息的模型。如果没有确定统一的数据结构,只能通过传递字符串、不停拼装不一样的结构体。导致接口的参数列表在扩展时经常变更:
Register(host string,port int,path string) error
UnRegister(host string,port int,path string) error
如果确定以 URL 为传递上下文信息的模型:
Register(url *common.URL) error
UnRegister(url *common.URL) error
所以在 Dubbo-go 的各个接口中充斥着大量这种 URL 的参数。在此之上,利也是显而易见:
模型统一:从接口的参数到数据存储使用统一的数据结构。可简化概念,代码易读性提高,也可以形成统一的代码编写规范。
可扩展性:具有十分强的可扩展性。只要根据 URL 规范即可方便对数据结构进行扩展,不需要修改接口参数。
多语言兼容性高:编程语言上基本上都存在可对 URL 字符串进行反序列化的方法,可以开箱即用。
正所谓,有利必有弊。URL 最大的缺点就是维护成本高。因为扩展太容易,如果在缺乏统一结构化的描述文档,特别在多语言情况下,在新增或者删除参数之后,不容易被发现。然而,维护统一的描述文档,则会导致维护成本增加。
推荐阅读:
点个“在看”和“赞”吧,
毕竟我是要成为前端网红的人。