分类： 云计算

传统架构与云架构

根据分析公司Canalys的数据，2019年全球组织在云计算基础设施即服务上的支出达到创纪录的1070亿美元，比上年增长37％。 甚至在大流行之前，几乎所有公司都在跟踪更高的云计算销售。 但是，大多数云行业分析师预测，大流行后将在公共云服务上运行。

目前，在危机期间，大多数企业都属于以下一种普遍的运营模式：

那些处于保持状态将不会对任何费用，直到他们得到全部清除IT相关的项目。 此类别包括大多数大中型企业。 许多项目都处于暂停状态，这种普遍的延迟可能会再次困扰他们。

当前与大流行相关的限制使在紧急模式下运行的业务部分或全部被禁用。 此类别中的示例包括餐馆，酒店，游轮和许多小型店面。 他们将资源转移到较短的快速修复项目上。 如果没有良好的整体规划，可能会发生这些修复，因此将做出一些错误的决定，这些错误需要在以后进行纠正。

*终，有些会继续以正常模式运行 ，而大多数时间都是照常营业。 这将包括那些员工在大流行之前在自给自足的家庭式场所工作的企业，例如IT顾问和员工，艺术家和手Craft.io者，以及其他可以远程完成的基于服务的企业。

无论您现在所处的模式如何，当我们到达大流行的另一端时，情况都会改变。 以下是三种很可能会成为焦点的云架构模式：

• 无服务器的一切。 无服务器计算从一个好主意变成了一个奇妙的主意。 无需调整服务器大小并使其在线（与存储相同）。 大多数公共云提供商现在可以为容器，数据库和人工智能提供无服务器计算。 大流行后世界的好处是部署速度和变更速度，这意味着您创建了一个专为变更而设计的架构。
• 联合安全。 通常，鉴于云资源和应用程序的分布式性质，IAM（身份访问管理）是实现云计算安全性的*佳方法。 分布式资源的集中安全管理是一个新兴的概念，它已经到来了。 联合安全性涵盖所有计算和存储资源，以及所有设备和人员。 无论需要多少资源来适应新的市场机会或全球危机，这种方法都将大步向前。 这将是前进的更好方法。
• 分布式容器。 您已经听说过使用容器编排技术（例如Kubernetes）的容器和群集容器。 什么是分布式容器？ 它是独立运行或在集群中运行的容器联合，具有在任何地方（无论是否在云中）运行这些容器的能力。 再次，我们正在寻找灵活性，以使我们摆脱未来的麻烦。 您可以更快地将处理从一个云转移到另一个云，或者从数据中心转移到云，在危机期间您拥有更多的选择。

危机之前和之后的计划都归结为常识。 在过渡期间，没有为云计算上的大流行后运行做好准备或至少没有做好准备的企业将在混乱或危机模式下运行。 您可能会遇到云提供商的服务短缺问题，因为云提供商难以获得必要的硬货和员工来应对大流行后的需求激增。

如果您现在可以采取一些防御措施来研究无服务器，联合安全性和分布式容器的选项，那么当生活恢复到新的正常水平时，您的云配置和选择将更容易实现。

如今，新兴的互联网行业对“云”很熟悉，传统企业们对“云”也并不陌生。

从进取到保守，云的扩散，让*初的互联网行业大踏步走在前方，而如今传统行业用户已然开启了奋起直追的模式！

企业们不再“等等看、试一试”，而是选择“有条件要上云、没条件创造条件也要上云”，随之而来的就是有关开放云架构运维的“一堆事儿”，有的倍感惊喜，有的则捶胸顿足……

其实在追云的道路上，我们不妨停下来思考一下，对于云，我们真的按需取舍、高效分配了吗？

 

 

“传统架构的优势就是稳定性较好，运算能力很强，但弱势也很明显，成本高且处理并发的能力比较不尽如人意，需要配置很多接入口，十分不方便！

采访中，尽管传统架构在过去风靡许久，就连在传统架构领域拥有成熟的解决方案和丰富的运维经验的中亦科技，总裁田传科也不得不承认这一点。
————————————————

其实随着互联网发展，同时连入服务器的访问量骤然增加，如此变化恰恰暴露了传统架构的短板，然后众望所归的云架构出现了，再多的请求都能从容应对，例如我们熟悉并经常使用的12306网站。

 

 

起初12306网站利用传统架构，响应缓慢、系统经常崩溃，像春运这种典型的峰值情况对于传统架构来说确实“力不从心”，怎么办？

 

 

将“查询”功能放在云架构上？

其实这项业务功能并不要求数据上有很高的一致性， 通俗点儿来说就是在一定程度上允许“延迟”，这样分配不但有效解决了高并发难处理的问题，还保证了业务的正常运行！

云架构好用，能够弥补传统架构的劣势，所以在很长一段时间内，“传统架构太落后、云架构必会取而代之”的言论尘嚣之上。

对此，田传科表示，云是随着虚拟化、负载均衡、分布式系统等技术的成熟而出现的。以公有云举例来说，节约资源、成本低，标准化程度高都是其显著特征。

但看似“无所不能”的云架构，真的就没有不足吗？很显然，云架构所带来的的数据一致性、安全稳定性等问题目前还没有得到很好的解决。

如果将云架构与传统架构做个形象的比喻，田传科表示，它们可以被通俗理解为青年公寓和别墅的关系。

青年公寓具有良好的性价比，但无法应对特殊“客户”的个性化需要。

例如很多金融企业，由于其特殊的业务复杂性、连续性以及对安全的高标准性，很难要求这类企业将自己的全部核心业务迁移到云上，尤其是公有云上。

“但云架构的确有其优势，确实可以选择将一部分峰值性、通道性强的业务进行迁移！”田传科补充道。

所以，未来的“新云态”，是传统架构和云架构共存的。

随着企业这种双态架构越来越复杂，运维服务商肩负的责任也就越来越大了！

田传科说，应对“新云态”就要做好“智运维”。对此，中亦科技很早就布局了自动化运维，以应对未来日益复杂的IT基础架构，并且发布了EVO自动化运维管理平台。

田传科表示，基于十余年的运维经验积累，中亦科技发现，自动化运维并非要实现全部环节的自动化。

在传统数据中心中，整个运维工作中的30%-40%是不需要人工的，例如自动部署。

运维中什么部分可以选择自动化呢？

选择自动化主要还是解决人工成本过高以及效率太低的问题。

但并不是所有运维都可以用自动化解决，自动化解决的是标准化、流程化的问题，但不可否认，另外的60%-70%仍然需要人工介入。

田传科强调，单纯的云架构和传统架构的运维方式是不同的，因为有标准化和非标准化的差别。所以新云态下，客户一定需要的是在云架构和传统架构中都非常专业的服务商，来帮助他们做好基础架构的运维。

对于IT基础架构的自主可控，田传科也表达了自己的看法。自主可控的*步应该首先是在服务上减少对国外厂商的依赖，在更换存量设备条件还不成熟的时候，国内的IT基础架构服务商有责任通过服务自主可控，为国产厂商的发展成熟争取时间。并且，像中亦科技这种IT基础架构全生命周期全架构覆盖能力的服务商已经完全有能力代替国外厂商的运维服务。
————————————————

原文链接：https://blog.csdn.net/sch881226/article/details/80776035

如今，火热的容器技术已然成为传统基于管理程序虚拟化的一种实力替代品。

业界普遍认为，容器与传统的虚拟机相比，在启动速度、体积、应用和生态等诸多方面确实表现不俗。

毕竟容器足够轻载而且可以提供增强的可移植性，高效应用在移动平台之间完全不用返工或者让应用程序的开发者再重新设计。

当然这种易用性也在相关数据中得到了印证。

有关数据显示，随着容器技术的普及，接近一半的企业受访者表示目前正在使用容器。

其中占比40%的企业只使用容器进行测试和开发，另外60%甚至会同时选择将其用于生产。

之所以选择容器，企业主要考量的还是其表现出来的高扩展性以及可以简化并加速测试的功能。

容器技术“不俗的表现”除了引起行业的高度关注外，同时也被当作可信云评估的重要技术方向而提上日程。

据了解，可信云评估作为国内高度认可的云计算标准和评估方法，是衡量云服务技术能力和服务水平的重要标准，如果企业获得可信云大会*项，也意味着是对其服务能力及技术创新能力的高度认可。

而云计算行业后发者京东云在近日刚刚召开的可信云大会上斩获“容器虚拟化”技术创新*，备受业界关注。

放眼如今巨头林立的云服务市场，京东云入局并不算早，但却可以被视作进步快速的云服务商之一。不但爆出战略投资EasyStack，将在云计算、分布式存储、容器三大开源技术领域进行合作的重头新闻，其针对容器服务的探索更是技术能力创新的*好展现。

总体来说，京东云容器服务基于其在容器方面的的技术积累，同时融合了容器与虚拟机的双重优势，高度整合了存储、网络、安全等整体服务。

