1. 引言

在华为核心网和无线领域有几个重量级的产品比如U2000/M2000等网管系统^[1]。里面的底层通信就是一套基于MDP(Message Dispatching Process)的星形拓扑通信系统。不同的业务进程之间通过消息(REQ/RSP)来通信，而不是通信RPC或者库的依赖。

由于年代久远，和现在主流的MQ技术相比有一些不同的地方，随便说几点:

1. 消息序列化只支持ASN.1. 当然好处在于提供一套抽象的语义定义，并且大家只需要传递ASN.1文件即可。或者由一个公共方将ASN.1文件编程对应的模型和支撑库提供给各个端对进行开发。但是同时呢，不好的地方也很明显，一方面是技术过时，再一个就是需要一个专门的团队来维护ASN.1定义和相应的工具；另一方面在于管理上没有形成一个好的ASN.1的分发机制。导致版本之间定义很混乱。对于前后向兼容性问题很难做到。当然，在网上也可以找到一些开源的ASN.1 Compiler^[3]。能不能用不清楚。

2. MDP并不支持消息的缓存和队列机制，本身也不提供可靠性保证。 那么如何来提供不丢失的消息呢？ 在华为，答案是提供一个框架层，业务团队并不直接使用MDP提供的库和接口，而是使用封装之后的一套框架，这套框架中提供了可靠性事件的发送的。实现的机制就是在发送之前存库。在接收业务处理完成之后，再从数据库中移除。当然这套机制也出现过不少问题，比如消息积压，数据库的内容不断上涨，甚至在局点可能出现过数据库表过大，导致其他业务访问很慢，甚至于极端情况下，整个数据库崩掉的情况都有。

3. MDP无法水平扩展，当消息出现峰值的时候，MDP有可能出现丢包的问题。 这个问题也比较头疼。这是从一开始设计的时候就没有考虑的问题。考虑到U2000/M2000对应的数据量实际上是很大的。假如MDP的处理峰值在于2000/s，每秒钟2W条消息尽力保证不丢包。 这个阈值总会在未来的某一天会被打破，那么这个时候问题就出来了，系统会出现频繁丢包，系统业务频繁故障，但是由于底层数据通道，在应用层面几乎无法做到一个比较好的解决方案。

4. ***MDP采用ACE^[4]，这一套框架比较复杂。***当然整体的U2000/M2000都是基于这个来开发，导致比较重型。
   另外就是在U2000/M2000北向领域，采用了大量的ACE/TAO/Event Channel机制。灵活性不够。
   为什么说CORBA是一个很不好的技术，最终会被时代所抛弃? 可以看这篇论文。下载链接

5. ***当前通信架构转异构通信架构的难度。***对于U2000/M2000来说，所有的开发支撑库都需要自己来完成。当然，对于华为来说，这个不是问题。问题这是人力预算的问题。

上面说的一些问题在华为内部看来，有一些并不是问题，有一些问题可以绕过。有几个点：

1. 客户的OSS/BSS系统都是基于CORBA调用。
2. ITU的标准定义就是基于ASN.1模型发布。
3. 整个产品技术切换的成本太高, 所以要保护既有投资，CORBA技术带来的复杂度也可以成为一种护城河。
4. 整个业务开发团队转型所面临的学习成本、人才招聘、人力缺口等等。

那么，从这几点来考虑，保持当前技术稳定，保持客户服务的稳定变是重点。所以，对于大企业来说，真的不是某个技术好就要上的。上面这个并非是吐槽，而是纯粹从技术上来分析我所经历过的产品在架构上的一些问题。

那么回过头来，那么如何通过messge queue来解耦不同系统（同构的还是异构的)来交换和通信来实现多异构同构系统之间的 星形通信呢？ 我们来做一个简单的设计。

这篇文章是一篇未完成稿，有时间再写

什么是消息队列（Message Queue）?

