手机网站可以做动态吗,培训网络营销的机构,北京燕华工程建设有限公司网站,怎么注册网络域名来源 | 后端技术学堂责编 | Carol封图| CSDN下载于视觉中国 在微服务设计中#xff0c;服务间接口通信设计常见的有两种方式#xff1a;RPC 和 REST#xff0c;关于微服务和 RPC 的更多细节#xff0c;可以参考我上一篇文章 面试都在问的微服务#xff0c;一文带你彻底搞… 来源 | 后端技术学堂责编 | Carol封图| CSDN下载于视觉中国 在微服务设计中服务间接口通信设计常见的有两种方式RPC 和 REST关于微服务和 RPC 的更多细节可以参考我上一篇文章 面试都在问的微服务一文带你彻底搞懂这篇文章主要介绍什么是 REST 风格设计以及 RESTful 接口。阅读完本文你将收获以下知识点什么是 REST 和 RESTfulREST 接口设计规范是什么REST 为什么要设计成无状态接口无状态真的是没有状态吗RPC 和 REST 适用场景REST 和 RESTfulRESTRepresentational State Transfer表述性状态转移 是一种软件架构风格。REST提出了一组架构约束条件和原则任何满足 REST 约束条件和原则的架构都称为 RESTful 架构。微服务之间需要相互通信以完成特定的业务处理在典型的客户端-服务端设计模型中客户端和服务端通通过消息请求-响应的方式交互协作REST 就是这样一套微服务之间交互接口的设计约束和原则规范。乍一看 REST「表述性状态转移」每个字都认得连起来不知道什么意思。这是作者 Roy Thomas Fielding 在他的博士论文里提出的概念论文自然都是学术用语不过感兴趣的同学可以去看看作者论文原文地址我贴出来https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm今天 lemon 用大白话帮你透彻理解这个概念我们把「表述性状态转移」掰开来看先搞明白什么是「表述性」什么是「状态转移」。表述性「表述性」其实是缺少了主语的主语是「资源」。完整的描述是「资源表述性」也就是「资源的描述」。在网络通信中用什么描述资源呢没错就是 URIUniform Resource Identifier统一资源标识符。这里有几个近义词先给大家先科普一下URI 是统一资源标识符用来唯一的标识一个资源。URL 是统一资源定位器它是一种具体的 URI即 URL 可以用来标识一个资源而且还指明了如何定位这个资源URL 是 URI 的子集。URN 统一资源命名是通过名字来标识资源。URN也是 URI 的子集。在 HTTP 协议中用 URL 标识资源也就是浏览器地址栏你看到的那一串网址。地址栏URL资源表述性为了说明「资源描述性」接口设计的优点我们来做一个接口设计方法的对比举个栗子就清楚了。传统的接口设计先来看下传统的网络通信模式是怎么样的。假设lemon这个人物对象在服务端的存储形式是一个c的class类型存储。下面的过程展示客户端发送请求服务端创建一个 lemon 对象的过程。服务端定义存储结构头文件 lemon.hclass lemon{ string name; string address; uint64 phone;}
客户端代码引用服务端定义的lemon.h「互相引用头文件增加了服务耦合性」客户端初始化一个 lemon 实例并序列化后通过网络接口发送给服务端。class lemon lm;lm.name lemon;lm.address Shenzhen;lm.phone 18666666666;
服务端接收消息反序列化存储传输过来的 lemon 对象资源表述性接口设计lemon 这个服务内部的对象对外表现可以用一张图片来表示也可以用包含lemon 的姓名、地址、电话等信息的 xml 或 json 格式的数据表示。{name : lemon,address: ShenZhen,phone : 18666666666}
?xml version1.0 encodingUTF-8 ? namelemon/name addressShenZhen/address phone18666666666/phone
也就是说lemon 这个「资源」在服务内部的存放形式对外不可见外界客户端发起请求可以用不同的资源表述格式来获取服务端的资源。如果服务器会说话他内心os 大概是这样的: 客户端你不用管我是如何保存这个对象的只要你说的清楚想要什么对象只管发来请求便是。这样做最显然的好处是减少了服务之间的耦合。客户端访问服务资源之前不需要知道资源在服务端的具体存储格式只需描述资源形式即可修改、创建、更新、删除服务端的资源。状态转移搞懂了「资源描述性」接下来看下什么是「状态转移」状态转移就是客户端通过一系列请求动作推动服务端的资源状态发生变化资源的状态可以在「创建-修改-查看-删除」之间转移。资源状态转移资源状态的变化在宏观上的反应就是业务流程推进。打个比方你去银行系统开户、查余额、销户这个过程你推动了你的银行账户这个「资源」经历了不同的状态转移让你完成了不同的业务操作。REST的约束条件协议选择REST 本身并没有提到底层应该使用什么协议日常实践案例中最常用的是基于 HTTP 的 RESTful 实现。这是因为 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 状态码 表示请求处理结果降低了微服务间互操作成本。下面是常见的HTTP状态码200 - 请求成功301 - 资源网页等被永久转移到其它URL404 - 请求的资源网页等不存在500 - 内部服务器错误无状态RESTful接口要求是「无状态」。无状态指的是任意一个Web请求必须完全与其他请求隔离当客户端发起请求时消息本身包含了服务端识别这一请求上下文所需的全部信息。无状态不是真的没有状态接口「无状态」更确切的说是服务端无状态整个会话还是需要状态维持的。要完成一个业务流程一般客户端与服务端需要多次的消息交互我们知道HTTP 协议是「无状态协议」这就需要服务端能够识别几个独立 HTTP 请求的「状态信息」从而将他们关联到一个业务流程中。还是举例子银行系统取款的例子用户lemon要登录银行系统首先需要在登录页面输入用户名和密码这时候产生一个登录请求服务端收到登录请求执行登录逻辑并返回操作结果lemon登录之后点击取款100万产生一个取款请求服务端收到取款请求执行取款逻辑并返回操作结果取款业务流程这里有个问题服务端在不同时间点收到登录请求和取款请求这两个请求都是用户 lemon 产生的如果不在技术层面做对独立的 HTTP 请求做关联的话服务端就无法知道这两个请求其实是都是用户lemon 「取款业务」的组成部分。技术方案服务端要能识别请求的「状态信息」有两种技术方案Session 方式。服务端保存会话状态客户端每次请求携带session-id。服务端维护一个会话状态信息列表用session-id唯一标识一个状态信息session-id一般包含在HTTP响应的Set-Cookie头部返回给客户端后续客户端请求携带包含session-id信息的cookie头部服务端解析cookie取出session-id去维护的状态列表中取回该消息对应的状态信息这样就把无状态的HTTP变成有状态的了。session会话Token 方式。服务端不保存会话状态客户端每次请求都携带完整的会话状态信息一般是加密的给服务端。Token也称作是「令牌」或临时证书签名状态信息都被加密到token中这样每当服务器收到请求后解密token就能获取该请求对应的状态信息也就能把不同的请求消息关联到同一个业务流程中来和session方式有类似的效果只不过这次的状态信息不保存在服务端。Token会话以上两种实现中第一种 Session 方式是有状态的第二种 Token 方式是无状态的。如果你要实现 RESTful 接口最好按第二种技术方案实现当然要实现无状态也还有其他方式思路都是「服务端不保持会话状态」就对了。为什么要无状态为了高可用性和负载均衡需求多个微服务通过负载均衡实现分布式集群化部署集群中每个服务都是独立和对等的。如果服务器在收到客户端请求之时不可用或者宕机无状态请求可以由任何其他可用服务器处理并作出应答这在分布式应用中非常重要。REST无状态接口想象一下如果服务端保存状态一个事务内的每个请求都必须落到同一台服务器去处理这就失去了分布式的意义和优势。所以 RESTful 接口要求是无状态的是为了更好的适应分布式业务场景发挥微服务集群优势。REST 和 RPC这两个概念经常出现在微服务架构设计中REST 是一种软件架构接口设计风格RPC 是一种计算机通信协议看起来是两个不同的概念没法比较。但是有些书中把它们放在一起比较真要比较的话我个人倾向于把 REST 具体化为一种基于HTTP 并按照 REST 约束设计的通信协议这样两个通信协议才有比较性。回顾下RPCRPC (Remote Procedure Call)远程过程调用是一个计算机通信协议。我们一般的程序调用是本地程序内部的调用RPC允许你像调用本地函数一样去调用另一个程序的函数这中间会涉及网络通信和进程间通信但你无需知道实现细节RPC框架为你屏蔽了底层实现。RPC 是一种服务器-客户端Client/Server模式经典实现是一个通过发送请求-接受回应进行信息交互的系统。适用场景很多 RPC 框架提供的消息传输都是基于二进制的比如Thrift、Protocol buffers。这样做的好处是消息结构比较紧凑对于频繁调用或者大流量、低时延要求的应用场景能够显著减少网络开销另一个约束是某些 RPC 框架有很强的技术耦合性比如 Dubbo 只能用于 java 技术栈。综上RPC 「更加适用于系统内部微服务之间的高效通信」RESTful接口由于提供了统一的基于 HTTP的 REST 设计标准只需 web 框架支持 HTTP 协议并设计RESTful 风格的接口即可极大的方便了第三方服务接入调用「适合用于微服务系统对外暴露的接口设计标准」写在最后本文是微服务架构设计中接口选型的一个小方面很多人会觉得现在工作面试不管是大厂还是小公司都是面试造飞机工作拧螺丝。个人认为即使你在入职之后接触不到架构方面的工作也要有一颗架构的心高度决定认知如果只盯着手上的那颗螺丝那和咸鱼有什么区别老规矩。感谢各位的阅读文章的目的是分享对知识的理解技术类文章我都会反复求证以求最大程度保证准确性若文中出现明显纰漏也欢迎指出我们一起在探讨中学习。同时欢迎所有开发者扫描下方二维码填写《开发者与AI大调研》只需2分钟便可收获价值299元的「AI开发者万人大会」在线直播门票!推荐阅读你知道吗其实 Oracle 直方图自动统计算法存在这些缺陷附验证步骤
你公司的虚拟机还闲着基于 Jenkins 和 Kubernetes 的持续集成测试实践了解一下一站式杀手级 AI 开发平台来袭告别切换零散建模工具那些神一样的程序员
比特币当赎金WannaRen 勒索病毒二度来袭通过 Python 代码实现时间序列数据的统计学预测模型
真香朕在看了