提供的容器服务不但无需管理虚拟机或集群，还可以做到快速部署以及弹性扩展，在保证安全、易用、全面几个重要指标的基础上计费模式更加精细化，对降低成本助力巨大。

据悉，不久之前京东云刚刚推出了完全托管的Kubernetes集群服务，“高可用性”是其显著特征。

具体来说，在京东云上可以通过全自动的方式完成跨区域的节点部署以及管理，同时还支持不同地域的数据中心节点的均衡部署，且为自动部署。

更重要的一点，京东云的Kubernetes集群可同时支持Serverless模式和非Serverless模式。不用考虑节点自身的复杂性，像原生容器一样调动所有API，无论是在创建环节还是调度上都确保*大的灵活可用性。

在这样深厚的技术积累之下，面对企业普遍反映的调度效率带来的成本提升以及诸多管理与规划的问题，京东云容器服务采用在hypervisors上直接运行Docker镜像，充分融合Docker容器和虚拟化的优点，既简化了平台复杂度又提高了性能和可靠性。

其中的独立内核技术，以虚拟机的隔离性为基础，避免容器间共享内核的安全隐患，同时凭借SDN技术实现不同租户实现完全隔离。

此外，由于集成了京东云VPC，服务可以通过安全组、网络ACL设置更细粒度的网络访问权限、提供基础的DDoS防护功能，哪怕是在同一私有网络中实现容器实例与公有云计算、存储、网络等资源内网互通，也可以充分利用产品资源。

由于京东云容器服务的技术特性，无论是微服务架构还是持续集成与部署都妥妥的适用。

具体来看，微服务架构将传统分布式服务继续拆分解耦，形成一些更小服务模块，服务模块之间独立部署升级，所以容器特性非常适用于微服务架构部署。

例如，每个容器中可以运行完全不同的镜像服务，容器启动后就会产生了一个独立的微服务主机节点，还可以直接将云平台提供的各种云服务与自定义的微服务整合成一个强大完整的服务集群。

此外，使用京东云容器服务，开发人员在提交新代码后，可立即开始构建、测试应用，测试通过后还可以随时将新版本镜像更新到线上并完成服务升级。

整个过程全自动化，*大程度地简化了运维成本，而且保证线上、线下环境完全一致。通过持续集成与持续交付提供的优秀的DevOps环境，*大提高软件发布效率，十分顺应行业内的敏捷开发要求。

京东云容器服务不但实现了基于虚拟化的底层强隔离，还同时保留了容器的轻量级特性，可谓是集高性能、便捷性、高可用性于一身。

此次可信云大会上，京东云不但凭借“容器虚拟化技术”获得可信云评估的高度认可，还通过“数据库技术”摘得了存储类的技术创新*。

据了解，京东云分布式关系型数据库DRDS将拆分解决单机数据库容量无法满足业务需求的问题，通过事件驱动的多路复用模型外加把压力，打散到多个RDS实例上，从而解决单机数据库性能无法满足业务需求的困难。

通过实时备份解决数据高可靠，让DRDS与RDS融合支持用户快速便捷搭建分布式数据库服务以及落地两地三中心方案，提升用户的开发效率以及降低运维成本。

据悉，DRDS完全兼容MySQL的传输协议，用户可以快速便捷的从原生MySQL切换至DRDS服务，以*低的代价分钟级搭建一整套高性能高并发的分布式数据库解决方案，该服务尤其支撑了京东内部众多核心0级系统在618及双11的考验。

除了技术领域的创新成绩，依托自身“政务云解决方案”，京东云还助力宿迁市电子政务办公室荣获了“可信云十大用户*”，以京东云公有云以及自建私有云的混合云模式为基础而建成的市级政务云平台有效助力宿迁实现了“云端发展”。

有数据显示，此次获*的宿迁市政务云平台已完成迁移上云146个，上云率达95.4%。其中政务服务网、公积金系统、市政府门户网站群、居民信用积分平台等核心系统均稳定运行其上。

除了“宿迁政务云”典型项目之外，京东云目前已在多达15个城市进行了智能城市布局，通过“政务云”建设等形式为各地赋能。

其中，京东云政务云以城市新经济合伙人的身份出发深耕本地服务市场，从城市需求入手，通过技术赋能将京东云计算、大数据、AI、物联网、移动互联网等技术能力整体输出。

如今京东云进入“申元庆时间”，势头猛烈。他表示：“此次京东云获得可信云大会的*项，表明了业界对京东云技术能力以及政务云解决方案的认可和肯定。一直以来，京东云致力为用户提供安全、稳定的云计算服务并在技术方面努力创新；同时也希望通过自身云计算的技术赋能，助力智能城市的发展。”

目前京东云已经拥有108个云计算产品和服务，能够提供IaaS、PaaS、SaaS全栈式云服务，未来还将继续夯实自身的技术能力，开启属于自己的“云加速计划”。
————————————————

原文链接：https://blog.csdn.net/sch881226/article/details/81703830

腾讯云对外上新了一款服务器，号称深度自研且独一无二，其名字也十二分的卡哇伊，叫做“星星海”。晶少虽然还没来得及探寻其名的出处，不过在与腾讯服务器供应链总经理刘裕勋的谈聊中已基本了解到星星海的重要style之一，为云而生。

星星海，腾讯首款为云而生的服务器，不是简单挂个响亮的标签而已。深入剖析 “为云而生”的理念，我们恐怕还要追溯到通常情况下的服务器研发过程。

我们发现，一般情况下的服务器研发很难规避“堆砌”的窘境，所谓A用户需要A类特性，B用户又要求B种风格，一来二去整个架构变得异常复杂，企业级服务器更是如此，因为需要满足更多企业以及用户的需求；而相比之下此处的“为云而生”，很重要的一点就是要依照云的属性进行设计甚至优化。所以在设计部署过程中，星星海果断结合了数据中心实际部署环境要求，针对云端的计算、存储、网络等场景做了重点优化，据了解能够有效满足腾讯云98%应用场景需求。

“其实每个软件产品对相应硬件的配置要求均有不同，但如果可以使用同一套服务器架构，无论是CPU内存还是基础存储，都可以满足软件层面产品的需求，自研技术上达到了承上启下，也被称为软硬协同。”刘裕勋表示。在这样的想法驱使下，星星海通过精细的硬件设计大幅度降低了硬件成本和运营成本，同时有效匹配腾讯服务器供应链整体升级，更好整合了硬件产业链能力。

除了从云出发，高效利用硬件资源之外，星星海很重要的一点还表现在精简，有数据显示相比传统服务器，星星海在整个用料剪裁方面超过了20%，这种“好与省”尤其在能耗上体现突出。例如10万台星星海服务器组成集群，相比传统服务器实际上每年都会节省超过5亿度的用电量，毕竟电量消耗的百分之五十均来自服务器的能耗，当然这种精简精神是对标传统而言。

在星星海对外官宣的介绍中，我们发现，其与传统服务器相比很重要的一点就是整机方案可以支持不同的CPU主机类型，兼容架构具有较高的前瞻性，硬件基础被统一规划且放言可支持未来3-5年的服务器产品演进。有资料显示，其联合AMD在*新ROME平台下深度定制CPU，实现了行业*优单核性能和*优单核TCO。根据晶少了解，星星海可以实现云服务实例综合性能提升35%以上，其中视频处理速度提升40%，图形转码得分提升35%，Web服务页面QPS提升高达152%。

谈及深度定制AMD的CPU，刘裕勋提出，腾讯作为AMD七大CSP之一，在测试过程中发现的相关问题一经反馈就会得到AMD方面的高度重视，并用于AMD产品技术升级的重要参考之一。

以本次星星海服务器深度定制CPU为例，先前AMD对外发布的CPU只有两种类型，分别为32核与64核，而星星海在*新的rome平台下定制的单颗CPU为48核，此区别主要源于腾讯云方面针对内存开销和整个服务器性能开销的综合评定与兼顾。相比通常售卖的两套CPU搭载一个8G内存的传统形式，具体来说基于腾讯云海量数据的运营，48核的CPU无论是主频还是性能上都达到了*佳的适配效果。通俗来说，如果替换成一个更高阶的CPU，其能耗就会大大增加，说到这里，刘裕勋还特地列举了十分幽默诙谐的例子让大家能够更加形象生动的了解：一张餐桌本可以容纳十人就餐，如果每个就餐的人都是体重超过200斤的肥胖者，想必这样的就餐环境就会显得拥挤很多，而每一个身材肥胖的就餐者就像一枚高能耗的CPU，在实际使用过程中肯定会出现诸多问题。除了深度定制的CPU助力，在配套日虹散热技术的加持使用下，星星海实现了*大负载能效对比业界可提高50%，尽管该技术不算是业界散热的新理论，但实际落地，星星海算是杰出代表之一。

