当前位置:首页 > 公众号精选 > 架构师社区
[导读]来自:后端技术学堂 本文是后端微服务架构系列的第二篇文章。在微服务设计中,服务间接口通信设计常见的有两种方式:RPC  和 REST,关于微服务和 RPC  的更多细节,可以参考我上一篇文章 面试都在问的微服务,一文带你彻底搞懂! 这篇文章主要介绍什么是 REST

面试造飞机系列:看架构师如何设计微服务接口

来自:后端技术学堂

本文是后端微服务架构系列的第二篇文章。在微服务设计中,服务间接口通信设计常见的有两种方式:RPC  和 REST,关于微服务和 RPC  的更多细节,可以参考我上一篇文章 面试都在问的微服务,一文带你彻底搞懂!

这篇文章主要介绍什么是 REST 风格设计以及 RESTful 接口。阅读完本文你将收获以下知识点:

  • 什么是 RESTRESTful
  • REST 接口设计规范是什么
  • REST 为什么要设计成无状态
  • 接口无状态真的是没有状态吗
  • RPCREST 适用场景

REST和RESTful

REST(Representational State Transfer,表述性状态转移) 是一种软件架构风格。REST提出了一组架构约束条件和原则,任何满足 REST 约束条件和原则的架构,都称为 RESTful 架构。

微服务之间需要相互通信以完成特定的业务处理,在典型的客户端-服务端设计模型中,客户端和服务端通通过消息请求-响应的方式交互协作,REST 就是这样一套微服务之间交互接口的设计约束和原则规范。

乍一看 REST「表述性状态转移」每个字都认得,连起来不知道什么意思。

这是作者 Roy Thomas Fielding 在他的博士论文里提出的概念,论文自然都是学术用语,不过感兴趣的同学可以去看看作者论文原文,地址我贴出来:https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

今天 lemon 用大白话帮你透彻理解这个概念,我们把「表述性状态转移」掰开来看,先搞明白什么是「表述性」,什么是「状态转移」。

表述性

「表述性」其实是缺少了主语的,主语是「资源」。完整的描述是「资源表述性」,也就是「资源的描述」。在网络通信中用什么描述资源呢?没错就是 URI(Uniform Resource Identifier,统一资源标识符)

这里有几个近义词先给大家先科普一下:

URI  是统一资源标识符,用来唯一的标识一个资源。

URL 是统一资源定位器,它是一种具体的 URI,即 URL 可以用来标识一个资源,而且还指明了如何定位这个资源,URLURI 的子集。

URN  统一资源命名,是通过名字来标识资源。URN也是 URI 的子集。面试造飞机系列:看架构师如何设计微服务接口

HTTP 协议中用 URL 标识资源,也就是浏览器地址栏你看到的那一串网址。

面试造飞机系列:看架构师如何设计微服务接口
地址栏URL

资源表述性

为了说明「资源描述性」接口设计的优点,我们来做一个接口设计方法的对比,举个栗子就清楚了。

传统的接口设计

先来看下传统的网络通信模式是怎么样的。假设lemon这个人物对象,在服务端的存储形式是一个c++class类型存储。

下面的过程展示,客户端发送请求服务端创建一个 lemon 对象的过程。

  1. 服务端定义存储结构头文件 lemon.h

     
class lemon{ string name; string address; uint64 phone;}
  1. 客户端代码引用服务端定义的lemon.h「互相引用头文件,增加了服务耦合性!」

  2. 客户端初始化一个 lemon 实例并序列化后通过网络接口发送给服务端。


     
class lemon lm;lm.name = "lemon";lm.address = "Shenzhen";lm.phone = 18666666666;
  1. 服务端接收消息,反序列化,存储传输过来的 lemon 对象
资源表述性接口设计

lemon 这个服务内部的对象,对外表现可以用一张图片来表示,也可以用包含lemon 的姓名、地址、电话等信息的 xmljson 格式的数据表示。

{name : "lemon",address: "ShenZhen",phone : 18666666666}
<?xml version="1.0" encoding="UTF-8" ?> <name>lemon</name> <address>ShenZhen</address> <phone>18666666666</phone>

