Kubernetes这项技术对于我今年的职业生涯而言可谓至关重要，相信其重要意义在新的一年中还将继续保持。值此辞旧迎新之际，请大家允许我结合个人体会做出一点大胆的预测：Kubernetes的未来在于虚拟机，而非容器。

Kubernetes这项技术对于我今年的职业生涯而言可谓至关重要，相信其重要意义在新的一年中还将继续保持。值此辞旧迎新之际，请大家允许我结合个人体会做出一点大胆的预测：Kubernetes的未来在于虚拟机，而非容器。
2018年是中国十二生肖中的狗年，同时也是技术层面的Kubernetes元年。如今，学习Kubernetes的朋友已经为数不少，各公司的CIO也在努力制定自己的“Kubernetes战略”。更有部分组织已经开始在Kubernetes上运行大规模生产工作负载。
如果您刚刚尝试建立Kubernetes策略，那么您恐怕已经失败了——我们会在后续文章中就此展开探讨。
换句话说，在Gartner为Kubernetes提出的炒作周期各个阶段当中，都有很多人陷入了幻灭的低谷甚至是绝望的陷阱。

我个人正是容器技术的忠实粉丝，我也绝对不是说容器技术会走向消亡。Docker于2013年为我们带来了Linux容器的打包方案，其显示出一种令人印象深刻的应用程序构建、打包、共享与部署新方法。容器的成功可谓正当其时，毕竟这时候我们正在认真考虑如何实现持续交付。容器模型***适合现代交付管道与PaaS，同时也高度契合之后出现的CaaS平台。

谷歌公司的工程师们也意识到，技术社区终于为容器的出现做好了准备。长久以来，谷歌方面一直在使用(甚至在一定程度上发明了)容器技术。他们开始构建Kubernetes，现在我们知道其灵感源自谷歌内部的Borg平台，而项目本身则以社区开发的形式运作。
不久之后，各大公有云供应商就为Kubernetes提供了***的发挥舞台(GKE、AKS以及EKS等)。内部人员也很快建立起自己的基于Kubernetes平台(Pivotal Container Service以及OpenShift等)。
令人头痛的多租户机制
然而，仍有一个棘手的问题有待解决，我认为这也可能成为容器崩溃的核心原因——多租户机制。
Linux容器在设计之初并没有考虑到安全的隔离沙箱(例如Solaris Zones或者FreeBSD Jails)。相反，容器采用的是共享内核模式，其利用内核功能提供基础性的进程隔离功能。正如Jessie Frazelle在文章中指出，“容器并不真实存在。”

更麻烦的是，大多数Kubernetes组件无法感知到租户。虽然我们可以使用命名空间以及Pod安全策略，但API本身确实不具备租户感知能力。此外， kubelet或者kube-proxy等内部组件也存在同样的问题。这意味着Kubernetes能够提供的只是一种“软租户”模式。

抽象泄漏。建立在容器之上的平台会继承容器技术的诸多软租户因素。正如建立在硬多租户虚拟机基础之上的平台(包括VMware、Amazon Web Srevices以及OpenStack等)，也都继承了这种硬租户机制一样。
Kubernetes集群本身成了“硬租户”面临的***道坎，也因此导致大部分用户只能使用“多集群”这一新兴模式，而非“单一共享”集群。相信很多朋友都发现了，谷歌GKE Service的用户往往需要面向多个团队部署数十个Kubernetes集群，有时候每一位开发者都拥有自己的集群。这类作法***终导致了严重的Kube泛滥问题。
“这类作法***终导致了严重的Kube泛滥问题。”
通常来讲，我们使用的***小集群包含四台设备(或者虚拟机)。其中一台(或者三台，用以实现高可用性)作为Kubernetes主节点，另外三台作为Kubernetes工作节点。这不仅会带来***高的资金成本，同时也使得大部分系统资源长期处于闲置状态。
因此，我们需要以某种方式将Kubernetes转换至硬租户模式。Kubernetes社区对于这种需求有着明确的认知，也建立起专门的多租户工作组。该小组一直在努力解决这个问题，并针对各类可行模式给出了多种改进建议。
针对速度进行优化的小型虚拟机更为可行……
Kata Containers是一个开源项目与社区，致力于构建轻量***虚拟机的标准实现方案。其使用感受与执行效果与容器类似，但能够提供与虚拟机相同的工作负载隔离能力及安全优势。
Jessie建议使用Kata Containers这类虚拟机容器技术。Kata Containers将虚拟机级别的隔离机制与容器的执行及起效方式加以结合。如此一来，Kubernetes将能够为每个租户(我们假定每命名空间一个租户)提供运行在嵌套虚拟机容器(即由底层IaaS提供，运行在虚拟机之内的容器)内的一组独立Kubernetes系统服务。

image from Jessie Frazelle – Hard Multi-Tenancy in Kubernetes
这可谓是一种优雅的Kubernetes多租户问题解决方案。Jessie甚至进一步建议Kubernetes使用嵌套容器虚拟机处理运行在Kubernetes之上的工作负载(Pod)，从而大大提高资源利用率。
在这方面，我们至少还能够做出一项深层优化，即为底层IaaS或云服务供应商构建合适的虚拟机管理程序。如果其中虚拟机容器代表着由IaaS提供的***层抽象，那么我们甚至能够进一步优化资源利用率。具体来讲，我们可以将运行Kubernetes集群所需要的***虚拟机数量减少至一个(或者三个以实现高可用性)，并用以承载开放给“***用户”的Kubernetes控制平面。
资源(成本)优化型多租户机制
配合两个命名空间并运行有多款应用程序的Kubernetes集群将如下所示。

注意：同一IaaS基础设施之上还运行有其他云用户的工作负载。由于这些属于虚拟机容器，因此其拥有与常规云虚拟机相同的隔离级别，因此，它们能够以***风险运行在同一虚拟机管理程序之上。
起初，云基础设施上的部署量为零，因此***用户的成本也为零。
该***用户从云端请求Kubernetes集群，云服务供应商负责创建单一容器虚拟机(或者三个容器虚拟机以实现高可用性)以运行主Kubernetes API与系统服务。***用户可以选择在系统命名空间当中部署Pod，或者创建新的命名空间以分配面向其他用户的访问。
***用户创建两个命名空间，分别为foo与bar。Kubernetes从云端为每个命名空间的控制平面(即Kubernetes API与系统服务)请求两个虚拟机容器。***用户为各用户分配该命名空间的访问权限，从而允许这些用户各自部署一部分工作负载(Pod)，而用户自己的控制平面又进一步请求用于运行这些工作负载的虚拟机容器。
在整个执行流程当中，***用户只需要为实际消费的资源付费，云端可供用户使用的全部容量皆归云服务供应商所有。
其实这并不是什么新鲜事物……
云服务供应商们已经在努力实现上述目标。关注开源社区动态的朋友肯定已经发现了相关迹象。(更具体地讲，亚马逊希望通过Fargate达到的正是这一效果，只是并未公开宣布。)
***个迹象就是Virtual Kubelet，这款开源工具旨在模拟kubelet。其将Kubernetes与其它API相连，从而允许Kubernetes从云端的容器虚拟机调度程序处请求容器虚拟机。
其它多种新兴虚拟机容器技术中也存在着类似的迹象，包括之前提到的Kata Containers、亚马逊的Firecracker以及谷歌的gvisor等等。
总结
将正确的改进效果同Kubernetes硬租户模式相结合，大家将真正发挥Kubernetes的全部潜能。Kubernetes工作负载的全面隔离与每Pod成本消费模式将***终使Kubernetes成为工作负载运行的***选项。
对于并没有使用公有云的朋友，虽然业务体系中不存在基础设施供应商(这种情况下，基础设施将由您自行提供)，因此无法获得同样的容量消费模式，但大家仍然可以通过这种方式实现资源利用率提升与总体容量需求削减。
我们也热切希望VMware与OpenStack关注这一趋势，并为我们带来基于虚拟机管理程序的轻量级虚拟机容器技术以及理想的Virtual Kubelet实现方案。

作者：Jet 译

并购与重组是判断一个市场活跃度的重要标准，为此本文梳理了2018年全球备受关注的云计算市场的重要收购与重组，从中筛选了十个***为重要的并购，并进行逐一点评。
作者：袁绍龙来源：亿欧网

