系统间通信知识点总结

1.信息格式

常用的信息格式包括：

• XML： 
  可扩展标记语言，这个语言由W3C（万维网联盟）进行发布和维护。XML语言应用之广泛，扩展之丰富。适合做网络通信的信息描述格式（一般是“应用层”协议了）。例如Google 定义的XMPP通信协议就是使用XML进行描述的；不过XML的更广泛使用场景是对系统环境进行描述（因为它会造成较多的不必要的内容传输），例如服务器的配置描述、Spring的配置描述、Maven仓库描述等等。

• JSON： 
  JSON(JavaScript Object Notation) 是一种轻量级的数据交换格式。它和XML的设计思路是一致的：和语言无关（流行的语言都支持JSON格式描述：Go、Python、C、C++、C#、JAVA、Erlang、JavaScript等等）；但是和XML不同，JSON的设计目标就是为了进行通信。要描述同样的数据，JSON格式的容量会更小。

• protocol buffer（PB）： 
  protocolbuffer(以下简称PB)是google 的一种数据交换的格式，它独立于语言，独立于平台。google 提供了三种语言的实现：java、c++ 和 python，每一种实现都包含了相应语言的编译器以及库文件。

• TLV（三元组编码）： 
  T（标记/类型域）L（长度/大小域）V（值/内容域），通常这种信息格式用于金融、军事领域。它通过字节的位运算来进行信息的序列化/反序列化（据说微信的信息格式也采用的是TLV，但实际情况不清楚）。

• 自定义的格式 
  当然，如果您的两个内部系统已经约定好了一种信息格式，您当然可以使用自己定制的格式进行描述。您可以使用C++描述一个结构体，然后序列化/反序列它，或者使用一个纯文本，以“|”号分割这些字符串，然后序列化/反序列它。

2.网络协议

• 物理层：物理层就是我们的网络设备层，例如我们的网卡、交换机等设备，在他们之间我们一般传递的是电信号或者光信号。

• 数据链路层：数据链路又分为物理链路和逻辑链路。物理链路负责组合一组电信号，称之为“帧”；逻辑链路层通过一些规则和协议保证帧传输的正确性，并且可以使来自于多个源/目标 的帧在同一个物理链路上进行传输，实现“链路复用”。

• 网络层：网络层使用最广泛的协议是IP协议（又分为IPV4协议和IPV6协议），IPX协议。这些协议解决的是源和目标的定位问题，以及从源如何到达目标的问题。

• 传输层：TCP、UDP是传输层最常使用的协议，传输层的最重要工作就是携带内容信息了，并且通过他们的协议规范提供某种通信机制。举例来说，TCP协议中的通信机制是：首先进行三次通信握手，然后再进行正式数据的传送，并且通过校验机制保证每个数据报文的正确性，如果数据报文错误了，则重新发送。

• 应用层：HTTP协议、FTP协议、TELNET协议这些都是应用层协议。应用层协议是最灵活的协议，甚至可以由程序员自行定义应用层协议

3.通信方式/框架

3.1 BIO（阻塞模式）通信：

• 客户端向服务器端发出请求后，客户端会一直等待（不会再做其他事情），直到服务器端返回结果或者网络出现问题。

• 服务器端同样的，当在处理某个客户端A发来的请求时，另一个客户端B发来的请求会等待，直到服务器端的这个处理线程完成上一个处理。

3.2 NIO（非阻塞模式）通信：

目前流行的NIO框架非常的多。在论坛上、互联网上大家讨论和使用最多的有以下几种：

• 原生JAVA NIO框架： 
  JAVA NIO通信框架基于多路复用IO原理。

• APACHE MINA 2： 
  是一个网络应用程序框架，用来帮助用户简单地开发高性能和高可扩展性的网络应用程序。它提供了一个通过Java NIO在不同的传输例如TCP/IP和UDP/IP上抽象的事件驱动的异步API。

• NETTY 4/5： 
  Netty是由JBOSS提供的一个java开源框架。Netty提供异步的、事件驱动的网络应用程序框架和工具，用以快速开发高性能、高可靠性的网络服务器和客户端程序。我们将讲解NETTY 4 的工作原理。另外说一句：MANA和NETTY的主要作者是同一人Trustin Lee。

