架构设计：系统间通信（1）——概述从“聊天”开始上篇

从这篇博文开始，我们将进入一个新文章系列。这个文章系列专门整理总结了目前系统间通信的主要原理、手段和实现。我们将讲解典型的信息格式、讲解传统的RMI调用并延伸出来重点讲解RPC调用和使用案例；最后我们还会讲到SOA架构的实现，包括ESB实现和服务注册/治理的实现，同样包括原理、实现和使用案例。

系统间通信是架构师需要掌握的又一个关键技术领域，如果说理解和掌握负载均衡层技术需要您有一定的linux系统知识和操作系统知识的话，那么理解和掌握系统间通信层技术，需要您有一定的编程经验（最好是JAVA编程经验，因为我们会主要以JAVA技术作为实例演示）。

1、一个场景

首先我们来看一个显示场景：在现实生活中有两个人技术人员A和B，在进行一问一答形式的交流。如下图所示：

我们来看这幅图的中的几个要点：

• 他们两都使用中文进行交流。如果他们一人使用的是南斯拉夫语另一人使用的是索马里语，并且相互都不能理解对方的语系，很显然A所要表达的内容B是无法理解的。

• 他们的声音是在空气中进行传播的。空气除了支撑他们的呼吸外，还支撑了他们声音的传播。如果没有空气他们是无法知道对方用中文说了什么。

• 他们的交流方式是协调一致的，即A问完一个问题后，等待B进行回答。收到B的回答后，A才能问下一个问题。

• 由于都是人类，所以他们处理信息的方式也是一样的：用嘴说话，用耳朵听话，用大脑处理形成结果。

• 目前这个交流场景下，只有A和B两个人。但是随时有可能增加N个人进来。第N个人可能不是采用中文进行交流。

2、信息格式

很明显通过中文的交谈，两个人相互明白了对方的意图。为了保证信息传递的高效性，我们一定会将信息做成某种参与者都理解的格式。例如：中文有其特定的语法结构，例如主谓宾，定状补。

在计算机领域为了保证信息能够被处理，信息也会被做成特定的格式，而且要确保目标能够明白这种格式。常用的信息格式包括：

• 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，但实际情况我不清楚）：

这里有一篇介绍TLV的文章：《通信协议之序列化TLV》，TLV格式所携带的内容是最有效的，它就连JSON中用于分割层次的“{}”符号都没有。

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

在这个系列的博文中，我们不会把信息格式作为一个重点，但是会花一些篇幅去比较各种信息格式在网络上传输的速度、性能，并为大家介绍几种典型的信息格式选型场景。

3、网络协议

如文中第一张图描述的场景，有一个我们看不到但是却很重要的元素：空气。声音在空气中完成传播，真空无法传播声音。同样信息是在网络中完成传播的，没有网络就没法传播信息。网络协议就是计算机领域的“空气”，下图中我们以OSI模型作为参考：

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

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

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

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

• 应用层：HTTP协议、FTP协议、TELNET协议这些都是应用层协议。应用层协议是最灵活的协议，甚至可以由程序员自行定义应用层协议。下图我们表示了HTTP协议的工作方式：

在这个系列的博文中，我们不会把网络协议作为一个重点。这是因为网络网络协议的知识是一个相对独立的的知识领域，十几篇文章都不一定讲得清楚。如果您对网络协议有兴趣，这里推荐两本书：《TCP/IP详解.卷1-协议》和《TCP/IP详解.卷2-实现》。

4、通信方式/框架

在文章最前面我们看到其中一个人规定了一种沟通方式：“你必须把我说的话听完，然后给我反馈后。我才会问第二个问题”。这种沟通方式虽然沟通效率不高，但是很有效：一个问题一个问题的处理。

但是如果参与沟通的人处理信息的能力比较强，那么他们还可以采用另一种沟通方式：“我给我提的问题编了一个号，在问完第X个问题后，我不会等待你返回，就会问第X+1个问题，同样你在听完我第X个问题后，一边处理我的问题，一边听我第X+1个问题。”

实际上以上两种现实中的沟通方式，在计算机领域是可以找到对应的通信方式的，这就是我们这个系列的博文会着重讲的BIO（阻塞模式）通信和NIO（非阻塞模式）。

4-1、BIO通信方式

以前大多数网络通信方式都是阻塞模式的，即：

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

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

如下图所示：

传统的BIO通信方式存在几个问题：

• 同一时间，服务器只能接受来自于客户端A的请求信息；虽然客户端A和客户端B的请求是同时进行的，但客户端B发送的请求信息只能等到服务器接受完A的请求数据后，才能被接受。