“确实，星星海对于我们来说算是first one，但*不是only one，我们已经把未来3-5年对云计算硬件服务器领域的发展趋势做了充分的认证，使服务器整套方案能够满足未来3-5年的产品演进。可以简单理解为，就是这样一套服务器方案，当面对新的技术应用层出不穷之时，只需要作出细微调整而不改变大的架构方向，就可完成技术适配与升级。”晶少得知，在星星海设计到量产不到一年时间这样的速率下（一般传统的服务器厂商，从 概念设计到可能的量产部署，一般周期在一年半到两年），未来到年底将会部署至少超过五千台的规模在腾讯云现有的业务领域中，可谓“又多又快”的节奏。

正常预测的话，在今年春节的QQ抢红包环节或者微信业务都能够直接运行在星星海上。通过快速部署在腾讯的公有云产品上，而且用自研QQ和微信，如此庞大体量的业务去做拉测来打磨整个硬件和软件产品，相信通过这种方式“锻炼”出来的腾讯云星星海能够更加高效为用户提供性价比优势的计算产品，赢在场景的丰富性。

谈及星星海的未来，刘裕勋提出了适配不同CPU架构的方向，其中包括英特尔、国产化架构抑或是自研芯片等，毕竟对于云服务商来说，降本增效历来都是永恒的主题。“如果没有办法每年都提供优质、高性价比的产品给用户，一定程度上相当于整个腾讯云的竞争优势会受到影响。我们更愿意通过产业互联网的思维，基于多年在用户体验方面的打磨，实现针对性能和成本的*致追求；通过经营化和演进能力，提供高性价比产品来降低企业或者客户上云的成本或者用云的开销，进而促进整个产业互联网的蓬勃发展。”
————————————————

原文链接：https://blog.csdn.net/sch881226/article/details/102954472

近一段时间，Serverless的横空出世似乎让大家发现了架构开发的新乐园。

无需纷繁复杂的后台开发配置，更不用介怀巨型架构体系造成的“迷宫”困境，开发人员轻松上阵即可完成过去耗时数小时才能搞定的初始版本，*大缩短技术研发与市场检验的距离。关于此，Serverless.com CEO Austen Collins表示，确实从运营商的角度出发，更需要将越来越多的产品serverless化，因为serverless涉及的层面更接近开发者以及应用层，与传统的基础设施与平台层面区别很大，需要部署很多抽象定制的解决方案。

晶少了解到，如果从运维角度去分析大热的serverless，当大家将很多核心业务，例如小程序云开发等放入其中，自然需要考量在生产环境下从事运维与监控等诸多细节，像无服务器这样的开发模式可以更好助力开发者去运维产品。

此外，谈及serverless帮助提升开发效率的环节，晶少觉得可以这样理解，举例来说过去一个团队需要10名开发者耗时一个月的时间完成某项功能的开发；如今采用serverless就只需要3名开发者耗时2周时间即可完成。所以对于一家企业来说，时间缩短且效率提升能够将更多成本放入业务开发的过程中加以投入，让每个流程中每名开发者的耗时做到*短并顺畅无误完成业务推进，才是*关键的。

另外在大家眼中，Serverless更加无所不能的一点还在于，不但能够hold住生产过程中需要的所有构建，更重要的是适用于所有在公有云部署业务的企业，如此小而美的开发方式，被誉为创业者、中小型公司的福音。那么问题来了，Serverless如此优势，企业在部署的同时怎样做到让配置更加接近于企业实际应用呢？

腾讯云中间件总经理Yunong Xiao​​​
关于这个问题，腾讯云中间件总经理Yunong Xiao认为，如果从部署角度深入，再对比传统服务器，作为云服务商确实不太希望用户太多感知到底层结构，而是做到更顺畅将自研应用的价值发挥出来，这或许需要改变全球范围内开发者们的习惯，将开发过程以及产品尽可能的serverless化。基于此，作为云服务商就越发要思考如何能够给企业以及开发者们提供一套流程，涉及从项目管理到代码托管，从构建到发布，通过serverless来提高开发效率，让用户对底层复杂的架构实现无感知。

听完两位专家关于Serverless的分析讲解，我们大致了解其中，其实无论是Serverless.com还是腾讯方面，针对Serverless的推进远不止于此，这还要回到腾讯云主办的首届Techo开发者大会上，腾讯云与Serverless开发平台Serverless.com达成战略合作并成为 Serverless.com全球战略合作伙伴以及大中华区*合作伙伴的震撼新闻发布。

据晶少了解，截至目前Serverless.com已经拥有了百万级别的活跃应用程序以及50000+的日下载量。旗下的开发平台Serverless Framework在促进简化开发、部署云函数方面表现突出，具有函数资源编排、自动伸缩、事件驱动等优势能力，可以做到让开发者无需关心底层资源即可快速完成Serverless应用的开发，无基础设施的运维负担。

具体来说针对开发者，Serverless Framework在应用编排上可以提供基于应用场景的丰富案例，只需要根据实际需求选择对应场景后简单几步，即可快速搭建出自己需要的服务。目前Serverless Framework覆盖了从初始化、编码、调试、配置和发布的全生命周期并提供了业务监控告警、测试和故障排查的一站式解决方案，帮助开发者更好地基于Serverless部署业务。

“Serverless.com 将与腾讯云合作，从基础设施到应用工具层面，共同推进 Serverless 技术的落地及制定行业规范，目前已经有一些优秀的架构在腾讯云落地。”Serverless.com CEO Austen Collins 指出。同时，腾讯云中间件总经理Yunong Xiao表示：“腾讯云将通过持续应用新的技术、提供新的功能、开发新的产品和构筑新的生态，从多方面为开发者提供全面完整的Serverless 体验，助力开发者实现Serverless的架构落地。”

需要强调的是，本次合作中*重要的成果之一就是腾讯云将与Serverless.com联手打造下一代无服务器计算开发平台——Serverless Cloud。据悉，该平台同样将覆盖从初始化、编码、调试、资源配置到部署发布，再到业务监控告警、故障排查的全生命周期。“从serverless框架角度来，此平台更加倾向于满足开发者的诉求，其中的应用场景不仅包括无服务器计算，而是致力于怎样为用户提供一个抽象定制化的解决方案。当然这只是腾讯云针对serverless迈出的*小步，未来可能会有关于大数据场景、AI场景等加入，覆盖更多的同时让越来越多的开发者应用serverless。”Yunong Xiao总结道。

谈及选择与腾讯云合作的初衷，Austen Collins说：“大约一年前与腾讯云相识，其创新与愿景都给我们留下了非常深刻的印象。可以肯定的是，腾讯云与我们有着相似的目标和视野，都认为Serverless是云计算的未来发展趋势，希望借助合作为更多开发者赋能。尽管Serverless与很多云厂商都有合作，但与腾讯云合作会更加紧密，因为腾讯云会更加贴近客户及应用场景并愿意吸取serverless在解决客户问题时得到的经验，以此来进一步优化基础产品，这是我们认为非常难得的一点。”

针对合作，未来双方都希望确保提供与腾讯Serverless基础设施的无缝、更深层次的集成，其中包括Serverless基础设施和架构之间的无缝集成；希望利用这种优势以及紧密关系为开发、监控、调试和保护提供更加先进的工具，同时来增强国内与世界其他地方的开发人员社区能力。提及腾讯云如何与serverless.com合作促进其在国内发展的问题，腾讯云方面就此表示，其实serverless是一个开发者的生态，必须接触更多的开发者来持续创新；很关键的是serverless是一个比较新的概念，如何应用、有哪些框架、产品之间怎样更好集成等，都需要彼此学习以及加强合作，将知识和经验引入国内发展。

就观察，毋庸置疑除却两者之间的紧密合作外，Serverless技术也一直是腾讯云原生的重点发力领域。目前来看，腾讯确实有一些独特的内容生态优势可以发挥并与serverless的方式进行结合；如果从业务角度来说，serverless也可以被称为是未来技术发展的趋势之一。

通常来说，针对云计算等很多技术而言，起初确实需要很多高端技术背景的开发者才可以推进并使用，但发展到一定阶段，更多的创新迭代方式是让技术大众化。“我们可以利用很多框架，将没有serverless的产品包装成serverless属性的产品，这从产品开发角度可以更快加速更多开发者应用serverless。对每一个技术开发者来说，写代码就是要去解决业务方面的问题，而在这个过程中，需要选择更便捷的业务逻辑。”腾讯云方面表示。

总结来看，目前serverless还处于不断创新的阶段，需要很多维度的调试与排查，但如果可以提供给开发者一套便捷业务发展的工具来躲避多种实战陷阱，并完成更多自动化的应用需求，无论是腾讯云还是Serverless.com都认为Serverless有能力完成这样的开发使命，是*合适的选择。

一直以来，随着无服务器时代加速来临以及产品和生态走向成熟，腾讯云正在构建全面的开发支持、DevOps、运维监控等能力，协助开发者更好地通过Serverless实现低成本、快速高效、稳定安全的业务部署，为Serverless承载起企业业务发展奠定坚实基础，这次与Serverless.com的鼎力合作正是说明了此点。
————————————————