并购与重组是判断一个市场活跃度的重要标准，为此本文梳理了2018年全球备受关注的云计算市场的重要收购与重组，从中筛选了十个***为重要的并购，并进行逐一点评。
转眼间，2018年已结束。回顾2018年的云计算市场，不可谓不精彩：云计算巨头们依然保持着惊人的高速增长;传统IT厂商们也不甘于被时代所抛弃，纷纷向云计算市场发力;创新公司则依然保持着十足的活力，在各大细分领域展现出无比的创新能力。
并购与重组是判断一个市场活跃度的重要标准，从这个角度来看，2018年的云计算市场可谓是精彩戏码层出不穷。为此，大数据在线梳理了2018年全球云计算市场的重要收购与重组，从中筛选了十个***为重要的并购，并进行逐一点评。
从这十大并购中，我们对全球云计算市场变化一窥究竟，可以看到业界各大厂商纷纷加码对云计算的投资与布局，围绕开发者、数据、芯片、安全、多云、人工智能等不同角度进行收购。
千里之行始于足下，2018年的系列并购或许将对2019年甚至更远的云计算市场带来***的影响。
1、IBM 340亿美元收购Redhat
IBM宣布以340亿美元收购开源软件巨头Redhat，收购价格为每股190美元，溢价63%，并购之后Redhat将并入到IBM混合云事业部，不过将成为其中一个独立的部门。IBM希望此举来寻求业务的多元化，增加高利润产品和服务。
该收购是IBM史上***一笔收购，也是美国科技界第三大收购，堪比当年戴尔以670亿美元收购EMC。Redhat作为开源软件领域的巨头，年营收额接近30亿美元，在开源云计算软件堆栈、多云管理、混合云等领域有着全面布局。IBM CEO 罗睿兰甚至表示，收购Redhat之后，IBM将成为全球头号混合云提供商。
IBM宣布收购的同时，也强调将继续致力于推进Redhat的开放治理、开源贡献、参与开源社区和开发模型，并培育其广泛的开发者生态系统;并会继续与AWS、微软等云服务提供商保持合作伙伴关系。
点评：
多云和开源可谓是当前云计算***重要的趋势。Redhat作为世界上***成功的开源软件公司，在云计算、存储、虚拟化、中间件等方面有着全面的软件堆栈，并且在营收规模和盈利上都有着优秀表现，也有着深厚的开源社区基础。对于近年来营收持续下滑的IBM而言，并购Redhat之后，构建出更加完善的多云解决方案，以满足客户对于云计算开源产品日益增长的需求。
此外，多年以来，IBM花费了数十亿美金在支持Linux生态系统上，涉及到上百个Linux项目，包括Xen、Apache、Linux内核等。但是IBM过于商业化的形象，并没有让IBM在开源社区取得与之匹配的影响力。通过收购Redhat，无疑将***大加强IBM在开源社区的影响力，以及未来对Linux生态系统有着长远影响。
更加重要的是通过并购之后，IBM可以凭借在企业级领域深厚的咨询、服务、产品等能力，让开源商业化之路进一步完善，Redhat的丰富产品也可以借助IBM的体系获得更多客户的青睐。当然，并购也存在着包括文化差异、众多产品的市场优先级、方案整合等系列挑战，这些将是成为IBM今后面临的考验。
2、微软 75亿美元收购GitHub
微软在今年6月宣布以75亿美元收购全球***的代码托管平台GitHub。此举是微软在继斥资262亿美元收购社交平台Linkedin之后又一手笔，如果说微软收购Linkedin瞄准的是商务职场社交领域，那收购GitHub明显就是看重开发者人群。
GitHub托管软件开发项目、文档和代码，目前拥有超过8500万个代码库，有2800万开发人员在上面学习、共享与协作。GitHut深受全球广大开发者的热爱，它并且是全球开发者***重要的交流社区。有意思的是，微软现在是GitHub的***贡献者，微软已经有超过1000名员工积***地将代码提交到GitHub的代码库中。在2015年***后一轮融资中，GitHub估值达到了20亿美元。
收购之后，微软副总裁Nat Friedman将担任GitHub CEO，GitHub现任CEO Chris Wanstrath将成为微软技术研究员，向执行副总裁Scott Guthrie汇报。微软CEO Satya Nadella表示，“我们将通过直接销售和合作渠道，加快企业开发人员对GitHub的使用，并接入微软的全球云基础设施和服务。”
点评：
微软收购GitHub此举无疑将会微软Azure云服务以及开发者人群带来巨大好处，大幅提升微软在开发者人群中的影响力。事实上，微软对于GitHub的整合已经在加快。在今年的微软TechSummit上，微软***副总裁Julia Liuson就介绍了微软在开发工具平台与GitHub的集成情况，包括像Visual Studio Code等开发工具与GitHub集成，大幅提升开发效率和体验。
在开源大行其道的今天，微软对于开源的态度可谓是发生了一百八十度的大转弯，全面拥抱开源和开放已经成为微软的基本策略。正所谓是抓住开发者的心，才能抓住未来。因此，我们可以看到微软通过收购GitHub来完善对开源、开放生态的布局。可以预见，微软在未来将继续集成和完善GitHub平台，提供云端更加完善的开发和管理体验。
3、SAP 80亿美元收购Qualtrics
传统企业软件巨头SAP在今年11月宣布，以80亿美元收购总部位于犹他州的云调查和研究SaaS公司Qualtrics，是SaaS领域第三并购案。此次收购正值Qualtrics准备上市的前夕，而当时的估值大约为39-45亿美元之间。
Qualtrics是一家专注于市场研究、客户满意度和忠诚度、产品和概念测试、员工评估和网站反馈的SaaS公司。Qualtrics拥有超过9000家客户，平均每天进行超过210万次调查，2018年的营收规模预计为4亿美元，其实现了超过40%的长期增长率，***的竞争对手是SurveyMonkey。
据悉，Qualtrics在被收购之后将成为SAP云业务部门的一部分，Qualtrics的联合***人Ryan Smith将继续担任CEO，预计2019年上半年完成收购。SAPCEO Bill McDermott表示Qualtrics经验数据将完善SAP公司的数据集，SAP***终目标是拥有足够的数据接触点，为各种行业和场景创建独特的算法。
点评：
作为传统ERP企业软件巨头，SAP这两年向云转型的步伐正在加快，除了积***与云服务提供商进行SAP HANA云服务合作之外，SAP在今年在云计算领域的触角进一步延伸。收购Qualtrics从数据层面的角度来看，更像是一次内部数据和外部数据的融合与打通，SAP作为企业级软件巨头，对于企业的内部数据***了解;而Qualtrics更像是对外部用户情绪感知数据，这两部分数据日后如果能够实现融合与打通，其实有利于使用SAP软件或者服务用户能够拥有更大的数据视角。
事实上，除了Qualtrics之外，SAP在今年的云计算市场异常活跃，还巨资收购了另外一家云计算公司(下文将会详细介绍)，围绕数据触点去布局云计算的版图越来越清晰。可以说，SAP是继Oracle之后，又一个希望摆脱传统企业软件公司的角色，努力向云转型的公司。
4、Salesforce 65亿美元收购Mulesoft
Salesforce在今年3月宣布以现金加股票共计65亿美元的价格收购云服务公司Mulesoft。Mulesoft去年3月在纽交所上市，目前拥有超过1200家客户，其中45%是全球500强企业。Mulesoft近年来一直处于高速增长的阶段，去年营收实现了58%的增长，今年则预计能达到40%的增长。
Mulesoft主要提供基于云计算的企业集成服务，包括SOA集成、iPaaS平台、API管理等，用户可以在其AnyPoint平台上方便集成各种企业应用、设备和不同的数据工具，可以帮助企业业务网络获得更快的连接。Salesforce CEO Marc Benioff表示，此次合并将帮助Salesforce用户连接那些跨越不同云产品的数据，将传统企业内部的计算与公有云的数据和应用程序结合在一起。
点评：
随着企业内部应用的增多，以及多云环境的出现，企业应用集成可谓是大势所趋。从数据整合的角度来看，Mulesoft既有利于数据的整合与打通，有利于提升企业内外部的连接效率;与此同时，这种整合也有着***强的使用粘性，用户一旦使用习惯之后便不会轻易舍弃。
Salesforce收购Mulesoft无疑有利于自身SaaS产品的整合和使用，并能够获得优秀的客户群。
5、阿里巴巴全资收购中天微
今年四月，阿里巴巴宣布全资收购中天微，具体金额并未透露。不过此举意味着阿里巴巴在芯片领域的布局完成了重要一步。
杭州中天微成立于2001年，是目前中国大陆***大规模量产的自主嵌入式CPU IP核公司，致力于32位高性能低功耗嵌入式CPU研发，以芯片架构授权为核心业务的IC设计公司。目前，中天微的合作厂商已逾70家，SoC芯片累积出货已经突破5亿片。
中天微与阿里云在物联网领域有着深入的合作。阿里云在今年8月份的深圳云栖大会上表示，阿里云IoT的定位是物联网基础设施的搭建者，计划在未来5年内连接100亿台设备。中天微是阿里云***早进入IoT合作伙伴计划中的成员，在芯片领域全面推进IoT芯片通过阿里云Link Market在终端的大规模应用。同时针对AliOS Things进行深度优化，推动AliOS在IoT芯片领域的部署与应用。
点评：
芯片可谓是互联网巨头们的又一大阵地。除了中天微之外，阿里巴巴的达摩院在今年还推出了人工智能神经网络芯片Ali-NPU，阿里巴巴的芯片动作频繁。据悉，中天微在收购之后，推出了基于AliOS软硬件框架的3款“云芯片”，包括计算机视觉芯片、融合接入安全的MCU平台芯片、以及与中兴微电子合作推出的全球首款基于AliOS的***低功耗NB-IoT物联网安全芯片。
与国外AWS、Google云、微软等云计算巨头早已布局芯片领域相比，国内云服务提供商显然还有很长的路要走。这其中，阿里云是国内少的在芯片领域有着远见的公司，能够看到芯片对于云计算未来的重要性，尤其是随着人工智能、物联网等应用的兴起，芯片将会是***的基石。除了更多的支撑日渐丰富人工智能应用之外，阿里云显然也不希望在芯片上受制于人。
6、Adobe 47.5亿美元收购Marketo
Adobe公司在今年9月宣布，将以47.5亿美元收购云计算营销自动化公司Marketo。而两年前，私募股权公司Vista Equity刚以18亿美元的价格将Marketo私有化。Adobe表示，将把Marketo融入到Adobe体验云中，为不同行业和不同规模的用户提供全新的体验。
Marketo成立于2006年，是一家电子邮件营销服务公司。根据穆迪数据显示，去年该公司的收入约为3.21亿美元。据悉，收购之后，Marketo现任CEO Steve Lucas将继续管理公司，但归属于Adobe的数字体验团队。
Marketo的B2B营销应用将补充Adobe的数字营销业务，后者提供云工具以帮助创建、管理和分析广告及营销活动。Adobe数字体验部门执行副总裁、总经理Brad Rencher表示：“收购 Marketo之后，在B2C和B2B客户体验方面Adobe的***优势进一步扩大，而且还可以将Adobe Experience Cloud变成所有营销的核心。”
点评：
从***早的打印机语言Postscript，到后来的图像处理软件，Adobe一直都在探索新的业务领域。2009年，Adobe正式进入到营销云的市场，通过收购Efficient Frontier、TubeMogul、Day Software、Neolane等一系列收购，其数字营销业务迅速发展，并与微软、甲骨文、SAP和Salesforce等巨头形成直接的竞争关系。
Adobe其实向大家展示了一条新的云计算之路，并不追求大而全的业务线，即瞄准某一个细分云计算领域，通过收购等方式快速布局，并且持续做深做强，从而获得市场的强势地位。
7、SAP 24亿美元收购CallidusCloud
SAP公司在今年1月底宣布以24亿美元收购云计算公司CallidusCloud。
CallidusCloud提供基于云计算的HR、销售、现金导向(报价-现金)系统、营销和客户体验解决方案。这与SAP自己的HR和销售SaaS解决方案套件有天然的协同作用，并且对其CRM功能有所提升。
CallidusCloud公司拥有云计算lead-to-money应用套件，其中包括销售绩效管理SPM和配置报价。CallidusCloud是SAP的长期合作伙伴，而SAP也是CallidusCloud的客户，一直在内部运行其应用程序。此外，CallidusCloud连续多次入选Garnter SPM(销售绩效管理)魔力象限的***象限。
SAP希望将SAP Hybris解决方案中的所有CallidusCloud产品资产整合为SAP的云业务部门的一部分。现有的管理团队将继续领导CallidusCloud。SAP云平台将用于CallidusCloud解决方案的技术整合。SAP CEO Bill McDermott表示：“SAP正试图后台与前端连接起来，以顺应当前消费者驱动型增长趋势。我们的客户正致力于重塑销售、服务、市场营销和商业，CallidusCloud的加入***符合SAP改革前端的创新战略。而SAP也将带领CallidusCloud走向全球规模，加速其持续增长。”
点评：
CallidusCloud是基于云的报价转现金解决方案的***，其产品组合将加强现有的SAP销售解决方案。SAP一直在加快其云计算的步伐，并且试图以数据和连接的视角完成其云计算的布局，以顺应用户新的业务需求。
8、Cloudera与Hortonworks合并
今年10月，世界上***的两家大数据平台服务商Cloudera与Hortonworks宣布合并，双方希望以此共同创建一个***的数据平台，新公司的年收入或将达到7.2亿美元，并且没有***债务。据此，两家公司的总市值将达到52亿美元，Cloudera将拥有合并后公司60%的股权，而Hortonworks将持有40%的股权。
根据协议，两家将加强与公有云供应商和系统集成商的伙伴关系，增加规模和资源，提供业界***个企业级数据云，提高公有云的易用性和灵活性。曾几何时，Cloudera与Hortonworks是不共戴天的仇人，为Hadoop的发行版挣的是头破血流。
Cloudera CEO Tom Reily表示：“合并后的公司将具有更大的规模，可以更快地进行创新。”据悉，双方合并之后，除了大数据Hadoop之外，还将关注容器、物联网等领域。合并之后，Cloudera CEO 将担任合并公司的CEO。
点评：
Cloudera与Hortonworks合并的例子告诉我们，市场上试图销售开源软件商业版本或者服务的大部分公司都是举步维艰，尤其是当这个市场有大批技术能力强大的公有云服务提供商进入之后。以Hadoop为例，支持这些开源项目需要巨大的成本，但是赚钱却是十分困难，很多公司甚至都已经推出了这个市场。
可以预见，随着这次合并，将***大巩固公司在Hadoop市场上的“垄断”地位，未来一个更加统一的Hadoop版本也将问世。
不过，更加值得关注的是，Cloudera与Hortonworks合并之后如何在云计算市场发力，尤其是当三大云服务提供商(AWS、Azure、Google)都提供了强大的Hadoop/Spark云服务。在容器、机器学习等技术趋势兴起的情况下，公有云服务提供商有着更强大的整合能力，而不仅仅是单纯的大数据分析平台产品。
9、思科 23.5亿美元收购Duo Security
思科在今年8月宣布以23.5亿美元现金和假设股权收购多云安全公司Duo Security。这是继2017年，思科37亿美元收购应用管理公司App Dynamic以来***的一笔收购。
Duo Security于2010年创立，专注于基于云的多因素身份验证，为客户提供基于云的工具，以防止设备上的安全漏洞。Duo Security的客户包括中小企业到大型企业，这些客户使用其技术通过建立对其身份的信任，评估设备可信度以及促进安全的应用程序访问来验证用户的身份。并购之后，Duo Security将并入到思科的网络和安全部门。
思科CEO罗宾斯表示：Duo Security开发的技术可以跟踪“物理和多云环境中***地方的***工作负载”。
点评：
作为传统的企业网络与安全设备制造，思科近年来的收购策略也是紧跟云计算的发展趋势，从应用管理公司App Dynamic到现在的多云安全公司Duo Security，思科希望将网络与安全产品和服务全力扩展到多云环境之中，以符合多云环境的发展趋势。
除了Duo Security之外，思科今年还完成了对云计算公司BroadSoft，补强了基于云计算的呼叫和联络中心解决方案。
10、西门子7亿美元收购mendix
工业巨头西门子对于云计算也不甘寂寞，在今年8月份宣布以7亿美元收购云原生低代码应用公司mendix公司。
据悉，收购之后，mendix将成为西门子数字化工厂集团软件业务的一部分，并且将保留其自有品牌、文化，并继续保持生态系统和社区。mendix的平台也将部署于西门子其他的业务集团。
mendix于2005年在荷兰鹿特丹成立，以SaaS的方式进行销售。西门子预计，mendix将帮助加快西门子在现有的云计算、物联网和数字化企业软件方面的能力发展。