• Grizzly： 
  Grizzly是一种应用程序框架，专门解决编写成千上万用户访问服务器时候产生的各种问题。使用JAVA NIO作为基础，并隐藏其编程的复杂性。

4.通信方式

4.1 直接使用单纯HTTP请求（速度慢、复杂调用时接口不易管理）

4.2 RPC

      定义：

• RPC是协议：既然是协议就只是一套规范，那么就需要有人遵循这套规范来进行实现。目前典型的RPC实现包括：Dubbo、Thrift、GRPC、Hetty等。这里要说明一下，目前技术的发展趋势来看，实现了RPC协议的应用工具往往都会附加其他重要功能，例如Dubbo还包括了服务管理、访问权限管理等功能。

• 网络协议和网络IO模型对其透明：既然RPC的客户端认为自己是在调用本地对象。那么传输层使用的是TCP/UDP还是HTTP协议，又或者是一些其他的网络协议它就不需要关心了。既然网络协议对其透明，那么调用过程中，使用的是哪一种网络IO模型调用者也不需要关心。

• 信息格式对其透明：我们知道在本地应用程序中，对于某个对象的调用需要传递一些参数，并且会返回一个调用结果。至于被调用的对象内部是如何使用这些参数，并计算出处理结果的，调用方是不需要关心的。那么对于远程调用来说，这些参数会以某种信息格式传递给网络上的另外一台计算机，这个信息格式是怎样构成的，调用方是不需要关心的。

• 应该有跨语言能力：为什么这样说呢？因为调用方实际上也不清楚远程服务器的应用程序是使用什么语言运行的。那么对于调用方来说，无论服务器方使用的是什么语言，本次调用都应该成功，并且返回值也应该按照调用方程序语言所能理解的形式进行描述。

      典型的rpc框架

• JAVA RMI：RPC最早就是由SUN提出，并在后来由IETF ONC修订。RMI就是一个典型的RPC实现，只不过RMI不支持跨语言性，所以RMI中也没有IDL存在的必要。但是RMI真心快，并且由于没有IDL的存在，在构建一套完整的RPC实现时要比其他RPC框架少了一些步骤，所以使用起来也比较简单。如果您的业务需求中并不存在跨语言的考虑，并且基本上主要系统都是用JAVA实现，那么RMI绝对是您一个可以考虑的方案。

• GRPC：GRPC是一个高性能、通用的开源RPC框架，由Google主要面向移动应用开发并基于HTTP/2协议（注意是HTTP/2协议，不是我们常使用的HTTP 1_1。HTTP/2协议详细的介绍可以参见官方地址：https://http2.github.io/）标准而设计，基于ProtoBuf(Protocol Buffers)序列化协议开发，且支持众多开发语言。为了支持GRPC的跨语言性，GRPC有一套独立存在IDL语言。不过由于GRPC是Google的开源产品，在信息格式封装方面Google主要还是推广的自己的ProtoBuf，所以GPRC是不支持其他信息格式的（至少ProtoBuf效率是大家有目共睹的）。关于GRPC详细的使用介绍，可以参见官方地址：https://github.com/grpc/grpc

• Thrift：Thrift是Facebook的一个开源项目，后来进入Apache进行孵化。Thrift也是支持跨语言的，所以它有自己的一套IDL。目前它支持几乎所有主流的编程语言：C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, OCaml and Delphi and other languages。Thrift可以支持多种信息格式，除了Thrift私有的二进制编码规则和一种LVQ（类似于TLV消息格式）的消息格式，还有常规的JSON格式。Thrift的网络协议建立在TCP协议基础上，并且支持阻塞式IO模型和多路IO复用模型。Thrift也是目前最流行的RPC框架之一，从网络上各种性能测试情况开，Thrift的性能都是领先的。Thrift的官网地址为：http://thrift.apache.org/

• Hetty：Hetty是一款构建于Netty和Hessian基础上的高性能的RPC框架。Hetty的网络协议基于HTTP，由于采用了Netty，所以Hetty支持阻塞式IO模型和多路IO复用模型。Hetty的消息格式采用私有的二进制流格式。

• Dubbo：Dubbo是Alibaba开源的分布式服务框架。注意我说的是分布式服务框架，不是RPC框架（用比较严谨的词语概括，应该是“服务治理框架”）。除了集成RPC的规范外，Dubbo还在RPC的上层搭建服务层功能、配置层功能、服务路由功能（加上真正的RPC规范实现总共有10层）。