也就是说,lemon 这个「资源」在服务内部的存放形式对外不可见,外界客户端发起请求可以用不同的资源表述格式来获取服务端的资源。

(如果服务器会说话,他内心os 大概是这样的:  客户端你不用管我是如何保存这个对象的,只要你说的清楚想要什么对象,只管发来请求便是!)。

面试造飞机系列:看架构师如何设计微服务接口

这样做最显然的好处是,减少了服务之间的耦合。客户端访问服务资源之前不需要知道资源在服务端的具体存储格式,只需描述资源形式即可修改、创建、更新、删除服务端的资源。

状态转移

搞懂了「资源描述性」接下来看下什么是「状态转移」?状态转移就是客户端通过一系列请求动作,推动服务端的资源状态发生变化,资源的状态可以在「创建-修改-查看-删除」之间转移。

面试造飞机系列:看架构师如何设计微服务接口
资源状态转移

资源状态的变化在宏观上的反应就是业务流程推进。打个比方,你去银行系统开户、查余额、销户,这个过程你推动了你的银行账户这个「资源」经历了不同的状态转移让你完成了不同的业务操作。

REST的约束条件

协议选择

REST 本身并没有提到底层应该使用什么协议,日常实践案例中最常用的是基于 HTTPRESTful 实现。

这是因为 HTTP 协议自带的动词 GET/POST/PUT/DELETE 可以作为推动状态转移的方法,另外HTTP 的制定了规范的状态码。还有其他的一些 HTTP 特性,这些特性使得在HTTP 之上实现 REST 要简单得多,而如果使用其他协议的话,就需要自己实现这些特性。

请求规范

RESTful 架构中,发生状态转换的是「资源」,所以URI 中一般只能包含代表「资源」的名词,并且推荐是复数,而不应该在 URI 中包对资源进行操作的动词。

对资源执行的CURD「增删改查」动作应该在HTTP请求方法的GET/POST/PUT/DELETE中体现。

符合REST规范的写法:

POST http://www.test.com/lemon // 创建Get http://www.test.com/lemon // 查询PUT http://www.test.com/lemon // 修改DELETE http://www.test.com/lemon //删除

不符合REST规范的写法:

POST http://www.test.com/Createlemon // 创建POST http://www.test.com/Querylemon // 查询POST http://www.test.com/Modifylemon // 修改POST http://www.test.com/Deletelemon //删除

状态码

服务端消息响应携带状态码,指示客户端进行下一步处理。符合 RESTful 规范的接口返回状态码都是通用的,不需要额外约定,利用HTTP Status Code 状态码 表示请求处理结果,降低了微服务间互操作成本。

状态码 状态码含义
2xx 成功,操作被成功接收并处理
3xx 重定向,需要进一步的操作以完成请求
4xx 客户端错误,请求包含语法错误或无法完成请求
5xx 服务器错误,服务器在处理请求的过程中发生了错误

下面是常见的HTTP状态码:

  • 200 - 请求成功
  • 301 - 资源(网页等)被永久转移到其它URL
  • 404 - 请求的资源(网页等)不存在
  • 500 - 内部服务器错误

无状态

RESTful接口要求是「无状态」。无状态指的是任意一个Web请求必须完全与其他请求隔离,当客户端发起请求时,消息本身包含了服务端识别这一请求上下文所需的全部信息。

无状态不是真的没有状态

接口「无状态」更确切的说是服务端无状态,整个会话还是需要状态维持的。要完成一个业务流程,一般客户端与服务端需要多次的消息交互,我们知道HTTP 协议是「无状态协议」,这就需要服务端能够识别几个独立 HTTP 请求的「状态信息」,从而将他们关联到一个业务流程中。

还是举例子银行系统取款的例子:

  • 用户lemon要登录银行系统,首先需要在登录页面输入用户名和密码,这时候产生一个登录请求
  • 服务端收到登录请求,执行登录逻辑并返回操作结果
  • lemon登录之后点击取款100万,产生一个取款请求
  • 服务端收到取款请求,执行取款逻辑并返回操作结果