在 IM 这种讲究高并发、高消息吞吐的互联网场景下，MQ 消息中间件是个很重要的基础设施，它在 IM 系统的服务端架构中担当消息中转、消息削峰、消息交换异步化等角色。
作者：朱小厮来源：朱小厮的博客|2019-01-04 09:59 收藏 分享
在 IM 这种讲究高并发、高消息吞吐的互联网场景下，MQ 消息中间件是个很重要的基础设施，它在 IM 系统的服务端架构中担当消息中转、消息削峰、消息交换异步化等角色。

当然，MQ 消息中间件的作用远不止于此，它的价值不仅仅存在于技术上，更重要的是改变了以往同步处理消息的思路。
比如进行 IM 消息历史存储时，传统的信息系统作法可能是收到一条消息就马上同步存入数据库，这种作法在小并发量的情况下可以很好的工作，但互联网大并发环境下就是灾难。

MQ 消息中间件可以理解为一个水池，水池的这头是消息生产者，水池的那头是消息消费者，生产者和消息者无需直接对接，这将带来很多好处：业务解耦、架构分布式化等，生产者和消费者互相***透明。
但市面上的 MQ 消息中间件产品很多，作为 IM 系统中必不可少的一环，我们该如何选型?
什么是消息队列中间件
消息队列中间件(简称消息中间件)是指利用高效可靠的消息传递机制进行与平台无关的数据交流，并基于数据通信来进行分布式系统的集成。
通过提供消息传递和消息排队模型，它可以在分布式环境下提供应用解耦、弹性伸缩、冗余存储、流量削峰、异步通信、数据同步等等功能，其作为分布式系统架构中的一个重要组件，有着举足轻重的地位。

目前开源的消息中间件可谓是琳琅满目，能让大家耳熟能详的就有很多，比如 ActiveMQ、RabbitMQ、Kafka、RocketMQ、ZeroMQ 等，不管选择其中的哪一款，都会有用的不趁手的地方，毕竟不是为你量身定制的。
可能有些大厂在长期的使用过程中积累了一定的经验，加上其消息队列的使用场景也相对稳定固化，或者目前市面上的消息中间件无法满足自身需求，同时它也具备足够的精力和人力而选择自研来为自己量身打造一款消息中间件。
但是绝大多数公司还是不会选择重复造轮子，那么选择一款适合自己的消息中间件显得尤为重要。
就算是前者，那么在自研出稳定且可靠的相关产品之前也会经历这样一个选型过程。
在整体架构中引入消息中间件，势必要考虑很多因素，比如成本及收益问题，怎么样才能达到***的性价比?
虽然消息中间件种类繁多，但是各自都有各自的侧重点，选择合适自己、扬长避短无疑是***的方式。如果你对此感到无所适从，本文或许可以参考一二。
各类消息队列简述
ActiveMQ
Apache 出品的、采用 Java 语言编写的***基于 JMS1.1 规范的面向消息的中间件，为应用程序提供高效的、可扩展的、稳定的和安全的企业级消息通信。
不过由于历史原因包袱太重，目前市场份额没有后面三种消息中间件多，其***架构被命名为 Apollo，号称下一代 ActiveMQ，有兴趣的同学可自行了解。
RabbitMQ
采用 Erlang 语言实现的 AMQP 协议的消息中间件，***初起源于金融系统，用于在分布式系统中存储转发消息。
RabbitMQ 发展到今天，被越来越多的人认可，这和它在可靠性、可用性、扩展性、功能丰富等方面的***表现是分不开的。
Kafka
起初是由 LinkedIn 公司采用 Scala 语言开发的一个分布式、多分区、多副本且基于 ZooKeeper 协调的分布式消息系统，现已捐献给 Apache 基金会。
它是一种高吞吐量的分布式发布订阅消息系统，以可水平扩展和高吞吐率而被广泛使用。目前越来越多的开源分布式处理系统如 Cloudera、Apache Storm、Spark、Flink 等都支持与 Kafka 集成。
RocketMQ
是阿里开源的消息中间件，目前已经捐献给 Apache 基金会，它是由 Java 语言开发的，具备高吞吐量、高可用性、适合大规模分布式系统应用等特点，经历过双 11 的洗礼，实力不容小觑。
ZeroMQ
号称史上***快的消息队列，基于 C 语言开发。ZeroMQ 是一个消息处理队列库，可在多线程、多内核和主机之间弹性伸缩。
虽然大多数时候我们习惯将其归入消息队列家族之中，但是其和前面的几款有着本质的区别，ZeroMQ 本身就不是一个消息队列服务器，更像是一组底层网络通讯库，对原有的 Socket API 上加上一层封装而已。
目前市面上的消息中间件还有很多，比如腾讯系的 PhxQueue、CMQ、CKafka，又比如基于 Go 语言的 NSQ，有时人们也把类似 Redis 的产品也看做消息中间件的一种。
当然，它们都很优秀，但是本文篇幅限制无法穷其所有，下面会针对性地挑选 RabbitMQ 和 Kafka 两款典型的消息中间件来做分析，力求站在一个公平公正的立场来阐述消息中间件选型中的各个要点。
消息中间件选型要点
衡量一款消息中间件是否符合需求，需要从多个维度进行考察。
首要的就是功能维度，这个直接决定了你能否***程度上地实现开箱即用，进而缩短项目周期、降低成本等。
如果一款消息中间件的功能达不到想要的功能，那么就需要进行二次开发，这样会增加项目的技术难度、复杂度以及增大项目周期等。
消息中间件具体选型指标
功能维度
功能维度又可以划分成多个子维度，大致可以分为以下这些。
优先级队列
优先级队列不同于先进先出队列，优先级高的消息具备优先被消费的特权，这样可以为下游提供不同消息级别的***。
不过这个优先级也是需要有一个前提的：如果消费者的消费速度大于生产者的速度，并且消息中间件服务器(一般简单的称之为 Broker)中没有消息堆积。
那么对于发送的消息设置优先级也就没有什么实质性的意义了，因为生产者刚发送完一条消息就被消费者消费了，那么就相当于 Broker 中至多只有一条消息，对于单条消息来说优先级是没有什么意义的。
延迟队列
当你在网上购物的时候是否会遇到这样的提示：“三十分钟之内未付款，订单自动取消”，这个是延迟队列的一种典型应用场景。
延迟队列存储的是对应的延迟消息，所谓“延迟消息”是指当消息被发送以后，并不想让消费者立刻拿到消息，而是等待特定时间后，消费者才能拿到这个消息进行消费。
延迟队列一般分为两种：
基于消息的延迟，是指为每条消息设置不同的延迟时间，那么每当队列中有新消息进入的时候就会重新根据延迟时间排序，当然这也会对性能造成***大的影响。
基于队列的延迟，实际应用中大多采用这种，设置不同延迟级别的队列，比如5s、10s、30s、1min、5mins、10mins等，每个队列中消息的延迟时间都是相同的，这样免去了延迟排序所要承受的性能之苦，通过一定的扫描策略(比如定时)即可投递超时的消息。
死信队列
由于某些原因消息无法被正确投递，为了确保消息不会被无故丢弃，一般将其置于一个特殊角色的队列，这个队列称为死信队列。
与此对应的还有一个“回退队列”的概念，试想如果消费者在消费时发生了异常，那么就不会对这一次消费进行确认(Ack), 进而发生回滚消息的操作之后消息始终会放在队列的顶部，然后不断被处理和回滚，导致队列陷入死循环。
为了解决这个问题，可以为每个队列设置一个回退队列，它和死信队列都是为异常的处理提供的一种机制保障。实际情况下，回退队列的角色可以由死信队列和重试队列来扮演。
重试队列
其实可以看成是一种回退队列，具体指消费端消费消息失败时，为防止消息无故丢失而重新将消息回滚到 Broker 中。
与回退队列不同的是重试队列一般分成多个重试等级，每个重试等级一般也会设置重新投递延时，重试次数越多投递延时就越大。
举个例子：消息***次消费失败入重试队列 Q1，Q1 的重新投递延迟为 5s，在 5s 过后重新投递该消息。
如果消息再次消费失败则入重试队列 Q2，Q2 的重新投递延迟为 10s，在 10s 过后再次投递该消息。
以此类推，重试越多次重新投递的时间就越久，为此需要设置一个上限，超过投递次数就入死信队列。
重试队列与延迟队列有相同的地方，都是需要设置延迟级别，它们彼此的区别是：延迟队列动作由内部触发，重试队列动作由外部消费端触发;延迟队列作用一次，而重试队列的作用范围会向后传递。
消费模式
消费模式分为推(push)模式和拉(pull)模式：
推模式，是指由 Broker 主动推送消息至消费端，实时性较好，不过需要一定的流制机制来确保服务端推送过来的消息不会压垮消费端。
拉模式，是指消费端主动向 Broker 端请求拉取(一般是定时或者定量)消息，实时性较推模式差，但是可以根据自身的处理能力而控制拉取的消息量。
广播消费
消息一般有两种传递模式——点对点(P2P，Point-to-Point)模式和发布/订阅(Pub/Sub)模式：
对于点对点的模式而言，消息被消费以后，队列中不会再存储，所以消息消费者不可能消费到已经被消费的消息。虽然队列可以支持多个消费者，但是一条消息只会被一个消费者消费。
发布订阅模式定义了如何向一个内容节点发布和订阅消息，这个内容节点称为主题(Topic)，主题可以认为是消息传递的中介，消息发布者将消息发布到某个主题，而消息订阅者则从主题中订阅消息。
主题使得消息的订阅者与消息的发布者互相保持独立，不需要进行接触即可***消息的传递，发布/订阅模式在消息的一对多广播时采用。
RabbitMQ 是一种典型的点对点模式，而 Kafka 是一种典型的发布订阅模式。
但是 RabbitMQ 中可以通过设置交换器类型来实现发布订阅模式而达到广播消费的效果，Kafka 中也能以点对点的形式消费，你***可以把其消费组(Consumer Group)的概念看成是队列的概念。
不过对比来说，Kafka 中因为有了消息回溯功能的存在，对于广播消费的力度支持比 RabbitMQ 的要强。
消息回溯
一般消息在消费完成之后就被处理了，之后再也不能消费到该条消息。消息回溯正好相反，是指消息在消费完成之后，还能消费到之前被消费掉的消息。
对于消息而言，经常面临的问题是“消息丢失”，至于是真正由于消息中间件的缺陷丢失还是由于使用方的误用而丢失，一般很难追查。
如果消息中间件本身具备消息回溯功能的话，可以通过回溯消费复现“丢失的”消息进而查出问题的源头所在。
消息回溯的作用远不止于此，比如还有索引恢复、本地缓存重建，有些业务补偿方案也可以采用回溯的方式来实现。
消息堆积+持久化
流量削峰是消息中间件的一个***重要的功能，而这个功能其实得益于其消息堆积能力。
从某种意义上来讲，如果一个消息中间件不具备消息堆积的能力，那么就不能把它看做是一个合格的消息中间件。
消息堆积分内存式堆积和磁盘式堆积：
RabbitMQ 是典型的内存式堆积，但这并非绝对，在某些条件触发后会有换页动作来将内存中的消息换页到磁盘(换页动作会影响吞吐)，或者直接使用惰性队列来将消息直接持久化至磁盘中。
Kafka 是一种典型的磁盘式堆积，所有的消息都存储在磁盘中。
一般来说，磁盘的容量会比内存的容量要大得多，对于磁盘式的堆积其堆积能力就是整个磁盘的大小。
从另外一个角度讲，消息堆积也为消息中间件提供了冗余存储的功能。援引《纽约时报》的案例，其直接将 Kafka 用作存储系统。
消息追踪
对于分布式架构系统中的链路追踪(Trace)，大家一定不陌生。对于消息中间件，消息的链路追踪(以下简称消息追踪)同样重要，***通俗来理解，就是要知道消息从哪来，存在哪里以及发往哪里去。
基于此功能，我们可以对发送或者消费完的消息进行链路追踪服务，进而可以进行问题的快速定位与排查。
消息过滤
消息过滤是指按照既定的过滤规则为下游用户提供指定类别的消息。
就以 Kafka 而言，***可以将不同类别的消息发送至不同的 Topic 中，由此可以实现某种意义的消息过滤，或者 Kafka 还可以根据分区对同一个 Topic 中的消息进行分类。
不过，更加严格意义上的消息过滤，应该是对既定的消息采取一定的方式按照一定的过滤规则进行过滤。
同样以 Kafka 为例，可以通过客户端提供的 Consumer Interceptor 接口或者 Kafka Stream 的 Filter 功能进行消息过滤。
多租户
也可以称为多重租赁技术，是一种软件架构技术，主要用来实现多用户的环境下公用相同的系统或程序组件，并且仍可以确保各用户间数据的隔离性。
RabbitMQ 就能够支持多租户技术，每一个租户表示为一个 VHost，其本质上是一个独立的小型 RabbitMQ 服务器，又有自己独立的队列、交换器及绑定关系等，并且它拥有自己独立的权限。
VHost 就像是物理机中的虚拟机一样，它们在各个实例间提供逻辑上的分离，为不同程序安全保密地允许数据，它既能将同一个 RabbitMQ 中的众多客户区分开，又可以避免队列和交换器等命名冲突。
多协议支持
消息是信息的载体，为了让生产者和消费者都能理解所承载的信息(生产者需要知道如何构造消息，消费者需要知道如何解析消息)，它们就需要按照一种统一的格式描述消息，这种统一的格式称之为消息协议。
有效的消息一定具有某种格式，而没有格式的消息是没有意义的。
一般消息层面的协议有 AMQP、MQTT、STOMP、XMPP 等(消息领域中的 JMS 更多的是一个规范而不是一个协议)，支持的协议越多其应用范围就会越广，通用性越强。
比如 RabbitMQ 能够支持 MQTT 协议就让其在物联网应用中获得一席之地。还有的消息中间件是基于其本身的私有协议运转的，典型的如 Kafka。
跨语言支持
对很多公司而言，其技术栈体系中会有多种编程语言，如 C/C++、Java、Go、PHP 等，消息中间件本身具备应用解耦的特性，如果能够进一步的支持多客户端语言，那么就可以将此特性的效能扩大。
跨语言的支持力度也从侧面反映出一个消息中间件的流行程度。
流量控制
针对的是发送方和接收方速度不匹配的问题，提供一种速度匹配服务抑制发送速率使接收方应用程序的读取速率与之相适应。通常的流控方法有 Stop-and-Wait、滑动窗口以及令牌桶等。
消息顺序性
顾名思义，是指***消息有序。这个功能有个很常见的应用场景就是 CDC(Change Data Chapture)。
以 MySQL 为例，如果其传输的 Binlog 的顺序出错，比如原本是先对一条数据加 1，然后再乘以 2，发送错序之后就变成了先乘以 2 后加 1，造成数据不一致。
安全机制
在 Kafka 0.9 版本之后就开始增加了身份认证和权限控制两种安全机制：
身份认证，是指客户端与服务端连接进行身份认证，包括客户端与 Broker 之间、Broker 与 Broker 之间、Broker 与 ZooKeeper 之间的连接认证，目前支持 SSL、SASL 等认证机制。
权限控制，是指对客户端的读写操作进行权限控制，包括对消息或 Kafka 集群操作权限控制。权限控制是可插拔的，并支持与外部的授权服务进行集成。
对于 RabbitMQ 而言，其同样提供身份认证(TLS/SSL、SASL)和权限控制(读写操作)的安全机制。
消息幂等性
确保消息在生产者和消费者之间进行传输，一般有三种传输保障(Delivery Guarantee)：
At most once，至多一次，消息可能丢失，但绝不会重复传输。
At least once，至少一次，消息绝不会丢，但是可能会重复。
Exactly once，精确一次，每条消息肯定会被传输一次且仅一次。
对于大多数消息中间件而言，一般只提供 At most once 和 At least once 两种传输保障，对于第三种一般很难做到，由此消息幂等性也很难***。
Kafka 自 0.11 版本开始引入了幂等性和事务，Kafka 的幂等性是指单个生产者对于单分区单会话的幂等。
而事务可以***原子性地写入到多个分区，即写入到多个分区的消息要么全部成功，要么全部回滚，这两个功能加起来可以让 Kafka 具备 EOS(Exactly Once Semantic)的能力。
不过如果要考虑全局的幂等，还需要从上下游方面综合考虑，即关联业务层面，幂等处理本身也是业务层面所需要考虑的重要议题。
以下游消费者层面为例，有可能消费者消费完一条消息之后没有来得及确认消息就发生异常，等到恢复之后又得重新消费原来消费过的那条消息，那么这种类型的消息幂等是无法由消息中间件层面来***的。
如果要***全局的幂等，需要引入更多的外部资源来***，比如以订单号作为***性标识，并且在下游设置一个去重表。
事务性消息
事务本身是一个并不陌生的词汇，事务是由事务开始(Begin Transaction)和事务结束(End Transaction)之间执行的全体操作组成。
支持事务的消息中间件并不在少数，Kafka 和 RabbitMQ 都支持，不过此两者的事务是指生产者发生消息的事务，要么发送成功，要么发送失败。
消息中间件可以作为用来实现分布式事务的一种手段，但其本身并不提供全局分布式事务的功能。
下表是对 Kafka 与 RabbitMQ 功能的总结性对比及补充说明：

