消息系统的业界挑战
第一，开源软件给传统闭源软件带来的冲击。早期的消息系统是闭源的，但随着开源生态的发展，出现越来越多的的开源消息系统，使得用户在面临消息系统选型的时候有了更多的选择，这对传统的Messaging厂商来说是个非常大的挑战。
第二，互操作性成本越来越高。消息系统正面临越来越多的上下游生态。例如，部门和部门之间选择了不同的技术栈，这个部门选择了这个消息，那个部门产生了那个消息，当两者之间进行流通的时候必然带来了互操作性的问题，所以，这对消息系统提出了很高的互操作性要求。
第三，消息天然就是异构的，它是为解决数据间的流转问题而生。每个部门在拥有自己技术栈的同时产生了不同的开发语言，每门语言都有自己所擅长的技术领域，一门语言并无法通吃所有需求场景。这样的场景下，如果用了Messaging，都会希望消息系统能在不同的语言之间进行互通，但目前，业界很少有多语言的消息系统并且可以cover的得很好的，因为缺少稳定的多语言类库。
第四，券商和电商领域需要微秒级的延迟，微秒级的延迟在软件和硬件上没有达到很好的配合，所以第四个挑战就是由于嵌入式和新型硬件设备能力较弱所导致的。
第五，物联网有很多的端，端到端之间到后台都有数据采集和数据上报，规模化的部署能力也是所有消息系统所面临的挑战。
阿里巴巴是如何应对这类挑战的
第一，我们希望在开源基础框架的基础上，能够针对某些垂直领域或者针对高性能低延时场景分别推出企业版本和云上版本。云上版本重点关注部署流畅度，降低部署时间，提高扩展性，甚至能够加速云基础设施的迁移。因为很多MMQ的厂商已经做了商业化的场景，而我们做了企业版本，在FQ领域研发了IOT网关，在金融领域应用分布式的消息，通过这种方式让用户使用起来，而云上我们有更强的兜底能力。大家使用云上版本之后会发现：成本降下来了，部署速度快了，企业只需要专注业务，不需要关注底层基础设施的变化所带来的影响。
第二，互操作性在任何技术领域都是一个需要面对的问题。而在消息领域，业界已经有三个比较出名的消息标准，但都无法很好的解决互操作性问题：JMS是一个Java 平台中关于面向消息中间件的API；MQTT是对物联网行业具有低功耗特点的通讯协议；AMQP则主要应用于电信和金融行业。
在评估了所有可用的替代品后，我们决定选择创建一个新的面向Cloud Native的消息分发标准 OpenMessaging，这是一个供应商中立，且和语言无关的标准，并为金融、电子商务、物联网和大数据等领域提供了行业指南。
第三，我们开放了OpenMessaging内核，并通过sidercar的方式提供了解决多语言需求的方案，据此，我们只需要在Java的基础上，打造C语言的内核，然后把Java和C语言的内核开放出来，在此之上建立Python、Go等其他语言的sdk，实现和社区共建生态。
第四，在券商和电商领域，我们提出一个解决方案：大家都很清楚就是现在慢慢在使用NVMI存储去替代以前的SSD硬盘。如果我们采用这类硬件设备，是可以绕过内核的。通过对比发现，MQ的硬件设备，在硬件层通过SSD存储层，延迟会大大降低，所有的延迟都集中在APP层或者集中在硬件驱动层。这样的话，能够保证应用在100毫秒甚至十几微秒的情况下达到非常少的延迟。而传统的软件要适配在这类硬件上是很有挑战的，因为这类硬件不兼容传统软件的API。
第五，对于规模化的部署，存储计算分离和事件驱动架构是很好的解决方案。例如，IoT领域，存储端和计算端是可以分开的，这样极大地的提升了端的计算能力。
OpenMessaging的未来发展方向
现在，我们都看到了基础设施非常open，就像公路和桥梁一样，有很多的操作系统，像Open Office办公软件等很多技术已经转向开放，我们希望将OpenMessaging打造成数据层面非常好的基石。
数据维度，我们可以涵盖日志数据和业务数据；行业维度，游戏行业、电商行业的交易数据都可以通过OpenMessaging往下拓展，对于IOT，则可以通过OpenMessaging把数据的上游和下游以标准化的方式串起来。厂商维度，包括Apache Kafka，Apache RocketMQ，RabbitMQ，Apache ActiveMQ都可以基于这个标准构建下一代的消息解决方案。
现在，OpenMessaging有四个工作组：第一个工作组主要是关注在span的制定上面；第二个工作组是解决API；第三个工作组是希望提供bench mark API；第四个工作组是解决存储的工具化，因为未来的架构一定是存储和计算分离，一定会面临很多的存储。
经过一年多的发展，整个OpenMessaging的技术发展委员会已经有7名成员，他们分别来自4家公司，有电商、广告搜索、流计算，还有数据集成，大家共同的特点就是互操作。除了对产品和技术方向进行把握的技术委员会之外，还有11位来自6家不同企业组成的咨询委员会，这11位同学会帮助我们提一些建设和产品发展规划方面的建议。除此之外，还有接近二十多位来自社区的contributors，从而保证OpenMessaging是在往多元化、无厂商锁定的健康的方向上发展。