架构杂谈《九》

架构杂谈《九》

微服务与轻量级通讯机制

　　微服务架构是一种架构模式，它提倡将单一应用程序划分红一组小的服务，服务之间胡亮协调、互相配合，为用户提供最终价值。在微服务架构中，服务与服务之间通讯时，一般是经过轻量级的通讯机制，实现彼此间的互通互联、互相协做。所谓轻量级通讯机制，一般是指与语言无关、与平台无关的这类协议。经过轻量级通讯机制，使服务与服务之间的协做变得简单、标准化。

一、同步通讯与异步通讯

　　1.1概述

　　微服务架构是一种架构模式，它提倡将单一应用程序划分红一组小的服务。所以，微服务架构本质上分布式系统。

　　相比传统的单机系统，因为服务和数据分布在不一样的节点上，每次交互都须要跨节点与运行，这使得网络成为微服务架构实施考虑的必要因素之一。

　　1.2 同步通讯与异步通讯的选择

　　　　同步通讯是指当客户端发出请求后，在服务端处理未结束前，客户端一直处于等待状态，直到最终得到服务端的响应。

　　　　异步通讯则是指当客户端发出请求后，服务端或者第三方组件会先接受消息并应答，而后在合适的时间对请求进行处理。在这中间。客户端不须要一直处于等待状态。

二、远程调用RPC

　　RPC（Remote Procedure Call）又称远程过程调用。是一种典型的分布式节点间同步通讯的实现方式。远程过程调用采用客户端/服务端的模式，请求的发起者是客户端，提供响应的是服务器端。

　　百度百科

　　客户端经过客户代理存根（Stub），传递函数参数，向服务器端发起函数调用。服务器端经过服务器代理存根（Skeleton），接受到客户端的请求后，对请求进行处理。并在结束后向客户端返回响应，从而完成一次通讯。

　　2.1远程过程调用的核心

　　　　远程过程调用采用客户端/服务器端模式。请求的发起者是客户端，提供响应的是服务器端。客户端与服务器端的交互模式图以下：

　　　　　一、首先，客户端调用本地代理存根，发送请求到服务器端，等待应答信息

　　　　　二、在服务器端，服务代理处于睡眠状态，直到客户端请求到达并将其唤醒

　　　　    三、服务代理得到请求参数后，交由服务器的服务代码对其进行处理

　　　　　四、应用程序处理结束后，由服务代理向客户端发送应答，等待下一次请求

　　　　　五、客户端代理存根接收应答信息，交给客户端的调用代码进行处理。

　　2.2远程方法调用

　　　　传统的远程过程调用框架主要包括 Sun RPC、DCE/RPC，主要基于C语言实现，以函数调用为主。

　　　　随着面向对象语言的快速发展，序列化/反序列化等特性的诞生。基于不一样语言的远程过程调用框架开始提供对象远程访问的功能，如 Thrift、protocol buffers等，同传统的远程过程调用框架相比，有一类框架可以容许客户端经过面向对象的调用方式，调用远端的实现。咱们称这类调用为远程方法调用，换句话说 远程方法调用是远程过程调用的一种面向对象的实现。

　　2.3 RPC的弊端

　　　　　　RPC 经过 使用代理存根（Stub/Skeleton）的方式，屏蔽了通讯双发底层的调用细节，让客户端没必要显式地区分当前代码级别的方法调用是本地调用仍是远程调用。所以使分布式节点间的通讯变得简单。可是，虽然RPC 的调用机制屏蔽了调用的细节，简化了调用流程。但其也存在着弊端。

　　　　　　1：耦合度高

　　　　　　2：灵活性差

三、REST

　　3.1 REST 概述

　　　　REST（Representation State Transfer）（表述性状态传递）是这几年使用较普遍的分布式节点间通讯的实现方式，REST 从语义层面将响应结果定义为资源，并使用HTTP的标准动词映射为对资源的操做，造成了一种以资源为核心、以HTTP为操做方式的，与语言无关、平台无关的服务间通讯机制。

　　　　百度百科

　　3.2 REST的核心

　　

　　　　资源：（Resource）是一种抽象的概念，是指对某类信息实体的抽象。实体是指服务器端须要处理的具体信息，它能够是一段文本、一种图片也能够是文件系统中的一个文件、数据库中的一张表等。与面向对象设计中的概念相似，资源一般以名词为核心来定义，每一个资源对应一个特色的URI做为标识。