性能
功能维度是消息中间件选型中的一个重要的参考维度，但这并不是***的维度，有时候性能比功能还要重要，况且性能和功能很多时候是相悖的，鱼和熊掌不可兼得。
Kafka 在开启幂等、事务功能的时候会使其性能降低;RabbitMQ 在开启 rabbitmq_tracing 插件的时候也会***大影响其性能。
性能指什么?
消息中间件的性能一般是指其吞吐量。虽然从功能维度上来说，RabbitMQ 的优势要大于 Kafka，但是 Kafka 的吞吐量要比 RabbitMQ 高出 1 至 2 个数量级。
一般 RabbitMQ 的单机 QPS 在万级别之内，而 Kafka 的单机 QPS 可以维持在十万级别，甚至可以达到百万级。
注明：消息中间件的吞吐量始终会受到硬件层面的限制。就以网卡带宽为例，如果单机单网卡的带宽为 1Gbps，如果要达到百万级的吞吐，那么消息体大小不得超过(1Gb/8)/100W，即约等于 134B。
换句话说如果消息体大小超过 134B，那么就不可能达到百万级别的吞吐。这种计算方式同样可以适用于内存和磁盘。
性能的指标是什么?
时延作为性能维度的一个重要指标，却往往在消息中间件领域被忽视，因为一般使用消息中间件的场景对时效性的要求并不是很高，如果要求时效性***可以采用 RPC 的方式实现。
消息中间件具备消息堆积的能力，消息堆积越大也就意味着端到端的时延也就越长，与此同时延时队列也是某些消息中间件的一大特色。那么为什么还要关注消息中间件的时延问题呢?
消息中间件能够解耦系统，对于一个时延较低的消息中间件而言，它可以让上游生产者发送消息之后可以迅速的返回，也可以让消费者更加快速的获取到消息，在没有堆积的情况下，可以让整体上下游的应用之间的级联动作更加高效。
虽然不建议在时效性很高的场景下使用消息中间件，但是如果所使用的消息中间件的时延方面比较优秀，那么对于整体系统的性能将会是一个不小的提升。
可靠性+可用性
消息丢失是使用消息中间件时所不得不面对的一个痛点，其背后消息可靠性也是衡量消息中间件好坏的一个关键因素。尤其是在金融支付领域，消息可靠性尤为重要。
然而说到可靠性必然要说到可用性，注意这两者之间的区别：
消息中间件的可靠性是指对消息不丢失的保障程度。
而消息中间件的可用性是指无故障运行的时间百分比，通常用几个 9 来衡量。
从狭义的角度来说，分布式系统架构是一致性协议理论的应用实现，对于消息可靠性和可用性而言也可以追溯到消息中间件背后的一致性协议：
对于 Kafka 而言，其采用的是类似 PacificA 的一致性协议，通过 ISR(In-Sync-Replica)来***多副本之间的同步，并且支持强一致性语义(通过 Acks 实现)。
对应的 RabbitMQ 是通过镜像环形队列实现多副本及强一致性语义的。
多副本可以***在 Master 节点宕机异常之后可以提升 Slave 作为新的 Master 而继续提供服务来保障可用性。
Kafka 设计之初是为日志处理而生，给人们留下了数据可靠性要求不高的不良印象，但是随着版本的升级优化，其可靠性得到***大的增强，详细可以参考 KIP101。
就目前而言，在金融支付领域使用 RabbitMQ 居多，而在日志处理、大数据等方面 Kafka 使用居多，随着 RabbitMQ 性能的不断提升和 Kafka 可靠性的进一步增强，相信彼此都能在以前不擅长的领域分得一杯羹。
同步刷盘是增强一个组件可靠性的有效方式，消息中间件也不例外，Kafka 和 RabbitMQ 都可以支持同步刷盘。
但是笔者对同步刷盘有一定的疑问：绝大多数情景下，一个组件的可靠性不应该由同步刷盘这种***其损耗性能的操作来保障，而是采用多副本的机制来***。
这里还要提及的一个方面是扩展能力，这里我狭隘地将此归纳到可用性这一维度，消息中间件的扩展能力能够增强其可用能力及范围，比如前面提到的 RabbitMQ 支持多种消息协议，这个就是基于其插件化的扩展实现。
还有从集群部署上来讲，归功于 Kafka 的水平扩展能力，其基本上可以达到线性容量提升的水平，在 LinkedIn 实践介绍中就提及了有部署超过千台设备的 Kafka 集群。
运维管理
在消息中间件的使用过程中难免会出现各式各样的异常情况，有客户端的，也有服务端的，那么怎样及时有效的进行监测及修复?
业务线流量有峰值有低谷，尤其是电商领域，那么怎样进行有效的容量评估，尤其是大促期间?脚踢电源、网线被挖等事件层出不穷，如何有效的做好异地多活?
这些都离不开消息中间件的衍生产品——运维管理。运维管理也可以进行进一步的细分，比如申请、审核、监控、告警、管理、容灾、部署等。
申请、审核很好理解，在源头对资源进行管控，既可以有效校正应用方的使用规范，配合监控也可以做好流量统计与流量评估工作。
一般申请、审核与公司内部系统交融性较大，不适合使用开源类的产品。
监控、告警也比较好理解，对消息中间件的使用进行全方位的监控，既可以为系统提供基准数据，也可以在检测到异常的情况配合告警，以便运维、开发人员的迅速介入。
除了一般的监控项(比如硬件、GC 等)之外，消息中间件还需要关注端到端时延、消息审计、消息堆积等方面：
对于 RabbitMQ 而言，***正统的监控管理工具莫过于 rabbitmq_management 插件了，但是社区内还有 AppDynamics、Collectd、DataDog、Ganglia、Munin、Nagios、New Relic、Prometheus、Zenoss 等多种优秀的产品。
Kafka 在此方面也毫不逊色，比如：Kafka Manager、Kafka Monitor、Kafka Offset Monitor、Burrow、Chaperone、Confluent Control Center 等产品，尤其是 Cruise 还可以提供自动化运维的功能。
不管是扩容、降级、版本升级、集群节点部署、还是故障处理都离不开管理工具的应用，一个配套完备的管理工具集可以在遇到变更时做到事半功倍。
故障可大可小，一般是一些应用异常，也可以是机器掉电、网络异常、磁盘损坏等单机故障，这些故障单机房内的多副本足以应付。
如果是机房故障就要涉及异地容灾了，关键点在于如何有效的进行数据复制，Kafka 可以参考 MirrorMarker、uReplicator 等产品，而 RabbitMQ 可以参考 Federation 和 Shovel。
社区力度及生态发展
对于目前流行的编程语言而言，如 Java、Python，如果你在使用过程中遇到了一些异常，基本上可以通过搜索引擎的帮助来得到解决，因为一个产品用的人越多，踩过的坑也就越多，对应的解决方案也就越多。
消息中间件也同样适用，如果你选择了一种“生僻”的消息中间件，可能在某些方面运用的得心应手，但是版本更新缓慢、遇到棘手问题也难以得到社区的支持而越陷越深。
相反如果你选择了一种“流行”的消息中间件，其更新力度大，不仅可以迅速的弥补之前的不足，而且也能顺应技术的快速发展来变更一些新的功能，这样可以让你也“站在巨人的肩膀上”。
在运维管理维度我们提及了 Kafka 和 RabbitMQ 都有一系列开源的监控管理产品，这些正是得益于其社区及生态的迅猛发展。
消息中间件选型误区总结
选型误区
在进行消息中间件选型之前可以先问自己一个问题：是否真的需要一个消息中间件?
在搞清楚这个问题之后，还可以继续问自己一个问题：是否需要自己维护一套消息中间件?
很多初创型公司为了节省成本会选择直接购买消息中间件有关的云服务，自己只需要关注收发消息即可，其余的都可以外包出去。
很多人面对消息中间件有一种自研的冲动，你***可以对 Java 中的 ArrayBlockingQueue 做一个简单的封装，你也可以基于文件、数据库、Redis 等底层存储封装而形成一个消息中间件。
消息中间件做为一个基础组件并没有想象中的那么简单，其背后还需要配套的管理运维整个生态的产品集。
自研还会有交接问题，如果文档不齐全、运作不规范将会带给新人噩梦般的体验。
是否真的有自研的必要?如果不是 KPI 的压迫可以先考虑下面这两个问题：
目前市面上的消息中间件是否都真的无法满足目前的业务需求?
团队是否有足够的能力、人力、财力、精力来支持自研?
很多人在做消息中间件选型时会参考网络上的很多对比类的文章，但是其专业性、严谨性、以及其政治立场问题都有待考证，需要带着怀疑的态度去审视这些文章。
比如有些文章会在没有***限定条件及场景的情况下直接定义某款消息中间件***。
还有些文章没有指明消息中间件版本及测试环境就来做功能和性能对比分析，诸如此类的文章都可以唾弃之。
消息中间件犹如小马过河，选择合适的才***重要。这需要贴合自身的业务需求，技术服务于业务，大体上可以根据上一节所提及的功能、性能等 6 个维度来一一进行筛选。更深层次的抉择在于你能否掌握其魂。
笔者鄙见：RabbitMQ 在于 Routing，而 Kafka 在于 Streaming，了解其根本对于自己能够对症下药选择到合适的消息中间件尤为重要。
消息中间件选型切忌一味的追求性能或者功能，性能可以优化，功能可以二次开发。
如果要在功能和性能方面做一个抉择的话，那么***性能，因为总体上来说性能优化的空间没有功能扩展的空间大。然而看长期发展，生态又比性能以及功能都要重要。
可靠性误区
很多时候，可靠性方面也容易存在一个误区：想要找到一个产品来***消息的绝对可靠，很不幸的是这世界上没有绝对的东西，只能说尽量趋于***。
想要尽可能的保障消息的可靠性也并非单单只靠消息中间件本身，还要依赖于上下游，需要从生产端、服务端和消费端这 3 个维度去努力***。
消息中间件选型还有一个考量标准就是尽量贴合团队自身的技术栈体系，虽然说没有蹩脚的消息中间件，只有蹩脚的程序员，但是让一个 C 栈的团队去深挖 PhxQueue 总比去深挖 Scala 编写的 Kafka 要容易的多。
消息中间件大道至简：一发一存一消费，没有***的消息中间件，只有***合适的消息中间件。