面试造飞机系列:看架构师如何设计微服务接口
取款业务流程

这里有个问题,服务端在不同时间点收到登录请求和取款请求,这两个请求都是用户 lemon 产生的,如果不在技术层面做对独立的 HTTP 请求做关联的话,服务端就无法知道这两个请求其实是都是用户lemon 「取款业务」的组成部分。

技术方案

服务端要能识别请求的「状态信息」,有两种技术方案:

  1. Session 方式。服务端保存会话状态,客户端每次请求携带session-id

    服务端维护一个会话状态信息列表,用session-id唯一标识一个状态信息,session-id一般包含在HTTP响应的Set-Cookie头部返回给客户端,后续客户端请求携带包含session-id信息的cookie头部,服务端解析cookie取出session-id,去维护的状态列表中取回该消息对应的状态信息,这样就把无状态的HTTP变成有状态的了。

面试造飞机系列:看架构师如何设计微服务接口
session会话

  1. Token 方式。服务端不保存会话状态,客户端每次请求都携带完整的会话状态信息(一般是加密的)给服务端。

    Token也称作是「令牌」或临时证书签名,状态信息都被加密到token中,这样每当服务器收到请求后解密token就能获取该请求对应的状态信息,也就能把不同的请求消息关联到同一个业务流程中来,和session方式有类似的效果,只不过这次的状态信息不保存在服务端。

面试造飞机系列:看架构师如何设计微服务接口
Token会话

以上两种实现中,第一种 Session 方式是有状态的,第二种 Token 方式是无状态的。

如果你要实现 RESTful 接口最好按第二种技术方案实现,当然要实现无状态也还有其他方式,思路都是「服务端不保持会话状态」就对了。

为什么要无状态

为了高可用性和负载均衡需求,多个微服务通过负载均衡实现分布式集群化部署,集群中每个服务都是独立和对等的。如果服务器在收到客户端请求之时不可用或者宕机,无状态请求可以由任何其他可用服务器处理并作出应答,这在分布式应用中非常重要。

面试造飞机系列:看架构师如何设计微服务接口
REST无状态接口

想象一下如果服务端保存状态,一个事务内的每个请求都必须落到同一台服务器去处理,这就失去了分布式的意义和优势。

所以, RESTful 接口要求是无状态的,是为了更好的适应分布式业务场景,发挥微服务集群优势。

REST 和 RPC

这两个概念经常出现在微服务架构设计中,REST 是一种软件架构接口设计风格,RPC 是一种计算机通信协议,看起来是两个不同的概念,没法比较。

但是有些书中把它们放在一起比较,真要比较的话,我个人倾向于把 REST 具体化为一种基于HTTP 并按照 REST 约束设计的通信协议,这样两个通信协议才有比较性。

回顾下RPC

RPC (Remote Procedure Call)远程过程调用是一个计算机通信协议。我们一般的程序调用是本地程序内部的调用,RPC允许你像调用本地函数一样去调用另一个程序的函数,这中间会涉及网络通信和进程间通信,但你无需知道实现细节,RPC框架为你屏蔽了底层实现。

RPC 是一种服务器-客户端Client/Server模式,经典实现是一个通过发送请求-接受回应进行信息交互的系统。

适用场景

很多 RPC 框架提供的消息传输都是基于二进制的,比如ThriftProtocol buffers。这样做的好处是消息结构比较紧凑,对于频繁调用或者大流量、低时延要求的应用场景,能够显著减少网络开销;另一个约束是某些 RPC 框架有很强的技术耦合性,比如 Dubbo 只能用于 java 技术栈。综上,RPC 「更加适用于系统内部微服务之间的高效通信」

RESTful接口由于提供了统一的基于 HTTPREST 设计标准,只需 web 框架支持 HTTP 协议,并设计RESTful 风格的接口即可,极大的方便了第三方服务接入调用,「适合用于微服务系统对外暴露的接口设计标准」

写在最后