原文链接：https://blog.csdn.net/sch881226/article/details/103111398

2.4亿人在线使用文档协作无延宕……

6万名武汉中小学生实力打造“远程课堂”活学高效……

疫情以来，“远程”、“协作”持续大热，此局毋庸置疑。

根据QuestMobile*新发布的《2020中国移动互联网“战役”专题报告》显示，2020年春节假期前后，由于远程办公、在线学习等需求的上升，效率办公日均活跃用户规模上升了4000万。其中值得提及的一点，有一款将“远程多人协作”与“大规模突发信息汇总分享”需求有机结合的软件可谓榜上有名，成绩如何？

有数据显示，其位列办公商务品类微信小程序用户日活数量*位不说，就在几天前刚刚公布的阿拉丁指数微信小程序2月份榜单中，此软件稳稳占据阿拉丁指数总榜单第三，并牢牢保持工具类榜单*的名号。众里寻TA，正是2018年7月独立上线，如今月活跃用户突破2.39亿的金山文档。

据晶少了解，受金山文档领衔的“文档上”之风助力，有效解决受疫情影响的学校授课延期问题，只需老师在该软件上发起会议，实时共享任意格式的课件文档的同时邀请全班同学点击链接进入即可完成远程授课。此过程中，授课老师作为主讲人控制屏幕翻动资料，学生们可通过电脑或者手机完成实时观看并语音发问，操作便捷。

此外，金山文档还提供了表单式的作业收集，学生完成作业后只需通过表单上传习题本上的图片，老师批改作业后再发回给学生进行相应修改即可，课上课后沟通实在无负担。据悉，借助金山文档的远程会议功能，疫情期间江汉区54所中小学、4200名教师和60000名学生已高效开启远程“在线授课”模式，直至此次疫情全面结束。

之后不仅武汉本地，包括广东、广西、陕西、黑龙江、吉林、云南、深圳等多地在内的众多大中小学均开始基于金山文档打造“*人性化”的在线课堂，据悉人数*多的一堂课，同时参与的学生数量超过2000人，全流畅无卡顿实在叹为观止。此外针对政府、医院和学校等机构，金山文档在疫情期间还赠送了约400万个企业版金山文档供使用。

除了基于课件共享的在线课堂外，金山文档还为疫情期间众多场景提供了便捷功能。例如需求爆棚的电商行业，员工可根据工作需要在同一表格里协作，既可进行视图区分也可同时数据修改以及回放找到改动源头，从而高效准确作业；另外借助政务微信小程序嵌入金山文档表单功能，产品还可以做到让街道人员实现“无接触式”的人员信息统计；重要的是，在全国多个一二线城市中甚至有的社区居民在防控期间会使用金山文档的表单功能收集买菜信息，以此代替传统的在微信群中接龙买菜模式，因此受到不少家庭的好评。

如今，金山文档支持常见的办公组件Word、Excel、PPT、PDF的多人协作编辑，并且满足*多300+Excel函数公式，同时完全兼容MS Office的文件格式，保证了在线文档落地的标准性。

除常规在线文档支持外，金山文档表格还研发了强大的跨book引用、保护工作表等满足多人协作场景的刚需功能，真正做到权限可控、文档安全。“其实团队协作不只是一起写文档。除了表格、文字、演示、PDF的协作编辑，金山文档还开发了高阶协作的会议、待办、表单、日历等功能，尤其是类似会议、表单等功能在这次疫情中通过一些意想不到的方式帮到了大家。”金山办公首席运营官章庆元说。

功能强大、需求众多，面对上述情况，晶少得知在疫情期间金山文档一直通过有序的服务器扩容来满足不断增长的使用需要。“疫情发生后，从除夕前后开始，先是统计人员信息的表单功能需求激增，随后是2月3日延迟复工后，会议和在线编辑需求快速增加。”金山办公高级研发总监汪大炜表示，“过去一个多月里，金山文档在线编辑日活增长约6.5倍，表单日活增长约27倍，而会议日活增长高达177倍。得益于持续对云办公的投入，在此过程中我们保持了产品系统稳定和体验流畅。”

具体来说，有数据表明在此期间，金山文档WPS表单服务器扩容了5倍，会议服务器扩容了3倍，在线office业务也扩容了1倍的机器。当原来备用的服务器全部用完时，也会开始使用一些金山云提供的云主机来满足支撑需要。

另外由于金山文档的内核是采用C++编程语言，具备效率表现很高但内存占用却很低的特性；相比之下，其他在线文档产品多数源于数据库支撑，占用的内存与系统资源较大，对比C++的原生线程，金山文档一台服务器实际支撑的用户量会比通常情况多很多，效率自然提升显著。

谈及疫情中庞大的用户需求与技术扩容细节，金山办公高级研发总监汪大炜总结道，经过长期的观察，教育行业、电商以及物流运输业都对远程协作等“文档上”的诸多需求呈现暴增态势。“过去，教育行业通常都是传统的上课与交作业模式，很难应用到远程课堂与线下协同；同时疫情中电商类的需求也是我们始料未及的，表现比较鲜明的则是不断的版本更新与迭代；此外在物流运输方面，我们也逐步发现了针对表单功能的庞大受众群体，未来或许在这些行业都会爆发新的增长点。”

如此看来，对比其他同类产品，金山文档则更多关注新时代、新用户在新场景下的协作问题，正是这种文档协作、会议协作所延伸出的时间层面的协作构成了特殊的产品定位，即坚持以开放的office文档作为核心服务，寄希望于将现有的办公模式做迭代升级，而不是颠覆，这也是与传统Office明显不同的地方，以至于产品更多立足于怎样帮助用户协作以及在协作的过程中完善流程，让使用体验更友好。“金山文档的定位不会倾向于做一个类似于WPS的重产品，而是坚持在线与云化的思维，真正做到深度功能的持续优化，完成不同产品之间的整合，降低用户在学习与使用层面的门槛与成本。”章庆元提出。

未来面对移动远程办公行业的两类主要玩家，分别是基于互联网巨头内部办公软件的一站式中小企业协同办公解决方案以及在线文档、视频会议等细分领域龙头企业，除了共同探索、教育用户、培养用户认知、打造良好市场环境之外，金山文档方面认为，更多还是为入局玩家们提供专业的文档在线协同服务，诸如与阿里云、腾讯云开展SaaS层面的合作，将文档处理转变为一种随处可找、随时可用的权益，无需花费时间另做开发，完成能力上的输出，始终坚持“文档服务提供商”的战略定位才是关键。

“未来很长一段时间内，在技术产品上，金山文档整体还是会聚焦和文档相关的协作上，夯实用户留存的环节，会不断强化产品的相关能力，例如加入更多音视频技术要素，选择与更多专业领域合作伙伴一同攻克音视频技术难题，而不是通过自身来解决问题；但会自主研发AI美化文档功能，强化文档的创作和处理能力等。”

早在2018年，金山办公启动以“云、多屏、内容、AI”为核心的升级战略，届时金山文档以此成为云战略落地的*重要载体之一，同时受国内云计算、云存储和移动计算技术的共同推动，包括金山文档在内的以“协作”为核心的在线文档产品，开启全面颠覆传统工作方式的征程；而此次因全民抗击疫情而爆发的远程办公需求，正恰到好处地印证了云协作办公的独特价值。

如今数亿用户开始熟悉并习惯协作办公，这对于文档行业具有重大意义，2020年或将成为真正的“在线办公”概念实践元年，当在线化与云化逐渐走向前台并明朗之际，我们相信金山文档或能带来更多惊喜。

原文链接：https://blog.csdn.net/sch881226/article/details/104746367

鼠年春节，一场疫情突如其来地打破了人们平静的生活；但在滨州，一款名为“疫情助手”的上线软件却为滨州市民的疫情生活带来“雪中送炭”的丝丝温情，细微知著中人们深深感受到了京东诠释而来的“ABCDE”技术战略以及那股子科技力量背后的温暖人心。

滨州市一位公务人员展示“疫情助手”
疫情之内，京东释放科技力量温暖人心
据晶少了解，这款“疫情助手”全名为“疫情助手智能机器人咨询平台”，作为京东自主研发的智能情感客服系统，其主要依靠NeuHub京东人工智能开放平台提供的语义理解、句法分析等能力，就可通过问题预判、意图反问、分类识别、相似度匹配等多种方法探索出用户的准确意图，并根据问题类型，智能匹配出*佳的解决方案。

在滨州抗疫过程中，该产品历经多重场景、用户、数据的锤炼，通过提供实时疫情查询、专业医生服务、就医指南、发热门诊医院查询等功能高效协助当地政府、医疗单位遏制灾情，提供了有效的技术支撑。

同样的抗疫惊喜还出现在千里之外的广西南宁。一样在疫情期间，京东智能疫情产品在南宁“爱南宁”APP和微信端落地被应用，超过千万市民只需从疫情专区进入“应急资源信息发布”，就可以在“智能疫情助理”模块中选择相应服务。