随着大数据这个概念的兴起以及真实需求在各个行业的落地，很多人都热衷于讨论分布式数据库，今天就这个话题，主要分为三部分：***部分讲一下分布式数据库的过去和现状，希望大家能对这个领域有一个全面的了解;讲一下分布式数据库未来可能的趋势。
一、分布式数据库的历史和现状

1、从单机数据库说起
关系型数据库起源自1970年代，其***基本的功能有两个：
把数据存下来；
满足用户对数据的计算需求。
***点是***基本的要求，如果一个数据库没办法把数据安全完整存下来，那么后续的***功能都没有意义。当满足***点后，用户紧接着就会要求能够使用数据，可能是简单的查询，比如按照某个Key来查找Value;也可能是复杂的查询，比如要对数据做复杂的聚合操作、连表操作、分组操作。往往第二点是一个比***点更难满足的需求。
在数据库发展早期阶段，这两个需求其实不难满足，比如有很多优秀的商业数据库产品，如Oracle/DB2。在1990年之后，出现了开源数据库MySQL和PostgreSQL。这些数据库不断地提升单机实例性能，再加上遵循摩尔定律的硬件提升速度，往往能够很好地支撑业务发展。
接下来，随着互联网的不断普及特别是移动互联网的兴起，数据规模爆炸式增长，而硬件这些年的进步速度却在逐渐减慢，人们也在担心摩尔定律会失效。在此消彼长的情况下，单机数据库越来越难以满足用户需求，即使是将数据保存下来这个***基本的需求。
2、分布式数据库
所以2005年左右，人们开始探索分布式数据库，带起了NoSQL这波浪潮。这些数据库解决的首要问题是单机上无法保存全部数据，其中以HBase/Cassadra/MongoDB为代表。为了实现容量的水平扩展，这些数据库往往要放弃事务，或者是只提供简单的KV接口。存储模型的简化为存储系统的开发带来了便利，但是降低了对业务的支撑。
(1)NoSQL的进击
HBase是其中的典型代表。HBase是Hadoop生态中的重要产品，Google BigTable的开源实现，所以这里先说一下BigTable。
BigTable是Google内部使用的分布式数据库，构建在GFS的基础上，弥补了分布式文件系统对于小对象的插入、更新、随机读请求的缺陷。HBase也按照这个架构实现，底层基于HDFS。HBase本身并不实际存储数据，持久化的日志和SST file存储在HDFS上，Region Server通过 MemTable 提供快速的查询，写入都是先写日志，后台进行Compact，将随机写转换为顺序写。数据通过 Region 在逻辑上进行分割，负载均衡通过调节各个Region Server负责的Region区间实现，Region在持续写入后，会进行分裂，然后被负载均衡策略调度到多个Region Server上。
前面提到了，HBase本身并不存储数据，这里的Region仅是逻辑上的概念，数据还是以文件的形式存储在HDFS上，HBase并不关心副本个数、位置以及水平扩展问题，这些都依赖于HDFS实现。和BigTable一样，HBase提供行级的一致性，从CAP理论的角度来看，它是一个CP的系统，并且没有更进一步提供 ACID 的跨行事务，也是很遗憾。
HBase的优势在于通过扩展Region Server可以几乎线性提升系统的吞吐，及HDFS本身就具有的水平扩展能力，且整个系统成熟稳定。但HBase依然有一些不足。首先，Hadoop使用Java开发，GC延迟是一个无法避免问题，这对系统的延迟造成一些影响。另外，由于HBase本身并不存储数据，和HDFS之间的交互会多一层性能损耗。第三，HBase和BigTable一样，并不支持跨行事务，所以在Google内部有团队开发了MegaStore、Percolator这些基于BigTable的事务层。Jeff Dean承认很后悔没有在BigTable中加入跨行事务，这也是Spanner出现的一个原因。
(2)RDMS的救赎
除了NoSQL之外，RDMS系统也做了不少努力来适应业务的变化，也就是关系型数据库的中间件和分库分表方案。做一款中间件需要考虑很多，比如解析 SQL，解析出ShardKey，然后根据ShardKey分发请求，再合并结果。另外在中间件这层还需要维护Session及事务状态，而且大多数方案并不支持跨shard的事务，这就不可避免地导致了业务使用起来会比较麻烦，需要自己维护事务状态。此外，还有动态的扩容缩容和自动的故障恢复，在集群规模越来越大的情况下，运维和DDL的复杂度是指数级上升。
国内开发者在这个领域有过很多的著名的项目，比如阿里的Cobar、TDDL，后来社区基于Cobar改进的MyCAT，360开源的Atlas等，都属于这一类中间件产品。在中间件这个方案上有一个知名的开源项目是Youtube的Vitess，这是一个集大成的中间件产品，内置了热数据缓存、水平动态分片、读写分离等，但这也造成了整个项目***复杂。
另外一个值得一提的是PostgreSQL XC这个项目，其整体的架构有点像早期版本的OceanBase，由一个***节点来处理协调分布式事务，数据分散在各个存储节点上，应该是目前PG 社区***的分布式扩展方案，不少人在基于这个项目做自己的系统。
3、NewSQL的发展
2012~2013年Google 相继发表了Spanner和F1两套系统的论文，让业界***次看到了关系模型和NoSQL的扩展性在一个大规模生产系统上融合的可能性。 Spanner 通过使用硬件设备(GPS时钟+原子钟)巧妙地解决时钟同步的问题，而在分布式系统里，时钟正是***让人头痛的问题。Spanner的强大之处在于即使两个数据中心隔得***远，也能***通过TrueTime API获取的时间误差在一个很小的范围内(10ms)，并且不需要通讯。Spanner的底层仍然基于分布式文件系统，不过论文里也说是可以未来优化的点。
Google的内部的数据库存储业务，大多是3~5副本，重要的数据需要7副本，且这些副本遍布全球各大洲的数据中心，由于普遍使用了Paxos，延迟是可以缩短到一个可以接受的范围(写入延迟100ms以上)，另外由Paxos带来的Auto-Failover能力，更是让整个集群即使数据中心瘫痪，业务层都是透明无感知的。F1是构建在Spanner之上，对外提供了SQL接口，F1是一个分布式MPP SQL层，其本身并不存储数据，而是将客户端的SQL翻译成对KV的操作，调用Spanner来完成请求。
Spanner和F1的出现标志着***个NewSQL在生产环境中提供服务，将下面几个功能在一套系统中提供：
SQL支持
ACID事务
水平扩展
Auto Failover
多机房异地容灾
正因为具备如此多的诱人特性，在Google内部，大量的业务已经从原来的 BigTable切换到Spanner之上。相信这对业界的思路会有巨大的影响，就像当年的Hadoop一样，Google的基础软件的技术趋势是走在社区前面的。
Spanner/F1论文引起了社区的广泛的关注，很快开始出现了追随者。***个团队是CockroachLabs做的CockroachDB。CockroachDB的设计和Spanner很像，但是没有选择TrueTime API ，而是使用HLC(Hybrid logical clock)，也就是NTP +逻辑时钟来代替TrueTime时间戳，另外CockroachDB选用Raft做数据复制协议，底层存储落地在RocksDB中，对外的接口选择了PG协议。
CockroachDB的技术选型比较激进，比如依赖了HLC来做事务，时间戳的精确度并没有办法做到10ms内的延迟，所以Commit Wait需要用户自己指定，其选择取决于用户的NTP服务时钟误差，这点对于用户来说***不友好。当然 CockroachDB的这些技术选择也带来了很好的易用性，所有逻辑都在一个组件中，部署***简单，这个是***大的优点。
另一个追随者就是我们做的TiDB。这个项目已经开发了两年时间，当然在开始动手前我们也准备了很长时间。接下来我会介绍一下这个项目。
二、TiDB的架构和***近进展
TiDB本质上是一个更加正统的Spanner和F1实现，并不CockroachDB那样选择将SQL和KV融合，而是像Spanner和F1一样选择分离。下面是TiDB的架构图：