　　　　表述：（Representation）资源的表述是对资源在某个特定时刻的状态的描述。资源是一种信息实体，实体在客户端与服务器端进行信息交换时，能够有多种表现形式，如：文本能够用TXT格式表现，也能够用HTML格式、XML格式、JSON格式表现，甚至能够采用二进制格式；图片能够用JPG格式标识也能够用PNG格式表现。这种资源的表述格式在客户端与服务器端经过请求-响应的协商机制来肯定。实际上，URI 仅表明资源的实体，并不表明它的表述。如：有些URL最后的.html 后缀名并属于表述范畴，表述应该在HTTP请求的头信息中用 Accept和Content-Type 字段来指定。这两个字段才是对“表述”的描述。

　　　　状态转移：（State Transfer）是指在客户端同服务端交互的过程当中。客户端可以经过资源的表述，实现操做资源的目的。当咱们使用浏览器访问一个网站时，就表明了客户端和服务器端的一个交互过程。在这个过程当中，必然会涉及数据或者状态的变化。可是咱们知道HTTP是一个无状态的协议。这意味着，全部的状态都保存在服务器端。所以，若是客户端想要操做资源，必须经过某种手段，让服务器端发生状态的转移。而这种转移是创建在资源的表述上的。因此一般将其称为表述层状态转移。

　　　　统一接口：（Uniform Interface）客户端操做资源的方式，一般是基于HTTP的4个动词（Verb）：GET、POST、PUT、DELETE。它们分别对应4种资源的操做方式。

　　　　　　GET：用来获取资源

　　　　　　POST：用来新建资源

　　　　　　PUT：用来更新资源

　　　　　　DELETE：用来销毁资源

　　　　由于客户端是经过HTTP的这4个动词操做资源的。也就意味着无论请求的URI是什么，请求的资源有什么不一样，但操做资源的接口都是统一的。

　　3.3 REST的优点

　　　　经过资源表述、状态转移以及统一接口，REST 将客户端的请求、服务器端的响应基于资源联系起来，逐渐造成了一种以资源为核心、以HTTP为操做方式的、与语言无关、平台无关的通讯机制。同时，因为HTTP自己的无状态性，使用REST，可以有效保持服务/应用的无状态性，利于未来的水平伸缩。

　　3.4 REST的不足

　　　　随着团队或者组织业务的不断增加，服务器端响应内容复杂度的增长，REST的使用面临以下的挑战：

　　　　　　1：如何标准化资源结构

　　　　　　2：如何处理资源的相关连接

　　　　3.4.1 如何标准化资源结构

　　　　　　使用REST能够将业务场景的具体信息定义为资源。并基于JSON或者XML返回给客户端，随着业务的不断增加，逻辑的增长，服务器端对内容的响应结构会变得愈来愈复杂（所谓响应结构，是指服务器端的响应内容结构，既资源的结构）

　　　　　　REST做为指导性的原则，并无定义服务器端响应结构应该遵循什么标准。这也就意味着在企业内部、不一样的部门、不一样的开发小组，对同一类资源所定义的结构可能不一样，所以如何定义一套标准的资源响应结构，成为服务数量增多后使用的REST面临的一个挑战。

　　　　3.4.2 如何有效处理相关资源的连接

　　　　　　大部分REST的实现，都是基于 JSON 做为传输格式，但 JSON最大的遗憾在于没有对超连接处理作内置的支持，而这部分却偏偏是 Web 的基石，这带来的潜在问题是，对于调用接口的客户端而言，每次须要查看相关的接口文档，才能了解如何修改资源的状态，或者获取相关联资源的信息。所以，如何用有效的方式管理REST中相关资源的依赖以及连接，是否可以将这种方式标准化，成为服务数量增多后使用REST面临的另外一个挑战。

　　　　3.4.3 其余须要考虑的因素

　　　　　　性能：

　　　　　　　　因为REST 是基于 HTTP 之上的协议，而HTTP自己是一个使用普遍的、基于TCP/IP的应用层协议，所以 REST 并非低延时通讯的最好选择。对于服务之间对低延时要求的场景，可能须要选择不一样的底层协议，如UDP 来达到但愿的性能，或者其余RPC框架

　　　　　　开发成本：

　　　　　　　　使用REST，其传输格式是XML或者JSON的文本格式，在享受平台无关、语言无关优点的同时，团队须要编写更多的代码来解析文本格式的协议，不过目前已经有不少成熟的库帮助咱们来作相似的事情，如 Java下解决 JSON的 JSON-lib、org.json 以及 C# 下的 Newtonsoft.Json

说明：

　　一、参考书籍：《分布式服务架构：原理、设计与实战》《微服务架构与实践》

　　二、若有不合适的地方请反馈。综合后更改。

 

原文出处：https://www.cnblogs.com/haoxiaozhang/p/11304021.html