据悉，这款京东“智能疫情助理”产品源于京东智联云打造的通用智能对话平台，可以根据不同行业、不同场景的需求，快速搭建出融合行业理解、支持多轮交互、具备情感能力的对话产品，具有场景化快速落地与快速调优能力，目前累计服务咨询量高达数近百万次。

此外，基于京东智联云*的语音语义技术研发的同款智能疫情助理已经在北京、山东、安徽、江苏、江西、四川等地的十多个行业、一千余家组织和机构中快速落地，服务免费并累计服务咨询数量达数百万条，让人们在特殊时期充分感受到了技术的便利与科技的温度。

无论是智能疫情助理驰援抗疫前线武汉，还是携手浙江丽水开启“5G+AI”科技抗“疫”，抑或是全国十余城共同落地“京东智能温感筛查系统”，可以想见，疫情期间京东已充分做到广泛调动内部基于京东云平台、京东人工智能开放平台NeuHub、京东物联小京鱼智能服务平台的能力和资源，迅速向社会推出了应急资源信息发布与匹配平台、智能疫情助理、云视频会议、远程家庭医生服务等十余款免费产品和服务，为3000多个企业提供免费远程视频会议服务，保障数十万学生“停课不停学”，实现云上经营、云上办公等，截至2月28日已覆盖上万机构、数百万用户，匹配并提供抗疫物资超6.6亿件。

疫情严峻，但京东的技术是有温度的。对此京东集团技术委员会主席、京东云与AI总裁周伯文表示，在疫情防控攻坚战中，京东智联云不断推出有温度的技术产品助力政府治理、企业经营、服务公众生活，彰显责任与担当。

疫情之外，京东一路技术向前、融合至上
放眼疫情科技背后，盘点京东一路坚持贯彻的“技术转型”，我们发现，其实早在2017年初，全面加速转型的号角就已然在其内部吹响：在日前发布的2019年第四季度及全年财报数据显示，京东全年净服务收入为662亿元人民币，同比大幅增长44.1%，总收入占比超过10%，如此说明什么问题？足见技术与服务正逐渐成为其增长的又一重要引擎。

除此之外，晶少得知，2019年京东体系所属上市及非上市企业合计研发投入达179亿元，研发投入同比增长高达47.8%，已跃升为对技术投入*多的中国企业之一，成绩表现着实可圈可点。具体来讲在云计算领域，截至2019年，京东云累计建基地及落地城市云超过40个，合作伙伴超过2500，注册用户超过69万，推出300+款产品与服务，实现100%云上订单，拥有全球*大规模Docker集群之一和中国*大的GPU集群之一。

另外在物联网技术领域，京东方面2014年就率先进行业务布局并发布*个自主研发，跨品牌，跨品类的智能家居互联互通平台。目前该智能家居互联互通平台可连接高质量设备突破1.5亿台，设备品类超230种，品牌超1000家，用户交互次数近20亿次。

如此发展，可以想见未来包括以安全、可信赖为核心差异化的基础云服务，以智能供应链为抓手的数字化、智能化产业互联网应用云服务，以边缘计算为代表的云、边、端协同的下一代智能云服务等在内的三个方向都势必成为主攻着力点。

深耕技术的同时，我们了解到目前恰逢互联网竞争已遁入下半场，人口红利正被2B企业服务（特别是技术服务)所取代；行业方面，随着AI、云计算等技术与IoT产业的融合，硬件与软件的协同趋势加剧，促使涉足2B领域的企业必须同时具备全产业链整合和供应链智能制造能力，从而覆盖全场景以及全品类。

在此背景下，作为一家以供应链为基础的技术与服务公司，京东技术战略强大之余走向融合实属必然，所以在趁热打铁之际，2019年12月京东集团再次加码对技术的投入，将原京东云、人工智能、物联网整合成为京东云与AI事业部，统一冠名为“京东智联云”品牌，并于2020年3月5日正式启用，技术融合释放更多价值，终成定局。

着力解读新品牌内涵就会发现，总体来说LOGO所描绘的三种颜色分别代表了人工智能、物联网、云计算与大数据等多种前沿技术。对此京东集团技术委员会主席、京东云与AI总裁周伯文总结道，“京东智联云的品牌形象传承着京东‘红’，代表可信赖；搭配世界通用的科技‘蓝’，代表在京东价值观下对技术与创新的坚持；交互融合组成的无限符号‘ ∞’，代表互联互通的智联世界，也寓意更多不断发展变化的前沿科技。未来十年将是智能经济的时代，作为京东对外技术与服务输出的核心通道，将着力打造可信赖的智能技术，更好携手合作伙伴，始于信赖，胜于格局。”

就晶少理解，*简线条中 3个无限符号相互环绕交织，确实生动形象地表达了京东人工智能、物联网以及云计算融合形成的科技体系，未来将成为集团技术能力的统一输出窗口，但此种部门的整合、业务的合并以及品牌的融合*不仅仅是简单的“加法关系”，而是更多承载了“以人工智能（AI）为大脑、大数据（Big Data）为氧气、云（Cloud）为躯干、物联网（Device）为感知神经，以不断探索（Exploration）为好奇心”的京东技术“ABCDE”战略的有机体，以此为基础提供可信赖与高效率的前沿科技服务，为G（政府）、B（企业）、C（个人）端用户提供包括从基础资源到智能应用等各类产品与服务才是核心所在。

AI、云计算、 IoT的业务整合是技术发展的需要，也是“集中力量办大事”的考量，能够具备提供一站式、生态化技术解决方案的能力才更有助于将自身全面深厚的技术积累转化为技术势能，对内释放并对外赋能，正所谓“融合技术、释放价值、整合优势，输出一体化解决方案”就是这个道理。

技术融合在前，帮助用户补齐产业要素、实现产品创新、推进产业转型升级紧随其后，不容割裂。基于新品牌的着力打造，面对企业伙伴甚至是智能化初期企业，京东智联云未来想必会大力整合云、AI、IoT技术和产品，打造安全、可信赖差异化的基础云服务，共同进行产品技术创新和打磨。另外对于开发者而言，全新组合的京东智联云则是一个平台、技术与工具的乐园。稳定、丰富、高效、开放的特点让开发者尽情施展才华，开“箱”即用，部署成本低是常态。如今以NeuHub为核心载体的新一代智能供应链平台已成入选了科技部公布的智能供应链国家新一代人工智能开放创新平台，未来会让更多产业开发者受益匪浅。

由简入深，技术以场景致胜，联接场景、赋能产业也是未来京东智联云内外赋能的重要一环。通过数字企业和数字政府两大主要场景，京东智联云协同打造零售、物流、金融、城市四朵云和强大丰富的生态平台，提供从底层资源到上层应用的全面服务，凭借自身在零售、物流、金融等领域多年深耕所积累的场景和技术优势，为客户提供更多、更好、更融合、更场景化的技术与服务，构建统一平台生态。想必此举也是助推内部技术能力、资源优势来搭建京东技术大中台，将技术势能通过技术中台对内释放和对外赋能的重要抓手之一。

回到行文*初，疫情之内我们看到了京东智联云携手宿迁联通、鸿联九五在江苏推出疫情防控外呼机器人公益活动；我们看到了京东智联云助力黑龙江省前进农场，在抗击疫情*艰难的时刻用技术短时间内帮助解决抗疫、生产物资供应等紧急问题；我们同时也看到了由京东智联云为海淀区政府定制部署，提供“应急物资、疫情动态、企业服务、市民服务”等多重服务，全面支持北京市海淀区应急防疫工作的诸多举措……这不正是京东通过可信赖的AI+云+端技术打造云智联世界，探索前沿科技，抵达真实生活，展望美好未来的集中展现吗？

疫情之外，如今越来越多的“智能”走入日常生活，随时随地享受数字经济时代带来的便捷渐渐演变成人们生活的主旋律。可以肯定的一点，未来品牌升级之后的京东智联云势必将大力联手各方，通过云、边、端提供丰富、稳定且易用的产品、服务与解决方案，将智能科技落地千万家，民之所想、技术所向。

如今智能经济时代已开启，消费者服务面临升级，企业技术服务的黄金机遇也已到来，我们相信品牌升级之后的京东智联云，未来定将一如既往，利用自身沉淀的能力洞察以及各产业场景中的实战经验，铸造更多“硬核”技术力量服务民生、技术报国，在一线。
————————————————

原文链接：https://blog.csdn.net/sch881226/article/details/104747505

一场突如其来的疫情，打乱了人们春节探亲访友的步伐，“隔离、延迟复工/开学、远程办公”等成为2020开年的关键词，大家的生活方式也随之发生了变化。为打赢这场疫情防控阻击战，数千名医护人员奔赴疫区，与此同时，还有一大批科技公司加入战斗。Nutanix就是这其中的一位。