消息队列使得应用之间可以通过互发消息的方式来通信，这和传统的RPC方式有很大的区别。通过消息队列提供的服务，解除了点对点，星形拓扑通信耦合的问题。同时，当目标服务不可用的时候，消息队列充当了临时的消息缓存。

下面先解释一下什么是消息队列^[1]，怎么使用，在架构层面又会带来什么样的好处^[2]。

队列就是将事物排成一列，依次处理，并且依照先进先出(First In, First Out)的顺序。那么消息队列（MQ），就是用于不同系统或者应用之间通信的的列表， 将需要通信的消息保存在队列中，等待应用依次处理。queues.io是一个比较好的网站可以查找各种不同功能的队列。

调研结果和建议

综合来看，Avro或者Protocol Buffer二选一即可， 但是出于灵活性和标准JSON的支持力度上来看，更推荐Protocol Buffers。同时部分数据依然可以通过JSON方式传输。

主流序列化框架对比

Kafka的序列化

Kafka并不限定的消息格式。Kafka自身提供了一系列的序列化器，比如ByteArraySerializer，ByteBufferSerializer，DoubleSerializer，FloatSerializer，StringSerializer，UUIDSerializer， IntegerDeserializer, LongSerializer, ShortSerializer, 总结起来就是基本类型、字符串类型、二进制消息。

但是在通常情况下不会使用比如Float这种来做序列化，原因在于系统间交互或者放到Kafka的数据一般来说都比较复杂，无法用一个字段来表示。于是，这种情况下，就需要在Kafka之上建立一个消息格式的契约，以便于Kafka的生产者和消费者之间都能理解消息中的语义。最好地方就是在Kafka基础之上增加一层应用层的消息协议，比如JSON格式、比如二进制编解码协议（序列化），出于性能考虑，一般也不直接使用Java POJO对象的原生序列化（虽然可行）。在Apache Spark中使用的Kryo Register，由于场景限制（不提供IDL定义），不适用Kafka。

下面对常见的几个序列化框架做一个横向对比：

占坑，后面有时间对Kafka进行详细的更新

A bit of History

Kafka是高性能的、分布式的、数据可持久化的消息丢列。最初由LinkedIn开发，用来跟踪Web上的用户的一系列事件，譬如页面浏览(Page view)，搜索框的输入，展示的广告等等。这些事件对于监控和调查用于对于网站交互的参与度非常的重要。每天都有大量的数据产生，因为，需要一个可以轻松扩展，同时又不会增加额外负担的一个解决方案。

总体来说，Kafka从设计之初有3个目标：

1. 简单的生产者/消费者API设计
2. 尽可能减少网络传输和磁盘存储的额外成本
3. 从一开始就为可扩展性而设计

调研结果和建议

针对是否可以跨数据中心部署Kafka集群的问题，答案是可行，但是不建议。建议先支持单集群部署，以简化运维成本，支持多地多应用业务上线。

可行性与跨网络部署产生的问题

Kafka实际上并不禁止将Broker部署到不同的网络地域。但是，Kafka的设计是按照单个数据中心进行设计、开发、测试和调优的。从Kafka的官方文档^[1]来看，并不推荐将集群跨网络部署。 由于Broker分布在不同的跨地域的网络（WAN）, 除了数据同步会极大地增加延迟之外， 并且如果由于网络中断无法保证zk始终可用，带来其他问题，比如：

1. Partition Leader无法选举。或者由于网络问题，某个Broker频繁掉线导致集群不稳定。
2. 在Producer推送数据时候，产生延迟（推送到remote Broker）。或者由于网络问题，无法获取ACK。

什么是Thrift?

Thrift是一种接口描述语言和二进制通讯协议，它被用来定义和创建跨语言的服务。它被当作一个远程过程调用（RPC）框架来使用，是由Facebook为“大规模跨语言服务开发”而开发的。它通过一个代码生成引擎联合了一个软件栈，来创建不同程度的、无缝的跨平台高效服务，可以使用C#、C++（基于POSIX兼容系统）、Cappuccino、Cocoa、Delphi、Erlang、Go、Haskell、Java、Node.js、OCaml、Perl、PHP、Python、Ruby和Smalltalk。虽然它以前是由Facebook开发的，但它现在是Apache软件基金会的开源项目了。该实现被描述在2007年4月的一篇由Facebook发表的技术论文中，该论文现由Apache掌管。