这样分层的思想也是贯穿整个TiDB项目始终的，对于测试，滚动升级以及各层的复杂度控制会比较有优势，另外TiDB选择了MySQL协议和语法的兼容，MySQL社区的ORM框架、运维工具，直接可以应用在TiDB上，另外和 Spanner一样，TiDB是一个无状态的MPP SQL Layer，整个系统的底层是依赖 TiKV 来提供分布式存储和分布式事务的支持，TiKV的分布式事务模型采用的是Google Percolator的模型，但是在此之上做了很多优化，Percolator的优点是去中心化程度***高，整个继续不需要一个独立的事务管理模块，事务提交状态这些信息其实是均匀分散在系统的各个key的meta中，整个模型***依赖的是一个授时服务器，在我们的系统上，***限情况这个授时服务器每秒能分配 400w以上个单调递增的时间戳，大多数情况基本够用了(毕竟有Google量级的场景并不多见)，同时在TiKV中，这个授时服务本身是高可用的，也不存在单点故障的问题。

上面是TiKV的架构图。TiKV和CockroachDB一样也是选择了Raft作为整个数据库的基础，不一样的是，TiKV整体采用Rust语言开发，作为一个没有GC和 Runtime的语言，在性能上可以挖掘的***会更大。不同TiKV实例上的多个副本一起构成了一个Raft Group，PD负责对副本的位置进行调度，通过配置调度策略，可以***一个Raft Group的多个副本不会保存在同一台机器/机架/机房中。
除了核心的TiDB、TiKV之外，我们还提供了不少易用的工具，便于用户做数据迁移和备份。比如我们提供的Syncer，不但能将单个MySQL实例中的数据同步到TiDB，还能将多个MySQL实例中的数据汇总到一个TiDB集群中，甚至是将已经分库分表的数据再合库合表。这样数据的同步方式更加灵活好用。
TiDB目前即将发布RC3版本，预计六月份能够发布GA版本。在即将到来的 RC3版本中，对MySQL兼容性、SQL优化器、系统稳定性、性能做了大量的工作。对于OLTP场景，重点优化写入性能。另外提供了权限管理功能，用户可以按照MySQL的权限管理方式控制数据访问权限。对于OLAP场景，也对优化器做了大量的工作，包括更多语句的优化、支持SortMergeJoin算子、IndexLookupJoin算子。另外对内存使用也做了大量的优化，一些场景下，内存使用下降75%。
除了TiDB本身的优化之外，我们还在做一个新的工程，名字叫TiSpark。简单来讲，就是让Spark更好地接入TiDB。现在其实Spark已经可以通过JDBC接口读取TiDB中的数据，但是这里有两个问题：1. 只能通过单个TiDB节点读取数据且数据需要从TiKV中经过 TiDB 中转。2. 不能和Spark的优化器相结合，我们期望能和Spark的优化器整合，将Filter、聚合能通过TiKV的分布式计算能力提速。这个项目已经开始开发，预计近期开源，五月份就能有***个版本。
三、分布式数据库的未来趋势
关于未来，我觉得未来的数据库会有几个趋势，也是TiDB项目追求的目标：
1、数据库会随着业务云化，未来***的业务都会跑在云端，不管是私有云或者公有云，运维团队接触的可能再也不是真实的物理机，而是一个个隔离的容器或者「计算资源」，这对数据库也是一个挑战，因为数据库天生就是有状态的，数据总是要存储在物理的磁盘上，而数据移动的代价比移动容器的代价可能大很多。
2、多租户技术会成为标配，一个大数据库承载***的业务，数据在底层打通，上层通过权限，容器等技术进行隔离，但是数据的打通和扩展会变得异常简单，结合***点提到的云化，业务层可以再也不用关心物理机的容量和拓扑，只需要认为底层是一个无穷大的数据库平台即可，不用再担心单机容量和负载均衡等问题。
3、OLAP和OLTP业务会融合，用户将数据存储进去后，需要比较方便高效的方式访问这块数据，但是OLTP和OLAP在SQL优化器/执行器这层的实现一定是千差万别的。以往的实现中，用户往往是通过ETL工具将数据从OLTP数据库同步到OLAP数据库，这一方面造成了资源的浪费，另一方面也降低了OLAP的实时性。对于用户而言，如果能使用同一套标准的语法和规则来进行数据的读写和分析，会有更好的体验。
4、在未来分布式数据库系统上，主从日志同步这样落后的备份方式会被Multi-Paxos / Raft这样更强的分布式一致性算法替代，人工的数据库运维在管理大规模数据库集群时是不可能的，所有的故障恢复和高可用都将是高度自动化的

 

使用 Active Backup Business 备份套件（以下简称 ABB ），就能享有备份一体机，集中备份 Winodws PC 和服务器整机、文件服务器、虚拟机、公有云的数据与服务，企业不需要费心管理多套平台。更重要的是，Active Backup 无需购买许可证，无论备份多少设备都不需要再额外付费。

传统中小企业的烦脑 ： 无法集中备份企业的PC、服务器、虚拟机，还需要额外购买备份软件，且不同备份软件还原方式又不一样。

成本高、效率低、占用空间容量大，而且员工众多，部署、更新备份任务难上加难。

点击下方链接查看 ABB 完整介绍↓↓↓

节省50%的空间！群晖企业级备份方案如何又稳又省？

对于大型企业的运维人员 ABB 不仅可以在同一界面统一管理，批量为员工部署电脑备份。并且 ABB 在运行中无法停止备份任务，可以有效防止员工误操作或有意删除电脑中重要的公司数据。

心动了没有，让我们跟着视频看一下如何进行操作的吧

↓↓↓

（请在 WiFi 环境下观看）

晕视频的小伙伴，可以看下面的图文教程

1

备份设置

点击下方链接查看晖姑娘之前发的备份图文教程↓↓↓

新技能Get，PC整机快速备份和还原靠谱攻略

2

还原设置-祼机恢复

演示创建 USB 媒体，并用它来恢复 Windows 系统

数据保护解决方案提供商：为企业级用户提供云计算环境下的数据备份、恢复、迁移、灾难恢复演练等产品与解决方案。（容灾备份解决方案提供商）

—————————————————————————————————

 

IT解决方案：

文件共享、私有云盘、企业网盘  解决方案

存储雷电MAS/DAS /SAN/JBOD/IPSAN ISCSI 解决方案

企业级存储 解决方案

备份 容灾 数据保护 解决方案

防勒索病毒解决方案

NAS 应用场景：***解决文件共享/文件分享问题，替代传统文件服务器

NAS网络存储 文件NAS存储 PC备份 服务器备份 数据库备份

磁带库 灾备 灾难备份 不同 备策略建立独立的备份作业， 文件备份 系统备份 数据库备份 虚机备份

非结构化数据的备份

群晖备份一体机 适用于的企级备份软件有：

（acronis 安克诺斯 /veeam卫盟/veritas华睿泰/commvault 慷孚沃德 /arcserver )

PHD virtual , Nakivo, IBM spectrum protect , (TSM) HP data protector

DELL  EMC Networker  RecoverPoint Quest  veritas system recovery 18

虚拟数据保护方案：RTO 小于2分钟

虚拟机备份解决方案：无代理备份方案、oVirt 备份方案，Ovirt虚拟化备份，

VMware vSphere 备份方案、Citrix XenServer备份方案、RedHat RHV备份方案、、Ovirt备份方案、、H3C CAS备份方案、、Openstack备份方案、、华为 FusionSphere备份方案、、中科睿光 SVM备份方案、、深信服 HCI备份方案、、云宏CNware备份方案、、浪潮 InCloud Sphere备份方案、、中标麒麟***服务器虚拟化备份方案、、噢易服务器虚拟化备份方案、。

兼容国内备份软件：联鼎，精容数安，鼎甲，火星仓，合力记易UPM，浪擎，爱数 云祺 盛思睿

西南NAS存储总分销：威联通 qnap, 色卡司thecus,infotrend普安, 华芸asustor qsan, 海康hikvision IPsan ，大华 dahua IPsan铁威马TerraMaster，Freenas,  EMC，netapp,

NAS专用硬盘：  seagate 希捷 酷狼ironwolf ，锡捷seagateironwolf 酷狼pro

WD westdigital 红盘

黑群晖无法升级，易丢失数据，建议用白群晖，黑群晖洗白

产品：国行原装***, Synology群晖科技

synology partner：

深圳市凯洛蜜贸易有限公司

深圳国亿国际贸易有限公司（深圳国亿国际)

世平伟业国际贸易（上海）有限公司（上海世平伟业)

群晖：synology inc , 群晖科技

服务区域：四川群晖 成都群晖 西藏群晖  重庆群晖贵州群晖 贵阳群晖 云南群晖  昆明群晖

NAS品类：存储服务器，NAS网络存储服务器，群晖NAS网络存储，synology nas  ,网络附加存储, nas存储器, nas服务器，企业级网络存储器，网络存储器，NAS云存储，网络存储池

私有云存储