“与2003年的‘非典’时期不同，随着互联网、云计算的快速发展和应用，再次面对突发事件，很多企业客户已经能够应对自如。”Nutanix中国区董事总经理马莉在接受采访时表示，疫情期间，“远程办公”似乎成为了一种常态现象。相应的，也产生了大量新的需求和新的趋势。数据显示，从2月10号开工以来，全国保守估计有近2亿人通过远程办公的方式工作。这背后所代表是则是一些企业已经利用一系列软件解决方案和应用来应对了近来的不可预测和不确定因素，确保了业务的连续性。毫无疑问，云技术在其中起了重要作用。

作为技术*的企业云软件和超融合解决方案厂商，Nutanix在疫情期间把员工的健康和安全放在首位的同时，也在关注客户的现有产品使用情况。他们积*与合作伙伴进行联络，建立合作伙伴和客户的培训机制等，助力合作伙伴应对此次疫情。

为了更好地助力中国企业保持平稳运行，Nutanix发布了相应的举措来支持中国企业：3月3日，Nutanix宣布向所有中国企业提供桌面即服务（DaaS）解决方案Xi  Frame 的增强免费试用版，帮助中国企业解决因员工无法正常工作而导致的企业生产力下降问题；3月12日，Nutanix宣布新增5个数据中心扩展Xi Frame虚拟桌面服务在亚太和日本地区的可用性，进一步支持受疫情影响企业。

“我们在这个时间段推出一系列的解决方案，就是希望能够帮助到合作伙伴来复工复产，保证业务连续性。”马莉表示，IDC预测，到2021年中国90%以上的企业会采用多云组合的方式，即采用公有云、多云，私有平台这样一个组合的方式来运营它的信息系统。在疫情影响的推动下，我们看到这个进程其实是在加速的，而且很多客户已经在考虑和启动多云环境来推进他的业务了。

多云环境下，虚拟桌面架构（VDI）和桌面即服务（DaaS），成为疫情期间远程办公的理想解决方案，其原因主要有两点：产品的灵活性、方便性，在任何时间、任何地点、任何设备上都可以进行的便捷、安全、高效的远程办公体验；以及对信息的安全、数据的安全，包括如何能够保证效率和长期的投入、产出等优势，被更多的客户和企业关注。

虽然VDI与DaaS都是远程办公场景，但涉及到基础架构层面，两者是大有不同的。Nutanix中国区技术总监夏峰先生介绍到，Nutanix后台的架构可以随着并发用户数增加能灵活、水平地扩展，而且可按需扩展的。现在使用的VDI主要有两大供应商：Citrix和VMware。Nutanix和两家都有着紧密的合作，可以为客户提供整合的VDI解决方案。

夏峰讲到，VDI的优势在于能够为企业带来的*大价值在于其能够让企业在不牺牲业务安全性、生产力或性能的情况下，为人员提供流动性和灵活性。Nutanix 超融合架构是*适合虚拟桌面架构的数据中心架构，这样一种架构就是为了应对并发用户数的提升或者是将来用户突然间的增长。在疫情下，原来很多使用VDI的客户，一下子并发的办公人数增多，对Nutanix提出的需求更多的是扩容，要求增加节点，要求应对更多的用户这样一些需求。当然还有一些客户可能是原来没有考虑VDI，现在要考虑建设远程桌面。

在采访的过程中，夏峰为我们举了澳大利亚客户的一个例子。这个客户临时因为疫情管控，员工不能面对面工作。客户临时决定要把原来的预算用来做VDI，它选用了Nutanix的底层架构。*终，Nutanix只用了两天的时间布了1千个点，让企业的员工在家里面能够拨入到公司里面的一些数据和应用环境，能够支撑它的员工在家里办公。“底层用 Nutanix 易于管理，非常灵活，能够非常迅速地部署，安全性又很高。这些条件其实都可以让用户考虑快速地在Nutanix的产品上部署自己远程办公的系统和环境。”夏峰如是说。

另一方面，就DaaS来说，这其实是一种完全外包的虚拟桌面解决方案。它既不依赖也不占用任何内部硬件资源，能够提供与VDI相同的灵活性、安全性和权限，但完全由第三方处理，并且托管在他们的云上。在公有云市场刚刚兴起的早期阶段，许多服务商就已经可以提供这样的服务。夏峰在采访中还提到，DaaS是可以立即启用，不需要企业在数据中心提供相应的架构来支撑这样的计算和存储，而且云平台就是把这样一个基础架构的建设从一次性投入转变为按需投入的模式。

“Nutanix的Xi Frame其实也是这样的一种解决方案，而且，Xi Frame可以提供各种用户的认证方式，以及任意的交互。”夏峰讲到，目前，Nutanix 的Xi Frame解决方案有两种落地方式：因中国的特殊互联网管理要求，选择与跟国内公有云厂商或者服务提供商合作提供DaaS服务。另外一种，是本地“Xi Frame”，即用户自己把数据或者桌面的分配方式放在云上，企业通过云上的控制平面，在自己的数据中心搭建本地的虚拟桌面。

夏峰强调，如果大家在远程办公中需要使用VDI或者DaaS环境，并且想要获得良好的云体验，就必须保证企业后台的现代化数据中心是一个水平扩展的架构，这个其实也是Nutanix一直致力的方向。

“Nutanix作为一个未来的多云环境当中的重要的提供商，希望能持续的有一些创新的想法，创新的做法，并推到这个市场当中，能够帮中国的客户，帮我们的合作伙伴渡过难关。“正如马莉*后所谈到的，Nutanix已经吹响科技战“疫”的号角，全力为打赢疫情战做努力。
————————————————

原文链接：https://blog.csdn.net/sch881226/article/details/105114609

随着业务对大数据技术需求的不断演变，分布式数据库在整个生态圈中的地位愈加重要，已可预见必将成为未来大数据技术发展的又一个核心，而其中OLAP（联机分析处理）显得尤其重要。

基本理论

数据库的基本理论ACID

原子性（Atomic）。整个事务中的所有操作要么全部完成，要么全部不完成，不可能停滞在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。

一致性（Consistent）。在事务开始之前和事务结束以后，数据库的完整性约束没有被破坏。

隔离性（Isolated）。隔离状态执行事务，使它们好像是在给定时间内系统执行的唯一操作。如果有两个事务，运行在相同的时间内，执行相同的功能，事务的隔离性将确保每一事务在系统中认为只有该事务在使用系统。这种属性有时称为串行化，为了防止事务操作间的混淆，必须串行化或序列化请求，使得在同一时间仅有一个请求用于同一数据。

持久性（Durable）。在事务完成以后，该事务对数据库所作的更改便持久地保存在数据库之中，并不会被回滚。

对于ACID的实现方式主要有两个，一个是日志式的方式（Write ahead logging），几乎所有的数据库系统（MySQL、Oracle等）都基于日志的方式。另外一种是Shadow paging，代表的数据库主要是SQLite，Android或者iOS APP开发的话应该会比较了解，但大型的数据库都不会用到。

图1 事务隔离性一览

分布式数据库的CAP理论

一致性（C）。分布式系统中所有数据备份在同一时刻的值是否相同。

可用性（A）。当集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求（可用性不仅包括读，还有写）。

分区容忍性（P）。集群中的某些节点无法联系后，集群整体是否还能继续进行服务。

图2 CAP三大定律

NoSQL分类

如果同时满足这三点，成本将会非常高，所以建议根据业务的具体需求做好平衡选择。把NoSQL做一个简单分类将包括如下几种：

Key/Value 或 ‘the big hash table’。典型的有Amazon S3 (Dynamo)、Voldemort、Scalaris、Memcached (in-memory key/value store)、Redis等。

Schema-less。典型的有Cassandra (column-based)、CouchDB (document-based)、MongoDB(document-based)、Neo4J (graph-based)、HBase (column-based)、ElasticSearch(document-based)等。

OLTP和OLAP的对比分析

目前分布式数据库主要分为两种场景——OLTP（联机事务处理）和OLAP（联机分析处理）。随着大数据技术发展，数据库选择越来越多，其主要差别包括：面向事务还是面向分析；数据内容是当前的、详细的数据还是历史的、汇总的数据；数据库设计是实体联系模型ER和面向应用的数据库设计，还是星型、雪花模型和面向主题的数据库设计等。前者指的是OLTP场景，后者指的是OLAP场景。

表1 OLTP和OLAP对比

基于分布式数据库的理论，不管是数据库的优化还是设计、使用，遇到的问题非常多。举例说，现在硬件发展很好，特别SSD，如果其设备性能远远没有达到，那么使用SSD的数据库性能该如何提高。如果只是为了满足业务当前的简单需求，可以把现在很多数据库的传输引擎存储直接换成SSD，可以快速地解决很大的问题。另外还有一个很经典的问题，怎么保证在高可靠的前提下提高数据库插入和查询性能。刚才说的是单机模式，多机的分布式模式下又该怎么提高数据调用性能，也有许多挑战。总之，一定要根据业务的需求来选择*合适自己的数据库系统。