本文是微服务架构设计中接口选型的一个小方面,很多人会觉得现在工作面试,不管是大厂还是小公司,都是面试造飞机,工作拧螺丝。个人认为即使你在入职之后接触不到架构方面的工作,也要有一颗架构的心,高度决定认知,如果只盯着手上的那颗螺丝那和咸鱼有什么区别?

老规矩。感谢各位的阅读,文章的目的是分享对知识的理解,技术类文章我都会反复求证以求最大程度保证准确性,若文中出现明显纰漏也欢迎指出,我们一起在探讨中学习。

今天的技术分享就到这里,本文是后端开发微服务设计系列的第二篇,这个系列应该还会继续更新,我想到了再写,我们下期再见。

特别推荐一个分享架构+算法的优质内容,还没关注的小伙伴,可以长按关注一下:

面试造飞机系列:看架构师如何设计微服务接口

长按订阅更多精彩▼

面试造飞机系列:看架构师如何设计微服务接口

如有收获,点个在看,诚挚感谢

免责声明:本文内容由21ic获得授权后发布,版权归原作者所有,本平台仅提供信息存储服务。文章仅代表作者个人观点,不代表本平台立场,如有问题,请联系我们,谢谢!

本站声明: 本文章由作者或相关机构授权发布,目的在于传递更多信息,并不代表本站赞同其观点,本站亦不保证或承诺内容真实性等。需要转载请联系该专栏作者,如若文章内容侵犯您的权益,请及时联系本站删除。
换一批
延伸阅读

9月2日消息,不造车的华为或将催生出更大的独角兽公司,随着阿维塔和赛力斯的入局,华为引望愈发显得引人瞩目。

关键字: 阿维塔 塞力斯 华为

加利福尼亚州圣克拉拉县2024年8月30日 /美通社/ -- 数字化转型技术解决方案公司Trianz今天宣布,该公司与Amazon Web Services (AWS)签订了...

关键字: AWS AN BSP 数字化

伦敦2024年8月29日 /美通社/ -- 英国汽车技术公司SODA.Auto推出其旗舰产品SODA V,这是全球首款涵盖汽车工程师从创意到认证的所有需求的工具,可用于创建软件定义汽车。 SODA V工具的开发耗时1.5...

关键字: 汽车 人工智能 智能驱动 BSP

北京2024年8月28日 /美通社/ -- 越来越多用户希望企业业务能7×24不间断运行,同时企业却面临越来越多业务中断的风险,如企业系统复杂性的增加,频繁的功能更新和发布等。如何确保业务连续性,提升韧性,成...

关键字: 亚马逊 解密 控制平面 BSP

8月30日消息,据媒体报道,腾讯和网易近期正在缩减他们对日本游戏市场的投资。

关键字: 腾讯 编码器 CPU

8月28日消息,今天上午,2024中国国际大数据产业博览会开幕式在贵阳举行,华为董事、质量流程IT总裁陶景文发表了演讲。

关键字: 华为 12nm EDA 半导体

8月28日消息,在2024中国国际大数据产业博览会上,华为常务董事、华为云CEO张平安发表演讲称,数字世界的话语权最终是由生态的繁荣决定的。

关键字: 华为 12nm 手机 卫星通信

要点: 有效应对环境变化,经营业绩稳中有升 落实提质增效举措,毛利润率延续升势 战略布局成效显著,战新业务引领增长 以科技创新为引领,提升企业核心竞争力 坚持高质量发展策略,塑强核心竞争优势...

关键字: 通信 BSP 电信运营商 数字经济

北京2024年8月27日 /美通社/ -- 8月21日,由中央广播电视总台与中国电影电视技术学会联合牵头组建的NVI技术创新联盟在BIRTV2024超高清全产业链发展研讨会上宣布正式成立。 活动现场 NVI技术创新联...

关键字: VI 传输协议 音频 BSP

北京2024年8月27日 /美通社/ -- 在8月23日举办的2024年长三角生态绿色一体化发展示范区联合招商会上,软通动力信息技术(集团)股份有限公司(以下简称"软通动力")与长三角投资(上海)有限...

关键字: BSP 信息技术
关闭
关闭