群晖配件：群晖钥匙， 群晖硬盘钥匙，群晖硬盘托架钥匙， 群晖网卡， 群晖万兆网卡，  群晖内存， 群晖电源， 群晖主板

群晖售后：群晖客服、群晖客服电话

水货保修，水货维修，亚马逊购买 海外购机保修，美亚群晖群晖

 

群晖技术支持电话 群晖nas售后客服电话 群晖售后电话 群晖存储盘客服电话

群晖售后电话400 群晖售后服务电话 群晖nas客服电话 群晖nas售后电话

维修：群晖保修保内保外维修  群晖保修 群晖维修，亚马逊海淘的群晖保修

港版群晖维修

群晖数据恢复：  服务器数据恢复 raid数据恢复  nas数据恢复   希捷数据恢复  西数硬盘恢复  seagate 数据恢复  WD数据恢复 群晖硬盘数据恢复

代理体系：synology群晖全国***、synology群晖国代，synology群晖***，synology群晖总分销商、synology群晖授权经销商、synology群晖官方代理商）方案适用机型：

19-系列

DS1219+ ，UC300 RackStation

18-系列: FS1018、RS3618xs、DS3018xs、RS2818RP+、RS2418(RP)+、RS818(RP)+、DS918+、DS718+、DS418、DS418play、DS218+、DS218play、DS418j、DS218、DS218j、DS118、NVR1218；

17-系列: FS3017、FS2017、RS18017xs+、RS4017xs+、RS3617xs+、RS3617RPxs、RS3617xs、RS217、DS3617xs、DS1817+、DS1517+、DS1817、DS1517、扩展柜：417sas、RX1217sas、RX1217、DX517；

16-系列：RS18016xs+、RS2416RP+、RS2416+、DS916+、DS716+II、DS716+、RS816、DS416、DS416play、DS416slim、DS416j、DS216+II、DS216+、DS216play、DS216、DS216j、DS216se、DS116、NVR216、群晖扩展柜 RX1216sas；

15-系列: RC18015xs+、DS3615xs、DS2015xs、RS815(RP)+、DS2415+、DS1515+、DS415+、RS815、DS1515、DS715、DS415play、DS215+、DS215j、DS115、DS115j、DS1815+；

14-系列: RS3614xs+、RS2414(RP)+、RS814(RP)+、RS814、DS414、DS214+、DS214play、RS214、DS414j、DS414slim、DS214、DS214se、DS114、EDS14；

13-系列: RS10613xs+、RS3413xs+、DS2413+、DS1813+、DS1513+、DS713+、DS413、DS213+、DS413j、DS413j、DS213、DS213j、DS213air；

12-系列: DS112、DS112j、DS112+、DS212、DS212j、DS212+、DS412+、DS712+、DS1512+、DS1812+、DS3612xs、RS212、RS812、RS812+、RS812RP+、RS2212+、RS2212RP+、RS3412RPxs、RS412xs、RS412RPxs；

11-系列

DS1511+、ds2411+， RS3411xs、RS3411RPxs、DS3611xs，扩展箱 DX1211、rx1211rp+, rs411

RS2211(RP)+，RS3411(RP)xs，RX1211(RP)

10-系列：DS1010+，DS710+，RS810(RP)+， ,rx410

09-系列

ds509+ ，rs409,rs409RP+,rx4

早期系列：ds-101

群晖配件：

M2D17 ，synology 群晖监控许可证

成都科汇科技有限公司 — 专业数据备份服务商

无论您的IT架构是 本地化、云端、还是混和云 都能提供一站式数据备份方案。

京东群晖synology  天猫群晖 线下代理售后维修服务站

四川成都群晖官方授权核心代理商（企业级服务商）

四川成都群晖synology解决方案中心

四川成都群晖synology体验中心

四川成都synology群晖线下实体店

四川成都群晖synology售后维修中心

四川成都群晖synology官方授权专卖店

成都科汇科技有限公司

地址：成都市人民南路四段1号时代数码大厦18F

群晖电话：400-028-1235（群晖400）

QQ:     2231749852

手机：138 8074 7621（微信同号）

微信公众号：群晖Synology技术中心

随着云计算、大数据以及移动互联网技术的快速普及，互联网企业对于数据的应用越发得心应手，而更多的传统企业也发觉数字背后所隐藏的故事令人心醉，以此为目的，数字化转型成为近年来企业变革的重要方向之一，而IT企业作为数字化转型应用落地的排头兵，正在为更多的企业转型赋能。

Riverbed大中华区总经理袁志陵

数字化时代的来临，所有的企业都需要积***应对，Riverbed大中华区总经理袁志陵表示，数字化已经是Riverbed***为看重的市场，在解决方案中，无论是***的SD-WAN产品方案，还是应用性能管理可视化更多的服务于为企业数字化赋能这一目标，而Riverbed将持续的进行创新，并努力与合作伙伴一起做到更好。

技术创新无止境

对于Riverbed而言，客户需求正在发生改变，终端用户的基础设施的边界越来越模糊，传统的架构的网络模式正在受到挑战，特别是由于5G技术的逐步成熟，客户对于业务应用的落地将更多的趋向于采用动态的、灵活的以及分布式的方式实现业务模式的搭建。

Riverbed大中华区技术总监张晓和

Riverbed大中华区技术总监张晓和表示，Riverbed希望通过在物联网与人工智能技术方向上的投入，能结合现有的产品解决方案，提供给客户更有效的、更为量化的以及可视化的产品，帮助客户解决端到端的数字化体验，***终实现为企业数字化转型服务。

随着物联网国家标准的日益成熟，物联网正在进入2.0时代，而在这一时期，企业将不仅仅以自身为中心，将会融入到新的业务模型和商业体系中，在这一体系中，企业由于在视频监控、供应链管理等等众多方面的变化都将对物联网应用和设备带来新的需求和挑战，Riverbed认为利用5G技术，结合市场客观需求，可以将更为多元、更分布的流量采集和监控融入方案中。

Riverbed一直致力于成为数字化转型中的倡导者和***，帮助企业实现业务应用的可管理、可优化，并且做到端到端的监控，而人工智能作为一个重要的手段将被应用于解决方案中，或是一些自动化运维，或是基于性能的数据化分析和优化，人工智能的正在展现出重要的生产力和价值。

基于对数字化转型的认知，张晓和提到，未来Riverbed十分看好企业端到端的数字化体验，这将是一个成长巨大的市场，Riverbed已经形成了以技术监控平台为中心的解决方案，在这一方案中，网络安全、网络监控，以及自动化运维都将提供给客户，帮助客户实现宏观的预测，克服更多的挑战。

DEM解决方案

据IDG调查显示，89%的企业未来将采纳或者已经开始数字化战略，与之相对应的是，85%的企业认为数字化***的推动者是云计算的使用，而云正在使数字体验管理变得更加重要。目前有96%的企业采用云计算，使用混合云的企业占比达到81%，据了解，企业除去自有数据中心的流量，对于外部公有云网络流量可追踪的网络流量仅仅是45%。

Riverbed亚太区技术方案架构师李耀宗

特别值得一提的是，由于云原生应用的使用，使得企业的应用更为复杂，同时可能会因为云原生架构引发新的性能问题，比如，云原生应用之间的聊天应用会无形提高云成本，或者缺乏对于容器栈的可视化会降低应用的生命周期等等。

Riverbed亚太区技术方案架构师李耀宗表示，来自数字转型举措的压力已经从根本上改变了公司开发、实施和管理其应用环境的方式。企业不仅要确保这些关键业务计划能实现其针对企业的目标利益，还需要在日益便携、短暂的环境中实现这些目标。

李耀宗还表示，***版数字体验管理（DEM）解决方案Riverbed SteelCentral可显著提升云应用性能。通过引入全新应用性能管理（APM）和网络性能管理（NPM）功能，新版SteelCentral从根本上改变了云架构的性能管理方式，使原生云应用和云化网络具备更高可视化能力。

据了解，SteelCentral APM采用可扩展的大数据方法，可***适应原生云生态系统。***版SteelCentral APM解决方案组件AppInternals通过在Kubernetes，Pivotal Cloud Foundry和Red Hat OpenShift中运行的交易、容器和服务实现全面可视化显著增强了对现代云化应用架构的支持。

此外，NPM云解决方案既可广泛地查看云网络流量，也可深入研究云网络交互。在网络性能管理中运用流量和数据包方法，企业可以将现有的本地技能扩展至云环境。

渠道整合将发挥更强作用

Riverbed在国内正在高速成长中，除了Riverbed不断适应市场需求，以数字化转型为契机，提供优秀的解决方案外，与Riverbed对于渠道合作伙伴与生态的建设的看重也戚戚相关。

Riverbed大中华区***渠道总监赵强

Riverbed大中华区***渠道总监赵强表示，今年年初，Riverbed推出新的渠道伙伴政策正在发挥重大作用，该计划通过依据不同产品线、根据合作伙伴具体贡献实现对于合作伙伴形成新的认证制度，利用这一方式，有效的提升了合作伙伴的积***性，他强调表示，未来将在此计划的基础上更进一步。

具体而言，在原有计划基础架构不变的情况下，通过方案的调整，激励合作伙伴自发的产生新的项目。与此同时，为了提高合作伙伴的技术能力，Riverbed将推动工程师认证体系的发展，而该认证将从认知数字化的角度出发，实现对数字性能的度量、管理、调优的了解，并以此形成平台性产品。

赵强强调表示，过去传统的搬箱子式的合作伙伴已经不能适应当前的发展需求，由于渠道合作伙伴更多的面向终端客户，渠道合作伙伴也需要能够拥有产品的交付能力，这不仅仅有利于Riverbed，也有利于合作伙伴的成长，而Riverbed未来也将持续帮助渠道合作伙伴开发这种新的能力，让更多的传统渠道伙伴转型成为服务供应商。

总结来看，Riverbed已经不仅仅是一家广域网优化公司，Riverbed在为企业数字化转型服务的道路上越走越快，随着Riverbed持续不断的技术创新与完整和全面的渠道生态建设，面对如此庞大的市场，Riverbed必将更加快速的成长。

国内三大OA 厂商 之一 致远的 成长之路

世上只有中国有而别的国家没有的事物有很多，OA算一个。

但对于OA众说纷纭莫衷一是，一位资深业内人士介绍所有的外企里没有一个叫办公室的部门，但中国所有的企业都有办公室，而且很强大，就有了办公自动化（OA-Office Automation）一说。

进入新世纪后，后来被广泛提及的三家OA厂商泛微（成立于2001年）、蓝凌（成立于2001年）、致远（成立于2002年）相继开始了各自的征程。

时过境迁，近20年发展，互联网巨头在数据智能时代掌握了话语权，BAT已经成为很多创业者绕不开的高山。泛微在去年A股上市，蓝凌正在转板并获得阿里钉钉的战略投资，致远已不说OA好多年。

本篇主要介绍16岁的致远，在新的市场格局下如何去做，而且它也要上市了。

矢志协同

2002年3月15日，在北京友谊宾馆，徐石等创业团队和用友软件公司共同发起成立“用友致远软件技术有限公司”（以下简称“致远”），专注于协同管理领域。据悉当时企业并不理解什么是协同管理，只认OA系统。

而OA还要追溯到1985年，在全国首次办公自动化规划会议上，我国的专家学者将办公自动化（OA）定义为：利用先进的科学技术，不断使人们的部分办公业务借助于各种设备，并由这些设备与办公人员构成服务于某种目标的人—机信息处理系统。

致远早年借助用友的渠道体系起步，2004年首届全国渠道大会举办，凭借着渠道体系和过硬的产品致远高速发展。计世资讯《2008-2009年中国协同软件市场发展趋势研究报告》表明，2008年致远以11.3%的市场份额排名***。