分布式数据库实际案例

HBase

在HBase的设计原则中，每个列族可以包含任意多的列，每个列可以有任意多的版本，列只有在有值时才存在，列本身是排序的。

重点看一下Zookeeper的模型，它用了一个非常经典的模型叫Leader/Follower。举个例子说，在去餐厅吃饭时，进餐厅肯定有领班把你领过去，安排到某个座位，点菜则不是他的工作，而由其同事完成，这是非常传统的半同步模型。而Leader/Follower模型是领班把你领过去帮你点菜，他在之前会再选一个Follower做Leader，通过选举制来实现，这样会减少线程的调度，这对数据库的性能会有很大的提升。

图3 HBase中的功能实现

ElasticSearch（ES）

对于分布式数据库里把ElasticSearch也作为一种分布式数据库是有原因的，如果需要快速查询，但列很多，HBase的SQL支持不太好，使用不方便。而ES对于前端工程师开发非常简单，不需要对分布式数据库内核了解很深就可以很快使用起来，而只需要了解RestfulAPI就可以了，并且也很方便。ES底层都是分布式的Lucene，如Github使用Elasticsearch搜索20TB的数据，包括13亿的文件。ES的模型比较清晰比较简单，就两个步骤，一个步骤是怎么把数据建索引，建完索引主要是做查询，怎么把SQL的语句做查询。

图4 ElasticSearch亮点

ES*重要的是建索引，每个的记录都会根据需求建索引，这么做有好有坏——如果突然来了100亿条记录，建索引的时间会很长，对于业务索引是不能忍受的。所以如果支持离线建立索引，后面实时增量建索引这样会更好，目前ES这个模型还不能支持。 但是ES时下已发展的比较成熟，现在能对接的接口都能支持，所以是非常方便的。

分布式数据库系统对比

图5 ElasticSearch功能模块

这里主要对比Pinot和Druid，支持多维度实时查询的分布式系统。

表2 Druid和Pinot功能实现对比

由于Pinot跟ES系统架构很类似，而Pinot比Druid支持存储格式更多一些，所以我们用Pinot和ES做了一个性能测试对比，测试条件如下：

• 记录条数分为100亿以内和1000亿条

• 服务器数量为70台，配置为：CPU 12核，内存96G，硬盘48T

• 测试语句：select count(*) from test where age > 25 and gender > 0 and os > “500” and sc in (“0001009″,”0002036″,”0016030″,”…”) or bs>585 and group by age,gender,os,bs

• 总共12列：动态列为3列（多值列），普通列为9列

表3 ElasticSearch和Pinot百亿条检索对比

表4 ElasticSearch和Pinot千亿条检索对比

对于Pinot和ES有一个共性，他们都有多值列的属性，即类似的属性可以放入同一列，这样查的话大部分需要把一个列的数据查出来，从而更有益于性能。

真实案例分析

业务需求：

1.每天请求数超过 100 亿

2. 每天增长超过 5TB 级数据

3. 每天对几千亿条记录进行上 1000 种维度的计算

4. 客户有流式、实时、离线需求

图6是系统数据流程。

图6 系统数据流程

数据采集用WebService，如Nginx；数据收集服务用Kafka和Flume；数据清洗服务Storm，采用Storm主要有下面两个原因，业务需求在毫秒级需要；有严格要求的时间序列，如原来输入是1、2、3、4、5，输出还必须是1、2、3、4、5。其他用Spark Streaming将会比较好。

接下来把Kafka分流出来的数据对应每一条不同的业务，然后导入对应的存储，如HBase、HDFS等，通过不同的流来解决不同的业务问题，然后基于不同存储做各种算法分析；*后将各种结果数据导入ElasticSearch或者MySQL给前端做数据可视化。

通过阅读上述知识相信各位对分布式数据库的发展和不同系统的技术特点已经有了一定的了解，限于篇幅的原因，笔者以分享几个ES的使用心得结束：

1.用 ES 的 Alias 特性实现数据的水平扩展。

2. 用 Kibana 分析和展现数据（ELK三剑客）可以满足很多公司业务80%以上的需求，ELK是指ElasticSearch、Logstash、Kibana，它们分别功能为：ElasticSearch是负责日志检索和分析；Logstash负责日志的收集，处理和储存;Kibana负责日志的可视化，建议用Kibana4版本。

3. 多条件聚合查询，布尔查询。

4. 定制分词插件（IK），实现对特殊字符的精确匹配，目前现在主流的搜索引擎在搜索关键词的时候对标点符号是忽略的，但是在实现一些对监控微博等社交数据时，如果微博里有很多符号，举例来说“：）”其实代表的是笑脸，而笑脸对于我们来判断正负面是非常有用的，所以判断正负面不只是语义分析的，还有对标点符号分析也非常重要。

作者简介：卢亿雷，AdMaster技术副总裁，资深大数据技术专家。关注高可靠、高可用、高扩展、高性能系统服务，关注Hadoop/HBase/Storm/Spark/Flink/ElasticSearch等离线、流式及实时分布式计算技术。

环境：
物理主机系统：Windows server 2019 Datecenter (v1809, 17763.805)
Docker：Docker for windows 2.1.0.4 (Engine: 19.03.4, Compose: 1.24.1)
MySQL：MySQL for win64 8.0.18 Community Server
Nginx：Nginx for windows 1.16.1
Nextcloud：17.0.0 (hub.docker.com/_/nextcloud, nextcloud:latest, nextcloud:apache, OS:Linux/amd64)
可选附加：
Onlyoffice-document-server： https://hub.docker.com/r/onlyoffice/documentserver, tag:latest
redis： https://hub.docker.com/_/redis, tag:latest
总之除了 Nextcloud，附加的 onlyoffice-document-server 和 redis 之外，其余均为基于 windows 的软件

Nextcloud 镜像的选择：在官方 Docker 页面中主要版本有默认的 Apache 版和采用容器化 Nginx 的 FPM 版，在我个人实际搭建过程中 FPM 版的 Nginx 和宿主机 windows 之间隔着一层 NAT，配置调试起来显得十分麻烦，故选择运行起来更简单的 Apache 版

Docker for windows 安装是全自动创建 Docker Host 的 Hyper-V 虚拟机，网络使用 NAT 转发，Host IP 为 10.75.0.1，Container IP 为 10.0.75.0

MySQL Community 创建好供 Nextcloud 使用的 utf8mb4 编码的数据库(database)，并设置好相关的用户名和密码，也可以直接使用默认的 root 账户，记得要修改密码

NextCloud 和 Nginx 的搭建后续重点讲述

重点讲述：
Nextcloud 容器：
这个其实百度和谷歌上有一大批的教程，只是个人在实际环境运行中出现了各种各样的小细节问题，还有更多的是这些教程大多数都过时了，当然接下来的所有讲述都是仅供参考，毕竟每个人的运行环境都不同

Compose 文本内包含了 redis 缓存容器和 onlyoffice-document-server 文档服务器容器配置，觉得有用请自取

我个人将一些比较重要的文件和 log 通过 volume 挂载到物理系统 windows server 的 D 盘中，Nextcloud 则是直接将整个 PHP 程序和数据文件夹 /var/www/html 转移到 D:/Docker/nextcloud 中，方便以后直接使用 windows 管理文档