• 其他的RPC框架：除了上诉的RPC协议的实现外，还有：Wildfly、Hprose等等。Hprose是一款国人主导的RPC实现，感兴趣的读者可以去看看（http://www.hprose.com/）。另外基于RPC的定义，Xfire，CXF这些Web Service框架也属于RPC：WSDL描述文件就是他们的IDL，通过WSDL为不同的编程语言生成Stub、通过不同的Web服务器管理具体服务实现的运行过程、HTTP是它们的通信协议、XML是它们的消息格式。

      rpc性能依据：

      在物理服务器性能相同的情况下，以下几个因素会对一款RPC框架的性能产生直接影响：

• 所支持的网络IO模型：您的RPC服务器可以只支持传统的阻塞式同步IO，也可以做一些改进让您的RPC服务器支持非阻塞式同步IO，或者在您的服务器上实现对多路IO模型的支持。这样的RPC服务器的性能在高并发状态下，会有很大的差别。特别是单位处理性能下对内存、CPU资源的使用率。

• 基于的网络协议：一般来说您可以选择让您的RPC使用应用层协议，例如HTTP或者之前我们提到的HTTP/2协议，或者使用TCP协议，让您的RPC框架工作在传输层。工作在哪一层网络上会对RPC框架的工作性能产生一定的影响，但是对RPC最终的性能影响并不大。但是至少从各种主流的RPC实现来看，没有采用UDP协议做为主要的传输协议的。

• 选择的消息封装格式：选择或者定义一种消息格式的封装，要考虑的问题包括：消息的易读性、描述单位内容时的消息体大小、编码难度、解码难度、解决半包/粘包问题的难易度。当然如果您只是想定义一种RPC专用的消息格式，那么消息的易读性可能不是最需要考虑的。消息封装格式的设计是目前各种RPC框架性能差异的最重要原因，这就是为什么几乎所有主流的RPC框架都会设计私有的消息封装格式的原因。

• 实现的服务处理管理方式：在高并发请求下，如何管理注册的服务也是一个性能影响点。您可以让RPC的Selector/Processor使用单个线程运行服务的具体实现（这意味着上一个客户端的请求没有处理完，下一个客户端的请求就需要等待）、您也可以为每一个RPC具体服务的实现开启一个独立的线程运行（可以一次处理多个请求，但是操作系统对于“可运行的最大线程数”是有限制的）、您也可以线程池来运行RPC具体的服务实现（目前看来，在单个服务节点的情况下，这种方式是比较好的）、您还可以通过注册代理的方式让多个服务节点来运行具体的RPC服务实现。

4.3 MQ

    4.3.1 消息定义

    三个基本概念：消息、消息协议、消息队列。消息既是信息的载体。为了让消息发送者和消息接收者都能够明白消息所承载的信息（消息发送者需要知道如何构造消息；消息接收者需要知道如何解析消息），它们就需要按照一种统一的格式描述消息，这种统一的格式称之为消息协议。所以，有效的消息一定具有某一种格式；而没有格式的消息是没有意义的。

而消息从发送者到接收者的方式也有两种。一种我们可以称为即时消息通讯，也就是说消息从一端发出后（消息发送者）立即就可以达到另一端（消息接收者），这种方式的具体实现就是我们已经介绍过的RPC（当然单纯的http通讯也满足这个定义）；另一种方式称为延迟消息通讯，即消息从某一端发出后，首先进入一个容器进行临时存储，当达到某种条件后，再由这个容器发送给另一端。 这个容器的一种具体实现就是消息队列。

    4.3.2 消息协议

    XMPP：

XMPP基于XML，用于IM系统的开发。国内比较流行的XMPP服务器叫做Openfire，它使用MINA作为下层的网络IO框架（不是MINA2是MINA1）；国外用的比较多的XMPP服务器叫做Tigase，它的官网号称单节点可以支撑50万用户在线，集群可以支持100万用户在线：（http://projects.tigase.org/）

    Stomp：