致远如此重视渠道的建设与徐石上一次刻骨铭心的创业有关，上个世纪90年代，“十亿人民九亿商，还有一亿在观望”描述了那一拨创业浪潮，徐石是90年代中期从国企下海，在老家成都做软件代理商、系统集成商，作为软件产业的一环，并不被尊重。后来他带着疑惑去了四川大学商学院学习，决心不要做生意而是要做企业做真正的产品。而由于在做软件代理商时受到过不公平的待遇，他更能理解合作伙伴，也要创建一个与合作伙伴结成联盟的可持续发展的生态圈。

所以在产品的设计和商业模式的设计上一开始就为合作伙伴留出更大的合作空间，这才有了后来的业务生成器，更多的二次开发接口，为代理商设计成长上升通路，对区域代理商提供保护等，明白伙伴和客户的成功才是自己的成功。2010年正式更名为“北京致远协创软件有限公司”，确立“致远软件”独立品牌。

然而创业的不同阶段都会出现不同的机遇与挑战，徐石深受西方商业精神和佛家哲学思想的影响，容易居安思危，也懂得要拿得起放得下。

关于高端协同产品A8的开发体现了他居安思危的一面，当时致远产品好卖、利润较高，日子好过，可以说小有成就，即使股东回家歇着也有可观的回报。但是开发高端产品面临巨大风险，内部经历了激烈的讨论。徐石力排众议的坚持才有了A8历时两年研发的开花结果，使得协同软件进入集团化应用的新阶段。

而关于后者，2012年受央视同名节目的启发，徐石带着52名管理团队重走“玄奘之路”的戈壁徒步，通过这段108公里内训旅程，用身体力行让团队放下杂念回归初心。

致远的初心是在协同的道路上矢志不渝，但是随着网络基础设施和新技术的发展，协同的内涵发生了变化。

接下来致远向平台型公司发展，要做大协同，所谓大协同在徐石看来就是移动互联网时代真正的协同管理。

大协同要有多大？

2013年一向低调的徐石希望成为扛旗的人，让致远的名字刻在中国协同软件的里程碑上。

同年6月致远发布了历时三年研发的V5平台，在向平台型公司的发展中迈出了坚实的一步。基于V5平台，致远互联整合了原有的A6、A8产品线，升级了移动产品M1，并提出大协同的理念。而大协同就是要以人为核心，他说花了十年的时间，终于明白公司的经营就是经营人，经营人的本质是经营人心，其他的诸如利润、营收等等都是副产品。而从2013年开始中国企业从人力资源管理转型人才管理，更加注重人的能力。

徐石认为在互联网化的产业和企业中，组织将裂变得越来越小，不同的组织间需要有效协同聚集。而且，互联网的快速易变性对组织中人的能力提出了很高的要求。因此，以人为中心的协同，将是组织管理中的普遍需求和互联网化的基本配置。

2015年国家发布互联网+战略，市场上演集体去OA的一幕，蓝凌主打移动办公上市（新三板上市）***股，泛微主打协同办公，致远主打协同+，深耕各个细分行业，OA“迟暮”。2016年致远首次提出了“深耕协同生态链”的战略目标，这是“协同+”战略的升级，也标志着一直深耕生态的致远将协同生态上升到战略层面。徐石说过：“合作伙伴和致远互联的***合作缘于生态，而企业是因为梦想而存在的，致远互联要走更远的路，要与有相同观念的人合作。”

致远深耕协同领域十多年，注重合作伙伴与渠道体系的建设，目前已经将用友渠道、金蝶渠道、系统集成商等不同属性和经营方向的软件渠道厂商纳入其中。

2017年又一个新三年之际，“致远软件”更名为“致远互联”，同时前用友股份执行总裁、用友优普总裁向奇汉加盟致远担任致远互联执行总裁。名称变化的背后是其业务在协同领域的拓展。未来三年，致远将以专业、开放、智能的“协同+”平台，从产品型公司转型升级为平台型公司，而***终成为生态型公司。在会上徐石提到了传统OA与协同的不同，“协同所涉及的内容在发生变化，协同管理在关注组织的结构化信息同时，高度关注组织的非结构化信息。高度关注个人与组织的工作行为、业务行为以及相互的关系，***终落到组织运营的绩效上。传统OA仅仅是协同管理的一个子集，今天，致远重新定义的协同早已超出传统OA的概念！”

而关于协同的生态，向奇汉认为更多企业的协同需求在于内部和外部产业生态的协同，即在原来隔离的企业内部、外部建立连接，搭建一个支持企业生态链发展的协同平台。未来，只是单点信息，而不具备流程化的OA将会被智能的、场景化的协同办公所取代。

在今年一些公司提出了打造大协作、大闭环的战略目标，不仅包括企业内外的管理系统连接打通，还包括上下游的连接打通。虽然他们属于不同领域，SaaS、人工智能、大数据技术在不同行业和不同领域的成熟度参差不齐，应用场景有待完善，软件集成的发展也会有木桶短板效应。但是越来越多的软件厂商开始提出打造大协作、大协同或者大闭环，也说明软件之间的集成、打通做生态走到了新的阶段，今后对于这种资源、生态整合的竞争也会更加激烈。

年终岁尾各种预测性的文章便多了起来，近日不少投资人和创业者认为接下来是ToB的好时代，但是正如一位投资人说的没有什么好时代和坏时代，大浪淘沙始见金。

不站队的致远

在2014年的又一个致远三年规划之际，徐石在接受《世界经理人》采访时指出，未来三年是致远的关键期，做好了进入新的协同境界，做不好就要被淘汰。

这三年间，新的技术和商业模式不断涌现，移动化、社交化、大数据、云计算成为资本、创业者、媒体言语中的热词，在传统软件时代没有分出胜负的时候，不断有新的玩家加入，而钉钉的强势发展为协同领域带来了冲击。

在社交折戟的来往决定在移动办公领域开启新的征程，由此企业级市场迎来了重量级的玩家阿里钉钉，也宣告互联网巨头进军B端。钉钉和企业微信一开始都是主打中小微企业市场，对于协同SaaS创业公司的冲击更大一些，甚至在2017年的时候还有业内人士讨论钉钉是不是鸡肋。而当集团型的企业开始使用钉钉的时候，传统厂商便感到了威胁。

显然致远随着平台化、生态化战略的发布与执行，并没有被淘汰。到了2018年可谓是协同办公领域的大变之年，新的格局新的挑战已经出现，市场也需要一个新的致远。

2018年9月26日，钉钉宣布战略投资蓝凌，携700万中小微客户杀入中大型移动办公市场。

次日，泛微推出新一代OA产品e-cology9.0，并宣布与腾讯企业微信、上海CA认证中心、契约锁形成战略联盟，来应对从入口端到深度应用、身份认证、电子契约的产业链整合。而集四家所长的e-cology9.0被描述为“智能化、平台化、全程电子化”。

之前泛微和企业微信已达成合作，双方计划共推合作伙伴发展，主推泛微旗下移动云OA平台eteams。e-cology9.0的推出表明企业微信与泛微的合作进一步升级到中大型客户，同时也意味着企业微信不再满足于中小企业市场。

BAT选边站在协同办公市场也同样有效，协同办公市场进入帝国之战。致远的一系列动作表明没有站队，但是和企业微信走得更近。

2017年11月11日，致远互联与企业微信达成战略合作，致远互联升级的一站式办公应用平台formtalk云应用入驻企业微信。

致远互联副总裁、formtalk***人李平回忆，因为担心企业微信“抢”了服务商的饭碗，2015年8月和其他数十位ToB、SaaS、本地化软件***人或高管来到企业微信总部要说法，“逼宫”企业微信（当时叫微信企业号）。***后企业微信表态“只做连接，不做应用”让大家放了心。

2017年12月22日，企业微信产品部总经理等6为高管来到致远，加强构建“企业微信+服务商+ISV”生态模式，未来在G6、致远V5协同管理软件也将陆续与企业微信合作集成。

曾有业内人士说过钉钉和很多ISV合作起来并不愉快，因为钉钉本身的风格偏激进和强势，它希望ISV们能跟上它的节奏，否则钉钉可能就会放弃ISV，甚至自己来做。

致远与钉钉也有合作，比如致远微协同等方面的集成。日前钉钉举行了新的发布会，更加明确了自身定位想要拉近其与ISV、客户的距离，或许我们应该用新的视角来看钉钉以及中国的协同市场了。

不站队的致远在生态的布局上加快了脚步，在创立致远之初，徐石就明白“未来的竞争，一定是商业生态的竞争，谁拥有更完整的商业生态，就会拥有更持久的生命力。”今年发布了伙伴凤凰计划，第八届用户大会致远互联与百度AI、企业微信、360企业安全集团、用友、华为云、金山办公、随锐科技等巨头企业达成生态战略合作，共同发布“协同+服务企业数字化生态”计划，这也被描述为致远互联协同生态升级的里程碑，寄予厚望。

平台和生态是致远未来十年的战略，但是生态做起来并不容易。

另一方面16岁的致远快要上市了。

致远要上市了

自致远独立发展以来一直谋求上市，但是一直没有明确的上市时间表。

甚至徐石曾经表达过对于上市并没有那么强烈的欲望，在2014年接受《世界经理人》采访时他说“如果奔着上市而去，那么至少前三年就要为了美化业绩而不敢大手笔投入研发，这样主业势必受到影响。另一方面，如果实力不够，即使上了市，也只能东拼西凑去美化业绩向股民交差，比如冷落主业去挣快钱。”

或许是认为时机到了，过去两年致远在积***改制准备，2015年12月11日二六三公司以5250万元人民币自有资金向用友网络收购其所持有北京致远互联软件股份有限公司7.5%股权，二六三方面表示致远互联正处在IPO前期准备阶段。

2017年1月19日致远与中德证券签署了《北京致远互联软件股份有限公司与中德证券有限责任公司之辅导协议》，致远上市被推上了进程，协议约定中德证券作为致远互联首次公开发行股票并在创业板上市的辅导机构。致远***近的一次资本活动是2017年3月在改名更标的同时，宣布获得近2亿元新一轮融资，由正和岛投资、高榕资本和盛景嘉成母基金联合投资，三家资本在企业级服务市场都有多年的积累，也让“新致远”有了更多的想象空间。

今年是公认的资本寒冬，有的公司流血上市，不过一大波关于高科技和创新性公司的上市利好政策发布，对于正在谋求上市的致远而言也是一个机遇。3月30日，CDR（中国市场存托凭证）规则、就IPO管理办法及《证券公司股权管理规定》征言，《关于开展创新企业境内发行股票或存托凭证试点的若干意见》发布，为云计算、人工智能等创新企业上市提供政策支持。9月26日国务院发布关于推动创新创业高质量发展打造“双创”升级版的意见，支持发展***好但尚未盈利的创新型企业上市或在新三板、区域性股权市场挂牌。而在进博会期间宣布在上交所创建科创板，打造中国的“纳斯达克”。

去年徐石在新三年战略发布会上充满自信，“15年前，致远软件从北京友谊宾馆起步，15年后的今天，梦在前方，从鸟巢开始，从鸟巢起飞！”如今矢志协同的致远乘着政策的东风，打造大协同和生态，正处在16岁的花季，也将要上市走向新的旅程。

创业是一将功成万骨枯，也是如鱼饮水冷暖自知。近20年间那么多新技术与新趋势，并非每个公司都能踩对节拍与时代共舞。古人云“立言者，未必即成千古之业，吾取其有千古之心；好客者，未必即尽四海之交，吾取其有四海之愿。”有梦就去努力实现吧！

转载至 人称T客