nextcloud 容器用的 “wyxls/nextcloud:full” 镜像是我自建的，Nextcloud 的官方镜像默认不带 smbclient 和 crontab，会影响到外部存储挂载 APP 使用 (因为我主要 windows 的 smb 共享)，于是我根据官方提供的 Dockerfile 自建了镜像并上传到 docker hub，不需要的话可以改成 nextcloud 官方的 image ( https://hub.docker.com/_/nextcloud)

Dockerfile example：( https://github.com/nextcloud/docker/blob/master/.examples/dockerfiles/full/apache/Dockerfile)

version: ‘3’
#初始化网络模块，为了让 Nextcloud 和 onlyoffice+redis 协作
networks:
nextcloud:
#services 以下都是容器
services:
#redis 容器，暴露 6379 端口供其他容器使用
redis:
image: redis
container_name: redis
hostname: redis
restart: always
networks:
– nextcloud
expose:
– 6379
#nextcloud 容器，宿主机 10000 端口转发 80 端口访问
nextcloud:
image: wyxls/nextcloud:full
container_name: nextcloud
restart: always
depends_on:
– redis
environment:
– UID=1000
– GID=1000
– UPLOAD_MAX_SIZE=5G
– APC_SHM_SIZE=128M
– OPCACHE_MEM_SIZE=128
– CRON_PERIOD=15m
– TZ=Aisa/Shanghai
– NEXTCLOUD_TABLE_PREFIX=oc_
volumes:
– D:/Docker/nextcloud:/var/www/html
ports:
– 10000:80
networks:
– nextcloud
#onlyoffice 容器，宿主机 10005 端口转发 443 端口访问，在 nextcloud 的 onlyoffice 设置里必须以 https+宿主端口访问
onlyoffice:
container_name: onlyoffice
image: onlyoffice/documentserver:latest
stdin_open: true
tty: true
restart: always
depends_on:
– nextcloud
volumes:
– D:/Docker/onlyoffice/document_data:/var/www/onlyoffice/Data
– D:/Docker/onlyoffice/document_log:/var/log/onlyoffice
– D:/Docker/onlyoffice/document_fonts:/usr/share/fonts/truetype/custom
– D:/Docker/onlyoffice/document_forgotten:/var/lib/onlyoffice/documentserver/App_Data/cache/files/forgotten
ports:
– 10005:443
networks:
– nextcloud
在 Docker 容器中运行的 Nextcloud 默认以 root 权限运行所有程序，所以访问时会提示设置权限 chmod 0770，但在我个人实践中无论是 chown 还是 chmod 都无法解决这个问题，后来还是强行忽略文件权限检查

在 /var/www/html/config/config.php 中加入以下一行：

‘check_data_directory_permissions’ => false, #检查数据目录权限
此外别忘了还要添加 Trusted_Domains，不然 Nextcloud 的 Web 端无法访问：

‘trusted_domains’ =>
array (
0 => ‘example.com’,
1 -> ‘localhost’,
),
Nginx：
由于 Docker for windows 是基于 Hyper-V 虚拟机模拟出的 Linux/amd64 系统，相当于物理 windows——Hyper-V 虚拟机（ Docker Host 宿主机）——Docker Container （容器）两层 NAT 网络，所以需要使用 Nginx 当中间人进行反向代理，下面是我个人配置的 conf，仅供参考

因为我个人的 Windows Server 内网可以直接通过 SMB 访问管理文件，而 Nextcloud 只进行外网访问，所以我只做了 HTTPS 监听+反向代理，有内网 HTTP 访问需求的可以将 SSL 相关部分注释掉

原本在反向代理 proxy_pass 段有 connect, read, send 等 timeout 限制，但后来发现添加后网页访问和 windows 客户端同步变得异常缓慢，而且频繁报错，故删除

server {
listen 10002 ssl; #Nginx 监听端口
server_name example.com localhost 192.168.x.x; #域名, IP, 本地地址都可以填写
root D:/nextcloud; #nextcloud 目录
index index.php;

ssl_certificate D:/SSL-Certificates/fullchain.cer;
ssl_certificate_key D:/SSL-Certificates/private.key;
ssl_protocols SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
ssl_prefer_server_ciphers on;

#以下部分为隐藏 header, 为了解决 nextcloud 自检问题
proxy_hide_header Strict-Transport-Security;
proxy_hide_header X-Content-Type-Options;
proxy_hide_header X-Robots-Tag;
proxy_hide_header X-Frame-Options;
proxy_hide_header X-Download-Options;
proxy_hide_header X-Permitted-Cross-Domain-Policies;
proxy_hide_header Referrer-Policy;
proxy_hide_header X-XSS-Protection;

add_header Strict-Transport-Security “max-age=31536000; includeSubDomains; preload” always;
add_header X-Content-Type-Options nosniff;
add_header X-Robots-Tag “none”;
add_header X-Frame-Options “SAMEORIGIN”;
add_header X-Download-Options “noopen”;
add_header X-Permitted-Cross-Domain-Policies “none”;
add_header Referrer-Policy “no-referrer”;
add_header X-XSS-Protection “1; mode=block”;

client_max_body_size 10G;
fastcgi_buffers 64 4K;
fastcgi_hide_header X-Powered-By;

location / {
proxy_pass http://localhost:10000/; #反向代理地址
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

location = /.well-known/carddav { #解决自检 carddav 未正常配置解析提示问题
return 301 $scheme://$http_host/remote.php/dav;
}

location = /.well-known/caldav { #解决自检 carddav 未正常配置解析提示问题
return 301 $scheme://$http_host/remote.php/dav;
}

location = /robots.txt {
allow all;
log_not_found off;
access_log off;
}

location ~ ^\/(?:build|tests|config|lib|3rdparty|templates|data)\/ {
deny all;
}

location ~ ^\/(?:\.|autotest|occ|issue|indie|db_|console) {
deny all;
}

}
在初步搭好 Nextcloud 后实际使用中经常出现访问超时，原因是 Nextcloud 在反向代理中可能会无法侦测正确的协议，需要强行覆写（ Nextcloud 默认 latest 镜像用 Apache 作为 Web server 监听 HTTP 80 端口）

‘overwriteprotocol’ => ‘https’,
额外部分：
Onlyoffice-document-server：
Nextcloud 官方提供连接 onlyoffice 服务的 APP，与 onlyoffice 对接后能实现 Nextcloud 内通过 Web 访问直接打开并编辑 office 相关文档 (pptx, xlsx, docs 等)，通过 Docker 可以一键配置

version: ‘3’
services:
onlyoffice:
container_name: onlyoffice
image: onlyoffice/documentserver:latest
stdin_open: true
tty: true
restart: always
depends_on:
– nextcloud
volumes:
– D:/Docker/onlyoffice/document_data:/var/www/onlyoffice/Data
– D:/Docker/onlyoffice/document_log:/var/log/onlyoffice
– D:/Docker/onlyoffice/document_fonts:/usr/share/fonts/truetype/custom
– D:/Docker/onlyoffice/document_forgotten:/var/lib/onlyoffice/documentserver/App_Data/cache/files/forgotten
ports:
– 10005:443
networks:
– nextcloud
证书安装：在 /var/www/onlyoffice/Data 中建立”certs”文件夹并将 SSL 证书及私钥以”onlyoffice.crt”和”onlyoffice.key”保存，或者直接在 yml 中 environment 环境参数添加，在 Docker-Settings-Shared Drives 设置共享后可以直接使用 windows 物理路径指定，比如：D:\SSL-certificates\onlyoffice.crt

environment:
– SSL_CERTIFICATE_PATH=证书路径
– SSL_KEY_PATH=私钥路径
通过访问 https://example.com:10005 可以查看 Document Server 运行状况，显示 Document Server is running 表示成功

*后在 Nextcloud 内设置 Document Editing Service address 为 https://example.com:10005，如果页面下方出现 settings 一类选项则表示已成功连接

Redis：
Nextcloud 官方推荐使用 Redis 缓存 Nextcloud，我自己也不太懂原理，但官方既然推荐了就一起部署上啦

version: ‘3’
services:
redis:
image: redis
container_name: redis
hostname: redis
restart: always
networks:
– nextcloud
expose:
– 6379
记得要在 Nextcloud 对应的 config/config.php 中添加相关内容

‘memcache.local’ => ‘\OC\Memcache\APCu’, #redis
‘memcache.distributed’ => ‘\OC\Memcache\Redis’, #redis
‘memcache.locking’ => ‘\OC\Memcache\Redis’, #redis
‘redis’ => array( #redis
‘host’ => ‘redis’, #如果 redis 部署在物理机上填 localhost,这里由于 redis 和 nextcloud 在同一网络 nextcloud 内，所以可用 redis 代替
‘port’ => 6379,
),
结语：
onlyoffice 目前我个人测试只能在 Docker 内部 Nextcloud 使用，详细原因猜测是 onlyoffice 内置的 Nginx 没正确配置监听或允许外部网络域名访问（反正我软路由的另一个 Nextcloud 对接时显示 Connetion refused ）

我凭借着记忆将大致的搭建过程写了出来，难免会有所纰漏，烦请各位朋友查漏指正，有什么问题可以回复交流

此外如果对过程中任何一部分有修正改进的建议，请务必告诉我，我对 Nginx、PHP、MySQL 参数调优真的是一窍不通

牢骚话：

有人可能会问为什么不干脆用 Linux 物理系统来搭，没辙啊，老爸只会用 windows，老妈想着吃饭时间连上去看 iqiyi 的电视剧，家里其他人又想摆一台公用的共享 NAS，我自己对 centOS 又不是特别熟悉，*后翻了一大堆的论坛帖子、网站文章自己摸索，目前也就只能这样先用着了

其实*关键是没钱买群晖，而且家里人的要求比较杂，群晖不能很好地满足，于是这份攻略就诞生了

曾经想过 ESXi 6.7 组建 FreeNAS + centOS + Docker (Nextcloud)+ Windows 7 的大虚拟机，把路由 LEDE 也虚拟化，从此就可以把那台软路由也扔掉，但后来发现搞不定 N 卡直通后给 Windows，重启虚拟机就带着 ESXi 一起死机的问题。据谷歌搜索说是因为 ESXi 6.7 在显卡*次直通给虚拟机后关机时没能正常 reset 显卡状态，导致第二次虚拟机启动时显卡处于正在使用状态而带着宿主机一起 Boom，折腾了两天还是解决不了，随后我就放弃并滚回去用 windows 了