Stomp协议，英文全名Streaming Text Orientated Message Protocol，中文名称为 ‘流文本定向消息协议’。是一种以纯文本为载体的协议（以文本为载体的意思是它的消息格式规范中没有类似XMPP协议那样的xml格式要求，你可以将它看作‘半结构化数据’）。目前Stomp协议有两个版本：V1.1和V1.2。一个标准的Stomp协议包括以下部分：命令/信息关键字、头信息、文本内容。

    AMQP：

AMQP协议的全称是：Advanced Message Queuing Protocol（高级消息队列协议）。目前AMQP协议的版本为 Version 1.0，这个协议标准在2014年通过了国际标准组织 (ISO) 和国际电工委员会 (IEC) 的投票，成为了新的 ISO 和 IEC 国际化标准。

    当然还有很多具体的消息队列协议没有讲到，但是通过介绍XMPP、AMQP、Stomp协议可以起到一个管中窥豹可见一斑的效果。

    补充JMS

JMS不是消息队列，更不是某种消息队列协议。**JMS是Java消息服务接口，是一套规范的JAVA API 接口。这套规范接口由SUN提出，并在2002年发布JMS规范的Version 1.1版本。**JMS和消息中间件厂商无关，既然是一套接口规范，就代表这它需要各个厂商进行实现。好消息是，大部分消息中间件产品都支持JMS 接口规范。也就是说，您可以使用JMS API来连接Stomp协议的产品（例如ActiveMQ）。就像您可以使用JDBC API来连接ORACLE或者MYSQL一样。

    4.3.3 具体mq产品

目前业界有很多消息中间件可供大家选择，主要分为两类：需要付费的商业软件和开源共享的非商业软件。对于商业软件您和您的团队可以选择IBM WebSphere集成的MQ功能，也可以选择Oracle WebLogic集成的MQ功能。非商业软件比较流行的有：

ActiveMQ

ActiveMQ是Apache软件基金会的开源产品，支持AMQP协议、MQTT协议（和XMPP协议作用类似）、Openwire协议和Stomp协议等多种消息协议。并且ActiveMQ完整支持JMS API接口规范（当然Apache也提供多种其他语言的客户端，例如：C、C++、C#、Ruby、Perl）。

RabbitMQ

RabbitMQ基于Erlang语言开发和运行。它与Apache ActiveMQ有很多相同的特性，例如RabbitMQ完整支持多种消息协议：AMQP、STOMP、MQTT、HTTP，我们使用RabbitMQ时会默认使用AMQP1.0 协议。当然，RabbitMQ作为Apache ActiveMQ最主要的竞品之一也有其独特的功能特性。例如RabbitMQ支持一套特有的Routing-Exchange消息路由规则。这套规则可以按照消息内容，自动将消息归类到不同的消息队列中。

Kafka

Apache Kafka最初由LinkedIn贡献，目前它是Apache下的一个顶级开源项目。Apache Kafka设计的首要目标是解决LinkedIn网站中海量的用户操作行为记录、页面浏览记录，后继的Apache Kafka版本也都是将“满足高数据吞吐量”作为版本优化的首要目标。为了达到这个目标，Apache Kafka甚至在其他功能方面上做了一定的牺牲，例如：消息的事务性。如果您的系统需要进行单位时间内大量的数据采集工作，那么可以考虑在您的系统设计方案中加入Apache Kafka。

5.整合手段

5.1 ESB

ESB（企业服务总线）是SOA的典型实现，各种ESB软件它们的共同特点是：将各个（有访问权限的）系统所提供服务集中在一起（进行管理、控制、协调），请求方只需要访问ESB软件，然后再由ESB软件代其访问指定的服务，最后返回处理结果。ESB的功能特点是代理。

5.2 服务治理

服务注册中心，是SOA的另一种实现方式，和

https://www.cnblogs.com/likehua/p/3999538.htmlESB最大的不同点是：“服务注册中心”主要提供各原子系统的服务注册、服务治理、服务隔离、权限控制。当客户端进行请求时，“服务治理”将告诉客户端到哪里去访问真实的服务，自己并不提供服务的转发。Dubbo就是一个典型的服务治理框架。

参考：

https://blog.csdn.net/wangyunpeng0319/article/details/78651998

https://www.cnblogs.com/zhuxiaojie/p/5564187.html

https://www.cnblogs.com/likehua/p/3999538.html

https://www.sojson.com/blog/48.html