目前流行的服务调用方式有很多种，例如基于 SOAP 消息格式的 Web Service，基于 JSON 消息格式的 RESTful 服务等。其中所用到的数据传输方式包括 XML，JSON 等，然而 XML 相对体积太大，传输效率低，JSON 体积较小，新颖，但还不够完善。本文将介绍由 Facebook 开发的远程服务调用框架 Apache Thrift，它采用接口描述语言定义并创建服务，支持可扩展的跨语言服务开发，所包含的代码生成引擎可以在多种语言中，如 C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, Smalltalk 等创建高效的、无缝的服务，其传输数据采用二进制格式，相对 XML 和 JSON 体积更小，对于高并发、大数据量和多语言的环境更有优势。本文将详细介绍 Thrift 的使用，并且提供丰富的实例代码加以解释说明，帮助使用者快速构建服务。Thrift的下载地址是：http://thrift.apache.org/download

thrift.exe支持的参数有哪些？

原作者： 保罗▪福特 2015年2月11日
译者： 山野@成都 2017

在阅读之前

这篇文章^[1]是我在2017年在麻省理工评论（MIT Technology Review）上看到的翻译的。 作者是保罗▪福特^[2]。距离当初的翻译已经过去了2年。现在人工智能的概念已经深入到各行各业，从大家经常接触的SNS社交数据挖掘、智能客服、B2C商品推荐系统、新闻推荐系统、智能汽车，以及到更广泛的更偏向于传统的领域，比如医疗、城市规划、交通领域、建筑领域、社区管理、行政服务等等的一切都在提到一个词，那就是“智慧”，“智能”。

这一切的背后都和机器学习技术（深度学习、加强学习）等等的兴起，以及更加容易使用的框架和API，比如谷歌的tensorflow；更加容易处理大规模数据的框架，比如Apache Spark、Apache Hadoop套件等，这些都助力于并提高了各种业务对于基于大量数据的建模和预测能力。而这些能力就是大家所说的人工智能。

下面这篇文章并没有讲解具体的某种应用于人工智能的技术，而是从更高更抽象的层面，从社会和伦理的层面探讨了人工智能所带来的一些问题。

下面是正文：

通过maven自动化构建protocal buffer

当对代码进行工程构建的时候，如果能够尽可能的自动化，这样对于提升整个软件质量、节省人力成本、减少因为人工干预导致的各种不可预知的错误是很好。
从protobuf的官方文档来看，通过cmd调用protoc当然可以生成相应的代码，但是对构建不够友好。于是，可以考虑通过maven来进行自动化构建，在启动maven构建的时候，自动调用protoc，生成代码，并打包成相应的jar包，集成到工程发布包中。
这里有2种方式，如下。

RPM

RPM是Red-Hat Package Manager（RPM软件包管理器）的缩写，这一文件格式名称虽然打上了RedHat的标志^[1]，但是其原始设计理念是开放式的，现在包括OpenLinux、S.u.S.E.以及Turbo Linux等Linux的分发版本都有采用，可以算是公认的行业标准了。

apt-get

apt-get^[2]，是一条linux命令，适用于deb包管理式的操作系统，主要用于自动从互联网的软件仓库中搜索、安装、升级、卸载软件或操作系统。主要适用于Debian、Ubuntu的系统。

maven从设计上来说非常的简单，但是却是一个非常强大的工具。很多人将maven只是当做一个构建工具（从源代码生成可运行软件），但是实际上可以将maven当做一个项目管理工具，比如工程管理、插件管理、Jar包依赖管理、软件发布仓库管理等。

下面讲解一些在使用maven当中所遇到的一些小的技巧。