架构

前言JVM是java的核心和基础，在java编译器和os平台之间的虚拟处理器。它是一种基于下层的操作系统和硬件平台并利用软件方法来实现的抽象的计算机，可以在上面执行java的字节码程序。java编译器只需面向JVM，生成JVM能理解的代码或字节码文件。Java源文件经编译器，编译成字节码程序，通过JVM将每一条指令翻译成不同平台机器码，通过特定平台运行。这里就给大家讲一下JVM。技术大咖带你垂直打击JVM什么是运行时数据区? 我们一起来分享。了解JVM底层原理,让你的代码撸得飞起。搞定内存溢出，涨薪升职。涨见识，字节码执行过程分析。直击真相，原理和代码全都有。测试、效果演示及总结。JVM是什么？JDK: java development kit (Java开发工具包) 编译、反编译、调试等。JRE: java runtime enviroment (Java运行环境)JVM: java Virtual Mechinal (Java虚拟机) 一次编写，到处运行！学jvm的目就是：提升代码质量、解决项目问题。面试！面试！还是面试！JVM是怎么玩的类加载器：Class字节码文件加载到内存执行引擎：解析字节码指令，得到执行结果运行时数据区JVM运行时数据区线程私有程序计数器虚拟机栈本地方法栈线程共享堆列表项目方法区BAT的JVM面试题JVM什么情况下会发生栈内存溢出？JVM中一次完整的GC流程是怎样的？GC——垃圾回收完整意味着有多种情况程序计数器指向当前线程正在执行的字节码指令的地址(行号)栈是什么？栈（Stack）入口和出口只有一个入栈出栈FILO先进后出虚拟机栈虚拟机栈创建一个线程就为线程分配一个虚拟机栈，它又会包含多个栈帧，因为每运行一个方法就创建一个栈帧。运行时才有数据栈帧运行一个线程中的一个方法1.局部变量表2.操作数栈3.动态连接4.返回地址深入理解虚拟机栈演示一段代码的方法的执行过程代码：public int calc(){int a=100;int b=200;int c=300;return(a+b)*c;}虚拟机栈的异常StackOverFlowError异常原因：执行的虚拟机栈深度大于虚拟机栈允许的最大深度(方法的递归调用)。解决办法：增加默认栈的容量。栈容量 -Xss 默认1MOutOfMemeoryError异常原因：多线程环境下虚拟机在扩展栈时无法申请到足够的内存空间。解决办法：减少默认栈的容量来换取更多的线程支持。JVM中线程共有的内存区域Java堆Java堆是被所有线程共享的一块内存区域所有的对象实例以及数组要在堆上分配元数据区老版本名称：方法区(永久代)类信息、常量、编译后的代码信息直接内存以上源于一个视频讲解的概述总结，后续将分享后半部分的内容：可达性分析算法——GC RootsJVM中的堆新生代为什么分三个区？新生代对象的分配和回收老年代对象的分配和回收JVM中一次完整的GC流程是怎样的？如果有兴趣想了解视频具体内容的可以关注我，加入我的合作群（805685193）即可获取原视频。还有一些Java架构视频讲解，需要获取Dubbo、Redis、设计模式、Netty、zookeeper、Spring cloud、分布式、高并发等架构技术视频教程资料，架构思维导图，和BATJ面试题及答案的，都是免费分享的。关注我，加入我的合作群（805685193）即可获取视频。

摘要： 数据库的架构升级就好像是在给一个高速运行的飞机更换引擎。2019年1月4日，OceanBase迁移服务解决方案在ATEC城市峰会中正式发布。蚂蚁金服资深技术专家师文汇和技术专家韩谷悦共同分享了OceanBase迁移服务的重要特性和业务实践。蚂蚁数据库架构的三代升级史在过去的十多年时间里，蚂蚁在整个基础数据库架构上一共经历了三代升级。第一代数据架构是构建在IOE的基础之上——IBM的小型机、Oracle的商业数据库，还有EMC的共享存储。基于第一代IOE架构的运维成本是非常高的，同时稳定性的挑战也是非常大的。随着业务的快速发展，这套架构已经完全没有办法适应业务发展的增速。随之诞生的是第二代架构，第二代架构的主体是OE——也就是Oracle和EMC，加上蚂蚁自身的分布式中间件，解决了业务的水平和垂直的弹性能力。这一代架构其实伴随着蚂蚁走了很多年。随着4G、5G时代的到来和金融的普及化，人们的生活越来越离不开移动支付，业务井喷式的发展给底层的数据库提出了更高的要求。这些要求包括更高的稳定性，快速恢复能力和极致的弹性能力等。于是最终演进到了我们如今的第三代架构。第三代架构是由OceanBase为代表的金融级云数据库和分布式中间件所构成。数据库架构升级的挑战伴随着整个蚂蚁的发展，整个数据库的架构也仅仅演进了三代。这其中一个很重要的原因就是对于任何企业而言，整个数据库的架构升级都是一件非常有挑战的事情。蚂蚁金服资深技术专家师文汇说道，“用一个我们内部经常说的比喻，就是数据库的架构升级就好像是在给一个高速运行的飞机更换引擎。”更换引擎的目的是为了拥有更好的动力，做更多技术上的创新。但是横亘在眼前的问题是，如何才能做到稳妥创新，保证驾驶中的飞机平稳顺利的运行，这其实是有非常大的挑战。在过去三代架构的演进中我们可以看到，本质上每一代架构的迭代基本上都是以两到三年为周期，这其中会有非常高的人力投入和成本开销。第二个挑战就是从传统的商业数据库迁移到OceanBase数据库之上，我们如何保证迁移过程中以及迁移以后的稳定性。另外一个非常大的挑战就是数据质量，在金融企业里，数据承载的不仅只是钱，更承载了数以亿计用户的信任。所以数据一条不能丢，一条不能错，这是我们做数据库的底线。当然，包括兼容性问题和性能风险也给数据库的架构升级带来重重挑战。OceanBase迁移服务：向分布式架构升级的直接路径基于上述问题和挑战，同时经过蚂蚁十年数据库架构升级的先进经验，蚂蚁金服为客户打造了这款一站式数据迁移解决方案——OceanBase迁移服务（OceanBaseMigration Service，简称OMS）。OMS的发展演进OMS的演进是以业务为驱动，并且与OceanBase的架构升级和不断发展密不可分。早在2014-2015年期间，蚂蚁主站上的一些核心业务，包括大家熟知的交易业务，支付业务和会员业务等，需要从Oracle迁移到OceanBase上。当时的OMS还是以一个工具类、模块化的形态支撑着这些项目。所以在2015年我们开始对OMS的方案进行全面的调研，力求沉淀出通用的系统化的解决方案。在2016年，OMS已经有了平台化的架构，引入了大规模编排的思想，将整个迁移特别是切换过程中繁琐易错的环节全部集成到平台。这一时期，OceanBase也完成了从0.5版本到1.0版本的架构升级，这一年OMS还支撑了网商银行、印度PayTM以及主站的核心业务升级到OceanBase 1.0版本。到了2018年的时候，无论在基础功能层面还是任务编排层面，OMS都已经被打磨得日趋完善。今年OMS已经支持了蚂蚁森林，蚂蚁商户平台以及众多大量核心及非核心的业务从MySQL迁移到OceanBase之上。与此同时，在外部业务包括很多已经上线OceanBase的商业银行，也已经验证了使用OMS一键迁移到OceanBase的能力。OMS的方案优势OceanBase迁移服务其实主要解决了五个重要的问题。1.负载回放验证：其中第一个核心的问题就是负载回放验证，通过采集源端数据库的SQL流量，在目标库OceanBase上回放，可以验证其在OceanBase上的功能是否兼容、性能是否出现问题等。同时基于蚂蚁DBA十多年的经验沉淀，OMS会为客户提供性能等方面的调优建议。2.秒级数据校验：第二点就是数据校验，OMS有三层数据校验，可以做到秒级的延迟。举一个例子，比如说我们想把传统商业数据库替换成OceanBase，如果在迁移过程中任何一条数据出现了错误，在一秒钟内就可以快速发现。校验的延迟可以完全保证在一秒以内，根据蚂蚁线上的经验，大概在100-200毫秒之间。3.分钟级即时回滚：第三点也是最重要的一点，就是OMS有随时回滚的能力，而且回滚是无损的。这也是我们前面所强调的稳妥创新的基石。4.多种数据库类型支持：目前OMS支持源端数据库类型有Oracle、MySQL、OceanBase等等，支持全量迁移和增量数据同步。5.一键完成迁移：整个数据迁移链路和回滚机制的搭建基本上都是通过一键操作完成，使用简便。OMS的技术架构OMS的核心方案其实非常简单，我们把OceanBase变成Oracle/MySQL的一个备库。传统的商业数据库一般都是有主库和备库的：主库承担写的流量，如果主库出现问题，我们会把数据切到备库，然后通过OMS提供的一整套虚拟主备库的解决方案完成切换。比如原来Oracle有一个主库一个备库，然后OceanBase其实变成了一个虚拟的备库。整个数据库架构的升级也会变得异常简单，简单到只是做了一个主备切换。回滚也会变得非常简单，其实也是做了一次主备切换。从OMS的整体架构来看，其实一个非常关键的点就是，我们在传统的商业数据库和OceanBase之间建立了一套虚拟的主备链路，整个OMS里用到的所有组件，其实都是在蚂蚁和阿里有很多年技术沉淀的，也都是基于真实场景所产生的。OMS的迁移流程OceanBase迁移服务的整体迁移流程其实只有七步。1.评估：首先第一步是通过负载回放工具做兼容性分析;2.PoC：接下来OceanBase云平台可以帮助客户部署一套PoC集群;3.预迁移：然后OMS把线上的Oracle的数据预迁移到一个测试库里；4.验证：在这个测试库里用负载回放工具去回放这些SQL，然后找到SQL里不兼容，性能或者数据质量不满足预期的部分，并提供优化建议；5.正式迁移：前四步做完了以后，业务需要调整或者需要优化的SQL已经完成优化，然后就可以正式迁移了。首先把原有的全量数据迁过来，然后再把增量变化的那部分数据实时同步过来；6.校验：等到所有的数据准备好以后，然后我们继续完成三级校验；7.切换和回滚：等到所有的校验都完成以后，可以一键完成切换和回滚功能。通过这七步就可以轻松完成从传统商业数据库到分布式数据库的完整迁移。蚂蚁商户平台基于OMS的业务实践蚂蚁商户平台承载着商户档案数据信息，订购关系、签约信息的数据和相应的服务能力。其中一部分业务使用的是MySQL数据库，还有一部分核心业务使用的是Oracle数据库。随着商户的快速增长以及业务场景的不断丰富，商户平台数据增长迅速，数据规模相当庞大。尤其是MySQL的单表瓶颈日益明显，DDL变更、DML更新的性能与风险已经无法承担。蚂蚁金服技术专家韩谷悦介绍道，“OceanBase能够支持数据的无限扩展，满足商户业务的容量与性能需求。那么如果我们换一种数据库底盘，其实所要面对的性能、稳定性和数据质量的风险同样不可避免。”从蚂蚁商户平台的业务实践来看，使用OMS迁移与传统迁移进行对比，我们可以看到：业务评估和改造过去通常一个业务少则花费1-2个月的时间去做改造和适配；那么基于OMS自动化的SQL兼容性评估和负载回放的能力，蚂蚁商务平台业务的改造大概只用了一个星期的时间。数据迁移和校验客观来讲，迁移的总时长主要取决于业务数据模型，数据量和网络环境。在提高迁移效率方面，OMS目前增量迁移的延迟仅为毫秒级，跨城情况下最长只需要3秒。并且针对校验出的数据差异提供补齐的SQL和订正方案，使得迁移和校验的整体效率有了大幅度的提升。业务切换其实在切换之前，往往需要制定严密的切流方案和Failover方案，整个切换过程中需要检查与校验的细节非常繁琐，任何一步疏忽都有可能造成数据不一致的问题。那么OMS通过引入大规模编排的思想，把所有繁琐复杂的环节通通落到平台当中。所以从原来业务切换需要用时1-2周时间， 使用OMS后蚂蚁商户平台业务无论是切读还是切写的过程中都只用了几分钟的时间。业务回滚在过去，迁移之后的业务回滚要担负重大的决策风险，OMS使得业务回滚就像一次主备切换，可以瞬间完成并且不丢数据，所以让业务回滚不再成为难题。商户业务整体迁移的过程中也发生过业务抖动，使用OMS回滚的时候从登陆系统到完成回滚也只用了几分钟的时间。所以全程下来蚂蚁商户平台这个业务的迁移时间大概在三个多星期的时间完成，那么无论从人力成本还是时间成本上，OMS都极大地提升了数据库的整体迁移效率。最后，韩谷悦为大家展示了OMS一键迁移的demo演示。当前， 越来越多的企业已经认识到分布式架构在实现业务灵活扩展以及敏捷开发等方面的巨大价值。OceanBase不断通过产品端的革新，为传统企业输送“互联网基因”，帮助更多客户向分布式架构转型。同时OceanBase也在不断提高服务客户的深度和广度。深度意味着在同样的业务场景下，随着业务的发展和体量的壮大，帮助更多企业承担起业务所带来的极致压力。广度则针对的是随着新型技术形态和业务场景的出现，帮助更多企业快速响应，通过技术创新而适应变化所带来的新的市场契机。OceanBase致力于将蚂蚁自身业务多年沉淀下来的最浓缩，最经典和最普世的方法论输出给广大的企业客户，同时做到深度和广度并存，真正帮助客户实现稳妥创新。本文作者：平生栗子阅读原文本文为云栖社区原创内容，未经允许不得转载。

摘要： OceanBase是一个通用的分布式的关系型数据库，有很多独特的特点。比如数据库的多租户、高可用、极致弹性伸缩能力。如果把OceanBase当作单库使用，就没有把OceanBase的分布式优势发挥到极致。前言OceanBase是一个通用的分布式的关系型数据库，有很多独特的特点。比如数据库的多租户、高可用、极致弹性伸缩能力。如果把OceanBase当作单库使用，就没有把OceanBase的分布式优势发挥到极致。本文主要分享一个基于分布式架构的应用把OceanBase数据库的分布式优势发挥到极致所需要了解的OceanBase基础，这也是理解蚂蚁金服的基于OceanBase构建的三地五中心异地多活架构的基础。分布式数据库开发相关问题好的性能首先是设计出来的，应用如果追求极致的性能，就需要关注OceanBase里数据的相关事情。如：数据如何分布？数据如何读写？存储容量瓶颈怎么办？访问性能瓶颈怎么办？数据库出故障时数据可用性和可靠性具体怎样？应用需要做什么特殊处理么？数据库扩展时应用需要迁移数据么？数据迁移的时候对应用有什么影响？这些问题对理解OceanBase的分布式特点很有帮助。后面我们逐步看看OceanBase是如何应对。OceanBase集群外观首先简介一下OceanBase集群的外观。OceanBase是以集群形式运行的，由一堆服务器组成。上图是「三副本」部署，机器会分为三组，每组一个区域（称为Zone），各个机器通过网络互相访问。没有光纤交换机、共享存储以及直连网线等。服务器通常建议CPU、内存和磁盘尽可能的大，磁盘建议用普通SSD盘。普通服务器的好处是便宜，劣势是可靠性和性能可能不如小型机那么高。也就是说OceanBase可以部署在一组可靠性和性能不是特别高的普通服务器上，却提供了高性能、高可用和高可靠、弹性伸缩等多项能力。以上是一个OceanBase集群的外观和能力，但是提供给业务的并不是这个集群的全部资源和能力，而是其子集，即租户（Tenant）。OceanBase多租户特性OceanBase定义了一些基本的资源规格（Resource unit config，如4CPU8Gmem500Gdisk等），然后选取某类资源规格创建一组资源池（Resource Pool），此时集群资源就有一部分被分配出去了。最后将这个资源池关联到一个新建租户，则租户就可以使用这个资源池的能力。OceanBase默认有个sys租户，管理整个集群。用户租户必须在sys租户内部创建。如下示例就是创建租户的过程。#sys租户登录方法$mysql -hxxx.xx.11.11 -uroot@sys#obdemo -P2883 -proot oceanbase -A#资源规格（UnitConfig）create resourceunit S0_uc max_cpu=2,max_memory=‘5G’,…资源单元（Unit）create resourcepool Pool_01 unit=‘S0_uc’,unit_num=2,…租户（Tenant）create tenant test_ins resource_pool_list= (‘Pool_01’),…OceanBase兼容了大部分MySQL连接协议和语法，租户的使用体验跟MySQL实例很像。研发可以在租户里创建数据库（Database）、表（Table）。还包括分区表等。OceanBase里描述数据的最小粒度是分区。普通的表（非分区表）就是一个分区，分区表则包含多个分区。租户的示意图如下。租户之间数据是绝对隔离，资源有一定程度隔离。研发可以将业务先垂直拆分为多个独立的子业务，分别使用不同的租户或者集群。OceanBase资源单元租户里并不知道数据具体在哪个机器上，也可以说没必要知道。只是租户的性能还取决于运维为租户规划的资源池分布情况，所以了解一下资源单元的分布特点对性能规划也是有意义的。资源池（Resource Pool）是由一组资源单元（Resource Unit）组成。资源单元数量默认跟Zone的数量一致或者是它的倍数（可以配置具体分布在哪些Zone以及每个Zone里的Unit数量）。如下图资源单元具备一定的资源能力，是数据的容器。租户拥有的资源单元规格和数量决定了这个租户最大性能。资源单元可以在同一个Zone的不同节点之间自由迁移，OceanBase借此来维持各个节点的资源利用率尽可能维持一个均衡状态。OceanBase拆分设计数据库拆分数据库拆分有两种。一是垂直拆分。即按业务模块拆分到不同的实例或库里。为了模块之间互不影响，拆分到不同的实例比较好。在OceanBase里实现时可以是拆分到同一个集群里不同租户或者不同集群里的租户都可以，取决于业务规模和数据库集群规模。垂直拆分很好理解，后面不再赘述。一是水平拆分。即按某个业务维度将数据拆分到多个分片。这些分片可以是在一个库或者不同库或者不同实例的不同库下。水平拆分实现又有两类常用的选择。如下：分库分表。将一个业务表拆分到N个相同结构的物理表中。中间件做业务表（逻辑表）到分表（物理表）的映射路由以及其他相关操作（如结果聚合计算）等。这个N个物理表可以在不同实例的不同分库中。分库的维度和分表的维度可以不一样，比较灵活。分区表。将一个物理表设计为分区表，拆分到N个分区。分区表的各个分区结构是数据库内部保证一致。OceanBase选择的是分区表的水平拆分方式，并且支持二级分区表（即有2个不同的拆分维度叠加使用）。水平拆分示意图如下：上图是分库分表和分区表同时结合使用。业务表order先经过中间件拆分为100个分表（存在10个分库里），每个分表在OceanBase内部又是一个分区表（100个分区）。分库分表的维度和分区表分区的维度都是一致的，根据用户ID。分库分表和分区各有利弊。分库分表的好处是各个分表的结构一致性是在中间件层保证，比较好控制，比较适合灰度变更（允许部分分表结构不一致，最终必须全部一致）。此外更大的好处是，分库分表是实现异地多活单元话架构的必不可少的条件。缺点是中间件的SQL支持范围有限。分区的好处是在数据库内部解决了拆分问题。针对分区表的SQL功能是数据库SQL引擎的本质工作，相关特性（全局索引、二级分区等）会持续开发完善。分区分库分表架构设计，需要确定机器数、实例数、分库数和分表数的拓扑，性能理论上限取决于主实例所处的机器节点数。此后要做扩展就要调整这四个元素的数目及其联系。这种扩展很可能涉及到分表数据的迁移，需要借助外部工具或产品实现。分区架构设计，研发确定分区策略和分区数，运维确定租户的资源单元数量，OceanBase确定资源单元（Unit）在哪些机器节点上以及分区（Partition）在哪些资源单元里。同一个分区不能跨节点存储。如下图。此后要做扩展就是调整资源单元的规格、数量。OceanBase在确定Unit里的分区的位置时会尽量让每个节点的负载维持均衡。这个负载的计算方式比较复杂，会综合考虑OB节点内部CPU、内存和空间利用率等。分区随意分布对应用性能很可能有负面影响。当业务上有联系的两个表的分区分布在不同的资源单元里（同时也分布在不同的节点里），这两个表的连接就难以避免跨节点请求数据，网络上的延时会影响这个连接的性能。注： t1(p0) 表示表t1的0号分区。每个分区在集群里数据实际有三份，即三副本（Replica）。图中忽略了Zone2和Zone3的细节。三副本之间的数据同步靠把Leader副本的事务日志同步到其他Follower副本中。Paxos协议会保障这个事务日志传输的可靠性（事务日志在一半以上成员里落盘，剩余成员最终也会落盘），同时还有个以分区为粒度的选举机制，保障Leader副本不可用的时候，能快速从现有两个Follower副本里选举出新的Leader副本，并且数据还绝对不丢。这里就体现了故障切换时两个重要指标：RPO=0， RTO<30s。Locality图5中t0和t1业务上是有联系的表（如主表和详情表），两者都是分区表，分区策略和分片数都相同，OceanBase提供了一个表属性“表分组”（TableGroup）。设置为同一个表分组的不同表的分区数一定一样，并且同号分区组成一个“分区分组”（PartitionGroup）。同一个分区分组的分区一定会分配在同一个资源单元（Unit）内部（也就是会在同一个节点内部），彼此的连接逻辑就避免了跨节点请求。另外一个效果是如果一个事务同时修改两个有业务关联的分区，使用分区分组也可以规避跨节点的分布式事务。这个表分组属性的设置就是OceanBase的Locality特性之一——影响相关分区的分布。实际上每个分区都有三副本（Replica, 本文例子），图5中省略了t0(p0)和t1(p0)的其他两个副本都分别会在同一个Unit里分配。不仅如此，每个分区的三副本里都会有leader副本默认提供读写服务。leader副本是选举出来的。t0(p0)和t1(p0)的leader副本也一定会在同一个Unit里（即在同一个Zone里）。这样才彻底的避免了连接的时候跨节点请求。OceanBase的Locality特性还可以指定租户/数据库/表的默认Zone，这样下面的表的leader副本会优先被选举为这个Zone里副本。如下面例子，数据库和表会继承租户的默认设置，当然也可以自己修改primary_zone或者locality属性覆盖上层设置。：create tenant obtrans0primary_zone=‘hz1’;create table item (…)locality = ‘F@hz1, F@hz2, F@hz3,R{all_server}@hz1, R{all_server}@hz2, R{all_server}@hz3’注：F表示全功能副本，R表示只读副本。设置primary_zone后单个租户的所有表的读写都集中到一个Zone里，该租户在其他zone里的Unit就没有读写压力。通常这样做是源于业务应用的要求。如应用的请求都是来自于这个Zone，为了规避应用跨Zone读写数据性能下降。不过primary_zone更大的意义在于当集群里有很多租户的时候，可以将不同业务租户的读写压力分摊到不同Zone的机器，这样集群整体资源利用率提升，所有应用的总体性能也得到提升。后面要介绍的异地多活架构就充分利用OceanBase这个特性，在数据库层面将拆分的表的业务读写点尽可能分散到所有Zone的所有机器上。除了表与表之间可能有联系，业务模块之间也可能有联系。一个业务过程可能会横跨多个业务模块，前面这些模块的数据被垂直拆分到多个租户里。OceanBase的Locality特性“租户分组”（TenantGroup）还可以设置不同租户之间的联系。如下租户交易订单和支付订单在业务上是先后发生。create tenantgroup tgtrade tenant_array=(‘obtrade0’, ‘obpay0’);租户分组的意义依然是为了在分布式架构下尽可能将一个业务流程内多次数据库请求都约束在同一个Zone或者Region（注：OceanBase将地域相邻的Zone定义为一个Region）里。OceanBase异地多活架构异地多活概念异地多活的概念一直都有，只是内涵不断变化。以双机房多活为例，应用通常都是无状态的，可以多地部署。数据库有状态，传统数据库只有主库可以提供读写，备库最多只能提供只读服务（如ORACLE的Active Dataguard）：1. 应用双活，数据库A地读写，B地不可读写。这种只有应用多活，数据库是异地备份容灾（无并发）。2. 应用双活，数据库A地读写，B地只读。这种也是应用双活，数据库读写分离（实例级并发）。3. 应用双活，数据库双活，两地应用同时读写不同表。这种数据库双向同步，应用同时错开写不同的数据（表级并发）。4. 应用双活，数据库双活，两地应用同时读写相同表不同记录。这种数据库双向同步，应用同时错开写不同的数据（行级并发）。5. 应用双活，数据库双活，两地应用同时读写相同表相同记录。这种数据库双向同步，应用同时写相同的数据，最终会因为冲突一方事务回滚（行级并发写冲突）上面第1种情形，B地应用是跨地域远程读写数据库。两地距离较大的时候性能会很不好。2的B地应用是本地访问数据库。3，4，5三种情形两地数据库都提供读写服务，对应用而言是本地访问数据库，但到分布式数据库内部，其要读写的数据是否正好在本地就取决于业务和数据库的拆分设计。有这么一种情形，B地应用访问B地数据库实例，请求的数据的写入点恰好是A地，这样会走分布式数据库内部路由远程A地实例中拿到数据，性能上会有些下降，而业务可能不知道为什么。OceanBase水平拆分方案为了避免在分布式数据库OceanBase内部发生跨Zone请求，应用的请求流量的水平拆分规则和数据的水平拆分规则要保持一致并联动，就可以实现真正的应用向本地实例请求读写的数据恰好就是在本地实例种。这就是Locality的用途所在。首先业务架构层面能根据用户ID（uid）做拆分，将用户拆分为100分。x和y是用户直接相关的表，都根据uid拆分为100个分表，分布在5个不同的租户里。x[00-19]表示20个分表。每个租户的Leader分别分布在不同的Zone。uid:00-19表示 分到这20个分片的用户数据和用户流量。应用层面在某个环节能根据UID将用户请求转发到对应的机房（Zone），应用服务之间的请求信息都有这个UID信息，后面应用请求都在本机房流转，并且访问数据库时通过分库分表中间件（DBP）和OceanBase的反向代理（OBProxy）就路由到本机房的业务租户上。实际使用这个架构时，有几个隐含的前提，Zone1和Zone2是同城双机房，Zone3和Zone4是同城双机房，两个城市靠的比较近，Zone5 实际很远，所以一般不提供写入。为节省空间，Zone5里的副本放的是日志副本。应用异地多活架构上面要实现OceanBase在每个Zone的应用写入都是恰好是本地访问，关键点就是应用流量水平拆分规则跟数据水平拆分规则保持一致。而应用要维持这样一个规则，需要很多产品都要支持水平拆分等。如下图图中流量接入层的“负载均衡”环节负责调整用户流量到对应的机房（Zone），此后的应用之间的请求就都是本地访问。能使用这个解决方案的业务都是能按用户维度做水平拆分。有些业务的拆分维度跟用户维度是冲突的，或者有些业务的数据只支持集中写入等，不能做到上面这种多活，但也可以使用OceanBase，实现单点写入，多点读取的功能。OceanBase在异地容灾和多活架构方案中的价值就是支持水平拆分规则的定义、解决了多个机房间数据同步和一致性问题、始终具备高可用和弹性伸缩能力等。参考OceanBase负载均衡的魅力蚂蚁金服异地多活的微服务体系本文作者：mq4096阅读原文本文为云栖社区原创内容，未经允许不得转载。

2019年1月4日，OceanBase迁移服务解决方案在ATEC城市峰会中正式发布。蚂蚁金服资深技术专家师文汇和技术专家韩谷悦共同分享了OceanBase迁移服务的重要特性和业务实践。蚂蚁数据库架构的三代升级史在过去的十多年时间里，蚂蚁在整个基础数据库架构上一共经历了三代升级。第一代数据架构是构建在IOE的基础之上——IBM的小型机、Oracle的商业数据库，还有EMC的共享存储。基于第一代IOE架构的运维成本是非常高的，同时稳定性的挑战也是非常大的。随着业务的快速发展，这套架构已经完全没有办法适应业务发展的增速。随之诞生的是第二代架构，第二代架构的主体是OE——也就是Oracle和EMC，加上蚂蚁自身的分布式中间件，解决了业务的水平和垂直的弹性能力。这一代架构其实伴随着蚂蚁走了很多年。随着4G、5G时代的到来和金融的普及化，人们的生活越来越离不开移动支付，业务井喷式的发展给底层的数据库提出了更高的要求。这些要求包括更高的稳定性，快速恢复能力和极致的弹性能力等。于是最终演进到了我们如今的第三代架构。第三代架构是由OceanBase为代表的金融级云数据库和分布式中间件所构成。数据库架构升级的挑战伴随着整个蚂蚁的发展，整个数据库的架构也仅仅演进了三代。这其中一个很重要的原因就是对于任何企业而言，整个数据库的架构升级都是一件非常有挑战的事情。蚂蚁金服资深技术专家师文汇说道，“用一个我们内部经常说的比喻，就是数据库的架构升级就好像是在给一个高速运行的飞机更换引擎。”更换引擎的目的是为了拥有更好的动力，做更多技术上的创新。但是横亘在眼前的问题是，如何才能做到稳妥创新，保证驾驶中的飞机平稳顺利的运行，这其实是有非常大的挑战。在过去三代架构的演进中我们可以看到，本质上每一代架构的迭代基本上都是以两到三年为周期，这其中会有非常高的人力投入和成本开销。第二个挑战就是从传统的商业数据库迁移到OceanBase数据库之上，我们如何保证迁移过程中以及迁移以后的稳定性。另外一个非常大的挑战就是数据质量，在金融企业里，数据承载的不仅只是钱，更承载了数以亿计用户的信任。所以数据一条不能丢，一条不能错，这是我们做数据库的底线。当然，包括兼容性问题和性能风险也给数据库的架构升级带来重重挑战。OceanBase迁移服务：向分布式架构升级的直接路径基于上述问题和挑战，同时经过蚂蚁十年数据库架构升级的先进经验，蚂蚁金服为客户打造了这款一站式数据迁移解决方案——OceanBase迁移服务（OceanBaseMigration Service，简称OMS）。OMS的发展演进OMS的演进是以业务为驱动，并且与OceanBase的架构升级和不断发展密不可分。早在2014-2015年期间，蚂蚁主站上的一些核心业务，包括大家熟知的交易业务，支付业务和会员业务等，需要从Oracle迁移到OceanBase上。当时的OMS还是以一个工具类、模块化的形态支撑着这些项目。所以在2015年我们开始对OMS的方案进行全面的调研，力求沉淀出通用的系统化的解决方案。在2016年，OMS已经有了平台化的架构，引入了大规模编排的思想，将整个迁移特别是切换过程中繁琐易错的环节全部集成到平台。这一时期，OceanBase也完成了从0.5版本到1.0版本的架构升级，这一年OMS还支撑了网商银行、印度PayTM以及主站的核心业务升级到OceanBase 1.0版本。到了2018年的时候，无论在基础功能层面还是任务编排层面，OMS都已经被打磨得日趋完善。今年OMS已经支持了蚂蚁森林，蚂蚁商户平台以及众多大量核心及非核心的业务从MySQL迁移到OceanBase之上。与此同时，在外部业务包括很多已经上线OceanBase的商业银行，也已经验证了使用OMS一键迁移到OceanBase的能力。OMS的方案优势OceanBase迁移服务其实主要解决了五个重要的问题。1.负载回放验证：其中第一个核心的问题就是负载回放验证，通过采集源端数据库的SQL流量，在目标库OceanBase上回放，可以验证其在OceanBase上的功能是否兼容、性能是否出现问题等。同时基于蚂蚁DBA十多年的经验沉淀，OMS会为客户提供性能等方面的调优建议。2.秒级数据校验：第二点就是数据校验，OMS有三层数据校验，可以做到秒级的延迟。举一个例子，比如说我们想把传统商业数据库替换成OceanBase，如果在迁移过程中任何一条数据出现了错误，在一秒钟内就可以快速发现。校验的延迟可以完全保证在一秒以内，根据蚂蚁线上的经验，大概在100-200毫秒之间。3.分钟级即时回滚：第三点也是最重要的一点，就是OMS有随时回滚的能力，而且回滚是无损的。这也是我们前面所强调的稳妥创新的基石。4.多种数据库类型支持：目前OMS支持源端数据库类型有Oracle、MySQL、OceanBase等等，支持全量迁移和增量数据同步。5.一键完成迁移：整个数据迁移链路和回滚机制的搭建基本上都是通过一键操作完成，使用简便。OMS的技术架构OMS的核心方案其实非常简单，我们把OceanBase变成Oracle/MySQL的一个备库。传统的商业数据库一般都是有主库和备库的：主库承担写的流量，如果主库出现问题，我们会把数据切到备库，然后通过OMS提供的一整套虚拟主备库的解决方案完成切换。比如原来Oracle有一个主库一个备库，然后OceanBase其实变成了一个虚拟的备库。整个数据库架构的升级也会变得异常简单，简单到只是做了一个主备切换。回滚也会变得非常简单，其实也是做了一次主备切换。从OMS的整体架构来看，其实一个非常关键的点就是，我们在传统的商业数据库和OceanBase之间建立了一套虚拟的主备链路，整个OMS里用到的所有组件，其实都是在蚂蚁和阿里有很多年技术沉淀的，也都是基于真实场景所产生的。OMS的迁移流程OceanBase迁移服务的整体迁移流程其实只有七步。1.评估：首先第一步是通过负载回放工具做兼容性分析;2.PoC：接下来OceanBase云平台可以帮助客户部署一套PoC集群;3.预迁移：然后OMS把线上的Oracle的数据预迁移到一个测试库里；4.验证：在这个测试库里用负载回放工具去回放这些SQL，然后找到SQL里不兼容，性能或者数据质量不满足预期的部分，并提供优化建议；5.正式迁移：前四步做完了以后，业务需要调整或者需要优化的SQL已经完成优化，然后就可以正式迁移了。首先把原有的全量数据迁过来，然后再把增量变化的那部分数据实时同步过来；6.校验：等到所有的数据准备好以后，然后我们继续完成三级校验；7.切换和回滚：等到所有的校验都完成以后，可以一键完成切换和回滚功能。通过这七步就可以轻松完成从传统商业数据库到分布式数据库的完整迁移。蚂蚁商户平台基于OMS的业务实践蚂蚁商户平台承载着商户档案数据信息，订购关系、签约信息的数据和相应的服务能力。其中一部分业务使用的是MySQL数据库，还有一部分核心业务使用的是Oracle数据库。随着商户的快速增长以及业务场景的不断丰富，商户平台数据增长迅速，数据规模相当庞大。尤其是MySQL的单表瓶颈日益明显，DDL变更、DML更新的性能与风险已经无法承担。蚂蚁金服技术专家韩谷悦介绍道，“OceanBase能够支持数据的无限扩展，满足商户业务的容量与性能需求。那么如果我们换一种数据库底盘，其实所要面对的性能、稳定性和数据质量的风险同样不可避免。”从蚂蚁商户平台的业务实践来看，使用OMS迁移与传统迁移进行对比，我们可以看到：· 业务评估和改造过去通常一个业务少则花费1-2个月的时间去做改造和适配；那么基于OMS自动化的SQL兼容性评估和负载回放的能力，蚂蚁商务平台业务的改造大概只用了一个星期的时间。· 数据迁移和校验客观来讲，迁移的总时长主要取决于业务数据模型，数据量和网络环境。在提高迁移效率方面，OMS目前增量迁移的延迟仅为毫秒级，跨城情况下最长只需要3秒。并且针对校验出的数据差异提供补齐的SQL和订正方案，使得迁移和校验的整体效率有了大幅度的提升。· 业务切换其实在切换之前，往往需要制定严密的切流方案和Failover方案，整个切换过程中需要检查与校验的细节非常繁琐，任何一步疏忽都有可能造成数据不一致的问题。那么OMS通过引入大规模编排的思想，把所有繁琐复杂的环节通通落到平台当中。所以从原来业务切换需要用时1-2周时间， 使用OMS后蚂蚁商户平台业务无论是切读还是切写的过程中都只用了几分钟的时间。· 业务回滚在过去，迁移之后的业务回滚要担负重大的决策风险，OMS使得业务回滚就像一次主备切换，可以瞬间完成并且不丢数据，所以让业务回滚不再成为难题。商户业务整体迁移的过程中也发生过业务抖动，使用OMS回滚的时候从登陆系统到完成回滚也只用了几分钟的时间。所以全程下来蚂蚁商户平台这个业务的迁移时间大概在三个多星期的时间完成，那么无论从人力成本还是时间成本上，OMS都极大地提升了数据库的整体迁移效率。最后，韩谷悦为大家展示了OMS一键迁移的demo演示。当前， 越来越多的企业已经认识到分布式架构在实现业务灵活扩展以及敏捷开发等方面的巨大价值。OceanBase不断通过产品端的革新，为传统企业输送“互联网基因”，帮助更多客户向分布式架构转型。同时OceanBase也在不断提高服务客户的深度和广度。深度意味着在同样的业务场景下，随着业务的发展和体量的壮大，帮助更多企业承担起业务所带来的极致压力。广度则针对的是随着新型技术形态和业务场景的出现，帮助更多企业快速响应，通过技术创新而适应变化所带来的新的市场契机。OceanBase致力于将蚂蚁自身业务多年沉淀下来的最浓缩，最经典和最普世的方法论输出给广大的企业客户，同时做到深度和广度并存，真正帮助客户实现稳妥创新。

人在屋檐下，哪能不低头（记2018年底互联网大寒潮）伴随着深冬凌冽的寒风，中华大江南北飘起了大雪，寒冷刺骨；接踵而至的互联网“寒潮”更是令众多的程序员寒在了心头。继阿里、京东传出缩招的消息之后，国内影响力最大的科技企业之一的华为也传出停止社招，华为方面迅速辟谣，不过另有消息人士指华为的社招虽然没有停止，不过社招方面对中端和低端人才的确实已停止仅剩下对高级人才的招募在继续，笔者认为对于互联网企业来说未来更让人担忧的恐怕是裁员潮。然后………于是………2019年说来就来了，还没被18年虐够的你，19年要更残忍了。年底向来是不太稳定的，这时候是大部分人开始计划年后跳槽的时间，也是公司人员调整的开始。其实很多人也说不准，究竟是公司正常的人员优化，还是因为宏观经济的影响开始辞退一些员工，但现在大家都挺敏感的，一点风吹草动可能都会引起一场激烈讨论。最近有新浪员工在网上发帖称，公司开始裁员了，首先就是还没转正的，差不多裁掉10%。看评论应该是裁也确实裁了一些，但应该不是大规模，现在大部分公司都已经缩招了，甚至关闭校招/社招通道，只出不进，这是个很普遍的情况。终上所述————这一切的一切，就是因为你 技！术！不！行！但使龙城飞将在，不破楼兰终不还（但使双手两眼在，不入阿里终不还）是的，只要你双手还能敲代码，双眼还能看得见，对于程序员来说，阿里等这些BAT大厂将会是你技术的必达点。对于尚处在20芳华的程序员来说，你在技术这条道路上已经踏上了你的脚印，并且，你要想义无反顾的走下去，那你就要放平自己的心态，找到正确的方向，制定远大的目标。或许很多在“寒潮”中幸存的工作了2至5年的程序员正在瓶颈期瑟瑟发抖，也没有多少感到庆幸的，甚至还有些许的害怕，之所以会感到害怕，就是因为你感觉你的技术水平已经没有什么长进了，不清楚接下来要怎么提升了。说懂吧，好像什么都懂点，说不懂吧，只要深入一点就一无所知。这就是技术只是停留在了运用的层面上，互联网公司里面，这样的人一抓一大把，毫无核心竞争力可言。那么我就要拿前篇那位大佬的Java架构技术知识路线图来说事儿了，对于目前的一线互联网大厂来说，这些技术已经算得上是最贴切且全面的，要学完这些技术，看起来有点多，但是到你用起来的时候，你会发现这些都是应该掌握的。1、开源框架解析站在巨人肩膀，收获不一样的视野。1.spring概述2.Spring 容器3.Spring AOP4.Spring MVC5.Spring 5新特性6.Mybatis2、架构筑基深入内核、直击故障、拒绝懵圈。1.分布式环境指挥官Zookeeper2.分布式消息通讯 异步与MQ3分布式缓存 NoSql4数据存储5高并发分流技术Nginx6分布式文件存储fastdfs3、微服务架构你还不知道微服务，怎么涨薪。1.SpringBoot2.SpringCloud3.Docker虚拟化技术4.Dubbo应用及源码解读4、高性能架构成为互联网架构师，你要的都在这里。1.性能优化如何理解2.JVM调优3.JAVA程序性能优化4.Tomcat5.Mysql5、团队协作开发让你团队开发效率提高十倍。1.Git2.Maven3.Jenkins4.Sonar6、B2C商城项目实战撸起袖子干实事，项目经验那点事。7、设计模式如果需要以上高清的技术图的话可以关注一下我，加入我的合作群 805685193 即可获取以上知识点这边都有相应的视频讲解而且每天都会更新，需要获取Dubbo、Redis、设计模式、Netty、zookeeper、Spring cloud、分布式、高并发等架构技术视频教程资料，架构思维导图，和BATJ面试题及答案的，都是免费分享的。

在比特币系统中，为了保证安全，比特币的交易吞吐率需要保持一个较低的水平。为了提高区块链的吞吐率，很多方案被提出来，其中一种方案通过使用有向无环图（Directed Acyclic Graph, DAG）的账本结构，提高基于工作量证明（Proof of Work, PoW）的区块链系统的吞吐率，从而实现不牺牲安全性与去中心化的效率提升。那么和经典的链式结构的 PoW 区块链（如比特币、以太坊）相比，DAG 账本结构对区块奖励与交易费机制设计提出了哪些新的要求和挑战呢？比特币/以太坊的激励机制对于一个基于工作量证明的公链来说，通过设计合理的激励机制，来鼓励矿工参与挖矿并遵守规则，是非常重要的事情。作为加密数字货币的开山鼻祖，比特币合理的激励机制设计是它成功的重要因素。在比特币中，矿工每挖出一个区块，就可以获得一定数额的 区块奖励 。最开始这个奖励数额是 50 BTC, 之后每挖出 21 万个区块，比特币的区块奖励就减半。目前比特币的区块奖励是 12.5 BTC。 预计在 2020 年夏天，比特币的区块奖励将降至 6.25 BTC。除了区块奖励，比特币矿工的另一个收入来源是交易费。每个用户在发起一笔交易时，需要支付一笔 交易费 。每个比特币区块中所有的交易费会付给挖出这一区块的矿工。在比特币的设计中，早期的交易不多，区块奖励是矿工主要的收入来源。随着时间的流逝，当比特币的用户越来越多，区块奖励也经过多次减半后，交易费将取代区块奖励成为主导部分。例如，在比特币区块 500439 中，交易费超过 13 BTC，高于该区块的区块奖励 12.5 BTC。以太坊的矿工收入主要也包含 区块奖励 与 交易费 两部分，但与比特币相比有几处不同：1.以太坊的基础区块奖励没有比特币的定期减半计划。在初始阶段，以太坊的基础区块奖励是 5 ETH。在 2017 年名为拜占庭的硬分叉中，649 号提案被激活，基础区块奖励调整为 3 ETH。目前的 1234 号提案计划将基础奖励调整至 2 ETH。2.为了适配智能合约的场景，用户在以太坊中发起交易时，不直接指定交易费，而是指定一个交易费单价，被称为燃料价格(gas price)。 交易实际执行时的计算量就是消耗的燃料，燃料用量乘以燃料价格是以太坊每笔交易最终的交易费。3.以太坊出块速度较快，所以会出现更多分叉。为了给矿工提供更好的挖矿体验，以太坊引入了“叔块”的概念。每个区块除了选择自己的父亲区块，还应当选择最多两个“叔块”。每个区块每选择一个叔块，可以额外获得基础区块奖励 1/32 的奖励。而被主链区块选中的叔块，其中的交易不会被执行，但也可以获得一定的奖励，具体数值是：(8+叔块高度-主链块高度)/8*基础区块奖励接下来，我们以 Conflux 共识机制为例，为大家分析一下使用 DAG 账本结构的 PoW 公链，在激励机制设计上有什么新的挑战，以及如何应对。DAG 的区块奖励机制比特币的方案在 DAG 中有什么问题Conflux 通过有向无环图结构保留了所有的区块，在保证去中心化和安全性的前提下，可以提高性能。但是，经过计算和分析，我们发现如果在 DAG 中直接采用比特币或以太坊的区块奖励方案会存在一些问题。在 Conflux 的共识机制中，所有的区块被保留了下来。之所以这样设计，不仅是为了最大化交易处理速率，也有安全上的考虑。（目前已知的 DAG 区块丢弃规则，在出块速度较快时，都可能会被坏人利用，导致大量好人区块被丢弃，从而可能影响安全性。因此保留所有区块是唯一的选择。）在这种情况下，如果我们依然采用比特币或以太坊的规则，每一个区块的区块奖励是一个固定值，将会面临一个问题——我们称之为 “零成本攻击”的问题。什么是“零成本攻击”? 我们假设在比特币中，有一个攻击者正在尝试挖一条分叉链，以此来与主链竞争。如果竞争失败，整个分叉链会被丢弃，攻击者拿不到任何奖励。在这个过程中，攻击者消耗了大量算力，付出了巨额的电费。这样的攻击是有高额的成本作为代价的。但如果一个攻击者在 Conflux 中这样做，他依旧可以拿到和正常挖矿相当的区块奖励。这是因为 Conflux 会保留所有的区块，固定区块奖励意味着攻击者不会受到任何惩罚。（需要注意，攻击者在 Conflux 这样做是无法双花已经被确认的交易的，Conflux 的安全性以非常高的概率保证这件事)。这个问题虽然不会危及链的安全性，但是会影响交易被确认的时间，也会使 DAG 结构变得更加复杂，从而增加每个矿工的工作量。我们不希望看到，由于激励机制没有对类似这样的攻击行为做出任何惩罚，导致每天都有矿工在攻击 Conflux。所以，我们在设计激励机制的时候，仔细考虑了这一点。而我们的解决这一问题的方式是惩罚矿工“假装没有看到一些区块”的行为。Conflux 的区块奖惩方案下图中以一个例子，说明了一个坏人如果想挖分叉链，就需要假装没有看到一些区块。如果要具体地描述这个机制，就要先讲一个概念：“光锥外区块”(anticone-block)。什么是“光锥外区块”呢？在 DAG 中，如果两个区块之间没有一条路径，这两个区块的互为对方的 “光锥外区块”, 比如在下图中，B 和 C 互为对方的光锥外区块。一个区块的区块奖励与它的光锥外区块的数量有关，光锥外区块越多，其奖励越少。当坏人挖出一个新区块时，那些假装没看见的区块，都会成为坏人区块的“光锥外区块”，减少坏人区块的区块奖励，对坏人造成经济上的惩罚。避免重复交易与交易费机制由于 Conflux 采用了 DAG 结构，因此不同的区块中可能会包含相同的交易。最近，社区里有很多热心的朋友询问我们，如果相同的交易过多，导致有效吞吐率大幅下降怎么办。这也是一个和激励机制紧密相关的问题，解决这一问题，概括来说就是两句话：1.矿工从交易等待池(加权)随机选取交易2.设计激励机制，鼓励矿工遵守上一条规则交易随机选择策略在比特币和以太坊系统中，每个矿工会选择交易费最高的若干交易来打包，这样的选择在比特币或以太坊这样链式结构下是没有任何问题的。但是在 Conflux 的 DAG 结构中，如果依然采用这样的策略，就可能会导致每个节点选择的交易都差不多一样，都是那几笔交易费最贵的交易。那么区块中就会出现大量的重复交易，导致吞吐率降低。为了解决这个问题，一个很直观的想法是，那就让矿工们从交易等待池中，随机地选取交易。当交易等待池中的交易越多，矿工随机选取交易出现冲突的概率就越小，重复交易的比例就越小。除此之外，我们还应该考虑交易的优先级问题。在比特币/以太坊的系统中，更高的交易费意味着更高的优先级。在 Conflux 的系统中，也应当保证交易费更高的交易具有一定的优先权。因此，交易选择策略的目标不应是最大化去重后的交易数量，而是去重后的交易费总量。所以我们会根据交易费为每笔交易计算一个权重，矿工根据权重从交易等待池随机选取交易。交易费用激励机制交易随机选择策略可以在很多交易都处于等待的状态时，很好地解决交易重复的问题，同时还可以兼顾高交易费交易的优先级。但这样的策略为激励设计带来了巨大的挑战。矿工们的目的是从挖矿的过程中获取收益。如果违背交易选择策略，可以为矿工们带来更高的收益，矿工们自然就会选择让自己收益最大化的方案，而非遵守策略。如果 Conflux 采取和比特币一样的设计，一个区块中的交易费由该区块的矿工全部拿走，每个矿工的最优策略将会是选择交易费最高的交易，而非遵守上述规则。这其实是一个博弈论机制设计问题。我们将每个节点打包交易的过程抽象成一个博弈问题并进行分析后发现，如果在多个并行存在的区块之间，平均分配这些区块中的交易手续费，矿工节点之间可以形成一种合作的模式：即共同通过减少冲突来最大化各自的收益。每个节点的收益与这些区块的总交易费成比例。矿工如果遵守规则，将可以最大化这些区块的总交易费，从而也就最大化了自己的期望收益。欢迎关注我们的微信公众号：Conflux中文社区(Conflux-Chain)添加微信群管理员 Confluxgroup 回复“加群”加入 Conflux官方交流群 ...

不久前，在团队内部和大家做了一次分享，内容就是这次要讲的“用认知和人性来提升自己的技术水平”，大家反响不错，所以这次整理一下也分享给大家。最初我是想用“借优秀的产品经理思维来做最棒程序员”的这个标题，但想想还是要有同理心，技术同学平时和产品同学已经是相爱相杀了，就不刺激大家啦。但是必须要说的是优秀的产品经理思维和优秀的程序员思维确实是殊途同归的，两者是想通的，就是来自认知和人性。这里我不会过多去梳理认知和人性的概念，后面会用很多例子来说明，保证通俗易懂，只想先提2个概念：对人性的理解能帮助提升认知狭义的技术是指java,php,android,spring,vue等的掌握和实践，它们只是帮助你提升认知的工具，却绝不等同于认知。下面我来逐一举例说明例子1-技术选型问题：今年开始慢慢火的一个移动端跨平台技术是google发布的"flutter"，如果你作为一名移动端的开发人员来评估这门技术是否值得选型作为公司产品的语言框架，你怎么能保证评估不会看走眼？认知：flutter强化了跨平台的生产效率，且性能比前端框架更好。解释：很多同学会想，怎么第一句感觉就像废话一样，人家官方文档也是这么写的，这叫什么认知。别急，所谓的认知，就是能够提炼成外人看上去貌似一句很普通的话，但只有经过深度思考的你才知道它真正的价值。在flutter没有出现前，我存在一个认知偏差，我认为客户端一定会被前端诸如react，vue这样的技术取代。因为它们既可以跨平台，也可以随时更新，符合互联网快速变化的节奏。但我的认知存在一个非常严重的漏洞，那就是跨平台和随时更新在客户端技术里的占比各应该是多少？哪个更重要？经过分析思考，以我们公司当前用户量的发展阶段，提升跨平台的生产效率且不损失太多性能更重要，所谓的运营快速需求变化有时候可以通过事先想清楚，而降低频率。flutter带来的生产效率提升，不仅仅是一个开发可以同时产出android和ios两端应用。更在于产品经理以后只需要和一个开发沟通需求细节，不会再担心出现android和ios功能细节实现偏差的问题了。由于有了这样的认知，虽然flutter作为新技术，还有需要完善的地方。但这不是主要问题，我们愿意为它去冒险，在我们的产品里去尽快实践。人性：最后多说一句，为什么google先做了kotlin后又做了flutter呢？我的认知是：大公司两个部门做重复轮子很正常，互相竞争，看谁更好。一个想试探性取代java以避免被oracle捏住命脉（如果接受的人多，将来把底层的jvm再抽掉），一个野心更大希望统一所有平台，不同部门的想法而已。大家不要把google的布局想得那么纯粹技术化，大家都是人嘛。人脱离不了：竞争，征服，自保的人性。:)例子2-查线上问题问题：觉得查线上问题很痛苦，压力很大，查得也不快怎么办？认知：1 查线上问题是成本最小的，锻炼逻辑思维的方式，相比写代码更有效率。 2 查问题要看本质，抓住案发第一现场解释：很多同学碰到线上问题的时候，都很痛苦，因为要加班了耽误我学习技术的时间，所以有时查问题态度也不积极。这个认知是非常错误的，大家平时都会认可优秀程序员的核心特质看的是思维逻辑，而不是用哪个语言哪个技术。那如果是思维逻辑优先，写代码就能比查线上问题更能提升吗？显然不是，大家知道我们在写代码时，往往要花费很多时间在编写冗余代码（如get,set代码，配置文件），普通的crud逻辑，编译，部署等这些非核心点上，它们并不能帮助我们提升思维（动手写代码前的思考才是最核心的）。但是查线上问题就不一样了，你不需要写任何代码，但是需要在很短时间内，让自己理清思路，按正确的步骤去查出代码的核心问题，底层系统的核心问题。你需要对系统很了解，对业务逻辑很了解，对代码细节很了解，这真是一个几乎没有任何冗余步骤，但是却能快速提升严谨思维的好方式！怎么让查问题更有效率？其实很简单，我们如果借鉴名侦探柯南的想法，那就是“抓住案发第一现场”。举两个例子，对于JAVA这样的静态语言，查询线上日志的方法是非常重要的。很多同学发现某个请求出问题了，就去看当次请求的日志，这种方式不一定准确。因为对于静态语言，它的案发第一现场可能已经不是当次请求了，很有可能是首次发生这个问题的时候，或者服务器刚刚启动的时候（静态语言的”缓存”特色）。当你发现上层的业务系统发生了mysql死锁的报错，就不要太纠结于上层业务系统的日志了。应该去看mysql的bin log，抓住这个案发第一现场，看看到底发生了什么。不知道怎么解决线上问题，99%是因为连案发第一现场都没找到，等你找到了，基本也有解决方法了。人性：每个人都喜欢做省力的事情，喜欢的事情。但是人往往有偏见，根本没有想明白查线上问题的价值，就认为这是一个很low的事，是不可取的。对自己不了解的，未知的事物，应该敬畏和学习。例子3-技术面试问题：很多同学的技术经验已经很扎实了，也能写出很稳定的代码，但是作为技术面试官，为什么老是会看走眼呢？认知：对应聘者而言，能否独立解决问题是能通过面试的及格线，应聘者专业技术的掌握程度只决定offer薪资的高低。解释：是不是觉得又来歪论拉？恩，继续解释一番。首先问你，你为什么要招人，我想信很多人都会这么说：当然是找你来帮我干活啊，我现在天天干到11点，累死了，急需人帮忙啊。恩，所以你很清楚，这个人是要能独立解决问题的，能帮你分担的，不是来了还要你天天在那里盯着的。但是我们看到很多同学的内心认知是混乱的，虽然他能看懂这句话，但是在面试的时候他会这么做：准备10个左右他擅长的技术细节问题，一个个问，应聘者只能答出5个，废柴，不送。答出7个，恩，可以进来。答出10个，还说了1个我不知道的，好牛逼，绝不能让他看出来我比他弱，否则进来后还怎么带他。但是这个和你之前痛恨的应试教育又有什么区别呢？这种招聘方式有很大的风险招进来的人是研究手机屏幕从几楼摔下去不会碎，而不是研究让屏幕显示更清晰的人。正确的方式应该是：让他讲一个之前投入度比较高的项目，描述下自己是怎么独立去解决问题的。对每一个点的描述，只要你觉得还不能体现他“独立解决问题”的能力，那就继续扒皮深问，直到他竭尽全力，被你”逼到墙角”。特别优秀的人被逼到墙角后，具备现场把墙砸掉的能力，这样的人是死也不能放过的，具体什么意思大家可以去体会思考。之前我们曾经面试过一个性能测试工程师，从技术细节看对性能测试的工具和方法是比较了解的。在项目描述中我们问了他一个问题：你之前通过性能压测发现的服务端问题，有去了解过发生的原因吗？他给的答复是：因为我们是外企，制度比较明确，开发也是另外一个部门，所以我没有去了解。不好意思，这个回答基本体现了没有独立解决问题的能力乃至意识。碰到一堵很小的墙，他都没有办法独立解决，好奇和学习的欲望也很弱。他在技术细节上的积累只是因为看了几本书，用了几次工具，这些都只是为了应付面试和不懂的领导，根本没有深入实践，他未来的瓶颈一定非常大。只要能够独立解决问题，就一定能通过面试，有些技术不了解，最多就是被砍点薪资而已。在这一点上，10年工作经验的同学还真未必比得上2-3年工作经验的同学，如果没有独立解决问题的能力，那只是多累积了一些所谓的专业经验，但还是无法解决问题。很多大公司喜欢校招优秀的毕业生，也是这个原因，虽然这些学生还没有实际工作过，但已经具备了很强的独立解决问题能力。我们曾经招过一名同济大学的测试实习生，有一次她独立组织了部门的团建活动，搞得井井有条，方方面面都考虑到了，这样的同学做好技术只是时间问题。:)人性：应聘者的人性有哪些呢？懒：影响独立解决问题的意识。 要面子：比如刚刚举的例子，拿公司制度掩盖自己无法独立解决问题的现状。（并且他自己是意识不到的，因为他内心的认知是混乱的） 盲目自信又不自信：对自己做的熟的东西盲目自信，对没接触过的技术很不自信。例子4-最严重的线上故障问题：到底是什么原因，会导致严重的线上故障呢？是我们团队的技术水平不高，还是流程问题才造成了如此严重的故障呢？认知：个体的过失很难造成严重的线上故障。真正的原因是：集体性的认知出错。解释：在现代微服务的架构下，各服务之间的解耦性已经做得非常好了，总体来说出现全面严重问题的概率已经降得非常多了。就像一个国家一样，不怕局部的腐败，怕的是整个链条的腐败。举个例子，如果一个系统上线前，需要在数据库里配置一个关键的参数，如果不配置会导致很多请求处理错误。但是开发同学发生了错误的认知，潜意识里认为配置不是写代码=配置没有写代码技术含量高=配置没有写代码重要，最后把它忘了。测试同学认为测试配置不是测试新写的代码=优先测试新写的代码，再测试配置=测试代码比测试配置更重要，最后把它也忘了。那这基本上是救不回来了，上线后一定会发生严重的问题，每个链条的检查机制都失灵了。坚决预防集体性的认知出错，就可以避免很多严重的问题。集体性的认知出错往往是从一些小现象开始的，比如我们的团队曾经发生过一次正常的项目延期，原因是周五到了，没有完成测试，为了避免仓促上线出问题，所以延期一天发布。其实到这里都是非常正常的，但是当测试同学在钉钉群里发出这个原因的时候，有一些同学发出了大拇指的表情。注意，这个时候大家是没有犯错的，但是认知已经出现了偏差，变成了“以后就算测不完，只要说项目风险，就可以延期”。群里很多同学都看着，一旦这个集体性的认知偏差形成，未来项目的延期就会越来越多。所以需要立刻出来说一句：因为风险项目暂时不上可以，但是延期的原因要总结反思。 通过这样一句让大家心里不太舒服的话，尽快把集体性认知偏差扭转过来。马云说过”小事要大做”，就是这个道理，不大做，等发生大事的时候就来不及了。人性：盲目自信：对自己做的领域有天然的偏见，哪个重要，哪个不重要。随大流：别人也这么做了，应该不会错，还省力，我也这么做。懒：默守所谓的安全方案，其实在那个场景下已经不安全了，但是内心认知出现偏差，懒得去破局改进。例子5-如何看待代码逻辑复用问题：对于代码逻辑的复用，大家的看法往往不一样，有些同学认为只要是有公共性的代码都该不断抽出通用函数复用。有些则认为对重要的通用逻辑才该复用，过度复用反而增加成本。认知：能力该复用，业务不该复用。分久必合，合久必分。解释：这里提出了两个认知，我们来分别解释下。能力该复用，业务不该复用，这个很好理解。能力是指对这个系统有价值的功能，会长期存在且扩展下去的。而业务是一个泛指，既可以表示单一的产品需求，也可以表示某个局部的功能。比如你的应用里接入了一个支付宝支付，对支付这个事情我们判断下来是一个基础核心能力，且将来很有可能也要接入微信支付，所以应该抽出公共的函数。再比如对于客户端的登录页面和注册页面，虽然渲染逻辑90%是一样的，但是不应该复用，因为它们是单一功能，不是能力，贸然复用反而带来了很大的风险。分久必合，合久必分，这个的理解就很有意思了。大家都知道，这句话的出处来自三国演义，说的是一个国家分裂久了就会合并，合并久了也会分裂，其实对代码逻辑的复用也是如此。大家在合并抽出公共函数时，会发现有10%-20%的逻辑不是那么顺眼，总感觉暂时放在里面是可以的，但将来可能会拆出来。那么在写公共函数时，就要特别注意这部分逻辑。它虽然暂时在函数里，但是需要做到和上下文相对隔离，甚至还可以加入明显的换行和TO DO，为下一次的拆做好准备。而在拆出一些独立逻辑的时候，也要思考这些逻辑可能和其它的哪些逻辑有机会是合起来的，那么尽量放在一个类里，一个包里，为后续的合做好准备。人性：不要刻舟求剑，妄图用一套规则来应对外部复杂变化的世界，要因地制宜，实事求是，学会变通。例子6-开源的意义问题：为什么现在很多中国的互联网公司开始重视开源的宣传了？认知：开源直接决定了公司的成本收入，以及人才储备解释：是不是要崩溃了，开源无偿写代码，然后免费给别人用，不是在消耗公司成本吗？别急，还记得马云说过的一句话吗，“免费的才是最贵的”。恩，这个道理同样适用于开源。今天中国很多的互联网公司已经非常明白了，甭管你的开源技术到底好不好用，宣传一定要大，一定要让大家参与进来。带来的好处太多了，因为用了你的开源消息队列，之后就会用你的云计算平台。因为程序员都很懒，开发环境和线上保持一套嘛，你后面一定能赚大钱。因为开源项目非常知名，让你公司的技术形象立刻高大起来（先不管这个项目到底创造了多少有价值的产品），每年校招的优质学生资源尽收囊中，其他公司要抢人，只能花更多的钱。而每年中国优秀的毕业生就那么多，早就供需失衡，谁抢到了大部分，那之后在技术上一定能保持绝对优势。最后万一公司财报不好看了，不好意思开始收授权费，就像google收android的费用一样。不作恶只是口号，开源带来了无比巨大的利益，不能赚钱，谁开源？！现在微软也懂了这个道理，成为了开源社区的标杆，但在早期的鲍尔默时代可是出现了认知偏差呢。人性：开源者的人性：追求利益，喜欢声誉。 接受开源的人：渴望进步，赚便宜，崇拜权威。关键点：如何提升认知内心简单：内心越简单的人，将来能到达的境界就越高。大家千万不要误解了，我说的不是思想浅薄，而是内心简单纯粹要像少年一样。一个很好的例子，郭靖，用世俗的眼光来看他天资不高，开始学什么都慢。但是他有一个很大的优点，就是想法简单，无私心，持之以恒。报家仇，报国仇，保护好他爱的人，不会去想是不是别人骗了他，他多做一点是不是亏了。20岁就达到五绝水平，最后终于融合“降龙十八掌”、“九阴真经”和“左右互搏”三大盖世武功为一体，武林尊为“天下第一侠士”。内心越简单，就越不会花费额外的精力在一些无关紧要的事上面。随着时间的推移，你的认知水平就一定能提升得更快。不要去想今天你学的语言明天是否还流行，先利用当前语言训练好你的思维模式。不要去想我作为测试给开发指出太多问题后，开发会不会不爽，做为测试你的核心是保证产品质量。不要去想今天我帮组内的开发分担了额外的代码编写，我是不是亏了，这些付出一定会在将来某个时候兑现，因为你比他们有更多的代码实践。相信跨界的力量：ipod+手机诞生了iphone，手机+钱包诞生了支付宝，c,python+java诞生了go，人类的创新其实都是来自于跨界的结合。很多时候大家去看一个技术大神，会认为他一定是看了很多专业的书，看了很多牛逼开源项目的代码，写了很多项目才达到现在的这个水平。然后又看到别人的兴趣爱好：音乐，滑雪，画画，牛逼，大神就是大神，做好技术的同时还能“兼顾”这些兴趣。这个认知完全错了好吗，我告诉你，写代码看书固然很重要，但如果他没有这些兴趣，他在技术上可能根本达不到今天的程度。一个有画画功底的人，理解向量，理解数据的PCA分析就是快好吗。一个财务出身的人，写支付系统的代码就是不容易出错好吗。人类的大脑从来都是一个网状的，互相关联的知识图谱，根本不存在靠”单一事物”修炼成功的好吗。千万不要成为技术上的孔乙己，天天学各种API的写法，和学习茴香豆的茴字有几种写法没有任何区别。在方案想不出来的时候，在代码水平感觉到瓶颈的时候，在看不懂一些专业书籍的时候，一定要跳出来，和自己的兴趣结合，和自己经历结合，和自己的生活结合，这样才能突破瓶颈，提升到更上一层的认知。相信更高认知人的指引：科幻神作三体里，外星人看地球人就像纸片一样，在三体人的眼中，地球人是二维的，而不是三维的。回到现实中，高认知的人看低认知的人也是一样的，不是低认知的人不够努力，而是你的知识图谱里比高认知的人少了一些维度。所以不管你怎么努力，你会发现仍旧无法超过他，他还比你轻松，学霸给大家留下的阴影就是这么来的。在实际工作中，你的leader，你的架构师只要不是水货，往往他们的认知就是比你高的。一旦你觉得这个人的本性是靠谱的，你就该无条件去相信他给你的建议和指引。因为他能看到在你那个维度上感受不到的东西，照他的话去实践几次，你才有机会到达他那个维度，才能升级认知。不过在现实情况中，我们往往看到很多leader和架构给下面的同学苦口婆心说了很多，但是他们不理解，反而更叛逆。这份痛苦我懂，你是拼了命想拉他到你那个维度，但是他还年轻着呢。:)持之以恒地实践：人就是一个如此奇妙，如此复杂的生物，不管你看多少书，看多少源码，写多少demo，你不真刀真枪地去实践，去写代码，这些知识无论如何都无法进入你大脑的知识图谱。它们永远只能是“狭义上的知识”，而不是“有价值的认知”。相信大家人生中都有过类似的经历了，越是辛苦的实践，越是坚持，你最后的收获一定越大。简单来说，认知不通过持之以恒的实践是不可能升级的。还有一点我必须要强调，实践应该尽量和公司的项目去结合，而不是依靠于自己写demo。这里面有一个很大的误区，自己私下写demo经常是没有“明确，高压的”目标的（人性总是偏懒的），这种实践往往很难提升认知。而公司的项目往往不同，会提出"支持多少用户访问"，“为什么你每次开发都不能更快一点”（核心挑战的是你架构的扩展能力），“为什么这个功能这么卡”（性能优化），这些“明确的，高压的”目标能督促你去拼命提升自己的认知（只是写demo是很难给自己设下这些障碍的，是反人性的）。当然从结果来看，又是公司的压榨剥削拉，让我们回忆一下前面说的，如果你觉得这个公司是靠谱的，那就让我们的“内心简单一点”，持之以恒地实践升级认知吧。:)最后总结一下，现在已经不是一个单纯比拼知识量的时代，而是比拼认知高低的时代。作为程序员我们并不特殊，和市场，财务，产品，运营的这些同学一样，核心看的是认知，并不存在谁比谁困难，谁比谁辛苦的这种浅层比较。而我们学习的那些语言，框架，工具，和我们大学时期学习的微积分，高等物理没有区别，都只是帮助我们不断训练提升认知的实践工具，而不是认知本身。让我们不要再局限于程序员狭义技术的范畴内，把提升自己的认知作为最重要的目标，我们要努力做到“既是程序员，也不是程序员”。

阿里妹导读：2018年12月下旬，由阿里巴巴集团主办的Flink Forward China在北京国家会议中心举行。Flink Forward是由Apache软件基金会授权的全球范围内的Flink技术大会，2015年开始在德国柏林举办，今年第一次进入中国。今天，计算平台事业部的资深技术专家莫问，将带领我们重温这场大数据技术的饕餮盛宴，感受Apache Flink 作为下一代大数据计算引擎的繁荣生态。Flink Forward China 大会邀请到了来自阿里巴巴、腾讯、华为、滴滴、美团点评、字节跳动、爱奇艺、去哪儿、Uber、DellEMC、DA（Flink 创始公司）等国内外知名企业以及Apache软件基金会的嘉宾为大家分享了Apache Flink的成长历程、应用场景和发展趋势。Flink Forward China 2018 嘉宾PPT及演讲视频：https://github.com/flink-china/flink-forward-china-2018参与有道，如何更“好”地贡献 Apache 项目上午大会由Apache软件基金会的秘书长Craig Russell开场，Craig首先分享了Apache开源之道，以及开源社区的精神和体制，然后以Apache Flink项目的成长经历为背景，向大家介绍了如何创建以及管理一个Apache开源项目，如何为Apache开源项目做贡献，并跟随开源项目一起成长和收获。通过Craig的分享，我们也更详细地了解到了Apache Flink的发展经历。Flink早期起源于德国柏林工业大学的一个研究项目Stratosphere，并于2014年4月捐献给Apache软件基金会，同时重新定位品牌为Flink，经过8个月孵化期，在2014年12月成功从Apache软件基金会毕业，成为Apache顶级项目，从此开始在大数据领域航行。经过最近4年的持续快速发展，Apache Flink社区已经培养出了42名Committer和19名PMC Member，不断加入的新鲜血液为Apache Flink社区持续贡献代码，并推动社区健康快速的发展。云上计算普惠科技在Craig分享后，阿里巴巴集团副总裁、搜索事业部与计算平台事业部负责人周靖人进行了主题演讲。靖人首先向大家介绍了阿里巴巴大数据云上计算的现状和趋势，让大家看到了阿里巴巴大数据业务场景的超大规模，以及未来更大的挑战。为了更好地支持阿里巴巴未来大数据的发展，阿里大数据发展策略一方面要进一步提升计算力和智能化，增强企业级服务能力。同时也要加强技术的生态化建设，大力支持并推动开源技术社区的发展，兼容行业生态标准，发展生态伙伴联盟，推动生态建设。目前阿里巴巴已经参与贡献230+开源项目，具备8000+合作伙伴和2000+ ISV，云上生态也已经突破1000,000开发人员。在大数据领域，阿里巴巴最近几年对Apache Flink社区进行了持续大力的投入，贡献超过15w行代码，主导建立了Flink China中文社区，加速Flink在国内的生态建设，并于今年开始在北京、杭州、上海、深圳等地多次组织Flink Meetup，促进国内Flink技术人员更方便的分享交流。靖人在分享的最后宣布了阿里巴巴内部Flink版本（Blink）将于2019年1月正式开源，本次开源内部版本的目标主要是希望让广大Flink用户能提前享受到阿里巴巴对Flink的改进和贡献。阿里巴巴同时会尽快将Blink中对Flink的各项改进和优化贡献给Flink社区，坚持对Apache Flink一个社区的拥抱和支持。Apache Flink，如何重新定义计算？在靖人宣布阿里巴巴开源内部Flink版本（Blink）后，阿里巴巴集团研究员蒋晓伟分享了Apache Flink在阿里巴巴内部的成长路线以及技术演进之路。阿里巴巴从2015年开始调研Flink，并于2016年第一次在搜索场景中上线Flink，在经过搜索大数据场景的检验后，2017年Flink开始在阿里巴巴集团范围内支持各项实时计算业务， 到目前为止阿里巴巴基于Flink打造的实时计算平台，已经支持了包括淘宝、天猫、支付宝、高德、飞猪、优酷、菜鸟、饿了么等所有阿里巴巴集团下的所有子公司的数据业务，并通过阿里云向中小企业提供一站式实时计算服务。在2018年的双11中，阿里实时计算平台已经实现了峰值每秒17亿次，当天万亿级的消息处理能力。Apache Flink目前在阿里巴巴内部最典型的业务场景是实时BI，阿里巴巴内部有着海量的在线交易以及用户数据，实时看到各个维度的数据统计可以及时地感知并指导阿里巴巴的运营。下图是一个典型的阿里实时BI流程，阿里的在线服务系统和数据库会实时产生大量日志数据并进入消息队列，FlinkJob会从消息队列中实时读取处理这些数据，然后将各种统计分析结果实时更新到KV/Table存储系统中，例如：HBase，终端用户可以通过Dashboard实时看到各种维度的数据统计分析结果。在双11当天，各种维度的实时数据报表是指导双11决策的依据，其中最为关键的就是全球直播的实时GMV成交额。Flink已经连续两年支持阿里巴巴双11实时GMV大屏，一个看似简单的数字，其背后实际上需要大量Flink计算任务平稳、精准地运行支撑。Flink在阿里巴巴另一个典型的应用场景是在线机器学习，传统的离线机器学习方法需要T+1的分析用户历史行为，训练出模型，当第二天模型上线后就已经是过去式，用户当前的需求和预期可能已经完全改变。为了给用户更好的购物消费体验，阿里巴巴的机器学习系统早已经进化到在线学习时代，例如：当一个用户在搜索完一个Query，浏览结果页时，或者点击查看部分商品时，阿里巴巴的在线学习系统已经可以利用这个间隙了解到这个用户当时的意图和偏好，并在下次用户Query时给出更好的排序，并向用户推荐更合适的商品，这种方式不仅可以进一步提升业务效率，同时也能为用户带来更好的产品体验，尤其是在双11这种大促场景，用户的行为时效性都是很短的，只有通过实时在线学习方式，才能做出更加精确的个性化预测和推荐。在线学习系统的优势在于可以实时收集并处理用户的行为数据，从而进行实时流式的特征计算和在线训练，并将模型的增量更新实时同步回在线系统，形成数据闭环，通过不断迭代自动优化系统效率和用户体验。在阿里的业务规模下，整个在线学习流程将会面对海量的用户数据规模、和极其复杂的计算挑战，但在Flink的驱动下，整个流程可以在秒级完成。通过以上两种经典场景可以看出阿里巴巴实时业务场景在各方面的挑战都很大，直接将Flink社区版本在阿里上线使用是不现实的，因此阿里巴巴实时计算团队这两年也对Flink进行了全面的优化、改进和功能扩展，其中有些功能和改进已经推回到了Flink社区。在Flink Runtime领域，阿里巴巴贡献了：全新的分布式系统架构：一方面对Flink的Job调度和资源管理进行了解耦，使得Flink可以原生运行在YARN，K8S之上；另一方面将Flink的Job调度从集中式转为了分布式，使得Flink集群规模可以更大的扩展。完善的容错机制：Flink默认在任何task和master失败后，都会整个Job 重启，阿里巴巴提出的region-based failover策略以及job manager failover/ha机制，让Flink可以运行地更加可靠稳定；大量的性能优化：Flink早期只提供全量Checkpoint机制，这在阿里巴巴大规模State场景下无法正常运行，阿里巴巴提出了增量Checkpoint机制，让Flink即使在TB级State场景下也可以高效运行；Flink Job经常在内部算子或者UDF中访问外部存储系统，例如：mysql，hbase，redis等，一旦出现个别query被卡住，整个task就被卡住，并通过反压影响到整个job，阿里巴巴提出了async IO机制，大幅降低了同步IO访问带来的影响。 此外，阿里巴巴贡献了credit-based的全新网络流控机制，使得Flink网络数据传输性能得到了显著提升。在Flink SQL领域，阿里巴巴贡献了全新的Streaming SQL语义和功能。例如：Agg Retraction，UDX支持，DDL支持和大量的Connector适配。在阿里巴巴，我们发现很多经典的业务场景都是同时具备实时流处理和离线批处理两种需求，而且流处理和批处理中的业务逻辑几乎是一样的，但用户需要开发两套代码，两套集群资源部署，导致额外的成本。例如阿里巴巴的商品搜索索引构建流程，白天需要将商品的更新信息流式同步到搜索引擎中，让用户可以在搜索引擎中看到实时的商品信息，晚上需要将全量的阿里巴巴商品进行批处理构建全量索引，这就是传统的Lambda架构。阿里巴巴的解法是希望提供一套批流融合计算引擎，让用户只需开发一套业务代码，就可以在实时和离线两种场景下复用，这也是在2015年阿里巴巴选择Flink作为未来大数据引擎的初衷。 Flink基于流处理机制实现批流融合相对Spark基于批处理机制实现批流融合的思想更自然，更合理，也更有优势，因此阿里巴巴在基于Flink支持大量核心实时计算场景的同时，也在不断改进Flink的架构，使其朝着真正批流融合的统一计算引擎方向前进。在Flink Runtime领域，阿里巴巴提出了全新的Operator Framework/API设计，使其能够同时适应批流两种算子特性；同时在Job调度和网络Shuffle两种核心机制上，都实现了灵活的插件化机制，使其能够适应批流不同场景的需求。在Flink SQL领域，阿里巴巴提出了全新的Query Execution和Optimizer架构，利用高效的二级制数据结构，更加合理的内存利用方式，更细粒度的Codegen机制以及更加丰富的优化器策略，使得Streaming 和Batch SQL都有了非常大的性能提升。经过大量架构改进和性能优化后，阿里巴巴内部Flink版本（Blink）在批处理上也实现了重大成果突破，在1T，10T和30T的TPC-DS的Benchmark中，Blink的性能数据均明显超出Spark，并且性能优势在数据量不断增加的趋势下越来越明显，这也从结果上验证了Flink基于流做批的架构优势。目前，阿里巴巴的内部Flink版本（Blink）已经开始支持内部批流融合的应用场景，例如阿里巴巴的搜索推荐算法平台，流式和批量的特征以及训练流程都已经统一基于Flink在运行。蒋晓伟在分享的最后给出了对Flink未来的一些展望，他认为Flink除了批流融合，还有很多新的方向值得去扩展，例如：Flink可以进一步加强在机器学习和图计算生态上的投入，从而在AI浪潮中实现新的突破。此外，Flink天然具备基于事件驱动的处理思想，天然的反压和流控机制，以及自带状态管理和弹性扩缩容的能力，这些优势都在促使基于Flink构建微服务框架成为一种新的思想和解决方案。总结蒋晓伟老师的分享，Apache Flink过去虽然在流计算领域已经获得很大的成功，但Flink并没有停滞，而是正在不断在突破自己的边界，Flink不仅仅是Streaming Engine，也不仅仅是Bigdata Engine，未来更希望努力成为Application Engine。流处理即未来接下来来自DA（Flink创始公司）的CTO - Stephan Ewen也对Flink的发展趋势给出类似的观点。Stephan认为“Streaming Takes on Everything”即流处理是一切计算的基础， Flink一方面需要朝着离线方向发展，实现批流融合大数据计算能力，另一方面也需要朝着更加实时在线方向发展，支持Event-Driven Application。前面已经重点阐述了Flink在批流融合计算方面的进展，接下来我们重点介绍下Flink在Event-Driven Application方向的思路。传统的应用服务架构一般是Online App +Database的架构，Online App负责接收用户Request，然后进行内部计算，最后将Result返回给用户，Application的内部状态数据存储在Database中；在Flink的event-drivenApplication架构中，可以认为Flink Source接收Request， Sink返回Result，JobGraph进行内部计算，状态数据都存储在State中。传统应用服务架构需要自己负责分布式和弹性管理，并由Database负责数据一致性管理；而Flink在这两方面是存在天然优势的，因为Flink天然是分布式系统，可以自己管理弹性伸缩，此外Flink内置了状态管理和exactly once一致性语义，因此基于Flink可以更方便、高效实现Transactional Application。城市级实时计算的力量在Apache Flink社区大神Stephan Ewen的分享后，来自阿里云的AI首席科学家闵万里向大家分享了实时计算在阿里云智慧城市中发挥的力量，通过分享多个真实应用案例，让大家对实时技术有了更多的体感和认识。在城市大脑的业务场景中，不仅要能实时处理来自各种传感器收集到的信息，对现实世界发生的事情进行响应，同时也要对未来将要发生的事情进行预测，例如：接下来那里可能要发生交通拥堵，从而提前做出干预，这才是更大的价值。整个城市大脑的架构都运行在阿里云基础设施之上，Apache Flink承担了核心实时计算引擎的角色，负责处理各种结构化和非结构化数据。在2018年9月的云栖大会上，阿里云发布了杭州城市大脑2.0，覆盖杭州420平方公里，可以监控到超过150万辆在途行驶机动车的实况信息，这个看似简单的事情在过去是很难做到的，现在我们通过1300多个路口的摄像头、传感器以及高德App的实时信息，通过Flink进行三流合一的处理，就可以实时感知到整个城市交通的脉搏信息，并通过进一步分析可以得出延误、安全等交通指数，预测感知城市的态势发展。在杭州，城市大脑通过实时分析4000多个交通摄像头采集的视频流，可以实时监控路上车辆的异常事件，例如：车辆超速、逆行和擦碰等，并将这些异常事件实时同步到交警指挥中心进行实时报警，目前杭州的交通事件报警已经有95%来自城市大脑自动通报的，这背后都是通过Flink进行各种复杂的计算逻辑实时算出来的。实时计算让交警处理交通故障的方式从过去的被动等待变成了主动处理，从而大幅提升城市交通的效率，为老百姓带来实实在在的好处。这50%，关乎生死2018年，城市大脑第一次走出国门，来到马来西亚吉隆坡，基于实时大数据对交通进行智能调度，它可以根据救护车的行驶信息，以及沿途路况信息，智能调整红绿灯，为救护车开辟绿色快速通道，这项技术为救护车节省了近50%的时间到达医院，这50%的时间可能意味着人的生和死，在这里技术显得不再骨感，实时计算的力量也许可以挽救生命。在工业生产IOT场景中，大量设备的传感器都收集了海量的指标数据，这些信息过去都被暂存2个月后丢弃了，唯一的用途就是在出现生产故障时拿来分析用，在有了大数据实时计算能力后，这些指标都可以被实时监控起来，作为及时调控生产流程的依据。协鑫光伏是全球最大的光伏切片企业，阿里云利用实时设备监控，帮助其提高了1%的良品率，每年可以增加上亿元的收入。滴滴实时计算平台架构与实践Keynote最后一位嘉宾是来自滴滴出行的研究员罗李，大家都知道滴滴出行是一个实时出行平台和交易引擎，它的数据和场景天然是实时的，各种网约车服务产生的数据都需要实时处理和分析。滴滴的实时业务场景主要包括实时风控、实时发券、实时异常检测，实时交易、服务和工单监控，以及实时乘客、司机和订单特征处理等。滴滴实时计算平台发展已经经历了三个阶段，第一阶段是各个业务方自建小集群，造成集群和资源碎片化问题；第二阶段由公司统一建立了大集群，提供统一的平台化服务，降低了集群资源和维护成本；第三阶段是通过Flink SQL方式提供平台化服务，通过SQL语言优势进一步降低业务开发成本，提升开发效率。滴滴现阶段基于Apache Flink引擎建设的实时计算平台以开源的Hadoop技术体系作为平台底座，并通过DataStream, SQL和CEP三种API向滴滴内部业务提供实时计算服务，同时在平台层也已经具备相对完善的WebIDE、数据血缘管理、监控报警和多组合隔离等机制。在滴滴实时业务的快速发展推动下，其实时计算集群已经达到千台规模，每天运行2000+流计算任务，可以处理PB级的数据。滴滴在搭建Flink实时计算平台的过程中，在内部也对Flink做了一些改进，例如在 Stream SQL领域扩展了DDL，丰富了 UDF，支持了TTL的双流Join和维表Join等；在CEP领域，增加了更多算子支持和规则动态修改能力等，其中部分优化已经推回了社区。最后，罗李介绍了滴滴实时计算平台的未来规划，主要方向在于进一步推广Stream SQL提升业务开发效率，推动CEP在更多业务场景落地，同时完成公司内部原有Spark Streaming向Flink的迁移，并发力IOT领域。在下午的几个分会场中，来自阿里巴巴、腾讯、华为、滴滴、美团点评、字节跳动、爱奇艺、去哪儿、Uber、EMC、DA（Flink 创始公司）的多位嘉宾和讲师都围绕Flink技术生态和应用场景进行了分享和交流。从分享的内容上可以看出，BAT三家中阿里巴巴和腾讯都已经完全拥抱了Flink；美团、滴滴和字节跳动（TMD）三家新兴互联网企业在实时计算场景也都已经以Flink作为主流技术方向开始建设，滴滴在Keynote上分享已经令人印象深刻，美团的实时计算集群也已经突破4000台规模，字节跳动（头条和抖音的母公司）的Flink生产集群规模更是超过了1w台的惊人规模 。由此可见Apache Flink的技术理念已经在业界得到了大量认可，基于Flink的实时计算解决方案开始在国内占据主流趋势。下一步Flink需要一方面继续完善流计算能力，争取在IOT等更多场景落地，与此同时进一步加强在批流融合能力上的全面突破，并完善在机器学习和AI生态上的建设，以及在event-driven的application和微服务场景上进行更长远的探索。本文作者： 莫问阅读原文本文来自云栖社区合作伙伴“阿里技术”，如需转载请联系原作者。 ...

摘要： Dubbo 这个名字，最后会变成一个 Apache 的商标，会成为一个在 GitHub 上有 2 万多人关注、一百多人参与贡献的超级项目。梁飞在 2011 年开源 Dubbo 这个项目的时候，完全没有想过，Dubbo 这个名字，最后会变成一个 Apache 的商标，会成为一个在 GitHub 上有 2 万多人关注、一百多人参与贡献的超级项目。在自己退出这个项目多年后，Dubbo 仍在野蛮生长，并焕发新机。从商业公司开源出去的产品会变成什么样？开源是否一定要按照某种既定的方式去生长？还是说开源的世界有足够的包容性、开放性，能够允许各种各样的创作在其中成长？且看本次二叉树——Dubbo 项目的故事。嘉宾简介梁飞（虚极），2009 年加入阿里巴巴，负责中间件的开发，Dubbo 开源分布式服务框架作者，HTTL 开源模板引擎作者，QCon 优秀出品人。 2012 年加入天猫，负责手机天猫 APP 的技术团队，见证了天猫双 11 无线化全过程。热衷参与开源社区建设，传播服务化，SOA，框架设计，移动应用等架构设计理念。Dubbo 项目诞生于 2008 年。梁飞最早进入阿里的时候，Dubbo 项目还没有 Dubbo 这个名字，那时的 Dubbo 还是一个阿里内部的系统。2010 年，Dubbo 项目进行了重构。“2009 年下半年主要在修 bug，到了 2010 年初的时候觉得这个架构实在是不堪重负，觉得改起来太痛苦了，于是就重写了。”从 1.0 进入 2.0，梁飞推动了大量的工作，同时继续在 JavaEye 写着他的博客。“写博客对你有什么影响？”“在社区里面看别人的博客，他们也在写一些开源软件，大家互相看博客，然后就认识了。推荐我来阿里的朋友就是当时圈子里认识的。”2011 年的阿里，憋了一股劲儿要成为一家技术人向往的企业。那个时候，开发者刚刚成为国内各大厂商争相夺取的宝贵资产。靠什么吸引最顶尖的开发者？黑客文化。工程师文化。开源文化。“那时候公司觉得要做一些开源的事情，一个是反哺开源界，同时也希望通过开源来提升公司的影响力。”当时在淘宝、在阿里 B2B，都有团队在推动开源。阿里 B2B 这边决定先拿 Dubbo 项目开源出去。“大概在 2011 年初做了很多剥离的工作，也把文档做了梳理。我们并没有做很强的推广，我们自己在技术群里发了一些文章，就有人开始在用了。”“那个时候的团队多少人？我看到你们有一张六个人团队的照片。”“人员的变化还是挺多的，六个人是顶峰时期，是我们知名度上来之后加入我们的。我们平时开发基本上就是一到两个为主。”“有外面的人来贡献代码吗？”“有很多人给我们贡献代码。还有很多公司请我们来跟他们讲。”“还有公司问说能不能我们付一点钱，这样的话他们觉得出了问题可以找我们。”“但是我们当时没有这种机制。”一年时间很快过去了，Dubbo 的用户越来越多，有知名汽车厂商、证券厂商、水泥厂商、电器厂商、电商厂商。“当时来这么多公司，在你的预期之内吗？”“超出我的预期。”就在这个时候，发生了一件大事：阿里巴巴集团要强化 One Company，开始进行架构调整。技术层面，整个公司大统一，就希望不要重复建设，但凡相同的项目都要合并。当时的淘宝有一个项目叫做 HSF，也是一个中间件服务框架，跟 Dubbo 做的事情高度重合。“一开始说可以让 HSF 合并到 Dubbo 里面来，给了我们三个月时间要把它们整合起来。”HSF 项目的作者林昊（毕玄），也是当时国内 Java 领域的知名技术领袖。在 OSGi 非常流行的时候，毕玄可能是国内能够把 OSGi 解释的最清楚的人之一。HSF 和 Dubbo，虽然做的事情高度重合，但是设计理念不怎么一样，虽然有些碰撞，但最终目的还是为了“强强联合”。“合并的时候，整个淘系都在用 HSF，而阿里金融、集团、B2B 都在用 Dubbo。”“时间没有达到预期，还是没合并起来。但其实我们把两边的协议都兼容好了。”“后来就决定反向合并，把 Dubbo 合并到 HSF 里面去。”“你当时觉得应该合并吗？”“我觉得协议能互通是有好处的，并不是坏事。我觉得他们做的挺好，把两边的设计理念全部整合在一起了。”不久之后，Dubbo 团队调整，去到了各个地方。从外面看来，Dubbo 项目从 2014 年之后就再也没有更新过。倒是当当网开发的扩展版本 Dubbox 后来持续发展，被圈内人评价为“墙内开花墙外香”。“你会不会觉得建立共识是一个特别困难的事情？”“我觉得任何东西必须要有一个主导，但这个东西其实没有对错。一个设计是没有对错的，有些人可能就是不会认同你这个共识，但你总是能找到认同你共识的人。”“我就是认为越简单越好，我的设计原则就是一定要实用。增加的复杂度越小，能带来更大的收益，我觉得就值得。”“那么，你要怎么吸引那些能够认同你的人到你的身边来？在他们还不知道你的时候。”“我会去其他团队认识人，或者在圈子里面认识人，我会跟他去聊我的理念，我会去分享。有人特别认同的话，他就会来。”就在所有人都以为 Dubbo 项目已经没有未来的时候，事情又出现了变化。2017 年 9 月，就在项目已经将近 3 年没动静的时候，Dubbo 连续发布了好几个新版本，并且开始在内部招募对 Dubbo 感兴趣的同事。新版本背后的主力开发团队是阿里巴巴中间件团队，其中一个重要的人名叫北纬，他从 2017 年 7 月开始接手 Dubbo。在一次对外公开的采访中，北纬说到：“我对 Dubbo 的了解主要来自梁飞在 JavaEye 的系列文章，再通过自己阅读源码，以及在内部 RPC 框架对 Dubbo 兼容的工作中学习所得。”梁飞曾经在 2015 年写过一个继续推动 Dubbo 的规划，找了很多人聊过：找过开源委员会，找过内部的朋友，找过外面的朋友，希望能共同把这个事情继续推起来。但是，梁飞已经没有那么多时间可以投入到 Dubbo 上。他当时在做天猫客户端。“不管是谁，靠一腔热血都很容易凉掉。”有的开源项目，通过志愿者们投入各自的业余时间活下去。但我们应该要求所有的开源项目都能做到这一点吗？事实上，用户也不会愿意将自己重要的东西跑在单纯靠志愿者们的业余时间堆砌起来的项目上——尤其是企业用户。Dubbo 是中间件项目，用户一定是企业。企业用户宁愿花钱，有人给他提供服务，而不是搞来一堆免费而没有保障的东西，自己为所有的问题负责。Dubbo 的转机，在于阿里云的流行。2017 年的阿里云，发现有一批客户上云之后，想要用 Dubbo。因为他们 Dubbo 已经用的很熟了，不想因为上云而被迫改变自己的使用习惯。于是，阿里云就把 Dubbo 服务作为自己的一个产品，卖给了这些客户。但是，客户们又提出了一个问题：“你看你们 Dubbo 都不怎么更新代码了是吧？你们自己都不维护了，我们用你的框架就觉得特别不放心。”这下好了，真正的客户提出要求了。提升客户对 Dubbo 的信心，成为了一件在公司层面有价值的事情。“怎样提升客户对 Dubbo 的信心？”“让它进一步升级。”“最好的办法是什么？”“捐给 Apache。”北纬带动着他的团队，将 Dubbo 项目捐给了 Apache。2018 年初，Dubbo 项目正式进入了 Apache 的孵化器。一边是 Apache Dubbo 重启后的第一个里程碑版本 2.7.0 进入社区投票阶段，并将作为社区的毕业版本；另一边，Dubbo 正在从一个微服务领域的高性能 Java RPC 框架，演进到微服务框架 Dubbo Ecosystem，打造出一个完整的微服务生态。而此时，距离去年 Dubbo 重启仅过一年有余。我们去找到北纬，希望他聊聊 Dubbo 的未来。北纬说，还是让梁飞跟我们多讲讲。“你觉得什么是开源的精神？”“开源的精神，就是大家的智慧能共同成长。”“你觉得中国的开源现在有哪些做得好的地方和不足的地方？”“我觉得中国的开源最缺对社区的重视，很多都只是把代码 push 出来，有些甚至连文档都不完善，好像人家爱用不用，出了问题也不是我的事。但这可能是一个初级阶段，慢慢会成熟起来。但我觉得好的地方就是，大家都相信开源的力量。”“您会不会觉得中国企业做开源，功利心特别重，光去看这个东西是不是有用？”“输出技术影响力是吧？我觉得一个开源社区要能够一直运作下去，而且能跟上时代的潮流，其实是要与时俱进的。我觉得做开源，就是期望这个东西一直有生命力，这个作品能够活多久应该作为它的核心目标。”“那您觉得 Dubbo 还能活多久？”“我觉得技术的革新其实挺快的，不革新的话，就有淘汰的危险。但是在这个节点上进行一次革新的话，我觉得它还有很长的生命力。”“那是什么样的革新？”“任何技术一定是没有终点的。没有任何架构能解决现实中所有的问题，而任何一个架构去解决前面的问题的时候，一定会带来副作用，然后就需要下一个架构去治理。这个探索的方向是没有止境的，但只有你到达了一个阶段，你才能够去想下一个阶段的很多事情。”“回到原点，十年前的选择一定是最正确的吗？就算当时是最正确的，现在也不一定正确对吧？因为时代在变化。如果我们今天从零开始，我们有没有更好的选择？有时候我们背了十年的包袱，反而不敢行动了。但我希望我们下一代演化的时候，我们能够提出一些颠覆式的理念，真正革新的解决我们现在面临的问题背后的那些问题，而不是头痛医头脚痛医脚。这是我们期望做的事情。”如常，早上 9 点多，梁飞打开邮箱，关于 Apache Dubbo 重启后的第一个里程碑版本 2.7.0 的讨论邮件还在 mailing list 里热烈进行着；另一边，Dubbo 正在从一个微服务领域的高性能 Java RPC 框架，演进到微服务框架 Dubbo Ecosystem，打造出完整微服务生态。而此时，距离去年 Dubbo 重启仅过一年有余。本文作者：二叉树阅读原文本文来自云栖社区合作伙伴“InfoQ”，如需转载请联系原作者。 ...

2019年的第一个工作日，阿里巴巴达摩院重磅发布了2019十大科技趋势，引发社会各界对未来科技的讨论和向往。这一发布同样引来科学界的普遍关注。来自包括中科院、清华大学、佛罗里达大学、杜克大学等权威学术机构的十余位专家就此发表评论，深度点评达摩院提出的观点，充分肯定达摩院在基础科研领域持续深耕的专注精神。专家普遍认为，达摩院发布的科技趋势虽然有十个方向，但都是围绕着当前科学发展的几个关键潮流，即以芯片为代表的算力、以图计算为代表的算法以及以5G为代表的连接能力。一、计算是变革的源头传统时代的计算始终在冯诺伊曼架构约束下发展，但人工智能的到来正在挑战冯诺依曼架构，而摩尔定律也接近失效，新型芯片以及新的计算机架构已经成为整个行业研究重心。达摩院认为，计算体系结构正在被重构，基于FPGA、ASIC等计算芯片的异构计算架构正在对以CPU为核心的通用计算发起冲击。“通过推高通用芯片的性能来征服一切的方式已经失效。” 中国科学院计算技术研究所研究员陈天石对此评论说，“学术界和工业界都把目光投向了更加专用的处理器架构，并且一直在期待新器件引发的新的架构演进。”杜克大学副教授、IEEE Fellow陈怡然也表示，目前学术界的研究重心在一些更为革命性的架构研究，例如内存计算、非冯诺依曼架构、神经形态计算等。而佛罗里达大学杰出教授、IEEE Fellow李涛则指出，计算体系结构的变革将主导和引领ICT领域的持续创新和发展，这将是未来产业界的核心竞争力。在人工智能领域，GPU无疑是最受企业以及开发者追捧的芯片。但达摩院认为，数据中心的AI训练场景下，计算和存储之间数据搬移已成为瓶颈，AI专用芯片将挑战GPU的绝对统治地位。“对于训练场景来说，计算量要求非常高，需要存储和处理的数据量远远大于之前常见的应用，AI专用计算架构是最佳选择。” 清华大学微纳电子系副系主任尹首一对达摩院的这一观点表示认可。根据达摩院的判断，AI专用芯片的应用将成为趋势。在2018年的杭州云栖大会上，阿里巴巴曾宣布首款AI芯片AliNPU将于2019年应用于城市大脑和自动驾驶等云端数据场景中。陈天石指出，“AI芯片可以灵活高效地支持视觉、语音和自然语言处理，甚至传统的机器学习应用，将在数据中心场景发挥重要作用。”二、算法的创新让AI更加智能1950年，人工智能之父图灵提出著名的图灵测试用以检验人工智能能力，即如果有超过30%的测试者不能确定被测试者是人还是机器人，则认为是通过测试。图灵提出的猜想可能将会很快实现。达摩院认为，在未来，人类可能无法辨别人工智能生成的语音和真人语音，具备语音交互能力的公共设施将会越来越多，甚至在一些特定对话测试中机器可以通过图灵测试。西北工业大学计算机学院教授谢磊对此表示，“声音合成技术在某些方面已经可以媲美人声，并将会拉动‘耳朵经济’的爆发，各种‘AI声优’ 将上岗，为大家提供听觉盛宴。”人工智能行业的迅速发展与深度学习带来的突破高度相关，但仅靠深度学习要实现通用人工智能仍然困难重重。达摩院认为，结合深度学习的图神经网络将让机器成为具备常识、具有理解、认知能力的AI。杜克大学统计学院终身教授David Dunson对此评论说，“结合了深度学习的图计算方法将实现推荐系统的变革性改进，为用户提供更有趣和更合适的产品，同时改善整体用户体验。”过去两年，城市大脑成为社会热词。达摩院认为，2019年，人工智能将在城市大脑技术和应用的研发中发挥更大作用，未来越来越多的城市将拥有大脑。中国城市规划设计院院长杨保军认为，“城市大脑将不再是单一领域或是单项要素的智慧，而是全局联动、多源交融的智慧。”同济大学智能交通运输系统研究中心主任杨晓光则表示，“新一代城市智能管理、智能服务与智能决策将帮助人类最大程度地预防和综合治理城市病。”三、连接万物的5G催生更多应用场景过去几年，5G的热度并不逊于人工智能。5G构建的不仅是一张人联网，它将会成为连接万物的纽带。达摩院在此次十大科技趋势中提到，5G将催生超高清视频、AR/VR等场景的成熟。中国信通院副总工、工信部信息通信经济专家委员会秘书长陈金桥对此评论说，“5G将掀开数据资源作为生产力的大幕，一个基于泛在高速连接的智能社会必将形成。” 车路协同将会是5G与人工智能两大技术交融的典型场景。达摩院认为，车路协同技术路线会加快无人驾驶的到来，并且将在固定线路公交、无人配送、园区微循环等商用场景将快速落地。单纯依靠“单车智能”的方式革新汽车存在诸多限制，例如传感器部署的成本高，感知系统以及决策系统的可靠性低等。“车路协同的优势在于，可降低单车系统在定位方案部署上的成本，并且可以实现更好的感知与决策。” 中科院自动化研究所研究员赵冬斌如此表示。本文作者：阿里云头条阅读原文本文为云栖社区原创内容，未经允许不得转载。

今天我们来谈谈 Dubbo XML 配置相关内容。关于这部分内容我打算分为以下几个部分进行介绍：Dubbo XMLSpring 自定义 XML 标签解析Dubbo 自定义 XML 标签解析DubboBeanDefinitionParser.parse()EndDubbo XML在本小节开始前我们先来看下 Dubbo XML 配置文件示例：dubbo-demo-provider.xml<?xml version=“1.0” encoding=“UTF-8”?><!–<beans xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance" xmlns:dubbo=“http://dubbo.apache.org/schema/dubbo" xmlns=“http://www.springframework.org/schema/beans" xsi:schemaLocation=“http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-4.3.xsd http://dubbo.apache.org/schema/dubbo http://dubbo.apache.org/schema/dubbo/dubbo.xsd"> <!– provider’s application name, used for tracing dependency relationship –> <dubbo:application name=“demo-provider”/> <!– use multicast registry center to export service –> <!–<dubbo:registry address=“multicast://224.5.6.7:1234”/>–> <dubbo:registry address=“zookeeper://10.14.22.68:2181”/> <!– use dubbo protocol to export service on port 20880 –> <dubbo:protocol name=“dubbo” port=“20880”/> <!– service implementation, as same as regular local bean –> <bean id=“demoService” class=“org.apache.dubbo.demo.provider.DemoServiceImpl”/> <!– declare the service interface to be exported –> <dubbo:service interface=“org.apache.dubbo.demo.DemoService” ref=“demoService”/></beans>在这段配置文件中有一些以 dubbo 开头的 xml 标签，直觉告诉我们这种标签和 dubbo 密切相关。那么这些标签的用途是什么？又是如何被识别的呢？我们结合 Spring 自定义 xml 标签实现相关内容来聊聊 Dubbo 是如何定义并加载这些自定义标签的。Spring 自定义 XML 标签解析Dubbo 中的自定义 XML 标签实际上是依赖于 Spring 解析自定义标签的功能实现的。网上关于 Spring 解析自定义 XML 标签的文章也比较多，这里我们仅介绍下实现相关功能需要的文件，给大家一个直观的印象，不去深入的对 Spring 自定义标签实现作详细分析。定义 xsd 文件XSD(XML Schemas Definition) 即 XML 结构定义。我们通过 XSD 文件不仅可以定义新的元素和属性，同时也使用它对我们的 XML 文件规范进行约束。在 Dubbo 项目中可以找类似实现：dubbo.xsdspring.schemas该配置文件约定了自定义命名空间和 xsd 文件之间的映射关系，用于 spring 容器感知我们自定义的 xsd 文件位置。http://dubbo.apache.org/schema/dubbo/dubbo.xsd=META-INF/dubbo.xsdhttp://code.alibabatech.com/schema/dubbo/dubbo.xsd=META-INF/compat/dubbo.xsdspring.handlers该配置文件约定了自定义命名空间和 NamespaceHandler 类之间的映射关系。 NamespaceHandler 类用于注册自定义标签解析器。http://dubbo.apache.org/schema/dubbo=org.apache.dubbo.config.spring.schema.DubboNamespaceHandlerhttp://code.alibabatech.com/schema/dubbo=org.apache.dubbo.config.spring.schema.DubboNamespaceHandler命名空间处理器命名空间处理器主要用来注册 BeanDefinitionParser 解析器。对应上面 spring.handlers 文件中的 DubboNamespaceHandlerpublic class DubboNamespaceHandler extends NamespaceHandlerSupport { @Override public void init() { registerBeanDefinitionParser(“application”, new DubboBeanDefinitionParser(ApplicationConfig.class, true)); // 省略… registerBeanDefinitionParser(“annotation”, new AnnotationBeanDefinitionParser()); }}BeanDefinitionParser 解析器实现 BeanDefinitionParser 接口中的 parse 方法，用于自定义标签的解析。Dubbo 中对应 DubboBeanDefinitionParser 类。Dubbo 解析自定义 XML 标签终于进入到本文的重头戏环节了。在介绍 Dubbo 自定义 XML 标签解析前，先放一张图帮助大家理解以下 Spring 是如何从 XML 文件中解析并加载 Bean 的。上图言尽于 handler.parse() 方法，如果你仔细看了上文，对 parse() 应该是有印象的。 没错，在前一小结的第五点我们介绍了 DubboBeanDefinitionParser 类。该类有个方法就叫 parse()。那么这个 parse() 方法有什么用？ Spring 是如何感知到我就要调用 DubboBeanDefinitionParser 类中的 parse() 方法的呢？我们带着这两个问题接着往下看。BeanDefinitionParserDelegate上面图的流程比较长，我们先着重看下 BeanDefinitionParserDelegate　类中的几个关键方法。BeanDefinitionParserDelegate.javapublic BeanDefinition parseCustomElement(Element ele, BeanDefinition containingBd) { // 获取当前 element 的 namespaceURI // 比如 dubbo.xsd 中的为 http://dubbo.apache.org/schema/dubbo String namespaceUri = this.getNamespaceURI(ele); // 根据 URI 获取对应的 NamespaceHandler NamespaceHandler handler = this.readerContext.getNamespaceHandlerResolver().resolve(namespaceUri); if (handler == null) { this.error(“Unable to locate Spring NamespaceHandler for XML schema namespace [” + namespaceUri + “]”, ele); return null; } else { return handler.parse(ele, new ParserContext(this.readerContext, this, containingBd)); }}这个方法干了三件事获取 element 元素的 namespaceURI，并据此获取对应的 NamespaceHandler 对象。Dubbo 自定义标签(比如 Dubbo:provider) namespaceUri 的值为 http://dubbo.apache.org/schema/dubbo;根据 step1 获取到的 namespaceUri ，获取对应的 NamespaceHandler 对象。这里会调用 DefaultNamespaceHandlerResolver 类的 resolve() 方法，我们下面会分析;调用 handler 的 parse 方法，我们自定以的 handler 会继承 NamespaceHandlerSupport 类，所以这里调用的其实是 NamespaceHandlerSupport 类的 parse() 方法，后文分析；一图胜千言 在详细分析 step2 和 step3 中涉及的 resolver() 和 parse() 方法前，先放一张时序图让大家有个基本概念：DefaultNamespaceHandlerResolver.javapublic NamespaceHandler resolve(String namespaceUri) { Map<String, Object> handlerMappings = this.getHandlerMappings(); // 以 namespaceUri 为 Key 获取对应的 handlerOrClassName Object handlerOrClassName = handlerMappings.get(namespaceUri); if (handlerOrClassName == null) { return null; } else if (handlerOrClassName instanceof NamespaceHandler) { return (NamespaceHandler)handlerOrClassName; } else { // 如果不为空且不为 NamespaceHandler 的实例，转换为 String 类型 // DubboNamespaceHandler 执行的便是这段逻辑 String className = (String)handlerOrClassName; try { Class<?> handlerClass = ClassUtils.forName(className, this.classLoader); // handlerClass 是否为 NamespaceHandler 的实现类，若不是则抛出异常 if (!NamespaceHandler.class.isAssignableFrom(handlerClass)) { throw new FatalBeanException(“Class [” + className + “] for namespace [” + namespaceUri + “] does not implement the [” + NamespaceHandler.class.getName() + “] interface”); } else { // 初始化 handlerClass NamespaceHandler namespaceHandler = (NamespaceHandler)BeanUtils.instantiateClass(handlerClass); // 执行 handlerClass类的 init() 方法 namespaceHandler.init(); handlerMappings.put(namespaceUri, namespaceHandler); return namespaceHandler; } } catch (ClassNotFoundException var7) { throw new FatalBeanException(“NamespaceHandler class [” + className + “] for namespace [” + namespaceUri + “] not found”, var7); } catch (LinkageError var8) { throw new FatalBeanException(“Invalid NamespaceHandler class [” + className + “] for namespace [” + namespaceUri + “]: problem with handler class file or dependent class”, var8); } }}resolve() 方法用途是根据方法参数中的 namespaceUri 获取对应的 NamespaceHandler 对象。这里会先尝试以 namespaceUri 为 key 去 handlerMappings 集合中取对象。如果 handlerOrClassName 不为 null 且不为 NamespaceHandler 的实例。那么尝试将 handlerOrClassName 作为 className 并调用 BeanUtils.instantiateClass() 方法初始化一个NamespaceHandler 实例。初始化后，调用其 init() 方法。这个 init() 方法比较重要，我们接着往下看。DubboNamespaceHandlerpublic void init() { registerBeanDefinitionParser(“application”, new DubboBeanDefinitionParser(ApplicationConfig.class, true)); registerBeanDefinitionParser(“module”, new DubboBeanDefinitionParser(ModuleConfig.class, true)); registerBeanDefinitionParser(“registry”, new DubboBeanDefinitionParser(RegistryConfig.class, true)); registerBeanDefinitionParser(“monitor”, new DubboBeanDefinitionParser(MonitorConfig.class, true)); registerBeanDefinitionParser(“provider”, new DubboBeanDefinitionParser(ProviderConfig.class, true)); registerBeanDefinitionParser(“consumer”, new DubboBeanDefinitionParser(ConsumerConfig.class, true)); registerBeanDefinitionParser(“protocol”, new DubboBeanDefinitionParser(ProtocolConfig.class, true)); registerBeanDefinitionParser(“service”, new DubboBeanDefinitionParser(ServiceBean.class, true)); registerBeanDefinitionParser(“reference”, new DubboBeanDefinitionParser(ReferenceBean.class, false)); registerBeanDefinitionParser(“annotation”, new AnnotationBeanDefinitionParser());}NamespaceHandlerSupportprivate final Map<String, BeanDefinitionParser> parsers = new HashMap();protected final void registerBeanDefinitionParser(String elementName, BeanDefinitionParser parser) { this.parsers.put(elementName, parser);}DubboNamespaceHandler 类中的 init() 方法干的事情特别简单，就是新建 DubboBeanDefinitionParser 对象并将其放入 NamespaceHandlerSupport 类的 parsers 集合中。我们再回顾一下 parseCustomElement() 方法。BeanDefinitionParserDelegate.javapublic BeanDefinition parseCustomElement(Element ele, BeanDefinition containingBd) { // 省略… return handler.parse(ele, new ParserContext(this.readerContext, this, containingBd)); // 省略…}这里会调用 NamespaceHandlerSupport 类的 parse() 方法。我们继续跟踪一下。public BeanDefinition parse(Element element, ParserContext parserContext) { return this.findParserForElement(element, parserContext).parse(element, parserContext);}private BeanDefinitionParser findParserForElement(Element element, ParserContext parserContext) { String localName = parserContext.getDelegate().getLocalName(element); BeanDefinitionParser parser = (BeanDefinitionParser)this.parsers.get(localName); if (parser == null) { parserContext.getReaderContext().fatal(“Cannot locate BeanDefinitionParser for element [” + localName + “]”, element); } return parser;}看到这里大家有没有一丝豁然开朗的感觉？之前的 resolve() 方法实际上就是根据当前 element 的 namespaceURI 获取对应的 NamespaceHandler 对象(对于 Dubbo 来说是 DubboNamespaceHandler)，然后调用 DubboNamespaceHandler 中的 init() 方法新建 DubboBeanDefinitionParser 对象并注册到 NamespaceHandlerSupport 类的 parsers 集合中。然后 parser 方法会根据当前 element 对象从 parsers 集合中获取合适的 BeanDefinitionParser 对象。对于 Dubbo 元素来说，实际上最后执行的是 DubboBeanDefinitionParser 的 parse() 方法。DubboBeanDefinitionParser.parse()最后我们再来看看 Dubbo 解析 XML 文件的详细实现吧。如果对具体实现没有兴趣可直接直接跳过。private static BeanDefinition parse(Element element, ParserContext parserContext, Class<?> beanClass, boolean required) { RootBeanDefinition beanDefinition = new RootBeanDefinition(); beanDefinition.setBeanClass(beanClass); beanDefinition.setLazyInit(false); String id = element.getAttribute(“id”); // DubboBeanDefinitionParser 构造方法中有对 required 值进行初始化； // DubboNamespaceHandler 类中的 init 方法会创建并注册 DubboBeanDefinitionParser 类 if ((id == null || id.length() == 0) && required) { String generatedBeanName = element.getAttribute(“name”); if (generatedBeanName == null || generatedBeanName.length() == 0) { if (ProtocolConfig.class.equals(beanClass)) { generatedBeanName = “dubbo”; } else { // name 属性为空且不为 ProtocolConfig 类型，取 interface 值 generatedBeanName = element.getAttribute(“interface”); } } if (generatedBeanName == null || generatedBeanName.length() == 0) { // 获取 beanClass 的全限定类名 generatedBeanName = beanClass.getName(); } id = generatedBeanName; int counter = 2; while (parserContext.getRegistry().containsBeanDefinition(id)) { id = generatedBeanName + (counter++); } } if (id != null && id.length() > 0) { if (parserContext.getRegistry().containsBeanDefinition(id)) { throw new IllegalStateException(“Duplicate spring bean id " + id); } // 注册 beanDefinition parserContext.getRegistry().registerBeanDefinition(id, beanDefinition); // 为 beanDefinition 添加 id 属性 beanDefinition.getPropertyValues().addPropertyValue(“id”, id); } // 如果当前 beanClass 类型为 ProtocolConfig // 遍历已经注册过的 bean 对象，如果 bean 对象含有 protocol 属性 // protocol 属性值为 ProtocolConfig 实例且 name 和当前 id 值一致，为当前 beanClass 对象添加 protocl 属性 if (ProtocolConfig.class.equals(beanClass)) { for (String name : parserContext.getRegistry().getBeanDefinitionNames()) { BeanDefinition definition = parserContext.getRegistry().getBeanDefinition(name); PropertyValue property = definition.getPropertyValues().getPropertyValue(“protocol”); if (property != null) { Object value = property.getValue(); if (value instanceof ProtocolConfig && id.equals(((ProtocolConfig) value).getName())) { definition.getPropertyValues().addPropertyValue(“protocol”, new RuntimeBeanReference(id)); } } } } else if (ServiceBean.class.equals(beanClass)) { // 如果当前元素包含 class 属性，调用 ReflectUtils.forName() 方法加载类对象 // 调用 parseProperties 解析其他属性设置到 classDefinition 对象中 // 最后设置 beanDefinition 的 ref 属性为 BeanDefinitionHolder 包装类 String className = element.getAttribute(“class”); if (className != null && className.length() > 0) { RootBeanDefinition classDefinition = new RootBeanDefinition(); classDefinition.setBeanClass(ReflectUtils.forName(className)); classDefinition.setLazyInit(false); parseProperties(element.getChildNodes(), classDefinition); beanDefinition.getPropertyValues().addPropertyValue(“ref”, new BeanDefinitionHolder(classDefinition, id + “Impl”)); } } else if (ProviderConfig.class.equals(beanClass)) { parseNested(element, parserContext, ServiceBean.class, true, “service”, “provider”, id, beanDefinition); } else if (ConsumerConfig.class.equals(beanClass)) { parseNested(element, parserContext, ReferenceBean.class, false, “reference”, “consumer”, id, beanDefinition); } Set<String> props = new HashSet<String>(); ManagedMap parameters = null; for (Method setter : beanClass.getMethods()) { String name = setter.getName(); if (name.length() > 3 && name.startsWith(“set”) && Modifier.isPublic(setter.getModifiers()) && setter.getParameterTypes().length == 1) { Class<?> type = setter.getParameterTypes()[0]; String propertyName = name.substring(3, 4).toLowerCase() + name.substring(4); String property = StringUtils.camelToSplitName(propertyName, “-”); props.add(property); Method getter = null; try { getter = beanClass.getMethod(“get” + name.substring(3), new Class<?>[0]); } catch (NoSuchMethodException e) { try { getter = beanClass.getMethod(“is” + name.substring(3), new Class<?>[0]); } catch (NoSuchMethodException e2) { } } if (getter == null || !Modifier.isPublic(getter.getModifiers()) || !type.equals(getter.getReturnType())) { continue; } if (“parameters”.equals(property)) { parameters = parseParameters(element.getChildNodes(), beanDefinition); } else if (“methods”.equals(property)) { parseMethods(id, element.getChildNodes(), beanDefinition, parserContext); } else if (“arguments”.equals(property)) { parseArguments(id, element.getChildNodes(), beanDefinition, parserContext); } else { String value = element.getAttribute(property); if (value != null) { value = value.trim(); if (value.length() > 0) { // 如果属性为 registry，且 registry 属性的值为"N/A”，标识不会注册到任何注册中心 // 新建 RegistryConfig 并将其设置为 beanDefinition 的 registry 属性 if (“registry”.equals(property) && RegistryConfig.NO_AVAILABLE.equalsIgnoreCase(value)) { RegistryConfig registryConfig = new RegistryConfig(); registryConfig.setAddress(RegistryConfig.NO_AVAILABLE); beanDefinition.getPropertyValues().addPropertyValue(property, registryConfig); } else if (“registry”.equals(property) && value.indexOf(’,’) != -1) { // 多注册中心解析 parseMultiRef(“registries”, value, beanDefinition, parserContext); } else if (“provider”.equals(property) && value.indexOf(’,’) != -1) { parseMultiRef(“providers”, value, beanDefinition, parserContext); } else if (“protocol”.equals(property) && value.indexOf(’,’) != -1) { // 多协议 parseMultiRef(“protocols”, value, beanDefinition, parserContext); } else { Object reference; if (isPrimitive(type)) { // type 为方法参数，type 类型是否为基本类型 if (“async”.equals(property) && “false”.equals(value) || “timeout”.equals(property) && “0”.equals(value) || “delay”.equals(property) && “0”.equals(value) || “version”.equals(property) && “0.0.0”.equals(value) || “stat”.equals(property) && “-1”.equals(value) || “reliable”.equals(property) && “false”.equals(value)) { // 新老版本 xsd 兼容性处理 // backward compatibility for the default value in old version’s xsd value = null; } reference = value; } else if (“protocol”.equals(property) && ExtensionLoader.getExtensionLoader(Protocol.class).hasExtension(value) && (!parserContext.getRegistry().containsBeanDefinition(value) || !ProtocolConfig.class.getName().equals(parserContext.getRegistry().getBeanDefinition(value).getBeanClassName()))) { // 如果 protocol 属性值有对应的扩展实现，而且没有被注册到 spring 注册表中 // 或者 spring 注册表中对应的 bean 的类型不为 ProtocolConfig.class if (“dubbo:provider”.equals(element.getTagName())) { logger.warn(“Recommended replace <dubbo:provider protocol="” + value + “" … /> to <dubbo:protocol name="” + value + “" … />”); } // backward compatibility ProtocolConfig protocol = new ProtocolConfig(); protocol.setName(value); reference = protocol; } else if (“onreturn”.equals(property)) { int index = value.lastIndexOf(”.”); String returnRef = value.substring(0, index); String returnMethod = value.substring(index + 1); reference = new RuntimeBeanReference(returnRef); beanDefinition.getPropertyValues().addPropertyValue(“onreturnMethod”, returnMethod); } else if (“onthrow”.equals(property)) { int index = value.lastIndexOf(”.”); String throwRef = value.substring(0, index); String throwMethod = value.substring(index + 1); reference = new RuntimeBeanReference(throwRef); beanDefinition.getPropertyValues().addPropertyValue(“onthrowMethod”, throwMethod); } else if (“oninvoke”.equals(property)) { int index = value.lastIndexOf("."); String invokeRef = value.substring(0, index); String invokeRefMethod = value.substring(index + 1); reference = new RuntimeBeanReference(invokeRef); beanDefinition.getPropertyValues().addPropertyValue(“oninvokeMethod”, invokeRefMethod); } else { // 如果 ref 属性值已经被注册到 spring 注册表中 if (“ref”.equals(property) && parserContext.getRegistry().containsBeanDefinition(value)) { BeanDefinition refBean = parserContext.getRegistry().getBeanDefinition(value); // 非单例抛出异常 if (!refBean.isSingleton()) { throw new IllegalStateException(“The exported service ref " + value + " must be singleton! Please set the " + value + " bean scope to singleton, eg: <bean id="” + value + “" scope="singleton" …>”); } } reference = new RuntimeBeanReference(value); } beanDefinition.getPropertyValues().addPropertyValue(propertyName, reference); } } } } } } NamedNodeMap attributes = element.getAttributes(); int len = attributes.getLength(); for (int i = 0; i < len; i++) { Node node = attributes.item(i); String name = node.getLocalName(); if (!props.contains(name)) { if (parameters == null) { parameters = new ManagedMap(); } String value = node.getNodeValue(); parameters.put(name, new TypedStringValue(value, String.class)); } } if (parameters != null) { beanDefinition.getPropertyValues().addPropertyValue(“parameters”, parameters); } return beanDefinition; }上面这一大段关于配置的解析的代码需要大家自己结合实际的代码进行调试才能更好的理解。我在理解 Dubbo XML 解析的时候，也是耐着性子一遍一遍的来。 关于 ProtocolConfig 和 protocol 加载先后顺序的问题最后再集合一个小例子总结下吧： dubbo-demo-provider.xml <dubbo:protocol name=“dubbo” port=“20880”/>当我们先解析了 ProtocolConfig 元素时，我们会遍历所有已经注册 spring 注册表中 bean。如果 bean 对象存在 protocol 属性且与 name 和当前 ProtolConfig id 匹配，则会新建 RuntimeBeanReference 对象覆盖 protocol 属性。对于上面这行配置，最后会新建一个拥有 name 和 port 的 beanDefinition 对象。先解析了 protocol 元素，ProtocolConfig 未被解析。此时我们在 spring 注册表中找不到对应的 ProtocolConfig bean。此时我们将需要新建一个 ProtocolConfig 并将其 name 属性设置为当前属性值。最后将其设置为 beanDefinition 对象的 protocol 属性。后面加载到了 ProtocolConfig 元素时，会替换 protocol 的值。EndDubbo 对于自定义 XML 标签的定义和解析实际上借助了 Spring 框架对自定义 XML 标签的支持。本篇水文虽然又臭又长，但是对于理解 Dubbo 的初始化过程还是很重要的。后面我们会介绍关于 Dubbo 服务暴露相关内容。本BLOG上原创文章未经本人许可，不得用于商业用途及传统媒体。网络媒体转载请注明出处，否则属于侵权行为。https://juejin.im/post/5c1753… ...

双11猫晚是家喻户晓的综艺晚会，在今年的双11，阿里集团为2500万用户提供了一场在线直播视觉盛宴。网友评价这是一场既稳定流畅又高清的直播，当然在这背后离不开阿里云的技术支持。本次天猫晚会中，视频云首次采用4k和50帧的技术，把整个画质提升到接近肉眼极限，同时为用户提供了如丝般顺滑的直播体验。那么这么一场大型活动的直播究竟是如何炼成的呢？阿里云视频云技术专家裘良科带我们从稳定、画质、流畅、监控四个方面开始解读。如何做到100%稳定？裘良科认为：“最安全的做法就是做好500%的准备，以不便应万变。”下图是双11直播的技术架构，分为几大部分：直播源站、视频直播中心和CDN分发系统和客户端。简单的看这张图，所有的链路都是双备份的。直播源站部分，采用了多线收流、主备转码器、多线专线等策略，直播中心都是多机房接入，再采用多流合并，当任何一个机房出现问题的时候，输出的直播流是不会受任何影响的。在这之后，直播中心会对直播流进行转码、录制、智能处理、切片、时移回放等处理，中间所有模块都是专有资源池供大型活动使用，保证不会受其他活动影响。任何一个模块发生异常，都可以秒级进行切换。产生到的内容在分发之前，会先进行存储，中心主备。到了分发环节，会实时检查源站的质量，并进行切换。在这样的架构之下，任何单点、单机房、单线路、单模块的故障，都不会导致直播服务不可用，几乎做到绝对安全。当然，除了自身稳定之外，安全也十分重要。在安全方面，视频云在推流、播放和拉流等环节，采用多重鉴权、IP黑白名单、播放格式/地区/IP等限制、HTTPS、防劫持等能力，实现全链路安全保障。如何让用户享受到极致的画质？一、实时4K直播视频清晰度作为衡量用户体验的重要指标，也是视频云技术团队十分关注的方向。本次猫晚的视频清晰度再度升级，通过阿里云直播服务提供实时4K直播，将现场4K超高清、高帧率的视频实时处理，进行画质提升。在4K视频的处理上，直播服务大规模使用GPU进行视频处理及转码，大大提升了实时视频处理能力，保证了直播视频最高4K的HEVC实时转码。据悉，4K高清直播已在阿里云的众多游戏直播客户中广泛使用。二、50帧极清阿里云和优酷合力研发的50帧极清技术，可通过人工智能算法预测运动方向和轨迹，将原始的每秒25帧画面普通电视信号变换为每秒50帧画面的高帧率视频内容，给用户提供更加流畅的沉浸式观看体验。50帧极清的效果，就像去电影院看大片，动作效果非常丰富的情况下，也不存在顿挫感。今年夏天的世界杯和本次双11猫晚都采用50 帧技术，视觉上看是非常流畅的。三、码率（比特率）最佳配比除了4K技术，基于内容进行编码优化也是视频云的优势。裘良科表示：“阿里的窄带高清技术精髓就在于使每一个比特分配到最需要它的地方。”这里我们先来看几个概念：分辨率是图像精密度的概念，代表着质量的极限，是不是越大越好呢？是也不是。分辨率大，点就多，需要的码率就高，需要的带宽就会变大，传输成本和对网络的要求都会变大。码率，比就是比特率，它代表单位时间传送的数据位数，视频文件大小就是由码率决定的，而且是成正比。帧率，代表着视觉流畅度，在我国通常帧率在25帧左右。然而帧率达到50-60的时候，我们几乎肉眼察觉不到间隔和差异。那我们如何在帧间和帧内进行合理码率分配，以达到最优的平衡呢？1. 合理分配帧间码率每一帧都需要码率来显示图像，那么我们如何判断哪一帧需要较多的帧率？哪一帧需要较少呢？其实这就需要基于对内容的分析，提前进行预判，你认为这一帧是复杂的画面，比如好莱坞动作大片，就多分配帧率，如果这一阵比较简单，比如新闻联播，就少分配。以此来实现合理的帧间码率分配。2. 合理分配帧内码率在整个图像中，并不是全部都需要非常清楚的。比如说你在看晚会的时候，你看的是中间的人物嘉宾，所以把人物和脸识别出来，就是你眼睛聚焦的地方，多分配一些码率。同时，衣服的褶皱纹理也多分配一些码率，背景作为脱焦区域，就少分配一些码率了。通过帧间、帧内的码率分配，让整个视频的质量更高。在同等码率之下，获得更高的质量。同样质量之下，可以节省更多带宽。那在播放层面，如何保证流畅不卡顿呢？裘良科认为，在确保直播流畅度上，全球覆盖的CDN节点和精准调度系统缺一不可。CDN节点是采用分布式架构，拥有遍布全球的1500个节点和充足的带宽储备，单节点带宽 40Gbps+，全网带宽输出能力120 Tbps。同时采用四层智能调度架构（如下图），来确保整个分发的流畅。如何实现精准调度，确保大型活动突发峰值的流畅但是面对晚会等大型活动，突发峰值非常高，需要更精准的调度策略，来实现调度。打比方有一个装了很多冰块和水的杯子，如果我们要把杯子里面的狭小空间全部用上，我们先要把冰块放进去，再倒液态水。DNS的协议限制类似冰块。其他别的调度形式，比如IP调度，可以做好请求级别的调度，也就是支持任意比例的负载均衡，就像液态水一样。所以，在智能调度的场景里，把“固体”和“液体”结合起来考虑，才能做到所有的节点、水位的精准控制，实现更精准的调度。同时，在码率瞬间激增的情况下，常规的流量预测算法失算了，进而会干扰流控程序, 这个问题阿里云使用了基于AI流量预测进行预调度，在10分钟内的预测的精准度到98%，一小时的精准度95%以上。监控系统保驾护航在确保了稳定、画质和流畅之后，一场大型活动的直播离不开监控系统。我们肯定需要对当前的直播状态做监控，以确保及时调整策略。监控从以下四个方面进行：1、流监控：针对每一路流进行秒级实时监控，及时获得直播流的帧率、码率、时间戳等状态2、播放质量监控：实时获知服务端慢速比，用户端卡顿率3、可用性监控：实时返回视频5XX等播错误数据，及时定位视频失败原因4、业务量监控：实时获取当前在线用户数作为这场猫晚的唯一网络直播平台，优酷平台上直播观看人数近2500万，是去年的两倍。这也是阿里云视频云第四年支持双11猫晚网络直播，从作战室监控的数据上来看，猫晚直播期间各项系统数据指标运转平稳，一场稳定、高清、流畅的大型活动直播就就此实现。经过世界杯、双11猫晚等多次锤炼，视频云直播服务已经具备一整套大型赛事/活动/综艺直播的服务经验，并实现对阿里云各行业客户的赋能，为视频行业创造更多价值。本文作者：樰篱 阅读原文本文为云栖社区原创内容，未经允许不得转载。

12月27日，Conflux受邀参与TokenGazer举办的在线问答活动，Conflux CTO伍鸣博士与参与活动的百余名研究员进行了深度问答、科学辨析。此次活动让大家深刻的了解到Conflux的技术优势和发展潜力，也让更多人对Conflux的未来发展坚定了积极的信念。（以下为此次活动的文字整理版）问题1：Conflux使用的有向无环图（DAG）跟比特币、以太坊的区块链结构有什么具体不同，优势是什么？伍鸣@Conflux： 这个问题是一个非常本质的问题，我愿意展开来谈一谈，这要从比特币的效率局限性谈起。根据一些论文，在比特币协议中，无论如何调整出块速度和区块大小这两个参数，速度与安全不可兼得。这其中的原理是什么呢？我们想象一下，如果两个区块都是由诚实节点生成的，但是因为网络延迟，他们在生成的时候互相没有看到对方，那么在两个不同的分叉上，那么它们就会在不同的分叉上。一旦进入到不同的分叉上，二者便是你死我活的竞争关系，最终有一个区块被丢弃。诚实节点的区块被丢弃，损失的诚实节点的总算力。分叉越多，好人区块的内讧越多，坏人的攻击门槛越低，比特币越不安全。为了安全，比特币必须维持一个低的吞吐量。Conflux使用有向无环图结构 (DAG)，我们允许每个区块引用多个区块作为自己的祖先区块，可以避免好人之间的这种竞争，从而打破比特币的矛盾，在提高效率的前提下不牺牲安全性。以太坊与比特币相比特殊一些，以太坊其实有了DAG的雏形。关注区块链技术的朋友可能知道，以太坊中有叔块的概念。一些区块选一个父块，几个叔块，看似也构成了一个DAG。但是，以太坊的叔块只是为了给没有进主链的区块发一点鼓励安慰的系统奖励，叔块中的交易依然会被丢弃。如果将以太坊的出块速度提高，导致分叉过多，其有效吞吐率依然很低。下面有图可以更好地展示优势，这张图展示了4MB大小区块下不同出块时间下被保留区块的数量。Conflux保留了所有区块，比特币和Ghost (以太坊协议改自这个协议) 则由于分叉丢失了大量的区块。总结一下：①Conflux是和比特币、以太坊类似的PoW公链，但允许一个区块引用多个区块作为祖先，从而构成一个DAG。②比特币、以太坊的实际吞吐率很低，即使你尝试减少出块间隔或者增加区块大小，也无法得到一个安全性和效率兼得的公链。③和比特币、以太坊相比，Conflux可以在不牺牲去中心化和安全性的情况下，提高吞吐率。问题2：基于DAG的智能合约会遇到“交易顺序问题”，比如谁先预定到某航班的座位跟交易顺序有关，Conflux有没有比较好的设计解决这个问题？伍鸣@Conflux： “预定航班座位”是一个很好的例子，从这个例子可以看到，在DAG中，如果不同的交易需要竞争合约中的资源（比如航班座位），区块排序与交易排序是一件十分必要的事情。这将决定谁的交易在前，谁的交易在后，谁最终得到了这个座位。也是因为这一点，我们需要对DAG中的区块设计一个拓扑排序算法，将所有区块排一个顺序，然后根据区块的顺序决定交易的执行顺序。而且这个拓扑排序需要满足以下几点：· 一致性：不同矿工节点排的结果是一致的。如果一些矿工告诉你选座成功，一些矿工告诉你选座失败，你就会很困惑。· 安全性（不可更改性）：排序结果不能被坏人的攻击更改。比如说，你选了一个座位，5分钟后，这笔交易确认成功了，你很开心。三天后你登机的时候，发现排序发生了更改，你的座位没了。这也是很严重的公链安全事故。Conflux设计了一个满足上述要求的安全拓扑排序算法，算法输入一个DAG，输出DAG中区块的一个拓扑排序。每个矿工（全节点）将本地机器的DAG上输入这个算法，就可以得到区块排序，根据这个结果，就知道了应该先执行谁，后执行谁。“一致性与安全性”可能比较抽象，我们举个例子。今天，这个DAG中有10000个区块，9900个区块里的交易已经被确认。明天，这个DAG有20000 个区块，那么把明天的DAG和今天的DAG分别作为算法的输入，前9900个区块应当是一样的，哪怕有坏人在做双花攻击。这就是一致性与安全性。Conflux 的算法设计可以保证一致性与安全性。关于这个排序算法具体是如何设计的，感兴趣的伙伴们可以阅读我们的论文或者科普文章。总而言之，Conflux通过设计安全的拓扑排序算法，解决“交易顺序问题”。问题3：如何解决不同区块内的打包交易的交易冲突问题，了解到当交易冲突时时间稍后的冲突交易会被“discard”掉，这个被丢弃的交易是怎样和有效交易进行状态区分的？伍鸣@Conflux： 在问题2中，我们已经解决了交易顺序问题。那么当所有节点对DAG得到一个一致的区块排序时，只要遵循一个规则：“发生重复或冲突者，排序居后的交易无效”，就可以判断哪些交易是无效的交易，然后自己在本地标记一下就行。区块排序的一致可以保证“无效交易标记”的一致。额外说一点，由于每笔交易是否有效是每个矿工自己做出的判断，而没有持久化写在区块中，所以无法实现像比特币那样，通过Merkle Path向轻节点证明一个交易在区块中，因为你无法通过Merkle Path知道它是有效的还是无效的。但是，Conflux采用账本模型，每个区块头会存储当前账本状态的哈希值。通过这个哈希值，很容易向轻节点证明指定地址的余额等。总结一下：①被丢弃的交易由全节点本地进行标记，一致的排序结果保证一致的标记。②基于这一点，Conflux轻节点的交易验证与比特币有所不同。问题4：那无效的交易会被追加一个状态么，或者说我在区块浏览器只查看交易哈希时，能否看出这两笔交易（有效和无效）的区别?伍鸣@Conflux： 交易是否无效可以看成是交易执行的某种结果，这种结果状态是可以记录在区块中的，这样，在区块浏览器中就可以查到这种状态。问题5：这个交易执行结果是标记在本地还是在链上？伍鸣@Conflux： 标记是在本地，但链上也会有所提现。之前的回答中其实提到，每个区块头会存储当前账本状态的哈希值，通过主链区块的账本状态，会体现历史区块中每笔交易是否有效。问题6：跟其他链不同，无效的交易不会记录在链上，Conflux是需要对无效交易本地打标，这是否可能对不了解的用户有学习成本，以及利用这一点来混淆用户的可能?伍鸣@Conflux： 通过浏览器提供标记，可以帮助普通用户判断一笔交易是否有效。问题7: DAG结构中不存在“叔块”问题，网络中是否会存在过多的空块或者区块中的交易重复导致区块数据冗余，从而对节点的网络和硬件配置带来压力？伍鸣@Conflux： 首先，DAG中每一个区块都是需要消耗算力才能生成的，所以网络中各种区块，无论是正常的区块还是空块，其数量受挖矿难度的制约，是有一个上界的。所以，对节点的网络和硬件不会带来额外的压力。其次，空块或重复交易过多确实会影响利用率和实际的交易吞吐率。所以我们需要为矿工们设计一个交易选择算法，从交易等待池中，根据交易费加权随机抽取交易，以最大限度避免交易重复。这个算法的设计应当考虑激励兼容性 (Incentive Compatible)，以从经济激励上鼓励矿工遵守这个算法。问题8: 这个算法是否已经完成？伍鸣@Conflux： 这个算法的设计和理论分析已经有了，现在在我们的系统中开发实现，还没有完成。问题9：理论基础就是姚教授的新论文？伍鸣@Conflux： 姚老师的论文是基于比特币进行分析的，对我们这个算法的理论基础有一定的启发。问题10：项目是否会进行预挖？主网启动后矿工奖励是否会有变化，枢轴链和分叉链上的区块的区块奖励是否一样。伍鸣@Conflux： 和以太坊一样，创始块会分配一定比例的代币。每个区块的基础系统奖励开始比较多，时间长了以后会逐渐减少。在 Conflux 中，每个区块的系统奖励不是一个固定值，是根据一个规则算出来的。枢轴链和分叉链的区块奖励计算规则是一致的。（小编注释：在介绍这个规则之前，我们先来考虑一下一种情形。在Conflux 规则里，每个新的区块应该选择一些引用边，使所有已经存在的区块成为它的祖先。(具体的选边规则参见我们的文章)。但是一个坏人可能会出于某种目的，在挖出一个新的区块时，假装没收到或没看见一些区块，以获取更多的交易费。我们就要惩罚坏人这种行为，假装没看到的区块越多，这个区块的区块奖励越少。）如果要具体地描述这个规则，就要先讲一个概念：“光锥外区块”(anticone-block)。什么是“光锥外区块”呢？在DAG中，如果两个区块之间没有一条路径，这两个区块的互为对方的 “光锥外区块”, 比如在下图中，B和C互为对方的光锥外区块。一个区块的系统奖励会与基础系统奖励和它的光锥外区块的数量有关，光锥外区块越多，其奖励越少。（小编注释：当坏人挖出一个新区块时，那些假装没收到没看见的区块，都会成为新区块的“光锥外区块”。）如此设计，是为了鼓励每个矿工遵守选择引用边的协议。问题11：项目预挖的比例是多少呢。还有区块减少的规则（比如比特币每隔4年减半）？伍鸣@Conflux： 这些具体的数据会在我们主网上线之前公布，大家可以关注我们的公众号。问题12：这个设计的会让区块内的奖励会有不同，矿工要额外技术要挖快的预计奖励对吧？那这样的话，币的数量是否会有不确定性？因为区块的奖励不确定，导致一年之后挖的币的数量不可控？伍鸣@Conflux： 这个设计会让区块内的奖励有不同，但是，在正常情况下，这个差异不会很大。我们希望用这个差异，来鼓励矿工们遵守协议。问题13：Conflux预计主网上线是什么时间，TPS能达到多少。伍鸣@Conflux： 我们的测试网预计在明年3月份上线，主网上线预计在明年Q3或Q4。—小编：在这次在线问答中，我们发现很多关心区块链的小伙伴对奖励机制和挖矿规则很感兴趣，我们会在后期特别推出一篇关于此话题的技术文章，欢迎小伙伴们关注我们的公众号来随时掌握更新状态！

1.1 什么是架构1.1.1 架构简述【优秀架构具备的特点】：优秀的 TPS 承载力优秀的性能故障影响降到最小投入产出最优方案1.1.2 架构师职责明确需求系统能力分解技术选型制定架构说明书及主导执行落地1.2 架构设计分层1.2.1 为什么要分层分而治之各司其职有条不紊的结合1.2.2 常见的分层设计计算机网络 OSI 七层模型Web 系统 MVC 模型分层基于领域模型的分层1.2.3 分层模型演进一、Servlet JSP 时代（V0.1）Servlet + Tomcat 容器完成 Web 接入使用 JavaBean + JDBC 完成数据层接入使用 JSP 完成页面展示二、MVC（V1.0）【V 1.0 时代 典型代表 SSH】Structs 解决接入及表示层。（ActionServlet 重）Spring 解决业务服务、事务处理、会话管理。Hibernate 解决数据存储接入问题。（特殊的SQL处理繁琐；SET 联动数据库问题）三、SSM 时代（V1.5）SpringMVC 解决接入及表示层Spring 解决业务服务、事务处理、会话管理等问题MyBatis 解决数据接入层四、SpringBoot all in one（V2.0）整合了所有 Spring 的框架功能提供了简单的配置及注解的接入方式提供 All in one 的服务【V2.0 存在的问题】：解决了单一应用内的软件分层，却没有解决整体应用的分层单一应用的性能瓶颈，无法支撑亿级流量团队协作问题五、分布式分层（V3.0）1、WEB概念层2、业务概念层3、数据访问记存储层

你们知道的，双11之后，我们做了一件晴天修屋顶的事儿，就是进行组织架构的调整——阿里云升级为阿里云智能；天猫升级为“大天猫”，形成天猫事业群、天猫超市事业群、天猫进出口事业部三大板块；加强技术、智能互联网的投入和建设。几天前，CEO逍遥子(张勇)在阿里的内网里，分享了自己在阿里青训营上，对组织架构升级的思考。今天橙子把内网上的逍遥子内部分享给你们搬过来啦！全都是干货哦~敲黑板，划重点◌ 学习“用人做事”，而不仅仅是“做事用人”；◌ 要善于从后排把人往前拔，Leader要有不拘一格降人才的心态；◌ 打仗不是协同，打仗是统一指挥；◌ 战略重要性业务，必须“升格建制”；◌ 真正完成创造性的工作，仅靠数字化的KPI肯定不行；◌“组织、人才”是业务一号位的首要工作，而不是HR；◌ 任何商业设计模式创新必须进行自上而下的组织设计；◌ 逍遥子每年问自己两个问题：第一，为集团找了哪几个人，关键是“找”，不是“招”；第二，为集团开辟了哪几个新赛道。↓ 以下是逍遥子分享的全文：“组织”一定是业务一把手的首要工作，而不是HR作为领导者，非常重要的一件事是排兵布阵。所谓“排兵布阵”在今天的具体场景里，就是怎么设计组织架构。组织设计不是HR的工作，而是业务一号位的首要工作。HR一号位配合业务一号位来完成组织设计和落地的执行。怎么样进行组织的设计、拆分、合并、目标设计，包括什么样的人在里面担任某个团队的Leader，充满了无穷的奥妙。如何“用人做事”，而不是“做事用人”2012年双11前夜，马老师送给我八个字。当时我们在万塘路口，华星时代广场上面，天猫大本营当时在那边，他说逍遥子，你现在是“做事用人”，但你要走向“用人做事”。“做事用人”就是你把事情怎么做想得清清楚楚，但越往后走，团队越来越大，组织越来越复杂，你要考虑整个组织每个板块结构怎么设计。什么叫从“做事用人”到“用人做事”？做事用人是事情已经想清楚了，找一个合适的人来干。相信很多人还在这个阶段。越往后走，会接触到“用人做事”，这事儿怎么干你也没搞清楚，你根本不是这方面的专家，但要找到最有可能把这个事情想清楚和做出来的人，让他来带一个合适的组织。我自己这几年的体会，用人做事和做事用人，跟组织设计是两件事，但高度相关。这两件事情都非常值得大家去体会。做事用人的核心，你把组织都想好，从上到下清清楚楚，你就可以排兵布阵，把人放到合适的位置上，按照既定策略做。另一种是事情没完全想清楚，但是你找到一个人，他能想清楚，或者他能把下面条分缕析地安排好，来设计组织，这就是用人做事。用人做事和做事用人，跟整个组织今天的状态、人的状态都有密切的关系。有时候过早地从做事用人到用人做事，是拔苗助长，因为经常你想不清楚的，你别指望另一个人能想清楚。在很多领域，人不可能是万宝书，人一定是在一方面有经验，另一方面经验相对缺乏，需要更有经验的人来做这个事情。组织调整不只是集团层面的调整，也不只是大的BG层面的调整，每个人都在运营一个组织，不同只是这个组织到底是由两万人组成、2000个人、200个人、还是20人组成。大家都面临排兵布阵的问题。仗怎么打，怎么样运筹帷幄、决胜千里，不仅要用策略，还要有排兵布阵，而排兵布阵就是从一个主管走向一个Leader最重要的变化。这个过程中非常重要的是，无论用人做事、做事用人，最终人从哪儿来。人分两种，一种是他本身执行力非常强，你只要给他清晰的策略，你非常自信这个策略会work，而且这个人适合做这个事情，这就是“做事用人”。另一种是，你相信他的策略，相信他的排兵布阵能力，你把这件事交给他展开，这个就是用人做事。但非常重要的是，大家一想，这对人的要求太高了，我找“做事用人”的人还容易找，我找“用人做事”的人，我哪儿去找。这就涉及到下面要讲的，如果这样，永远没有现成的人。领导者要善于“从后排把人往前拔”十年前，我从来不会想象我今天会跟大家讲这些，为什么？你经历了，从实战中学习，慢慢就有心得，就形成了自己的管理体系和方法论。只要每个人有学习能力，有悟性，愿意思考，都有可能。领导者有一些基因是天生的，但是大量训练是可以后天培养的，不然我也不可能从一个会计做成一个CEO。这个时候一定要考虑的就是，我们怎么样善于从后排把人往前拔。很容易发生的情况是，团队下面五个人，每个人干一件事情，干得很好，五年以后、三年以后、两年以后，这五个哥们还在干同样的事情。我把这个问题抛给大家，大家既是这个问题的对象，又是需要去思考这个问题的人。晋升、绩效体系、Review这些问题，从M3升到M4、M4升到M5、M5升到M6，他除了升了一级，干的事情、职责有没有不一样，我们有没有诚心栽培一个人。讲这句话，对一部分人有点早，对一部分人已经合适，但在我脑子里，没有合适不合适，今天所有人既是被栽培的对象，同时要想怎么栽培别人。你能培养出七段棋手，你就可以成为八段，你就有可能成为九段，不然业余初段一堆，但怎么样从业余初段长到业余四段，变成专业六段，靠的是实战。没有人天生是专业高段位选手。在这之中，第一，每个人要去想，我在每个调整当中，要达到的战略目标是什么。所有调整都是伴随战略目标设计来进行的。调整一定有目的。没有目的，就不需要做战略调整，没有战略目的，就不需要做组织调整。第二，组织跟人挂钩，人和事挂钩，到底“做事用人”还是“用人做事”。第三，人从哪儿来。这三个问题，你们都可以在这次调整当中找到各自的答案。为什么调整，每一块到底是用人做事还是做事用人，人从哪儿来。人不够，必须后排拔上来，不然永远只有这几个哥们在第一排站着，大家觉得很无趣，只能到墙外创业去了。这帮人在岗位上没干多久，也不算很老，但也不小了，上面还有五级，什么时候是个头。有不拘一格降人才的思考今天大家是“用人”当中的人。我们需要尽可能让新一代同事、年轻的同事、有潜力的同事，去承担更大职责，这时候需要一点“不拘一格降人才”的思考。但是这个思考只在集团顶部做是不够的。今天大家也要开始思考，你怎么去培养你下面的同事，如果你是M4，你怎么样让M3长起来，你多几个M3，多几个M4。一个M4能够管住四个M4，你不到M5才怪呢。当然这很难，比较接地气的说法，只要这个老板是M4，其他M4都不愿意来了，为什么？老板是M4，我没机会升了。但你能让别人来，还能让四个M4听你干，变成一个高效率的团队，说明你不是M4了，起码M5了。这次组织架构调整要点第一，打仗不是协同，打仗是统一指挥。今天只要我们面对一个突破性、开创性的业务，必须用统一指挥的思考，而不是用组织协同的方式来进行团队设计和生产关系设计。我们要避免用职能部门的协同，来完成开创性业务的进展，这是不可能的。什么叫做职能部门的协同？这个哥们管支付、那个哥们管物流、这个哥们管营销、这个哥们管运营，大家各自一个团队，你说你们协同吧，一起打一场仗，没有人当头，肯定不行。在几个必须突破性进行模式创新的业务当中，必须进行从商业到供应链，到物流的完整闭环设计，只有这样才能打穿，也只有这样打穿，才有机会去沉淀具体场景的平台。平台肯定不是从天上掉下来的，第一天想做平台的，没有一个做成的。平台都是不知不觉中了头彩，做了一个平台。如果我们今天“言必称平台”，基本上做不成，为什么？你沉淀的核心能力是什么，这非常重要。第二，作为战略重要性业务，必须“升格建制”。对于一些相对年轻的Leader来讲，因为这个领域的重要性，我们必须升格建制。说白了，师长找旅长，他最多想师长的事情，尽管还是一个师长，但是搞成军级单位，他的想法立马不一样了，他就变成军长思考了。任何商业设计模式创新，必须进行自上而下的组织设计今天只有在相对纯粹的用户领域的产品，有可能完成自下而上的突破。但在任何商业设计的模式创新上面，在0到0.5，0到1的基础上，完成最后1到100，必须进行组织设计。只有在用户产品侧，存在很多可能，我们要进行自下而上的创新。但在其它领域，非常重要的一点，从0到1要进行自下而上的创新。没有0到1的创新，那就是富二代创业。历史上发生过很多这样的例子，我们有个非常前沿的想法，觉得是未来方向。但不是坚信这个方向的人去做，我们只是安排了一个团队去做，到底是他信还是那个做的团队信。今天趁这个机会希望大家提醒自己，提醒你们的团队和周围的同事，真正完成一个创造性的工作，仅靠一个数字化的KPI肯定不行。我知道大家都关心KPI，我们团队也有KPI，大家都说结果导向、KPI导向，KPI导向本身没有问题，数字本身也是无罪的。关键是我们的心态，我们到底是为了去做到一个数字，做到一个DAU，一个转化率，一个装机率，还是给我们的客户创造价值，这是每个人都要去想的。我们很容易在一个具体的事情上想目标，比如有同学会说，我今年的KPI是DAU，我的目标是GMV，我们不惜一切代价搞到这个数字。但我们忘掉了这个数字背后的本源，为什么要设这么一个东西。组织要把它串起来讲，在整个目标设计上讲。第一，要取得突破性进展，要尽量避免团队协同，把职能部门完全变成一个战斗单元的组成部分，而不是一个外来协作。第二，云的战略，必须成为整个经济走向未来数字化经济的中台。阿里巴巴的云应该成为数字经济时代的云。我们的使命，是在数字经济时代，让天下没有难做的生意。怎么真正做到这点，靠的是广义的阿里巴巴云的体系。我们的云必须从大家现在熟悉的AAS层的物理基础设施，走向更丰富的产品矩阵，走向PAAS，在某些领域走向零售云。零售云是SAAS，是SAAS到PAAS到AAS的一体化方案、一体化服务。我们完全具备这样的机会，走向物流云、金融云、营销云。但是捕捉和实现这样的机会，不能只靠今天一个云BG的团队，要把整个阿里的技术中台力量沉淀、广告业务的沉淀，阿里妈妈的沉淀，通过这个平台进行输出。今天我们只完成了这里面的一步，就是让我们原来的技术中台跟我们的云能够结合。在这当中，怎么样能够真正增加云服务附加值，增加云服务的厚度，我们必须从智能上，必须从阿里其它服务的技术产品沉淀上找到机会，这就是今天把云和原来的技术中台合一的重要原因。当然技术团队都知道，今天我们云业务的集群，从规模、供应链管理，从跟供应商的关系来讲，已经成为整个集团的主导。如果是这样，我们当然应该把业务部门、支持部门，更好地跟最大的业务场景合在一起，让他们支持好集团的其它业务，这是对于整个云的思考。在整个变化中，菜鸟不能做成天猫的物流部，关键是继前几年的电子面单、智能物流这样的产品之后，菜鸟如何真正为物流产业提升效率、降低成本、带来价值，而这个服务是由数据和技术驱动的。整个变化中，真正能够把服务应用场景做成横向的赋能平台，这是我们的基本思考。IoT对我们非常重要，今天我们花了几年开始沉淀出一些初步的智能硬件能力、供应链能力、工业设计、产品定义能力。但是我们需要不断扩大这样的能力，在IoT时代，很可能软件、硬件、操作系统是一体的。不瞒大家说，作为集团CEO，我每年问自己两个问题，第一，今年我为集团找了哪几个人，记住关键词是“找”，不是“招”。第二，今年我为集团养了哪几个新业务，或者说开辟了哪几个新赛道。也许今年还很不起眼，还没法跟阿里妈妈、淘宝比，但可以看看有没有在鸡窝里开始孵几只小鸡。我们必须为未来准备新一代的领导者，为未来准备新业务。过年是自我总结的时间。我就琢磨，去年我干了一些啥，忙忙碌碌的，又是双11。还要想想，现在集团还需要哪方面的人，还有哪些重要赛道是空的，数万亿级别的赛道还是有很多的，关键这些赛道如何能在经济体里融为一体，形成一个真正的业务矩阵，而不是几个独立的山头。本文作者：学习橙阅读原文本文来自云栖社区合作伙伴“阿里味儿”，如需转载请联系原作者。

本文由云+社区发表本文作者：许中清，腾讯云自研数据库CynosDB的分布式存储CynosStore负责人。从事数据库内核开发、数据库产品架构和规划。曾就职于华为，2015年加入腾讯，参与过TBase（PGXZ）、CynosDB等数据库产品研发。专注于关系数据库、数据库集群、新型数据库架构等领域。目前担任CynosDB的分布式存储CynosStore负责人。企业IT系统迁移到公有云上已然是正在发生的趋势。数据库服务，作为公有云上提供的关键组件，是企业客户是否愿意将自己运行多年的系统搬到云上的关键考量之一。另一方面，自从System R开始，关系数据库系统已经大约四十年的历史了。尤其是随着互联网的发展，业务对数据库实例的吞吐量要求越来越高。对于很多业务来说，单个物理机器所能提供的最大吞吐量已经不能满足业务的高速发展。因此，数据库集群是很多IT系统绕不过去的坎。CynosDB for PostgreSQL是腾讯云自研的一款云原生数据库，其主要核心思想来自于亚马逊的云数据库服务Aurora。这种核心思想就是“基于日志的存储”和“存储计算分离”。同时，CynosDB在架构和工程实现上确实有很多和Aurora不一样的地方。CynosDB相比传统的单机数据库，主要解决如下问题：存算分离存算分离是云数据库区别于传统数据库的主要特点之一，主要是为了1）提升资源利用效率，用户用多少资源就给多少资源；2）计算节点无状态更有利于数据库服务的高可用性和集群管理（故障恢复、实例迁移）的便利性。存储自动扩缩容传统关系型数据库会受到单个物理机器资源的限制，包括单机上存储空间的限制和计算能力的限制。CynosDB采用分布式存储来突破单机存储限制。另外，存储支持多副本，通过RAFT协议来保证多副本的一致性。更高的网络利用率通过基于日志的存储设计思路，大幅度降低数据库运行过程中的网络流量。更高的吞吐量传统的数据库集群，面临的一个关键问题是：分布式事务和集群吞吐量线性扩展的矛盾。也就是说，很多数据库集群，要么支持完整的ACID，要么追求极好的线性扩展性，大部分时候鱼和熊掌不可兼得。前者比如Oracle RAC，是目前市场上最成熟最完善的数据库集群，提供对业务完全透明的数据访问服务。但是Oracle RAC的线性扩展性却被市场证明还不够，因此，更多用户主要用RAC来构建高可用集群，而不是高扩展的集群。后者比如Proxy+开源DB的数据库集群方案，通常能提供很好的线性扩展性，但是因为不支持分布式事务，对数据库用户存在较大的限制。又或者可以支持分布式事务，但是当跨节点写入比例很大时，反过来降低了线性扩展能力。CynosDB通过采用一写多读的方式，利用只读节点的线性扩展来提升整个系统的最大吞吐量，对于绝大部份公有云用户来说，这就已经足够了。存储自动扩缩容传统关系型数据库会受到单个物理机器资源的限制，包括单机上存储空间的限制和计算能力的限制。CynosDB采用分布式存储来突破单机存储限制。另外，存储支持多副本，通过RAFT协议来保证多副本的一致性。更高的网络利用率通过基于日志的存储设计思路，大幅度降低数据库运行过程中的网络流量。更高的吞吐量传统的数据库集群，面临的一个关键问题是：分布式事务和集群吞吐量线性扩展的矛盾。也就是说，很多数据库集群，要么支持完整的ACID，要么追求极好的线性扩展性，大部分时候鱼和熊掌不可兼得。前者比如Oracle RAC，是目前市场上最成熟最完善的数据库集群，提供对业务完全透明的数据访问服务。但是Oracle RAC的线性扩展性却被市场证明还不够，因此，更多用户主要用RAC来构建高可用集群，而不是高扩展的集群。后者比如Proxy+开源DB的数据库集群方案，通常能提供很好的线性扩展性，但是因为不支持分布式事务，对数据库用户存在较大的限制。又或者可以支持分布式事务，但是当跨节点写入比例很大时，反过来降低了线性扩展能力。CynosDB通过采用一写多读的方式，利用只读节点的线性扩展来提升整个系统的最大吞吐量，对于绝大部份公有云用户来说，这就已经足够了。下图为CynosDB for PostgreSQL的产品架构图，CynosDB是一个基于共享存储、支持一写多读的数据库集群。CynosDB for PostgreSQL产品架构图图一CynosDB for PostgreSQL产品架构图CynosDB基于CynosStore之上，CynosStore是一个分布式存储，为CynosDB提供坚实的底座。CynosStore由多个Store Node和CynosStore Client组成。CynosStore Client以二进制包的形式与DB（PostgreSQL）一起编译，为DB提供访问接口，以及负责主从DB之间的日志流传输。除此之外，每个Store Node会自动将数据和日志持续地备份到腾讯云对象存储服务COS上，用来实现PITR（即时恢复）功能。一、CynosStore数据组织形式CynosStore会为每一个数据库分配一段存储空间，我们称之为Pool，一个数据库对应一个Pool。数据库存储空间的扩缩容是通过Pool的扩缩容来实现的。一个Pool会分成多个Segment Group（SG），每个SG固定大小为10G。我们也把每个SG叫做一个逻辑分片。一个Segment Group（SG）由多个物理的Segment组成，一个Segment对应一个物理副本，多个副本通过RAFT协议来实现一致性。Segment是CynosStore中最小的数据迁移和备份单位。每个SG保存属于它的数据以及对这部分数据最近一段时间的写日志。CynosStore 数据组织形式图二 CynosStore 数据组织形式图二中CynosStore一共有3个Store Node，CynosStore中创建了一个Pool，这个Pool由3个SG组成，每个SG有3个副本。CynosStore还有空闲的副本，可以用来给当前Pool扩容，也可以创建另一个Pool，将这空闲的3个Segment组成一个SG并分配个这个新的Pool。二、基于日志异步写的分布式存储传统的数据通常采用WAL（日志先写）来实现事务和故障恢复。这样做最直观的好处是1）数据库down机后可以根据持久化的WAL来恢复数据页。2）先写日志，而不是直接写数据，可以在数据库写操作的关键路径上将随机IO（写数据页）变成顺序IO（写日志），便于提升数据库性能。基于日志的存储图三 基于日志的存储图三（左）极度抽象地描述了传统数据库写数据的过程：每次修改数据的时候，必须保证日志先持久化之后才可以对数据页进行持久化。触发日志持久化的时机通常有1）事务提交时，这个事务产生的最大日志点之前的所有日志必须持久化之后才能返回给客户端事务提交成功；2）当日志缓存空间不够用时，必须持久化之后才能释放日志缓存空间；3）当数据页缓存空间不够用时，必须淘汰部分数据页来释放缓存空间。比如根据淘汰算法必须要淘汰脏页A，那么最后修改A的日志点之前的所有日志必须先持久化，然后才可以持久化A到存储，最后才能真正从数据缓存空间中将A淘汰。从理论上来说，数据库只需要持久化日志就可以了。因为只要拥有从数据库初始化时刻到当前的所有日志，数据库就能恢复出当前任何一个数据页的内容。也就是说，数据库只需要写日志，而不需要写数据页，就能保证数据的完整性和正确性。但是，实际上数据库实现者不会这么做，因为1）从头到尾遍历日志恢复出每个数据页将是非常耗时的；2）全量日志比数据本身规模要大得多，需要更多的磁盘空间去存储。那么，如果持久化日志的存储设备不仅仅具有存储能力，还拥有计算能力，能够自行将日志重放到最新的页的话，将会怎么样？是的，如果这样的话，数据库引擎就没有必要将数据页传递给存储了，因为存储可以自行计算出新页并持久化。这就是CynosDB“采用基于日志的存储”的核心思想。图三（右）极度抽象地描述了这种思想。图中计算节点和存储节点置于不同的物理机，存储节点除了持久化日志以外，还具备通过apply日志生成最新数据页面的能力。如此一来，计算节点只需要写日志到存储节点即可，而不需要再将数据页传递给存储节点。下图描述了采用基于日志存储的CynosStore的结构。基于日志的存储图四 CynosStore：基于日志的存储此图描述了数据库引擎如何访问CynosStore。数据库引擎通过CynosStore Client来访问CynosStore。最核心的两个操作包括1）写日志；2）读数据页。数据库引擎将数据库日志传递给CynosStore，CynosStore Client负责将数据库日志转换成CynosStore Journal，并且负责将这些并发写入的Journal进行序列化，最后根据Journal修改的数据页路由到不同的SG上去，并发送给SG所属Store Node。另外，CynosStore Client采用异步的方式监听各个Store Node的日志持久化确认消息，并将归并之后的最新的持久化日志点告诉数据库引擎。当数据库引擎访问的数据页在缓存中不命中时，需要向CynosStore读取需要的页（read block）。read block是同步操作。并且，CynosStore支持一定时间范围的多版本页读取。因为各个Store Node在重放日志时的步调不能完全做到一致，总会有先有后，因此需要读请求发起者提供一致性点来保证数据库引擎所要求的一致性，或者默认情况下由CynosStore用最新的一致性点（读点）去读数据页。另外，在一写多读的场景下，只读数据库实例也需要用到CynosStore提供的多版本特性。CynosStore提供两个层面的访问接口：一个是块设备层面的接口，另一个是基于块设备的文件系统层面的接口。分别叫做CynosBS和CynosFS，他们都采用这种异步写日志、同步读数据的接口形式。那么，CynosDB for PostgreSQL，采用基于日志的存储，相比一主多从PostgreSQL集群来说，到底能带来哪些好处？1）减少网络流量。首先，只要存算分离就避免不了计算节点向存储节点发送数据。如果我们还是使用传统数据库+网络硬盘的方式来做存算分离（计算和存储介质的分离），那么网络中除了需要传递日志以外，还需要传递数据，传递数据的大小由并发写入量、数据库缓存大小、以及checkpoint频率来决定。以CynosStore作为底座的CynosDB只需要将日志传递给CynosStore就可以了，降低网络流量。2）更加有利于基于共享存储的集群的实现：一个数据库的多个实例（一写多读）访问同一个Pool。基于日志写的CynosStore能够保证只要DB主节点（读写节点）写入日志到CynosStore，就能让从节点（只读节点）能够读到被这部分日志修改过的数据页最新版本，而不需要等待主节点通过checkpoint等操作将数据页持久化到存储才能让读节点见到最新数据页。这样能够大大降低主从数据库实例之间的延时。不然，从节点需要等待主节点将数据页持久化之后（checkpoint）才能推进读点。如果这样，对于主节点来说，checkpoint的间隔太久的话，就会导致主从延时加大，如果checkpoint间隔太小，又会导致主节点写数据的网络流量增大。当然，apply日志之后的新数据页的持久化，这部分工作总是要做的，不会凭空消失，只是从数据库引擎下移到了CynosStore。但是正如前文所述，除了降低不必要的网络流量以外，CynosStore的各个SG是并行来做redo和持久化的。并且一个Pool的SG数量可以按需扩展，SG的宿主Store Node可以动态调度，因此可以用非常灵活和高效的方式来完成这部分工作。三、CynosStore Journal（CSJ）CynosStore Journal（CSJ）完成类似数据库日志的功能，比如PostgreSQL的WAL。CSJ与PostgreSQL WAL不同的地方在于：CSJ拥有自己的日志格式，与数据库语义解耦合。PostgreSQL WAL只有PostgreSQL引擎可以生成和解析，也就是说，当其他存储引擎拿到PostgreSQL WAL片段和这部分片段所修改的基础页内容，也没有办法恢复出最新的页内容。CSJ致力于定义一种与各种存储引擎逻辑无关的日志格式，便于建立一个通用的基于日志的分布式存储系统。CSJ定了5种Journal类型：1.SetByte：用Journal中的内容覆盖指定数据页中、指定偏移位置、指定长度的连续存储空间。2. SetBit：与SetByte类似，不同的是SetBit的最小粒度是Bit，例如PostgreSQL中hitbit信息，可以转换成SetBit日志。3. ClearPage：当新分配Page时，需要将其初始化，此时新分配页的原始内容并不重要，因此不需要将其从物理设备中读出来，而仅仅需要用一个全零页写入即可，ClearPage就是描述这种修改的日志类型。4. DataMove：有一些写入操作将页面中一部分的内容移动到另一个地方，DataMove类型的日志用来描述这种操作。比如PostgreSQL在Vacuum过程中对Page进行compact操作，此时用DataMove比用SetByte日志量更小。5. UserDefined：数据库引擎总会有一些操作并不会修改某个具体的页面内容，但是需要存放在日志中。比如PostgreSQL的最新的事务id（xid）就是存储在WAL中，便于数据库故障恢复时知道从那个xid开始分配。这种类型日志跟数据库引擎语义相关，不需要CynosStore去理解，但是又需要日志将其持久化。UserDefined就是来描述这种日志的。CynosStore针对这种日志只负责持久化和提供查询接口，apply CSJ时会忽略它。以上5种类型的Journal是存储最底层的日志，只要对数据的写是基于块/页的，都可以转换成这5种日志来描述。当然，也有一些引擎不太适合转换成这种最底层的日志格式，比如基于LSM的存储引擎。CSJ的另一个特点是乱序持久化，因为一个Pool的CSJ会路由到多个SG上，并且采用异步写入的方式。而每个SG返回的journal ack并不同步，并且相互穿插，因此CynosStore Client还需要将这些ack进行归并并推进连续CSJ点（VDL）。 CynosStore日志路由和乱序ACK图五 CynosStore日志路由和乱序ACK只要是连续日志根据数据分片路由，就会有日志乱序ack的问题，从而必须对日志ack进行归并。Aurora有这个机制，CynosDB同样有。为了便于理解，我们对Journal中的各个关键点的命名采用跟Aurora同样的方式。这里需要重点描述的是MTR，MTR是CynosStore提供的原子写单位，CSJ就是由一个MTR紧挨着一个MTR组成的，任意一个日志必须属于一个MTR，一个MTR中的多条日志很有可能属于不同的SG。针对PostgreSQL引擎，可以近似理解为：一个XLogRecord对应一个MTR，一个数据库事务的日志由一个或者多个MTR组成，多个数据库并发事务的MTR可以相互穿插。但是CynosStore并不理解和感知数据库引擎的事务逻辑，而只理解MTR。发送给CynosStore的读请求所提供的读点必须不能在一个MTR的内部某个日志点。简而言之，MTR就是CynosStore的事务。四、故障恢复当主实例发生故障后，有可能这个主实例上Pool中各个SG持久化的日志点在全局范围内并不连续，或者说有空洞。而这些空洞所对应的日志内容已经无从得知。比如有3条连续的日志j1, j2, j3分别路由到三个SG上，分别为sg1, sg2, sg3。在发生故障的那一刻，j1和j3已经成功发送到sg1和sg3。但是j2还在CynosStore Client所在机器的网络缓冲区中，并且随着主实例故障而丢失。那么当新的主实例启动后，这个Pool上就会有不连续的日志j1, j3，而j2已经丢失。当这种故障场景发生后，新启动的主实例将会根据上次持久化的连续日志VDL，在每个SG上查询自从这个VDL之后的所有日志，并将这些日志进行归并，计算出新的连续持久化的日志号VDL。这就是新的一致性点。新实例通过CynosStore提供的Truncate接口将每个SG上大于VDL的日志truncate掉，那么新实例产生的第一条journal将从这个新的VDL的下一条开始。故障恢复时日志恢复过程图六：故障恢复时日志恢复过程如果图五刚好是某个数据库实例故障发生的时间点，当重新启动一个数据库读写实例之后，图六就是计算新的一致性点的过程。CynosStore Client会计算得出新的一致性点就是8，并且把大于8的日志都Truncate掉。也就是把SG2上的9和10truncate掉。下一个产生的日志将会从9开始。五、多副本一致性CynosStore采用Multi-RAFT来实现SG的多副本一致性， CynosStore采用批量和异步流水线的方式来提升RAFT的吞吐量。我们采用CynosStore自定义的benchmark测得单个SG上日志持久化的吞吐量为375万条/每秒。CynosStore benchmark采用异步写入日志的方式测试CynosStore的吞吐量，日志类型包含SetByte和SetBit两种，写日志线程持续不断地写入日志，监听线程负责处理ack回包并推进VDL，然后benchmark测量单位时间内VDL的推进速度。375万条/秒意味着每秒钟一个SG持久化375万条SetByte和SetBit日志。在一个SG的场景下，CynosStore Client到Store Node的平均网络流量171MB/每秒，这也是一个Leader到一个Follower的网络流量。六、一写多读CynosDB基于共享存储CynosStore，提供对同一个Pool上的一写多读数据库实例的支持，以提升数据库的吞吐量。基于共享存储的一写多读需要解决两个问题：1. 主节点（读写节点）如何将对页的修改通知给从节点（只读节点）。因为从节点也是有Buffer的，当从节点缓存的页面在主节点中被修改时，从节点需要一种机制来得知这个被修改的消息，从而在从节点Buffer中更新这个修改或者从CynosStore中重读这个页的新版本。2. 从节点上的读请求如何读到数据库的一致性的快照。开源PostgreSQL的主备模式中，备机通过利用主机同步过来的快照信息和事务信息构造一个快照（活动事务列表）。CynosDB的从节点除了需要数据库快照（活动事务列表）以外，还需要一个CynosStore的快照（一致性读点）。因为分片的日志时并行apply的。如果一个一写多读的共享存储数据库集群的存储本身不具备日志重做的能力，主从内存页的同步有两种备选方案：第一种备选方案，主从之间只同步日志。从实例将至少需要保留主实例自从上次checkpoint以来所有产生的日志，一旦从实例产生cache miss，只能从存储上读取上次checkpoint的base页，并在此基础上重放日志缓存中自上次checkpoint以来的所有关于这个页的修改。这种方法的关键问题在于如果主实例checkpoint之间的时间间隔太长，或者日志量太大，会导致从实例在命中率不高的情况下在apply日志上耗费非常多的时间。甚至，极端场景下，导致从实例对同一个页会反复多次apply同一段日志，除了大幅增大查询时延，还产生了很多没必要的CPU开销，同时也会导致主从之间的延时有可能大幅增加。第二种备选方案，主实例向从实例提供读取内存缓冲区数据页的服务，主实例定期将被修改的页号和日志同步给从实例。当读页时，从实例首先根据主实例同步的被修改的页号信息来判断是1）直接使用从实例自己的内存页，还是2）根据内存页和日志重放新的内存页，还是3）从主实例拉取最新的内存页，还是4）从存储读取页。这种方法有点类似Oracle RAC的简化版。这种方案要解决两个关键问题：1）不同的从实例从主实例获取的页可能是不同版本，主实例内存页服务有可能需要提供多版本的能力。2）读内存页服务可能对主实例产生较大负担，因为除了多个从实例的影响以外，还有一点就是每次主实例中的某个页哪怕修改很小的一部分内容，从实例如果读到此页则必须拉取整页内容。大致来说，主实例修改越频繁，从实例拉取也会更频繁。相比较来说，CynosStore也需要同步脏页，但是CynosStore的从实例获取新页的方式要灵活的多有两种选择1）从日志重放内存页；2）从StoreNode读取。从实例对同步脏页需要的最小信息仅仅是到底哪些页被主实例给修改过，主从同步日志内容是为了让从实例加速，以及降低Store Node的负担。CynosDB一写多读图七 CynosDB一写多读图七描述了一写一读（一主一从）的基本框架，一写多读（一主多从）就是一写一读的叠加。CynosStore Client（CSClient）运行态区分主从，主CSClient源源不断地将CynosStore Journal（CSJ）从主实例发送到从实例，与开源PostgreSQL主备模式不同的是，只要这些连续的日志到达从实例，不用等到这些日志全部apply，DB engine就可以读到这些日志所修改的最新版本。从而降低主从之间的时延。这里体现“基于日志的存储”的优势：只要主实例将日志持久化到Store Node，从实例即可读到这些日志所修改的最新版本数据页。七、结语CynosStore是一个完全从零打造、适应云数据库的分布式存储。CynosStore在架构上具备一些天然优势：1）存储计算分离，并且把存储计算的网络流量降到最低； 2）提升资源利用率，降低云成本，3）更加有利于数据库实例实现一写多读，4）相比一主两从的传统RDS集群具备更高的性能。除此之外，后续我们会在性能、高可用、资源隔离等方面对CynosStore进行进一步的增强。此文已由作者授权腾讯云+社区发布 ...

阿里云CDN实时日志服务可以将CDN采集的日志，秒级的交付给用户, 并且可以对采集到的日志进行实时、交互式分析和报表呈现，为监控、报警、渠道分析、运营分析提供实时、可靠的数据参考，让用户远离锁事，专注数据价值。12月26日，阿里云CDN实时日志服务举办线上直播发布会，全网首次深度解读阿里云CDN大数据系统技术演进、产品特性、应用场景与业务实操。CDN实时日志源起何处？阿里云CDN从2014年正式商业化至今，服务了百万域名，每天处理数PB的数据，并应对亿级并发的洪峰流量，实现最低秒级延迟，并且提供100%的高数据准确性服务。伴随系统规模发展，CDN产生的日志数据量也越来越庞大，同时CDN业务场景下的原始数据分布广泛、处理环节复杂、使用场景繁多等等现状也给阿里云大数据系统带来了不小的挑战。另一方面，阿里云CDN服务了全球三十多万客户，在与客户沟通中，通常会面临这样的问题：1. 用户无数据源绝大部分的CDN产商都只提供离线日志下载，日志数据从产生，到用户可下载，需要几十分钟到数个小时不等。这样大的数据产生延时，大大削减了高实时性要求场景的数据分析价值，无法驱动运营调整策略2. 无法进行实时监控报警无法实时把握CDN服务性能，对线上问题排查的不及时，遇到问题的灾备方案对客户端有感，进而无法实现更自动化、智能化的运维，不能提前发现业务瓶颈，进一步提升CDN的服务质量3. 数据分析及可视化的开发、运维成本高昂为了解决各类定制化的数据分析需求，用户通常需要自建数据仓库, 自建流式和离线分析平台, 数据可视化平台。投入大量建设资金的同时, 还需要投入大量的研发和运维人力4. 自建系统技术挑战大整个数据平台的数据来源广泛，数据处理方式复杂，随着业务的快速发展, 对系统稳定性、数据实时性、数据准确性、全球化服务能力也不断提出严苛的要求。使用开源软件对企业的技术挑战很大, 在性能、成本、定制化、稳定性也未必能跟上业务要求。综上所述，更通用、实时、准确的日志获取, 分析和可视化的需求逐渐凸显，阿里云CDN大数据系统在这个背景之下走上了技术演进之路。阿里云CDN大数据系统架构演进起初，阿里云CDN大数据业务架构完全基于开源软件搭建，但是随着业务系统越来越大，我们发现在开源方案中解决问题的成本也越来越高，考虑到成本和后续服务的及时性、稳定性、定制化等因素，逐渐将开源方案以集团内部自研方案来替换。比如，Scroll这个协议就是自研的一套日志数据编解码方案；Crimea是在节点上进行数据基础的采集、降维分析以及数据持久化的自研应用；Blink是阿里集团的流式计算平台; MaxCompute是阿里云对外售卖的通用离线分析平台。阿里云高级技术专家姜晓东表示：“整个CDN的业务逐渐复杂，对业务的稳定性要求也更高，数据是稳定性的基础条件，网络条件再好，硬件条件再好，缺少数据决策的能力，也不可能做到非常高服务能力。我们可以预测到阿里云CDN系统会有PB/EB级别的规模数据增长，同时我们对于数据的完整性、可用性、全球化部署等指标都有比较高的追求，所以我们逐渐演进、集成沉淀了现有的大数据解决方案。”如今的架构在CDN节点上实现了数据采集和第一步数据降维分析，延迟低，稳定性高；所有数据传输通过阿里云SLS和OSS来完成，通过SLS遍布全球的接入点实现秒级可见，对于批量或者文件处理，通过节点把数据写入OSS，再进行读取和分析；在数据分析这层，采用了阿里集团的MaxCompute和Blink的方案，实现离线大规模数据分析和在线流式分析。同时，SLS也使用了CDN的动态加速能力，提高在海外和弱网情况下的数据投递成功率。该技术架构具有以下两个技术优势：一、在数据采集阶段，自研了Scroll+Crimea应用，具备优秀的计算和容灾能力，运用内容自解释、高效编码、边缘预处理与降维分析、自动容灾处理、任务隔离等方案，确保了数据完整性、实时性和准确性。二、基于SLS实现全球多部署点写入，无缝对接存储和分析平台，达到秒级延迟，支持单次10亿级别的分析，并且无需付出代码和运维成本，能够实现快速、稳定、低成本、高容量的传输和分析。用数据价值赋能用户 CDN实时日志服务诞生CDN实时日志服务基于阿里云CDN大数据系统解决方案，将日志的实时采集、多维分析、可视化运营、监控与报警打通，形成一站式解决方案，整个系统中复杂的事情都交给阿里云来做，让用户尽可能地可以远离“琐事”，更专注挖掘数据价值，专注在业务本身。它具有以下五大优势：一、延时不超过60秒CDN实时日志可以从全球多个区域、数万节点实时采集日志，通常延时不超过60秒，否则日志的实时价值大打折扣。同时，在开通服务后，CDN将日志数据自动投递到日志服务(SLS)，免去繁琐的传统日志分析的流程，实时查看日志分析结果。二、平均节省60%成本使用实时日志还可以大幅降低资源、人力运维、分析等成本，以某家大型公司为例，每天系统产生日志约100亿条，自建Hadoop+Es集群，集群规模1500+服务器，运维+研发10人左右，一年总成本大约需要5000多万。而使用实时日志，平均减少投入60%以上，运维只需要将精力集中在访问监控上，而运营将精力聚焦在业务分析上，更专注业务本身。三、多维度SQL分析，秒级10亿+规模CDN实时日志系统支持每天千亿、万亿的日志7*24小时不间断采集，并实时对海量日志进行多维度分析，流计算系统在毫秒级。让用户更加专注于和业务更紧密、更有价值的数据“分析”上。四、数据可视化及大数据挖掘最终分析结果的展示也非常关键，CDN实时日志可以为用户提供基于业务的可视化报表服务，用户可轻松地掌控业务健康度、缓存命中率、平均下载速度、流量情况、网速、运营商、延时分布等数据。五、日志、监控、告警联动的一站式解决方案在CDN场景下，对服务的可用性、性能要求苛刻，需要对于各类异常进行实时、准确的报警，这就需要依赖可靠的监控报警系统。CDN日志系统未来将和监控、告警、处理机制联动，自动化的解决常规问题，缩短业务故障的时间，避免用户损失。CDN实时日志典型应用场景适用场景一：直播在直播场景下，用户访问集中，数据时效性非常强，对系统的稳定性要求又极其高，通过CDN实时日志可以获取秒级推流状态，并通过日志分析自定义报表，快速进行访问监控和错误追踪。• 推流概览 : 实时知道当前的推流数量、各个推流的流量和速度、从各省、运营商维度统计 • 推流质量：多维度的推流质量统计、重点推流的实时质量监控 • 错误根源追踪：快速定位错误产生的源头（直播源、服务端、客户端、运营商等）比如，虎牙直播就采用了CDN的实时日志服务，将访问节点的日志实时获取后对日志进行分析，对可能的用户运行风险进行及时预警，实现故障自愈和问题定位，同时实时评价CDN节点健康度，主动发现影响客户体验因素，屏蔽质量较差的节点和线路。适用场景二：大型活动或突发事件监控在类似双12双11的大型营销活动中，网站的访问突然激增，通过CDN实时日志可以快速搭建当前节点一系列数据报表，判断节点和运营商的访问质量，保证终端用户访问顺畅。在此基础上，运营可以通过用户分布、终端分布和版本分布，优化资源投放以及实时调整策略，真正实现数据驱动决策。• 整体质量： 健康度 : 在所有的访问中，有多少请求是成功的 Cache命中率 : 命中率越高，用户访问延时越低，体验越好 下载速度 : 这也是关系到播放质量的重要因素 • 多维度分析： top域名访问次数、流量 : 重点域名的访问质量 地域、运营商统计：各个链路的质量 下载量、速度、延时：多项关键指标 • 错误诊断： 实时错误QPS、比例 : 整体错误情况 错误Top 域名、URI : 错误是否和自身相关 错误Top 地域、运营商 : 错误是否和外部因素相关 错误客户端分别 : 是否是新发布版本引入的问题除了以上两个典型场景，CDN实时日志还可以应用在游戏直播监控或报警、在线教育直播监控或报警、网站大型推广或内容投放效果分析，网站促销活动监控或效果分析，内容运营效果分析等场景之下。适用不仅限于游戏、电商、教育、体育赛事、机酒订购等行业。CDN实时日志接入与实操指南点击链接跳转服务详细文档与开通指南开通仅需三步：一、打开CDN控制台，点击日志-实时日志推送，点击开通日志服务，按照指引步骤操作。二、单击创建实时日志推送服务，配置Project、Logstore、地区等信息，然后单击下一步。三、选择关联域名并绑定，然后单击创建。开通完毕，如何查看报表，进行日志分析？CDN默认帮用户创建了4张报表，分别是CDN基础数据、错误分析、热门资源和用户分析，用户可以通过这四张报表可以快速的去查看CDN的质量和分布数据。同时，用户也可以通过日志分析进行定制化的查询，查询完成后，可以将查询内容保存到现有的报表，或者是新建一份报表。另外，也可以将报表的任意统计项或者当前查询项保存为报警项，及时的发现和定位问题。实操演示：发布会直播的最后，CDN高级产品经理容蓓带着用户实操演练了整个开通和操作的流程，点击回顾视频版，上手更轻松：https://yq.aliyun.com/live/699此前，阿里云CDN实时日志系统经过了长期演进，已经成功运用在世界杯、双11等阿里集团大型活动之中，为活动提供实时、可靠、全面详实的数据监控系统。在当今大数据时代，阿里云会将同款能力开放赋能给行业用户，挖掘数据的无限价值，让业务决策快人一步。本文作者：樰篱阅读原文本文为云栖社区原创内容，未经允许不得转载。

12月25日圣诞夜，Conflux CTO伍鸣博士做客「火星财经创始学习群」，分享了“Conflux: 使用 DAG 结构提升中本聪共识的吞吐率”。嘉宾简介：Conflux CTO：伍鸣博士本科毕业于中国科技大学，中科院计算机系统结构博士，曾为微软亚洲研究院（MSRA）系统研究组的高级研究员，研究方向包括分布式事务处理系统、图计算引擎和人工智能平台。近年来在多个系统领域的顶级会议（如 SOSP、OSDI、NSDI、ATC等）中发表论文，并担任过 OSDI、ASPLOS、HotDep等会议的程序委员会委员。要点速览：1.基于中本聪共识的思想，使用 DAG 技术改造，可以在不牺牲去中心化和安全性的前提下，大幅提高吞吐效率。2.为什么传统的基于PoW的中本聪共识机制的吞吐率非常低下？总结来说，为了安全，不得不如此。3.保证安全性是公链系统最核心的要求，PoS虽减少了PoW中挖矿所需要消耗的资源，但同时引入了很多新的攻击情形和安全性威胁，目前没有很完美的解决方案。伍鸣博士坦言，目前存在的一些基于PoW的区块链系统所能提供的交易吞吐率都非常低，由此带来很多问题，包含用户体验糟糕、交易费用高昂，并进一步限制了在区块链系统上开发更有意义的应用的能力。在此背景下，Conflux通过有向无环图技术（DAG）与中本聪共识（比特币的共识机制）的结合，在不牺牲去中心化和安全性的前提下，提高基于工作量证明（PoW）的区块链系统的吞吐率。以下为伍鸣博士直播的详细内容（由Conflux和火星财经整理）第一部分：行业背景众所周知，当前区块链领域面临的最大的一个问题之一，就是效率的问题。业界已经存在的一些基于PoW的区块链系统（例如比特币、以太坊）所能提供的交易吞吐率都非常的低。比特币的极限速度是平均每秒处理大概7个交易，以太坊是每秒30个交易，远远低于像Visa这样的中心化的交易服务可以支持每秒上千个交易的吞吐率。效率低会带来很多问题：首先，效率低使得现有的区块链的用户体验很糟糕，比如交易被加入区块需要等很长时间。其次，吞吐率有限使得交易费用高昂。更进一步，交易费用高昂限制了在区块链系统上开发更有意义的应用的能力。为了提高效率，大体有以下这么几个思路：1.依然采用中本聪共识，但调整协议参数。通过调整出块时间和区块大小来提高效率。如莱特币(2.5 min/1MB block), BCH (10min/32MB block)。但有研究表明，无论这两个参数如何调整，提高吞吐率必然以降低安全性为代价，在第二部分，我将为大家分析这其中的原因。2.基于中本聪共识的思想，使用 DAG 技术改造。这可以在不牺牲去中心化和安全性的前提下，大幅提高吞吐效率。3.使用 PoS 或 dPoS 机制。dPoS算法如 EOS 很大程度上牺牲了去中心化，有不小的争议。而 PoS 算法也存在股权集中、难以应对长程攻击(Long Range Attack)等去中心化或安全性问题。4.使用分片 (Sharding), 状态通道 (State Channel) 等侧链或链下解决方案。其中一部分被有些人称为 Layer 2。 这些方案与 Conflux 目前的解决方案是正交的，它们在尝试从另一个角度解决吞吐率问题，对吞吐率的提高是可以效果叠加或优势互补的。例如，提升全节点的吞吐率的技术可以帮助使用分片技术的系统减少跨链交易所造成的性能瓶颈，也可以完成更多的状态通道结算交易。第二部分：中本聪共识机制为何吞吐率低下为什么传统的基于PoW的中本聪共识机制的吞吐率非常的低下？总结来说，为了安全，不得不如此。在公有链中，为了能让参与网络协议的机器节点对交易的执行达成共识，矿工挖出区块以后需要在P2P网络中进行广播，以便让所有的机器获得一致的账本结构。每个矿工会根据最长链规则，选择将新挖出的区块接在它所看到的最长链的末尾。也就是所有诚实的节点，会共同延长这个最长的主链。这样，如果恶意的节点没有>50%的算力就不可能逆转主链。然而，如果网络延迟比较大，使得一个新块在产生以后还来不及传播到全网就会有其他的节点产生另外的新块，就会在区块链上产生了大量分叉。下面让我们用一个图片，来展示了发生分叉后区块链账本的样子。这些分叉带来两个问题。第一，分叉的区块最终被丢弃，这浪费了网络和计算资源。第二，分叉同时也危害了安全性，如果大量诚实节点生成的区块因为分叉被丢弃，攻击者只需要少于50%的算力就可以产生出恶意的最长链了。因此，在比特币或以太坊中，为了保证安全性，它们需要保持一个很长的出块时间（即很低的出块速率），或者维持很小区块大小以减小区块在网络中广播的延迟，以此来减少分叉出现的频率，但同时也因此大大降低了系统的吞吐率。提高吞吐率会引发分叉，而不同分叉上的两个区块是竞争关系。它们争夺后续挖出的确认区块，来让自己所在的分支成为最长链，失败者则被丢弃。诚实节点挖出来的区块之间这种无意义的竞争，为攻击者带来了可乘之机。为了提高安全性，比特币选择了降低出块速度，尽量避免这种情况出现。那么，如果我们选择了另一个思路，即通过允许每个区块选择多个区块作为自己的父亲或祖先，哪怕在出块速度很快的时候，也可以避免诚实区块之间无意义的竞争。这样，就绕开了中本聪共识中安全与效率两难的困境。在这种思路下，整个网络将构成有向无环图结构(DAG)。下一步要考虑的是，不同的区块中的交易，应该以什么顺序执行？这时，我们通过设计一个安全的有向无环图拓扑排序算法，每个节点只需要在自己本地的 DAG 上执行一遍这个算法，就可以获得一个区块的执行顺序，这个算法应该保证：·每个挖矿的机器节点排出来的序应当是一致的。·即使在遭遇双花攻击时，这个顺序也不可被更改。稍后，我将以 Conflux 为例，来看一下怎么样设计这个安全的拓扑排序算法。DAG 技术有很多了，比如说 Spectre和 Phantom 算法，这是设计思路与我们最接近的算法，都是采用 DAG 角度优化 PoW 链的效率。但遗憾的是，Spectre 无法对所有区块排一个序出来，这导致它上面无法跑智能合约。而Phantom 被我们发现有漏洞。同时，还有一些基于 DAG 的算法，与今天讲的内容相比，形似但非神似，比如说雪崩共识，Hashgraph. 这些算法本质上都是联盟链的算法。与通过“股权质押”的方式，将联盟链算法转换成PoS 公链算法。但联盟链转换成PoS公链算法的过程存在安全性问题。比较为人熟知的一些针对PoS的攻击有，无利害攻击（Nothing-at-Stake Attack）和长程攻击（Long-Range Attack）。第三部分：使用PoW+DAG提高区块链吞吐量实例分析-Conflux 的机制设计接下来我们以Conflux为例，具体从技术细节的角度看一下，利用DAG提高吞吐量的思路是怎么实现的。在Conflux中，每个区块包含两种边，父边和引用边。父边和引用边共同构成一个有向无环图。去掉引用边，所有父边又构成了一棵树。在挖矿环节，矿工要监听 P2P 网络中广播的区块，并在本地维护一个有向无环图结构的区块账本。矿工在挖矿时，新区块父边和引用边的选择，需要遵循以下的规则：1.在父边构成的树中，依据 Ghost 规则选择一条主链。具体来说，从创世块开始，迭代地去从孩子区块中选择下一个在主链上的区块。选择的规则是挑选拥有最大子树的孩子区块。新区块的父边，应当指向主链中最后一个区块。2.此外，对于那些既没有父边，也没有引用边指向的区块，我们称为“叶子区块”，新区块的引用边要指向所有剩下的叶子区块。有了这些边的定义，这个账本结构就定下来了，区块被广播后，所有的节点最终都会得到一个结构一致的有向无环图，即一个一致的账本。那么有了一致的账本以后，所有的节点如何去决定一个安全的、一致的区块排序呢？我们的核心想法是，首先，这些节点先在DAG中决定一个一致的主链，然后，再根据这个主链来决定一个一致的区块的排序。下面，让我们用一个例子来看下如何决定一个一致的区块排序。主链的选取同样遵循 Ghost 规则，刚刚在选父边的时候我提到过这个规则。我们根据这一规则，我们将区块C,E,H,都选进了主链。根据我们刚刚讲的选边规则。新区块的父边应当指向 H, 同时 K 是叶子区块。所以新区块的引用边应当指向 K.（注意：H 的引用边指向了 G, 所以 G 不是叶子区块）。现在我们有了让所有节点对主链产生共识的机制。那接下来，这些节点如何对区块的全序达成共识呢？为了做到这一点，我们引入一个Epoch的概念。在主链上的每一个区块就确定了一个Epoch。在分叉上的区块属于哪个Epoch，是由第一个产生在它之后的主链区块所在的Epoch决定的。比如，区块D属于Epoch E，因为D最先被E引用，所以产生在E之前，但是D并不产生在C之前。按照这个规则，我们可以得到一个一致的排序，如下图所示。所以，在Conflux中，我们首先按照Epoch的顺序来给区块排个序。然后在每一个Epoch内部，我们再按照拓扑排序来确定区块的顺序。如果出现平局的情况，我们再根据区块的哈希值来打破平局。所以这个图中的区块排好序以后就是这样的。接下来我们要为交易排序，Conflux首先按照区块的顺序去给交易排序。然后在每个区块内部，我们就按照交易在区块里所在的位置来排就可以了。最后，我们来看一下，交易如果发生重复或冲突怎么解决。我们再用一个例子来解释一下：这个例子里面的交易2和交易3发生了冲突。因为交易2执行过以后，账户X里面就没有足够的余额来完成交易3了，因为在这个交易的全序里面，交易3是发生在交易2之后的，所以我们会让交易3变为无效。另一种情况是，相同的交易有可能被不同的节点打包到不同的并发区块里，比如交易4。在这种情况下，Conflux只会接受在全序中出现的第一个这样的交易，而把后面的重复交易无效掉。问答环节：Q1:Conflux 如何与PoS 公链项目对比？A1:我们都知道，保证安全性是公链系统最核心的要求，因为公链本身就是在构建一个可信的系统。PoS虽然减少了PoW中挖矿所需要消耗的资源，但同时它也引入了很多新的攻击情形和安全性威胁，而且目前没有很完美的解决方案。比较为人熟知的一些针对PoS的攻击有，无利害攻击（Nothing-at-Stake Attack）和长程攻击（Long-Range Attack）。出于这个原因，Conflux坚持采用基于POW的共识机制，通过引入DAG的技术来打破共识机制的性能瓶颈。这是我们原型测试系统实际跑出来的结果。Q2: Conflux 一笔交易能多久确认？A2: 在没有坏人攻击的情况下，5s 一个 4MB 大小的区块，确认时间约 8 分钟。在有 30% 算力攻击的情况下，确认时间约 16 分钟。Q3:Conflux的TPS能跑到多少 ?A3:在谈论和对比 TPS 的时候，我们需要注意区分测试 TPS 的实验设定。例如在比特币中，每一个区块都需要广播给所有矿工，每一笔交易都被所有人验证过，我们称之为一个交易得到的“全节点验证”。在一些 Sharding方案的实验中，所有的交易被分成 30 份, 每个节点可能只验证其中一份。这样的交易称为“部分节点验证”。很显然，“部分节点验证”交易的总 TPS 是可以成倍于 “全节点验证” 的。Conflux 在共识层面可以做到 4000-6000 TPS 的“全节点验证”, 如果考虑合约执行、状态读写等因素，实际部署可能会低一些。Sharding 技术是共识层技术一个很好的补充，Conflux 有计划在未来实现 Sharding, 提供更高的 “部分节点验证” TPS, 为用户提供多种选择。Q4: Conflux的roadmap和相关时间计划是怎样的？A4: 我们计划在春节后测试网上线，预计明年Q3主网上线。Q5:Conflux会有代币发行吗？还是挖矿？A5：Conflux没有ERC20，主网上线之后会有挖矿。Q6: 那这里会不会涉及到PoW，或者挖矿的算力? 另外这里的主要难点是什么?面临的主要技术问题是什么?A6: Conflux 是基于中本聪共识做的改进，是一个PoW 共识机制，当然会有挖矿。这里主要的难点是为DAG的账本设计高效的一致的排序算法。这个算法要能保证好人之间达成一致，还能够抵抗各种复杂的攻击情形。Q7: Conflux是如何预防双花攻击的？A7: 这个问题回答起来比较复杂，先来看一个图在这个图中，我们首先来看一下一个攻击者如何能够逆转在账本中的一个交易，比如交易4。为了做到这一点，一个攻击者需要产生一个交易4的双花交易，打包到一个区块里面，并且将这个区块在区块的全序中插入到区块B的前面。但攻击者很难做到这一点，主要有两个原因。第一个就是除非攻击者能够改变主链，不然他不能够逆转交易，因为交易的顺序是由主链来决定的。比如一个攻击者想把一个块插在靠前的位置，他能做就是在一个很早的Epoch里面的区块后面接着产生新块。但是只要这个块不在主链上，它就最终还是会属于一个很晚的Epoch。因为当一个诚实的新块产生以后，它会通过引用边把这个攻击者的区块给拉到新的Epoch里面。第二个原因就是，如果攻击者没有超过50%的算力，他就没有办法改变主链。Q8: Conflux的CTPS有测试数据吗？A8: CTPS是指确认交易的TPS。我们实验中测出来的TPS实际上就是确认交易的TPS。大概在4000~6000。Q9: 挖矿的话，对于挖矿设备具体有什么要求呢？A9: 我们会选择GPU友好的POW算法，所以使用GPU设备就可以了。 ...

微服务架构是这几年IT领域的一个高频词汇，越来越多的项目和应用正在以微服务的思想进行重构。相比于单体应用和SOA架构，微服务优势也逐渐凸显，被广大架构师和技术人员引入和推崇。当然，单体应用、SOA、微服务等各有优势和不足。单体架构在早期的企业内部信息化或者搭建中小型项目时很常见，简单说就是将应用程序的所有功能都打包成一个独立的单元，可以是JAR、WAR、EAR或其它归档格式。一般单体应用使用通用的IDE即可开发调试，项目便于共享、易于部署和测试。但是单体架构的应用不够灵活，任何修改都需要重新构建和部署，而且应用可能较大，不利于持续的迭代和交付。此类应用容易受到技术栈的限制，一旦先期设计出现问题，后期的技术债务会加重负担。微服务架构模式有点像SOA，它们都由多个服务构成。SOA架构将多服务整合在一起，但其和服务总线ESB过于紧密的联系以及其复杂性，也使得其在互联网应用中的部分场景里不太适用。微服务架构模式不包含ESB服务，微服务应用乐于采用简单轻量级协议，比如REST或者RPC来实现。常见的微服务调用拓扑结构如下，此示例是基于Spring Cloud的微服务调用。完整的微服务解决方案应该包括服务注册治理中心、API网关、服务的降级熔断以及分布式配置等机制。在业务逻辑体现上，其调用关系可能如下：微服务架构下有很多优势，这里不做具体扩展，可简单罗列如下：1：独立微服务复杂度可控制；2：可灵活水平扩展；3：可独立部署运维；4：开发针对性强、支持小团队敏捷开发；5：提高系统的可组合性和可替代性；但是，在解决服务拆分问题、水平扩展问题的同时，其使用也衍生出了一系列问题，如分布式应用部署自动化问题、数据一致性、配置文件管理、服务的注册、服务的治理等。当然，也有一系列的方案来处理解决上述问题，如基于DevOps的自动化运维工具（用友云运维平台）、配置中心、最终一致性方案、服务注册治理中心与统一的服务网关等。本文主要讨论下在微服务和分布式架构下，配置文件如何更好的管理。每个微服务都维护着相对独立的业务，服务之间通过RPC或者REST API的方式相互调用，聚合成整体。每个微服务一般有自己的数据库和支撑环境，每一个微服务实例也会拥有自己的运行环境或者说是独立的进程，也就相应的需要维护一份自身环境的配置文件，如Spring的配置文件、属性文件、业务的XML文件、AccessKey认证文件等等。一个完整的业务通常由多个微服务组成，每个微服务在开发环境、测试环境、预发布环境和生产环境对应着不同的配置信息，需要针对不同环境维护多份。开发者在开发测试以及联调的时候需要对应不同的环境信息，频繁的修改和调整配置信息，带来了很大麻烦。大量的配置文件的维护给运维人员带来相当大的困扰。痛点一：配置文件太多，如果开发规范不严格，各个组件集成在一起时配置文件整合麻烦；痛点二：一个服务一般对应开发、测试、预发布、生产等多组环境，多套环境下配置文件手动管理也很复杂；痛点三：运行中的环境对应的配置项需要变化调整时，调整配置文件需要重启环境；上述问题的出现，迫切需要一个统一的配置文件管理、维护的服务出现，此服务需能统一管理多个微服务的配置文件，还能根据开发、测试、预发布、生产等环境进行区分隔离，并且能记录配置文件的多个版本。我们通常将这类服务定义为分布式配置管理或者配置中心。在配置中心的管理下，运维管理员只构建一份代码，即可发布到不同的环境，应用从配置中心拉取不同环境的配置，各个应用可以定义多个配置文件，运维管理员在配置中心统一维护各个服务的配置信息。配置中心具有的如下几大基础功能：1：配置文件和配置项的统一管理、支持多套环境；2：提供统一SDK，获取不同的配置；3：统一的信息监控和统计；4：实时或近实时推动变化信息到客户端；同时，配置中心本还要考虑安全和加密等问题，其自身也是集群应用，应该具有高可用、支持高并发等特性。业界常用的配置中心开源产品如百度的disconf和阿里的diamond以及携程的Apollo等，几种产品各有所长，这里也不统一展开。用友云配置中心（以下简称配置中心）在对比开源产品提供功能的基础上，提供基于自身技术特色的配置中心服务，更加适用用友云体系的云产品，其示意图如下：配置中心优势：优势1：配置中心服务端权限控制，统一管理界面；通过配置中心的服务端，管理员可以进行应用管理、配置管理、文件上传、在线修改、查看客户端连线状态等操作；可以通过超级管理员登录，也可以统一在开发者中心进行登录。管理员可以配置通知邮箱，在配置文件变化后以邮件方式通知对应的关注人。优势2：支持配置的多环境、多应用、多版本；业务应用可能同时有多个版本在线，也可能有测试、预发布、生产等多个环境同时运行。配置中心包含应用、环境、版本等概念，可以维护多个应用，针对每个应用的不同环境，管理多个版本的配置文件，保证不同版本业务应用的运行环境对应不同版本的配置文件的需要。优势3：支持SaaS应用的多租户隔离、应用隔离管理；基于用友云平台，已经发展起了很多SaaS应用，各个SaaS应用在数据库隔离、文件存储隔离、缓存隔离等做了大量的工作。配置中心也支持将各个租户的配置文件数据隔离管理，更好的适配了SaaS应用对于数据隔离的需求。优势4：SDK、动态属性注入、回调机制；和配置中心管理服务端配和使用的，是Client端的SDK。利用SDK，开发者可以集成配置中心的拉取配置、监听变化等功能，其使用配置和注解的方式让集成过程简单快捷且侵入较小。优势5：实时监控连接状态；配置中心的管理员可以下开发者中心的控制台，监控到各个版本的配置文件被客户端的拉去和连接的状态，令管理员可以全局监控各个客户端的状态。优势6：多种连接方式，短轮询和长轮询机制支持近实时推送；集成与使用篇用友云的配置中心的集成和使用相当简单，可以通过SDK的方式单独使用，也可以通过开发者中心应用管理中的配置提取和下载方式使用。使用方式一：SDK方式步骤1：配置文件统一管理，通过界面操作配置文件的上传和修改；步骤2：属性文件、XML文件SDK拉取；步骤3：配置变化动态通知、属性注入和回调机制支持，注解支持；可以看到，无需编写复杂的代码，只需要进行Spring的配置修改和少量的Annotation的编写即可，大大简化了开发者的集成过程。使用方式二：开发者中心结合配置中心使用（用友云配置中心和开发者中心结合，相得益彰！）用友云开发者中心简介：用友云开发者中心为开者提供了资源管理、持续集成、持续交付、容器服务、镜像仓库等应用基础服务，同时为应用的微服务架构落地提供完备的支撑，结合DevOps的理念，通过提供自动化运维、日志管理、中间件服务等功能，帮助开发及运维人员降低产品研发迭代过程中的负担。详情请参考http://iuap.yonyou.com/produc…://developer.yonyoucloud.com。（1）与配置中心的结合，在开发者中心的应用发布的过程中进行配置文件提取，并使用golang版本工具拉取配置；（2）配置中心将各个租户间数据进行隔离并加入了权限控制，使得其对多租户的支持更加完善；此之外，配置中心和消息总线结合，可以完美支持微服务间解耦！配置中心是逻辑解耦，物理不解耦的微服务的利器。它可以解决配置导致的系统耦合，架构反向依赖的问题，配置中心的演进过程，配置私藏到全局配置文件，到配置中心。异步消息是逻辑上解耦，物理上也解耦的微服务架构利器。它非常适合数据驱动的任务依赖，调用方不关注处理结果，或者调用方关注处理结果，但是回调的时间很长的场景。综上所述，利用用友云配置中心，可以集中管理微服务架构下应用的配置文件，并且其支持多套环境、多个版本，提供完善的SDK，可利用注解的方式简便的拉取指定的配置。而且，用友云配置中心以服务的方式提供统一的管理界面，结合用友云的认证中心可以提供可靠的安全保障。

摘要： 支付宝与欲望、想象力的博弈乃至搏斗，10年来不曾停歇。小蚂蚁说：双11十年间，交易规模的指数级增长不断挑战人们的想象力，而对蚂蚁技术团队来说，这不仅是一场消费盛宴，而是无数次濒临压力和焦虑极限的体验，更是技术的练兵场。如今双11对蚂蚁金服而言，已经绝不仅限于一个技术项目，而更像是一个社会化工程，可以叫做「连贯的，社会化的技术大协作」。支付宝团队不正像那尊红漆雕塑一样？一面对技术保持着敬畏、谦逊，一面又不得不玩命狂奔。「双11」就在眼下了，但蚂蚁金服的新园区里气氛明朗，人群也没往年那么匆忙。进园区时，出租车司机左手扶稳方向盘，右手比划着说，秋天是杭州最好的季节，当然啦，春天也不赖。阳光猛烈，洒在园区的楼群上，映得金栗色玻璃深邃又清亮。这座新园区里尚有很多事不为人所熟知。每3分钟会有1人在2号楼门口左手边垃圾桶上捻灭烟头，吱呀作响；访客大厅的姑娘每天用胖大海跟人参片泡4壶茶，12个玻璃杯倒扣，杯子把统一偏右30度；园区身着橙色外套的保洁员不间歇地扫落叶，她们每天工作8小时，3班倒，总在推车上预备3个喷壶，以及1个保温杯；每个花坛里，通常能用竹质夹子够出三个烟头或纸片。这里的秋天昼夜温差只有6摄氏度，但早晚都有人衣着单薄；穿冲锋衣的外卖员打手机时，话筒离开嘴边20公分，嗓门平均70分贝；下午时分，很多餐馆的员工们蹲在门口抽烟，只有星巴克客流不断，这里的大蛋糕与迷你蛋糕预定时间都是3天，收银员也偶尔会用墨色水笔给姓董的先生标注Mr Wang；员工餐厅每天分四次供餐，楼群间额外排列着18家餐饮门店。楼内有超过1000平米的免费健身房，私教价格仅为外边的一半，穿耐克跑鞋的姑娘每天会带着她的柯基犬来同时使用两台跑步机，尽管她的身型已没什么可挑剔。当你在下沉广场跟第四个人搭话后，套着夹克衫的保安会盯着看，在你发毛之前问及身份，噢，是记者，别介意，履行职责嘛。这是造价超过11亿元，面积18万平方米的蚂蚁金服新总部，设施功能齐全，堪堪媲美小型城镇，是 NBBJ 建筑事务所的手笔，也被叫做「蚂蚁Z空间」。功能强大的综合体建筑容纳了这里的杭州人与新杭州人，注视着他们的每一单生意，每一次创新，这里承载上万人的财富与梦想，也记录着每个个体的骄傲与焦虑。双11十年间，交易规模的指数级增长不断挑战人们的想象力，而急速扩张背后，对技术团队来说，是无数次濒临压力和焦虑极限的体验。想象力和焦虑最初给蚂蚁金服技术团队结出了一张网，又织就成细密厚实的茧壳。从2010年开始的三四年里，人们总会在双11的消费前端感受到一些使用体验的卡顿、不舒适，而内里则是这批工程师与欲望、想象力的博弈乃至搏斗，并在很多个逼近焦虑极限的瞬间，不断打破桎梏。「为了几十秒，值吗？」杭州入秋的早晨，凉得很，黄勇（花名展一）起个大早，跟几位同事结伴跑了趟灵隐寺。这千年古刹在深山，向来香火旺盛。这几年，寺庙时兴环保，免费发清香，他请了三炷，点上，拜拜。采访时，我问拜的哪位菩萨，黄勇皱皱眉头，乐了，「还真不认识」。烧香的心可是诚的，况且，来许愿的人，没几个比他的愿望还大，作为今年双11支付保障PM（项目经理），他得事无巨细地操办这个事关几亿人的项目。每逢双11，蚂蚁金服的项目组成员们总要供上关二爷，穿上红内裤，换上红战袍，存几瓶红酒，烧几炉香。按支付宝双11保障团团长陈亮（花名俊义，技术风险部研究员）的话来说，这是对技术的敬畏。可事实上，要敬畏的绝不仅仅是技术这一件事，双11作为枝节空前庞杂的项目，每个事物的细节上都有无数个随机的可能性，早已超出了人能控制的边界。黄勇能做的就是制定「容灾」机制，尽力去逼近那个不可能到达的「确定性」。举个例子来说，在采访当天，黄勇刚刚给所有11月10号晚上要进光明顶（支付宝双11作战室）的成员发了邮件，仔细交代了「如果当晚茶杯在电脑上打翻了怎么办」这个主题。2012年，负责支付宝双11项目的PM同事从西安请回一尊皮影关公像，大伙觉得新鲜，纷纷敬上香烟、酸奶跟水果。自打那会开始，每逢重要的项目启动，总有人提前往公司请关二爷。创业邦这次拜访蚂蚁金服时，作战室里就供着一尊二爷铜像，该上的供也早都摆上了。请二爷似乎也开始带来好运，那位请铜像的同学，前年双11还在公司里抽到一次大奖。某年双11，马云带几位合作伙伴在西溪园区参观，登上光明顶（支付宝双11作战室）的时候，一位女性投资人吃惊地问，你们工程师居然时兴拜关公？俊义就笑，还是那个说辞，敬畏。信仰也好，敬畏也罢，双11显然都值得。十年里，从最初几乎不太被人感知的促销活动，由欲望、情绪、责任感和创造力混合驱动着增长，长成一个不断突破想象力极限的庞然大物。2009年，首届双11购物节的单日成交额是5000多万元，一个对比是，当年支付宝的日交易额最高突破了12亿元。「记得有几十个品牌参与，当时对它的感觉就是，淘宝做了个活动」，支付宝事业群总裁倪行军（花名苗人凤）回忆称。但他没有预料到，所有人都没预料到，从第二年，双11就开始刷新所有人的想象力上限，如今回头端详增长曲线，它在某些年份里维持着数字量级的增速，那线条着实显得陡峭，但想想吧，处在那个当下，未知和增长给人们心理带来的是更加强烈的冲击感。在蚂蚁金服CTO程立（花名鲁肃）的记忆里，2010年之后的几年双11，对支付宝技术团队来说，是像电影《2012》一般的巨大考验，「你把一个船放在那里，上面有个大浪，没人知道能不能扛住，扛住就扛住了，扛不住就没了。」这艘大船只能提前按既有的想象力建造，但在应对巨浪时，必须临时补救随机出现的漏洞，随机意味着不确定性，巨大的随机和不确定性就进一步施加给团队更庞大的压力。程立记得，现任阿里云副总裁李津当时在阿里巴巴集团负责双11项目，「受不了的时候，李津要开车到龙井山上，打开窗户睡一宿，他说压力太大了，要吸氧。」2010年，第二次迎接双11的支付宝经历了一次后来广为人知的「4秒惊魂」。11日的23时59分30秒，双11结束前半分钟，支付宝核心账务系统突然报警，资源行将耗尽。当时整个支付宝的账务数据库没有进行过任何拆分，一旦系统崩溃，所有业务都会挂掉，对淘宝和支付宝都会造成灾难性损失。在工程师将一个会计系统的应用关掉，释放出来资源时，离数据库崩溃只剩4秒。单就技术本身，在当时就已经是一笔永远测算不清楚的账。2012年双11之前，支付宝技术组已经把能想象到的压力测试做了个遍，但当晚高峰期还是出了岔子，运维工程师巩杰（花名袁越）记得，当时后台一条数据通道设置的阈值太低，导致短暂宕机，但系统认定为无法响应，于是自动将其剔除了，随后服务器一台接一台地挂掉，「跟雪崩似的，导致几十分钟里交易一直在抖动」，直到做了降级，切掉一部分流量之后，系统才恢复正常交易——按程立的说法是，那根保险钨丝被高频交易熔断了，临时搭上一根铜线才应付过去。此时，过于庞大复杂的系统，人力已经无法完成全面有效的测试了。巩杰说，因为有前两年数据库无法承压的情况，2012年已经在应用和DBA层面做了大量的压力测试，但最终出问题的，恰恰是前面还没压到的「路口」。采访中，俊义苦笑道，当时每年双11都信心满满，每年又都过得提心吊胆。在双11压力最大的那几年，整个支付宝技术团队每年要花费几个月乃至半年时间来「练兵」，做各种技术结构调整，系统测试。俊义最初产生过疑问，整个团队花费出的绝大部分时间精力，只是为了贡献给双11最高峰的那几秒。「非得这样吗？」「值吗？」但时间会赋予所有原本未知事物以终极的意义，双11正是这样一个把意义逐渐延展开的时代产物。「在当时，淘宝是我们最大的客户，我们必须服务好」，俊义说。按照马云早年的讲法，在客户关系之外，淘宝天猫和支付宝更像是夫妻关系，也正是在淘宝天猫的业务倒逼下，支付宝团队的技术能力被空前地激发，一位今年入职的工程师毫不讳言，他入职蚂蚁金服的核心吸引力就是双11，「对工程师来说，再没有比双11更值得挑战的项目了。」巩杰也是后来才意识到，某信用卡团队早先在实验室环境里实现的数万笔每秒的交易峰值，早就被支付宝在实战里远远抛在身后。2017年双11，支付宝的交易峰值就达到了25.6万笔/秒。按照资深技术专家李铮（花名祢衡）的说法，技术团队最近几年已经把双11两天48小时的工作量做了很细致的拆分，“我们做了非常详尽的作战手册，它有很多的步骤，按不同的时间点，你要去执行。”技术之外，双11是个在更广泛的范围内牵扯着不同部门，不同团队，不同企业的庞大协作系统。蚂蚁金服集团副总裁陈亮（花名关胜，品牌与公众沟通部门负责人）记得，某一年的双11当晚十点钟前后，一家国有大行银行的交易系统内的一百万个单号发光了，后续单子无法生成，于是当晚最后两个小时，所有源自该银行的支付订单都无法执行。「总会有你无法预想的问题出现，我们做好所有准备，剩下只能兵来将挡水来土囤了。」想想啊，就好比火箭升空一样，倪行军敲敲桌子说。多少软硬件技术环节，多少个零件组装拆卸，在设计制造的过程中，只能穷尽所有人脑可以企及的可能性去做测试，但在点火那一刹那，等待它的是圆满功成还是原地爆炸，你只能束手以待了。倪行军觉得，无论是技术人员拜关公、烧香还是公关团队的预案，都证明了蚂蚁金服团队对双11的敬畏心。2013年5月，支付宝下线了最后一台IBM小型机，随后逐渐以自主研发的OceanBase数据库替代了Oracle，完成了去IOE工程。如今双11对蚂蚁金服来说，已经绝不仅限于一个技术项目，而更像是一个社会化工程。程立说，如果为它定义一个清晰的组织概念，可以叫做「连贯的，社会化的技术大协作」。一面敬畏，一面狂奔蚂蚁Z空间的楼群维持着古怪的几何形状，像个「撅着屁股」的Z字，又像个扭动起舞的水泥巨人。但与外部怪异的建筑设计、杂乱的人流相反，在楼宇内部密布着闸机与证件机器，构建起坚固的秩序和准入流程。室外，巨大的红色人形雕塑朝着人流入口鞠躬，姿态谦逊，气势却浑然不可当。支付宝团队不正像那尊雕塑一样？一面对技术保持着敬畏、谦逊，一面又不得不玩命狂奔。这十年间，在双11之外，他们也有很多焦虑要去消解。被问及在支付宝工作十几年间最难忘的瞬间，倪行军和陈亮的首选都是那次年会。2010年1月21日，支付宝公司年会，此前内部并没有太多源自自觉的危机感。遥遥领先的市场份额与灼灼亮眼的业务数据，一切看起来十分顺利。但年会一开场，人们就发现气氛就有些怪异。会场高音喇叭里首先传来指责、抱怨、无奈与批评，这些声音是来自客服电话录音里的客户投诉。但现场事态发展，完全不只是「反思」而已。陈亮到了会场，才收到马云等阿里集团组织部的高管们将要到场的消息。随后，客户满意中心的代表上台，表达了「我们的体验如何糟糕，用户如何承受着折磨」；BD团队则指出「合作伙伴是如何对支付宝的高期望，同时又是如何的失望和无奈」。马云现场发火了。「烂，太烂，烂到极点」。陈亮记得，这是他多年来唯一一次在公开场合看到马云发脾气。马云毫不客气地指出，支付宝在很多问题上太过保守，如果不重视用户体验，「将慢慢死去」。这显然跟支付宝团队自我评价的结论相去甚远，事实上，在那个时点上，如果横向对比来看，支付宝的产品设计和市场占有率表现绝不算差，团队甚至把2009年定义为「用户体验年」。但回头看，当时在PC端的产品体验确实很不理想，每次支付都需要解决控件、插件、外接U盾一堆问题。 时任阿里巴巴CTO的王坚也给了一句非常严厉的评价，「自娱自乐」。这甚至使倪行军当下有点懵，他记得在年会之后一段时间里，一度陷入严重的自我怀疑，「搞了这么多年技术，怎么变成自娱自乐了？是不是我们对技术的认知出了问题？」后来他反应过来，差池是出现在从技术到产品、到业务、再到客户之间的对话环节。做客户体验，单由使命与愿景来驱动不够。他原本认为的应该如何运作，与用户的现实期待之间，鸿沟已现。整个中国的支付行业按照支付方式演变可以分成三个阶段：2009年-2013年，从网银支付到快捷支付；2014年-2016年，移动支付崛起；2017年-2018年，则是指纹和刷脸支付渐成主流。如今回头看，那次年会对整个蚂蚁金服公司来说都是个至关重要的节点，在此次转型的推动下，支付宝从网银支付迈进了快捷支付时代。「生生被逼出来的」，俊义回忆道，「如果那时候没有快捷支付，整个中国移动互联网的进程至少会落后两三年」。微信支付加入之前，支付宝曾有十年时间只能自我调试，寻找发展坐标。而当前者入局，支付宝团队的反应是：哇！我们有竞争对手了。「我们从没有遇过像这样的竞争对手，竞争是很正常的事情，但结局取决于竞争对手的能量，微信支付是非常值得尊敬的一个竞争对手。」陈亮如是说。微信支付出现，促使蚂蚁金服又一次推进意识形态的提升。如今说来云淡风轻，当时可是风起云涌，情绪百般垂丧。时间回到2014年1月26日，腾讯推出微信红包，后者立刻以病毒式传播的方式活跃在微信群内，并在除夕夜全面爆发。数据显示，除夕当天到初八，超800万用户参与了红包活动，超4000万个红包被领取。与微信红包这面的热火朝天形成明显反差的是，支付宝的「讨彩头」反响平平。后者推出于23日，还早了3天。「微信一个红包就超过支付宝8年干的事。」这句话很快流传起来，马云后来则用「珍珠港偷袭」评价腾讯推出微信红包一举。陈亮对这件事情对记忆尤其深刻，他参与了支付宝红包的产品讨论。因为也在广东工作过，知道当地有讨红包的习俗，于是他给出了做「讨红包」的建议。但微信做的是「发红包」，陈亮回想，当时讨论过程中，似乎也有人提出这一点，但产品设计最终并未将其采纳。 其实，即便支付宝当时采用了发红包的设计，在那一阵上也未必有胜算——没有关系链，没有社群，没有从交易体系到账户体系的整体准备。但陈亮仍然感到懊悔，控制不住的懊悔，甚至责怪自己技不如人。眼看着媒体群里纷纷扬扬的红包雨和赞扬声，陈亮都不想上微信了，「不想说话了，不敢说话了」。 他想去友人处寻得开解，想驳斥那句一个红包顶八年的说法，但他刚开口就沉默下去，市场反应已然说明一切。可他还是在心里翻来覆去地想，怎么我们没有想到人家那个点子，怎么就没有呢？ 但事情过去也就过去了。尽管公司层面的焦虑一直延续到2016年，但陈亮已经学会将焦虑情绪摒除在自己的生活之外。焦虑毫无用处这件事已被证明——前两年的焦虑除了让他自己难受紧张、动作变形外没有产生任何意义。其实，接受这种量级的竞争，或许某种意义上也是在接受命运馈赠。陈亮后来总是被年轻同事认为对困难事物的感受很迟钝，他自己觉得原因在于再没有过境况更加艰难的时刻了。再碰到困难时，总有一种消解的情绪在，「最难的时候都过来了，这些算什么？」而支付产业则更加受益于两家顶级公司的竞争推动，中国支付技术在国际上一骑绝尘。2017年年末，西班牙《世界报》刊文表达了对中国支付产业的看法，给出的结论叫做：「中国的支付革命堪称中国史上最大的技术革新之一。」技术的价值观其实从2010年双11的「4秒惊魂」之前，支付宝技术人员就意识到，使用IOE商用设备（IBM-服务器提供商，Oracle-数据库软件提供商，EMC-存储设备提供商，三者构成了从软件到硬件的企业数据库系统）与开源软件，已经不能适用于双11交易量指数级增长对技术支持的要求，尤其是在谁也不能完全预设到当晚状况的时候。即使能支撑，成本也将是天文数字。支付宝决定去IOE，自主研发分布式数据库，转云计算，OceanBase项目随即启动。俊义记得，他在支付宝做的第一个技术改造项目是拆分数据库。当时还不是因为双11，单纯是因为支付宝网站交易量涨得很快，数据库扛不住了，不拆，业务就无法增加。这是在2008年。2010年，俊义又拆了一次数据库。这次，他将上次拆出的两个数据库中的交易数据库，拆成10个小型机。这时已差不多算是为去IOE铺下基础。但很快，10个小型机也不够用了。 2011年的双11结束后，应用服务器与数据库的连接已到瓶颈，容量没办法再增加，换句话说，IOE集中式强大单点无法满足阿里特别是当时淘宝爆炸式业务增长应用的模式，同时也限制了技术潜力的发挥，另外，由于IOE是专用设备，对机架、电力、网络存在单独设计的要求，成本压力也已经非常大。 从2010年1月启动，到2011年7月完成商品库的去IOE（经历读写分离、去小型机、去Oracle和EMC），再到交易等其他核心系统的去IOE，2013年，支付宝最后一台小型机下线，IOE中的I和E都已经被中国自主研发的技术取代，上云完成阶段性进展，这就像造发动机，意味着双11的交易量不会再受到技术制约。不过在第一阶段，每年双11能否顺利通过，还是有点碰运气。从2014年开始，支付宝开始研发和施行全链路压测技术，这就有点像造飞机时候的风洞，造一个实验室，完全模拟当天峰值所有的真实环境，对系统进行压力测试。据2018年大促保障副队长巩杰说，全链路压测对真实用户请求的模拟可以达到与双11当天请求90%以上的一致度。这样一来，到了双11当天，平稳度过的概率就极高了，团队因不确定而产生的焦虑大幅降低。全链路压测作为消除不确定性的“大杀器”，已经成为目前测试系统的常规手段，随着系统的升级，使用频率也在降低，李铮记得，全链路压测技术刚刚研发使用的时候，“恨不得每天都做一遍测试”，而今年的双11准备工作里，每周定期做1-2次压力测试已经足够了。支付宝的双11已经是一个巨大的系统工程，已经无法再完全依赖人脑思考解决所有条线上的问题。所以，李铮觉得，“智能化”是另一个关键词。对系统工程的把控，也正是要辅以智能化全链路压测这类技术手段，才能更加精准高效地解决问题。 11月2日，大促保障团组织了最后一次模拟的全链路压测，万事俱备，只欠东风，就等10日24点一过。对支付技术来说，稳定压倒一切，稳定也意味着一切。一如往年，第10年双11，稳定的重要性依然处于第一位置。稳定之外，支付宝技术团队还有更多追求。在2018年的双11技术保障上，人工干预已经越来越少，因为整个保障系统的智能化程度越来越高。比如，往年筹备双11时，该配置多少计算资源，如何达到最优化的配置，都需要非常有经验的工程师进行严密计算，并进行反复的压力测试，不断调优。但现在，机器可以自动地进行计算和调优。程立打了个比方，双11的支付保障会越来越朝着「自动驾驶」的目标迈进，该往哪开，在哪停，如何躲避风险，保障安全，都是智能的。新的变化还体现在生物识别支付和区块链技术的应用。 在倪行军的谈论中，支付宝对支付的理解，倾向于支付脱媒，到最后，支付时不需要任何载体，人体本身即为最大媒介，当然，脱媒不可完全脱离，但生物识别技术是IoT时代用户参与到数字化场景的敲门砖，任何的场景系统都要首先确定一个所谓的数字身份的问题，而人本身就是最棒的载体，不需要其它的媒介做二次切换。由此，生物识别是可以重塑体验的技术。据倪行军透露，平日应用场景中的生物识别（包括指纹输入、面部扫描等）支付比例已经超过一半，这反映出整体人群对生物识别技术所对应的新支付体验的接受程度，这信号让他觉得，手机应用之外其他生活场景中，扩展生物识别技术用户的时机，已经到来。今年上半年，生物识别技术真正走向规模化商业化，倪行军的预期是先实现规模化，在终端设备达到百万级规模的基础上，根据用户行为与各商业场景连接的磨合情况，再考虑后续的商业诉求。未来，新技术的应用势必重新定义整个商业流程，新的百万级的商业机会将在此诞生。今年天猫双11用区块链技术为1.5亿跨境商品提供原产地溯源，包括比利时钻石交易所的钻石这类大额商品。 变化背后是蚂蚁金服的BASIC技术战略演进及开放，Blockchain (区块链)、Aritificial intelligence（人工智能）、Security（安全）、IoT（物联网）和Computing（计算）这五条线索构成对未来更加清晰的想象力。十年间，蚂蚁金服整个公司都在从中心化向分布式持续变化。人员能力变得更加均衡。俊义记得，早年在双11和很多技术攻关的关键时刻，总会有几位技术大牛同事站出来，在当下拿出过人的洞察与能力，最终顺利过关。但如今，蚂蚁金服公司的整个技术结构益发庞杂，必须形成全局、众人的工程化作战。IT架构从IOE变成分布式，再演化出「离在线混部」。去年有25%是自有服务器处理，55%在云上，20%是离线资源；今年这个比例则会更新到60%在云上，在线与离线分别20%，其间，性能较差的离线机房也能执行在线处理，核心在于资源的进一步合理分配。分布式趋势渐成大势：机房越来越多，从杭州拓展到全国各地；应用系统与数据库越扩越多；团队从支付宝技术团队扩至各个产品线，集团运作从前尚可靠寥寥能力拔尖者把握，如今则需层层分解，整体组织协同作战。「从中心化到分布式」是互联网发展过程中，近年形成的社会关系形态和内容的一大特征。如果将其视作一种价值观的话，作为一家工程师员工占比超过51%的互联网金融企业，它正在被深深影响、驱动并改变着，企业里大量人、事、物，都在明确地呈现这这种趋势导向，这家价值上千亿美金的企业，也正在成为一个由技术价值观驱动业务、团队革新与发展的经典范本。本文作者：平生栗子阅读原文本文为云栖社区原创内容，未经允许不得转载。

摘要： 2019技术发展趋势早知道，你值得拥有！年度回顾：2018年的AI/ML惊喜及预测19年的走势（一）Unravel Data首席执行官Kunal Agarwal人工智能和机器学习的日益重视将会推动TensorFlow和H2O实现技术突破成为可能。此外，Spark和Kafka将继续呈现引人注目的受欢迎程度。随着云业务模式快速成熟，企业并购交易将继续加速。巨头将对人工智能领先的创业公司进行大规模收购，以便在AI和ML中提供高度需求的知识产权和人才。谷歌和阿里巴巴在收购萌芽的人工智能技术方面处于领先地位，而其他一些科技巨头将尝试通过自主研发来模仿他们的成功。Grammarly研究总监Joel最近几年，人工智能推动了理解和生成语言的界限（最值得注意的是新闻翻译）。由于以下因素，我预计2019年更多自然语言处理（NLP）里程碑成果将会减少：语言解释依赖于语境，意味着真正理解一个人的写作或语言需要参与者的知识，还有他们先前的交流。大多数NLP模型工作是在没有这些因素的情况下进行的语言解释或生成，但我希望通过结合更多受众认知的知识，使得NLP性能提高并变得更加个性化。关于AI的一个小秘密：许多系统都是在数千人（或更多）人类评估者创建和标记的数据集上进行训练的。随着我们需要解决更复杂的人工智能问题，对大量高质量人工标注数据的需求将会增加，但在利用机器学习技术来收集这些数据时会有更多时间和成本效益的突破。同时，使用最少甚至没有标记数据（也称为无监督技术）的方法将减少我们对大量标记数据的依赖，使深度学习模型能够在新的和不同类型的问题上更加健壮。模型架构和基础架构的进步使丰富的深度学习模型能够在资源较低的环境中工作，例如在移动电话和Web浏览器中。在未来，我们希望看到更复杂的模型，即使没有互联网连接，也能在所有设置中为用户提供反馈。Univa总裁兼首席执行官GaryTyreman混合云和专用云将推动机器学习（ML）项目的大规模增长。根据最近对超过344名技术和IT专业人士的调查显示：在2020年，越来越多的项目将投入生产，ML将在未来两年内实现爆炸式增长。超过80％的受访者表示，他们计划将混合云用于ML项目，这样可以降低成本。Univa客户已经在寻求指导，将他们的HPC和机器学习工作负载迁移到云或混合环境，因为他们希望将他们的ML项目推进生产。AI/ML将进入企业应用程序。我们一直在谈论人工智能是过去两年中最热门的趋势之一。我们开始看到AI和机器学习稳步进入企业应用程序，用于客户支持，欺诈分析和商业智能等任务。我们完全有理由相信这些创新将继续在云中发生，2019年将是企业中人工智能的重要一年。HPC和GPU将在推进机器学习项目中发挥关键作用。GPU在HPC中将发挥很高的价值，其中许多任务，如模拟，财务建模和3D渲染也能在并行环境中运行良好。根据HPC市场的市场研究公司Intersect 360研究表明：50种最受欢迎的HPC应用程序包中有34种提供GPU支持，包括所有前15种HPC应用程序。因此，GPU在HPC中变得至关重要。科学家，企业研究人员，大学和研究机构都知道，加速应用程序对商业和研究来说都是有益的。Sutherland首席分析官Puti Nagarjuna打破障碍; 人工智能与人类恐惧之间的平衡：无论我们是否意识到，我们对人工智能的依赖比以往任何时候都更加活跃，2019年公司将齐心协力进一步了解人工智能的局限性，同时发现AI应对更细微的人类行为的方法。越来越多人接受人工智能作为客户体验的第一线：消费者将更多地接受人工智能聊天机器人作为客户体验的第一线，更多公司将采用它们来创造超个性化和便捷的体验。AI将把以客户为中心的营销推向新的高度：随着各种规模的公司转向人工智能技术，通过人工智能增强趋势分析将达到前所未有的价值水平，帮助企业评估如何优化营销工作，作为数据驱动的一部分CMO将崛起。机器学习追求最大价值：数据呈指数级增长，但访问该数据的能力对于良好的ML算法并不实用。在未来一年，一个主要的挑战将是不断发展的算法，以产生适用于你的数据的最大值具体需要。汇流数据架构师Gwen Shapira：随着越来越多的公司试图将AI从实验室转移到生产中，我们将看到越来越多的工具用于管理开发生命周期。AI具有独特的双阶段开发模型，目前的CI/CD工具链无法解决训练，可重复性和数据管理方面的独特挑战。许多公司意识到他们可以通过更简单的工具获得许多AI / ML优势，例如规则引擎和简单的推荐系统。我希望看到越来越多的人采用这些，既可以作为进入完全自治世界的垫脚石，也可以作为许多行业的良好解决方案。我们将看到许多数据工程工具被重新命名为AI/ML数据管道工具。它们与通常的数据工程工具大致相同，但预算较多。我期望一个真正的以人为本的数据管道来处理训练和生产之间的数据和模型流，特别是处理反馈循环和模型改进。Kinetica的首席技术官兼联合创始人：Nima Negahban数据工程师的崛起使AI成为企业的最前沿。去年是数据科学家的一年，企业重点关注招聘数据科学家创建高级分析和ML模型。2019年将是数据工程师的一年。数据工程师将专注于将数据科学家的工作转化为业务的强化数据驱动软件解决方案。这涉及创建深入的AI开发，测试，DevOps和审计流程，使公司能够在整个企业范围内大规模整合AI和数据管道。人与ML形成共生关系，以推动实时业务决策。2019年人工智能和分析的世界需要融合，以推动更有意义的业务决策。这将需要一种通用方法，将历史批量分析、流分析、位置智能、图形分析和人工智能结合在一个平台中进行复杂分析。最终结果是一种新的模型，用于结合临时分析和机器学习，比以往更快的速度提供更好的洞察力。Oqton首席技术官兼联合创始人：Ben Schrauwen2018年最大的惊喜是在解决大型训练数据集需求方面取得的进展。AlphaZero击败了所有以前的版本，达到了超人的水平。生成对抗网络（GAN）正在成功应用于产生更强大的模型。此外，我们现在看到AI可以在非常具体的任务中变得如此擅长，人类无法再说出差异，例如Google Duplex在语音合成中有效地越过了神奇的山谷，为特定的狭窄领域产生了自然的声音对话。我预计我们会很快看到AlphaZero的方法适用于大型搜索空间的难题，甚至超越人类的专业知识。视觉和3D深度学习的进步将导致越来越多的解决方案，以帮助提高人类在特定任务中的生产力，甚至完全自动化。MemSQL首席执行官：NikitaShamgunov预测＃1：现代工作负载需求将命令从NoSQL转移到NewSQL数据库。由于ML，AI和边缘计算工作负载不断激增数据，传统的NoSQL数据库不再足以满足市场对更高性能和可扩展性的需求，而不会给现有数据库增加新的复杂性。关系数据库已发展成更具可扩展性和快速运行的NewSQL数据库，通过将事务和分析处理功能集成到单个数据库中，这些数据库能够满足这些需要更高数据处理能力的现代工作负载的需求。预测＃2：人工智能和机器学习计划将要求CEO更好地了解它的基础架构。人工智能和ML的竞争正变得比以往任何时候都更加激烈。为了使企业能够成功部署AI和ML以实现最大化价值并降低风险，CEO和其他C级领导者需要了解其数据基础架构的成熟度，包括如何存储和处理数据，以确定哪些技术和人才需要推动转型。预测＃3：AI将使员工能够最大限度地减少劳动密集型任务。人工智能的采用有望推动新的角色和工作机会的引入，以符合公司战略，从而变得更加以数据为导向。人工智能将帮助员工专注于更有意义的职责，例如分析洞察力和应用快速数据驱动的决策制定技能，而不是替换人来执行工作，而是帮助执行通常耗时且劳动密集的任务。本文作者：【方向】阅读原文本文为云栖社区原创内容，未经允许不得转载。

摘要： 2019技术发展趋势早知道，你值得拥有！考虑到技术变革的速度，我认为让专业IT人士分享他们对2018年最大惊喜及2019年预测的看法会很有趣。以下是他们对人工智能（AI），机器学习（ ML）和其他数据科学迭代的看法：CLARA分析公司首席执行官兼创始人：Chiara Lakshmikanthan2018年的惊喜：我对AI已经应用于InsureTech行业的快速步伐感到惊讶。但更重要的是，商业保险公司在其工作流程的某些部分（如承保，理赔业务和客户服务）开始使用AI以保持竞争优势。2019年的预测：在B2B 的AI领域，人们越来越关注硬实力的储蓄和价值。AI的理论价值主张被广泛接受，但是，大多数公司在未来几年对AI技术提供商的期望也将更高。Sinequa产品营销总监Scott Parker：虽然围绕ML和AI进行了大量宣传，但具有变革性的AI还有很多仍在实验室中进行测试。对于2019年，ML和AI最终会以某种方式从实验室和现有应用程序中找到出路。在大多数情况下，人们甚至不知道它在那里，因为它将以无缝的方式嵌入。数据科学家Minkyung Kang：惊喜：端到端机器学习服务使ML工作流程变得更加简单。数据科学家和开发人员可以在一个地方构建，训练和管理ML模型，并将模型大规模转移到生产环境，而无需过多担心管道和架构。预测：在ML工作流程中连接和集成不同的步骤和流程将得到进一步改进和简化，并允许许多初创公司和企业使用更少资源的ML应用程序快速移动。这将进一步扩展到ML的整个生命周期的管理，包括数据收集和管理。Anaconda的联合创始人兼首席技术官：Peter Wang惊喜:Github和Red Hat的收购，Cloudera和Hortonworks的合并也令人惊讶,它标志着Hadoop“大数据”炒作周期的终结，并清楚地表明分析和ML的未来增长必须针对异构存储架构。预测:“数据科学”作为一个领域将分成几个子专业，包括数据工程，高级统计推断和解释器，我们需要为它制定标准和最佳实践。随着我们更多地了解国家发展人工智能的力度和用传感器来完善监控状态，这将为更多的数据隐私立法提供动力。SIOS Technology总裁兼首席执行官：Jerry Melnick数据分析和人工智能将无处不在：数据分析和人工智能将继续变得更加专注，专门针对特定问题而构建，这些功能将越来越多地嵌入到云平台和管理工具中。例如，用人工智能驱动的基础设施工具现在被用于分析来自无数监测和管理工具的输入，许多这些人工智能工具都致力于解决整个IT领域的广泛问题。在2019年这些快速发展，更加专注IT人员遇到的最关键的问题及常规和复杂问题。这种备受期待的功能将简化IT运营，提高基础架构和应用程序的稳健性，并降低总体成本。随着这一趋势，人工智能和数据分析将自然地嵌入到HA和DR解决方案以及CSP产品中，以增强其运营的稳健性。通过快速，自动和准确地了解问题并诊断复杂配置中的问题，从云提供的关键应用程序服务的可靠性和可用性将大大提高。BISim高级总监：OISkar Nieder机器学习和深度学习（DL）形成的AI革命在软件开发行业中继续受到越来越多的关注。随着图形处理单元（GPU）加速的引入，以前存在的时间和计算限制被消除，新的易于使用的框架和数据中心将使这些技术在2019年向所有人提供。Python，C ++和Javascript将在2019年继续作为主要编码语言。然而，对于开发人员来说，体验TensorFlow或Caffe for AI和Angular或React等Web语言开发的语言框架将变得更加重要。Micro Focus战略总监：Mark Levy在2019年，AI和ML将与自动化融合，并将彻底改变DevOps。在过去的几年中，自动化在DevOps中的作用继续成为更大实践的一个重要方面。目前，主要的重点是自动化过程或事件驱动的手动可重复任务，但AI/ML显示变化的新进展即将出现。通过AI和ML的融合，自动化有可能展示前所未有的智能，因为新系统将关注趋势，以及分析和关联整个价值流以预测和预防问题。随着DevOps实践专注于提高运营效率，ML，AI和自动化即将融合将为使用DevOps的公司带来显着优势。Micro FocusVertica产品营销副总裁Joy King在2019年，ML项目将从科学项目和创新实验室转向由行业颠覆者领导的全面生产。事实上，每家公司都有ML项目，但其中大多数都依赖于无法访问跟业务目标相关的所有数据的专业平台。所有数据都存储在各种数据仓库和数据库中，其中没有一个能够运行端到端ML，迫使数据移动到专业平台。然而，仅使用一部分数据来训练和评分ML模型，从而导致精度有限。在2019年，当前的行业颠覆者和智能传统公司将把ML带到其所有数据，而不是将其数据转移到ML平台上。这些公司将更准确地预测结果，包括医疗设备的预测性维护，基于个性化客户行为分析的预测收入，主动检测欺诈等非服务。Portworx的联合创始人兼首席执行官Murli Thirumale人工智能和自动化将改变IT的经济方向。即使基础设施本身变得可编程，大多数DevOps仍然由人驱动。但是数据量增长如此之快，应用程序发展如此之快，这就要求基础架构必须足够灵活，这样才不会成为瓶颈。在2019年，基础设施将变得越来越可编程，基于AI的机器将预测存储和计算需求，并根据网络状况，工作负载和历史模式自动分配资源。NICE解决方案营销人员Karen Inbar机器人自动化将创造新的就业机会。随着机器人过程自动化（RPA）的出现，组织内部正在衍生出新的角色。2019年，更多公司将招聘新的专业职位和角色，如RPA工程师、RPA架构师和RPA顾问，以帮助员工了解RPA最佳实践以及RPA如何强化工作流程。随着RPA技术在工作场所变得更受欢迎和更具吸引力，“首席机器人官”等新职位也将开始出现。公司需要选择自动化哪些流程。2018年的许多自动化项目都失败了，因为它们选择了对错误的流程进行自动化。在2019年，公司需要更密切地评估任务的时间分配和复杂性，这种自动化任务的战略性重新确定优先级将确保组织在数字化转型工作中推动投资回报率和成功。一旦组织掌握了更简单的任务的自动化，他们就可以引入更先进的技术，例如光学字符识别（OCR），使无人值守的机器人能够解释更多的数据元素。WekaIO首席技术官Andy Watson到目前为止，我们知道用于ML的数据集每年都在变大，不仅是累积量，还因为信号源（相机、物联网传感器、软件日志等）的数量越来越多。我们“预测”ML研究人员将利用越来越多的功能强大的GPU来处理前所未有的大量数据。但这仅仅是对当前趋势的观察，而不是预测。相反，让我们来看看如何使用这些更大的数据体。我可以通过ML训练来预测松弛参数，以允许软件减少训练错误，对支持ML计算环境的存储基础设施将产生影响。ML的领导者DeepMind最近发表了一篇重要论文：“关系归纳偏见，深度学习和图形网络。”一个关键点是ML训练可能会发展出一种更为徒手的方法，允许其软件影响其学习途径的选择标准（通过推理模式），这将影响数据存储基础架构。在今天的任何大型数据集中，我们都有一个“工作集” - 最活跃的数据子集，最常见的是最新数据。例如，在一组ML研究人员可能累积用于培训的所有许多PB中，他们数据中心的通常情况是，从较慢的“冷”存储中只能提升几百TB的总数据库，因此他们的GPU可以在“热”快速存储层中访问它。然而，随着这种大变化，将难以确定哪个数据应该是任何给定工作集的成员。相反，将整个事物视为可能必要的可能是适当的。正在进行的各种ML事件中的每一个将从所有那些PB中选择不同，并且这将指示所有数据被放置在热层中。McAfee的首席技术战略师Candace Worley首席分析官（CAO）和首席数据官（CDO）将需要监督AI。当公司扩展AI的使用时，必须做出无数的决定。隐私监管存在影响，但也存在法律，道德和文化方面的影响，我们需要在2019年创建一个专门的角色，并对AI的使用进行执行监督。在某些情况下，AI已经表现出不利的行为，例如种族貌相，不公平地拒绝个人贷款以及错误地识别用户的基本信息。CAO和CDO将需要监督AI培训，以确保AI决策避免伤害。此外，人工智能必须接受培训，以处理真正的人类困境，优先考虑司法，问责制，透明度，同时还要检测黑客攻击和数据滥用。可解释的AI将成为一项要求，特别是对于金融/银行和医疗行业。如果AI为个人的健康或治疗提出医疗建议，医生必须能够解释用于得出该结论的逻辑和数据。我们尚未与人工智能的关系处于某种程度，许多人因为人工智能的推荐而愿意接受药物治疗或手术，特别是如果涉及的医疗专业人员无法解释其建议的“原因”。在金融行业，我们将看到使用自动分析和认知消息，根据客户需求提供有关股票，债券，房地产和其他资产的财务指导和投资建议。在这里，消费者也需要对基于AI的决策进行解释。本文作者：【方向】阅读原文本文为云栖社区原创内容，未经允许不得转载。

在最近的上海和北美KubeCon大会上，来自于Treasure Data的Eduardo Silva（Fluentd Maintainer）带来了最期待的关于容器日志采集工具FluentBit的最新进展以及深入解析的分享；我们知道Fluentd是在2016年底正式加入CNCF，成为CNCF项目家族的一员，其被广泛用于容器集群中进行应用日志的采集、处理和聚合，但今天主要是跟大家分享一下同样来自于Treasure Data新开源的日志采集工具——FluentBit。FluentBit vs Fluentd既然已经有了Fluentd，那么为什么还要开发一个FluentBit呢？我们知道，Fluentd是基于Ruby语言的，在一些应用日志量较大或者单节点日志量较大的场景下，通过Fluentd采集日志的速率会远落后于应用日志的产生速率，进而导致日志采集的延迟时间较大，这对于一些实时性要求较高的业务系统或者监控系统来说是不可接受的；另外一方面，也是由于Fluentd自身的日志处理逻辑越来越复杂，全部放置在一个组件里来完成会导致越来越臃肿，因此Treasure Data在基于Fluentd优秀的架构和设计理念上重新开发了一个更加轻量级、更加高性能的日志采集工具——FluentBit，其主要采用C语言进行开发。从上面我们可以清晰地看到FluentBit本身占用的内存资源会比Fluentd少很多，且基本没有其他额外的环境依赖，但是支持的插件数相较于Fluentd会少很多，需要时间来慢慢丰富。FluentBit WorkflowFluentBit 内置了一个Service Engine，其每采集到一条日志时都会执行从Input到Output的整个Action Chain：- Input日志数据入口，FluentBit支持多种不同数据来源类型的Input Plugin，不仅能采集容器日志、内核日志、syslog、systemd日志，还支持通过TCP监听接收远程客户端的日志，同时还能够采集系统的CPU、内存和DISK的使用率情况以及本机Network流量日志。- Parser通过情况下我们的应用日志都是非结构化的，那么Parser主要是负责将采集到的非结构化日志解析成结构化的日志数据，一般为JSON格式；FluentBit 默认已经预置了下面几种Parser：JSON：按照JSON格式来进行日志数据解析；Regex：依据配置的正则表达式来进行日志数据解析；Apache：遵循Apache日志格式来进行解析；Nginx：遵循Nginx日志格式来进行解析；Docker：遵循Docker标准输出日志格式进行解析；Syslog rfc5424：按照syslog rfc5424规范格式进行日志解析；Syslog rfc3164：按照syslog rfc3164规范格式进行日志解析；- Filter在实际的生产应用中，我们通常需要对采集到的应用日志记录进行修改或者添加一些关键信息，这都可以Filter Plugin来完成；目前FluentBit也已预置了多种Filter插件：Grep：允许匹配或者过滤掉符合特定正则表达式的日志记录；Record Modifier：允许对日志数据进行修改或者添加新的KV数据，通过此可以方便我们对日志数据进行打标；Throttle：支持采用漏桶和滑动窗口算法进行日志采集速率控制；Kubernetes：自动提取容器或者POD相关信息并添加到日志数据中；Modify：基于设置的规则来对日志数据进行修改；Standard Output：允许将日志数据直接打印到标准输出；Lua：支持通过嵌入Lua Script来修改添加日志数据；- BufferFluentBit 内部本身提供了Buffer机制，会将采集到的日志数据暂存在Memory中直到该日志数据被成功路由转发到指定的目标存储后端。- Routing路由是FluentBit的一个核心功能，它允许我们配置不同的路由规则来将同一条日志数据记录转发到一个或多个不同的接收后端，其内部主要是基于每条日志数据的Tag来进行路由转发，同时支持正则匹配方式；如下面配置则表示希望将Tag满足正则表达式my_的日志直接打印到标准输出中：[INPUT] Name cpu Tag my_cpu[INPUT] Name mem Tag my_mem[OUTPUT] Name stdout Match my_- OutputOutput 主要是用来配置采集到的日志数据将要被转发到哪些日志存储服务中，目前已支持多种主流的存储服务，如ElasticSearch、NATS、InfluxDB、Kafka、Splunk、File、Console等，同样也支持将日志数据继续通过HTTP(S)协议将其传输到其他服务接口中；另外这里有一个比较特殊的Output就是Fluentd，可能大家会比较奇怪，其实在未来的日志架构模型中，FluentBit主要是在采集端专职负责日志的高性能采集，然后可以将采集到的日志在Fluentd中进行较复杂的聚合处理（同Filebeat和Logstash）：Other FeaturesEvent Driven内置的Service Engine采用完全异步的事件驱动模型来进行日志的采集和分发。Configuration简单灵活的、高可读性的配置方式，FluentBit的Workflow模型可完全通过配置文件的方式清晰制定。Upstream Manager采用统一的日志上游服务的网络连接管理，包括Keepalive和IO Error处理。TLSv1.2 / Security对于安全敏感的日志数据，支持通过TLS加密通道进行日志传输。Upcoming FeaturesFilesystem buffering mode当前FluentBit只支持Memory的buffer方式，但考虑到内存的易失性，未来也将会支持基于Filesystem的buffer机制。Optional plugins as shared libraries未来会将一些已内置的但又不是必需的插件以共享链接库的方式来进行动态加载。Kubernetes Filter improvements未来会继续深度整合Kubernetes，通过API获取更多POD关键信息并自动添加到日志数据记录中。Summary这两次的KubeCon大会上Eduardo Silva对日志采集工具FluentBit都进行了深度的解析分享，不仅介绍了FluentBit的整个架构模型，而且还分享了未来的发展方向，从整个分享来看FluentBit会侧重在日志的高性能采集方面；而阿里云容器服务在2017年初开源的Log-Pilot：https://github.com/AliyunContainerService/log-pilot ，其不仅能够采集容器的标准输出日志，而且还能动态地发现采集容器内文件日志，同时支持简单高效的日志声明式配置、支持日志路由、日志数据打标以及多种日志采集插件，未来我们将进一步与社区紧密结合，整合FluentBit的高性能采集特性以及Log-Pilot的动态发现和声明式配置优势来进一步增强容器化应用日志的配置采集效率。本文作者：chenqz阅读原文本文为云栖社区原创内容，未经允许不得转载。

小蚂蚁说：2018年9月20日，在杭州云栖蚂蚁金服 ATEC 科技大会主论坛上，蚂蚁金服副CTO胡喜正式宣布，蚂蚁金服的金融科技正式全面开放，为行业提供完整的数字金融解决方案。包括支付宝自主研发的容灾系统在内的多项核心技术和解决方案，如金融安全、区块链等都将对合作伙伴开放。“三地五中心”即在三座城市部署五个机房，一旦其中一个或两个机房发生故障，支付宝的底层技术系统会将故障城市的流量全部切换到运行正常的机房，并且能做到数据保持一致且零丢失。12月20日，在北京举行的“2018中国金融科技年会暨金融科技及服务优秀奖颁奖典礼”正式宣布蚂蚁金服自主研发的三地五中心异地多活解决方案获“2018年度金融科技优秀解决方案创新奖”。12月20日，由《金融电子化》杂志社举办的“2018中国金融科技年会暨金融科技及服务优秀奖颁奖典礼”在北京举行。来自银行、证券和保险等行业协会、金融机构，第三方支付公司，金融科技公司，以及信息产业界的200多家单位共计300余名代表与会。会上，中国金融电子化公司总经理、《金融电子化》杂志社社长张永福宣布，蚂蚁金服自主研发的三地五中心异地多活解决方案获“2018年度金融科技优秀解决方案创新奖”。达到银行业最高容灾等级标准要求据蚂蚁金服技术专家介绍，蚂蚁金服三地五中心异地多活解决方案是通过把物理数据中心划分为多个逻辑数据中心，并基于全局运维管理实现跨越多个数据中心的资源调度。逻辑数据中心分为分区业务单元、共享单元和全局单元，其中，业务单元部署按客户维度进行拆分，以此保证核心业务可以分布在不同的单元内同时处理。当故障发生时，可以进行单元之间快速切换。据悉，蚂蚁金服三地五中心异地多活解决方案率先实现了自主研发设计实施银行业去IOE架构下异地多活容灾体系，并达到银行业最高容灾等级标准要求和业内领先的灾难恢复能力等级。另外，该方案还可以打造无限可扩展的扩容能力及更稳定、更可靠、更高效的系统保障能力。技术能力已全面开放蚂蚁金服三地五中心异地多活解决方案是基于完全自主研发的SOFA金融分布式架构及OceanBase关系数据库。在该方案中，SOFA分布式架构能够承受高并发交易，并确保资金安全；同时，在系统扩展、容灾恢复、更新发布时做到数据无损，且服务持续可用。OceanBase分布式关系数据库具备数据强一致、高可用、高性能、在线扩展、高度兼容SQL标准和主流关系数据库、低成本等特点；可在低成本的通用硬件上，进行在线水平扩展，并创造了4200万次/秒处理峰值的纪录。在今年杭州云栖ATEC大会上，蚂蚁金服副CTO胡喜现场进行断网的演练，系统显示，仅在26秒后，运行在上面的支付宝虚拟账户便恢复了正常运转。这正是三地五中心异地多活解决方案进行自动切换，保证了支付服务的不中断。在近年来的双11大促中，三地五中心异地多活解决方案也经受了实战的考验，并为用户提供了丝般顺滑的购物体验。目前，包括三地五中心异地多活解决方案、OceanBase分布式关系数据库以及SOFA金融分布式架构都已经在蚂蚁金融科技官网（tech.antfin.com）对外开放。

摘要： 2018年12月20日，云栖社区3岁。阿里巴巴常说“晴天修屋顶”，所以我们特别制作了这个专辑——分享给开发者们20个阿里故事，50本书籍。2015年12月20日，云栖社区上线。2018年12月20日，云栖社区3岁。阿里巴巴常说“晴天修屋顶”。在我们看来，寒冬中，最值得投资的是学习，是增厚的知识储备。所以社区特别制作了这个专辑——分享给开发者们20个弥足珍贵的成长感悟，50本书单。多年以后，再回首2018-19年，留给我们自己的，除了寒冷，还有不断上升的技术能力与拼搏后的成就感。*12月21日，使命感与开放心态，是我们送给开发者的第2个感悟。德歌：公益是一辈子的事，I’m digoal, just do it德歌，江湖人称德哥。PG大神，在社区拥有6500+位粉丝。三年来，他沉淀在社区的博文超过2000+篇。还记得社区刚成立时，有位开发者在博文后留言“我一直认为PG是小众数据库，没想到社区有这么多干货。” 三年过去，PG的地位一直在上升，云栖社区PG钉群也已经超过1000位开发者在一起交流讨论。*周正中（德歌）PostgreSQL 中国社区发起人之一，PostgreSQL 象牙塔发起人之一，DBA+社群联合发起人之一，10余项数据库相关专利，现就职于阿里云数据库内核技术组。学习第一要有使命感，第二要有开放的心态。使命感是技术为业务服务，结合业务一起创造社会价值，有使命感才能让你坚持下去，遇到困难时不容易被打倒。开放是在扎实的技术功底之上，跳出纯粹的技术从生态进行思考，要埋头苦干也要抬头看路。比如行业生态中重叠部分，盟友与竞争关系，问题及补齐办法等，同时也要密切关注国家和国际形势，分析背后原因，在未来技术方向决策上避免逆流行舟。推荐的书单：《PostgreSQL实战》本文作者：云篆阅读原文本文为云栖社区原创内容，未经允许不得转载。

摘要： 由蓝军主导的技术攻防演练就是那个传说中的“疯起来连自己都打”的项目。如果一个技术团队不干别的，专门“搞破坏”，这是一种怎样的存在？这真的不是“天方夜谭”，在支付宝确实有这么一支队伍——技术蓝军。蓝军的任务就是不断地攻击和进攻，而防守方则是技术红军。在支付宝，蓝军从属于蚂蚁金服技术风险部（SRE），而红军则包括SRE及各业务部门的技术团队。说到SRE，就需要科普一下了。SRE全拼为Site Reliability Engineer，是软件工程师和系统管理员的结合，是一种要求极高的技术工种。据说，目前全球只有少数几家顶级互联网公司拥有真正意义上的SRE团队，蚂蚁金服是其中之一。由蓝军主导的技术攻防演练就是那个传说中的“疯起来连自己都打”的项目，今天，就来起底一下这个神秘的项目。从“青铜”到强者红蓝军技术攻防演练与蚂蚁金服技术风险部的发展息息相关，而蚂蚁技术风险的演进轨迹和游戏中的不断打怪升级非常相像。早期是质量+运维+架构师三角协同，各司其职并自发性的开展一些技术风险相关的工作。2013年，蚂蚁金服技术团队提出了质量2.0战略，以统一的规章、统一的流程和统一的阵型，开始体系化地沉淀故障检测等方面的平台化能力。大概一年后，也就是2014年，专门成立了技术质量部，从全域视角解决技术风险的问题。2015年，技术质量部正式升级成为技术风险部，专注研发及架构的技术风险问题，并完成相应解决方案和落地的平台。2016年，技术风险部再次升级为SRE团队。SRE团队组建后，就开始全面开展故障自动定位、自适应容灾、防抖、精细化高可用等工作。其中防抖这块，要保证任何的网络或基础设施抖动，用户都无感知；而精细化高可用，又叫单笔高可用，其颗粒度可以精准到用户的每一笔交易，远远优于行业内的机房级高可用。同时，那个热衷“找茬”的组织——技术蓝军也正式成立。这个专门的、拥有独立职能的团队不干别的，主要职责是挖掘系统的弱点并发起“真实”的攻击，红蓝军技术攻防演练也自此诞生。牛X的是，技术蓝军并不对各业务方负责，只对应用架构及防御系统的稳定性和可靠性负责。在蓝军眼中，故障的发生是必然的，只是时间早晚而已。蓝军只有想尽办法去触发这些故障，这样，在故障真实发生的时候，才有足够的应付能力。所以，蓝军发掘各类脆弱点，并通过红蓝军技术攻防演练，不断验证防御系统的可靠性。而故障防御系统及不断优化的高可用架构则是由SRE团队的红军与各业务深度合作，沉淀、构建出来的。现在，全栈级别的技术攻防演练每周都在进行，蓝军似乎对“疯起来连自己都打”很上瘾。利矛与坚盾不断升级持续不断的攻防演练，让蓝军和红军的技术能力得到了极大地提升，同时双方“武器库”也在不断升级。2017年秋天，蓝军团队在成立后的两个月内，自主研发了字节码级别的故障注入系统Awatch，这个武器的厉害之处在于可以实时地对运行中的业务系统进行任意链路的编织侵入。这对于对于技术蓝军以及整个红蓝攻防体系，具有里程碑式的意义。蓝军研发出了厉害的武器，红军也没闲着。与此同时，技术红军的防控体系建设也在如火如荼地进行着，实时核对平台横空而出。该平台能够做到稳定的分钟级核对异常发现能力，在某些场景下可以做到秒级发现，并且平台提供了业务快速接入的能力；红军还在实时核对平台的基础之上，升级演化出一套智能核对平台(内部代号四道防线)，引入AI技术自动识别业务问题，目前这套防线已经覆盖蚂蚁80%以上的业务。另外，各个业务域针对自身业务的一些特殊性，也研发了相应的核对系统。尽管蓝军制造故障的能力有很大的提高，但大部分的故障场景主要是各个业务方提供的，只有极少数是蓝军人工梳理业务或者分析代码产出。此时，蓝军团队认为，日常演练常态化，在故障场景发现方面不能再依赖业务，必须建立自主发现故障场景的能力。2018年3月，蓝军推出故障场景挖掘平台，基于Awatch探针探测应用内数据流，以此进行“弱点挖掘”。这套弱点挖掘体系，能够自动发现故障场景，最高能够在5分钟内产生500+的故障场景，红蓝攻防的日常演练的最为重要一块拼图终于完成！然而新的问题来了。蓝军的故障挖掘平台能力毋庸置疑，但有攻击就需要应急，高频攻防实施亦会给红军带来大量的人力消耗。持续应急压力驱动，红军开展““故障自愈”架构体系升级及能力建设，以效能为目标，结合仿真，红蓝军一起研发了“无损”攻防体系，并且推出与之匹配的度量平台，自动度量攻防结果，数据可视化。目前，常态红蓝技术对抗保持每周200+个故障场景的节奏在持续运作。常态化的红蓝 “互怼”在线、实时、随地、无差别……这是支付宝技术蓝军实施攻击行为的几大标签。2017年年底的红蓝技术攻防周，技术蓝军发起攻击，但由于故障组件一处隐藏bug导致故障命中数量远远大于预期，给红军增添了不少麻烦，业务线的技术同学投入大量的人力和资源进行善后。此情此景之下，红军方面不仅没有抱怨，反而给予蓝军鼓励，“这次预期外的故障攻击是最真实的应急锻炼！”2018年年中的一次红蓝技术攻防中，蓝军在周末发起突袭，而刚好红军的相关同学正在举办婚礼。于是，一群程序员赶紧拿出吃饭的家伙，噼里啪啦敲着键盘进行应急，那画面简直不要太美了。还是在2018年的一次对抗中，红军祭出了“尖端武器”——自适应防灾、防抖等，这让蓝军吃尽苦头，几乎每次攻击都无功而返。挫败感飙升的蓝军最终放出大招，让红军接受了非常猛烈的炮火洗礼。有意思的是，似乎蓝军攻击得越欢，红军的同学越高兴……虽然看上去很受虐，但却没毛病，因为蓝军攻击得越狠越深入，被挖掘和发现出来的技术风险就会越确定，防御系统的能力也会因此而得到提升。令人震惊的是，为了防止蓝军的“袭击”，红军除了在防御系统方面下十足的功夫，每年期中和期末的红蓝技术攻防演练，红军都要举办一个仪式——那就是拜关公，除了叩拜，还得给驱邪镇恶的关公献礼，礼品包括旺仔牛奶、格子衬衫、键盘、香烟等。风险防控技术全面开放蚂蚁金服技术风险部门经过不断地升级，并将红蓝技术攻防演练形成常态化。除了每周进行全栈级别的演练，每年还会举行规模极大的“期中考试”和“期末考试”。这意味着，支付宝的风险防控体系持续地经受打磨与锤炼。目前，支付宝的“红蓝对抗”演练已经沉淀出一整套成熟的风险防控体系，通过仿真环境模拟天灾人祸，去考验技术架构的健壮性及技术人员的应急能力，从而全面地提升系统稳定，实现系统的高可靠性和高可用性。所谓的天灾和人祸。天灾指的是，当出现台风、断网、火情等极端异常情况的时候，系统如何快速应对。这有点类似于今年杭州云栖ATEC大会上，蚂蚁金服副CTO胡喜现场演练的异常断网情况下，“三地五中心”自动切换，保证支付服务不中断。人祸则是指因技术人员操作失误引发故障后，系统如何快速应。在蚂蚁金融科技官网（https://tech.antfin.com/）上可以看到，这些技术风险相关的能力已经对外开放，目前共有3款产品，包括容灾应急平台、全链路压测和资金安全监控；另外，还有3款产品，变更管控、巡检平台和黑屏运维管控即将上线对外开放。本文作者：华蒙阅读原文本文为云栖社区原创内容，未经允许不得转载。

摘要： 红军 VS 蓝军，谁是更强者？小蚂蚁说：自古红蓝出CP，在蚂蚁金服就有这样两支“相爱相杀”的队伍——红军和蓝军。蓝军是进攻方，主要职责是挖掘系统的弱点并发起“真实”的攻击，俗称“找茬”；红军则是防守方，其防控体系建设中的实时核对平台能够做到稳定的分钟级核对异常发现能力，并提供业务快速接入的能力。支付宝“疯起来连自己都打”的项目就是红蓝军技术攻防演练，他们不仅每周进行全栈级别的演练，每年还会举行规模极大的“期中考试”和“期末考试”。接下来就跟着小蚂蚁一起去看看这对红蓝cp的日常“互怼”生活吧！如果一个技术团队不干别的，专门“搞破坏”，这是一种怎样的存在？这真的不是“天方夜谭”，在支付宝确实有这么一支队伍——技术蓝军。蓝军的任务就是不断地攻击和进攻，而防守方则是技术红军。在支付宝，蓝军从属于蚂蚁金服技术风险部（SRE），而红军则包括SRE及各业务部门的技术团队。说到SRE，就需要科普一下了。SRE全拼为Site Reliability Engineer，是软件工程师和系统管理员的结合，是一种要求极高的技术工种。据说，目前全球只有少数几家顶级互联网公司拥有真正意义上的SRE团队，蚂蚁金服是其中之一。由蓝军主导的技术攻防演练就是那个传说中的“疯起来连自己都打”的项目，今天，就来起底一下这个神秘的项目。从“青铜”到强者红蓝军技术攻防演练与蚂蚁金服技术风险部的发展息息相关，而蚂蚁技术风险的演进轨迹和游戏中的不断打怪升级非常相像。早期是质量+运维+架构师三角协同，各司其职并自发性的开展一些技术风险相关的工作。2013年，蚂蚁金服技术团队提出了质量2.0战略，以统一的规章、统一的流程和统一的阵型，开始体系化地沉淀故障检测等方面的平台化能力。大概一年后，也就是2014年，专门成立了技术质量部，从全域视角解决技术风险的问题。2015年，技术质量部正式升级成为技术风险部，专注研发及架构的技术风险问题，并完成相应解决方案和落地的平台。2016年，技术风险部再次升级为SRE团队。SRE团队组建后，就开始全面开展故障自动定位、自适应容灾、防抖、精细化高可用等工作。其中防抖这块，要保证任何的网络或基础设施抖动，用户都无感知；而精细化高可用，又叫单笔高可用，其颗粒度可以精准到用户的每一笔交易，远远优于行业内的机房级高可用。同时，那个热衷“找茬”的组织——技术蓝军也正式成立。这个专门的、拥有独立职能的团队不干别的，主要职责是挖掘系统的弱点并发起“真实”的攻击，红蓝军技术攻防演练也自此诞生。牛X的是，技术蓝军并不对各业务方负责，只对应用架构及防御系统的稳定性和可靠性负责。在蓝军眼中，故障的发生是必然的，只是时间早晚而已。蓝军只有想尽办法去触发这些故障，这样，在故障真实发生的时候，才有足够的应付能力。所以，蓝军发掘各类脆弱点，并通过红蓝军技术攻防演练，不断验证防御系统的可靠性。而故障防御系统及不断优化的高可用架构则是由SRE团队的红军与各业务深度合作，沉淀、构建出来的。现在，全栈级别的技术攻防演练每周都在进行，蓝军似乎对“疯起来连自己都打”很上瘾。利矛与坚盾不断升级持续不断的攻防演练，让蓝军和红军的技术能力得到了极大地提升，同时双方“武器库”也在不断升级。2017年秋天，蓝军团队在成立后的两个月内，自主研发了字节码级别的故障注入系统Awatch，这个武器的厉害之处在于可以实时地对运行中的业务系统进行任意链路的编织侵入。这对于对于技术蓝军以及整个红蓝攻防体系，具有里程碑式的意义。蓝军研发出了厉害的武器，红军也没闲着。与此同时，技术红军的防控体系建设也在如火如荼地进行着，实时核对平台横空而出。该平台能够做到稳定的分钟级核对异常发现能力，在某些场景下可以做到秒级发现，并且平台提供了业务快速接入的能力；红军还在实时核对平台的基础之上，升级演化出一套智能核对平台(内部代号四道防线)，引入AI技术自动识别业务问题，目前这套防线已经覆盖蚂蚁80%以上的业务。另外，各个业务域针对自身业务的一些特殊性，也研发了相应的核对系统。尽管蓝军制造故障的能力有很大的提高，但大部分的故障场景主要是各个业务方提供的，只有极少数是蓝军人工梳理业务或者分析代码产出。此时，蓝军团队认为，日常演练常态化，在故障场景发现方面不能再依赖业务，必须建立自主发现故障场景的能力。2018年3月，蓝军推出故障场景挖掘平台，基于Awatch探针探测应用内数据流，以此进行“弱点挖掘”。这套弱点挖掘体系，能够自动发现故障场景，最高能够在5分钟内产生500+的故障场景，红蓝攻防的日常演练的最为重要一块拼图终于完成！然而新的问题来了。蓝军的故障挖掘平台能力毋庸置疑，但有攻击就需要应急，高频攻防实施亦会给红军带来大量的人力消耗。持续应急压力驱动，红军开展““故障自愈”架构体系升级及能力建设，以效能为目标，结合仿真，红蓝军一起研发了“无损”攻防体系，并且推出与之匹配的度量平台，自动度量攻防结果，数据可视化。目前，常态红蓝技术对抗保持每周200+个故障场景的节奏在持续运作。常态化的红蓝“互怼”在线、实时、随地、无差别……这是支付宝技术蓝军实施攻击行为的几大标签。2017年年底的红蓝技术攻防周，技术蓝军发起攻击，但由于故障组件一处隐藏bug导致故障命中数量远远大于预期，给红军增添了不少麻烦，业务线的技术同学投入大量的人力和资源进行善后。此情此景之下，红军方面不仅没有抱怨，反而给予蓝军鼓励，“这次预期外的故障攻击是最真实的应急锻炼！”2018年年中的一次红蓝技术攻防中，蓝军在周末发起突袭，而刚好红军的相关同学正在举办婚礼。于是，一群程序员赶紧拿出吃饭的家伙，噼里啪啦敲着键盘进行应急，那画面简直不要太美了。还是在2018年的一次对抗中，红军祭出了“尖端武器”——自适应防灾、防抖等，这让蓝军吃尽苦头，几乎每次攻击都无功而返。挫败感飙升的蓝军最终放出大招，让红军接受了非常猛烈的炮火洗礼。有意思的是，似乎蓝军攻击得越欢，红军的同学越高兴……虽然看上去很受虐，但却没毛病，因为蓝军攻击得越狠越深入，被挖掘和发现出来的技术风险就会越确定，防御系统的能力也会因此而得到提升。令人震惊的是，为了防止蓝军的“袭击”，红军除了在防御系统方面下十足的功夫，每年期中和期末的红蓝技术攻防演练，红军都要举办一个仪式——那就是拜关公，除了叩拜，还得给驱邪镇恶的关公献礼，礼品包括旺仔牛奶、格子衬衫、键盘、香烟等。风险防控技术全面开放蚂蚁金服技术风险部门经过不断地升级，并将红蓝技术攻防演练形成常态化。除了每周进行全栈级别的演练，每年还会举行规模极大的“期中考试”和“期末考试”。这意味着，支付宝的风险防控体系持续地经受打磨与锤炼。目前，支付宝的“红蓝对抗”演练已经沉淀出一整套成熟的风险防控体系，通过仿真环境模拟天灾人祸，去考验技术架构的健壮性及技术人员的应急能力，从而全面地提升系统稳定，实现系统的高可靠性和高可用性。所谓的天灾和人祸。天灾指的是，当出现台风、断网、火情等极端异常情况的时候，系统如何快速应对。这有点类似于今年杭州云栖ATEC大会上，蚂蚁金服副CTO胡喜现场演练的异常断网情况下，“三地五中心”自动切换，保证支付服务不中断。人祸则是指因技术人员操作失误引发故障后，系统如何快速应。在蚂蚁金融科技官网（https://tech.antfin.com/）上可以看到，这些技术风险相关的能力已经对外开放，目前共有3款产品，包括容灾应急平台、全链路压测和资金安全监控；另外，还有3款产品，变更管控、巡检平台和黑屏运维管控即将上线对外开放。本文作者：平生栗子阅读原文本文为云栖社区原创内容，未经允许不得转载。

摘要： 阿里基础设施负责人毕玄结合自己的经历跟大家讲述了他在各个角色上成长的感受，值得所有正为职业发展而迷茫的技术同学细细品味。【编者按】2018年12月20日，云栖社区3周岁生日。阿里巴巴常说“晴天修屋顶”，所以我们特别策划了这个专辑——分享给开发者们20个阿里故事，50本书籍。第一位是林昊（毕玄）。在这篇《程序员的成长路线》里，阿里基础设施负责人毕玄结合自己的经历跟大家讲述了他在各个角色上成长的感受。在他的职业经历中，在成长方面经历了技术能力的成长、架构能力的成长，以及现在作为一个在修炼中的技术 Leader 的成长。其中技术能力和架构能力的成长是所有程序员都很需要的，值得所有正为职业发展而迷茫的技术同学细细品味。技术能力成长我大学读的是生物系，缺少了专业的训练，这个使得我在技术能力上其实欠缺的更多。回头想想，在工作的前5年，更多的都是在拓宽技术面，刚毕业的时候只会 ASP，工作前两年学会了 VB、Delphi这些神器，到工作的第三、四年比较专注的做了工作流领域。技术能力的成长主要还是在 2007 年加入阿里以后，在加入阿里前，我是一个连日均访问量 1万 PV 都没见过的人，到了阿里后，做的第一件事竟然就是写 HSF，并且在客服的 CRM 系统上线，访问量大概是每天上百万的服务调用，无知者无畏，当时也就那么上线了，更神奇的是竟然没出现什么问题，于是继续把HSF上线到当时的交易中心，当时交易中心每天的服务调用量大概是亿级，结果上线当天就回滚了，而且还不知道到底是什么原因，这次的回滚是对我触动最大的一次（当然，触动大也有可能是后面要是解决不了，就该从淘宝滚蛋了）。回滚后开始仔细查问题，最后发现是当时 HSF 所使用的 jboss-remoting 默认的超时参数 60s 的问题，自从这个问题后，才明白要支撑好到了一定量级的系统，最重要的是对整个技术栈的精通，否则出问题都不知道该怎么解决或临时查，于是才开始仔细学习 Java 的 BIO/NIO，Mina，反射，并发编程等，尽管这些东西很多在加入阿里前也看过一些书、资料学过，但到了这个时候才发现自己其实不怎么懂，那段时间密集的开始更细致的看书，翻看用到的 Mina、甚至是 Java 的各种 API 背后的源码，是自己的 Java 技能提升最快的一段时间，在回滚的两个月后，基于 Mina 完全重写了 HSF，再次上线终于一切顺利。在那之后，随着 HSF 应用的场景越来越多，以及加上后来自己在淘宝消防队查比较多的问题，Java 方面的技能也得到了不少成长，而同时也发现了很多的 Java 问题还得对 JVM、操作系统层面有一定掌握才行，尤其是 JVM，于是当时和还在阿里的撒迦经常一起周末跑到公司来结对看 JVM 代码，:)。在撒迦的帮助下对 JVM 的掌握终于也越来越好，那段时光会让自己明白很多东西只有看了代码，并且有相应的使用机会才能真正的掌握。在 HSF 之后，去做 HBase，学习了很多在存储方面的技能，这也是我之前完全不懂的领域，在HBase之后，开始做第一代容器产品 T4（寓意是第四代淘宝技术），进入彻底不懂的领域，虚拟化、Cgroup 等等都是那个时候才开始学习，但因为没详细研究过代码，并自己去做改造，其实到今天也就是点皮毛而已。对于程序员而言，技术能力的成长显然是最重要的（程序员行当里最赞的一句就是：Talk is cheap, show me the code!），我自己其实很多都属于被逼的成长，当然这样通常反而也是最快的，很多同学会觉得自己没碰到这样的机会，所以成长就比较慢，我会非常建议的是可以尝试自己去创造一些场景（当然，如果本来就是工作需要就更好了），来学相应的技术能力（例如学 Java 的通讯框架，可以尝试自己基于 BIO/NIO 写一个，然后对比 Mina/Netty 这些成熟的，看看为什么写的不太一样，又例如学 Java 的内存管理，可以尝试自己写程序去控制 GC 的行为，例如先来一次 ygc，再来两次 fgc，再来 5 次 ygc，再来一次 fgc之类的，学的时候除了一些入门的书外，我非常建议去翻看源码，最后你会发现所有的书都不如源码），这样才能真正的理解和学会，否则其实很容易忘。架构能力成长说起架构，在我刚工作的第三年负责工作流系统的时候也做过，但直到后来在阿里做 T4、异地多活，我才有了真正更强烈的感受，对架构师也有更深的一些理解。架构呢，我现在的理解基本是一个结构图，当然有不同视角的结构，但这个图里的部分呢是多个团队来做的，甚至是跨多个专业的团队。在做 T4 的时候，由于 T4 涉及到了标准的一个 Java WebConsole，一堆的运维体系，容器技术等，这是一个至少要跨三个团队的结构，无论是从研发视角还是部署视角都是如此，因此作为 T4 的架构师，怎么设计好整个的结构，各自的边界、接口是我当时最大的感受，让跨专业的多个团队能更好的协作，在这个阶段中最重要的要考虑的是怎么根据整个项目的优先级来调整每个部分，以及作为一个不是全懂的架构师怎么更好的确保结果，我自己的感受是 T4 让我学会了从一个只做自己专业系统的架构师成长为了能做跨专业的系统的架构师。在做异地多活的时候，感受就更加强烈，因为这个跨的专业数、整个参与的人数完全是上升到了一个非常大的程度，各个专业、系统的人都需要看整个架构才能知道自己应该做什么，扮演的角色，在做异地多活整个项目过程中，作为总的架构师，我自己感觉的是最重要的职责是怎么控制项目的风险，或者说作为架构师，你觉得一个项目中最重要的要掌控住的是，并且从架构上怎么设计这个部分，这也是后来我在问很多架构师时最喜欢问的问题，一份架构文档不是说按照模板写就可以（很多的架构设计文档都是千篇一律，通常看到的都是什么都考虑，但从架构设计上并没体现这些考虑的地方是怎么做的），而是要根据实际的项目/产品情况来突出重点，确保最重要的几个问题是从架构设计上就去掌控的，尤其是跨多个专业团队的大型项目，这种项目准确的说是大架构师带着一堆的专业领域的架构师来做的，例如异地多活项目从架构设计上来说除了正常的结构、边界以外，最重要的是数据正确性的设计，我自己最强的感受就是异地多活才让我明白了一个大型系统的架构师是怎么样的。所以就我自己的感受而言，架构师对知识的宽要求非常广，并且要能非常好的进行抽象，来做结构、边界的设计，分析出当前阶段系统的重点，并从架构层面做好设计来确保重点的实现，这个相对技术能力的成长而言我觉得更需要机会，但同样在机会前需要有足够的积累（例如写一个系统的时候，是不是主动的去了解过上下游的系统设计，是不是了解过具体的部署结构，对相应的知识点有没有简单的了解等，我自己在做 T4 前，LVS、机房/网络结构等完全搞不懂是怎么回事）。技术Leader修炼技术 Leader 我比较倾向于有前面两步积累的同学，技术 Leader 非常重要的一点是对技术趋势的感知和判断能力，这其实是个非常综合的能力，一到两个领域的技术深度，大的架构能力，对技术历程的理解、技术发展的思考能力，作为技术 Leader 是很需要的，然后是其他的一些作为 Leader 方面的比较综合的一些能力（例如组织搭建、建设方面的能力等，不过这些能力呢通常对技术的人来说确实会欠缺的更多一些），这个我自己还在修炼和学习中，就不讲太多了。总结总结来说呢，我认为程序员可发展的路线还是很多的，上面写的这三条其实都是可发展的路线，没有孰优孰劣，谁高一等之类的，兴趣、个人优势仍然是最重要的。*作为《OSGi原理与最佳实践》和《分布式Java应用：基础与实践》的作者，毕玄推荐了他的书单给到我们：《硅谷之谜》《智能时代：大数据与智能革命重新定义未来》本文作者：云篆阅读原文本文为云栖社区原创内容，未经允许不得转载。 ...

笔者注：本文是在2018年11月15日由Linux基金会CNCF主办的KubeCon & CloudNativeCon China 2018大会的“Running Blockchain as a Service (BaaS) on Kubernetes”演讲内容基础上整理而成，从技术上介绍了阿里云如何将基于区块链Hyperledger Fabric的BaaS和容器集群技术Kubernetes进行结合的设计理念和实践经验分享。大家好！我是来自于阿里云区块链团队的余珊，今天给大家分享的是《在Kubernetes上运行区块链服务（BaaS）》这个主题。以上是今天分享的内容大纲，其中重点在第三部分，我们将对BaaS结合Kubernetes的一些典型问题进行深入探讨。首先我们分享一下在我们眼中的区块链和BaaS的定义是什么。从狭义上来说，区块链是一种分布式共享账本技术，基于智能合约，在各参与方之间达成对交易的共识，并实现账本交易历史的不可篡改。这个定义是大家所熟知的，并且是从技术和功能上进行的概括。而从广义上来说，我们认为，区块链也是一种在机构、个人、机器之间，构建分布式信任网络、连接可信数据、实现价值流动的新的架构和协作模式。这也是跳出技术和功能维度，从更高维度去进行的理解和总结。对于另一个概念"BaaS"，即"Blockchain as a Service", 我们认为，是云平台之上的区块链平台服务，提供了区块链系统的部署、运维、治理能力，以及提供了区块链应用运行和管理的能力。区块链从其类型上可分为私有链、公有链、联盟链三种类型，而从系统拓扑上我们可以将其对应为下述三种模式。对于传统的中心化系统或私有链来说，它基本属于一种星型中心化系统。对于公有链来说，是一种将所有参与企业和个人都对等连接在一起的完全去中心化系统。而对于联盟链来说，是一种带分层结构的多中心化系统。而阿里云今天主要关注的是面向企业场景的联盟链技术类型。下面我们来探讨一下为什么将区块链与容器技术以及Kubernetes进行结合。首先，我们来分析一下区块链的特点。我们将其分为区块链系统和区块链业务应用两类。区块链系统是以数据为核心、高度分布式、Full-Mesh网络拓扑、Long-Running、复杂系统类型。数据为核心：其中最重要的是账本上的数据。高度分布式：因为区块链节点可能部署于不同机房、不同region、不同国家等等。Full-Mesh: 区块链节点之间要依赖全连通的网络以实现共识、账本同步等过程。Long-Running：区块链服务和节点是长时间运行，而不是像Web应用或批处理任务那样短生命周期的。复杂系统类型：区块链系统不是一两个模块构成的简单应用，而是往往一整天解决方案或系统的形式。区块链业务应用：没有统一的标准，可能包含各种应用类型，包括无状态应用、有状态应用、Web应用、数据型应用等等类型。接下来，我们分析一下区块链结合容器技术会带来哪些优势：容器技术为区块链系统和业务应用提供了标准化的软件打包、分发的能力。容器技术实现了区块链运行环境的一致性，以及与底层基础架构的解耦，使得区块链系统和业务应用可以很方便地移植和运行在各种平台之上。进一步的，我们发现，区块链使用Kubernetes集群技术可获得以下几方面的优势：Kubernetes提供了灵活的区块链所需要的底层资源的调度能力，如计算、存储、网络等。Kubernetes强大的运维管理能力，使得我们的区块链服务的产品上线速度以及运维的效率大大提升。Kubernetes支持各种应用类型以及微服务架构，因此对于上面区块链系统和区块链业务应用各自的需求都能很好地满足。使用Kubernetes，可以更好地跟云平台进行集成，因为今天在业界它已经成为了各大云厂商云原生应用的标准底座了。Kubernetes还提供了丰富的安全和隔离功能，这对我们区块链的安全防护体系是很大的增强。另外，围绕Kubernetes有着非常活跃的社区和丰富的技术和业务生态，因此为结合区块链的研发提供了强大的技术支持和资源。这里解答图中的一个疑问，微服务架构是否适合区块链，这要结合上面的区块链特点分析来看待：对区块链系统来说，内部组件之间是强耦合、强依赖的关系，比较难解耦，内部各组件本身不是通用化的服务定位，也不是REST化服务接口，更多是例如gRPC调用，因此不是太适合微服务架构。但是对区块链业务应用来说，则很适合考虑与微服务架构进行结合。上面这幅图展示了阿里云区块链产品形态的演进历史，同时也可以看出我们在区块链结合容器以及Kubernetes方面所在的工作。在2017年10月，我们开始提供基于容器服务的区块链解决方案，支持Hyperledger Fabric，为企业提供一键式的区块链自动部署能力，当时是基于Docker Swarm集群技术。紧接着在2017年12月，我们推出了支持Kubernetes的容器服务区块链解决方案，并且在业界也是较早开始使用Helm Chart部署区块链的。在今年7月底，我们正式推出了阿里云区块链服务BaaS，支持Hyperledger Fabric，同样也是基于Kubernetes。而在今年9月杭州云栖大会上，阿里云BaaS也正式支持了蚂蚁区块链，在这背后蚂蚁区块链也通过适配改造工作实现了在Kubernetes上的部署运行。这一页展示的是阿里云BaaS的产品架构大图。其中最核心的是BaaS，目前已经支持Hyperledger Fabric和蚂蚁区块链。它们的运行实例底座都是基于阿里云容器服务Kubernetes集群。今天的演讲内容主要是围绕Hyperledger Fabric跟Kubernetes结合这方面展开讨论的。上面这一页展示了阿里云容器服务Kubernetes版的产品架构图。这里我们展示了一套跨region的Hyperledger Fabric联盟链的部署架构图。在联盟管理方的Kubernetes集群上部署了Orderer organization和Peer Organization, 而在其他业务参与方所在region的Kubernetes上部署了各自的Peer Organization. 这里的CA、Peer、Orderer、Kafka、ZooKeeper的每个实例都是用了Kubernetes的Service和Deployment类型对象来定义。此外区块链的业务应用可以部署在Kubernetes上或者其他环境上，通过SLB映射到集群worker节点的NodePort上，来访问区块链的各个service。接下来我们进入重点的第三部分，对于实现BaaS运行在Kubernetes的过程，我们曾经遇到的一些有代表性的问题，以及我们的解决思路和实践经验。首先是关于区块链BaaS的打包、发布、服务编排等方面的问题。对于以Hyperledger Fabric为代表的区块链系统来说，这方面面临的主要问题是：区块链系统本身较为复杂，在一套典型部署里可能涉及到三十多个容器、近二十个服务、十来个容器镜像；而且这些服务相互之间有较强的依赖。对于这个问题，我们的解决思路是：在打包部署方面，从一开始我们便选用了容器镜像以及Kuberentes的Helm Chart作为标准的格式和工具。这里尤其提一下，为了保证联盟链各组织创建的独立性和灵活性，我们采用的是一类组织（例如Orderer Org或Peer Org）使用一套chart的方式。在存储库管理方面，目前使用的是阿里云OSS作为Chart Repo（当然可以使用功能更丰富的如ChartMuseum等工具），使用阿里云容器镜像服务作为镜像仓库。这里我们还采用了region化的镜像仓库配置，加快大体积镜像的下载速度，同时采用imagePullSecret保护镜像的安全。在配置方式方面，我们采用了Kubernetes的ConfigMap和Secrets来存储主要的配置和安全信息，以及使用Chart Values来让管控可以根据客户的输入去定制BaaS联盟链实例。在服务编排方面，为了满足服务的依赖性需求，我们结合了Chart Template，Chart的Hook（钩子）机制，以及Kubernetes的Init Container加上Shell脚本方式，实现各种服务尤其在启动过程中的依赖和顺序保证。对于企业来说，业务系统的高可用性是非常重要的，尤其是对生产环境的系统运行和应用访问。这里我们分享一下在BaaS的每一个层面上的高可用设计思路，以及Kubernetes在其中起到怎样的帮助。首先在云基础架构和云资源服务层，我们通过云数据中心的多可用区、所依赖的云服务本身的高可用性和高可靠性来提供保障。在BaaS管控层，通过管控组件的多实例化部署避免单点故障。在容器服务的Kubernetes集群，采用3个master节点和多个worker节点的方式提供应用底座的高可用。在Hyperledger Fabric这一层，它的Orderer、Peer、Kafka、ZooKeeper、CA等类型节点均有集群或高可用互备的设计，比如任一节点挂掉的话，其他节点依然能正常提供服务。但这里有一个关键的点，就是在Kubernetes集群上部署的时候，为了避免这些本应高可用互备的Fabric节点的pod被调度到同一个worker node上，我们采用了Kubernetes Pod Anti-Affinity的功能区将高可用集群的pod调度到不同的worker上，这样保证了真正高可用的部署，提高了对故障的容忍度。在区块链业务应用层，则需要各个企业客户对应用进行周全的高可用设计和实现。在运行时，应用访问Fabric各个服务的这一环节，我们BaaS内置了云平台的SLB负载均衡能力（包含对服务端口的健康检查），以及Fabric的Service Discovery，来保证即使后端部分节点或服务不可用时，应用的调用链路都会被调度到可用的节点或服务上。下面我们谈谈BaaS数据持久化存储的问题。虽然上面已经介绍了BaaS的高可用性设计，但我们仍需考虑如何将链上账本数据、区块链关键配置等重要内容持久化保存到可靠的外部存储而不是容器内部，这样便可以在服务器节点全部发生故障，或者系统重启、备份恢复等场合依然可以实现对系统和数据的恢复。首先，作为背景，我们分析了如果使用本地盘方式可能存在的问题：Kubernetes本身对pod的调度默认并没有限定worker节点，因此如果使用本地盘，就会因为在重启或恢复过程中调度导致的pod漂移而无法读取原来worker节点上的本地盘。对于第一个问题，Kubernetes提供了NodeSelector的机制可以让pod可以绑定worker节点进行部署，不会调度到其他worker节点上，这样就可以保证能始终访问到一个本地盘。但这又带来另一个问题，即在容灾的场景，如果这个节点包括其本地盘受到损坏无法恢复时，会导致整个pod也无法恢复。因此，我们在设计BaaS中的选择是阿里云的NAS文件系统存储、以及阿里云的云盘。在数据可靠性方面，NAS和云盘可以分别提供99.999999999%和99.9999999%的数据可靠性。此外，我们都选用了SSD类型以保证I/O性能。在Kubernetes部署的时候，Fabric的节点通过Persistent Volume和Persistent Volume Claim挂载上相应的存储，并且这些存储是为每一个Fabric的业务organization独立分配的，保证了业务数据的隔离性。在和参加KubeCon大会的一些区块链用户交流的时候，有朋友提到随着账本数据的持续增长，可以怎样解决存储问题。在我们的实践中，我们发现阿里云的NAS有一些很适合区块链账本存储的一些特点：首先，阿里云NAS可提供存储容量动态无缝扩容，在这过程中Fabric节点或区块链业务应用均无需重启或停机，对存储扩容过程完全无感知。其次，有用户担心随着存储数据量的增大，存储的性能是否会明显下降。恰恰相反的是，在阿里云NAS随着所使用的数据量变得越大，NAS所提供的吞吐性能会变得更高，这样可以打消企业用户在长期生产运行方面的顾虑。在上图的右边是Fabric不同类型的区块链节点使用不同类型存储的一个示意图。接下来我们探讨一下在设计搭建BaaS联盟链跨企业的网络方面遇到的挑战。对于大多数区块链技术而言，包括Hyerpedger Fabric, 在网络上要求区块链节点之间形成Full Mesh全连通网络，以实现节点间的账本数据同步、区块广播、节点发现、交易背书等过程，同时企业也要求保障跨企业链路的安全性。对于这些需求，我们梳理了业界目前常见的几类解决方案如下，并进一步分析它们存在的一些不足之处。方案一是采用单一VPC的联盟链网络方案，在这种模式下，联盟链的所有区块链节点均被部署到一套Kubernetes集群网络或VPC内。这种方案实质上是一种私有链的模式，失去了联盟链的各方自治的价值。方案二是基于公网的联盟链网络方案，区块链节点分布式部署在不同区域，通过公网IP对外提供服务以及实现互相通信。这种方案可以较灵活、较低成本低满足大多数基本需求，但对于高级需求如企业级安全网络则不能很好地满足。方案三是基于专线互联的联盟链网络方案，它采用运营商专线方式将不同网络或数据中心进行两两互联，在业界一些企业中得到了采用。但这里面主要存在两方面的问题，首先是如果联盟链参与企业采用了不同电信运营商的专线方案的话，项目实施的复杂性和成本都会很高；其次，如果几家企业已经建好了这样一个联盟网络，对于新来的参与企业，它的接入复杂度和成本也是一个不小的问题。针对上述各种问题，我们在阿里云BaaS基础之上，结合了CEN云企业网，提供了一种安全的联盟链网络方案，主要面向高端需求的企业用户。方案的核心，是采用CEN云企业网打通不同企业的VPC网络，就像一张跨企业的环网，这样不同企业不同的VPC内的网络就可以在CEN内实现全连通。在实现网络连通之后，因为阿里云BaaS联盟链中的Peer，Orderer，CA等服务是通过域名来访问的，目的是提升应用访问的灵活性，而在CEN的这套方案中，我们可以结合云解析PrivateZone，来实现企业环网内各企业VPC之间的统一域名解析。而且上述的网络连通性和域名解析仅限于联盟内部，不会暴露到外网。除了在公共云环境之外，对于那些将区块链节点部署于本地IDC的企业来说，他们也可以通过VPN或者专线方式，接入到云上已和CEN打通的任一VPC中，便可实现和联盟任意节点的通信。作为一个小提醒，在方案实施环节，需要注意提前规划好不同VPC内的内网地址分配，避免在环网中发生冲突。这样我们便形成了一套真正跨企业、跨账户，打通各个VPC的安全联盟链网络方案。下面我们将探讨一个非常有挑战性的问题。众所周知，智能合约是区块链的一个核心。Hyperledger Fabric中的智能合约即chaincode是运行于容器当中。在上面这幅图里我们总结了Hyperledger Fabric的chaincode容器生成过程的示意图：Peer通过Docker Client发起对Docker Daemon的调用，以fabric-ccenv为基础镜像创建出一个chaincode构建容器（chaincode builder container）Peer将chaincode源代码传入chaincode构建容器，在里面完成智能合约编译Peer再调用Docker Daemon创建以fabric-baseos为基础镜像的chaincode镜像，并将在第2步编译好的chaincode二进制文件内置在chaincode镜像中。启动运行chaincode容器。从上述过程我们分析一下这里面存在的一些问题：由于该过程是独立于Kubernetes体系之外运行的，难以对chaincode容器进行生命周期管理。无法基于Kubernetes的namaspace隔离、NetworkPolicy等机制实现对chaincode容器的安全管理。针对上面分析发现的问题，我们研究了几种问题解决的思路。第一种思路，是将chaincode容器纳入到Kubernete的体系（如pod）进行管理。这在我们的角度看来，其实是最理想的方案。因为它不仅可以实现chaincode容器全生命周期与Fabric其他类型节点一致的管理方式，并且可以结合Kubernetes的NetowrkPolicy控制chaincode容器的网络访问策略。其实此前Hyperledger Fabric社区已经创建了一个相关的需求即JIRA（FAB-7406），但目前仍未实现。假设未来在此功能实现之后，我们进一步展望一下，还可以将智能合约的容器调度运行于Serverless Kubernetes之上，提供kernal级别的隔离，保证应用容器之间的安全隔离。第二种思路，如社区和网上的一些观点所提到的，将chaincode容器放入Docker-in-Docker（DIND）环境运行。这个思路背后的出发点，主要是为了降低对宿主机Docker Daemon的依赖以及动态生成chaincode镜像和容器的不可管理性。对于这个思路，我们也基于Hyperledger Fabric和Kubernetes进行了试验，在右边的这部分Kubernetes部署模板yaml代码里，绿色框的部分是用于配置DIND的容器作为peer pod的一个sidecar，同时将DIND容器内的Docker Daemon通过本地端口2375以环境变量的形式配置到peer的参数中，使得peer可以将chaincode创建相关请求发送到DIND内。通过对结果的观察和分析，我们发现了以下这几点。DIND的思路有如下一些优点：无需依赖宿主节点的/var/run/docker.sock。无需专门清理每个Kubernetes worker节点的chaincode镜像。但DIND有着一些更为明显的不足：每次创建部署或恢复peer节点会变得很慢，因为DIND内需要去拉取fabric-ccenv镜像，其大小约1.4GB；而如果用传统部署方式的话，只需在worker节点拉取一次镜像即可。Chaincode的实例化（instantiate）过程稍微变慢，推测这和DIND容器本身运行所需的开销有一定关系。当peer节点或者整个组织（organization）删掉重建之后（复用原有的数据目录），启动速度比起传统方式会慢很多，这背后的原因和第1点相同。在业界实践中，DIND方法主要用于CI/CD的场景，但对于生产环境使用的话，则在稳定性等方面仍有较多的挑战。DIND的思路仍然不能解决chaincode容器的安全访问控制和隔离的问题。第三种思路，是我们目前在BaaS中采用的方法，即综合各种配置的手段先解决最主要的问题。这包括以下几个方面的工作：首先，通过Fabric peer的合理配置（如图中右上角的示例配置）保证chaincode和peer的通信。其次，使用docker rm和docker rmi命令清理chaincode容器和镜像（它们均包含“dev-”前缀）。这里面有不同的可选位置。2.1 适合事后清理的可选位置是采用DaemonSet结合lifecycle.preStop.exec.command的位置来运行这些清理命令。2.2 适合事前清理的可选位置是在initContainer中运行上述清理命令。采用iptables规则，对chaincode容器进行网络隔离。主要是通过在Helm Chart安装阶段配置Kubernetes worker节点的iptables规则，实现限制chaincode容器对Kubernetes网络和对外部网络的访问（同时也可以限制进入chaincode容器的网络访问）。通过上述一系列手段，我们得到了对chaincode容器实现生命周期管理、安全隔离和网络访问限制的一个实用的方案。未来我们也会继续朝着思路一这种最理想方式进行更多的探索。今天阿里巴巴集团的区块链已经在多个行业、多种场景实现了结合以及业务落地，包含了如商品溯源、数字内容版权、供应链金融、数据资产共享、公益慈善、医疗处方等等。我们的客户在生产环境已经达到了百万级的交易规模以及百GB的账本数据，这也为我们提供了很丰富的区块链应用实践经验。基于这些实践，我们想跟大家分享的是，其实区块链应用设计开发并不复杂，这一页总结了构建于Kubernete之上的区块链系统和应用的基本模式。可以看到，Kubernetes帮我们解决了底层基础架构和资源的复杂性，提供了应用的标准底座；而区块链服务BaaS则帮我们解决了区块链系统配置部署和运维的复杂性，提供了统一的接口，那么对企业来说，便可以聚焦在业务流程和业务逻辑的实现，及业务应用的开发上，以及与业务数据的交互和管理上来，实现核心价值的最大化。下面，我们将进行阿里云BaaS Hyperledger Fabric的一个demo，主要展示一下几方面的过程：首先，快速创建跨企业（跨账号）、跨region的联盟链。接着，动态添加新组织、新通道，完成企业间协同，包括邀请企业，以及企业各自的审批流程。在一些关键操作点上，BaaS内置了风控保障，强制邀请短信验证才允许完成操作，这看似麻烦的环节实际上是企业对生产安全保障以及审计都非常看重和需要的。最后，我们在BaaS上部署了经典的Marbles虚拟数字资产交易的应用，包含chaincode的部署和client SDK应用的部署。最后，欢迎有兴趣的朋友进一步了解和使用阿里云的区块链服务BaaS，通过扫描图中的两个二维码可快速访问相关产品主页，申请开通免费公测试用，以及访问产品文档获得更多使用和开发指南。以上就是我今天跟大家分享的全部内容，谢谢大家！本文作者：余珊阅读原文本文为云栖社区原创内容，未经允许不得转载。 ...

摘要： 本文将为你介绍为何要重用神经网络？哪部分可以重用，哪部分不可以重用。了解完这些基础概念，你就可以自行创建一个图像分类器了。经过了几个月的学习和实践，我完成了优达学城网站上《Python Programming with Python Nanodegree》课程的学习，该课程的终极项目就是使用Pytorch为102种不同类型的花创建一个图像分类器。在完成这个项目的过程中，我和其他学员一样，都碰到了各种问题和挑战，因此写下了这篇文章。希望你读完这篇文章以后，会对你的机器学习有所裨益。本文介绍了如何实现图像分类的基础概念，即理解图像内容的算法。本文并不会详细分步说明构建模型的具体步骤，而是从宏观上介绍整个过程，如果你正在学习机器学习或人工智能，相信这篇文章将会对你很有帮助。在第一部分中，我们将介绍加载预训练的神经网络，为什么要“重用”网络（即使用预训练神经网络），指明哪些部分可以重用，哪些部分不可以重用，以及如何自定义预训练网络。加载一个预训练网络“重用”是一个非常合理的策略，特别是当某些工具是大家都认可为标准的时候，“重用”更显得尤为重要。在这个例子中，我们的出发点是torchvision提供的一个模型框架。现在，我们要做的是加载一个预先训练好的网络，并用自己的网络替换它的分类器，然后，我们就可以训练自己的分类器了。虽然这个想法很合理，但是也比较麻烦，因为加载一个预先训练好的网络，并不会节省我们训练分类器的工作量。所以，使用预训练网络到底有什么好处呢？当我们人类在看图像的时候，我们会识别线条和形状，鉴于此，我们才可以将图像内容与之前看到的内容联系起来。现在，我们希望分类器也能做到这点，但是，图像并不是一个简单的数据，而是由数千个独立的像素组成，每个像素又由3个不同的值组合起来，形成颜色，即红色、绿色和蓝色。 如果我们希望分类器能够处理这些数据，我们要做的就是将每个待处理图像所包含的信息，以分类器可以理解的格式传给分类器，这就是预训练网络发挥作用的地方。这些预训练网络主要由一组特征检测器和分类器组成，其中，特征检测器被训练成可以从每个图像中提取信息，分类器被训练成理解特征层提供的输入。在这里，特征检测器已经在ImageNet中接受过训练，并且性能良好，我们希望这点能够继续保持。在训练分类器时，为了防止特征层被篡改，我们得对特征层进行“冻结”，下面这些代码可以很轻松的解决这一问题：for param in model.parameters(): param.requires_grad = False那么，问题又来了，既然我们可以“重用”特征检测器，我们为什么不能“重用”分类器？要回答这个问题，我们先来看看VGG16架构的默认分类器：(classifier): Sequential( (0): Linear(in_features=25088, out_features=4096, bias=True) (1): ReLU(inplace) (2): Dropout(p=0.5) (3): Linear(in_features=4096, out_features=4096, bias=True) (4): ReLU(inplace) (5): Dropout(p=0.5) (6): Linear(in_features=4096, out_features=1000, bias=True))首先，我们没办法保证这些代码能够起作用，在我们特定的环境中，这些默认层、元素、激活函数以及Dropout值并不一定是最佳的。尤其是最后一层的输出是1000个元素，这就容易理解了。在我们的例子中，我们要对102种不同类型的花进行分类，因此，我们的分类器输出必须是102，而不是1000。从上面VGG16架构的默认分类器中，我们还可以注意到，分类器的输入层有25088个元素，这是特定预训练模型中特征检测器的输出大小，因此，我们的分类器大小也必须要与要特征层的输出相匹配。结论从上面的分析，本文能够得到以下结论：1.预先训练好的网络非常有用。使用预训练模型，可以让我们更加专注于我们自己用例的具体细节，还可以重用众所周知的工具，对用例中的图像进行预处理。2.分类器的输出大小必须与我们希望识别的图像数量相同。3.特征层的输出和自定义分类器的输入大小必须相匹配。在下一篇文章中，我们将深入探讨，在训练分类器过程中，如何避免一些常见的陷阱，并学习如何调整超参数，来提高模型的准确性。本文作者：【方向】阅读原文本文为云栖社区原创内容，未经允许不得转载。

摘要： Kubernetes社区发现安全漏洞 CVE-2018-1002105，阿里云容器服务已在第一时间完成全面修复，敬请广大用户登录阿里云控制台升级Kubernetes版本。近日，Kubernetes社区发现安全漏洞 CVE-2018-1002105，阿里云容器服务已在第一时间完成全面修复，敬请广大用户登录阿里云控制台升级Kubernetes版本。目前Kubernetes开发团队已经发布V1.10.11、V1.11.5修复补丁，阿里云容器服务也已在第一时间完成漏洞全面修复，用户登录阿里云控制台即可一键升级。更多信息可以移步公告《关于Kubernetes CVE-2018-1002105 提权漏洞的修复公告》漏洞发现后的措施具体而言有一下几种情况供大家参考：1 用户选用阿里云容器服务K8s影响范围有限，阿里云容器服务ACK一直在推进和保障最小权限原则，默认开启了RBAC，通过主账号授权管理默认禁止了匿名用户访问。同时Kubelet 启动参数为”anonymous-auth=false”，提供了安全访问控制，防止外部入侵。对于使用子账号的多租户ACK集群用户，子账号访问Kubernetes，其账号可能通过Pod exec/attach/portforward越权。如果集群只有管理员用户，则无需过度担心。子账号在不经过主账号自定义授权的情况下默认不具有聚合API资源的访问权限。这些子账号用户请选择合适业务时间升级，进入控制台点击一键更新安全版本Kubernetes。2 如果是完全自行搭建K8s如果是在ECS上自建k8s的用户，请务必检查各项配置，如有失误，会引发较大安全风险。若用户在阿里云ECS服务器上自建Kubernetes集群，建议第一时间登录Kubernetes官网下载最新版，做好备份给节点打快照，并检查好配置、确保权限最小化，选择合适业务时间升级。3 如果是在无服务器版本无服务器版本Kubernetes在此之前已额外加固，用户不受此漏洞影响更多关于阿里云容器服务本次漏洞有限，阿里云容器服务Kubernetes采用了企业级的安全防护设计，为云上开发者省去了很多烦恼：API Server配置默认禁止匿名访问容器集群采用VPC方案，网络环境全隔离用户可以选择在公网隐藏API Server默认子帐号没有访问集群资源的权限此外，无服务器版本Kubernetes已提前加固，用户不受此漏洞影响。去年11月，阿里云率先推出了Kubernetes管理服务，整合阿里云在虚拟化、存储、网络和安全能力的优势，提供多种应用发布方式和持续交付能力并支持微服务架构。用户可轻松创建、配置和管理虚拟机群集，在阿里云上部署和管理基于容器的应用程序。为降低开发应用门槛，阿里云对Kubernetes能力进行了多重补充。比如，通过选择不同节点，实现异构计算集群支持深度学习等场景，或者云上一键部署集群，集成解决方案。阿里云容器服务采用了高性能的神龙技术架构，资源利用率提升了3倍以上，同时融合以太网RDMA技术25Gb网络，相比自建性能可提高数倍。同时，阿里云还是业内首家提供ServiceMesh服务网格最佳实践及异地多活方案的云厂商。安全是容器服务的重中之重。阿里云容器服务充分考虑了企业级的安全诉求，所有组件均提供双向证书验证，预制开启RBAC等鉴权能力，用户可以通过阿里云控制台可以安全地管理集群资源。作为国内最大规模的公共云容器平台，阿里云已为西门子、新浪微博、国泰君安、小鹏汽车、安诺优达等数千多家企业提供容器服务，在全球十六个地域部署，支持公共云、专有云、金融云、政务云。

2018天猫双11全球狂欢节，全天成交额再次刷新纪录达到2135亿元，其中总成交额在开场后仅仅用了2分05秒即突破100亿元，峰值的交易量达到惊人的高度，背后离不开阿里云大数据计算和存储能力的支撑。在整个交易的链路上，账单业务是一个重要的环节，尤其对商家系统来说，需要定期对账，账单子系统出现一点点问题都会影响商家的运营，2018的双十一，承载账单的消息系统把全网卖家账单系统60%的流量托付给了阿里云文件存储。在11日0点的峰值交易时刻，账单消息系统的写入流量瞬间达到日常流量的60倍以上，阿里云文件存储表现稳定，顺利扛下这一波洪峰，帮助业务系统完美度过0点的考验。本文将介绍阿里云文件存储的背景，以及文件存储是如何来保障业务系统应对高压力的。什么是云上的NAS文件存储在阿里云的发展早期，在云服务器ECS上运行的应用需要进行数据存储时，有两个选择：云盘：兼容应用的IO接口，但是和物理机使用硬盘一样，云盘和ECS绑定，单块云盘只能特定ECS访问；OSS：多ECS可以共享访问，但需要应用调整IO接口，使用OSS的REST接口；但如果应用既想保留原有的IO接口（一般是POSIX接口），又需要实现多ECS共享存储，就没有很好的解决办法。NAS文件存储在这样的背景下应运而生，针对传统企业级应用的存储需求，通过标准NAS系统协议（NFS/SMB），为ECS提供共享存储，支持随机读写以及PB级别容量，并且支持容量动态扩展，方便业务从小规模逐渐扩大过程中，不需要再担心存储容量的扩容以及运维问题。阿里云NAS文件系统从2016年推出至今，已经应用在丰富的业务场景中，包括高HPC性能计算、Web服务和内容管理、媒体和娱乐处理工作流、容器存储、基因和生命科学数据存储处理，深度学习大数据处理等等，很好地服务了云上的客户。NAS文件存储架构设计阿里云文件存储是一个可共享访问，弹性扩展，高可靠，高性能的分布式文件系统，其架构设计如图1所示。图1： 阿里云文件存储架构整个技术栈分五层，第一层是各类计算节点（比如ECS、Docker、GPU等）不同操作系统使用标准文件协议NFS/SMB访问文件存储。第二层是阿里云网络负载均衡，把客户端请求轮转发送到前端机。第三层是负责协议处理的前端机，具备scale-out的能力。第四层是文件系统元数据管理，实现高效的数据结构保证元数据的快速操作。第五层是元数据和数据的持久化存储，使用阿里云盘古存储系统。整个架构通过盘古保证高可靠，另外通过文件存储高效的数据和元数据管理技术实现scale-out、高可用，超高的数据访问性能以及一系列企业级存储的特性，如图2所示。图2 阿里云文件存储特性账单业务消息系统适配文件存储随着云上文件存储的知名度越来越广，阿里集团的很多内部业务也开始接入文件存储，其中就包括支撑账单业务的消息系统。架构设计消息系统的存储本来使用的是本地盘，这样最主要的问题就是当单机故障时，存储在磁盘上的数据没法及时被其他主机访问，其他主机不能快速接管原来主机的业务，缺乏容灾的能力，对应用的影响非常大。而使用文件存储天然具有多机共享访问的能力，可以很好的解决这个问题。但是，如果只是简简单单地做一个替换，把本地存储换成文件存储，如图3那样，图3 本地存储替换成文件存储（共享访问）多台ECS通过NFSv4挂载同一个文件系统，每个ECS会使用到一个文件系统里的多个子目录作为消息文件的存储空间，虽然解决了前述的容灾问题，但这个架构的问题是过于依赖单点的存储，万一单文件系统发生故障，所有消息队列的访问都会受到影响，因此需要对架构进行进一步调整。调整的基本思路就是将流量尽量打散到多个文件系统上，同时又避免对业务方软件的改造。调整后的架构入图4所示，为业务创建多个虚拟云机房，每个虚拟云机房的消息系统存储由4个NAS文件系统来承载，消息系统计算节点ECS会同时挂载4个文件系统，并且通过软链接的方式在‘nasroot’目录下看到多个队列，对业务使用上来说，这些队列对应的目录是在同一个文件系统（原来的架构）还是多个文件系统（新的架构）是不感知的，这样就将业务需要改造的量最小化，只需要在部署时候进行相应的自动化（挂载和创建软链接）即可，但带来的好处是巨大的，万一发生单文件系统的故障，业务可以自动分流到存活的文件系统，可以有效应对各种故障场景。图4 架构优化细节优化相对于使用本地盘，计算存储分离架构下，如果应对存储测的异常和故障呢？标准的NFS挂载下，如果服务端出现故障或者网络发生故障，客户端访问文件存储将会是完全hang住，直到服务或者网络恢复为止。针对这个问题，消息系统进行了相应改造，业务系统对消息的一致性保障进行了优化，可以支持写消息失败。这样就可以使用NFS的soft挂载模式，当服务端出现故障或者网络发生故障时，应用程序将不会再是完全hang住，而是能迅速监测到IOError，并立即采取对应的行动。结合前述的架构设计，应用程序能进行快速响应，把流量分流到其他存活的文件系统上，快速恢复。双十一的考验经过架构设计和细节优化，文件存储的scale-out能力在双十一尖峰发挥出了应有的能力，即使在0点时刻流量是平时的60倍以上，表现依然稳定，在文件存储的给力表现下，业务系统的响应依然如日常一样顺滑，完全感觉不出超大流量对系统的冲击。总结阿里云文件存储为云上业务提供支持标准接口（POSIX）以及标准文件访问协议（NFS，SMB）的存储服务，并且具有简单易用、安全可靠、性能和容量scale-out等特性。经过双十一的锤炼，文件存储的服务能力必将继续上升一个台阶，将提升后的能力以普惠技术的形式向云上各行各业输出，推动社会生产力的发展。

随着互联网的高速发展，计算和软件开发的进步，任何人都可以坐在他/她的厨房桌旁享受世界上最好的技术。几乎所有小型或大型企业都无所谓，似乎已将注意力转移到考虑在现有环境中处理和管理此类颠覆性技术的适当程序。云计算技术完全依赖于硬件和软件的虚拟化及其面向服务的架构和其他一些增值服务。无论您是希望备份，存储，恢复数据，开发新的应用程序和服务，托管博客和网站，按需提供软件，简化视频和音频，分析模式的数据以及使用一些最原始的预测做出前所未有的预测诸如基础架构即服务（IaaS），平台即服务（PaaS）和软件即服务（SaaS）等云服务值得考虑。在下面我想谈谈一些将在未来几年产生深远影响的云趋势，甚至有些人看不到它们的到来。1.组合5G通过将5G蜂窝网络与云计算技术相结合，您可以将更多容量和功能用于物联网（IoT）系统。什么是5G?5G具有独特的基础设施，可提供更快的移动服务连接，最终使网络客户能够顺利上传视频或简化电影。但问题来了，5G问题涉及金融，政治，健康和环境问题。我来为你详细说明一下。首先，网络转换为5G系统是非常昂贵的。其次，一些政府赞成取消有利于网络中立和促进竞争的法规。第三，中美之间即将展开一场战斗，说明哪个国家将主导5G的使用，并且正在进行投标。最后但并非最不重要的是，在全球范围内释放的无线辐射的增加可能会导致人类癌症。2.量子计算 在持续关注亚马逊网络服务（AWS），Microsoft Azure云，IBM和Google云等大型云服务提供商之后，2019年似乎将提供更大，更好，更光明的前景。量子计算是最新话题，有望将数学，材料科学和计算机科学理论转化为现实。在量子计算的帮助下，我们很快就能够通过类似人类的交互来优化复杂系统并构建更好的财务模型。3.混合云解决方案由于一些明显的原因，如自由和力量，混合云将征服商业世界。在结合私有云和公共云之后，您可以毫不费力地来回传输数据和应用程序。混合云具有更多灵活性，工具和部署选项，可确保降低转换风险和总体成本。例如，如果您希望进行电子邮件广告等项目，公共云是最佳选择，而对于更敏感的操作（如创建财务报告）则选择私有云。4.处理GDPRGDPR代表通用数据保护法规，该法规旨在对欧盟公民的数据保护法进行大规模改革。所有销售和存储公民个人信息的公司都无法控制数据。那些不遵守规则的人可能会面临严厉的处罚。许多组织都会发现急于云计算，而没有认真考虑其安全隐患。在确保数据实践完全符合GDPR要求时，公司可能在2019年遇到困难。可以使用诸如容器和无服务器计算之类的当代计算模型来实现若干布置或内置控制，诸如身份访问管理，网络安全组和网关网络防火墙。5.人工智能平台人工智能的一个重要用途是充分利用大数据。收集商业智能，更好地了解业务运作方式是技术提供的一些最重要的改进。人工智能平台主要用于比传统框架更有效，更智能地运行。这些AI平台能够做什么？Ø 支持更快，更有效，更有效的方式与数据科学家合作Ø 以各种方式降低成本-重复工作，自动化简单任务和劳动成本高昂的任务Ø 支持数据治理，确保工程师利用最佳实践6.增强的多云关注多云今年即将到来！灵活的外观模型，专门针对那些希望转变为不太传统的云模型的人。但请确保它包含一个数字管理平台，允许管理员和最终用户从一个集中位置访问您的云服务。除此之外，它甚至简化了所有云活动的管理。除此之外，多云提供：Ø 防止系统故障和其他灾难Ø 通过允许您一次在多个云环境中部署不同的云服务，消除了一些问题Ø 创建一种独特类型的云网络Ø 提供更大的灵活性，但代价是安全性结论看到许多中小型企业主为监督其业务的各个方面而感到自豪，这已经不足为奇了。但是，有时这会妨碍生产力和业务增长。因此，云计算成为可行的选择。所有行业的高管领域的技术出现持续加速，易于部署，可扩展性，灵活性或成本节约是值得考虑的重要优势。尽管如此，云基础架构必须与适当的安全和备份解决方案相辅相成，以确保数据安全。版权声明：本文素材来源于企业网D1net，转载此文出于传递更多信息之目的，如有侵权，请联系小编删除。

摘要： 原来人工智能跟人类智能有那么深的联系！几百万年前，第一次人类智能的星火出现在非洲大陆，并且持续发展，最终在大约10万年前在智人的大脑中达到顶峰。作为现代人类，我们只能想象我们的古代祖先在窥视夜空时所经历的事情，以思考物理现实的本质，以及从内心窥视自己心理现实的本质。在过去的几百年里，我们的物种通过发现控制空间、时间、物质和能量的基本数学定律。在发展对物理现实的精确理解方面取得了巨大的智力进步，现在已经在量子力学的大框架中被编纂。然而，我们正处于探索心理现实本质的最初阶段。尤其是人类智能是如何从100亿个突触连接的1000亿个神经元的生物湿件中产生的？神经科学，心理学和认知科学等现代学科在过去100年中取得了重要进展，为解决这一重大问题奠定了基础。但是，当涉及到我们的心智能力时，对于现代人来说，仅仅理解它们是不够的，我们非常希望在无生命系统中重现这些功能。本质上，人类作为进化的产物，有时也渴望扮演创造者的角色。这种向往渗透在人类文学的作品，事实上，人工智能（AI）这个新兴领域，通常与神经科学，心理学和认知科学领域合作，在创造具有类似人类能力的机器方面取得了巨大进步。在这篇文章中，我将进一步探讨人工智能，神经科学，心理学和认知科学以及数学，物理和社会科学中的联合学科在过去和未来将继续如何共同努力追求交织在一起的理解和创造智能系统的过程。生物学与人工智能之间的富有成效的合作在过去的60多年中，AI的发展受到了神经科学和心理学的深刻影响，其中也受到了神经科学和心理学的启发。在早期的几十年中，许多AI从业者在神经科学和心理学方面进行了很好的研究。在这里，我提供了神经科学，心理学和AI之间过去的相互作用：这种相对简单的元素（神经元）的分布式网络能够实现源于神经科学的人类智能的显着计算，并且现在以神经网络的形式渗透到AI系统中。这个想法并不总是显而易见的，在大约一百年前，在高尔基和卡哈尔之间的著名辩论之后，它才变得坚定。包括多维尺度和因子分析在内的各种降维技术最初是在心理测量学研究的背景下开发的。著名的神经科学家霍勒斯·巴洛（Horace Barlow）发明了分解代码的概念，这反过来启发了独立成分分析（ICA）和当前的AI研究，旨在解开数据变异的独立因素。托尔曼在认知图上的工作提供了方向，使得我们可以使用这些模型进行规划和导航。这巩固了内部模型形成作为动物智能的关键组成部分的思想，这部分目前处于人工智能研究的前沿。Hopfield网络是理论神经科学的一个模型，为思考分布式、可寻址的存储器和检索提供了一个统一的框架，也启发了Boltzmann机器，这反过来又为证明深度神经网络模型的成功提供了关键的第一步。它还启发了许多弱约束的分布式以满足作为AI计算模型的想法。目前主导机器视觉的深层卷积网络的关键核心直接受到大脑的启发。其中包括腹侧流中的分层视觉处理，它表明深度的重要性;视网膜的发现是整个视觉皮层的组织原理，导致卷积的出现;发现简单和复杂的细胞激发了最大池化等操作。关于稀疏编码的研究工作是为了理解初级视觉皮层中定向边缘检测器，导致稀疏编码成为现代AI系统中的基本构建块。时序差分学习等算法现在是强化学习领域的基础，它受到经典条件反射的动物实验的启发。反过来，强化学习对基底神经节功能的解释具有显着影响，其中多巴胺能为基底神经节提供了非常重要的奖励预测误差信号，该信号也驱动许多强化学习算法。大脑中存储系统的模块化启发了现代记忆神经网络，其在一定程度上将存储器存储和执行控制电路的操作分开，其决定何时从存储器读取和写入。人类注意力系统激发了注意力机制和神经网络的结合，这些神经网络可以被训练以动态地注意力或忽略其状态和输入的不同方面以进行未来的计算决策。语言学和认知科学中正式生成语法的发展导致概率语法的发展和CS的解析。Dropout等现代正则化技术的灵感来自于神经动力学的内在随机性。人工智能未来的生物学启示尽管当前人工智能系统在监督模式识别任务方面取得了显著的商业成功，但仿真人类智能仍然有很长的路要走。在这里，我将概述一些个人观点，其中我认为生物学和人工智能领域可以携手前进。1、生物学上可信的信用分配（plausible credit assignment）信用分配问题可能是神经科学和人工智能领域最大的开放性问题之一。很明显，假设你正在打网球而且你没有击中球。你的100万亿个突触中有哪一个应该受到指责？大脑如何在你的运动系统中专门找到并纠正突触组，尤其是在错误发生后几百毫秒内通过视觉系统传递错误时？在AI中，这种信用分配问题在许多情况下通过多层计算的反向传播来解决。然而，目前尚不清楚大脑如何解决这个问题。真实的情况是，大脑使用本地学习规则解决它：即每个突触仅使用物理上可用的信息来调整其强度，例如，由突触连接的两个神经元的电活动来奖励和惩罚的任何神经调节输入。解释这些本地突触规则是什么以及它们如何工作可能会对AI产生巨大影响，这可以一定程度上减少反向传播的通信开销。但更一般地说，解决困扰神经科学和人工智能的常见未解决问题应该通过将突触生理学家，计算神经科学家和AI从业者聚集在一起来集体解决生物学上可信的信用分配问题来推动进步。2、融合突触复杂性生物和人工神经模型之间的主要区别在于我们模拟连接神经元的突触的方式。在人工网络中，突触由单个标量值建模，反映乘法增益因子，转换神经元的输入如何影响神经元的输出。相反，每个生物突触都隐藏在极其复杂的分子信号通路中。例如，我们对最近事件记忆的海马突触各自包含数百种不同类型分子的化学反应网络，同时它具有整个复杂时间处理能力的动力系统。在看到这种复杂性后，理论家或工程师可能会试图简单地将其视为生物学上的混乱，而这种混乱就是一种进化的偶然事件。然而，理论研究表明，这种突触复杂性可能确实对学习和记忆至关重要。事实上，在突触具有有限动态范围的记忆网络模型中，这样的突触本身就要求是具有复杂时间滤波特性的动态系统，以实现合理的网络存储容量。此外，最近在AI中正在利用更智能的突触作为解决灾难性遗忘问题的一种方法，其中训练学习两个任务的网络只能学习第二个任务，因为学习第二个任务会改变突触权重以这种方式消除从学习第一项任务中获得的知识。一般地说，我们的人工智能系统很可能通过忽略生物突触的动态复杂性而取得重大的性能提升。正如我们为我们的网络添加空间深度以实现复杂的层次表示一样，我们可能还需要为突触添加动态深度以实现复杂的时间学习功能。从系统级模块化大脑架构中获取灵感通常，当前的商业AI系统涉及具有相对均匀的分层或循环架构的训练网络，其从随机权重开始。但是，对于更复杂的任务来说，这可能是一个难以解决的问题。事实上，生物进化的道路却截然不同。所有脊椎动物的最后共同祖先生活在5亿年前。从那以后，它的基本大脑一直在发展，导致大约1亿年前出现哺乳动物大脑，以及几百万年前的人类大脑。这种不间断的进化链导致了一个错综复杂的大脑结构，具有高度保守的计算元素和巨大的系统级模块化。事实上，我们目前缺乏工程设计原则，来解释像大脑一样复杂的传感，通信，控制和记忆网络可以在5亿年的时间内不断扩大规模和复杂性，同时永远不会失去在动态环境中自适应运行的能力。因此，AI从大脑的系统级结构中获取灵感可能非常有趣。一个关键的系统属性是功能和结构的模块化。大脑不像我们目前的AI架构是同质的，而是有不同的模块，如海马（保留情节记忆和导航），基底神经节（潜在的强化学习和动作选择）和小脑（自动化的运动控制和通过监督学习获得更高层次的认知）。此外，人脑中的记忆系统（习惯记忆，运动技能，短期记忆，长期记忆，情景记忆，语义记忆）也是功能模块化的。此外，在运动系统中，嵌套反馈环架构占主导地位，通过简单的快速循环在20毫秒内实现自动运动校正，稍慢的智能循环通过运动皮层在50毫秒内实现更复杂的运动校正，最后经过整个大脑的视觉反馈实现对运动错误的有意识的校正。最后，所有哺乳动物大脑的一个主要特征是由大量相似的6层皮质柱组成的新皮层，所有这些都被认为是在单个规范计算模块上实现的变异。总体而言，现代哺乳动物大脑具有显著的模块性，通过1亿年的进化保存下来，表明这种系统级模块化可能有利于在AI系统中实施。目前从白板上训练神经网络的方法是不可能走向更普遍的人类智能的途径。实际上，系统级模块化的组合带来的不同类型的纠错嵌套循环和动态复杂的突触可能都是解决生物学上可信的信用分配的关键因素。本文作者：【方向】阅读原文本文为云栖社区原创内容，未经允许不得转载。

12月12日，第八届中国云计算标准和应用大会在北京隆重召开，工业和信息化部党组成员，总工程师张峰先生，中国工程院副院长陈左宁女士，中国工程院院士沈昌祥先生，中国电子技术标准化研究院院长赵波先生，国家市场监督管理总局标准技术管理司副司长国焕新先生出席本次大会并做演讲。本次大会上，重磅发布了阿里云与中国电子技术标准化研究院等多家单位共同合作编写的《边缘云计算技术及标准化白皮书》，在业界首次从标准的角度明确定义了”边缘云计算“的概念、技术特点、应用场景及标准化建议。阿里云视频云总经理朱照远同时发表了《技术、标准、合作-构建阿里云边缘云计算开放生态》的主题演讲。据IDC预测，到2020年将有超过500亿的终端和设备联网，其中超过50%的数据需要在网络边缘侧分析、处理与存储。万物互联时代的基本需求是“低时延，大带宽，大连接，本地化”， “云、边、端三体协同”是物联网时代的计算组合形态，边缘云计算将是物联网时代不可或缺的通用基础设施。边缘云计算就是要通过层层前移，深入到每一个计算场景。未来五年，阿里云将在运营商基础互联网和政企家庭等客户侧构建边缘计算，逐步打造成为“全球覆盖，无处不在”通用基础设施。朱照远表示，在未来将有越来越多的应用会在边缘云计算平台上生长出来，这需要构建开放生态系统，通过合作伙伴、开发者，将边缘的资源及平台能力包装成适合于各类垂直行业客户使用的产品，以满足企业“低延时，低成本”的组合计算需求。但由于边缘设备众多、差异化大，各云服务商所采用的架构、技术存在一定的差异，边缘云计算的应用场景也各具特色，业界需要在边缘云计算的定义、使用场景、参考架构等方面形成共识，使基于边缘云计算技术打造的相关应用可以跨平台使用，促进边缘云计算的应用和推广。依据目前边缘云生态中技术、产品、服务、应用等关键环节，结合国内外边缘云技术发展现状以及标准化需求，发挥国家标准化机构和行业领先企业的联合优势，阿里云率先倡议并组织开展了边缘云计算标准化体系框架建设，标准建议包括：基础、技术要求、管理要求、安全要求、行业及应用等，这些标准主要结合现有云计算标准体系做了延续和扩展，以满足边缘云计算的新需求和新特性。阿里云希望通过标准化的能力开放API，促进边缘云计算产品和服务的进一步发展，提升边缘云计算的安全，营造开放的边缘云计算产业生态，加快边缘云计算技术创新和成果转化，促进技术创新、支撑云计算技术和产业的进一步发展。点击了解阿里云边缘节点服务（ENS）产品详情站内下载《边缘云计算技术及标准化白皮书》直接下载《边缘云计算技术及标准化白皮书》附件下载： 边缘云计算技术及…[樰篱].1544599778.pdf

一台服务器，不管是物理机还是虚拟机，必不可少的就是内存，内存的性能又是如何来衡量呢。内存与缓存现在比较新的CPU一般都有三级缓存，L1 Cache（32KB-256KB），L2 Cache（128KB-2MB），L3 Cache（1M-32M）。缓存逐渐变大，CPU在取数据的时候，优先从缓存去取数据，取不到才去内存取数据。内存与时延显然，越靠近CPU，取数据的速度越块，通过LMBench进行了读数延迟的测试。从上图可以看出：Intel(R) Xeon(R) Platinum 8163 CPU @ 2.50GHz 这款CPU的L1D Cache，L1I Cache为32KB，而L2 Cache为1M，L3为32M；在对应的Cache中，时延是稳定的；不同缓存的时延呈现指数级增长；所以我们在写业务代码的时候，如果想要更快地提高效率，那么使得计算更加贴近CPU则可以获取更好的性能。但是从上图也可以看出，内存的时延都是纳秒为单位，而实际业务中都是毫秒为单位，优化的重点应该是那些以毫秒为单位的运算，而内存时延优化这块则是长尾部分。内存带宽内存时延与缓存其实可谓是紧密相关，不理解透彻了，则可能测的是缓存时延。同样测试内存带宽，如果不是正确的测试，则测的是缓存带宽了。为了了解内存带宽，有必要去了解下内存与CPU的架构，早期的CPU与内存的架构还需要经过北桥总线，现在CPU与内存直接已经不需要北桥，直接通过CPU的内存控制器（IMC）进行内存读取操作：那对应的内存带宽是怎样的呢？测试内存带宽有很多很多工具，linux下一般通过stream进行测试。简单介绍下stream的算法：stream算法的原理从上图可以看出非常简单：某个内存块之间的数据读取出来，经过简单的运算放入另一个内存块。那所谓的内存带宽：内存带宽=搬运的内存大小/耗时。通过整机合理的测试，可以测出来内存控制器的带宽。下图是某云产品的内存带宽数据：Function Best Rate MB/s Avg time Min time Max timeCopy: 128728.5 0.134157 0.133458 0.136076Scale: 128656.4 0.134349 0.133533 0.137638Add: 144763.0 0.178851 0.178014 0.181158Triad: 144779.8 0.178717 0.177993 0.180214内存带宽的重要性自然不言而喻，这意味着操作内存的最大数据吞吐量。但是正确合理的测试非常重要，有几个注意事项需要关注：内存数组大小的设置，必须要远大于L3 Cache的大小，否则就是测试缓存的吞吐性能；CPU数目很有关系，一般来说，一两个核的计算能力，是远远到不了内存带宽的，整机的CPU全部运行起来，才可以有效地测试内存带宽。当然跑单核的stream测试也有意义，可以测试内存的延时。其他内存与NUMA的关系：开启NUMA，可以有效地提供内存的吞吐性能，降低内存时延。stream算法的编译方法选择：通过icc编译，可以有效地提供内存带宽性能分。原因是Intel优化了CPU的指令，通过指令向量化和指令Prefetch操作，加速了数据的读写操作以及指令操作。当然其他C代码都可以通过icc编译的方法，提供指令的效率。

一台服务器，不管是物理机还是虚拟机，必不可少的就是内存，内存的性能又是如何来衡量呢。1. 内存与缓存现在比较新的CPU一般都有三级缓存，L1 Cache（32KB-256KB），L2 Cache（128KB-2MB），L3 Cache（1M-32M）。缓存逐渐变大，CPU在取数据的时候，优先从缓存去取数据，取不到才去内存取数据。2. 内存与时延显然，越靠近CPU，取数据的速度越块，通过LMBench进行了读数延迟的测试。从上图可以看出：Intel(R) Xeon(R) Platinum 8163 CPU @ 2.50GHz 这款CPU的L1D Cache，L1I Cache为32KB，而L2 Cache为1M，L3为32M；在对应的Cache中，时延是稳定的；不同缓存的时延呈现指数级增长；所以我们在写业务代码的时候，如果想要更快地提高效率，那么使得计算更加贴近CPU则可以获取更好的性能。但是从上图也可以看出，内存的时延都是纳秒为单位，而实际业务中都是毫秒为单位，优化的重点应该是那些以毫秒为单位的运算，而内存时延优化这块则是长尾部分。3. 内存带宽内存时延与缓存其实可谓是紧密相关，不理解透彻了，则可能测的是缓存时延。同样测试内存带宽，如果不是正确的测试，则测的是缓存带宽了。为了了解内存带宽，有必要去了解下内存与CPU的架构，早期的CPU与内存的架构还需要经过北桥总线，现在CPU与内存直接已经不需要北桥，直接通过CPU的内存控制器（IMC）进行内存读取操作：那对应的内存带宽是怎样的呢？测试内存带宽有很多很多工具，linux下一般通过stream进行测试。简单介绍下stream的算法：stream算法的原理从上图可以看出非常简单：某个内存块之间的数据读取出来，经过简单的运算放入另一个内存块。那所谓的内存带宽：内存带宽=搬运的内存大小/耗时。通过整机合理的测试，可以测出来内存控制器的带宽。下图是某云产品的内存带宽数据：————————————————————-Function Best Rate MB/s Avg time Min time Max timeCopy: 128728.5 0.134157 0.133458 0.136076Scale: 128656.4 0.134349 0.133533 0.137638Add: 144763.0 0.178851 0.178014 0.181158Triad: 144779.8 0.178717 0.177993 0.180214————————————————————-内存带宽的重要性自然不言而喻，这意味着操作内存的最大数据吞吐量。但是正确合理的测试非常重要，有几个注意事项需要关注：内存数组大小的设置，必须要远大于L3 Cache的大小，否则就是测试缓存的吞吐性能；CPU数目很有关系，一般来说，一两个核的计算能力，是远远到不了内存带宽的，整机的CPU全部运行起来，才可以有效地测试内存带宽。当然跑单核的stream测试也有意义，可以测试内存的延时。4. 其他内存与NUMA的关系：开启NUMA，可以有效地提供内存的吞吐性能，降低内存时延。stream算法的编译方法选择：通过icc编译，可以有效地提供内存带宽性能分。原因是Intel优化了CPU的指令，通过指令向量化和指令Prefetch操作，加速了数据的读写操作以及指令操作。当然其他C代码都可以通过icc编译的方法，提供指令的效率。本文作者：ecs西邪阅读原文本文为云栖社区原创内容，未经允许不得转载。

摘要： 只有不停的去挑战自己，永不停歇的思考和不断颠覆自我，才可能保持一点点微小的领先。小蚂蚁说：从“互联网推进器计划”到“成熟一个开放一个”，再到蚂蚁金融科技全面开放战略的公布，这一路走来，蚂蚁金服不断创造技术的里程碑，同时，也缔造出一个又一个的业界里程碑。然而，谁又想到，“蚂蚁的科技开放究竟要怎么做？”今天，我们将分享一个“蚂蚁金服科技开放的故事”。文 | 央行观察作为 “空降” 蚂蚁金服的高管之一，刘伟光刚来的时候颇不适应。刘伟光是蚂蚁金融科技开放的负责人。2017年12月底，在杭州某酒店的一次公司内部会上，刚来公司不久的他，向同事们讲了下他对蚂蚁金融技术开放的战略。那个时候他正在苦苦思索未来的开放格局不得其解，当天人处在正发高烧的状态，状态差到极点。“很多当时的想法连自己都没有说服自己，更不要说别人了”，后来，每次想起这次 “失败” 的分享，刘伟光都觉得挺惭愧的，那就是当时的困境所在。那时的蚂蚁金服，正渐入开放的深水区，从 “成熟一个，开放一个” 决意走向全面开放。如何真正全面、从哪入手等问题都扑面而来。说开放难做，是因为这意味着很多技术能力要从服务C端，跨越到B端和C端兼顾，这中间有一个巨大的能力跨越和需要不断论证的过程。 放眼全球，真正能做到的公司屈指可数，而蚂蚁金服所处的金融行业特殊性，又进一步增加了这个难度：首先，IOE 传统架构下的流程和模式已经在行业根深蒂固，新来者必须提供更有价值的服务；其次，蚂蚁金服自身也有金融业务，合作方难免会有顾忌。因此，如果提供不了更好的解决方案、真正给用户带来价值的话，蚂蚁技术开放的战略就将只是一厢情愿。蚂蚁的科技开放究竟要怎么做？刘伟光和同事们绞尽脑汁地想了几个月，无数个夜晚在黄龙国际的办公室里和旁边的夜宵馆子里带着团队苦苦的进行 “脑暴”。一、“想办法摸到放置在十米高的篮筐”在加入蚂蚁金服之前，刘伟光曾在 Oracle、EMC、Pivotal 等全球顶尖软件公司工作过多年。到蚂蚁后，这是一个全新的行业，且行业在巨变，在老东家的那套玩法已经行不通了。外企最看重的是业务规模和短线收入，但是现在如果他再说自己做了几个 million、几个 billion 的生意的话，在蚂蚁没有人会在意，公司需要的是开拓一种全新的服务模式和用技术来促进甚至驱动生态的做法。这中间需要巨大的脑洞和付出。就像一个篮球运动员，如果让他从3.05米高的篮筐摸到3.20米，只要勤加锻炼就可以达到，这是一种线性的思维和增长，一个不一定恰当的比喻就是：如果篮筐放到10米高让他去摸，怎么办？靠之前的方法就完全不行，必须换一种新的思路和打法。对于刘伟光来说也是如此，要想进一步推动蚂蚁金融科技，就必须有一套新的打法。首先就要颠覆自己，改变自己近20年的纯粹 IT 思维模式，这本是就是一个巨大的挑战。2018年春节后的一个下午，刘伟光要和公司的 CTO 程立以及副CTO 胡喜讨论headcount（人员招聘）的问题，刘伟光在会议的开始说了一句，“我这里还有些关于业务上的最新的打法可以聊聊”。“那就先说打法吧”，程立打断了刘伟光。程立曾经是支付宝最早的程序员，在蚂蚁金服的十几年中，他经历过 “双11” 的洗礼、“账目三期” 的历练，熟知这家企业在技术上所走的每一步。在2017年杭州云栖 ATEC 大会上，程立首次披露了蚂蚁金服面向未来的技术布局——“BASIC” 战略（“BASIC：Blockchain（区块链）、AI（人工智能）、Security（安全）、IoT（物联网）和 Computing（计算）”）。也正是从那时起，科技 (开放)、普惠和全球化一道，成为了蚂蚁金服的三大核心战略。事实上，蚂蚁金服的科技开放战略早在几年前就有。2015年9月，时任蚂蚁金服总裁的井贤栋就宣布启动互联网推进器计划。随后的几年里，开放战略不断升级，直到成为公司最重要的核心战略之一，这背后有着特殊的时代背景：一是金融系统去IOE、自主可控化的趋势日益明显，二是金融科技的发展体现出深度融合的趋势，银行、新金融机构之间的技术和业务合作正呈现出加速的趋势。在和程立、胡喜的那次谈话中，刘伟光就从赋予金融行业前中后台新的定义、重构未来数字金融这个角度说了自己的想法。他认为，好的科技服务，应该切中用户的真实需求，应该先从服务银行与用户交互最多的移动端发力，重新定义移动端金融的能力，然后走向中台，建立敏捷能力中心，最后再助力银行瘦身后台系统。通过分布式技术平台重构后台核心系统，全新的架构更加强调对业务和产品迭代周期的缩短，增强对新型业务的快速支撑，包括对线上线下业务融合的思考，从而适应中国金融行业发展的趋势。在很多 IT 专业人士眼中，前中后台的提法算不是上什么新词，但是在那个黑板上画出的架构图却是完全不同的定义，但这却是刘伟光和同事在几个月思索后的一些阶段性想法。银行 App 的用户体验，一直是客户诟病的痛点，如果看看手机应用商店下的评论，我们就知道银行在这方面需要做多么大的提升，而这也正是蚂蚁金服能够帮助到银行的地方。无独有偶，蚂蚁的竞争对手腾讯，也在帮商业银行做用户体验大调研，以期从移动端切入用户。讲到最后，程立在白板上写下了自己的愿望，“用技术实现真正的数字金融”。可以说这番谈话开启了后来的很多故事。实现这个业务目标的第一步，是要倾听银行伙伴们在移动端上的真实需求。2018年3月底的一个晚上，在支付宝大厦楼下的一个小饭馆里，刘伟光向同事和盘托出了想从移动端入手的思路。他说，“我们要办一场专注在移动金融的会，请100家银行来，倾听他们的想法，验证我们的思路”。当时刘伟光在喊出100家银行的时候其实心里是很虚的。这些思路和打法到底能否真正得到市场的认可还是个问号。这就是在蚂蚁金融科技开放历程中非常著名的 “511大会”。整个会议的筹备没有用供应商，蚂蚁的人自己来负责会议的通知、接机、组织和所有的会务工作，全员上阵，连 HR 和研发的专家们都在现场做会务支持。通过主动联系和人传人的方式，最后有250家银行报名参加，西子宾馆的大会议室里超过500人云集。在这次会上，刘伟光代表公司将蚂蚁在移动端的服务战略和思路分享给了银行客户，也对蚂蚁未来的前中后台战略做了展望，还请到了银行客户上台发言。当天的会议进行到下午5～6点钟的时候，依然有80%左右的上座率。“我们用蚂蚁的精神办了一场会”，刘伟光说。二、从解决方案入手在加入蚂蚁一年多的多时间里，刘伟光和团队一起拜访了中国数百家家金融机构，每到一地，他都要和当地银行的高管做深入的沟通。在这个过程中，他感受到了银行面向科技、面向移动、面向数字化转型的迫切需求。1、“为什么我们银行做了这么多APP，没有一个app日活量大？”2、“为什么别人是千人千面，我们是千人一面的APP？”3、 “我们花了一个多亿人民币构建一个数据仓库，为什么现在还一张数据报表都跑不出来？”4、“金融科技到底是什么？不是给科技部自用，而是应该给全行所有人包括客户都用的起来的工具才有意义，人人都可以使用大数据系统做 BI，而不是仅限于非常少数的专业人员。“5、“分布式架构就是银行的未来，我们科技部把职业生涯赌在这场改造上，你们蚂蚁金服敢不敢跟我们一起赌？”6、“农村金融是世界性难题，金融科技如果能解决最后一公里的触达，才真正有意义。”7、“中国的城商商业银行如果没有自己的核心客户群，没有核心竞争力的产品，没有差异化竞争，未来的出路在哪里？”这些客户心声给了蚂蚁技术团队非常大的触动，这些问题充满着困惑、焦虑但又极具启发，也促使蚂蚁金服对科技开放的模式进行更深层的思考，传统金融 IT 服务公司讲究的是卖系统、卖软件，鲜少从战略和业务提升的角度入手。然而，今天所有的需求归结到最本质的一点就是，金融科技的开放怎样才能真正给客户带来价值，科技到底能不能和业务的增长产生方程式般的关联度？正如美国柯林斯在其畅销书《从优秀到卓越》一书中所阐述的，技术变革从来不是实现从平庸到伟大的关键因素，在柯林斯眼中，技术是加速器而非驱动企业实现变革的第一推动力。同样，今天金融机构面向数字化的转型，是从之前的 IT 模式，过渡到互联网服务的模式，蚂蚁金服不仅需从自身实践的角度看问题，还要站在客户的视角去找到解决的办法，和他们一起跨越业务和技术之间的鸿沟。数字金融创新，不只是业务导流和线上风控，也不是单一的科技产品应用，而是抵达核心业务系统的转型创新，构建自身的核心数据资产。金融机构需要的是成本低、见效快、可用性高、符合金融级别安全标准、又能够真正带来业务价值的科技输出服务，帮助其进行快速敏捷的产品开发。金融机构的需求就是蚂蚁金服努力的方向。刘伟光和同事在重新梳理产品体系之后，从业务的视角切入，将金融最核心的三个元素抽象出来，推出了 “分布式金融核心套件” 这款新产品。简言之，“分布式金融核心套件” 是一个业务视角入手的产品。金融机构使用之后，既可以针对业务需求进行敏捷开发，快速获取客户，还能将产品工厂、资金交换、核算等金融机构核心业务技术能力封装成业务组件，以支撑各个业务线条的快速调用。蚂蚁金服将很多与此相关的技术能力封装在 “分布式金融核心套件” 之中，与生态 ISV 一起就能够将传统的业务能力叠加进来，从而快速支撑每一项业务的发展，将金融机构过去多个竖井式的核心系统架构改变为适应金融业务和产品快速迭代的分层领域架构，让银行的业务核心能力无处不在。创新与改变，一直是驱动着蚂蚁技术开放团队的源动力。2017年，南京银行引入蚂蚁金服分布式架构 SOFAStack、分布式数据库 Oceanbase 以及大数据平台能力，构建新的互联网核心。同年11月上线互联网金融平台 “鑫云+”，“鑫云+” 一端对接互联网平台的金融需求，另一端对接实际的金融产品和服务，通过使用金融级互联网架构设计模式、敏捷工具和微服务平台，“鑫云+” 从架构设计到上线投产仅用了5个月。上线之后，正好赶上了消费金融的大发展，在截至2018年6月底的最近8个月中，“鑫云+” 平台新客户数达到390万，每日贷款额从1万人民币上升至10亿人民币。“我们用一年时间干了过去十年的业务量”，南京银行信息科技部副总经理李勇感慨的说。三、蚂蚁技术发展历程开放的前提是强大的技术实力。解决实际问题、促进业务发展，一直是蚂蚁金服技术创新的底色。从支付宝最初的担保交易，到后来的快捷支付、余额宝，乃至今天的借呗、花呗、相互宝，蚂蚁金服的发展受益于技术的支撑。在这个过程中，公司内部也形成了独特技术部门组织架构：负责统一架构的事业部，以及各个业务单元里的应用技术事业部，平台技术与应用技术并行不悖，高度融合。为了展示蚂蚁的技术实力，2018年9月20日，杭州云栖大会 ATEC 主论坛现场上演了一场特别的技术秀。蚂蚁金服副CTO 胡喜现场模拟挖断支付宝近一半服务器的光缆。结果只过了26秒，模拟环境中的支付宝就完全恢复了正常。类似的灾备演练在蚂蚁金服内部经常举行，但是在一个公开的场合对外展示却并不容易。“几乎是我们所有人脱了一层皮”，胡喜这样说道，观众看到的是四根线剪掉了，然而由于数据和交易分布在不同的机房，其中牵涉不同的分布式架构，要调动底层数量众多的数据库系统一起协同，难度非常大。现在，蚂蚁金服的机房架构已经做到了 “三地五中心”，即在三座城市部署五个机房，一旦其中一个或两个机房发生故障，支付宝的底层技术系统会将故障城市的流量全部切换到运行正常的机房，并且能做到数据保持一致且零丢失。这样的技术架构，让蚂蚁金服的系统持续可用性因此达到了 “6个9”，即便用金融级别的标准来衡量的话，这个水平在全球也是首屈一指的。“这次是演习。而在真实环境下，如果支付宝部署在两个城市的两个机房同时出问题，跑在这两个机房上的支付宝账户恢复正常的速度是分钟级”，胡喜这样说道。胡喜2007年加入支付宝，37岁的他是阿里巴巴集团最年轻的合伙人之一，早些年，胡喜和他的同事，主要面临两个问题：一是让系统容量可以无限增长；二是希望系统持续可用。如果说分布式架构解决了第一个问题的话，那么 “异地多活” 技术的成熟，就意味着第二个问题已经不再是问题。回顾蚂蚁金服技术的发展历程，大致可以分为三个阶段，在第一个阶段，支付宝需要应对 “双十一” 大促海量并发的系统需求，支付宝自身的系统架构从原来的烟囱式改成了分布式，这个阶段支付宝完全是在自我探索；在支付宝掌握了分布式架构技术之后，又将这种技术应用在网商银行等场景，成熟后又通过互联网推进器计划向外输出，成功服务了南京银行等客户；在个案的探索之后，蚂蚁金服将自身的金融科技能力通过 “分布式金融核心套件” 的产品开放出来，将金融机构获取科技服务的门槛大大降低。“打穿打透” 的极致性技术追求，让胡喜和他的同事，将蚂蚁的技术带到了全球 Fintech 领域的最高点。也正是在那次会议上，胡喜宣布，蚂蚁金融云升级成为蚂蚁金融科技并全面开放，目的就是为行业提供完整的数字金融解决方案，而刘伟光就是这个项目的直接负责人。今天，站在金融科技这个赛道上，刘伟光和他的同事深知，任何公司和个人都要适应这个时代的快速转型，只有不停的去挑战自己，永不停歇的思考和不断颠覆自我，才可能保持一点点微小的领先。而这份微小的领先，也只有在开放共享，携手合作中才能焕发真正的能量。蚂蚁金服最希望成为这个赛道上，和众多的金融科技伙伴，始终携手同行的那一个。本文作者：平生栗子阅读原文本文为云栖社区原创内容，未经允许不得转载。 ...

摘要： 智能监控是智能运维的子领域，详细分析。作者简介王肇刚：阿里巴巴全球运行指挥中心高级技术专家智能监控是智能运维的子领域，我们说的监控，探讨的更多是在监控策略，因为可能从数据采集、日志收集、包括计算等等产生数据，再设定一些判断的规则和策略，发送报警，这些都属于监控。我和我的团队在阿里内部的分工是横向去看阿里巴巴业务指标的监控，我们就以这个话题展开。分享分为五个环节，从阿里巴巴不同的业态，特别是新的业态带来的挑战讲起。对于我们之前已有的基于机器学习算法这样一个算法工程架构，我们做了哪些增强应对这些挑战。我们的监控也从单一指标监控延展到多个指标一起监控。监控完了之后，我们可能要分析定位，这时系统又能帮运维工程师做什么，这是第四方面的话题。最后是对智能运维整个领域做一些展望。一、新业态给业务监控带来的挑战上图是阿里巴巴不同的业态，有比较传统的电商业态，右上角是国际电商，蚂蚁金服还有阿里云。最近这段时间阿里在收购各种各样的公司，也是商业的布局，我们会看到优酷、钉钉等等。我们团队在阿里巴巴内部是负责横向的业务指标监控，这个有什么差异？技术层面也是通过日志的采集流程计算看一个指标下跌还是上涨，区别在于只要业务发生了不可用或者发生问题，我们希望都能够发现，而不是说阿里巴巴本身的系统出问题了。举个例子，如果阿里巴巴一点异常都没有，但是电信可能有问题，这个时候我们希望知道。它是从对于业务数据量实时的监控。因为阿里巴巴本身的业态是很丰富的，有这么多的业态，我们看到的数据也很丰富。上边这个图，大家可能看到的这些 Logo，看到购物或云计算的一些业务，但是团队做智能运维算法的同学，看到的就是右边这种奇形怪状的曲线。我们团队在阿里内部是横向团队，第一环节就是需要能够精确、及时的发现业务是否有异常。为了达到这个目标，我们引入了称之为智能基线的系统，这个系统可以在网上搜索到。这个系统效果还是不错的，能够在没有任何阈值或者规则输入的情况下，自觉做预测。同时有些业务发展比较迅速，我们可以比较好地在历史的长期趋势和短期的业务沟通之间，做出一个相对较优的折中。业务变化之后，假设你以前配了阈值还要改，智能基线不需要改。阿里巴巴几千项业务指标，通过人工的检查验收之后的准确率是在80%以上，这个数字每周都不一样。而对比传统的工程师通过传统的静态分段阈值或者环比的方式，准确率可能只有 40% 左右。大家可能也会看到特别对于业务量监控，可能 10 条报警里面，4 条真的觉得有问题已经不容易了。阿里有很多不同的业态，所以一套系统解决所有问题还是挺难的，因为不同业态之间的差异还是非常大，数量级、波动、周期均有差异，包括现在有新零售业务，它是把线上线下的业务结合起来，而且非常强调线下。比如盒马鲜生有几百家门店，这是个商业的尝试，对于做运维监控的同学也带来很多挑战。比如淘宝和天猫的某些交易量在分钟级别是万或十万或更高的数量级，这个可能就是百或几百，波动的量级和原始量级在一个量级上，这个就比较难处理。包括周期性，对于一般的在线服务，是7X24小时提供服务，每天什么时间流量最低？国内业务凌晨四点钟最低，这个会受门店的开关门影响，因为零售是有时间的。我们如果线上刷淘宝下单点一下就行，线下不一样，一对一排队结账。而且在量小的情况下，很多时候不能看单一指标，许多指标要一起看，所以就给我们之前的算法提出非常大的挑战，我们需要做新的算法演进。大家可能会问为什么整这么复杂的算法。配监控，配规则不就可以了吗？其实是可以的，但业务太复杂。作为一个横向团队，算法工程师可能只有三四人，七八个人要面对阿里巴巴集团成千上万的业务监控指标，不可能了解每个指标的所有细节，这个时候是没有办法用人，我们要用机器学习的方法去做。二、增强版的时间序列异常检测实战接下来讲讲怎么用机器算法解决问题，这是一年半以前我们采取的架构，我们能从业界很多文章上看到类似的架构。我们希望做一个基线拟合，这个曲线应该是什么样，我们说异常这两个字就是异于平常。我们第一步想知道正常的曲线是什么样子，所以我们做基线拟合，我们用STL做这样的方法，我们用比较传统的 N-sigma 做调整。这种架构其实能解决 60% 左右的问题，但是有些极端的情况解决不了，所以我们就把架构做了演进。我们第二代的架构做数据预处理，然后又做了比较简单的滑动平均，数据有时候会缺点，不管是采集侧的一些不稳定因素，还是计算一侧出现了问题，导致你希望一分钟出一个数据点，但是最后还没有算出来。这种情况应该从工程上解决，所以我们会在算法层面做一些脑部的算法策略，就是即使缺了能补回来，但是不能长时间缺数据。下面的逻辑就走了机器学习的思路，我们对曲线做特征工程。我们之前的基线拟合的这种预测只是我们特征工程中一部分，对于重要的部分，我们也会把一些统计特征编码进去，当然也会把一些时间特征编码进去。因为我们知道很多电商的业务是有定期促销的习惯，比如淘宝的交易量每天早晨十点一定会有阶峰，大家不知道在抢什么东西。算法层面怎么解决？我们把每天的这个时刻第几小时第几分钟，通过热度编码的方式做到里面去，就可以让算法学到这个时间点这样一下可能是正常的。我们后面采取了不同类型的统计学的判断和做法，最后做成集成策略，大家可以理解为简单的投票策略。它其实给我们带来了比较好的一些算法的效果，比如说基线拟合会更准，对于不同类型的异常进行判定。很多时候曲线有不一样的异常，如果用 N-sigma 的方式，你的刻画表现能力是不够的。即使是这样，对于遇到的新零售业态，我们觉得还是不够。因为你看刚才的算法能解决一般性的问题，但是对于曲线问题差异很大的时候，之前的预处理就需要增强，量级从十万左右到几百万，你的预处理策略需要变化。很多曲线不具备周期性，或者周期性非常零乱。比如我们有一个业务比较奇怪，大家在淘宝上有没有充话费？这个是天、周、月三重周期，天的话基本没有问题，周的话工作日和周末是有差异的，月这个周期，因为大部分人是在月末报警了或者月初充。最后一个线下的业务对这种异常很敏感，在这种情况下我们用一套算法策略是解决不了不同问题的，所以我们做了第三次优化。我们先引入了一层算法路由，希望能够通过机器学习的方式，把不同的曲线归到不同的算法路由里面去，这样的话不同的曲线走不同的处理路径，那么效果会很好。我举三个例子，比较周期性、非周期性、百分比的指标等等，这些不同类型的指标方法都不一样。在这些不同的方法之后，我们还是觉得算法也许解决不了所有的问题，因为算法对于大多数运维工程师来讲，不见得那么方便去调参数，所以我们也开放了三个参数，我们会看它不同的抑制时间、发布策略和敏感度。分开来看，算法路由，这个工作的目的就是说让算法自动把数据分类，这一块也不一定非得用算法，用人就可以，但是因为量太大，所以人工的成本很高。这里我们用了深度学习的算法，上面那个图是网络的图，我们使用了孪生网络，两边都是LSTM，所以我们用了双向的网络结构去把我们标记为一样和不一样的，最终能够区分开。在这个基础上，我们做了一个分类模型。这块从技术层面来讲，不用特别复杂的算法，我们用这个算法就是想探索一下，实际大家真正做的好的话，比如你用一般的分类方法，用我们最直接方法也可以达到类似的效果，但是我们这里尝试了一下。分好之后有个工程架构，以前是说不同的算法场景走的处理逻辑都是一样的，里面的参数可以不一样，后面不同的处理逻辑像插件一样可以去做组合，这个组合的变化频度不会太快，但是一般变化成本都很低。这样以前是三条通路，我把插件的参数和顺序和有没有插件做一个变化。有了这个之后，对于阿里巴巴成千上万条，但都是到万这个级别，不会再多。大家会想这个东西可能是从业务角度监控的，从惯性思维来看，我们可能会是想监控 CPU 或者某个接口调用的超时，这些也是可以的。我们也探索了在系统级指标或者非应用级指标做这个尝试。它的周期性不太明显，第二个这个指标的变化跟业务行为关系不那么大，运维的决策对它的曲线影响大于业务的影响。最后一个就是标准不统一，你觉得这个可能需要报警，别人可能觉得不需要报警。我们采取了一种轻量级的方式去做检测，可以做到自动学习。它跟上面那套算法相比在于它比较轻，可以做成一个包的形式，嵌到监控系统中去做监测。它的效果如上图右边显示，我们内存中有奇形怪状的异常，这个算法逻辑还是比较简单的，不用太在意算法本身的框架，因为这些算法你可以替换成其他的算法，但可能需要考虑在数据进来之前做比较好的预处理。第二个可能你需要基于统计特征和那些曲线本身的特征，影响你的特征工程。最后孤立森林不是说基于用户的标注去做的，因为实际场景中我们不可能像做人脸识别这样给我们标注。什么参数微调？第一个是说抑制报警的时间，这个很容易理解。第二个防抖动策略，这个也很容易理解，就跟过去 N 分钟有 N 条报警是一样的，所以我们概括成N/M。最后一个是报警灵敏度。这个在我们市场环境中测试的效果大于70%，现在这个数字可能稍微好一些。最终怎么评价算法？还是要看人标的。比如说我们有十几位同学评判，他们的标准也不统一。甚至一个人今天说这个点标的对，第二天忘了再看一遍就说标的不对。所以说以上是我们介绍的关于单个指标，不管是系统级的还是业务级的指标，怎么通过机器学习的方法，做不用任何监控阈值配置和维护成本的智能监控。三、多指标关联分析的探索刚才也提到了在新业态下，很多时候我们只看一个指标是没有办法判定业务有没有异常，或者我们发现指标和指标之间是有关联的，这个在实践当中也会遇到。有时候两个指标都出了问题，这时这个信息能不能被利用，我们也做了探索。这个东西有一个业务背景，就是我们刚才提到的看一个指标不够，我们经常在一些业态里看到会监控某一个业务的成功量、成功率、失败的错误请求数几个指标相关变化。有时候会发现指标有异常传播，这个传播有几种方向传播。比如说在不同的业务之间传播，比如因为两个程序之间有关联关系，A坏了B也影响了。还有就是混合部署的情况，同一个集群布两个业务，A被打爆，B也被压死了，也有这样的情况。我们怎么做这个事情？分为两步。第一步我们希望发现和维护相关的指标，就是哪些指标应该有关联的，发现之后要维护。一旦我们掌握这个信息之后就可以做两个事情。第一种我们能够把这些相关指标放在一起判定业务是不是异常，而不是只看一个指标。第二种我们单指标能看的很准，但这时候我想知道为什么会下跌，虽然给不出因果，但是可以给出相关。业务指标之间的相关性其实有不同的类型，比如上下游之间有监控项，比如我们在阿里做过一个实际情况，大家看淘宝搜商品，如果出现异常大家就搜不了东西，我们的淘宝详情页的浏览量和下单量都会下降。不是说搜索的程序或者应用服务掉了那个服务，它们之间没有关联，但是很多用户习惯了搜而买。一但搜挂了，很多用户不知道怎么买了。所以这样的关联靠系统内部是拿不到的。包括业务不同分量的监控，比如河南省播放成功率和河北省播放成功率之间的关联。这种关联我们怎么发现？一定是靠人工梳理，但是对于阿里的体量，一个是梳理不过来，第二个梳理以后过两天又变了。阿里集团可能每天的业务发布的频次是千级别的，那怎么办？还有第三种方式。第一种利用 CMDB，我们通过CMDB看到哪些应用之间可能相关。第二个通过 时间序列相关性 发现了方法，这个跟刚才提到的卵生网络的方法是类似的。但从实际来看，一般是在第一个检测的基础上，再在局部做第二个，而不是全局的检测。第三个我们利用关联规则挖掘看哪些项经常关联报警。我们可以通过算法发现这些关系，这三个方案其实是互补的方案。所以有了这三个方案后，就可以把很多相关的指标放在一起监控，方案取得了较好的效果。在盒马鲜生，基于我们上面做的新的算法，单指标架构和多指标关联架构，能够把监控发现率和误报量做非常好的提升，这就是我们在新业态下通过单个指标的算法和多个指标的算法取得关联效果。四、故障影响面和根因分析的探索之前都是关于监控的部分，监控是为了发现问题，但是发现完了问题，很多时候是需要想怎么能够解决问题的。我们在故障根因的推荐层面做过一些探索，但这个也只能是探索，供大家参考借鉴。首先我们看一下故障原因分析问题的范围和边界，我也跟很多工程师交流过，凡是做运维系统的工程师都有一个梦想，就是我想做一套系统，一旦我的业务出问题，告诉我问题原因在哪，这个非常理想化。但在实际过程中，这个事情是非常难解决的，探索来说在阿里内部也解决地不好。虽然解决的不好，我们也做了一些探索。为了避免我们做的事情不符合我们老板或者客户的预期，我们需要先把能做什么说清楚。我们很难做到淘宝交易量下跌了，我告诉你哪个代码有bug，这个做不到，但是我们能做到缩小影响范围。这个为什么有价值？因为阿里巴巴有两到三万名工程师，半夜两点出了问题，我打电话叫起来就是一个非常复杂的技术问题。首先要从阿里巴巴几万个应用程序里，先要看这个业务故障到底跟哪几个应用相关，这个都是非常典型的问题。我们的目标是能够从站点、产品线和业务功能指标出现问题的时候，能够定位到应用服务层，包括数据库这层。这个架构就是能够锁定这个范围，然后之后的事情可能需要更细致的方式解决。另外一个好处，我们可以对故障做一个结构化的快照，除了阿里巴巴，我看到很多公司也会对故障做复盘做改进措施，但是没有形成很好的流程。但是在阿里我看到过去大大小小非常严谨的复盘和故障记录，包括非常多的细分的环节和字段，这个非常好，因为以后的故障可以从中学些东西。但是有个遗憾，这些东西全是用汉语写成的，长篇大论几千字。人可以去读，但是比如阿里有另外一个工作叫全链度压测，我们要对去年的业务优先进行测试，这个时候我们要挖掘到底哪些有问题。挖不出来，为什么？都是汉字写的。汉字写的话，它的表述、格式，都是很难被机器理解的。如果做的这件事情以后出故障，我们尽可能地把故障做一个结构，这个不仅对这次故障的本身，对以后故障的防范都有非常大的价值。怎么做？如上图所示，我们会有一个主的抽象流程，当我们的前面算法发现问题之后，我们会尝试找到跟这个业务指标相关的应用和它的中间件以及数据库，以及相关的网络服务器IDC。我们建立了一个囊括阿里主流的所有运维相关事件的这样一个数据仓库，阿里内部可能有自己的这种事件存储的机制。这个数据仓库能够告诉我们在哪些运维的对象上发生了什么事情，最后我们对这个事情做一个排序和筛选，把可疑的挑出来。逻辑还是比较清晰的，但是真正做的时候发现有很多具体的环节需要考虑。比如你怎么找到监控项关联应用，淘宝交易下跌了，你怎么知道是阿里的几万个应用中哪个应用造成的问题？这个其实也是比较难的问题，我们也没有解决太好，但是可以看到思路。最直接来讲，我们通过监控系统本身的配置来得到。我们的业务指标能画成一张趋势图，能做监控，因为背后有逻辑计算，有日志的采集等等。这些系统的工作，是因为加监控的同学已经把监控怎么采集配置进去了。但是它有失效的时候，比如说两种情况。一种发现业务环境非常强，ABC三个程序不断做处理，最后把结果打到第四个程序上去了。所以你通过这个，能得到第四个应用的名字，前三个应用其实跟这个业务非常相关，但是你从这里读不到，所以这是我们要解决的。第二个有一些应用本身是用来监控的，比如阿里的客户端，它会上报到某一些监控系统，这时候监控系统画出来的曲线，其实跟监控系统本身相关的，而不是跟产生监控数据的应用相关的。这种情况下，这个方案就失效了。这个时候就需要通过人工配置的方式解决，目前是这两种方式结合在用。刚才说的第一个问题，我们也可以通过阿里巴巴的中间做的系统去解决这个问题，包括我们也可以通过算法，对于报警做平台挖掘，可以挖掘出来像刚才搜索框下跌，导致交易量下跌的关系等等都可以挖掘出来，这个东西也是补充的方式。但是最核心的不是算法，最核心的是CMDB如果维护得好，比什么都好。通过刚才那个思路，能够把我们的业务指标跟应用结合起来，但是很多时候应用经常是无状态的，状态存储在数据库集群里面，这个时候还是经常通过CMDB解决这个问题。还有比较难的问题，就是网络跟应用程序的关系，有一个机房出问题了，经常我们是混合部署的，所以这个时候问题其实是一个非常散的关联，这个问题上我们解决的也不好，所以我们只能把这个信息当成一个缺少的信息推荐出来，供大家去决策。比如说不管阿里什么业务出了问题，我们都会把网络最近出的一些异常点或者事情推送出来，提醒大家是不是这个问题，但是这块很难做到精细的管理。我们知道了哪些运维实体跟业务有关联之后，还要知道这些运维实体上、程序上、集群上、网络上发生了什么事情？那这个事情我们怎么知道？我们会建立一个在线的数据仓库，它能够不断地抓取来自于各个运维平台和系统中的不同格式的事件。这个抓取之后不是简单放一块存，还要建立关联索引。阿里有很多不同的横向纵向的系统，他们的数据格式的字段都不一样。我们尝试做一个翻译，在当中找到了两三个大家都能看懂的词。比如钉钉应用，这在阿里内部非常稳定的。第二个IP地址，这个也是很稳定的。但是这两个之外，格式语言是不一样的。我们把数据仓库建好之后，输入开始时间、结束时间和应用列表三个关键词，就可以查到这段时间内实体发生了什么事情。我把事情都推荐出来是不是就解决了？还不够。我给大家分享一个数字，在阿里巴巴内部，像这样的事情一分钟发生四千到六千次，也就是说一个故障如果持续了十分钟，就是几万个事件，所以我们还要再做筛选。这个时候就会通过一些方式做筛选，我们会根据哪些运维实际上发生了报警，把这些实体的信息优先放在前面。怎么知道有跳变？我们会对怀疑的对象做系统级指标的扫描，扫描出来跳变就排到前面去，所以有了这个之后就可以相对精确地缩小范围，当阿里巴巴淘宝天猫有异常的时候，我就可以知道。我们能够从上面看到，最上面这个环节是同一个时间内有多少业务的多少点在报警，红颜色的时候，可能就是某些业务出现短暂的异常了。我们会感觉 CMDB 加平台化算法对报警压缩合并，看到了集中在优酷、集团客户体验、菜鸟这三个业务功能上。这个其实就是刚才讲的多指标关联分析的作用，这时候我也不知道是不是因为它导致的，但是他们之间是相关的，这个可以帮助我们定位。最后我们能够根据刚才说的逻辑，把跟这个事情相关的前五个或者前十个应用程序推荐给你。为什么推荐给你？要么它发生了一些骤变，要么发生了一些大的业务操作。很多时候可能百分之五六十的业务故障，都是发布新功能或者改配置改错导致的。做的比较好的地方，可能能够做到70%以上的推荐准确率。但是也有做的不好的，百分之三四十的准确率。因为阿里业务很复杂，每个环节每个业务都有不一样的方式。但是这个方法，我认为还是一个值得推广和借鉴的大逻辑上的思路，这个就是我们介绍的监控发现问题之后，我们在根因分析层面有哪些探索和思考。五、智能运维在故障治理领域的未来规划最后希望能够和大家一起探讨一下在智能运维领域现在与未来可以做什么事情。运维本质上是解决在线服务运行中的质量、成本和效率三方面，运维不是从上到下的思路，包括我也参与了白皮书的工作，我们也跟其他业界的同事探讨这个问题，不是说有一个顶层规划要怎么做，实际是在这些点所处的具体环节上，很多工程师开始尝试用算法的方式解决问题，逐步汇集成一个数。我们现在在上图左边那条路做了一些探索，已经在业务中用起来了。最早的探索，其实在阿里内部已经稳定运行了接近两年时间，也是效果在不断演化演进。最近我们也在探索右边这条路，就是无人值守相关的东西。出问题的时候很多人问淘宝的故障恢复了没有，支付宝有没有受影响。靠自然语言提出的问题，是不是可以通过机器人回答你，这个也是我们探索的。当然现在还不敢做全自动，还是我们列出来你再确认一下，但已经比你调出系统然后跟很多人沟通半天决策要方便一些。所以其实不仅是在质量领域我们做智能化的监控，智能化的根因分析，其实在节省人效率层面，也可以做一些探索。中间这块跟成本相关，这块在阿里巴巴有很多团队做这样的事情，也可以通过智能化的调度能够做容量预测，优化包括硬件采购的周期，预测你服务器增长怎么样。或者在实施的时候，通过自动化的调度策略，节省服务器的资源。所以其实智能运维这个概念，在今天已经不是个概念，它已经在我们企业实际工作中，有非常多落地的点。希望今天我的分享，能给大家有一些借鉴和参考，我们一起建设智能运维美好的明天。说明：以上内容为阿里高级技术专家王肇刚在 GOPS 2018 · 上海站的分享。本文作者： 王肇刚阅读原文本文来自云栖社区合作伙伴“高效运维”，如需转载请联系原作者。

12月4日，google flutter团队宣布第一个flutter正式版本发布。次日，Flutter Live Beijing 会议上，google flutter团队邀请了在这一技术方案中重要的合作伙伴闲鱼团队分享这半年以来的通过flutter产出的业务结果以及对应的技术挑战。本文根据Flutter Live Beijing嘉宾闲鱼客户端团队负责人于佳（宗心）的演讲内容进行整理，从flutter的优势和挑战引出闲鱼这半年来针对flutter基础设施进行重新的构建，定义，以及优化的过程，最后是这半年来对社区的一些贡献和未来的规划。Flutter的优势与挑战众所周知，Flutter提供了一套解决方案，既能用原生ARM代码直接调用的方式来加速图形渲染和UI绘制，又能同时运行在两大主流移动操作系统上，其像素级别的还原，保证了不同平台的UI强一致性。同时其提供了一整套机制（hot reload/attach Debug）保证开发的高效，基于此闲鱼团队在众多跨平台方案中选择了Flutter作为其未来主要的开发方案。从4月份开始尝试在业务侧接入flutter到现在，闲鱼在线上已经有10+的页面使用了flutter进行开发，其中覆盖了核心主链路发布和详情。闲鱼目前是市场上最大的闲置交易社区，作为一款有巨大用户体量的C端创新类产品，我们对体验以及研发迭代效率都有比较高的要求。在享受flutter带来的收益的过程中，同样会面临技术转型过程中的一些挑战。主要的挑战来源于以下的三个方面工程体系在现有工程体系下如何将flutter体系融入，并保持团队不同技术栈（Android/iOS/Flutter）的同学能各自独立高效进行开发。业务架构如何提供一套flutter之上的业务架构，保证上层代码的统一标准，同时尽可能的使得代码的复用度及隔离性更好。基础中间件如何保证不同技术栈背后使用的基础能力是一致的（底层统一使用具有相同优化策略的图片库/音视频库），且在这个过程中如何解决flutter融入后产生的问题。面对这些挑战，闲鱼团队在下半年开始了针对基础设施的改造与重建。基础设施重建之路工程体系工程体系部分，首当其冲需要考虑的是不同技术栈同学的协同问题，举例说明，我们的详情和发布页面是flutter的，而首页以及搜索部分目前暂时采用native进行开发。这就需要考虑到flutter的环境要对开发native的同学透明，甚至在native同学没有安装flutter环境的情况下，依然可以保持原来的方式进行开发native页面。如图中所示，以iOS为例，我们针对flutter的框架flutter.framewrok和业务代码App.framework通过持续集成服务进行打包并自动上传至云端的pod repo上，native同学只需在Podfile内指定对应的两个库的版本即可，同理，针对flutter的plugin代码，同样打包上传至pod repo即可。这套体系整体不复杂，需要说明的是，由于多人开发flutter工程，因此打包是一件非常频繁的事情，因此我们这半年构建了持续集成体系来帮助大家将打包上传等整个体系做成一键式服务，另外，由于原有iOS平台的flutter产物是需要依赖我们的native主工程的代码的，这种默认的打包方式，代码量巨大，造成持续集成时间在10-20分钟不等，因此在这个过程中，闲鱼团队通过直接基于xcode_backend.sh + insert_dylib的自定义脚本完成了不依赖native主工程源码的打包，将持续集成时间降至2分半。同理在android上面，也进行了一些基础的改造，感兴趣的同学可以给我们留言，我们会根据大家的需求程度在后续安排贡献给flutter社区。另外一部分比较重要的内容是混合栈相关的，由于flutter没有提供flutter到混合工程的最佳实践，所以我们在上半年自建了一整套混合栈的体系，这里主要是分享一些混合栈的关键思考，在混合栈的实现过程中，需重点测试验证dart这一侧widget的生命周期，并简化堆栈的管理（目前闲鱼的做法是将堆栈管理统一交由native进行控制，简化Dart层API），并需要考虑如何兼容Dart上层的比如Navigtor API的调用。整体这部分闲鱼团队还在验证当中，总之，这部分看似简单，但实际是比较深的坑，需要重点优化。另外，截至发文时间前，我们跟google flutter团队就混合栈交换了一些看法，flutter团队后续如果可以提供多flutterview，单flutter engine的基础能力，就可以使得闲鱼现有的混合栈实现成本整体大幅度降低，后续大家有什么特别好的建议，也欢迎跟我们进行交流。业务架构今年下半年由于有更多的业务迁移至flutter，这意味着更多的团队成员开始了Dart侧的研发。很快我们发现团队的代码风格，层次结构都比较混乱，bug也层出不穷，因此我们需要找到一种可以保证大家研发规范，同时确保多人协同过程中，代码既能更好的复用，又可以在适当的场景下做到相互隔离的这么一种方案。在经过社区的多个框架库的实践和比较以后，不管是flex还是redux都不能完全解决我们的问题。最后我们选择了自己进行设计和实现，我们对框架进行基础分层以后，将重点最终落在了基于单一数据源的组件化框架上面，因此我们产生了自己的框架fishRedux，我们严格参考标准js的redux规范和源码（redux的设计三原则）进行了完整的dart侧的实现，并在此基础上提供扩展能力用于我们的组件化开发。如图所示，component将redux中的view，reducer，middleware以及我们的扩展能力effect进行组装，从而可以在不同的页面进行组件的复用，当然，全局依然遵循redux的单一数据源的原则，但我们将逻辑本身通过更细粒度的拆解，保证了这些逻辑在不同的component组装下都可以尽可能的进行复用。基于这种结构，我们可以将任意的component进行挂载和拼装，通过更多小粒度的组件，产生不同场景下的复杂页面。另外，针对于component的多层组装，大家可以细看下dependents这个字段，通过基于这个字段的组装，在我们提供的这段代码里面，实际上是提供了一个详情页面的插槽的功能，详情页面目前在闲鱼有近10种不同的组合，在这个场景下，可以在保证组件可以服用的同时，做到不同流程下的代码隔离。我们只要针对dependents的components里面进行替换，就可以很容易的达到在详情页面插入不同widget以及逻辑的效果。fishRedux框架目前已经接近修改的尾声，目前还有部分微调和文档的补充，明年4月份前，我们有计划进行该框架的开源，为后续业务架构提供一个新的标准，大家敬请期待。基础中间件在阿里集团内部，已经产出了较多的基础中间件，因此如何复用这个中间件到flutter侧是一个新的挑战，针对于传统的比如网络库，crash收集等中间件，由于不涉及到UI的复用，相对容易，但针对音视频，图片库等这类的中间件，虽然flutter提供了flutterTexture的方案，但依然不是特别完美。我们在做音视频及图片库的复用过程中，主要的问题在于flutter原生提供的机制，针对图片的渲染存在GPU到CPU，然后CPU再到GPU的这样一个过程，如图所示。根本原因在于不同的glContext无法共享texture。因此，我们目前采取的方案是修改flutter引擎，并暴露出glContext的shareGroup（以iOS为例）。目前整个方案已经上线。由于该改动目前在闲鱼自己fork的engine里面，因此目前将我们之前踩到的一些坑同步给大家，如果大家有在flutter和native侧同时使用音视频的情况，建议特别注意ppt中的前两点，否则会造成flutter侧或者native侧音视频的错乱。当然如果按照闲鱼团队的提供的修改方案进行engine改造后，也可以通过第三点，对native设置跟flutter相同的sharegroup来解决这个问题。在flutter live Beijing结束之后，我也将该方案正式介绍给google flutter团队，希望后续能将类似的功能融入flutter的官方实现。闲鱼与flutter社区闲鱼这半年，对于flutter社区，也有一些小小的贡献。我们针对flutter的方案进行整理并在各个技术社区进行传播。另外我们将已有的一些问题和解决方案提供给google flutter官方团队，直接或者间接的推动了flutter的整体进度，并改变了这个技术未来的部分走向。我为自己的团队感到由衷的骄傲，但同时我意识到，要想让flutter成为终端未来的主流技术，依然任重道远，因此我们后续也会将目前的一些相对稳定的框架和解决方案，逐步开源到社区，我们的要求是，至少闲鱼团队需要在线上有应用和验证。目前我们已经有一些初步的demo和小工具放在上面，大家感兴趣的可以往我们的github上提issue，我们后续会逐步开放更多的代码。最近会公布的比较重要的框架会是fishRedux，因此请大家持续关注我们。总结与展望我们首先带大家回顾了flutter带来的优势以及在闲鱼的实际例子，并引出在复杂工程下的一些挑战。我们针对这些挑战，在下半年进行了整个体系的重新建设，初步完成了隔离的混合工程体系统一标准的业务架构高效复用基础中间件设施本次的分享，其实只是我们目前团队的一部分内容，我们基于flutter和dart还有更多的技术方案目前在预研和研发中，所以没有在这次live中进行宣讲。在后续跟google flutter团队的沟通中也了解到，他们对我们的多个方案都有较大的兴趣。对于未来来说，一方面，除了本文分享的内容以外，我们自己在代码自动生成/Dart Server/线上问题自动回放/国际化/动态模版等/持续集成等多个方面都在持续关注和调研。另一方面，在flutter 1.0公布后，类似hummingbrid这一类全新的方案也有机会让flutter具有全终端制霸的可能性，我们也会持续跟进和进行尝试。Anyway，依然希望有更多的同学可以加入我们一起完善flutter的生态，同时通过新的技术手段，让天下没有闲置。来闲鱼一起改变世界吧，少年！PPT下载：https://yq.aliyun.com/download/3130本文作者：闲鱼技术-宗心.阅读原文本文为云栖社区原创内容，未经允许不得转载。

阿里妹导读：数据库从IOE（IBM小机、Oracle商业DB、EMC存储）一路走来，大家都知道数据库是资源重依赖的软件，对服务器的三大件CPU、内存、磁盘几乎都有要求。数据库作为广泛使用的数据存储系统，其SQL请求背后涉及的物理读、逻辑读、排序过滤等消耗了IO和CPU资源，业务SQL不同，执行计划不同，资源消耗就不同，因而不同业务对资源规格的需求也不一样。正因如此，我们更需要抽象规格，更好地让不同资源诉求的数据库实例混跑在相同的物理机上，提升整体利用率。今天，阿里资深技术专家天羽为我们讲述阿里数据库的极致弹性之路。除了日常业务需求，阿里的双11场景，让我们持续思考如何低成本高效率地支持峰值流量，把这些思考变成现实，变成技术竞争力。在大促资源弹性上有这么几个思路：使用公共云标准资源弹性，直接用阿里云的标准资源支撑大促后归还。这个是最直接的想法，但这里的难度是业务需求和云资源在性能、成本上的差距，不要定制化机器。混部能力，存量业务的分类混部、分时混部。使用离线资源支撑大促，既是分类混部，双11零点离线降级，高峰后在线归还资源也是分时复用。快上快下，在有能力使用云、离线资源后，尽量缩短占用周期。碎片化资源，数据库一直是块石头，是一个大块完整的规格。如果把数据库自己的大库变成小库，就可以使用其他业务的碎片化资源，包括公共云上的资源。大促的成本=持有资源X持有周期，更通用的资源（云）、更快的部署（容器化）是缩短持有周期的关键，如何更少地使用资源（使用离线或只扩计算资源），就依赖存储计算分离架构的实施。沿着极致弹性的目标，数据库经历了混合云弹性、容器化弹性、计算存储分离弹性三个阶段，基础架构从高性能ECS混合云、容器化混合云、存储计算分离的公共云和离线混部一步步升级。基本上架构演进就是每年验证一个单元，第二年全网铺开，每年挖个坑然后和团队一起努力爬出来，每次演进需要跨团队背靠背紧密合作，快速拿下目标，这也是阿里最神奇的力量。借助于底层软硬件技术发展，一步步的架构升级使得弹性混部越来越灵活和快速。 一、混合云弹性，高性能ECS应运而生2015年之前，我们的大促弹性叫人肉弹性，也就是大促要搬机器，比如集团用云的机型支撑大促，大促结束后搬机器归还给云。但就在2015年底的一次会议上，李津问能否把数据库跑到ECS上，如果可以，就真正帮助了云产品成熟，当时张瑞和我讨论了一下，在会议上就答复了：我们决定试一下。这个合作非常契合会议主题“挑战不可能——集团技术云计算战区12月月会召集令”。对于数据库跑在虚拟机上，我们判断最大的消耗在IO和网络的虚拟化上，因此如何做到接近本机性能，怎么穿透虚拟化就是一个问题。网络的用户态技术DPDK已经比较成熟，但如何做到足够高的效率，是否offload到硬件来做计算是个问题。文件系统IO的用户态链路有个Intel的SPDK方案，Intel推出后各大厂商还在验证中，还没有规模的应用。我们就在这个时候启动的这个项目，叫高性能ECS。通过和ECS团队紧密合作，最终我们做到了最差场景高性能ECS相比本地盘性能损耗低于10%。2016年在集团通过了日常验证，2017年大促开始大规模用云资源直接弹性。这个项目除了打造高性能ECS产品，更重要的是沉淀了网络和文件IO的纯用户态链路技术，这是一个技术拐点的产生，为阿里后续存储计算分离相关产品的高性能突破打下了基础。二、容器化弹性，提升资源效率随着单机服务器的能力提升，阿里数据库在2011年就开始使用单机多实例的方案，通过Cgroup和文件系统目录、端口的部署隔离，支持单机多实例，把单机资源利用起来。但依然存在如下问题：内存的OOM时有发生存在IO争抢问题多租户混部存在主机账号等安全问题数据库主备机型一致性随着单机部署密度越来越高，社区Docker也开始发展起来，尽管还不成熟，Docker本身依赖Cgroup做资源隔离，解决不了Cgroup的IO争抢或OOM问题，但它通过资源隔离和namespace隔离的结合，尝试对资源规格以及部署做新的定义，因此我们看到了容器化更多的优势：标准化规格，数据库与机型解耦，主备不需要对称。这对规模化运维带来极大的效率。Namespace隔离带来混部能力，资源池统一。不同数据库类型，不同数据库版本随便混。让DB具备与其他应用类型混部的条件。2015年数据库开始验证容器化技术，2016年在日常环境中大量使用。因此在集团统一调度的项目启动后，我们就定下了2016年电商一个交易单元全部容器化支撑大促的目标，承载交易大盘约30%，并顺利完成。2017年数据库就是全网容器化的目标，目前数据库全网容器化比例已经接近100%。容器化除了提升部署弹性效率，更重要的是透明底层资源差异，在没有启动智能调度（通过自动迁移提升利用率）前，仅仅从容器化带来的机器复用和多版本混部，就提升了10个点的利用率，资源池的统一和标准部署模板也加快了资源交付效率。容器化完成了底层各种资源的抽象，标准化了规格，而镜像部署带来了部署上的便利，基于数据库PaaS和统一调度层的通力合作，数据库的弹性变得更加快速灵活，哪里有资源，哪里就能跑起数据库。 三、计算资源极致弹性，存储计算分离架构升级实现了容器化混合云，是不是每年大促使用高性能ECS，容器化部署就可以了呢？其实还是有不足的：数据库弹性需要搬数据，把数据搬到ECS上是非常耗时的工作。 弹性规模太大，如果超过公有云售卖周期，会增加持有成本。因此如何做到更快、更通用的弹性能力，是一个新的技术问题。随着2016年调度的发展，大家考虑机器是不是应该无盘化，是不是应该存储计算分离，从而加快调度效率，而数据库的存储计算分离更是争议很大。数据库的Share Nothing分布式扩展已经深入人心，存储计算分离会不会回到IOE状态？如果IDC是一个数据中心，应用就是计算，DB就是存储，DB自己再做存储计算分离有意义吗？数据是主备双副本的，存储计算分离后变成三副本，存储集群的容量池化能balance掉额外副本的成本吗？为此我开始测算存储计算分离架构在大促场景下的投入产出，我们来看下大促场景，弹性大促时，业务需求计算能力数倍甚至10倍以上扩容，承担大促峰值压力，而磁盘因为存储长期数据，峰值的数据量在整体占比不高，因此磁盘容量基本不需要扩容。在以前本地磁盘跑主备的架构，无法计算、存储分开扩容，大促指标越高，添加标准机器越多，成本浪费越大，因为磁盘是标准数据库机器的主要成本。而存储计算分离的情况下，测算下来，我们看到在较低日常压力下存储计算分离成本是比本地盘高的，但再往上，存储计算分离只需要增加计算，存储集群因为池化后，不只容量池化了，性能也池化了，任何高负载实例的IO都是打散到整个集群分担的，磁盘吞吐和IOPS复用，不需扩性能，成本优势非常明显。磁盘不扩容，只扩计算自然成本低很多。传统的思考是存储集群容量池化的优势，但在大促场景我们更多用到的是性能的池化，突破单机瓶颈，因此我们提出了电商异地多活所有单元存储计算分离，其余业务继续使用本地磁盘进行同城容灾的目标架构。提出这个设想，而这个架构的可行性如何判断？基于一些数字就可以推断，大家知道SSD磁盘的读写响应时间在100-200微秒，而16k的网络传输在10微秒内，因此尽管存储计算分离增加两到三次的网络交互，加上存储软件本身的消耗，整体有机会做到读写延时在 500微秒的范围内。在数据库实例压测中我们发现，随着并发增加，存储集群具备更大的QPS水位上线，这印证了性能池化突破单机瓶颈带来的吞吐提升。数据库团队在2017年开始验证存储计算分离，基于25G的TCP网络实现存储计算分离部署，当年就承担了10%大促流量。我们基于分布式存储做到了700微秒的响应时间，这里内核态和软件栈的消耗较大，为此X-DB也针对性地做了慢IO优化，特别是日志刷盘的优化，开启原子写去掉了double write buffer提升吞吐能力。这个过程中，我们沉淀了存储的资源调度系统，目前已经作为统一调度的组件服务集团业务。我们对当前架构性能不太满意，有了X-DB的慢IO优化、存储计算分离跨网络的IO路径、存储资源调度等技术沉淀，加上阿里巴巴RDMA网络架构的发展，2017下半年数据库开始和盘古团队一起，做端到端全用户态的存储计算分离方案。四、全用户态IO链路的存储计算分离架构落地 从数据库软件X-DB的IO调用开始，就走我们自己研发的用户态文件系统DBFS，DBFS使用盘古的用户态客户端，直接通过RDMA网络访问后端盘古分布式文件系统，整个IO链路完全绕过了内核栈。这里DBFS绕过了内核文件系统，自然也绕过了pagecache，为此DBFS针对数据库场景，实现了更简洁高效的BufferIO机制。因为IO都是跨网络远程访问，因此RDMA起到了重要作用，以下是RDMA与TCP网络在不同包大小下的延时对比，除了延时优势外，RDMA对长尾IO的tail latency能够有效控制，对一个数据库请求涉及多次IO来说，对用户请求的响应时间能够更有效保证。RDMA技术的应用是DB大规模存储计算分离的前提条件，通过我们的数据实测，DBFS+RDMA链路的延时已经和Ext4+本地盘达到相同水平。今年我们首次大规模部署RDMA，如履薄冰。经过多次压测、演练， RDMA配套监控和运维体系建设已经完善起来，我们能够在1分钟内识别服务器网卡或交换机的网络端口故障触发告警，能够故障快速隔离，支持业务流量快速切走，支持集群或单机的网络RDMA向TCP降级切换等等。在我们的切流演练中，从DBFS看到RDMA链路的写延时比TCP降低了一倍。我们在全链路压测中，基于RDMA技术保障了在单个数据库实例接近2GB吞吐下磁盘响应时间稳定在500微秒左右，没有毛刺。盘古分布式存储为了同时支持RDMA、EC压缩、快照等功能，做了大量的设计优化，尤其对写IO做了大量优化，当然也包括RDMA/TCP切流，故障隔离等稳定性方面的工作。作为阿里的存储底盘，其在线服务规模已经非常庞大。整个技术链路讲清楚之后，说一下我们在规模应用中遇到的难题，首先，容器的网络虚拟化Bridge和RDMA天然不兼容，由于容器走Bridge网络模式分配IP，而这个是走内核的。为了应用RDMA，我们必须使用Host网络模式进行容器化，走Host + X-DB + DBFS + RDMA +盘古存储这样的全用户态链路。其次，对于公有云环境，我们通过VPC打通形成混合云环境，因此应用通过VPC访问数据库，而数据库使用物理IP用于RDMA访问盘古以及X-DB内部X-Paxos。这个方案复杂而有效，得益于DBPaaS管控的快速迭代和容器化资源调度的灵活性，这些新技术能够快速落地，在变化中稳步推进。今年年初，我们定下了2018大促的支撑形态，即异地多活的中心机房将计算弹性到大数据的离线资源，单元机房将计算弹性到公共云资源，不搬数据直接弹性扩容，快上快下的大促目标。今年DB全局一盘棋，完成了资源调整，实现了电商各站点的存储计算分离架构升级，并通过X-DB异地多副本架构灵活部署，实现了弹性大促目标。基于底层盘古分布式的共享存储，弹性不需要迁移数据，只需要挂载磁盘，数据库可以像应用一样快速弹性，做到一个集群10分钟完成弹性扩容。同时在全链路压测过程中，对出现性能瓶颈的业务，我们可以边压边弹，快速弹到更大的规格上。基于快速弹性的能力，今年DB所有站点的大促扩容都在三天内完成，这在以前是不可能实现的，这就是存计分离的架构带来的效率。最后，感谢阿里内部通力合作的盘古、网络、调度、IDC等团队，正是大家的支持让阿里数据库的基础架构才能不断升级，不断提升效率和成本的竞争力。数据库存储计算分离的架构升级，大大节约了大促资源成本。目前我们的弹性能力正在日常化，通过数据预测，自动触发弹性扩容，我们的目标是让单机容量问题导致故障成为历史。 接下来我们平台将向智能化发展，对于数据库来说，只有基础架构足够强大，足够快速，灵活，弹性，智能化才能有效发挥。本文作者：天羽 阅读原文本文来自云栖社区合作伙伴“阿里技术”，如需转载请联系原作者。

阿里妹导读：努力和选择，对于技术人的成长来说，至关重要。今天，阿里基础设施负责人毕玄，将和你分享他多年的经验和心得。文章不长，但值得所有正为职业发展而迷茫的技术同学细细品味。工作这么些年了，看到了各种各样的程序员，也看到了各种各样的成长路线，说说自己的一些观点吧。作为技术人员，在刚起步阶段时，首先需要拓宽自己的技术宽度，对自己所做的项目/产品所涉及的方方面面的技术都应该有所了解，另外对于就是学习工程化，让自己真正具备开发商业软件的能力。在工程化和知识宽度达到一定阶段后，需要开始根据自己的兴趣和工作内容有所选择，主要是加强在某一领域的技术深度。在技术深度达到了一定阶段后，需要对自己做出一个选择，就是偏业务方向，还是偏基础技术方向。偏业务方向的技术人员，我认为做的好的表现是：对业务发展的未来有一定的预判，有商业敏感意识；能对复杂的业务进行合理的抽象；在系统的设计上能对未来业务的变化有一定的预留处理。偏基础方向的技术人员，我认为做的好的表现是：能结合业务的发展趋势对基础技术的方向有一定的预判，避免业务发展受到基础技术的拖累；对业界的技术发展方向有自己的认知和判断；在对应的基础技术领域有不错的技术深度。结合自己的特质以及当前的一些状况，做出一个选择，重点发展。而再往更高阶走的同学，通常就会出现一种新的角色，就是成为团队leader，做为一个技术团队的leader，无论是业务的还是基础技术的，在技术能力上还是不能差的，尤其是判断力上，另外，作为一个团队leader，就意味着承担了团队方向的判断的职责，一个团队的方向基本会直接影响到团队所有成员的未来，以及所支持的业务的发展状况，所以对于一个团队leader，我觉得最重要的能力就在方向的判断上，然后是根据方向的判断的组织建设（团队搭建，人才识别、培养、招募等）能力。如果不是往leader方向呢，那基本就是往架构师方向为多，架构师的话，在至少一两个领域的深度外，对广度的要求非常高，还有同样就是判断能力，无论是业务架构师，还是基础方向的架构师，领域的知识宽度是非常重要的，意味着能做多大范围的事，判断能力会体现出一个架构师在做一个架构设计时重点是怎么判断的，在有限的资源和时间情况下取舍是怎么做的，对未来是怎么做铺垫的，以及TA对事情的技术控制能力，一个好的架构师在技术风险的控制能力上必须是非常强的，例如一个强大的基础领域的架构师，应该是可以很好的控制跨多个专业技术领域的技术演进。还有一种是往专业技术深度领域方向走，例如内核、JVM等，这些领域是真正的需要非常深的技术功底才能hold的住的。还会有其他例如转型往业务产品方向等发展的就不在这说了。总而言之，言而总之，我觉得在整个成长过程中，兴趣是最为关键的，所以follow your heart非常重要，只有在有足够的兴趣或梦想的情况下才能产生很强的自驱，没有足够的自驱我觉得在技术领域基本上是不可能走到高阶的，除了兴趣外，自己的优势也要判断清楚，每个不同的方向，我自己认为还是需要一定的天分的，而所谓的天分我觉得就是对个人优势的判断。本文作者：bluedavy阅读原文本文来自云栖社区合作伙伴“阿里技术”，如需转载请联系原作者。

摘要： 构筑敏捷能力中心，打造下一代数字银行“操作系统”！小蚂蚁说：近年来，越来越多国内外领先银行全力投入数字化转型。数字化转型是技术与商业模式的深度融合，最终结果是商业模式的变革。银行数字化转型是一个逐步递进的旅程，敏捷能力中心的打造如同建设下一代数字银行“操作系统”，在银行数字化之旅中具有里程碑意义。银行业已进入全面数字化时代，数字化转型将从改善客户连接的1.0时代，进入到以敏捷能力为核心的数字化2.0时代。蚂蚁金服认为，打破过去独立分散的系统架构，铸造以分布式平台为支撑的金融敏捷能力中心，将成为银行机构全面数字化转型、提升客户服务能力的重要引擎。2018年11月29至30日，由《当代金融家》全媒体集团、鸿儒金融教育基金、蚂蚁金服主办的2018年（第七届）中国中小银行发展高峰论坛在广州举办，论坛围绕新时代中小银行金融科技与风险防控展开，来自监管层、股份制银行、国内城商行、农商行代表及相关机构领约300位专业人士出席峰会。在演讲中指出，银行数字化转型是一个逐步递进的旅程，敏捷能力中心的打造如同建设下一代数字银行“操作系统”，在银行数字化之旅中具有里程碑意义。他解释道，“敏捷能力中心从根本上解决企业的管理效率，以及服务终端、前台创新的问题，可助力银行不断快速响应、探索、挖掘、引领用户的需求，提升用户体验，降低服务成本，在全面数字化时代领先行业。”曾经，金融行业由于对可靠性和风险管理的要求高于一般行业，而后台修改的成本和风险较⾼，所以驱使他们会尽量选择保持后台系统稳定性的IT建设模式，把大量的业务逻辑（业务能力）直接部署在前台系统中，形成厚重的前台系统。这样便形成业务联系彼此割裂的状态，并未能很好地支撑前台快速创新响应用户的需求，降低了用户体验。随着IT技术的不断发展，曾经微服务、DevOps等技术也给出了技术上实现敏捷能力的“银弹”。但局部的方案未能从根本上解决全行级敏捷问题，银行的业务部门、研发中心、数据运维中心各自都是拿着拼图的一部分寻找方向。峰会上，蚂蚁金服结合自己的实践，从自身的实践总结出覆盖技术、数据、业务多个维度的敏捷能力中心，与广大银行业伙伴共享，以助力各家银行机构打造自身的“数字化操作系统”。据介绍，数字化时代敏捷能力中心包括以下几个方面：敏捷技术中心：把分布式架构体系涉及到的研发、测试、治理、运维、风险形成完整的支持全行应用的技术平台。除此之外还有三地五中心的灾备架构、免疫架构、防御资金安全和不断地、主动地发现故障等。这些技术能力体现蚂蚁技术敏捷中心不断追求的在分布式架构下的敏捷与自愈能力，将“不确定性变为确定性”。敏捷智能中心：把数据智能计算、数据研发、数据资产有机组合形成全行统一数据平台和金融智能应用，例如针对全行风险八大领域，构建全行级风险平台，实现风险管理统一化、风险技术平台化、风险数据规划化。敏捷业务中心：沉淀分布式架构下组件化、服务化的业务核心能力，向上提供平台化领域服务、开放式的编程接口来帮助快速构建存贷汇、互金等各类业务产品；同时封装了金融级分布式架构中的技术复杂性，降低分布式转型的学习曲线，提升分布式转型速度。纵观银行数字化发展历程，数字化1.0从移动端开始，着力于改善客户连接，提升业务触达能力。而刘伟光分析道，到数字化2.0时代，银行等企业机构重点在于通过分布式架构，获得数字化原生企业的标准技术栈能力，来建立与数字化原生企业相对标的三大核心竞争力：技术敏捷能力、数据智能驱动能力、业务敏捷能力，打造面向下一代数字化转型的数字银行“操作系统”。基于这些能力，银行可在未来的数字化3.0时代，建设多方位的生态合作新型银行模式：对内进行业务场景接入，对外通过API Bank向企业开放、建设基于API的应用生态市场模式，构建基于金融组件化操作系统的开放生态银行。本文作者：平生栗子阅读原文本文为云栖社区原创内容，未经允许不得转载。

摘要： 关于卷积神经网络最重要的概念都在这里！介绍这篇文章旨在以全面和简洁的方式介绍卷积神经网络（CNN），目标是建立对这些算法的内部工作的直观理解。因此，这项工作对于刚从这个主题开始的非数学、非计算机科学背景的读者来说意味着特别有价值。我写这篇文章的灵感来自于我正在参加的Fast.ai课程’Code Deeprs For Coders v3’，导师Jeremy Howard鼓励我们在博客上讲述我们学到的东西。我在这里分享的知识来自于阅读各种材料和参加不同的课程的成果，目的是在以医学影像的学生研究项目。这些帖子的主要部分取自我最近完成的这篇论文。在旅程开始之前，必须采取一些预防措施来对卷积神经网络进行透视。机器学习（ML）是计算机科学的子领域，通过具有学习能力的算法解决问题。“学习”通过内部组件的自动优化一个称为参数的权重。适用于ML的问题是两种形式的预测：回归-连续值的预测以及分类-通过类成员预测将对象细分为不同的组。深度学习（DL）又是ML的子域，通过将具有特定架构的算法（称为神经网络）应用于机器学习问题来区分。这种架构的灵感来自于自然界中的神经网络，并且包括-稍微简化-表示连接不同神经元的计算单元和边缘以及确保信息流动的神经元。其中存在多种不同类型的神经网络：人工神经网络（ANN），专门用于处理表格数据；用于时间序列数据的递归神经网络（RNN），如语音和卷积神经网络（CNN），特别适用于图像数据。有了这些基础知识，我们就可以开始研究后一种类型了。“解剖”CNN图1是网络的循环示例图，它的灵感来自LeNet（LeCun等，1998）第一个CNN架构。虽然CNN之间的特定架构不同，但它们的特征在于都有该示例网络所涵盖的规定元素。该算法旨在解决二元分类问题，例如猫与狗之间的区别。在这一点上，重要的是该图和紧接着的用于为演练创建框架。因此，不需要完全理解和熟悉所有术语。这些更深入的理解在即将到来的部分中逐渐形成，图1将作为便于读者大致的参考。从图1中可以看出，网络被细分为前向和后向传递。在前向传递期间，数据通过不同的层（图1：彩色箭头）。由二维阵列表示的输入图像（图1：左空矩形）被提供给给出名称的卷积层。该层识别输入数据上的轮廓和形状，并输出一组特征图（图1：垂直条纹矩形）。最大池层成为卷积层的成功之处，它成功的消除了无关紧要的部分，从而缩小了数据。此后，数据通过平均池化操作，将图像数据转换为矢量，进入完全连接的层（图1：水平条纹矩形）。这些图层在此向量中标识特定于类的模式，并在此基础上预测输入数据的类成员资格。到目前为止，还没有学习过，因为这是在向后传递中完成的。首先，通过损失函数量化分类误差，基于损失函数的结果，通过反向传播和梯度下降来优化前述层中的参数。很明显更高的迭代次数，即输入更多训练样本图像，是实现正确分类结果所必需的。完整训练数据集通过模型的点称为epoch。卷积，线性整流函数和最大池化术语“卷积”描述了特定类型的矩阵计算，其中称为滤波器的特殊目的矩阵应用于输入图像，如图2所示。滤波器（3x3矩阵）通常是较小的矩阵，在卷积运算中，它被放置在图像的子部分上：（图2中的3x3青色图像子集）。每对相应值的元素乘法和随后对所有乘积的进行求和，产生单个输出值。换句话说，图像子集的左上角值与滤波器的左上角值相乘，顶部中间值与相应的顶部中间值相乘，最后所有乘积都相加。之后，滤波器以滑动窗口的方式在输入图像的每个拟合子集上执行上述计算的图像上移动。得到的输出值被收集在称为特征图的输出矩阵中，其中特征图中的输出值的位置（图2：青色顶部中间值）对应于计算中涉及的输入图像子集的位置。过滤器在图像上的移动方式取决于步幅和填充。一个步骤描述了每个卷积运算将滤波器移动一个像素，从而产生更小的特征图（图2：步幅s=1）。通过向图像的外边界添加零像素来抵消特征图的尺寸减小，称为填充（图2：填充=0）。在卷积操作期间，大多数单独的滤波器应用于输入图像，从而产生每个滤波器的特征图（图2：滤波器和特征图后面的多个silhouttes）。换句话说，卷积层输出与其滤波器计数对应的一叠特征映射。可以将滤波器视为专用轮廓检测器，并且得到的特征图报告检测位置。如果过滤器放置在包含边缘的图像子部件上，它会将其转换为特征图中的高值。换句话说，高特征映射值表示特定位置处的输入图像中的轮廓检测。该过程如图3所示：如果过滤器到达由黄色和绿色框标记的子部分，则识别基础轮廓。因此，特征图也可以被视为图像并相应地可视化。图4显示出了对输入图像应用滤波器（图4：底行）以进行垂直或水平边缘检测的结果。过滤器值是权重、是学习的参数。它们在后向传递期间不断优化，同时更多的数据通过网络。通过这种方式，实现了调整过程：过滤器学习识别输入图像中可用的特定元素，并且可以将其可视化为图片本身。而早期图层中的过滤器（图5：左）将学习基本像素，如轮廓，后期图层中的过滤器（图5：右）将连接上游特征，并学习更复杂的构造，例如眼睛甚至脸部（ Zeiler和Fergus，2014）。因此，可以小心地将滤波器与视觉皮层神经元的感受野进行比较。这个被称为线性整流单元（ReLU）的函数应用于输出特征图（图6）。在令人生畏的名称下隐藏了一个简单的阈值步骤：零以下的所有值都归零。阈值化的特征图被移交给最大池化层（图7）。这里，虽然类似于卷积，但实际上发生了更简单的矩阵计算。过滤器再次以滑动窗口方式放置在要素图子集上，并提取子集的最高值，将它们保留在精简输出要素图中。目的是丢弃多余的数据：没有表示任何轮廓检测的值被划掉，而空间信息大致保留，这导致较低的计算成本。灵感和参考Jeremy Howard和Fast.ai深入学习编码器；Andrew Ng和deeplearning.ai的神经网络和深度学习；LeCun，Y.，Bottou，L.，Bengio，Y.，Haffner，P.，1998。基于梯度的学习应用于文档识别；Zeiler，MD，Fergus，R.，2014。可视化和理解卷积网络；本文作者：【方向】阅读原文本文为云栖社区原创内容，未经允许不得转载。

阿里妹导读：2018天猫双11物流订单量创新高，突破10亿件，这是一次史无前例的物流洪峰。天猫双11十年来，见证了物流业从手写地址、人工分拣，到电子面单、机器人分拣。无论是物流园区、干线运输，还是秒级通关、末端配送，都通过技术高效连接，智能物流骨干网正在加快实现行业数字化、智能化升级。因此，阿里技术推出《菜鸟智慧新物流》专题，邀请菜鸟技术人，为你揭秘物流核心技术。今天第二期，我们将了解到“仓储体系的大脑”：智能波次，全面了解它在过去一年时间里算法友好型的系统架构建设和演进过程。一. 前言仓储管理体系从粗放向精细化经营、柔性自动化管理转变是大的趋势，2018年双11国内物流订单首次突破10亿，对整个物流行业都是巨大的挑战，菜鸟的AGV小车、PTL、立体存储等自动化设备发挥了强大的作用。在智能化方面，菜鸟仓储技术团队同样在进行多维度的探索，覆盖从接单、分拣、交接等关键链路，并取得显著效果。在仓储系统中，波次汇总是将系统单据（信息流）转化为可作业单据（实物流）的关键节点，传统方式有诸多缺点，本文主要介绍了菜鸟仓储系统的智能化波次在过去一年时间里算法友好型的系统架构建设和演进过程，以期为其他业务平台的智能化提供借鉴，进而构建覆盖整个仓储领域的智能化系统架构。二. 背景介绍什么是波次汇总？交易订单承载着物流契约信息，仓储系统根据货品的属性将订单切分成可作业的包裹单元。波次汇总是以包裹为单位，按照一定的策略（波次策略）进行筛选，并将不同包裹按照策略内指定的规则聚合成拣选单，来指导拣货。在这个过程中，波次汇总的准确性、平衡性、可控性、高效性都尤为重要。面临的挑战1. 技术挑战：波次汇总（菜鸟内部称之为中枢平台，寓意就像大脑一样是整个仓储体系的大脑，调度仓库的作业节奏）是大数据计算密集型的系统，对数据量、效率、数据一致性、计算资源等因素极为敏感。系统上需要重点解决的是在分布式架构下的最优化生产计算问题。2. 实操挑战：在智能波次诞生前，波次汇总主要有两种方式——波次查询汇总和波次导航汇总，它们都是人为的根据一定的条件查询包裹并应用波次策略来生成拣选单，查询设置都是制单员根据仓库现场进行决策。在实操方面，问题主要集中在以下几点：汇单生成优质拣选单的要求极高要考虑订单时效性、实操的拣选效率、现场劳动力等因素，控制汇波节奏；汇单人员能力良莠不齐、无法掌控全局数据，一旦产生路径依赖，很难再去思考如何优化波次策略；拣选单生成后未进入作业的积压，拣选无法精细化每次汇总单量大，打印的拣选单长时间未进入生成，造成拣选单积压；而这部分订单hold单后可以提高优化空间，提升秒杀率；已经确认的拣选单无法回滚和拦截，只能到质检时拦截，拣选作业浪费；综合来看人工波次汇总的方式无法达到最优，要做到满足时效前提下提供柔性服务，这种关键节点必须交由系统来决策。三. 构建算法友好型的智能化波次架构历程智能波次由来2017年双11结束后复盘，我们着手解决人工决策来进行波次汇总情况下出现的问题，思考用智能化系统手段来提升——由系统根据全局的数据来判断何时汇单、用什么条件汇单、汇哪些单，以便更柔性的控制生产节奏。优化思路聚焦如下三点：不是思考如何设置最优的波次策略参数，而是从拣选单的角度出发，现场有多少的作业能力，就从“所有的”包裹里选出“最好的”进行聚合组单；在对包裹进行聚合组单，充分考虑仓内巷道、库位的布局，将拣选距离、SKU动碰次数作为优化目标，进而提高人效；控制波次汇总节奏，对仓库现场和仓内数据进行详细的采集，交由人工智能的算法决策是否波次，再由业务系统来进行执行。详细的系统流程可以用下图来理解：在前期的可行性验证中，我们选取一个单量适中的仓库作为样本，对该仓单日出库包裹进行仿真汇总，和当日实际的人工汇总结果进行对照。下图是几个对照组的结果：系统生产方式与第一列的实际作业情况进行对比，拣选单数量明显下降，单包裹平均库位数的下降趋势也很明显。经过核算间接人效提升达到两位数的百分比：为了和传统的人工决策方式进行区分，我们称之为智能化波次，下图是一个形象化的展示： 我要着重强调的是，很多同学在比较智能波次和人工波次时往往把注意力集中在各种feature上（比如包材的优化、比如容量的劳动力控制、比如动态的组单参数、比如自适应的参数配置等等），但更重要的是理念上的转变：人工波次的着眼点是包裹——关注的是如何根据规则来组合包裹、生成拣选单，进而来优化规则；智能波次的着眼点是拣选单——需要拣选单来进行生产，然后是怎么根据现场的状态来挑选包裹生成最好的拣选单。方向上的差别不可小觑，智能波次是真正尝试实现仓内“按需生产”（JIT，Just In Time——只在需要的时候，按需要的量，生产所需的产品），让仓库拣选作业从对包裹的需求转变成拣选单的需求，向精益管理、柔性服务迈出第一步。正如曾鸣教授《智能商业》一书中提到的，我们要从“数据提供支持”向“数据智能进行决策”进化。样本仓库试点在几个月的时间内，全国范围的样本仓开始使用智能波次来进行波次汇总，期间完整经历了几次大促的考验。对于样本仓库，我们进一步明确了主要指标并进行效果跟进：拣选单数：count(pickBill)，日均拣选单数表达所有包裹出库需要拣选作业的人次；该指标与单量正相关；在相同包裹量下，越低越好；单个包裹平均拣选时长：sum(pickBill.time)/sum(packageCount)，拣选每个包裹需要的时间；该指标与单量负相关；在相同包裹量下，越低越好；包裹平均库区/巷道/库位数：sum(pickBill.position)/packageCount，拣选每个包裹需要走过的库区/巷道/库位数；该指标与单量正相关；该指标越低越好；智能波次上线后几个主要指标呈现下降趋势，与此同时仓库所需的拣选人员数也同时减少，切实降低了成本。下图是“单个包裹平均拣选时长”指标的变化趋势：架构探索期从完整的可行性仿真到样本仓库落地，是智能波次的架构探索期。当时菜鸟内部业务系统和算法的系统设计和交互比较简单，L1级别的交互图如下表示：在这样的方式下，算法蜕化为业务系统的依赖，业务系统像普通的二方包/HSF服务一样来进行调用，那这是否是算法友好型的设计呢？简单做下比较： 构建算法友好型的业务系统在试点仓库进行智能波次可行性的验证后，我们开始考虑如何升级当前的系统，进一步构建算法友好型的业务系统，以应对双11海量的订单。阿里巴巴从电商、金融、仓储物流、云计算等领域有不少智能化应用的场景，在调研预演阶段，我们对广告、搜索、推荐等集团内业务平台和算法协同的典型场景进行分析对比，看看我们这样的生产型业务平台怎么做智能化，通过下列的对比，可以看到菜鸟仓储系统是既有着与互联网级别的高并发，又有企业级复杂特性、金融级安全稳定的特点，所以在系统形态上既有共性，又具备独特的要求。最终我们演化出了基于TPP（阿里个性化平台）的实现仓内智能化架构方式：与之前相比，新系统架构和特点还是比较明显的：数据资源层+计算容器层+业务层三层；数据层来解耦业务系统和算法技术；基于集团的算法个性化平台TPP做计算+灵动做存储的架构来进行设计，blink来进行订单预处理；算法场景配置化，降低开发工作量；稳定性设施齐全，算法方案的变更、分桶更加灵活高效，快速打造多个行业的方案；OnLine运算+NearLine预测+OffLine分析，为智能算法提供更完备的输入，具备一定的预测机制；一套行之有效的业务平台+智能化算法协同的架构模式，具备可复制性；上线后系统表现：在业务数据量级提升2倍的情况下RT降低5倍以上；代码行数缩减到之前的1/3；应用数降低2/3，机器数缩减6台。另外在这套架构之上，可以进行仓储智能化系统的进一步构建和完善，比如丰富的劳动力数据、实时的作业状态、自动化设备的运行态的获取和使用。仓库的部署速度也越来越快，双11期间智能波次覆盖了华东、华中、华南、西南、西北等全国范围的猫超仓库，帮助仓库降本提效，充分验证系统的可靠性。新架构下的开发协同方式在TPP平台上进行方案的开发，一般来说是算法同学来进行的，但由于波次计算的复杂性，里面不可避免的掺杂了业务规则（如某些场景下对库存的筛选，很难通过数据来进行解耦），如果TPP代码中掺杂算法计算和业务逻辑，日后绝对难以维护。我们创新性的基于TPP的插件机制来进行业务和算法模块的解耦。具体来说，算法和业务的代码封装成插件，方案的代码蜕化成简单的胶水代码，用方案对插件的调用来隔离两方的内部逻辑。在这样的方式下，我们采用“总-分-分-总”的方式进行项目开发，后期各领域内独立迭代。快速的系统功能支持能力在未进行架构升级之前，我们经常面临算法的快速迭代能力和业务系统稳健要求的矛盾。基于TPP的新架构下我们要充分利用平台能力，以参数预估模块为例说一下我们的快速支持方式。在前期的智能波次中，由于上游的交易订单是源源不断流入的，临近出库时间等部分场景下需要用户来进行少量的参数配置，校准系统行为。为进一步降低人为干涉，我们提供预估模块来进行系统参数自动判断，在不违反时效约束的前提下做到所有拣选单的总fitness最优。在新架构下，算法和工程同学在前期仿真完成后，很短时间内开始开发、分桶测试，充分体现了新架构下功能特性快速上线的能力。从下图上看，系统效果和实际运行的曲线拟合度很高。双11大考表现每一个新架构上线后都要面临双11大促的考验，对此我们确立智能波次业务的专项保障，从前期的影子链路改造、底层存储优化、网络请求合并、异步查询优化到后期的全链路压测，整体保障准确有力，面对老板们提出智能波次实现千万级别订单的自动化智能化汇单的目标大家都很有信心。经过充分准备我们在双11交出答卷——整个大促期间仓库自动化汇单，而且各个仓库拣选时效均有不同程度的提升，体现了菜鸟数据化、智能化的决策能力。下图是各个大区随机选取共计9个仓的效果跟踪（形象化展示，恕不披露详细数据）四. 出库智能化从去年12月份到今天经历双11大促，我们在中枢智能化迈出的这一小步，已经激起了片片涟漪。未来我们还有更长的路要走，4PL仓库怎么去支持？自动化场景下怎么更好的协同？订单的波次和补货怎么线上化？波次如何更具有计划性？如何实现产品化、平台化的跨越？技术驱动的社会化物流协同，是菜鸟技术人坚持的方向。延伸到仓储智能化方面，多环节协同、应对复杂场景的不确定性、时效性与可预测性、国际化，这些问题都还未有答案，需要我们更多的思考和落地，半年甚至一年后再来看现在，希望能有更大的突破。本文作者：哲成阅读原文本文来自云栖社区合作伙伴“阿里技术”，如需转载请联系原作者。

摘要： 一起来探索蚂蚁双11的神秘技术之旅吧！小蚂蚁说：你们都很关心的 “OB双11大促实战分享” 专题来啦！本系列将为你系统性的介绍OceanBase支撑蚂蚁双11背后的技术原理和实战分享。从平台到架构，再到实现，一起来探索蚂蚁双11这场神秘的技术之旅吧！2018年的双11十周年，最终成交额以2135亿元创纪录收官，支付宝系统在这场“商业奥运会”中再次经受住了考验。这也是OceanBase顺利支撑蚂蚁双11的第五年。从五年前，只有10%流量切到OceanBase上，到如今OceanBase 2.0版本成功支撑2018年双11的支付宝核心链路。每年不变的是一如既往的表现平稳，丝般顺滑，变化的是技术能力的不断升级和迭代。今年的双11，OceanBase 2.0扛起了大梁，性能比去年提升了50%，真正实现了“零成本”支撑大促。一、2018双11大促使用了哪些核心技术？今年的双11，OceanBase致力于通过底层架构及平台能力的提升，来实现双11稳定性、成本优化、性能及效率方面的全方位的提升。相较以往始终如一“丝般顺滑”的大促能力外，2018年的双11，OceanBase更加注重长久技术能力的沉淀：OceanBase2.0版本首次上线支付宝的核心链路，包括交易、支付系统，为“峰值百万支付能力”的三年战略沉淀了通用的“极致弹性”的分布式数据库能力，夯实了百万支付的底层基座。在底层存储介质方面，OceanBase 2.0核心链路首次100%运行在容器上，同时存储计算分离架构上线，大幅降低资源成本的同时夯实统一存储基座。在智能化运维的实践方面，OCP（OceanBase云平台）着眼于SQL优化诊断、故障根因分析和智能容量规划等数据库关键场景，将数据库专家的经验与AI算法/机器学习相结合，提供智能化的数据库服务。在平台能力的沉淀上，OCP引入Orchestration理念，通过编排/复用原子变更任务灵活，实现大促快速弹出/弹回的流程，同时平台内置变更免疫及变更三板斧能力（可监控/可灰度/可回滚），极大的提升了大促整体的稳定性和效率；在整个大促期间，OCP自动执行40000+变更，最终实现全程零故障。在商业产品化方面：智能化运维及平台能力抽象出大促及对外商业化场景，建设通用能力来覆盖蚂蚁内外场景。二、OceanBase 2.0 & 百万支付每年双11的压力在不断创造新高，支付系统需要具备百万每秒的支付能力，那么一个亟待解决的问题是：如何解决最小数据分片的峰值能力超过单机性能的问题。OceanBase 2.0应运而生，其目标是在应用无感知的情况下对数据分片进一步拆分，将数据sharding到无限多的机器上，实现极致弹性能力优雅支撑百万支付峰值。1.百万支付架构如下图的百万支付架构所示，传统数据库的弹性架构，将数据进行物理拆分到不同机器，业务在数据访问、研发、后期维护及数据配套设施上都非常繁琐；同时拆分后资源很难快速回收，且数据拆分及聚合无法实现业务无损。相比于传统数据库的弹性架构，OceanBase 2.0架构完全不侵入业务，内部通过分区实现数据分片的自组织及负载均衡，通过生成列及分区规则实现自动路由，通过分区聚合（partition_group）消除分布式事务性能开销以提升性能，从而实现无损线性伸缩。另外，数据分片间share_nothing及多版本的架构，实现分片故障隔离及单点故障消除的高可用架构。2.性能提升为实现“零成本大促”，OceanBase 2.0花了非常多的精力致力于性能的提升。相比OceanBase1.0，2.0在分布式架构上全面升级，如原生sharding/分布式事务优化/优化事务提交日志开销。OceanBase作为底层基础软件，任何微小的性能提升都会为业务节省大量资源，秉承持续优化的匠心，OceanBase 2.0在数据库底层架构、系统实现层面及数据库运行环境全方位进行优化。最终，OceanBase 2.0相比1.0提升了50%的性能，实现今年双11大促的零机器增加。三、OceanBase 容器化 & 存储计算分离双11峰值需要大量的资源支撑，而峰值后资源处于低水位状态，如何快速申请/释放这部分资源？双11当天非支付链路资源空闲，大促是否可以抢占这批资源？大促不同活动时间错峰，不同链路的资源可否实现快速腾挪？类似的资源问题不一而足。大家可以发现以上问题的本质在于：如何最大化程度降低双11当天的资源成本？这是大促技术要实现的一个核心价值。双11大促资源成本与两个因素相关，一个是大促资源的总数目，另一个是持有时长。我们可以通过系统优化提升单机性能，来降低大促资源的总数目（如前章节提到的OceanBase 2.0的性能优化）。那么如何降低持有时长呢？我们统一的思路是：用“高峰期抢占/低峰值释放资源”的方式来大幅降低持有时长；其两个关键前提技术就是容器化和存储计算分离。1.OceanBase容器化OceanBase容器化的核心思想是“资源调度”，大促目标就是“OceanBase能够被快速调度到各种资源载体上（如离线资源、云资源、峰值无压力的数据库其他集群）”；容器化屏蔽了底层资源载体的差异化，具备弹性部署高效的优点，是资源调度的前提条件。OceanBase打造自身调度能力，深入结合副本、租户的概念，精细化资源画像，使得OB容器化部署快速实现分时复用、资源抢占及混部。2.存储计算分离存储计算分离，顾名思义，将数据库运行依赖的计算资源和存储资源部署到不同的资源载体上，从而实现数据库的弱状态化，使得数据库可分别对存储和计算资源进行弹性伸缩。其好处是显而易见的。典型场景：大促态——CPU资源需求激增，而存储资源增幅很小，那么我们可以针对性对计算资源的机型进行扩容，从而降低资源成本且提升扩容效率；日常态——OB LSM架构将离散IO转化成顺序IO，因此存储的IO能力不是瓶颈，更多的是存储空间上的需求；存储计算分离后，多集群间可降低存储碎片，共享整体存储资源池，提升资源利用率。四、平台智能化随着业务规模的快速增长，系统稳定性SLA预发严峻和OceanBase部署的多样化，传统平台已无法满足我们的需求，可以预见不久的将来，运维将成为业务扩展的瓶颈。因此，OceanBase平台正在逐步走向智能化道路实现智能运维。OCP着眼于SQL优化诊断、故障根因分析和智能容量等大促关键场景，目标是将运维专家的技术经验和AI算法/机器学习技术相结合，分解运维关键技术，开发成一系列的智能运维模型，应用于大规模运维系统中。众所周知，SQL plan的正确性对数据库运行至关重要。OCP针对风险场景SQL，在千万峰值压力下，实时进行plan正确性比对，并对可能存在性能变坏隐患的SQL进行分钟级修正。容量水位是大促至关重要的一环，OCP通过数据建模/智能水位预测对集群/租户/docker进行容量画像，结合OceanBase内置Tenant Group能力，实现容器/集群/租户等多个维度的自动扩缩容，同时计算容量plan在集群/租户维度混部，实现最佳负载均衡部署【 深度部署资源利用率达到(n-1)/n 】，大幅节省了机器资源。OCP作为OceanBase的“智能大脑”，实时监控数据库运行状态，小至单条SQL plan，大至数千台机器容量，真正做到了生产环境智能化全覆盖。未来，OCP还将不断创新数据库智能化的运维之路，打造更加完善的数据库自治体系。五、生态与连接蚂蚁金服与金融机构最早建立的连接是基于支付业务的合作，后来又逐渐扩展了很多其他普惠金融类的业务，比如网商银行的同业合作，借呗/花呗等。如今随着在蚂蚁金服内部多年积累的技术能力与产品能力，OceanBase也将全面走向外部，对所有行业开放，通过科技作为新的连接纽带助力企业的数字化转型。过去金融业IT系统的基础架构建设基本都来自国外，如IBM、甲骨文、EMC这些公司构建底层架构，其中门槛最高的就是数据库的整体平滑替换。OceanBase团队从成立之初就肩负着使命，即我们要做一款通用数据库真正的去推动整个社会的进步，能够让整个社会的生产力发生变化。从2016年底，OceanBase就开始准备走出去，用技术改变业务形态；用技术创造新的业务模式，与更多企业建立更为紧密的连接关系。近两年对外服务的过程中，通过与ISV的深度合作与赋能，不仅提供OceanBase内核的能力，也不断丰富周边配套产品生态，涵盖使用数据库过程中的方方面面。未来，我们将继续致力于提供高可用、高性能、低成本的数据库服务，相信通过科技的连接助力更多企业，让科技的产出变成可以量化的业务价值。本文作者：平生栗子阅读原文本文为云栖社区原创内容，未经允许不得转载。

为什么需要架构可视化随着企业进行微服务架构改造，系统架构复杂度越来越高，架构变化日益频繁，微服务改造后的实际架构模型可能与预期已经产生了巨大差异，架构师或系统运维人员很难准确记忆所有资源实例的构成和交互情况；其次，系统架构在动态演化过程中可能引入了一些不可靠的因素，比如弱依赖变强依赖、局部容量不足、系统耦合过重等，给系统的稳定性带了极大的安全隐患。所以我们每次在面对系统改造、业务大促以及稳定性治理工作之前，都会通过梳理架构图的方式，呈现系统架构中个组件之间的交互方式，架构可视化能够清晰的协助我们识别架构中存在的问题以及建立高可用的系统。架构可视化后，可以给我们带来以下几点但不局限于此的优势：确定系统边界一张好的架构图，应该明确系统所包含的各个组件以及各个组件之间的核心调用关系，这些组件的集合就是系统的处理边界，系统架构的边界在一定程度上也反映了业务域的边界。架构问题识别基于高可用的架构准则，结合可视化的架构图，可以评估架构可能存在的安全风险，比如系统在容灾、隔离以及自愈维度下的健壮性。其次，一些架构链路可视化工具(比如鹰眼)在实际工作中确实大大提高了开发者排查与定位问题的效率。提高系统可用性有了系统架构的上下游依赖关系图，在故障发生时，开发人员可以借助依赖数据快速定位到问题的来源，极大缩短问题修复时间（MTTR）。借助架构图，我们还可以梳理出系统中存在的强弱依赖，在业务高峰期对弱依赖进行降级，或者针对系统依赖的各个组件进行故障模拟，以评测系统整体在面对局部故障的可靠性。常见架构可视化的做法我们熟知的架构图是静态的停留在PPT上的，很多时候我们的架构已经发生了非常大的变化，但是我们还在使用那张看上去很经典却早已过时的架构图。长时间使用与实际架构不符的架构图对线上架构的认知的危害是巨大的，我们需要在脑海中不断更新对系统架构的视图，以保持对系统架构的敏感度。每年的大促或者重大系统改造成为我们梳理系统架构、对架构进行重新认知的机会，此刻我们需要通过各种工具查看系统的各个组件分布以及不同组件的内部与外部的依赖关系，这种梳理架构图的方法是最常用的方式，权且称之为“手工绘制法”。手工经常干的事情，就有追求效率的同学使用计算机系统带来的自动化手段帮助自己做这件事情，比如我们常常看到的基于数据埋点的微服务可视化解决方案，这类架构可视化手段通常在分布式追踪、APM等监控领域使用较多，下图为某APM产品提供的应用维度架构可视化方案：我们称这种可视化方式为“埋点式感知法”，架构组件的识别是依赖关键的核心类检测与埋点，此种方案存在以下弊端：语言相关性：只要是系统埋点，与语言相关的特征基本就拜托不了，需要针对不同语言提供不同的依赖包；不易维护：因为是对核心类的检测，当组件包做了重大变更时，需要同步变更；不易扩展：因为是客户端识别方案，客户端一旦开放出去，新组件的支持只能等待用户更新组件；规模受限：客户端识别的另一个缺点是算法受限，服务端进行识别，可以借助大数据分析等手段更有效准确的识别；还有一种自动化架构感可视化方法，我们称之为“无界架构感知”，是一种语言无关性的架构识别方案，其采用采集用户主机上的进程和容器的元数据、监控数以及网路数据的最最基础的数据，在服务端构建架构图。我们设计架构可视化的理念为了最大限度上降低用户进行架构可视化的成本，我们采用了无界架构感知-应用无侵入的方式微服务进行可视化，通过采集进程数据与网络调用数据，构建进程间的网络调用关系，构建微服务的架构信息。用户只需要安装我们AHAS Agent探针，即可完成架构可视化操作；对于阿里云云原生系统，我们提供了自动化安装方式，而无需登录机器。核心本质软件架构可视化的核心点是寻找在软件体系结构中有意义和有效的元素视图以及这些元素之间的关系。我们认为一款优秀的软件架构可视化产品应该帮助用户排除掉不重要的信息，给用户呈现出对他们有价值的视图，特别是在微服务架构下庞大而复杂的调用关系链场景中。这里面的核心点是__有意义__和__有效__，要做到这两点，首先需要识别什么是有意义和有效的元素和关系，我们在此领域做的事情归纳起来就是“识别”，识别机器上的每个进程是什么，发生的网络调用远端是什么，唯有知晓了这些元素是什么我们才有理由和依据来判断是否对用户有意义以及其在用户架构中的重要程度。在梳理了大量架构图，我们发现用户关心的架构元素主要分为三类：自己的应用服务；应用对外部的资源依赖；服务器本身的信息。 应用对外部资源的依赖通常以其它应用和通用中间件或者存储服务两种形式存在。故我们将需要识别的进程分为：应用服务和常见的组件服务（比如redis、mysql等），这些组件服务又分为用户自建的服务和使用公有云提供的服务，特别是对于Cloud Native应用来说，云服务的识别显得格外重要。目前，我们提供了20种阿里云云服务的识别以及包含mysql、redis、Tomcat等常见的21种三方服务组件，此组件库还在不断扩张中，目的就是最大限度的知晓架构中的元素到底是什么。架构分层我们同样认为架构可视化的有效性跟人的认知层次有关，架构可视化的重点是确定该工具是否更好的支持自顶向下方法、自下而上方法或者两者的结合。开发者更关心应用维度上的架构，架构师或者管理者更关心整体系统架构。所以需要针对不用的使用者提供不同层次的架构可视化视角。理想的架构图需要支持宏观维度以及不断下钻下的微观视角，我们对架构进行了分层设计，目前分为进程层、容器层和主机层，后期我们可能会继续上扩或者下钻支持地域层或者服务层。架构回溯没有哪个系统的架构是一成不变的，系统架构会随着系统的版本迭代不断进行演化。所以对架构可视化操作，还需要具备随着时间的推移可对架构信息进行自动更新已经回溯的能力。在我们提供的架构感知产品中默认架构图会随着时间自动刷新，同时支持对历史的回溯，你可以选择历史中的某一刻查看架构信息，比如，重大版本的变更时，发布前与发布后的系统架构是否发生了违背一些高可用原则的问题，抑或排查是否出现了不该有的依赖问题。可见可得架构可视化解决了可见的问题，但当我们从架构图中发现了问题需要解决时，架构图还应该给我们提供便利的可交互操作入口，让我们可以完成问题发现与解决的闭环。比如通过架构感知监控到了某个应用的流量非常大，我们需要对应用进行限流或者预案，那么通过架构图，我们应该是可以完成我们期望执行的操作。在架构图中融入可以交互的运维操作，让我们从看到到操作，再到问题恢复后体现在图中，这就像计算机发展史上从命令行视图到窗口视图的转变。我们对架构可视化的定位__架构可视化不是目的，只是实现系统高可用性的手段__。借助架构感知采集到的架构数据，在识别了用户使用的组件（我们对mysql、redis、mq等的统称)后，我们借助这些组件以及与组件匹配的故障库，可以给用户自动推荐这些组件可能遇到的故障，配合我们提供的评测服务让用户更方便地对组件进行各种故障的模拟与演练，以提高系统的健壮性。其次，通过架构感知识别Java Application 应用，如果发现其负载较高，配合我们提供的限流降级（阿里巴巴开源的Sentinel商业版）功能，为服务的持续可用性保驾护航。我们对AHAS的定位是一款数据分析型的高可用保障产品，帮助云原生架构系统实现高可用能力的提升。架构可视化是我们给用户提供的高效运维和管控的窗口，我们期望通过丰富的云原生数据体系配合架构图的可视化以及可操作性，建立起以应用为中心的运维一体化平台。在未来，我们会加强与其它云服务的集成，比如监控、容器服务，以丰富架构感知的数据维度；其次，会在数据的深度挖掘和智能化消费上投入更多精力，真正让数据成为企业的核心价值，让数据成为保障业务的稳定性的利器。本文作者：心远阅读原文本文为云栖社区原创内容，未经允许不得转载。

什么是POLARDBPOLARDB 是阿里云自研的下一代关系型分布式数据库，100%兼容MySQL，之前使用MySQL的应用程序不需要修改一行代码，即可使用POLARDB。POLARDB在运行形态上是一个多节点集群，集群中有一个Writer节点（主节点）和多个Reader节点，他们之间节点间通过分布式文件系统（PolarFileSystem）共享底层的同一份存储（PolarStore）。POLARDB通过内部的代理层（Proxy）对外提供服务，也就是说所有的应用程序都先经过这层代理，然后才访问到具体的数据库节点。Proxy不仅可以做安全认证（Authorization）和保护（Protection），还可以解析SQL，把写操作（比如事务、Update、Insert、Delete、DDL等）发送到Writer节点，把读操作（比如Select）均衡地分发到多个Reader节点，这个也叫读写分离。POLARDB对外默认提供了两个数据库地址，一个是集群地址（Cluster），一个是主地址（Primary），推荐使用集群地址，因为它具备读写分离功能可以把所有节点的资源整合到一起对外提供服务。主地址是永远指向主节点，访问主地址的SQL都被发送到主节点，当发生主备切换（Failover）时，主地址也会在30秒内自动漂移到新的主节点上，确保应用程序永远连接的都是可写可读的主节点。如上图，底层一套存储，节省成本，是『合』；中间多个节点，提高扩展性，是『分』；上层一套代理层，统一入口，使用简单，也是『合』。如此『合-分-合』的架构，在扩展性和使用便捷性之间保持了平衡，使得对于上层应用程序来说，就像使用一个单点的MySQL数据库一样简单。如何使用POLARDB部署在云端，创建时先选择使用的地域可用区和具体的VPC网络，然后指定节点的数量（从 2个 到 16 个）和配置（从 2核 到 88核）即可，存储空间不用提前配置，也不需要关心容量大小，系统会根据实际的使用量自动收取费用。创建过程可能持续5-10分钟，然后配置好白名单、创建完高权限账号就可以使用了。逻辑DB和账号User，可以在控制台创建，也可以通过高权限账号登录到数据库执行SQL创建，二者效果完全一样，没有区别。如果您需要迁移老的数据库到POLARDB，推荐使用DTS。不管源库是在RDS，还是在ECS自建MySQL，甚至是在云下有公网地址可访问的MySQL，都可以通过DTS做在线平滑迁移，停机时间5-10分钟。特点除了可以像使用MySQL一样使用POLARDB，这里还有一些传统MySQL数据库不具备的优势。容量大最高100T，不再因为单机容量的天花板而去购买多个MySQL实例做Sharding，甚至也不需要考虑分库分表，简化应用开发，降低运维负担。高性价比多个节点只收取一份存储的钱，也就是说只读实例越多越划算。分钟级弹性存储与计算分离的架构，再加上共享存储，使得快速升级成为现实。读一致性集群的读写分离地址，利用LSN（Log Sequence Number）确保读取数据时的全局一致性，避免因为主备延迟引起的不一致问题。毫秒级延迟——物理复制利用基于Redo的物理复制代替基于Binlog的逻辑复制，提升主备复制的效率和稳定性。即使是加索引、加字段的大表DDL操作，也不会对数据库造成延迟。无锁备份利用存储层的快照，可以在60秒内完成2T数据量大小的数据库的备份。并且这个备份过程不需要对数据库加锁，对应用程序几乎无影响，全天24小时均可进行备份。复杂SQL查询加速内置并行查询引擎，对执行时长超过1分钟的复杂分析类SQL加速效果明显。该功能需要额外连接地址。本文作者：乙休阅读原文本文为云栖社区原创内容，未经允许不得转载。

今天整理了一下近大半年以来的一些文章，和我的预期一样，很多文章我都忘记自己曾经写过了，这个记录的过程让我也有了新的理解。希望大家，收藏，点赞，加转发。面试必备面试必备：深入Spring MVC DispatchServlet 源码分析面试必备：一文读懂Spring AOP面向切面编程面试必备：理解JWT鉴权的应用场景及使用建议面试必备：浅谈偏向锁、轻量级锁、重量级锁面试必备：一致性哈希算法的理解与实践面试必备：深入理解为什么要设计幂等性的服务面试必备：面试官最爱的volatile关键字面试必备：Rabbitmq延迟队列实现定时任务面试必备：HashMap源码解析JDK8面试必备：Dubbo服务消费者调用过程面试必备：Dubbo服务提供者发布过程面试必备：Dubbo中暴露服务的过程解析面试必备：Java中transient关键字的作用面试必备：JavaSQL注入危害这么大，该如何来防止呢?面试必备：Java虚拟机运行时数据区面试必备：Redis之数据持久化RDB与AOF面试必备：Redis持久化RDB和AOF优缺点是什么面试必备：Redis集群下的RedLock算法(真分布式锁) 实践面试必备：Redis服务器被攻击后该如何安全加固面试必备：Zookeeper的Leader选举过程面试必备：ZooKeeper和CAP理论及一致性原则面试必备：MySQL从删库到恢复，还用跑路吗？面试必备：MySQL/InnoDB中，乐观锁、悲观锁、共享锁、排它锁、行锁、表锁、死锁概念的理解面试必备：MySQL常用30种SQL查询语句优化方法面试必备：MySQL InnoDB B+树索引和哈希索引的区别？ MongoDB 为什么使用B-树?面试必备：常用的分布式事务解决方案介绍有多少种？面试必备：对称加密，非对称加密，公钥和私钥面试必备：如何加密传输和存储用户密码Java并发Java并发：接口限流算法：漏桶算法&令牌桶算法Java并发：深入浅出AQS之共享锁模式源码分析Java并发：深入浅出AQS之独占锁模式源码分析Java并发：了解无锁CAS就从源码分析Java并发：分布式应用限流实践Java并发：Semaphore信号量源码分析Java并发：CAS源码分析面试题面试题：百度、腾讯、阿里、谷歌 面试题视频详解合集面试题：2018最新JAVA算法/数据结构面试题和答案面试题：70道Spring面试题与答案面试题：2018最新Redis面试题与答案面试题：50道多线程面试题与答案（二）面试题：50道多线程面试题与答案（一）面试题：Spring常见的一些面试题与答案面试题：300道Java面试题与答案面试题：40道常见面试题与答案面试题：20道数据库面试题与答案架构架构：应用消息中间件设计可以解决哪些实际问题？架构：搭建大众点评CAT实时应用监控平台架构：如何实现一个TCC分布式事务框架的一点思考架构：Dapper大规模分布式系统的跟踪系统架构：Dubbo 整合 Pinpoint 做分布式服务请求跟踪架构：理解大型分布式架构的演进历史、技术原理、最佳实践架构：解密 Redis 助力双十一背后电商秒杀系统架构：瞬间点击量过万，Redis热点Key的5种解决方案架构：通过案例读懂 RESTful 架构风格架构：一文读懂Apache Flink架构及特性分析架构：大数据推荐系统实时架构和离线架构架构：携程：日处理20亿数据，实时用户行为架构实践架构：什么是微服务架构架构：有赞服务化架构演进架构：微服务架构下静态数据通用缓存机制架构：小型系统如何“微服务”开发架构：Oracle推出开源轻量级 Java 微服务框架 Helidon搭建搭建：网站配置免费的HTTS证书搭建：Apache RocketMQ 单机环境搭建：MongoDB分片（sharding） / 分区 / 集群环境搭建：MongoDB 的安装与详细使用（二）搭建：MongoDB 的安装与详细使用（一）搭建：SolrCloud 集群服务搭建：Solr 单机服务搭建：RabbitMQ 3.6 单机服务搭建：RabbitMQ 3.6 集群服务搭建：离线部署 CDH 5.12.1 及部署Hadoop集群服务搭建：Mycat 读写分离数据库分库分表中间件及简单使用DockerDocker Compose 1.18.0 之服务编排详解Docker 部署 SpringBoot 项目整合 Redis 镜像做访问计数DemoDocker Registry企业级私有镜像仓库Harbor管理WEB UI, 可能是最详细的部署Docker Registry Server 搭建,配置免费HTTPS证书，及拥有权限认证、TLS 的私有仓库Docker Hub 仓库使用，及搭建 Docker RegistryDocker 容器常用操作命令讲解Docker 安装在之初窥 Dockerfile 部署 NginxSpring CloudSpring Cloud（十一）高可用的分布式配置中心 Spring Cloud Bus 消息总线集成（RabbitMQ）Spring Cloud（十）高可用的分布式配置中心 Spring Cloud Config 中使用 RefreshSpring Cloud（九）高可用的分布式配置中心 Spring Cloud Config 集成 Eureka 服务Spring Cloud（八）高可用的分布式配置中心 Spring Cloud ConfigSpring Cloud（七）服务网关 Zuul Filter 使用Spring Cloud（六）服务网关 zuul 快速入门Spring Cloud（五）断路器监控(Hystrix Dashboard)Spring Cloud（四） 服务提供者 Eureka + 服务消费者 FeignSpring Cloud（三） 服务提供者 Eureka + 服务消费者（rest + Ribbon）Spring Cloud（二）Consul 服务治理实现Spring Cloud（一）服务的注册与发现（Eureka）Spring BootSpring Boot 中使用 RabbitMQSpring Boot 中使用 RocketMQSpring Boot 中使用 SolrCloudSpring Boot 中使用 MongoDB 增删改查Spring Boot 中使用 Dubbo 详解Spring Boot 中使用 LogBack 配置Spring Boot 中使用 Docker镜像push到DockerHub上Spring Boot 写的一个java开源图床其他的震惊！面对他人提问某著名程序员居然这样回复爆出惊天内幕！这就是java的优雅停机如何招聘完美的以太坊开发者ElasticSearch优化会员列表搜索软件做异常测试？必知的22个测试点总结！还没用上 JDK 11吧，JDK 12 早期访问构建版使用Mybatis 一级缓存清理无效引起的源码走读程序猿的十二条自我修养，你有吗？Twitter的分布式雪花算法 SnowFlake 每秒自增生成26个万个可排序的ID (Java版)Java 10 新特性解密，引入类型推断机制，2018 年 3 月 20 日发布 ...

破土而出的生命力，源自理想主义者心底对技术的信念。开源曾经帮助 Redhat 在传统软件市场奠定了其行业地位。无独有偶，作为云计算时代的赶超者，谷歌也拿起了开源的武器，试图打乱 AWS 和 Azure 的节奏。目前，这一策略似乎正在奏效。如今云原生技术正席卷全球，云原生基金会在去年 KubeCon +CloudNativeCon NA 的现场宣布：其正在孵化的项目已达 14 个，入驻的厂家或产品已超过 300 家，并吸引了 2.2 万开发者参与项目代码贡献，其明星产品 Kubenetes 的 GitHub 上 Authors 和 Issues 量已排行开源领域的第二名。而 Kubenetes 正是 Google 开源的一个容器编排引擎。今年，KubeCon + CloudNativeCon 首次来到中国。在2018 KubeCon + CloudNativeCon的现场，阿里云研究员伯瑜向在场的开发者们宣布，CNCF 已将阿里巴巴云原生镜像分发系统 Dragonfly 接纳为其沙箱项目（Sandbox），并有机会成为国内首个从 CNCF 毕业的开源项目。目前已经毕业的两个项目，一个是 Kubernetes，另一个是 Prometheus。据悉，目前阿里巴巴已经有 8 个项目进入 CNCF 云原生全景图，分别是分布式服务治理框架 Dubbo、分布式消息引擎 RocketMQ、流量控制组件Sentinel、企业级富容器技术 PouchContainer、服务发现和管理 Nacos、分布式消息标准 OpenMessaging、云原生镜像分发系统 Dragonfly 和高可用服务 AHAS。时间回到 2016 年2016 年的那届双11，RocketMQ 创始人冯嘉和他的团队首次将低延迟存储解决方案应用于双11的支撑，经受住了流量的大考，整个大促期间，99.996%的延迟落在了 10ms 以内，完成了保障交易稳定的既定目标。对于读写比例几乎均衡的分布式消息引擎来说，这一技术上的突破，即便是放在全球范围内，也绝对是值得称赞的。另一边，在历时3个月的开源重塑后，冯嘉和他的团队启动了 RocketMQ 向Apache 软件基金会的捐赠之路，但迈出这一步并不容易。“当时国内的开源氛围还没有现在那么活跃，开源之后，很多设计、源码和文档的维护工作还不够理想，但我们就是想证明国内的开源项目和开源社区也可以在世界的开源舞台上发挥价值。”经过近一年的努力，在2017年9月25日，Apache 软件基金会官方宣布，阿里巴巴捐赠给 Apache 社区的开源项目 RocketMQ 从 Apache 社区正式毕业，成为 Apache 顶级项目（TLP），这是国内首个非 Hadoop 生态体系的Apache 社区顶级项目。值得一提的是，根据项目毕业前的统计，RocketMQ 有百分八十的新特性与生态集成来自于社区的贡献。2017 年，消息领域出现一件里程碑事件。分布式消息领域的国际标准 OpenMessaging 开源项目正式入驻 Linux 基金会，这是国内首个在全球范围发起的分布式计算领域的国际标准。消息通讯已经成为现代数据驱动架构的关键环节，但在全球范围内，消息领域仍然存在两大问题：一是缺乏供应商中立的行业标准，导致各种消息中间件的高复杂性和不兼容性，相应地造成了公司的产品低效、混乱和供应商锁定等问题。二是目前已有的方案框架并不能很好地适配云架构，即非云原生架构，因此无法有效地对大数据、流计算和物联网等新兴业务需求提供技术支持。这也是冯嘉和他的团队在开源 RocketMQ 过程中，开发者和合作伙伴经常会提到的问题：“在消息领域，市场上出现了各类不同的开源解决方案，这导致了用户更高的接入和维护成本，为了确保各个消息引擎间能正常通信，还要投入大量的精力去做兼容。”这时候，建立一套供应商中立，和语言无关的消息领域的事实标准，成为各社区成员共同的诉求。此后，在 2017 年 9 月，阿里巴巴发起 OpenMessaging 项目，并邀请了雅虎、滴滴出行、Streamlio共同参与，一年后，参与 OpenMessaging 开源标准社区的企业达10家之多，包括阿里巴巴、Datapipeline、滴滴出行、浩鲸科技、京东商城、青云 QingCloud、Streamlio、微众银行、Yahoo、中国移动苏州研发中心（按首字母排序），此外，还获得了 RocketMQ、RabbitMQ 和 Pulsar 3 个顶级消息开源厂商的支持。相比于开源一个分布式消息项目，一套开源标准能被各家厂商所接受，对整个国内开源领域而言，是更具有里程碑意义的事件。2017 年 9 月，Dubbo 重启开源。Dubbo 是阿里巴巴于 2012 年开源的分布式服务治理框架，是国内影响力最大、使用最广泛的开源服务框架之一，在 2016 年、2017 年开源中国发起的最受欢迎的中国开源软件评选中，连续两年进入 Top10 名单。2017 年 9 月 7 日，在 Github 将版本更新至 2.5.4，重点升级所依赖的 JDK 及其组件，随后连续发布了 11 个版本。并于2018年2月捐献给 Apache 软件基金会，希望借助社区的力量来发展 Dubbo，打消大家对于 Dubbo 未来的顾虑。项目重启半年后，Dubbo 项目负责人阿里巴巴高级技术专家北纬在接受媒体采访的时候，从战略、社区、生态和回馈四个方面谈了 Dubbo 重启开源背后的原因。“集团近几年开始将开源提到了新的战略高度，这次投入资源重启开源，核心是希望让开源发挥更大的社会价值，并和广大开发者一起，建立一个繁荣的Dubbo 生态，普惠所有使用 Dubbo 的人和 Dubbo 本身。”Dubbo项目组成员朱勇在今年上海的技术沙龙上分享Dubbo未来发展的过程中提到，其后续的规划是要解决好两个问题。第一个问题是重点关注技术趋势，例如云原生对Dubbo开源现状的影响。第二个问题是 Dubbo 本身定位的问题，除了保持技术上的领先性，还需要围绕 Dubbo 核心发展生态，和社区成员一起将 Dubbo 发展成一个服务化改造的整体解决方案。2017 年 11 月，阿里自研容器技术 PouchContainer 开源。在开源不到一年的时间里，PouchContainer 1.0 GA 版本发布，达到可生产级别。今年 8 月，PouchContainer 被纳入开源社区开放容器计划 OCI；9 月，被收录进高校教材《云计算导论》；11 月，PouchContainer 团队携蚂蚁金服容器团队、阿里云 ACS 团队，与容器生态 Containerd 社区 Maintainer进行技术交流，有望发展成 Containerd 社区 Maintainer 席位，代表国内企业在世界容器技术领域发声。PouchContainer 发展速度之快，超出了宏亮的想象。宏亮是 Docker Swarm 容器集群项目的核心代码维护者（Maintainer），并于2015 年 8 月出版了《Docker 源码分析》一书，对 Docker 架构和源代码进行了深入的讲解，该书在 Docker 领域迅速成为畅销书籍。2017 年，宏亮承担起阿里自有容器技术的对内支持和对外技术布道的工作，秉承初心，希望在竞争激烈的容器开源领域能抢下属于国内容器技术的一席之地。在团队的努力下，阿里集团内部已实现 100%的容器化，并已经开始涉及离线业务，实现在、离线业务的混合调度与部署。整个集团能实现 100%的容器化，离不开阿里内部自研的 P2P 分发技术，该项目取名为 Dragonfly，寓意点与点之间的文件分发能如蜻蜓般轻盈和迅速，解决传统文件发布系统中的大规模下载、远距离传输、带宽成本和安全传输的问题。日前，Dragonfly 正式进入 CNCF， 并成为国内第三个被列为沙箱级别（Sandbox Level Project）的开源项目，可见，CNCF 在其云原生的技术版图中正希望借助Dragonfly等优秀的镜像分发技术，以提升企业微服务架构下应用的交付效率。始于阿里，回归社区。今年夏天，国内开源领域，迎来了两位新成员。作为微服务和云原生生态下的两款重要开源框架/组件，Nacos主打云原生应用中的动态服务发现、配置和服务管理，Sentinel 则是聚焦在限流和降级两个方面。Nacos 和 Sentinel 均是在阿里近 10 年的核心业务场景下沉淀所产生的，他们的开源是对微服务和元原生领域开源技术方案的有效补充，同时也非常强调融入开源生态，除了兼容 Dubbo和Sentinel，也支持对Spring Cloud 和 Kubenetes 等生态，以增强自身的生命力。“阿里巴巴早在 2007 年进行从 IOE 集中式应用架构升级为互联网分布式服务化架构的时候，就意识到在分布式环境中，诸如分布式服务治理，数据源容灾切换、异地多活、预案和限流规则等场景下的配置变更难题，因为在一个大型的分布式系统中，你没有办法把整个分布式系统停下来，去做一个软件、硬件或者系统的升级。”阿里巴巴高级技术专家坤宇在 2017 QCon 的现场分享到。在配置变更领域，我们从2008年的无 ConfigServer 时代，借用硬件负载设备 F5 提供的 VIP 功能，通过域名方式来实现服务提供方和调用方之间的通信，逐步经历了 ConfigServer 单机版、集群版的多次迭代，不断提高其稳定性。曾写下支付宝钱包服务端第一行代码的阿里高级技术专家慕义，在今年深圳的技术沙龙现场回忆了阿里注册中心自研的 10 年路：“这期间，集团业务经历了跨越式的发展，每年翻番的服务规模，不断的给 ConfigServer 的技术架构演进带来更高的要求和挑战，使得我们有更多的机会在生产环境发现和解决一个个问题的过程中，实现架构的一代代升级。Nacos 便是在这样的背景下，经过几代技术人的技术攻坚所产生的。”我们希望 Nacos 可以帮助开发者获得有别于原生或其他第三方服务发现和动态配置管理解决方案所提供的能力，满足开发者们在微服务落地过程当中对工业级注册中心的诉求，缩短想法到实现的路径。巧的是，一边是 Nacos宣布开源，另一边是 Spring Cloud 生态下的服务注册和发现组件 Netflix Eureka 宣布闭源，勇敢者的游戏充满了变数，但在坤宇和他的团队看来，这场游戏自己可以走到最后，因为我们并不是一个人在战斗，Nacos 只是阿里众多开源项目中的一员，随后还会有更多的开源项目反哺给社区，形成生态，例如轻量级限流降级组件 Sentinel。7月29日，Aliware Open Source•深圳站现场，只能容纳 400 人的场地，来了 700 多位开发者。阿里巴巴高级技术专家子矜在现场宣布了轻量级限流降级组件 Sentinel 的开源。作为阿里巴巴“大中台、小前台”架构中的基础模块，Sentinel 经历了 10 年双 11 的考验覆盖了阿里的所有核心场景，也因此积累了大量的流量归整场景以及生产实践。Sentinel 的出现，离不开阿里历届高可用架构团队的共同努力。“在双11备战中，容量规划是最重要也是最具挑战的环节之一。从第一年开始，双11的 0 点时刻就代表了我们的历史最高业务访问量，它通常是日常流量的几十倍甚至上百倍。因此，如何让一个技术和业务持续复杂的分布式站点去更平稳支撑好这突如其来的流量冲击，是我们这 10 年来一直在解的题。”阿里巴巴高可用架构团队资深技术专家游骥在今年的双11结束后分享道。这 10 年，容量规划经历了人工估算、线下压测、线上压测、全链路压测、全链路压测和隔离环境、弹性伸缩相结合的 5 个阶段。2013 年双11结束后，全链路压测的诞生解决了容量的确定性问题。作为一项划时代的技术，全链路压测的实现，对整个集团而言，都是一件里程碑事件。随后，基于全链路压测为核心，打造了一系列容量规划相关的配套生态，提升能力的同时，降低了整个环节的成本、提升效率。随着容量规划技术的不断演进，2018 年起，高可用架构团队希望可以把这些年在生成环境下的实践，贡献给社区，之后便有了 Sentinel 的开源。一边是作为发起者。将自己生产环境实践下沉淀出来的架构和技术贡献给社区。另一边是作为参与者。基于一些开源项目或云平台，输出可以解决开发者当前工作中存在的痛点的解决方案，例如近期新开源的项目 Spring Cloud Alibaba 和 开发者工具 Alibaba Cloud Toolkit。相同的是，技术理想主义者都希望技术可以为让世界变得更好，这才是技术人的兴奋点。“让世界的技术因为阿里巴巴而变得更美好一点点”。这是阿里巴巴系统软件、中间件、研发效能事业部负责人毕玄邮件签名中的一句话。他正和一群技术理想主义者，与太平洋另一边的技术高手们正面PK，在这场躲不开的战役中，一起认真一把。本文作者：amber涂南阅读原文本文为云栖社区原创内容，未经允许不得转载。 ...

最近社区Java技术进阶群的小伙伴总是会问，如何面试阿里Java技术岗，需要什么条件，做哪些准备；小编就这些问题找到了阿里技术团队中在一线真正带Java开发团队并直接参与技术面试的专家，分享了自身在筛选简历时的要求，面试时经常会问到的问题，以及面试官通过提问是怎样判断面试者技术水平的。如有Java相关问题，请向专家提问 http://click.aliyun.com/m/1000023274/以下都是面试官的经验，我们只介绍普遍现象，但会存在特例哪类Java开发者更受阿里青睐？1、潜力比较大、心力脑力体力都处于巅峰状态的，工作4-5年左右是普遍的最佳时段2、经验足，有视野的，具备大项目积累沉淀3、平时爱学习爱总结，有进步的主观能动性4、聪明，皮实，乐观，自省 的同学，【聪明，皮实，乐观，自省】的解释： https://yq.aliyun.com/articles/671042哪些Java开发者面试阿里会比较艰难？1、工作多年已经转管理岗的，如果面试开发岗位，有可能代码不熟练或心力脑力体力很难跟上技术开发强度2、工作3年以下的，有可能技术和积累的还不够，需要继续修炼3、以往开发的项目太简单，很难看到工作亮点，例如项目经历过多是增删查改加缓存4、以上情况也会有例外的，例外情况的除外阿里Java技术面试流程：1、自我介绍，面试官的关注点：做过项目的规模、具体细节及本人所承担的任务2、一些Java基础问题，做初步的了解3、面试者选择一个最能体现价值的项目，详细描述细节，架构以及为什么这样设计4、设置1-2个必答题，如果答不上来后面不用继续了（面试官面试要效率的，所以会有这种杀手锏类的问题，这种必答题本文后面会详细举例）5、如果你走过前4步，后续面试官可能会提问关于学习能力的问题和考察处理未知问题的能力面试官经常会问到的几个知识点以及面试官问这些问题背后的解读1、杀手锏类问题（划重点），每个面试官的杀手锏可能不一样，但目的是一样的，用最短的时间筛选出适合的人例如1：请写出常用的Exception一般来说，能写出20个以上，而且随意选择几个，大都能说的比较清楚，就是非常不错的了。考面试者的实际开发能力，特别是深度，也可以看出过去常做的内容比如写了ClassNotFoundException，可能是做过ClassLoader动态加载的内容。如果是写了ConcurrentModifiedException，可能是并发问题或者别的地方不足。如果写了UnsupportOperationException，可能在设计方面有些基础或者经验。如果写了SecurityException或者IlleagalException，说明做的内容比较深一些，更贴近底层。例如2：死锁的是怎么产生的？如果答的很乱，提示需要几个线程几个资源？描述细节2、观察类问题，这类问题就是考验面试者思路，表达能力，项目经历例如1：讲述一个最能体现价值的项目，详细描述细节，架构以及为什么这样设计，和其他项目比，为何选此项目例如2：讲述一个有印象或者最难的Bug这类问题主要听面试者是否能够非常清楚细节地讲述一个项目或bug，包括如何发现，解决，反思，从这些内容上可以判断他是否在一线写代码，以及思维方式，一般会涉及：故障点，定位，解决思路，方案选择。3、开放类问题，问到这类问题说明面试官对你基本满意，不在乎说对说错，可能没有对错，就是考察你的学习能力和处理未知问题的能力以及你的思考。例如1：说出几本觉得最有意义的技术书籍例如2：如Spring中如何对同名Bean加载时的处理例如3：大并发时的系统架构需要考虑哪些问题，怎样扛住大并发量，一致性怎样解决，如何取舍如果以上技术你都游刃有余了，那么面试阿里成功的几率80%如果你对Java学习还有些问题，可以向社区Java专家提问http://click.aliyun.com/m/1000023274/本文作者：不靠谱贝贝阅读原文本文为云栖社区原创内容，未经允许不得转载。

摘要： 支付宝从最开始的工具型应用，逐渐发展成平台型应用，一直到现在，已经成为了一个超级 App。本文将带领大家进一步了解支付宝在动态化方案的探索以及 Nebula 框架。小蚂蚁说：此前分享的《模块化与解耦式开发在蚂蚁金服mPaaS深度实践探讨》（想要了解更多相关内容，欢迎关注公众号：mPaaS )已经对支付宝在移动端开发架构的设计思路有了初步了解。本文将结合在 iWeb 武汉站的分享，带领大家进一步了解 mPaaS 在移动端动态化方案设计。分享内容将分为以下三个方面：支付宝动态化方案的探索；Nebula 框架浅析；mPaaS 科技赋能支付宝动态化方案的探索任何一种技术方案都是在业务的发展和架构的演化中逐渐探索出来的，因此我们来看一下支付宝架构的演进： 支付宝从最开始的工具型应用，逐渐发展成平台型应用，一直到现在，已经成为了一个超级 App，它拥有多应用的生态，更加开放和动态化，并且保持着高可用，高性能，高灵敏的强大特性。随着 App 的逐渐庞大，整个应用的架构也在进行不断的调整，来适应各种特性。现在的支付宝客户端的架构如图所示： 整体架构分为五层：容器层、组件层、框架层、服务层、应用层。客户端整体采用统一的框架开发，模块化的开发模式，完全插件式的容器，支持模块独立发布，方便大规模团队的并行开发。在这样的框架结构中，同样包括了我们的动态化方案。支付宝中的动态化方案主要有两种框架：Nebula 和小程序。这两种方案不仅解决了需求迭代速度和发版周期之间的矛盾、跨平台开发、实时发布等一些普适问题，而且有效地保证了发布质量，对线上问题进行紧急止血，同时也有助于建立良好的开放生态。Nebula 是支付宝移动端 Hybrid 解决方案，它提供了良好的外部扩展功能，拥有功能插件化、事件机制、JSApi 定制和 H5App 推送更新管理能力。主要功能包括：接入 H5App 后台，方便管理离线或者在线 H5App，实现 H5 应用的推送、更新。加载 H5 页面，并按照 Session 的概念进行管理各个页面。Android 使用 UCWebView，拥有解决系统级 Webview Crash 的能力，内存管理更合理，网络加载提升更快，兼容性更好。彻底告别了在Android下兼容不同 Webview 的问题。支持自定义网络库，自定义网络通道；支持自定义键盘，自定义 Native View替换 H5 标签。提供丰富的内置 JSAPI，实现譬如页面 push、pop，标题设置等功能；支持用户自定义 JSAPI 和插件功能，扩展业务需求。自带埋点功能，接入 H5 监控平台，能够实时看到页面加载的性能、错误报警和监控。还有一种动态化方案就是支付宝小程序：支付宝小程序是一种全新的开发模式，融合了 H5 的易开发性、跨平台性、Native 性能，让开发者可以快速开发高性能的页面，提供优异的用户体验。通过使用支付宝小程序，开发者为支付宝开发了大量优质的小程序，丰富了支付宝生态能力。小程序开放给开发者更多的 JSAPI 和 OpenAPI 能力，通过小程序可以为用户提供多样化便捷服务。Nebula框架浅析Nebula 的架构如图所示，从上至下依次为 H5 应用层、服务层、原生框架层：H5 应用层：基于 HTML 和 JavaScript 技术开发，在 H5 容器上运行的手机应用，它拥有跨平台的特性，配合离线包的使用可以完成实时热修复的功能。 服务层：为开发者提供了高阶语言的 API 来使用手机系统资源，包括：视窗系统，开发者可以使用它来创造应用 UI，包括文字，图片，按键及定制 View资源管理，通过它开发者可以方便的访问如多语言文字，图片和布局等非代码资源应用生命周期管理，它决定应用在手机系统里的开始，结束以及强制关闭的时机H5 容器原生框架层：是手机系统的基础层，它提供了标准 API 来让高阶语言（比如 Java 和 Object-C）使用底层的硬件，并包含了许多为硬件访问的专有软件库。当上层调用某个框架 API 来访问硬件时，手机系统将加载相应的软件库。整个 Nebula 框架的核心部分就是 H5 容器，下面看一下 H5 容器的结构：H5Service，H5Session 和 H5Page都是从 H5CoreNode 类扩展而来，以 H5Service 为根节点，它与其他类一同形成了树状结构构成了页面流程和导航。在一般情况下，H5Pages 是 H5Session 的子节点，而 H5Sessions 是 H5Service 的子节点，在任何情况下只有一个 H5Service 根节点存在。H5Service：是 Nebula 里维护 H5 应用全局状态的基础类， 在 H5 应用的生命周期内只有一个 H5Service 的单例全局实例，H5Service 可以进行的操作包括：创建且打开一个新的 Web activity创建且开启一个新的 Web page从共享空间存储和读取数据注册插件和 Provider监听应用的生命周期H5Session：一个 H5Session 是由一叠 H5Pages 组成的完整业务流程。例如一个收银台的流程包括：一个购物车的小结页面，一个结账方式的选择页面，和最后一个结账确认页面。所有的页面都可以独立存在运作， H5Session 在其中的作用是把这些页面组织起立，按照业务逻辑把它们按序排列来完成业务。当你使用 H5Service 创建且开启一个新的 Web page 时，如果当前没有 H5Session 的话，一个新的 H5Session 实例将被创建，并为后续创建的 Web page 共享。你可以从 H5Session 中移除页面直到页面叠为空，也可以使用 H5Session 所提供的方法来获取首页，以及监听该 H5Session 的生命周期。 H5Page：是用户看得见，摸得着的页面，也是应用生命周期中最重要的一部分。你可以通过 URL 来加载内容，用 H5Param 来定制页面的外观和行为，甚至可以通过获取 H5Page 的视图层次，把 H5Page 视图和其他原生 UI 部件一起内嵌到同一个布局中。下面是 H5 容器的几个重要组成部分：API 管理器主要管理 JS API：Nebula 中已经提供许多内置的 JS API 供开发者使用，比如操控 UI，显示对话框和 Toast，以及使用网络 RCP 服务等。插件管理器主要管理 Plugin：如果现有的 JS API 无法满足你的业务需求，你也可以选择创造一个新的插件。你只需把原生代码打包在插件中，在管理器里注册该插件，便可在 Javascript 层使用新的 JS API 了JS Bridge 是连接原生层和 Javascript 的沟通桥梁：它将 Javascript 代码转译成能在系统框架运行的字节码，同时也把原生层的数据结构转成 Javascript 对象使其能在 Javascript 层处理。这里 Nebula 针对JS Bridge 做了一些优化：在 Android 里，js 调用 native 的通讯是通过 console.log 的方式，这个和其他容器实现不一样，其他容器一般通过 prompt 的方式来实现的，但是使用 prompt 的方式，有两个弊端：使用 prompt 会阻断整个浏览器的进程，如果 native 处理时间一长，会导致页面假死。prompt 是在 UI 层面上会弹出一个模态窗口，在 native 没有对其进行捕获处理的话，会造成一个问题。一旦这个页面放在非此容器的环境下，就会出现一个很诡异的 prompt 弹窗。在支付宝内，曾经出现过这个问题，天猫页面在支付宝 app 里的时候，由于容器机制不同，页面中 bridge 脚本没有判断环境，导致页面中 js 调用 API 的时候，在页面上出现了 prompt 的模态对话框，严重影响了用户体验，但是如果使用 console.log 的话，就不会出现这个问题。console 的方式避免了不兼容环境的体验问题和同时也避免了页面的假死。jsbridge 注入的时机，由于业务逻辑要依赖 bridge，所以业务的所有逻辑都会在 bridge ready 之后才会触发，而 bridge js 本身运行是要一定的时间的，因此注入的时机对于性能的影响显得非常的重要。但由于 H5 页面的生命周期和容器的生命周期是相互独立的，因此在 H5 生命周期的哪个阶段注入这段 bridgejs，对于性能的影响就显得异常重要。现在在支付宝内使用的方式为监听 H5 生活周期的事件，比如说当 Webview 设置 title 结束之后，Android 会放出一个 onReceivedTitle、shouldInterceptRequest 等事件，iOS 会尝试在 webViewDidStartLoad 事件，在监听到这些事件之后，立即注入 bridgejs，让其在 H5 生命周期尽早运行。通过这种方式的注入，经过测试，最早能在页面加载开始后， 50ms 以内就能成功注入 bridgejs。Event 机制：Nebula 提供了一套事件机制来管理事件在 H5Page，H5Session 和 H5Service 之间的流通顺序。一个 H5Event 可以在 H5Page, H5Session 或 H5Service 任何一层发生，事件派遣分为两步完成事件拦截。这个步骤中事件派遣的顺序为 H5Service -> H5Session or H5Page。事件可以在任何节点被拦截 （如果 interceptEvent() 返回 true ），也可以在任何节点被处理 （如果 handleEvent() 返回 true ）：如果事件在派遣过程中被拦截或处理，该事件将被视为已被消费且不再继续流通。如果在派遣过程后事件依旧没有被拦截或处理，会有错误抛给呼叫方处理。仅仅使用传统的 H5 技术展示在线页面，很容易受到网络环境影响，因而降低 H5 页面的性能。在 Neblua 中我们使用离线包技术来解决这个问题。离线包是将包括 HTML、Javascript、CSS 等页面内静态资源打包到一个压缩包内，它的目录结构如图所示：使用离线包可以使容器内的 H5 应用具有接近 Native 的体验，主要优势如下：减少网络环境对 H5 应用的影响：通过下载离线包到本地，然后在客户端打开，把打开H5页面的操作从网络 IO，变成磁盘 IO。直接从本地加载离线包，不仅最大程度地摆脱网络环境对 H5 页面的影响，而且增强了用户体验。提升用户打开 H5 应用的体验：通过离线包的方式把页面内静态资源嵌入到应用中并发布，当用户第一次开启应用的时候，就无需依赖网络环境下载该资源，而是马上开始使用该应用。实现动态更新：在推出新版本或是紧急发布的时候，您可以把修改的资源放入离线包，通过更新配置让应用自动下载更新。因此，您无需通过应用商店审核，就能让用户及早接收更新。下面介绍一下离线包的渲染过程当 H5 容器发出资源请求时，其访问本地资源或线上资源所使用的 URL 是一致的。H5 容器会先截获该请求，截获请求后，发生如下情况：如果本地有资源可以满足该请求的话，H5 容器会使用本地资源。如果没有可以满足请求的本地资源，H5 容器会使用线上资源。因此，无论资源是在本地或者是线上，WebView 都是无感知的。离线包的下载依赖用户当前的网络。一般情况下，只有在连接 WIFI 的情况下才会在后台下载离线包。如果用户处于移动网络下，不会在后台下载离线包。如果当前用户点击 APP，离线包没有下载好，用户就要等待离线包下载好才能用。为了解决离线包不可用的场景，fallback 技术应运而生。每个离线包发布的时候，都会同步在 CDN 发布一个对应的线上版本，目录结构和离线包结构一致。fallback 地址会随离线包信息下发到本地。在离线包没有下载好的场景下，客户端会拦截页面请求，转向对应的 CDN 地址， 实现在线页面和离线页面随时切换。那么本地资源如何寻址呢，我们设计了独特的虚拟域名机制，仅对离线应用有效。当页面保存在客户端之后，WebView 如果要访问的话，是通过 file schema 来从本地加载访问的。然而，用户就能在地址栏里直接看到 file 的路径，这就会导致以下问题：用户体验问题：当用户看到了 file 地址，会对暴露的地址产生不安全感和不自在。安全性问题：由于 file 协议上直接带上了本地路径，任何用户都可以看到这个文件所在的文件路径，会存在一定的安全隐患。基于如上问题的考虑，采用虚拟域名的机制而不直接使用 file 路径来访问。虚拟域名是一个符合 URL Scheme 规范的 HTTPS 域名地址，例如 https://xxxxxxx.h5app.example…Nebula 里面的 H5 容器和离线包，在传统的 Hybrid 框架的基础上进行了极致的优化，使整个 H5 应用具有如下特点：对网络链路强依赖的弱化增强对设备能力的支持增强的用户体验在性能方面，Nebula 在支付宝中经过了亿级用户的考验，crash 和 anr 以及其他稳定性指标有保障。Android 平台基于 UCWebview 深度定制，crash 率和 anr 量远低于系统webview，拥有解决系统 Webview 问题的能力。图中展示的就是在 Android 端，UCWebview 和系统 Webview 之间崩溃率和 ANR 率的对比，稳定性的优势显而易见。最后看一下小程序与 Nebula支付宝小程序复用 Nebula 容器技术栈，重构了开发方式，对外暴露有限个 jsapi 接口，让 app 开发更简单，更加便捷利用支付宝的能力，进而发布、推广、运营。小程序本质上是也是一个 H5 App 离线包，但是有一些自己的特点。小程序是为第三方 App 服务的，运行在独立进程，它的稳定和闪退不会影响到主 App，也支持二方 App 运行在主进程。小程序是支持保活的，极大的提升二次打开的体验。mPaaS技术架构与助力Nebula 有这么大优势，现在不仅在蚂蚁金服内部使用，也能够提供给外部来使用。首先什么是 mPaaS 呢，mPaaS 全称是 Mobile Platform as a Service 。是蚂蚁金服独创的移动研发平台，它源于支付宝 App 近 10 年的移动技术实践和思考，为移动开发、测试、运营及运维提供云到端的一站式解决方案，能有效降低技术门槛、减少研发成本、提升开发效率，协助生态伙伴快速搭建稳定高质量的移动 App。在 mPaaS 中，我们将 Nebula 的 H5 容器、jsapi 、离线包、小程序这些模块作为一个单独的组件来进行输出，在客户端中进行配置。任何一个 App 通过 mPaaS 插件，添加对应的模块，集成这些功能，只需要这样简单的操作，就可以让你的应用具有和支付宝一样强大的动态化能力。 同时 mPaaS 提供的小程序模块，允许用户把运行在支付宝上的小程序，无缝的迁移到自己的 App 中，做到【跨平台跨应用】开发，提高代码的复用能力Nebula 组件化输出，配合 mPaaS 提供的 MDS （移动发布服务） 来实现动态更新。mPaaS 提供的 MDS 服务，能够让每次发布更新就像发邮件一样简单。MDS 具有智能灰度发布的能力，可以通过内部灰度，外部灰度多重验证，保证在正式发布之前，发布的产品质量有充分的保证，同时提供多种升级策略，包括指定人群地域、机型，系统版本，网络环境等多种规则。对于离线包来说，更新离线包的下载对网络环境要求较高，包的大小越大，更新的成功率越低，在 mPaaS 中，我们采用增量差分的更新能力，减少数据冗余及设备带宽，在移动网络条件下优势明显。同时保证更新功能的高可用性，升级接口可用率达 99.99%，在线分钟级触达。下面是 Nebula 的生态基础，首先在集团内部，我们已经支持了不少产品，同时通过 mPaaS ，我们也与外部客户合作，将我们的技术能力输出给他们，典型的几个案例，包括 12306 客户端，广发发现精彩客户端，上海地铁，苏州银行等。尤其是 12306，使用 mPaaS 改版之后，客户端整体的体验更加优越。12306 整个客户端绝大部分都是使用的 H5 技术，他们就是使用 Nebula H5 容器 配合离线包来实现，无论是页面打开速度，还是UI事件响应，体验几乎接近 native。在更新发布方面，12306 的 app 包很少更新，以 AppStore 上的发布记录来看，今年只提交了两个版本，基本上都是通过动态化的方式完成业务的迭代发布。总结下来，蚂蚁金服 mPaaS 中就是通过「Nebula H5容器 + 离线包 + 小程序 + MDS」这样的方式来实现移动端的动态化方案。本文作者：平生栗子阅读原文本文为云栖社区原创内容，未经允许不得转载。 ...

随着阿里大数据产品业务的增长，服务器数量不断增多，IT运维压力也成比例增大。各种软、硬件故障而造成的业务中断，成为稳定性影响的重要因素之一。本文详细解读阿里如何实现硬件故障预测、服务器自动下线、服务自愈以及集群的自平衡重建，真正在影响业务之前实现硬件故障自动闭环策略，对于常见的硬件故障无需人工干预即可自动闭环解决。1.背景1.1.面临挑战对于承载阿里巴巴集团95%数据存储及计算的离线计算平台MaxCompute，随着业务增长，服务器规模已达到数十万台，而离线作业的特性导致硬件故障不容易在软件层面被发现，同时集团统一的硬件报障阈值常常会遗漏一些对应用有影响的硬件故障，对于每一起漏报，都对集群的稳定性构成极大的挑战。针对挑战，我们面对两个问题：硬件故障的及时发现与故障机的业务迁移。下面我们会围绕这两个问题进行分析，并详细介绍落地的自动化硬件自愈平台——DAM。在介绍之前我们先了解下飞天操作系统的应用管理体系——天基（Tianji）。1.2.天基应用管理MaxCompute是构建在阿里数据中心操作系统——飞天（Apsara）之上，飞天的所有应用均由天基管理。天基是一套自动化数据中心管理系统，管理数据中心中的硬件生命周期与各类静态资源（程序、配置、操作系统镜像、数据等）。而我们的硬件自愈体系正是与天基紧密结合，利用天基的Healing机制构建面向复杂业务的硬件故障发现、自愈维修闭环体系。透过天基，我们可以将各种物理机的指令（重启、重装、维修）下发，天基会将其翻译给这台物理机上每个应用，由应用根据自身业务特性及自愈场景决策如何响应指令。2.硬件故障发现2.1.如何发现我们所关注的硬件问题主要包含：硬盘、内存、CPU、网卡电源等，下面列举对于常见硬件问题发现的一些手段和主要工具：在所有硬件故障中，硬盘故障占比50%以上，下面分析一下最常见的一类故障：硬盘媒介故障。通常这个问题表象就是文件读写失败/卡住/慢。但读写问题却不一定是媒介故障产生，所以我们有必要说明一下媒介故障的在各层的表象。a. 系统日志报错是指在/var/log/messages中能够找到类似下面这样的报错Sep 3 13:43:22 host1.a1 kernel: : [14809594.557970] sd 6:0:11:0: [sdl] Sense Key : Medium Error [current]Sep 3 20:39:56 host1.a1 kernel: : [61959097.553029] Buffer I/O error on device sdi1, logical block 796203507b. tsar io指标变化是指rs/ws/await/svctm/util等这些指标的变化或突变，由于报错期间会引起读写的停顿，所以通常会体现在iostat上，继而被采集到tsar中。在tsar io指标中，存在这样一条规则让我们区分硬盘工作是否正常 qps=ws+rs<100 & util>90，假如没有大规模的kernel问题，这种情况一般都是硬盘故障引起的。c. 系统指标变化通常也由于io变化引起，比如D住引起load升高等。d. smart值跳变具体是指197(Current_Pending_Sector)/5(Reallocated_Sector_Ct)的跳变。这两个值和读写异常的关系是：媒介读写异常后，在smart上能观察到197(pending) +1，表明有一个扇区待确认。随后在硬盘空闲的时候，他会对这个197(pending)中攒的各种待确认扇区做确认，如果读写通过了，则197(pending) -1，如果读写不通过则 197(pending)-1 且 5(reallocate)+1。总结下来，在整条报错链路中，只观察一个阶段是不够的，需要多个阶段综合分析来证明硬件问题。由于我们可以严格证明媒介故障，我们也可以反向推导，当存在未知问题的时候能迅速地区分出是软件还是硬件问题。上述的工具是结合运维经验和故障场景沉淀出来，同时我们也深知单纯的一个发现源是远远不够的，因此我们也引入了其他的硬件故障发现源，将多种检查手段结合到一起来最终确诊硬件故障。2.2.如何收敛上一章节提到的很多工具和路径用来发现硬件故障，但并不是每次发现都一定报故障，我们进行硬件问题收敛的时候，保持了下面几个原则：指标尽可能与应用/业务无关：有些应用指标和硬件故障相关性大，但只上监控，不作为硬件问题的发现来源。 举一个例子，当io util大于90%的时候硬盘特别繁忙，但不代表硬盘就存在问题，可能只是存在读写热点。我们只认为io util>90且iops<30 超过10分钟的硬盘可能存在硬件问题。采集敏感，收敛谨慎：对于可能的硬件故障特征都进行采集，但最终自动收敛分析的时候，大多数采集项只做参考，不作为报修依据。 还是上一个硬盘io util的例子，如果单纯出现io util>90且iops<30的情况，我们不会自动报修硬盘，因为kernel问题也可能会出现这个情况。只有当 smartctl超时/故障扇区 等明确故障项出现后，两者关联才确诊硬盘故障，否则只是隔离观察，不报修。2.3.覆盖率以某生产集群，在20xx年x月的IDC工单为例，硬件故障及工单统计如下：去除带外故障的问题，我们的硬件故障发现占比为97.6%。3.硬件故障自愈3.1 自愈流程针对每台机器的硬件问题，我们会开一个自动轮转工单来跟进，当前存在两套自愈流程：【带应用维修流程】和【无应用维修流程】，前者针对的是可热拔插的硬盘故障，后者是针对余下所有的整机维修硬件故障。在我们的自动化流程中，有几个比较巧妙的设计：a. 无盘诊断对于宕机的机器而言，无法进无盘(ramos)才开【无故宕机】维修工单，这样能够大量地减少误报，减少服务台同学负担。无盘中的压测可以完全消除当前版本的kernel或软件的影响，真实地判断出硬件是否存在性能问题。b. 影响面判断/影响升级对于带应用的维修，我们也会进行进程是否D住的判断。如果存在进程D住时间超过10分钟，我们认为这个硬盘故障的影响面已扩大到了整机，需要进行重启消除影响。在重启的时候如果出现了无法启动的情况，也无需进行人工干预，直接进行影响升级，【带应用维修流程】直接升级成【无应用维修流程】。c. 未知问题自动化兜底在运行过程中，会出现一些机器宕机后可以进无盘，但压测也无法发现任何硬件问题，这个时候就只能让机器再进行一次装机，有小部分的机器确实在装机过程中，发现了硬件问题继而被修复了。d. 宕机分析整个流程巧妙的设计，使得我们在处理硬件故障的时候，同时具备了宕机分析的能力。不过整机流程还以解决问题为主导向，宕机分析只是副产品。同时，我们也自动引入了集团的宕机诊断结果进行分析，达到了1+1>2的效果。3.2.流程统计分析如果是同样的硬件问题反复触发自愈，那么在流程工单的统计，能够发现问题。例如联想RD640的虚拟串口问题，在还未定位出根因前，我们就通过统计发现了：同个机型的机器存在反复宕机自愈的情况，即使机器重装之后，问题也还是会出现。接下来我们就隔离了这批机器，保障集群稳定的同时，为调查争取时间。3.3.业务关联误区事实上，有了上面这套完整的自愈体系之后，某些业务上/kernel上/软件上需要处理的问题，也可以进入这个自愈体系，然后走未知问题这个分支。其实硬件自愈解决业务问题，有点饮鸩止渴，容易使越来越多还没想清楚的问题，尝试通过这种方式来解决兜底。当前我们逐步地移除对于非硬件问题的处理，回归面向硬件自愈的场景（面向软件的通用自愈也有系统在承载，这类场景与业务的耦合性较大，无法面向集团通用化），这样也更利于软硬件问题分类和未知问题发现。4.架构演进4.1.云化最初版本的自愈架构是在每个集群的控制机上实现，因为一开始时候运维同学也是在控制机上处理各种问题。但随着自动化地不断深入，发现这样的架构严重阻碍了数据的开放。于是我们采用中心化架构进行了一次重构，但中心化架构又会遇到海量数据的处理问题，单纯几个服务端根本处理不过来。因此我们对系统进一步进行分布式服务化的重构，以支撑海量业务场景，将架构中的各个模块进行拆解，引入了 阿里云日志服务(sls)/阿里云流计算(blink)/阿里云分析数据库(ads) 三大神器，将各个采集分析任务由云产品分担，服务端只留最核心的硬件故障分析和决策功能。下面是DAM1与DAM3的架构对比4.2.数据化随着自愈体系的不断深入，各阶段的数据也有了稳定的产出，针对这些数据的更高维分析，能让我们发现更多有价值且明确的信息。同时，我们也将高维的分析结果进行降维，采用健康分给每台机器打标。通过健康分，运维的同学可以快速知晓单台机器、某个机柜、某个集群的硬件情况。4.3.服务化基于对全链路数据的掌控，我们将整个故障自愈体系，作为一个硬件全生命周期标准化服务，提供给不同的产品线。基于对决策的充分抽象，自愈体系提供各类感知阈值，支持不同产品线的定制，形成适合个性化的全生命周期服务。5.故障自愈闭环体系在AIOps的感知、决策、执行闭环体系中，软件/硬件的故障自愈是最常见的应用场景，行业中大家也都选择故障自愈作为首个AIOps落地点。在我们看来，提供一套通用的故障自愈闭环体系是实现AIOps、乃至NoOps（无人值守运维）的基石，应对海量系统运维，智能自愈闭环体系尤为重要。5.1.必要性在一个复杂的分布式系统中，各种架构间不可避免地会出现运行上的冲突，而这些冲突的本质就在于信息不对称。而信息不对称的原因是，每种分布式软件架构在设计都是内敛闭环的。现在，通过各种机制各种运维工具，可以抹平这些冲突，然而这种方式就像是在打补丁，伴随着架构的不断升级，补丁似乎一直都打不完，而且越打越多。因此，我们有必要将这个行为抽象成自愈这样一个行为，在架构层面显式地声明这个行为，让各软件参与到自愈的整个流程中，将原本的冲突通过这种方式转化为协同。当前我们围绕运维场景中最大的冲突点：硬件与软件冲突，进行架构和产品设计，通过自愈的方式提升复杂的分布式系统的整体鲁棒性。5.2.普适性透过大量机器的硬件自愈轮转，我们发现：被纳入自愈体系的运维工具的副作用逐渐降低（由于大量地使用运维工具，运维工具中的操作逐渐趋于精细化）。被纳入自愈体系的人工运维行为也逐渐变成了自动化。每种运维动作都有了稳定的SLA承诺时间，不再是随时可能运行报错的运维脚本。因此，自愈实际上是在复杂的分布式系统上，将运维自动化进行充分抽象后，再构筑一层闭环的架构，使得架构生态形成更大的协调统一。本文作者：钟炯恩阅读原文本文来自云栖社区合作伙伴“阿里技术”，如需转载请联系原作者。

在新零售成为大趋势的今天，餐饮行业也加入到这一浪潮之中。智能餐饮系统将帮助餐饮行业从多个维度提升自己的运营能力和收益，而打造智能餐饮系统SaaS化能力也成为了目前的一个热点。本文中果仁软件联合创始人&研发副总赵亚南就为大家带来了关于使用阿里云POLARDB构建客到智能餐饮系统实践分享。本次分享中，首先介绍了“客到云餐饮”这款SaaS化产品，其次介绍随着业务发展所需要面对的挑战，以及“客到”为什么要选择POLARDB。第三将讲述使用POLARDB的解决方案以及迁移的整个过程所做的实践，最后将分享将数据库架构升级到POLARDB之后的效果。果仁软件与“客到云餐饮”背景介绍果仁软件早在2008年就是淘宝服务平台的第一批软件开发商，当时做了“麦多多”产品，也正是因为这款产品，果仁软件成为了阿里云的第一批客户。在使用阿里云的过程中也逐渐更多地了解了这些云产品，目前整体的技术架构都是基于阿里云的。使用阿里云产品为果仁软件带来的好处就是节省了大量运维成本，能够使技术团队更加专注于自身产品和业务的开发上。四年前，基于使用阿里云的经验和对于软件的理解，果仁软件参与到了餐饮行业的SaaS化软件“客到云餐饮”开发中。客到主要实现了SaaS化餐饮解决方案，包括了点餐、收银、财务以及后厨管理和营销、员工绩效考核等。“客到”通过智能化、数字化的餐饮服务软件，可以帮助餐厅更好地提升经营效率和服务质量，让客户真正地享受到餐饮行业所带来的服务。智能化点餐以及收银能够帮助餐厅很好地降低了人力成本和时间成本，智能化餐饮系统能够让餐厅的工作人员直接在报表中看到所有的流水信息，使得对账工作更加轻松简单。餐厅的厨师本身就非常忙碌，那么借助智能化后厨管理就能帮助厨师有序地制作菜品，进而提升后厨效率。会员营销是SaaS化中常用的功能，但是对于餐饮行业，传统会员营销方式并不能有效地吸引顾客，而借助智能系统，餐厅可以开展店内店外的智能营销，使得活动更加高效，为餐厅带来更多的资金流。很多餐饮企业越来越注意实时化的信息，对于报表的实时性要求更高。因此，餐饮行业的SaaS化就可以从这样的切入点开展。此外，“客到”在用户体验上也做了精细化设置，比较简洁、实用。而通过软件与智能硬件的配合，就能够更好地赋能餐饮行业。“客到”借助阿里云的SaaS化发展之路餐饮行业的特点就是业务峰值比较高，特别是午餐和晚餐时段这一点就体现的更为明显。通过阿里云后台的云监控可以看到在这两个时间段，几乎在瞬间系统压力就会大幅度提升，这就需要系统能够很好地应对峰值情况。此外，周末的晚上会比平时出现更大的峰值，能够达到平时的2到3倍。而且餐厅的订单数据量也是非常大的，正常的一家中餐厅每餐大概会销售200到250单，一些快餐厅甚至会达到1000到2000单。这样如果服务1万家餐厅，订单量就能达到每天100万，每年订单量就会达到7、8亿。结合菜单的明细数据，这样的数据量是非常大的。而且由于涉及到订单、会员以及促销等信息，因此表结构也会比较大，而且在高峰的时候这些业务都会出现高并发。此外，由于餐厅的特点，因此对于系统的稳定性要求非常高，基本上可以说是“365*24”小时的可用性要求。因为很多餐厅不仅提供中餐和晚餐，还会提供夜宵和早餐。之前用户量小时，就可以等待用户没有的时候进行发布新版本，而当用户量增大之后发现，这样的空闲时段已经不存在了。在最初设计餐饮软件的时候，认为只要餐厅有网络就完全可以实现SaaS化。但是后来发现在业务高峰的时候，即使带宽足够，但是在访问云端数据的时候还是非常差，甚至中断而影响业务。基于这样的情况，客到实现了本地的架构调整，能够实现即使断网也不影响业务流程的继续运行，用户对于网络情况可以实现无感知，这一点在友商内能够做到的也并不多，因此也收获了较好的口碑。随着业务发展量越来越大，用户量也越来越多，需求不断增加，业务的逻辑也越来越复杂。随着多种点餐方式以及多种下单场景的增加，对于业务调整的及时性要求越来越高。此外，产品线也越来越丰富，从3个产品飞速扩展得到8个产品。而随着业务量的增长，历史数据也飞速增长，有时候会因为云端的“慢SQL”出现卡顿，暴露出一些隐藏的问题。通过阿里云监控，及时地感知到高峰时期的CPU、内存等的报警信息，进而增加服务器或者服务器组的处理。针对于上述出现的问题，经常会做一些相应的分析。从页面的加载、前端再到后台数据库都会进行排查。在系统优化方面，会每天排查出慢SQL进行优化，包括RDS也会存在慢查询的统计，虽然慢查询并不会影响业务的正常运转，但是总会带来一些不好的用户体验。针对于以上的情况，需要增加一些索引机制以及缓存层等，对于一些历史数据进行归档，对于一些业务进行拆分，减少单表的压力，同时使得业务架构更加清晰。虽然以上的技术问题并不会影响业务的正常运转，但是有限的研发精力总是被这些技术问题所牵绊，就会影响技术团队开发新的需求和功能的速度和效率。特别是对于创业公司而言，研发效率和用户需求是最为注重的关键点。因此更加希望将技术精力集中在产品业务的开发中，做好产品，服务好客户。如果能够通过更好的技术方式和产品减少非主线研发的工作量也是各个公司以及架构师所需要考虑的。也就是说除了需要解决当前问题，还需要能够支撑起两年之内的业务扩展，虽然中间也会经历架构演变，但是对于架构师而言，需要做到心里有底。此外，好的产品一定能够提供好的性能，同时在费用上需要做到可控和可预算。为大家简单分享一下“客到”基于阿里云的架构设计。首先，从用户开始访问开始，阿里云提供了域名解析服务和CDN加速以及网络安全方面的Web应用防火墙。经过域名解析之后就到了前端的服务器，而通过负载均衡器将会将前置服务器和后置服务器再次分离，进而解决应用层面的并发请求量。应用服务器为了解决Session共享问题可以应用Redis解决，实现单机出现宕机不影响用户使用，从而实现高可用。同时Redis缓存可以有效缓解数据库层面的压力，但是在使用的时候也需要注意其自身的特点，比如带宽限制以及逻辑上需要和存储层保持一致。存储层之前使用RDS，现在换用了POLARDB，之前通过一台主RDS和几个RDS只读节点就基本上解决了关系型存储，可以对于订单的历史数据完成异步的备份。对于文件和图片等的存储可以放在阿里云OSS之上，这样比放在磁盘上更加节省成本。在安全方面，使用最多的就是云监控产品，这样就可以实现问题的提前监控预警。在设计架构的时候，架构师需要不断地梳理架构，这样在进行架构演进的时候就可以容易地分析和判断架构是否可以迁移。“客到”数据库架构向POLARDB迁移实践在进行架构迁移的可行性分析的时候，首先要把现在架构的情况，涉及到的业务以及运行的主机、ECS以及OSS都需要进行风险评估。所以在实际进行系统迁移的时候需要首先进行评估。之后为了打消研发和产品对于采用新技术和产品的顾虑，就需要做充分的准备和测试，比如对于应用POLARDB而言，需要对于性能进行充分测试，比如100%兼容MySQL，还需要对于业务进行全流程测试，在测试完成之后需要第一时间进行测试反馈。在迁移之后需要进行效果评估，“客到”在迁移到POLARDB之后发现页面响应速度得到了80%的提升，复杂SQL处理性能得到了200%的提升，而费用则降低了20%。而且整个迁移过程只使用了1个多小时，生产环境目前平稳运行，并且业务代码没有做任何修改，只做了配置文件的简单替换。最后为大家分享在数据库架构迁移过程中需要注意的两个关键点，第一点就是VPC的迁移，POLARDB使用的是VPC网络连接，那么在迁移的时候就需要做好网络规划，需要把握好时间点。此外，需要注意白名单的变化，因为在整个网络架构发生变化的时候，外网IP的变动有可能影响到第三方接口调用。本文作者：桐碧2018阅读原文本文为云栖社区原创内容，未经允许不得转载。

第一阶段：三年我认为三年对于程序员来说是第一个门槛，这个阶段将会淘汰掉一批不适合写代码的人。这一阶段，我们走出校园，迈入社会，成为一名程序员，正式从书本 上的内容迈向真正的企业级开发。我们知道如何团队协作、如何使用项目管理工具、项目版本如何控制、我们写的代码如何测试如何在线上运行等等，积累了一定的 开发经验，也对代码有了一定深入的认识，是一个比较纯粹的Coder的阶段。第二阶段：五年五年又是区分程序员的第二个门槛。有些人在三年里，除了完成工作，在空余时间基本不会研究别的东西，这些人永远就是个Coder，年纪大一些势必被 更年轻的人给顶替；有些人在三年里，除了写代码之外，还热衷于研究各种技术实现细节、看了N多好书、写一些博客、在Github上分享技术，这些人在五年 后必然具备在技术上独当一面的能力并且清楚自己未来的发展方向，从一个Coder逐步走向系统分析师或是架构师，成为项目组中不可或缺的人物。第三阶段：十年十年又是另一个门槛了，转行或是继续做一名程序员就在这个节点上。如果在前几年就抱定不转行的思路并且为之努力的话，那么在十年的这个节点上，有些 人必然成长为一名对行业有着深入认识、对技术有着深入认识、能从零开始对一个产品进行分析的程序员，这样的人在公司基本担任的都是CTO、技术专家、首席 架构师等最关键的职位，这对于自己绝对是一件荣耀的事，当然老板在经济上也绝不会亏待你。第一部分总结一下，我认为，随着你工作年限的增长、对生活对生命认识的深入，应当不断思考三个问题：1、我到底适不适合当一名程序员？2、我到底应不应该一辈子以程序员为职业？3、我对编程到底持有的是一种什么样的态度，是够用就好呢还是不断研究？最终，明确自己的职业规划，对自己的规划负责并为之努力。关于项目经验在网上经常看到一些别的朋友有提出项目经验的问题，依照我面试的感觉来说，面试主要看几点：项目经验+基本技术+个人潜力（也就是值不值得培养）。关于项目经验，我认为并发编程网的创始人方腾飞老师讲的一段话非常好：介绍产品时面试官会考察应聘者的沟通能力和思考能力，我们大部分情况都是做产品的一个功能或一个模块，但是即使是这样，自 己有没有把整个系统架构或产品搞清楚，并能介绍清楚，为什么做这个系统？这个系统的价值是什么？这个系统有哪些功能？优缺点有哪些？如果让你重新设计这个 系统你会如何设计？我觉得这就已经足以概括了。也许你仅仅工作一年，也许你做的是项目中微不足道的模块，当然这些一定是你的劣势且无法改变，但是如何弥补这个劣势？从方老师的话中我总结几点：1、明确你的项目到底是做什么的，有哪些功能。2、明确你的项目的整体架构，在面试的时候能够清楚地画给面试官看并且清楚地指出从哪里调用到哪里、使用什么方式调用。3、明确你的模块在整个项目中所处的位置及作用。4、明确你的模块用到了哪些技术，更好一些的可以再了解一下整个项目用到了哪些技术。在你无法改变自己的工作年限、自己的不那么有说服力的项目经验的情况下（这一定是扣分项），可以通过这种方式来一定程度上地弥补并且增进面试官对你的好感度。关于专业技能写完项目接着写写一名3年工作经验的Java程序员应该具备的技能，这可能是Java程序员们比较关心的内容。我这里要说明一下，以下列举的内容不是都要会的东西—-但是如果你掌握得越多，最终能得到的评价、拿到的薪水势必也越高。01 高可用负载均衡（负载均衡算法）反向代理服务隔离服务限流服务降级（自动优雅降级）失效转移超时重试（代理超时、容器超时、前端超时、中间件超时、数据库超时、NoSql超时）回滚机制（上线回滚、数据库版本回滚、事务回滚）02 高并发应用缓存HTTP 缓存多级缓存分布式缓存连接池异步并发03 分布式事务二阶段提交(强一致)三阶段提交(强一致)消息中间件(最终一致性)，推荐阿里的 RocketMQ。04 队列任务队列消息队列请求队列05扩容单体垂直扩容单体水平扩容应用拆分数据库拆分数据库分库分表数据异构分布式任务06 网络安全SQL 注入XSS 攻击CSRF 攻击拒绝服务（DoS，Denial of Service）攻击学习方向：01、maven的使用maven的使用入门maven私服的搭建及部署maven坐标分析/父控设置02、git版本管理及jenkins自动化构建git使用入门培训git常用命令分析和使用jenkins环境搭建及插件配置git+jenkins实现自动化构建03、NoSql专题-redis高性能缓存redis使用入门redis常用命令及客户端的使用redis高可用集群搭建04、NoSql专题-mongodbmongodb使用入门mongodb高可用集群搭建mongodb常用命令及客户端的使用05、分布式专题-zookeeper+dubbo服务协调zookeeper安装部署及命令分析zookeeper客户端的使用zookeeper实现原理分析dubbo的使用入门及配置分析zookeeper+dubbo实现服务注册和发现06、分布式专题-消息中间件activeMq-jms规范及使用activeMq消息分发机制分析kafka实现原理剖析kafka的数据传输事务性及实践练习07、分布式缓存分析对比memcache的原理分析及使用memcache和redis的横向对比分析分布式接口技术webservice/RMI/restful的使用09、高并发专题-数据库层面优化分库分表的原理及规则讲解数据库主备及高可用10、性能调优专题-jvm调优JVM原理剖析jvm内存模型及垃圾回收器的分析11、性能调优专题-容器性能优化nginx性能优化tomcat性能优化12、性能调优专题-数据库优化mysql常见优化手段分析及实践13、高性能容器的使用nginx使用入门nginx负载均衡/反向代理实现14、双十一专题-九阳真经太极聚气之分布式压测平台氤氲紫气之分布式缓存体系盘龙真诀之分布式消息系统金刚之躯之分布式跟踪系统外功辅助之分布式配置系统15、微服务架构技术栈分析springboot的使用16、分布式协调服务zookeeperzookeeper集群及相关概念分析zookeeper java api的使用及实践17、从集中式到分布式架构分布式架构的演进过程分布式架构的基石-TCP/UDP18、分布式通信协议分布式通信协议-HTTP及RESTful分布式通信协议-webservice详解分布式通信协议-RMI分布式通信协议-序列化技术19、分布式服务治理dubbo控制台及监控中心的安装部署dubbo常用配置分析dubbo实战演练20、NIO技术之-NettyNIO基本概念及BIO、AIO的对比分析NIO核心设计思想剖析（Buffer/Channel..）Netty产生的背景及优缺点分析Netty实现IM聊天系统21、分布式缓存技术-Redisredis的安装及数据类型分析Redis客户端的使用Redis高可用方案实战Redis+Lua脚本实现原子操作22、高性能之道-MongoDBMongoDB高可用部署MongoDB动态查询及索引剖析MongoDB集成spring应用23、数据库高性能之道-Mysql分库分表深入分析Mysql主从模型配置/Mycat的使用24、分布式通信技术JMS基本概念和模型ActiveMQ结合Spring开发ActiveMQ静态网络和动态网络链接Kafka的高可用方案及原理分析25、SOA架构及微服务架构什么是SOA架构/为什么需要SOA领域驱动设计方法/典型SOA架构设计spring boot深入剖析spring boot+dubbo企业实战26、Docker虚拟化技术Docker虚拟化技术(镜像/仓库/容器)Docker整合spring bootDocker 服务编排27、导流技术Nginx反向代理、负载均衡Nginx进程模型分析Nginx+keepalived高可用方案28、微服务技术spring boot（mvc）spring boot（REST）spring boot(验证）29、spring cloudspring cloud config clientspring cloud config serverspring cloud netflix eurekaspring cloud netflix ribbonspring cloud hystrixspring cloud feignspring cloud streamspring cloud busspring cloud sleuth30、分布式消息技术-kafkakafka高可用集群及介绍kafka底层实现原理分析31、分布式缓存-redisredis的数据类型分析redis高可用集群方案lua脚本在redis中的应用32、高性能之道-MongoDBMongoDB的基本原理MongoDB常用命令及客户端使用手写基于MongoDB的ORM框架MongoDB高可用解决方案33、数据库高性能-Mysql分库分表深入分析及主从模型数据库中间件Mycat介绍34、性能优化专题从测试的角度解读如何衡量性能了解Linux系统35、虚拟机-JVM内存模型、运行时数据垃圾回收、GC日志调优实战36、容器优化-Tomcattomcat架构分析线程模型分析tomcat调优实战37、Mysql数据库调优Mysql底层存储分析面试技巧之SQL执行计划及优化手段上面知识词汇是否在你脑海里呢？

译注：为了便于对照参考，“Serverless”、“BaaS” 等术语文中不做翻译。原文很长，这里分成上下两篇。翻译过程在 GitHub 上进行。原文：https://martinfowler.com/articles/serverless.html 作者：Mike Roberts无服务器架构（Serverless architectures）是指一个应用大量依赖第三方服务（后端即服务，Backend as a Service，简称“BaaS”），或者把代码交由托管的、短生命周期的容器中执行（函数即服务，Function as a Service，简称“FaaS”）。现在最知名的 FaaS 平台是 AWS Lambda。把这些技术和单页应用等相关概念相结合，这样的架构无需维护传统应用中永远保持在线的系统组件。Serverless 架构的长处是显著减少运维成本、复杂度、以及项目起步时间，劣势则在于更加依赖平台供应商和现阶段仍有待成熟的支持环境。引言无服务器计算（Severless computing，简称 Serverless）现在是软件架构圈中的热门话题，三大云计算供应商（Amazon、Google 和 Microsoft）都在大力投入这个领域，涌现了不计其数的相关书籍、开源框架、商业产品、技术大会。到底什么是 Serverless？它有什么长处/短处？我希望通过本文对这些问题提供一些启发。开篇我们先来看看 Serverless 是什么，之后我会尽我所能中立地谈谈它的优势和缺点。什么是 Serverless就像软件行业中的很多趋势一样，Serverless 的界限并不是特别清晰，尤其是它还涵盖了两个互相有重叠的概念：Serverless 最早用于描述那些大部分或者完全依赖于第三方（云端）应用或服务来管理服务器端逻辑和状态的应用，这些应用通常是富客户端应用（单页应用或者移动端 App），建立在云服务生态之上，包括数据库（Parse、Firebase）、账号系统（Auth0、AWS Cognito）等。这些服务最早被称为 “(Mobile) Backend as a Service”，下文将对此简称为 “BaaS”。Serverless 还可以指这种情况：应用的一部分服务端逻辑依然由开发者完成，但是和传统架构不同，它运行在一个无状态的计算容器中，由事件驱动、生命周期很短（甚至只有一次调用）、完全由第三方管理（感谢 ThoughtWorks 在他们最近的“技术观察”中对此所做的定义）。这种情况称为 Functions as a service / FaaS。AWS Lambda 是目前的热门 FaaS 实现之一，下文将对此简称为 “FaaS”。【边栏注释：“Serverless” 术语的起源】本文将主要聚焦于 FaaS，不仅仅因为它是 Serverless 中最新也最热门的领域，更重要的是它和我们传统技术架构思路的显著不同。BaaS 和 FaaS 在运维层面有类似之处（都无需管理硬件资源），并且也经常配合使用。主流的云服务商都会提供一套“Serverless 全家桶”，囊括了 BaaS 和 FaaS 产品——例如 Amazon 的 Serverless 产品介绍，Google 的 Firebase 服务也紧密集成了 Google Cloud Functions。对小公司而言这两个领域也有交叉，Auth0 最初是一个 BaaS 产品，提供用户管理的各种服务，他们后来创建了配套的 FaaS 服务 Webtask，并且将此概念进一步延伸推出了 Extend，支持其他 BaaS 和 SaaS 公司能够轻松地在现有产品中加入 FaaS 能力。一些示例界面驱动的应用（UI-driven applications）我们来设想一个传统的三层 C/S 架构，例如一个常见的电子商务应用（比如在线宠物商店），假设它服务端用 Java，客户端用 HTML/JavaScript：在这个架构下客户端通常没什么功能，系统中的大部分逻辑——身份验证、页面导航、搜索、交易——都在服务端实现。把它改造成 Serverless 架构的话会是这样：这是张大幅简化的架构图，但还是有相当多变化之处：我们移除了最初应用中的身份验证逻辑，换用一个第三方的 BaaS 服务。另一个 BaaS 示例：我们允许客户端直接访问一部分数据库内容，这部分数据完全由第三方托管（如 AWS Dynamo），这里我们会用一些安全配置来管理客户端访问相应数据的权限。前面两点已经隐含了非常重要的第三点：先前服务器端的部分逻辑已经转移到了客户端，如保持用户 Session、理解应用的 UX 结构（做页面导航）、获取数据并渲染出用户界面等等。客户端实际上已经在逐步演变为单页应用。还有一些任务需要保留在服务器上，比如繁重的计算任务或者需要访问大量数据的操作。这里以“搜索”为例，搜索功能可以从持续运行的服务端中拆分出来，以 FaaS 的方式实现，从 API 网关（后文做详细解释）接收请求返回响应。这个服务器端函数可以和客户端一样，从同一个数据库读取产品数据。我们原始的服务器端是用 Java 写的，而 AWS Lambda（假定我们用的这家 FaaS 平台）也支持 Java，那么原先的搜索代码略作修改就能实现这个搜索函数。最后我们还可以把“购买”功能改写为另一个 FaaS 函数，出于安全考虑它需要在服务器端，而非客户端实现。它同样经由 API 网关暴露给外部使用。消息驱动的应用（Message-driven applications）再举一个后端数据处理服务的例子。假设你在做一个需要快速响应 UI 的用户中心应用，同时你又想捕捉记录所有的用户行为。设想一个在线广告系统，当用户点击了广告你需要立刻跳转到广告目标，同时你还需要记录这次点击以便向广告客户收费（这个例子并非虚构，我的一位前同事最近就在做这项重构）。传统的架构会是这样：“广告服务器”同步响应用户的点击，同时发送一条消息给“点击处理应用”，异步地更新数据库（例如从客户的账户里扣款）。在 Serverless 架构下会是这样：这里两个架构的差异比我们上一个例子要小很多。我们把一个长期保持在内存中待命的任务替换为托管在第三方平台上以事件驱动的 FaaS 函数。注意这个第三方平台提供了消息代理和 FaaS 执行环境，这两个紧密相关的系统。解构 “Function as a Service”我们已经提到多次 FaaS 的概念，现在来挖掘下它究竟是什么含义。先来看看 Amazon 的 Lambda 产品简介：通过 AWS Lambda，无需配置或管理服务器(1)即可运行代码。您只需按消耗的计算时间付费 – 代码未运行时不产生费用。借助 Lambda，您几乎可以为任何类型的应用程序或后端服务(2)运行代码，而且全部无需管理。只需上传您的代码，Lambda 会处理运行(3)和扩展高可用性(4)代码所需的一切工作。您可以将您的代码设置为自动从其他 AWS 服务(5)触发，或者直接从任何 Web 或移动应用程序(6)调用。本质上 FaaS 就是无需配置或管理你自己的服务器系统或者服务器应用即可运行后端代码，其中第二项——服务器应用——是个关键因素，使其区别于现今其他一些流行的架构趋势如容器或者 PaaS（Platform as a Service）。回顾前面点击处理的例子，FaaS 替换掉了点击处理服务器（可能跑在一台物理服务器或者容器中，但绝对是一个独立的应用程序），它不需要服务器，也没有一个应用程序在持续运行。FaaS 不需要代码基于特定的库或框架，从语言或环境的层面来看 FaaS 就是一个普通的应用程序。例如 AWS Lambda 支持 JavaScript、Python 以及任意 JVM 语言（Java、Clojure、Scala 等），并且你的 FaaS 函数还可以调用任何一起部署的程序，也就是说实际上你可以用任何能编译为 Unix 程序的语言（稍后我们会讲到 Apex）。FaaS 也有一些不容忽视的局限，尤其是牵涉到状态和执行时长问题，这些我们稍后详谈。再次回顾一下点击处理的例子——代码迁移到 FaaS 唯一需要修改的是 main 方法（启动）的部分，删掉即可，也许还会有一些上层消息处理的代码（实现消息监听界面），不过这很可能只是方法签名上的小改动。所有其他代码（比如那些访问数据库的）都可以原样用在 FaaS 中。既然我们没有服务器应用要执行，部署过程也和传统的方式大相径庭——把代码上传到 FaaS 平台，平台搞定所有其他事情。具体而言我们要做的就是上传新版的代码（zip 文件或者 jar 包）然后调用一个 API 来激活更新。横向扩展是完全自动化、弹性十足、由 FaaS 平台供应商管理的。如果你需要并行处理 100 个请求，不用做任何处理系统可以自然而然地支持。FaaS 的“运算容器”会在运行时按需启动执行函数，飞快地完成并结束。回到我们的点击处理应用，假设某个好日子我们的客户点击广告的数量有平日的十倍之多，我们的点击处理应用能承载得住么？我们写的代码是否支持并行处理？支持的话，一个运行实例能够处理这么多点击量吗？如果环境允许多进程执行我们能自动支持或者手动配置支持吗？以 FaaS 实现你的代码需要一开始就以并行执行为默认前提，但除此之外就没有其他要求了，平台会完成所有的伸缩性需求。FaaS 中的函数通常都由平台指定的一些事件触发。在 AWS 上有 S3（文件）更新、时间（定时任务）、消息总线（Kinesis）消息等，你的函数需要指定监听某个事件源。在点击处理器的例子中我们有个假设是已经采用了支持 FaaS 订阅的消息代理，如果没有的话这部分也需要一些代码量。大部分的 FaaS 平台都支持 HTTP 请求触发函数执行，通常都是以某种 API 网关的形式实现（如 AWS API Gateway，Webtask）。我们在宠物商店的例子中就以此来实现搜索和购买功能。状态当牵涉到本地（机器或者运行实例）状态时 FaaS 有个不能忽视的限制。简单点说就是你需要接受这么一个预设：函数调用中创建的所有中间状态或环境状态都不会影响之后的任何一次调用。这里的状态包括了内存数据和本地磁盘存储数据。从部署的角度换句话说就是 FaaS 函数都是无状态的（Stateless）。这对于应用架构有重大的影响，无独有偶，“Twelve-Factor App” 的概念也有一模一样的要求。在此限制下的做法有多种，通常这个 FaaS 函数要么是天然无状态的——纯函数式地处理输入并且输出，要么使用数据库、跨应用缓存（如 Redis）或者网络文件系统（如 S3）来保存需要进一步处理的数据。执行时长FaaS 函数可以执行的时间通常都是受限的，目前 AWS Lambda 函数执行最长不能超过五分钟，否则会被强行终止。这意味着某些需要长时间执行的任务需要调整实现方法才能用于 FaaS 平台，例如你可能需要把一个原先长时间执行的任务拆分成多个协作的 FaaS 函数来执行。启动延迟目前你的 FaaS 函数响应请求的时间会受到大量因素的影响，可能从 10 毫秒到 2 分钟不等。这听起来很糟糕，不过我们来看看具体的情况，以 AWS Lambda 为例。如果你的函数是 JavaScript 或者 Python 的，并且代码量不是很大（千行以内），执行的消耗通常在 10 到 100 毫秒以内，大函数可能偶尔会稍高一些。如果你的函数实现在 JVM 上，会偶尔碰到 10 秒以上的 JVM 启动时间，不过这只会在两种情况下发生：你的函数调用触发比较稀少，两次调用间隔超过 10 分钟。流量突发峰值，比如通常每秒处理 10 个请求的任务在 10 秒内飙升到每秒 100 个。前一种情况可以用个 hack 来解决：每五分钟 ping 一次给函数保持热身。这些问题严重么？这要看你的应用类型和流量特征。我先前的团队有一个 Java 的异步消息处理 Lambda 应用每天处理数亿条消息，他们就完全不担心启动延迟的问题。如果你要写的是一个低延时的交易程序，目前而言肯定不会考虑 FaaS 架构，无论你是用什么语言。不论你是否认为你的应用会受此影响，都应该以生产环境级别的负载测试下实际性能情况。如果目前的情况还不能接受的话，可以几个月后再看看，因为这也是现在的 FaaS 平台供应商们主要集中精力在解决的问题。API 网关我们前面还碰到过一个 FaaS 的概念：“API 网关”。API 网关是一个配置了路由的 HTTP 服务器，每个路由对应一个 FaaS 函数，当 API 网关收到请求时它找到匹配请求的路由，调用相应的 FaaS 函数。通常 API 网关还会把请求参数转换成 FaaS 函数的调用参数。最后 API 网关把 FaaS 函数执行的结果返回给请求来源。AWS 有自己的一套 API 网关，其他平台也大同小异。除了纯粹的路由请求，API 网关还会负责身份认证、输入参数校验、响应代码映射等，你可能已经敏锐地意识到这是否合理，如果你有这个考虑的话，我们待会儿就谈。另一个应用 API 网关加 FaaS 的场景是创建无服务器的 http 前端微服务，同时又具备了 FaaS 函数的伸缩性、管理便利等优势。目前 API 网关的相关工具链还不成熟，尽管这是可行的但也要够大胆才能用。工具链前面关于工具链还不成熟的说法是指大体上 FaaS 无服务器架构平台的情况，也有例外，Auth0 Webtask 就很重视改善开发者体验，Tomasz Janczuk 在最近一届的 Serverless Conf 上做了精彩的展示。无服务器应用的监控和调试还是有点棘手，我们会在本文未来的更新中进一步探讨这方面。开源无服务器 FaaS 的一个主要好处就是只需要近乎透明的运行时启动调度，所以这个领域不像 Docker 或者容器领域那么依赖开源实现。未来肯定会有一些流行的 FaaS / API 网关平台实现可以跑在私有服务器或者开发者工作站上，IBM 的 OpenWhisk 就是一个这样的实现，不知道它是否能成为流行选择，接下来的时间里肯定会有更多竞争者出现。除了运行时的平台实现，还是有不少开源工具用以辅助开发和部署的，例如 Serverless Framework 在 API 网关 + Lambda 的易用性上就比它的原创者 AWS 要好很多，这是一个 JS 为主的项目，如果你在写一个 JS 网关应用一定要去了解下。再如 Apex——“轻松创建、部署及管理 AWS Lambda 函数”。Apex 有意思的一点是它允许你用 AWS 平台并不直接支持的语言来实现 Lambda 函数，比如 Go。什么不是 Serverless在前文中我定义了 “Serverless” 是两个概念的组合：“Backend as a Service” 和 “Function as a Service”，并且对后者的特性做了详细解释。在我们开始探讨它的好处和弊端之前，我想再花点儿时间在它的定义上，或者说：区分开那些容易和 Serverless 混淆的概念。我看到一些人（包括我自己最近）对此都有困惑，我想值得对此做个澄清。对比 PaaS既然 Serverless FaaS 这么像 12-Factor 应用，那不就是另一种形式的 Platform as a Service 么？就像 Heroku？对此借用 Adrian Cockcroft 一句非常简明的话：如果你的 PaaS 能在 20ms 内启动一个只运行半秒钟的实例，它就叫 Serverless。— Adrian Cockcroft换句话说，大部分 PaaS 应用不会为了每个请求都启动并结束整个应用，而 FaaS 就是这么做的。好吧，然而假设我是个娴熟的 12-Factor 应用开发者，写代码的方式还是没有区别对么？没错，但是你如何运维是有很大不同的。鉴于我们都是 DevOps 工程师我们会在开发阶段就充分考虑运维，对吧？FaaS 和 PaaS 在运维方面的关键区别是伸缩性（Scaling）。对于大多数 PaaS 平台而言你需要考虑如何伸缩，例如在 Heroku 上你要用到多少 Dyno 实例？对于 FaaS 应用这一步骤是完全透明的。即便你将 PaaS 配置为自动伸缩，也无法精细到单个请求级别，除非你有一个非常明确稳定的流量曲线可以针对性地配置。所以 FaaS 应用在成本方面要高效得多。既然如此，何必还用 PaaS？有很多原因，最主要的因素应该是工具链成熟度。另外像Cloud Foundry 能够给混合云和私有云的开发提供一致体验，在写就本文的时候 FaaS 还没有这么成熟的平台。对比容器使用 Serverless FaaS 的好处之一是避免在操作系统层面管理应用程序进程。有一些 PaaS 平台如 Heroku 也提供了这样的特性；另一种对进程的抽象是容器，这类技术的代表是 Docker。容器托管系统（Mesos、Kubernetes 等）把应用从系统级开发中抽象出来，这种做法日渐流行，甚至在此之上云服务商的容器平台（如 Amazon ECS、EKS、Google Cloud Engine）也像 Serverless FaaS 一样允许团队从管理主机中完全解放出来。在这股容器大潮中，FaaS 是否还有优势？概念上来说前面对 PaaS 的论断仍旧适用于容器。Serverless FaaS 的伸缩性是完全自动化、透明、良好组织的，并且自动进行资源监控和分配；而容器平台仍旧需要你对容量和集群进行管理。另外我还得说容器技术也处在不够成熟和稳定的阶段，尽管它越来越接近了。当然这不是说 Serverless 就成熟了，但你终究需要在两个都属前沿的技术方向中做出选择。还有个值得一提的是不少容器平台支持了自动伸缩的容器集群，Kubernetes 有内建的 Horizontal Pod Autoscaling 功能，AWS Fargate 则承诺会有“Serverless 容器”。总的来说 Serverless FaaS 和托管容器在管理和伸缩性方面的差别已经不大，在它们之间的取舍更多看风格取向和应用的类型。例如事件驱动的应用组件更适合用 FaaS 实现，而同步请求驱动的应用组件更适合用容器实现。我预计很快就会有不少团队和应用同时采用这两种架构模式，期待看它们会擦出怎样的火花。对比 NoOpsServerless 并非“零运维”——尽管它可能是“无系统管理员”，也要看你在这个 Serverless 的兔子洞里走多深。“运维”的意义远不止系统管理，它还包括并不限于监控、部署、安全、网络、支持、生产环境调试以及系统伸缩。这些事务同样存在于 Serverless 应用中，你仍旧需要相应的方法处理它们。某些情况下 Serverless 的运维会更难一些，毕竟它还是个崭新的技术。系统管理的工作仍然要做，你只是把它外包给了 Serverless 环境。这既不能说坏也不能说好——我们外包了大量的内容，是好是坏要看具体情况。不论怎样，某些时候这层抽象也会发生问题，就会需要一个来自某个地方的人类系统管理员来支持你的工作了。Charity Majors 在第一届 Serverless 大会上就这个主题做了个非常不错的演讲，也可以看看她相关的两篇文章：WTF is operations? 和 Operational Best Practices）。对比存储过程即服务还有一种说法把 Serverless FaaS 看做“存储过程即服务（Stored Procedures as a Service）”，我想原因是很多 FaaS 函数示范都用数据库访问作为例子。如果这就是它的主要用途，我想这个名字也不坏，但终究这只是 FaaS 的一种用例而已，这样去考虑 FaaS 局限了它的能力。我好奇 Serverless 会不会最终变成类似存储过程那样的东西，开始是个好主意，然后迅速演变成大规模技术债务。— Camille Fournier但我们仍然值得考虑 FaaS 是否会导致跟存储过程类似的问题，包括 Camille 提到的技术债。有很多存储过程给我们的教训可以放在 FaaS 场景下重新审视，存储过程的问题在于：通常依赖于服务商指定的语言，或者至少是指定的语言框架/扩展因为必须在数据库环境中执行所以很难测试难以进行版本控制，或者作为应用包进行管理尽管不是所有存储过程的实现都有这些问题，但它们都是常会碰到的。我们看看是否适用于 FaaS：第一条就目前看来显然不是 FaaS 的烦恼，直接排除。第二条，因为 FaaS 函数都是纯粹的代码，所以应该和其他任何代码一样容易测试。整合测试是另一个问题，我们稍后展开细说。第三条，既然 FaaS 函数都是纯粹的代码，版本控制自然不成问题；最近大家开始关心的应用打包，相关工具链也在日趋成熟，比如 Amazon 的 Serverless Application Model（SAM）和前面提到的其他 Serverless 框架都提供了类似的功能。2018 年初 Amazon 还开放了 Serverless Application Repository（SAR）服务，方便组织分发应用程序和组件，也是基于 AWS Serverless 服务构建的。关于 SAR 可以看看我的另一篇文章：Examining the AWS Serverless Application Repository。本文翻译的实时更新：https://amio.github.io/server… ...

导读：蚂蚁金融科技全面开放战略的公布，意味着蚂蚁金融科技正式进入全新的3.0时代。蚂蚁金融科技15年来的演进，在其发展史上不断留下了技术里程碑，同时，也缔造出一个又一个的业界“奇迹”。本文将深度揭秘蚂蚁金服的技术战略及布局。11月7日，第五届世界互联网大会在浙江乌镇开幕。当天下午，代表着行业最高水准的“世界互联网领先科技成果”发布，蚂蚁金服自主可控的金融级商用区块链平台等十余项先进技术获得此项殊荣。11月8日，世界互联网大会上由中国人民银行科技司主办的“金融科技与信用社会建设”主题论坛，蚂蚁金服宣布基于网络黑灰产防控治理的“天朗计划”全面升级，将蚂蚁风险大脑对传销、非法集资、金融诈骗等金融风险防控融入其中，同时，蚂蚁风险大脑也将会全面赋能合作伙伴，为其业务发展保驾护航，为投资者和消费者提供一个天朗气清的网络空间。而在同期举行的 “互联网之光”博览会上，蚂蚁金服不仅展示了15年来的技术演进之路，而且重点展示了区块链技术和蚂蚁风险大脑等相关产品及解决方案。蚂蚁金服15年技术演进之路经过15年的发展，蚂蚁金服已经成长为中国最重要的金融科技平台。除了支付、信贷、保险、理财、征信等众多业务，在金融技术的研发、投入及开放上，也已深耕不辍了多年。最初的蚂蚁金融云逐渐演变，在积累了众多云计算能力和技术组件的基础上，早已超越了传统金融云的概念，而囊括了云计算、大数据、AI、IoT、区块链等一整套技术体系。我们势必需要重新认识蚂蚁金服，将它的立体与多维展现出来，让金融科技的价值被真正重视！全面开放：数字金融技术整体解决方案当下，以支付宝为代表的蚂蚁金服的产品从一开始就要接受来自于网上的各种检验、钓鱼、攻击、窃取。面对一个开放的系统，没有办法关起门来，需要去研发各种技术，这对技术能力是非常大的考验。3年前，蚂蚁金服启动了“互联网推进器”计划，该计划表明，蚂蚁金服将在5年内助力超过1000家金融机构向新金融转型升级，在平台、数据和技术等方面实施能力全面对外开放。从2015年蚂蚁金融云发布到2016年GeaBase在支付场景上线，从2017年OceanBase 三地五中心集群部署到2018年“蚂蚁风险大脑”上线，蚂蚁金融科技开放一直在往纵深方向发展。到了今天，蚂蚁金服已经逐渐形成了“点线面”相结合的技术解决方案体系，包含了海量金融交易技术、金融智能技术、新一代金融交互技术、金融安全、区块链、综合技术等。在蚂蚁金融科技的大版图上，强调“技术开放”，而不是“技术输出”，或许这不仅仅是喊的口号不同，更是因为两者所导致的结果是真正差异化的：“开放”更具开源精神，它助推着金融科技的融合与创新，让新金融变成了“更好的金融”。在此前云栖ATEC主论坛上，蚂蚁金服副CTO胡喜就宣布，蚂蚁金服的金融科技正式全面开放，为行业提供完整的数字金融解决方案。包括容灾系统在内的多项核心技术和解决方案，如金融安全、蚂蚁风险大脑、区块链等都将对合作伙伴开放。五大关键技术详解：蚂蚁金服的“完整答卷”除了让金融机构摆脱传统IT架构的束缚外，蚂蚁金服也成就了自己世界级的技术能力。在多条重要技术主线上，无数的金融场景都能被一一对应，蚂蚁金服也由此不断进入“新领地”，在技术前沿展开探索。因此，主要梳理的技术主线有如下5条：海量金融交易技术交易技术是支付宝创造“人间奇迹”的起点。2017年的“双11”，支付宝凭借多项新纪录成为当天的主角：11秒钟破亿，28秒钟破10亿，3分01秒破100亿，6分05秒钟破200亿。根据支付宝官方数据，第5分22秒，双11的支付峰值达到25.6万笔/秒，同时蚂蚁金服自主研发的数据库处理峰值达到4200万次/秒，双双创下新纪录。而海量金融交易技术的背后，其实是分布式架构所带来的创新优势，敏捷迭代、容灾安全、弹性伸缩构成了分布式架构转型升级的三大驱动力。其中，OceanBase分布式数据库、SOFA ware分布式中间件、CAF?容器云平台三大技术构成了蚂蚁金服金融级的分布式架构。金融交易技术最关键的目标是“数据不丢失，业务不停机”。目前，TRaaS 技术风险防控平台（Technological Risk-defence as a Service）已一跃成为技术风险领域最为成熟的产品，在高可用架构（异地多活、全链路压测）、资损防控（交易实时核对、自动决策）、智能运维（AIOps故障自愈）等功能上做到了极致。而金融级分布式架构SOFAStack（Scalable Open Financial Architecture Stack）专注为金融用户提供安全、敏捷的基础架构能力，解决传统集中式架构转型的困难，将传统集中式架构转变为分布式系统架构。以人保健康为例，借助SOFAStack，其互联网保险云核心业务处理能力提升了上千倍，并支持弹性扩容，出单时间达到每秒1000单，外部渠道产品接入效率提升6倍，新产品上线时间缩短80%以上。经过四代架构演进，八年“双十一”的考验，现在SOFA已经从中间件这一层开始，逐渐对外进行开放和开源。金融安全技术安全是蚂蚁金服BASIC五大技术开放战略之一（Blockchain区块链、Artificial intelligence金融智能、Security安全、IoT物联网和Computing计算），事实上十多年以来，在业务场景的迫切需求的驱动下，蚂蚁金服的风控技术也经历了多次升级迭代，才发展成一套以AI智能算法、生物核身为基础的多层级立体闭环风控系统——蚂蚁风险大脑（Risk Brian）。人脸识别、指纹识别、虹膜识别、活体检测等技术加上智能设备终端、传感器识别等共同组成了蚂蚁风险大脑数字核身解决方案。面对日益复杂的新金融场景监管，地方金融监管机构正在承担越来越多的责任，同时监管痛点也逐步显现出来。而当下，蚂蚁风险大脑集风险感知、风险识别、智能进化、自动策略调整4大功能为一身，已形成了“金融消费者教育预警”、“7+4行业监测”、“涉众金融风险防控”、“金融风险联动处置”、“投资人信访登记”等完整的防控链路。目前，蚂蚁风险大脑已与北京、天津、广州等多个地方金融监管部门建立合作，共同保护消费者合法权益。全面、多样化的数字身份认证体系也是安全技术一大亮点。运用ZOLOZ（生物认证），对人脸识别的准确率高达99.99%， 覆盖2亿+互联网金融用户，确保20亿+次交易安全；运用IFAA（本地生物认证框架），实现覆盖终端设备12亿台，支持380款Android手机，TEE级别、高安全性，设备接入轻量快速低成本，周期从4个月降至1周内。除此之外，AlphaRisk （智能风控引擎）在风险感知、风险识别、智能进化、自动驾驶上也有着诸多应用，向着自动化、自学习、高准确率、高计算性能、自适应的方向进化。金融智能决策技术蚂蚁金服的金融智能决策技术与旗下网商银行独创的“310”模式息息相关。“310”即“3分钟申请、1秒钟到账、0人工干预”的服务标准，至今服务了1000万中小微企业的贷款。2018年6月，蚂蚁金服董事长兼CEO井贤栋透露，网商银行将启动“凡星计划”：未来三年，网商银行将与1000家各类金融机构合作，服务3000万家小微企业和个体经营户。在过去，发放一笔小微企业贷款的平均人力成本在2000元，而网商银行通过技术支撑的“310”模式，让每笔贷款的平均运营成本降低至2.3元，其中2元是计算和存储硬件等技术投入费用。可以说，技术降低了金融服务的成本，实现了商业上的可持续发展。具体运行方式上，金融智能决策技术涉4大步骤，分别是数据的采集与计算、AB试验体系和BI深度分析、统一指标与策略管理、模拟训练和预测平台等，至今已积累10万余项指标体系、3000多种风控策略，仅行业化风控模型就建立100多个。与此同时，在2017双11支付宝 25.6万笔支付每秒也需要其迅速做出大量高效的决策，最难得的是其资损率一直小于百万分之0.5的水平，交易资金的安全性得到了高度保障。新一代金融交互技术在新一代金融交互技术上，蚂蚁金服有着坚实的中台能力，新一代mPaaS平台，让客户端运行更为高效与稳定；小程序的组件和API则将支付宝特色能力与系统原生能力做了紧密地结合，实现了一次开发多端投放，并可以无缝迁移支付宝小程序到自己的App中；Ant Design让用户研究、交互模式、设计语言等形成了良好的循环圈，将终端用户的体验提升到了极致。具体来看，开发者能够利用蚂蚁金服移动开发平台mPaaS做好移动App的开发、管理、发布，并做好App全生命周期的管理，其中包括了开发期的研发测试、打包构建、发布管理，还有发布之后的用户行为分析、闪退分析等。2018年9月27日，支付宝小程序一站式云服务正式开放公测，为小程序开发者提供了完整的云端支持，让开发者无需自己搭建服务器，即可实现支付宝小程序的快速上线和迭代，大大节省开发成本、加快开发速度。如果说PaaS平台是对企业后台服务的生命周期的管理，包括研发、发布、监控这一套流程，那么mPaaS就是对移动应用App一整套全生命周期的管理服务，能有效降低技术门槛、减少研发成本、提升开发效率，协助金融机构快速搭建稳定高质量的移动应用。区块链技术蚂蚁金服自研可控的金融级区块链平台已经在多个社会和商业应用场景实现多机构、多国全球部署，提供面向政府、企业和普通百姓的各类数字服务。同时，蚂蚁区块链解决了很多区块链产业面临的技术挑战，在性能、安全性以及跨链交互等多个技术难点的研究与攻关进展方面均处于世界前列，已经具备金融级平台所需要的高性能、高可靠和高安全的技术特点。蚂蚁金服区块链总体定位是做一个信任连接的基础设施，与信美人寿相互保险社的合作是其区块链技术的试水，而在天猫跨境电商溯源、茅台溯源这两个可信的溯源服务上，区块链技术日臻成熟。2017年11月，蚂蚁金服正式上线关于天猫境外商品的跨境溯源的服务。在这个场景中，支付宝用户从天猫针对来自澳洲、新西兰26个商品、奶制品提供了关于每一瓶奶制品的身份证的溯源码服务。目前，蚂蚁金服在区块链领域申请了160多件专利，国家专利局公开授权的有65件，在知识产权产业媒体IPRdaily最新发布的《2018年全球区块链专利企业排行榜》排名第一。目前，蚂蚁区块链的专利方向主要集中于底层技术，并将这些技术首先应用在公益慈善、食品安全、跨境汇款、房屋租赁等更具社会价值的民生领域。2018年6月25日，蚂蚁金服宣布全球首个基于区块链技术的电子钱包跨境汇款服务在香港上线。在香港工作22年的菲律宾人Grace幸运地第一个尝鲜，整个汇款过程耗时仅3秒，而在以前需要短则10分钟、长则几天。在区块链技术的支持下，支付宝香港钱包可以为在港菲律宾劳工提供7×24小时不间断的跨境汇款服务，实现3-6秒汇款到账服务体验。同时，大大降低了多方对账成本。据了解，蚂蚁金服依次攻克了符合各国监管要求的隐私保护设计、区块链节点跨境多地多机房部署、低延时智能合约交易确认等技术难题。“BASIC”综合技术实力跻身一线可以说，除了上文介绍的数字金融五大关键技术，蚂蚁金服的综合技术实力在经历了“原始积累”之后，已经跻身一线技术厂商。“BASIC”是现在的蚂蚁金服最常提到的核心技术能力，即Blockchain（区块链）、AI（金融智能）、Security（安全）、IoT（物联网）、Computing（计算），未来所有的金融科技都围绕着这些技术来展开并实施开放开源。此外，蚂蚁金服完全自主研发的OceanBase 是高性能、高可扩展、数据强一致的金融级分布式关系型数据库，具备丰富的关系数据库功能，支持完整的 ACID 特性，首创的“三地五中心”城市级故障无损容灾方案正成为越来越多金融机构核心系统高可用的选择。OceanBase还高度兼容 MySQL，让用户能够以最小的迁移成本使用高性能、可扩展、持续可用的分布式数据库服务，同时对用户数据提供金融级可靠性的保障。而在最近几年被业界广泛关注的图数据库领域，蚂蚁金服经过3年多的探索，也自主研发出多项指标领先业界的金融级分布式图数据库GeaBase。GeaBase具备高性能、高可用、高扩展性及可移植性强等多重特性，支撑着蚂蚁金服旗下支付的风险控制、反洗钱、反欺诈、反刷单、反套现、金融案件审理、知识图谱、会员拉新、好友推荐、理财资讯推荐等众多的业务和应用。目前，GeaBase不仅广泛应用于蚂蚁金服的生态体系内，而且已经技术对外开放，正与多家银行等企业开展合作。从开放到开源，蚂蚁金服的“暖科技”在探索新的空间蚂蚁金服是最早提出技术开放的企业之一。在2015-2018三年间，从“互联网推进器计划”到“成熟一个开放一个”，蚂蚁金服公布的产品数量从5个增长到了80个，解决方案从3个发展到了50个，未来将以“蚂蚁金融科技”为技术输出品牌。现在，蚂蚁金融科技正式进入了3.0时代：支付宝对内延续“BASIC”战略，对外开放的技术越来越完整、越来越核心，是成建制、有体系的全面开放，并实现了技术商业化。业务上，实现了余额宝开放、借呗开放、花呗开放、小微企业贷款开放、蚂蚁财富平台、蚂蚁保险平台、蚂蚁森林等的开放……能力上，实现了小程序、生活号、实名核身能力、信用能力、风控能力、会员运营能力的开放……技术上，实现了区块链、金融智能、金融安全、金融分布式框架、移动开发、金融分布式数据库等100%开放……此外，在开源这条路上，蚂蚁金服一直保持着自己的节奏。2016年5月，企业级产品的设计体系Ant Design 1.0正式发布；2016年9月，企业级Node.js框架Egg宣布开源；2017年11月，专业的数据可视化解决方案AntV 3.0发布；2018年1月，首届蚂蚁金服体验科技大会在杭州蚂蚁Z空间成功举办；2018年4月，Ant Design成为国内公司star数最多的开源项目；2018年4月，蚂蚁金服启动分布式中间件开源计划，用于快速构建金融级云原生架构。……蚂蚁金服副CTO胡喜此前表示，蚂蚁金服内部建立了一个开源共建的体制，代码完全开放，其他业务的垂直BU自己也可以实现定制化需求。蚂蚁金服CTO程立曾说过，蚂蚁金服不是为了做技术本身而做技术，而希望用技术来解决社会当下和未来的问题。如果说用金字塔结构来描绘数字金融的社会价值，在塔顶的就是数字金融能在全球范围内带来更多平等的机会。同样，面向未来的技术探索与挑战，对“数据不丢失，业务不停机”保持极致追求，让整个数字世界变得安全可信，给全世界每一个人可信数字身份，在IoT的海量数据之上实时安全计算，蚂蚁金服责无旁贷。本文作者：华蒙阅读原文本文为云栖社区原创内容，未经允许不得转载。

前端架构设计的方法论系统的架构设计用来定义应用程序的基本特征和行为。良好的架构是系统构建成功的关键。架构驱动的软件开发是构建复杂系统的最有效方法，架构驱动的方法优于需求驱动，文档驱动和方法论（抽象推理的能力）驱动。虽然方法论（抽象推理的能力）可以帮助我们取得项目的成功，但是它并不是决定性的因素。1、初期如何设计架构所有架构的核心：关注点分离（分离角色和职能，分离之后的结果是对具体功能的高度抽象）。架构设计的过程其实也是在梳理需求的过程中不断标识、封装和操纵关注点。根据迪米特法则和开闭原则，分离之后的职责对象应该高度独立和封闭（优点是不需要关系它们内部的具体实现，只关心输入和输出即可）。更容易构造有效的(职责)角色和强力的模型，变的更好开发，测试，管理和维护。2、构建系统的步骤1、抽象职责（功能模块）之间的相互作用2、抽象职责和数据流之间的关系3、注意的四个点1、扩展性2、弹性（伸缩性）3、灵活性4、稳定性4、评判标准1、灵活性响应外部环境变化的能力，架构中是否便捷做一些改变，功能模块间的紧耦合是降低灵活性的关键。2、易于部署3、易于开发4、可测试性职责和数据流的划分，便于分块测试。5、伸缩性系统是否利于扩展，紧耦合与职责划分不清晰是降低伸缩性的关键。6、性能任何架构的本质是在处理数据流，所以数据流的流转效率决定了该架构的性能。最后本文提出的这些观点实际上也是属于架构设计的方法论。在掌握并熟练运用了这些方法论之后并实践到项目中，慢慢的才会搭建出更好的架构。ps：由于本人比较懒，所以没有针对一些名词做具体讲解和示例。

微内核架构在大型前端系统中的应用只讨论架构，不讨论框架1、名词解释由一群尽可能将数量最小化的软件程序组成，他们负责提供、实现一个操作系统所需要的各种机制和功能。这些最基础的机制，包括了底层地址空间管理，线程管理，与进程间通讯。2、设计理念将系统的实现，与系统的基本操作规则区分开来。它实现的方式是将核心功能模块化，划分成几个独立的进程，各自运行，这些进程被称为服务。所有的服务进程，都运行在不同的地址空间。让服务各自独立，可以减少系统之间的耦合度，易于实现与除错，也可以增进可移植性。它可以避免单一组件失效，而造成整个系统崩溃，内核只需要重启这个组件，不至于影响其他服务器的功能，使系统稳定度增加。同时业务功能可以视需要，抽换或新增某些服务进程，使功能更有弹性。就代码数量来看，一般来说，因为功能简化，核心系统使用的代码比集成式系统更少。更少的代码意味更少的潜藏程序bug。3、具体应用微内核架构在使用时主要考虑两个方面『核心系统』和『插件模块』。应用逻辑被划分为独立的『核心系统』和『插件模块』，这样就提供了良好的可扩展性与灵活性，应用的新特性和基础业务逻辑也会被隔离。一、核心系统核心系统通常是一个可以独立运行的最小化模块，操作系统（Windows NT、Mac OS X）就是这么实现的。从商业应用的角度来看，核心系统为那些特定的场景、规则、复杂的条件判断提供了通用的业务逻辑，而插件模块则提供了更为具体的业务逻辑。可以增加或扩展核心系统以达到产生附加的业务逻辑的能力。二、插件模块插件模块通常是一个专业处理额外特性的独立组件。通常，插件模块之间是没有依赖的，当然你也可以创建一个依赖其他插件模块的插件，但不管怎么样，让插件模块之间可以彼此通讯又不产生依赖是一个很重要的问题。三、获取插件模块并判断可用性核心系统需要知道每个插件的可用性并且知道如何获取它们，一个通常的实现方式是使用一组注册表。注册表包括了每个插件的基本信息，包括名称、数据规范、远程访问协议（取决于插件模块如何和核心系统进行连接）以及其他自定义数据。比如百度网盘中用于上传文件的上传插件提供了插件名称、数据规范（输入、输出数据）、数据格式（json、xml），如果这个插件是通过异步进行加载的，那么还会有一个具体远程HTTP访问协议地址。四、连接到核心系统插件模块可以通过多种方式连接到核心系统，包括OSGI（open service gateway initiative）、消息机制、web服务以及点对点的绑定（对象实例化，既依赖注入）。使用何种方式主要取决于具体的应用场景和特殊需求（单机部署、分布式部署），微内核架构默认没有要求具体的实现方式，但是必须保证插件模块之间不能产生任何依赖。五、通信规范插件模块和核心系统之间的通信规范分为标准规范和自定义规范，自定义规范通常是指某个插件模块是由第三方服务开发的。这种情况下，就需要在自定义规范和标准规范之间提供一个Adapter，这样核心系统就不需要关心每个插件模块的具体实现。在设计标准规范之前制定一个版本策略很重要。六、事件模式核心系统提供了多种事件模式，主要包括常用的点对点模式、发布订阅模式。同时，事件的类型分为全局（系统级）事件、系统内部事件以及插件模块内部事件。由于点对点模式中发送者和接收者之间没有依赖关系并且一条消息只对应一个接收者，所以可以用作广播全局（系统级）事件，比如调起某个插件模块。而发布订阅模式中订阅者和发布者之间存在时间上的依赖性，可以用于系统内部事件和插件模块的内部事件。此外，核心模块也可以通过发布订阅模式向外发布某些属于业务基本操作规则的事件。七、接口设计当插件模块注册到核心系统之后，通过系统级事件可以调起具体的某插件模块。此时就需要核心模块提供属于基本操作规则的接口供插件模块使用，同样的，插件模块也必须按照通信规范提供运行入口(类似于java的Main方法)和数据规范(参数格式，返回的数据格式)，以此保障插件模块可以在核心系统上正确运行。插件模块是独立于核心系统之外的，但是根据具体的需求（提供单纯的数据服务、处理系统数据和信息）可能会需要操作核心模块的系统服务做一些定制化功能，此时核心系统需要提供一个上下文对象（Context），且插件模块与外部进行交互只能通过此上下文对象。上下文对象提供了基础操作（调起其他插件模块、调起系统服务、获取系统信息）的API和事件。4、在前端系统中使用把前端系统当成一个操作系统，业务基本操作的业务逻辑抽象成一个可以独立运作的系统内核，而不属于业务基本操作的业务逻辑都当成一个应用程序，完成安装、卸载、禁用、调用以及开机启动等功能。在功能越来越多，依赖越来越负责的大型前端系统中，如果在项目初期没有很好地考虑后期兼容的灵活性、扩展性以及弹性，很容易出现项目难以维护或者谁都不想碰的尴尬场面，所以初期的设计很重要。目前的大型前端单页面系统使用的都是根据业务划分独立组件，进行解耦和复用，最后通过组件进行堆叠、编译、上线。这样虽然完成依赖良好的组件化设计考虑到了系统的扩展性和灵活性以及弹性，但是整个系统还是紧紧绑在一起的，并没有根据基础业务和附加业务进行很好的拆分。当然很多优秀的前端工程师也考虑到了这一方面，提出来微前端的概念。不过微前端还是一个比较新的技术概念，没有经过很多大型前端系统的实践。而微内核架构已经在操作系统和很多的产品的后端服务及前端APP中经过了很多的实践。一、定义核心模块和系统服务上面提到核心模块是一个可以独立运行起来，包含系统基本操作规则的最小化模块。没有任何插件模块依然可以正常运行并处理基本的业务逻辑，所以在大型前端系统中将基础页面以及基础功能单独包装起来，组成一个最小化的模块，称之为core system。而这个core system可以通过包方式在多个系统间进行复用(NPM、bower、bundle、js chunk)。同时，将那些和业务相关的操作按照类型和场景封装为多个系统服务，并挂载（依赖注入）到核心系统中，称之为system service。需要注意的是core system可操作system service，而system service不可操作core system。此外，core system根据具体的模块规范（AMD、CMD、CommonJS、ESM、SystemJS、UMD）向外部暴露了可交互的API和事件，称之为标准接口。后续在编写插件模块时要严格按照标准接口进行开发。二、定义插件模块插件模块是一个独立于核心系统的专业处理不属于系统基本操作的业务的模块（组件），比如网盘中的上传、下载、分享等功能。每个插件模块必须遵照定义好的标准接口和通信规范进行开发，而且每个插件模块都是相互独立的，所以没有对每个插件的实现细节做过多要求，如A插件模块使用React开发，B插件模块使用Vue开发，C模块使用jQuery开发。每个插件模块都应该提供一个包含本插件模块签名信息（Mainfest）的JSON文件，签名信息包括了这个插件的名称、数据规范、依赖、远程访问地址（异步加载的js下载地址）和其他自定义字段。在前端加载核心系统时将该Mainfest文件注册进去，完成核心系统和插件模块的连接。每个插件模块都应该提供一个统一名称的运行入口，比如start方法。也可以按照标准接口提供插件的生命周期事件，方便更细粒度的控制。三、注册和调起每个插件都提供了各自的Mainfest签名文件和可执行文件（JS文件、CSS文件）。所以当服务器接收到浏览器请求时可以将所要求的插件Manifest进行merge，合并成一个大的JSON结构，然后返回给浏览器。浏览器接收后，执行核心系统并注册Manfiest信息，然后启动。在注册过程中可以按照需求完成开机启动（默认执行）、预加载以及后台运行等不同类型的操作。在业务逻辑和插件内部逻辑中可以能存在调起其他插件模块的需求，由于插件模块之间不产生依赖并且独立于核心系统，所以无法直接进行调起。不过由于注册表和点对点事件模式的存在，可以通过核心系统向外暴露的API传入插件名称和组、插件模块ID等信息进行调起。在调起之前先判断该插件在是否已注册，是否已加载（同步加载、异步加载），是否为单例和互斥，参数信息和数据格式，保证它可以正确的调起。在插件运行过程中出现异常时，通过系统级事件通知核心模块。核心模块根据签名信息中的标识选择重启或关闭该插件模块。四、多入口管理在复杂的前端系统中同一个功能可能会存在过个入口的情况，比如上传、下载、分享等功能都是通过不同位置的按钮点击进行调起。通常，将具体功能（插件模块）和插件模块入口的UI展示进行隔离。首先，在基础页面结构中按照需求进行分块，分成不同的功能块，如菜单栏、右键菜单、列表项、右侧区域、左侧区域，并为这些区域定义唯一的名称和ID。在需要进行入口展示的插件模块的Manifest中，标识入口的区域和展示方式（按钮、图片、引导块、菜单项、下拉菜单）。核心系统在注册表注册完毕后，解析那些需要展示入口的的字段并交给专门渲染插件模块入口的系统服务，这样就通过配置完成了多入口的管理，在后续需求变动和修改时，只需要更改Manifest文件即可，更加完善了系统的扩展性、灵活性、弹性。5、技术选型架构是独立于框架和类库的存在。微内核架构的核心就是使业务的基本操作和专业处理额外特性的操作相隔离，提高系统的扩展性、灵活性和弹性。所以在技术选型时我们需要考虑三个方面：核心系统、系统服务、插件模块。核心系统通常包含一个项目所需要的基本功能，包括基本的展示页面、交互操作、业务处理，代码量通常很少；系统服务提供业务处理的通用功能，比如列表操作、弹框、提示、异步化接口处理等，通常将系统中通用的需求抽象到这一层中；所以，这两个方面可以使用目前常见的react或vue通过webpack工具进行规范化开发，但如何向外部暴露核心系统的API和事件给插件模块调用是一个十分重要的问题。插件模块更倾向于一个专业处理额外特性的lib库，所以推荐使用rollup或者webpack的lib模式进行开发和打包，产出一个『干净』的bundle（也可以发布到NPM中，实现独立发布和维护）。需要注意的是，如果这个bundle按照定义好的标准规范进行开发，那么它可以在任意一个微内核架构下运行，达到跨系统的能力。就像按照X86规范编写的程序可以在任意一个X86架构的系统上运行一样。调起插件模块时如何异步加载插件模块bundle？一、插件模块开发阶段方案一：source code插件模块的代码放置在一个根文件夹中，通过源代码进行开发和编译。每次更改后通过rollup或webpack产出一个bundle与Manifest文件，然后将它们上线更新即可。这种模式下，插件模块的代码更新后，对应的Manifest文件也会更新，所以核心系统加载到插件模块也会被更新，不需要基础业务逻辑执行任何操作。优点：不需要更新并上线基础业务代码。缺点：没有版本号的管理功能以及不方便测试。方案二：npm install插件模块发布到github、gitlab等其他托管平台中，通过npm进行安装到基础业务逻辑中。插件模块每次更改后需要重新发布到托管平台，并在需要在业务逻辑中更新版本号重新执行npm install xxx，然后重新编译业务代码进行上线。插件模块更新后，不需要像方案一那样上线插件模块。而是更新业务逻辑的依赖，安装最新版本的插件模块。优点：可以通过版本号加载不同的阶段的插件模块以及方便测试。缺点：更改后需要重新安装插件模块，并对依赖此插件模块的业务逻辑重新进行编译和上线。回归成本大，除了回归插件模块还要回归其他基础业务逻辑（当然也可以像方案一那样做，但是这样就抛弃了npm的最大优点 -> 版本号管理）。二、获取插件模块的Manifest签名信息方案一：服务器渲染直出到HTML中服务器收到浏览器的页面请求时，将该页面需要的插件模块的Manifest签名文件进行Merge操作，然后统一输出到HTML中并返回给浏览器。方案二：通过异步化获取通过script标签的async和defer功能或AJAX，异步从服务器获取Merge之后的Manifest签名信息集合。三、远程访问协议核心系统调起插件模块时，可以通过插件声明的远程访问协议的HTTP地址，进行异步加载。方案一：Manifest签名文件在Manifest签名信息中放置插件模块的远程访问协议，比如上传插件模块的签名示例：{ // 插件名称 “name”: “upload”, // 组 “group”: “com.xxx.xxx”, // 预加载插件模块资源 “preload”: true, // 数据规范，要求输入的参数 “arguments”: { // 核心系统提供的上下文对象 “ctx”: { “type”: “Object”, “required”: true }, // 需要上传的文件信息 “file”: { “type”: “Object”, “required”: false } }, // 远程访问协议 “entrance”: “http://www.a.com/static/plugin-bundles/upload-0.0.1.min.js"}方案二：异步化接口 + import()该方案是系统插件模块的远程访问协议不放置在插件模块的Manifest中，而是额外通过异步化接口请求得到远程访问协议。然后通过webpack提供的require.ensure()或esm的import()加载插件资源。// ctx为核心系统上下文对象ctx.loadPlugInAdapter = (pluginName, groud) => { // 通过接口请求上传插件模块的远程访问协议 fetchEntrance(pluginName, group).then(url => { // 核心系统执行插件模块 ctx.invoke(pluginName, url); });}// 调起插件模块ctx.loadPlugInAdapter(‘upload’, ‘com.xxx.xxx’);最后架构和框架是独立的，本文仅仅是提出一种架构思路，而且这个架构也在百度的某款用户量很大的复杂前端产品中得以应用。基于这一套弹性架构并结合Vue/React的现代化开发理念，可以很好的完成高复杂度的前端系统。希望本文可以给你们提供了除微前端之外的构建高弹性前端系统的另外一种思路。 ...

程序员节送 1500G 架构师视频，够不够视频提取码关注微信公众号：「搜云库」后台回复关键字：“1024"加站长微信好友把网盘视频链接发给站长微信(注意是完全匹配，不能有空格)，即可获取 “视频提取码"视频目录Activiti 6.0工作流引擎深度解析与实战https://pan.baidu.com/s/1JVSe…Docker Kubernetes 微服务容器化实战https://pan.baidu.com/s/169fA…Docker Jenkins企业实战视频https://pan.baidu.com/s/1Kiuh…Docker 到Kubernetes技术系列视频教程https://pan.baidu.com/s/1iZUZ…Docker 课程https://pan.baidu.com/s/1L13E…Docker 前后端分离https://pan.baidu.com/s/14byo…Docker 实现PaaS平台视频课程https://pan.baidu.com/s/1kRqW…Docker 视频https://pan.baidu.com/s/1m7i5…Docker 系列视频教程https://pan.baidu.com/s/1esAj…Docker 系统学习 践行DevOps理念https://pan.baidu.com/s/1_Vjb…Docker 虚拟化轻量容器技术教程https://pan.baidu.com/s/1DkoQ…ElasticSearch 5 视频教程https://pan.baidu.com/s/1UdhW…ElasticSearch 6 实战教程https://pan.baidu.com/s/1Mj33…Elasticsearch 顶尖高手系列课程https://pan.baidu.com/s/1ob05…Elasticsearch 分布式全文检索入门视频教程https://pan.baidu.com/s/1cEQW…Elasticsearch、Logstash和Kibana ELK Stack深入浅出视频https://pan.baidu.com/s/1gNW9…FTP服务器架设https://pan.baidu.com/s/1M-4r…Golang 北风网Golang 实战https://pan.baidu.com/s/1lzh5…Golang 传智播客2018Golang 语言https://pan.baidu.com/s/1DGuq…Golang 基于Golang协程实现流量统计系统https://pan.baidu.com/s/13jyF…Golang 慕课网Golang 语言https://pan.baidu.com/s/1HqAc…Golang 无闻Go语言视频教程https://pan.baidu.com/s/1u-2j…Golang 语言基础视频https://pan.baidu.com/s/1L6jM…Golang 语言实战开发一个WEB项目博客系统https://pan.baidu.com/s/1tBq-…Golang 资深工程师深度讲解Go语言https://pan.baidu.com/s/1mtEH…Hadoop 传智播客Hadoop7天培训 非吴超版https://pan.baidu.com/s/1Nr1V…Hadoop 大数据 01https://pan.baidu.com/s/1agMt…Hadoop 黑马Hadoop 视频教程全套https://pan.baidu.com/s/1WumO…Hadoop 马士兵hadoop2.7https://pan.baidu.com/s/1gJ2_…Hadoop 尚学堂_肖斌hadoop100集全https://pan.baidu.com/s/1idWV…Hadoop 泰克全套Hadoop视频https://pan.baidu.com/s/1JAZq…Hibernate 56讲视频教程https://pan.baidu.com/s/1oubv…Hibernate 70讲视频教程https://pan.baidu.com/s/1Bk3t…Hibernate 视频https://pan.baidu.com/s/1GPnp…Java 尚学堂 高并发 马士兵Java高并发编程，Java虚拟机调优https://pan.baidu.com/s/1Fafy…Java 尚学堂_高淇_300集视频教程https://pan.baidu.com/s/1ko9U…Jenkins 持续集成实战系列 + 集成端点 + Jenkins可持续集成https://pan.baidu.com/s/1frYF…Kafka 分布式消息系统实战与JavaScalaHadoopStorm集成https://pan.baidu.com/s/1nWjv…Kafka 高性能消息中间件 分布式集群安装架构原理https://pan.baidu.com/s/1wCjA…Kafka 高性能之道教程https://pan.baidu.com/s/1wNOL…Kafka 消息队列中间件技术视频https://pan.baidu.com/s/12-iy…Kafka 原理剖析及实战演练https://pan.baidu.com/s/1-ZYL…Kafka 原理剖析及实战演练视频教程https://pan.baidu.com/s/12wvi…Linux 操作系统教学视频https://pan.baidu.com/s/1-lGB…Linux 韩顺平https://pan.baidu.com/s/1b6W-…Linux 基础https://pan.baidu.com/s/1fJL5…Linux 尚学堂https://pan.baidu.com/s/1vEv7…Linux 视频教程https://pan.baidu.com/s/1svRm…Linux 汪利鹏https://pan.baidu.com/s/1MOHy…Lucence 视频https://pan.baidu.com/s/1_rKA…Lucene Solr ELK Stack及Solr企业级搜索引擎实战https://pan.baidu.com/s/1v4RP…Lucene Solr 垂直化搜索引擎https://pan.baidu.com/s/1JhfR…Lucene Solr 高级进阶版 全文检索https://pan.baidu.com/s/1-15h…Lucene Solr 企业实战视频https://pan.baidu.com/s/12Foe…Lucene Solr 企业搜索引擎实战之Solr 与ELKStackhttps://pan.baidu.com/s/1KXAQ…Lucene 实战视频教程https://pan.baidu.com/s/13RUL…Luncene 2天讲视频https://pan.baidu.com/s/1FK2c…Maven 视频 01https://pan.baidu.com/s/1Vdef…Maven 视频 02https://pan.baidu.com/s/1htEz…Mybatis 视频https://pan.baidu.com/s/1yMkG…MySQL DBA及Linux企业集群实战工程师https://pan.baidu.com/s/1AkNd…MySQL高级https://pan.baidu.com/s/1V6X2…MySQL基础视频https://pan.baidu.com/s/1gM_D…Netty SpringBoot+Netty 仿微信聊天全栈实战 从0开发到上线部署https://pan.baidu.com/s/1gJ6L…Netty 4源码剖析视频教程https://pan.baidu.com/s/1-D1A…Netty Java读源码之Netty深入剖析https://pan.baidu.com/s/1nPLB…Netty Mina、Nio 互联网架构师https://pan.baidu.com/s/1kCLQ…Netty NIO+Netty5视频教程https://pan.baidu.com/s/1N2jq…Netty 实战高性能分布式RPChttps://pan.baidu.com/s/1yORq…Netty 源码剖析&NIO+Netty5各种RPC架构实战演练https://pan.baidu.com/s/1py5Q…Nginx 视频https://pan.baidu.com/s/1-vQf…Node.js 7天学会Node.js微信公众号https://pan.baidu.com/s/1Bqf0…Node.js 基于Node.js的web实时聊天室项目https://pan.baidu.com/s/10dvg…Node.js 开发个性化全网内容抓取平台视频课程 实战教程https://pan.baidu.com/s/1swZQ…Node.js 爬虫应用之资讯助手系统https://pan.baidu.com/s/1mHjx…Node.js 全栈开发https://pan.baidu.com/s/1_ZXV…Node.js 入门和学习指导https://pan.baidu.com/s/1WgWl…Node.js 项目实战-仿cnodejs社区论坛https://pan.baidu.com/s/1w5p8…Node.js 真简单https://pan.baidu.com/s/1oIuS…PowerDesigner 数据库基本原理和数据库设计实战https://pan.baidu.com/s/1XgcQ…Python 6节课掌握Python爬虫视频https://pan.baidu.com/s/1ftLD…Python Python实战全套教学视频https://pan.baidu.com/s/1seVu…Python 操作三大主流库https://pan.baidu.com/s/1ELRq…Python 大数据项目实战之Python金融应用编程https://pan.baidu.com/s/1sgtR…Python 定向爬虫入门https://pan.baidu.com/s/1Sges…Python 基础https://pan.baidu.com/s/1qPcy…Python 零基础入门Python数据分析师到项目实战https://pan.baidu.com/s/1SmeW…Python 中文视频教程（全38集）https://pan.baidu.com/s/1iSRg…Python3 入门与进阶https://pan.baidu.com/s/1Oas0…RabbitMQ ActiveMQ RokcetMQ Kafka实战 视频教程https://pan.baidu.com/s/1JVSe…RabbitMQ 分布式消处理https://pan.baidu.com/s/1ku7b…RabbitMQ 消息队列从入门到精通https://pan.baidu.com/s/1WgGl…RabbitMQ 消息中间件 深入RabbitMQ集群架构https://pan.baidu.com/s/1QK2k…RabbitMQ 消息中间件技术精讲https://pan.baidu.com/s/1CBKV…RabbitMQ 消息中间件视频https://pan.baidu.com/s/1pskM…Redis 持久化、集群、MySQL5.6优化、Tomcat7优化https://pan.baidu.com/s/1gcYR…Redis 从入门到高可用 分布式实践https://pan.baidu.com/s/1UOsG…Redis 从入门到精通、集群与应用https://pan.baidu.com/s/1DD3a…Redis 缓存与性能优化 + Memcached + Redis + Nginxhttps://pan.baidu.com/s/17UiZ…Redis 视频 01https://pan.baidu.com/s/18wq5…Redis 视频 02https://pan.baidu.com/s/1j2Fp…Redis 视频教程https://pan.baidu.com/s/1J0nm…Redis 新特性、主从复制、集群视频教程https://pan.baidu.com/s/1VQXp…Redis 之高性能服务存储应用https://pan.baidu.com/s/14_Zv…Shiro 视频https://pan.baidu.com/s/1lgYa…Spark 1.从0基础到调通第一个wordcount程序 (课程1-12讲)https://pan.baidu.com/s/1L3jt…Spark 2.Spark内核解密(13-43讲)https://pan.baidu.com/s/1Xbw_…Spark 3.Spark性能优化(44-54讲)https://pan.baidu.com/s/1N0PA…Spark 4.Spark SQL从零起步彻底精通彻底实战(55-73讲)https://pan.baidu.com/s/1EtnF…Spark 5.Spark Streaming专家之路(82-113讲)https://pan.baidu.com/s/1cTDU…Spark 6.大型Spark项目性能优化系列(115-124讲)https://pan.baidu.com/s/1uDa-…Spark 7.Spark Streaming疯狂解密系列(125-134)https://pan.baidu.com/s/1ZY9r…Spark 8.Spark面试宝典（数据倾斜、性能调优等）(135-147)https://pan.baidu.com/s/17zGo…Spark 9.Spark Summithttps://pan.baidu.com/s/1XEHM…Spark Streaming+Kafka+Spark SQL+TopN+Mysql 电商广告点击综合案例实战https://pan.baidu.com/s/1Zt1z…Spark 大型项目实战：电商用户行为分析大数据平台https://pan.baidu.com/s/1HunW…Spark 内核源码剖析、Hadoop高端 实战教程https://pan.baidu.com/s/1sXDI…Spark 视频教程 陈博老师https://pan.baidu.com/s/1t5wY…Spring 视频https://pan.baidu.com/s/16E02…Spring 源码深度解析+注解开发全套视频教程https://pan.baidu.com/s/1FdPf…Spring 赵栋5天视频教程https://pan.baidu.com/s/1rfW6…Spring 注解驱动开发https://pan.baidu.com/s/1Xtmv…SpringBoot 技术栈博客企业前后端https://pan.baidu.com/s/1gSHn…SpringData 视频https://pan.baidu.com/s/16Jm5…SpringMVC 视频https://pan.baidu.com/s/1PV_h…SpringMVC+Spring+MyBatis+Maven整合视频https://pan.baidu.com/s/1YrfH…SpringMVC从入门到上手工作https://pan.baidu.com/s/1mXAa…SpringMVC框架https://pan.baidu.com/s/1BFTG…SpringSecurity 开发企业级认证与授权全套视频教程https://pan.baidu.com/s/1_Xec…Vue.js 2.5开发去哪儿网App 从零基础入门到实战项目https://pan.baidu.com/s/1hX77…Vue.js MUI 仿豆瓣电影 APP跨平台混编框架https://pan.baidu.com/s/1G4cX…Vue.js WebApp 书城整站开发https://pan.baidu.com/s/1v7c9…Vue.js 高仿饿了么APPhttps://pan.baidu.com/s/1QJJO…Vue.js 开发微信全家桶项目Vue,Node,MongoDB高级技术栈全覆盖https://pan.baidu.com/s/191mM…Vue.js 前端面试项目冲刺，京东金融Vue组件化实战https://pan.baidu.com/s/19F1D…Vue.js 全网首发mpvue课程小程序https://pan.baidu.com/s/1UeBX…Vue.js 全栈技能点 Vue2.0,Node.js,MongoDB 打造商城系统https://pan.baidu.com/s/1X_Yo…Vue.js 向军老师Vue开发宝典https://pan.baidu.com/s/1XZ2q…Vue.js 源码全方位深入解析【前7章】https://pan.baidu.com/s/17Usv…ZooKeeper 11讲实战课程https://pan.baidu.com/s/1fot9…ZooKeeper Spring跨机房容灾系统以及灰度发布https://pan.baidu.com/s/1ehcU…ZooKeeper 分布式系统开发实战https://pan.baidu.com/s/1yt8q…ZooKeeper 分布式专题与Dubbo微服务入门https://pan.baidu.com/s/1OmEN…ZooKeeper 基于ZooKeeper的分布式锁实现https://pan.baidu.com/s/1qSHa…ZooKeeper 尚硅谷大数据之ZooKeeper视频https://pan.baidu.com/s/1E0_i…ZooKeeper 实战教程https://pan.baidu.com/s/1xPVR…测试：JMete r接口测试https://pan.baidu.com/s/15a1B…测试：JMeter 深入进阶性能测试体系 各领域企业实战https://pan.baidu.com/s/1Ph-c…测试：Kali Linux渗透测试https://pan.baidu.com/s/1YfGr…机器学习：2018北风网人工智能https://pan.baidu.com/s/1tVIy…机器学习：2018北风网人工智能(完结)https://pan.baidu.com/s/1RnOL…机器学习：Python3 入门机器学习 经典算法与应用https://pan.baidu.com/s/1Obk4…机器学习：Python3 入门机器学习经典算法与应用https://pan.baidu.com/s/1JgXy…机器学习：Python视频教程量化投资与机器学习实战课程高频交易组合投资源码https://pan.baidu.com/s/1Jnxe…机器学习：Python数据分析与机器学习实战https://pan.baidu.com/s/1PQXP…机器学习：Python小象学院机器学习https://pan.baidu.com/s/18BNb…架构：Apache Strom+Zookeeper集群技术实战 Strom理论实战结合视频教程https://pan.baidu.com/s/1waSJ…架构：Java并发编程与高并发解决方案https://pan.baidu.com/s/1KS-F…架构：Java从零到企业级电商项目实战https://pan.baidu.com/s/1FANE…架构：Java秒杀系统方案优化 高性能高并发实战https://pan.baidu.com/s/1mstv…架构：SpringBoot互联网架构平台实战与运维架构https://pan.baidu.com/s/1JMfg…架构：SpringBoot金融项目实战https://pan.baidu.com/s/1kHDF…架构：从零开始学架构https://pan.baidu.com/s/1kKa6…架构：从无到有搭建中小型互联网公司后台服务架构与运维架构https://pan.baidu.com/s/1jNYm…架构：大数据技术推荐系统算法案例实战视频教程（mahout,spark）附完整资料数据软件环境 84课https://pan.baidu.com/s/1YSMO…架构：大数据实时流统计实战https://pan.baidu.com/s/1_h0i…架构：大型分布式架构课程https://pan.baidu.com/s/18H1D…架构：单点登陆基础到实战（jkxy）https://pan.baidu.com/s/1d5-t…架构：分布式事务实践 解决数据一致性https://pan.baidu.com/s/1TpW4…架构：分布式消息系统与Flume整合kafka集成https://pan.baidu.com/s/1RMWg…架构：高级系统架构设计师视频https://pan.baidu.com/s/184o9…架构：基于Dubbo分布式系统架构https://pan.baidu.com/s/1fA55…架构：基于Storm+Kafka+Zookeeper锁+Memcached+mysql架构全方位系统Storm项目案例实战https://pan.baidu.com/s/1dD1e…架构：架构技术之keepalived高可用和Nginx负载均衡实战案例视频https://pan.baidu.com/s/1whwY…架构：秒杀系统企业级实战应用https://pan.baidu.com/s/1cU2v…架构：企业级大型监控系统zabbix深入介绍 分集 53课https://pan.baidu.com/s/1yBTl…架构：手把手从零打造企业级电商平台-前端https://pan.baidu.com/s/1OBrD…架构：徐老师大数据培训Hadoop+HBase+ZooKeeper+Spark+Kafka+Scala+Ambarihttps://pan.baidu.com/s/1Dr5K…架构：亿级流量电商详情页系统的大型高并发与高可用缓存架构实战 二https://pan.baidu.com/s/1C2qo…架构：亿级流量电商详情页系统的大型高并发与高可用缓存架构实战 一https://pan.baidu.com/s/1WlR7…架构：亿级流量电商详情页系统实战（第二版）：缓存架构+高可用服务架构+微服务架构https://pan.baidu.com/s/1hDVt…架构：最新大型分步式项目实战redis+solr+linux+springmvc+mybatishttps://pan.baidu.com/s/1j4b-…算法：初级班第4期课程https://pan.baidu.com/s/1DjgY…算法：进阶班第4期课程https://pan.baidu.com/s/1Zl9o…算法：看得见的算法 7个经典应用诠释算法精髓https://pan.baidu.com/s/11eYh…算法：玩转数据结构 从入门到进阶https://pan.baidu.com/s/1Crqh…算法：玩转算法面试 从真题到思维全面提升算法思维https://pan.baidu.com/s/1HwkU…算法：学习算法思想，修炼编程内功https://pan.baidu.com/s/1g3r-…微服务：Java深入微服务原理改造房产销售平台https://pan.baidu.com/s/1pQN_…微服务：Spring Cloud 微服务实战https://pan.baidu.com/s/1XUzX…微服务：SpringCloud +SpringBoot+docker全套视频教程https://pan.baidu.com/s/1BA9_…微服务：SpringCloud 零基础入门与微服务教程2018年4月https://pan.baidu.com/s/10vlw…微服务：SpringCloud 尚硅谷视频https://pan.baidu.com/s/1-mcj…微服务：SpringCloud 微服务大型电商架构亿级流量电商详情页系统实战-缓存架构+高可用服务架构+微服务架构https://pan.baidu.com/s/1dESM…微服务：从天气看SpringCloud 微服务项目https://pan.baidu.com/s/1aG9n…微服务：面向服务体系架构 + JAX + Dubbo + Zookeeperhttps://pan.baidu.com/s/18kVw…微服务：微服务架构的分布式事务解决方案https://pan.baidu.com/s/1u-rs…视频提取码关注微信公众号：「搜云库」后台回复关键字：“1024"加站长微信好友把网盘视频链接发给站长微信(注意是完全匹配，不能有空格)，即可获取 “视频提取码"免责声明网站所有作品均由网上搜集共同更新，仅供读者预览及学习交流使用，下载后请24小时内删除，如果喜欢请购买正版资源!原作者如果认为本站侵犯了您的版权,请QQ：75997533 告知,我们会立即删除! ...

欢迎大家前往腾讯云+社区，获取更多腾讯海量技术实践干货哦~本文由elson发表于云+社区专栏目前在不考虑IE以及低端安卓机（4.3-）的兼容下，已经可以放心使用flex进行布局了。什么是flex布局以及它的好处，这里就不再赘述。在这篇文章里，想说说flex布局的属性语法及其细节。那么网上也有不少flex布局的教程，为什么又要再写一篇？首先，flex布局的迷之属性们，如果一知半解，机械记忆的话，那不到半个月基本忘光光。先感受一下这12个flex布局属性，是不是很“迷”人。容器属性flex-flowflex-directionflex-wrapjustify-contentalign-itemsalign-content元素属性orderflex-growflex-shrinkflex-basisflexalign-self就连老外也都在twitter吐槽不好理解，可见还是有一定的学习成本。而目前很多flex教程主要以列举属性为主，缺乏对比和理解性脉络。因此，下面会通过我梳理的一个脉络去理解flex布局，包括不同属性的异同以及一些容易造成误解的细节点，彻底弄懂flex布局。一、flex弹性盒模型对于某个元素只要声明了display: flex;，那么这个元素就成为了弹性容器，具有flex弹性布局的特性。每个弹性容器都有两根轴：主轴和交叉轴，两轴之间成90度关系。注意：水平的不一定就是主轴。每根轴都有起点和终点，这对于元素的对齐非常重要。弹性容器中的所有子元素称为<弹性元素>，弹性元素永远沿主轴排列。弹性元素也可以通过display:flex设置为另一个弹性容器，形成嵌套关系。因此一个元素既可以是弹性容器也可以是弹性元素。弹性容器的两根轴非常重要，所有属性都是作用于轴的。下面从轴入手，将所有flex布局属性串起来理解。二、主轴flex布局是一种一维布局模型，一次只能处理一个维度（一行或者一列）上的元素布局，作为对比的是二维布局CSS Grid Layout，可以同时处理行和列上的布局。也就是说，flex布局大部分的属性都是作用于主轴的，在交叉轴上很多时候只能被动地变化。1. 主轴的方向我们可以在弹性容器上通过flex-direction修改主轴的方向。如果主轴方向修改了，那么：交叉轴就会相应地旋转90度。弹性元素的排列方式也会发生改变，因为弹性元素永远沿主轴排列。flex-direction:rowflex-direction:columnflex-direction:row-reverseflex-direction:column-reverse2. 沿主轴的排列处理弹性元素永远沿主轴排列，那么如果主轴排不下，该如何处理？通过设置flex-wrap: nowrap | wrap | wrap-reverse可使得主轴上的元素不折行、折行、反向折行。默认是nowrap不折行，难道任由元素直接溢出容器吗？当然不会，那么这里就涉及到元素的弹性伸缩应对，下面会讲到。wrap折行，顾名思义就是另起一行，那么折行之后行与行之间的间距（对齐）怎样调整？这里又涉及到交叉轴上的多行对齐。wrap-reverse反向折行，是从容器底部开始的折行，但每行元素之间的排列仍保留正向。3. 一个复合属性flex-flow = flex-drection + flex-wrapflex-flow相当于规定了flex布局的“工作流(flow)”flex-flow: row nowrap;三、元素如何弹性伸缩应对当flex-wrap: nowrap;不折行时，容器宽度有剩余/不够分，弹性元素们该怎么“弹性”地伸缩应对？这里针对上面两种场景，引入两个属性(需应用在弹性元素上)flex-shrink：缩小比例（容器宽度<元素总宽度时如何收缩）flex-grow：放大比例（容器宽度>元素总宽度时如何伸展）1. flex-shrink: 缩小比例来看下以下场景，弹性容器#container宽度是200px，一共有三个弹性元素，宽度分别是50px、100px、120px。在不折行的情况下，此时容器宽度是明显不够分配的。实际上，flex-shrink默认为1，也就是当不够分配时，元素都将等比例缩小，占满整个宽度，如下图。#container { display: flex; flex-wrap: nowrap;}元素收缩的计算方法真的是等比缩小(每个元素各减去70/3的宽度)吗？这里稍微深究一下它的收缩计算方法。弹性元素1：50px→37.03px弹性元素2：100px→74.08px弹性元素3：120px→88.89px先抛结论：flex-shrink: 1并非严格等比缩小，它还会考虑弹性元素本身的大小。容器剩余宽度：-70px缩小因子的分母：150 + 1100 + 1120 = 270 (1为各元素flex-shrink的值)元素1的缩小因子：150/270元素1的缩小宽度为缩小因子乘于容器剩余宽度：150/270 * (-70)元素1最后则缩小为：50px + (150/270 *(-70)) = 37.03px加入弹性元素本身大小作为计算方法的考虑因素，主要是为了避免将一些本身宽度较小的元素在收缩之后宽度变为0的情况出现。2. flex-grow: 放大比例同样，弹性容器#container宽度是200px，但此时只有两个弹性元素，宽度分别是50px、100px。此时容器宽度是有剩余的。那么剩余的宽度该怎样分配？而flex-grow则决定了要不要分配以及各个分配多少。（1）在flex布局中，容器剩余宽度默认是不进行分配的，也就是所有弹性元素的flex-grow都为0。（2）通过指定flex-grow为大于零的值，实现容器剩余宽度的分配比例设置。元素放大的计算方法放大的计算方法并没有与缩小一样，将元素大小纳入考虑。仅仅按flex-grow声明的份数算出每个需分配多少，叠加到原来的尺寸上。容器剩余宽度：50px分成每份：50px / (3+2) = 10px元素1放大为：50px + 3 * 10 = 80px无多余宽度时，flex-grow无效下图中，弹性容器的宽度正好等于元素宽度总和，无多余宽度，此时无论flex-grow是什么值都不会生效。同理，对于flex-shrink，在容器宽度有剩余时也是不会生效的。因此这两个属性是针对两种不同场景的互斥属性。四、弹性处理与刚性尺寸在进行弹性处理之余，其实有些场景我们更希望元素尺寸固定，不需要进行弹性调整。设置元素尺寸除了width和height以外，flex还提供了一个flex-basis属性。flex-basis设置的是元素在主轴上的初始尺寸，所谓的初始尺寸就是元素在flex-grow和flex-shrink生效前的尺寸。1. 与width/height的区别首先以width为例进行比较。看下下面的例子。#container {display:flex;}。<div id=“container”> <div>11111</div> <div>22222</div></div>(1) 两者都为0width: 0 —— 完全没显示flex-basis: 0 —— 根据内容撑开宽度(2) 两者非0width: 非0;flex-basis: 非0—— 数值相同时两者等效—— 同时设置，flex-basis优先级高(3) flex-basis为autoflex-basis为auto时，如设置了width则元素尺寸由width决定；没有设置则由内容决定(4) flex-basis == 主轴上的尺寸 != width将主轴方向改为：上→下此时主轴上的尺寸是元素的heightflex-basis == height2. 常用的复合属性 flex这个属性应该是最容易迷糊的一个，下面揭开它的真面目。flex = flex-grow + flex-shrink + flex-basis复合属性，前面说的三个属性的简写。一些简写flex: 1 = flex: 1 1 0%flex: 2 = flex: 2 1 0%flex: auto = flex: 1 1 auto;flex: none = flex: 0 0 auto; // 常用于固定尺寸 不伸缩flex:1 和 flex:auto 的区别其实可以归结于flex-basis:0和flex-basis:auto的区别。flex-basis是指定初始尺寸，当设置为0时（绝对弹性元素），此时相当于告诉flex-grow和flex-shrink在伸缩的时候不需要考虑我的尺寸；相反当设置为auto时（相对弹性元素），此时则需要在伸缩时将元素尺寸纳入考虑。因此从下图（转自W3C）可以看到绝对弹性元素如果flex-grow值是一样的话，那么他们的尺寸一定是一样的。五、容器内如何对齐前面讲完了元素大小关系之后，下面是另外一个重要议题——如何对齐。可以发现上面的所有属性都是围绕主轴进行设置的，但在对齐方面则不得不加入作用于交叉轴上。需要注意的是这些对齐属性都是作用于容器上。1. 主轴上的对齐方式justify-content2. 交叉轴上的对齐方式主轴上比较好理解，重点是交叉轴上。因为交叉轴上存在单行和多行两种情况。交叉轴上的单行对齐align-items默认值是stretch，当元素没有设置具体尺寸时会将容器在交叉轴方向撑满。当align-items不为stretch时，此时除了对齐方式会改变之外，元素在交叉轴方向上的尺寸将由内容或自身尺寸（宽高）决定。注意，交叉轴不一定是从上往下，这点再次强调也不为过。交叉轴上的多行对齐还记得可以通过flex-wrap: wrap使得元素在一行放不下时进行换行。在这种场景下就会在交叉轴上出现多行，多行情况下，flex布局提供了align-content属性设置对齐。align-content与align-items比较类似，同时也比较容易迷糊。下面会将两者对比着来看它们的异同。首先明确一点：align-content只对多行元素有效，会以多行作为整体进行对齐，容器必须开启换行。align-content: stretch | flex-start | flex-end | center | space-between | space-aroundalign-items: stretch | flex-start | flex-end | center | baseline在属性值上，align-content比align-items多了两个值：space-between和space-around。align-content与align-items异同对比与align-items一样，align-content:默认值也是stretch。两者同时都为stretch时，毫无悬念所有元素都是撑满交叉轴。#container { align-items: stretch; align-content: stretch;}当我们将align-items改为flex-start或者给弹性元素设置一个具体高度，此时效果是行与行之间形成了间距。#container { align-items: flex-start; align-content: stretch;}/或者/#container { align-content: stretch;}#container > div { height: 30px;}为什么？因为align-content会以整行为单位，此时会将整行进行拉伸占满交叉轴；而align-items设置了高度或者顶对齐，在不能用高度进行拉伸的情况下，选择了用间距。尝试把align-content设置为顶对齐，此时以行为单位，整体高度通过内容撑开。而align-items仅仅管一行，因此在只有第一个元素设置了高度的情况下，第一行的其他元素遵循align-items: stretch也被拉伸到了50px。而第二行则保持高度不变。#container { align-items: stretch; align-content: flex-start;}#container > div:first-child { height: 50px;}两者的区别还是不明显？来看下面这个例子。这里仅对第二个元素的高度进行设置，其他元素高度则仍保持内容撑开。以第一个图为例，会发现align-content会将所有行进行顶对齐，然后第一行由于第二个元素设置了较高的高度，因此体现出了底对齐。两者差异总结：两者“作用域”不同align-content管全局(所有行视为整体)align-items管单行能否更灵活地设置交叉轴对齐除了在容器上设置交叉轴对齐，还可以通过align-self单独对某个元素设置交叉轴对齐方式。值与align-items相同可覆盖容器的align-items属性默认值为auto，表示继承父元素的align-items属性#container { display: flex; align-items: flex-start;}#container > div:first-child { align-self: stretch;}#container > div:nth-child(3) { align-self: center;}#container > div:nth-child(4) { align-self: flex-end;}六、其他order：更优雅地调整元素顺序#container > div:first-child { order: 2;}#container > div:nth-child(2) { order: 4;}#container > div:nth-child(3) { order: 1;}#container > div:nth-child(4) { order: 3;}order：可设置元素之间的排列顺序数值越小，越靠前，默认为0值相同时，以dom中元素排列为准七、总结附参考阮老师博文中的骰子练习，我做了张图，大家不妨可以各自实现下，理解之后应该能够比较轻松地写出来。codepen参考资料Flex 布局教程：语法篇Flex 布局教程：实例篇flex code pen理解Flexbox：你需要知道的一切深入理解css3中的flex-grow、flex-shrink、flex-basisA Complete Guide to Flexboxflex实战及坑总结flex bugs集锦相关阅读bitset用法小结Numpy基础知识点汇总【每日课程推荐】机器学习实战！快速入门在线广告业务及CTR相应知识 ...

什么是日志?日志就是按照时间顺序追加的、完全有序的记录序列，其实就是一种特殊的文件格式，文件是一个字节数组，而这里日志是一个记录数据，只是相对于文件来说，这里每条记录都是按照时间的相对顺序排列的，可以说日志是最简单的一种存储模型，读取一般都是从左到右，例如消息队列，一般是线性写入log文件，消费者顺序从offset开始读取。由于日志本身固有的特性，记录从左向右开始顺序插入，也就意味着左边的记录相较于右边的记录“更老”, 也就是说我们可以不用依赖于系统时钟，这个特性对于分布式系统来说相当重要。日志的应用日志在数据库中的应用日志是什么时候出现已经无从得知，可能是概念上来讲太简单。在数据库领域中日志更多的是用于在系统crash的时候同步数据以及索引等，例如MySQL中的redo log，redo log是一种基于磁盘的数据结构，用于在系统挂掉的时候保证数据的正确性、完整性，也叫预写日志，例如在一个事物的执行过程中，首先会写redo log，然后才会应用实际的更改，这样当系统crash后恢复时就能够根据redo log进行重放从而恢复数据(在初始化的过程中，这个时候不会还没有客户端的连接)。日志也可以用于数据库主从之间的同步，因为本质上，数据库所有的操作记录都已经写入到了日志中，我们只要将日志同步到slave，并在slave重放就能够实现主从同步，这里也可以实现很多其他需要的组件，我们可以通过订阅redo log 从而拿到数据库所有的变更，从而实现个性化的业务逻辑，例如审计、缓存同步等等。日志在分布式系统中的应用分布式系统服务本质上就是关于状态的变更，这里可以理解为状态机，两个独立的进程(不依赖于外部环境，例如系统时钟、外部接口等)给定一致的输入将会产生一致的输出并最终保持一致的状态，而日志由于其固有的顺序性并不依赖系统时钟，正好可以用来解决变更有序性的问题。我们利用这个特性实现解决分布式系统中遇到的很多问题。例如RocketMQ中的备节点，主broker接收客户端的请求，并记录日志，然后实时同步到salve中，slave在本地重放，当master挂掉的时候，slave可以继续处理请求，例如拒绝写请求并继续处理读请求。日志中不仅仅可以记录数据，也可以直接记录操作，例如SQL语句。日志是解决一致性问题的关键数据结构，日志就像是操作序列，每一条记录代表一条指令，例如应用广泛的Paxos、Raft协议，都是基于日志构建起来的一致性协议。日志在Message Queue中的应用日志可以很方便的用于处理数据之间的流入流出，每一个数据源都可以产生自己的日志，这里数据源可以来自各个方面，例如某个事件流(页面点击、缓存刷新提醒、数据库binlog变更)，我们可以将日志集中存储到一个集群中，订阅者可以根据offset来读取日志的每条记录，根据每条记录中的数据、操作应用自己的变更。在此我向大家推荐一个架构学习交流群。交流学习群号：897889510 里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化、分布式架构等这些成为架构师必备的知识体系。还能领取免费的学习资源，目前受益良多这里的日志可以理解为消息队列，消息队列可以起到异步解耦、限流的作用。为什么说解耦呢？因为对于消费者、生产者来说，两个角色的职责都很清晰，就负责生产消息、消费消息，而不用关心下游、上游是谁，不管是来数据库的变更日志、某个事件也好，对于某一方来说我根本不需要关心，我只需要关注自己感兴趣的日志以及日志中的每条记录。我们知道数据库的QPS是一定的，而上层应用一般可以横向扩容，这个时候如果到了双11这种请求突然的场景，数据库会吃不消，那么我们就可以引入消息队列，将每个队数据库的操作写到日志中，由另外一个应用专门负责消费这些日志记录并应用到数据库中，而且就算数据库挂了，当恢复的时候也可以从上次消息的位置继续处理(RocketMQ和Kafka都支持Exactly Once语义)，这里即使生产者的速度异于消费者的速度也不会有影响，日志在这里起到了缓冲的作用，它可以将所有的记录存储到日志中，并定时同步到slave节点，这样消息的积压能力能够得到很好的提升，因为写日志都是有master节点处理，读请求这里分为两种，一种是tail-read，就是说消费速度能够跟得上写入速度的，这种读可以直接走缓存，而另一种也就是落后于写入请求的消费者，这种可以从slave节点读取，这样通过IO隔离以及操作系统自带的一些文件策略，例如pagecache、缓存预读等，性能可以得到很大的提升。在此我向大家推荐一个架构学习交流群。交流学习群号：575745314 里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化、分布式架构等这些成为架构师必备的知识体系。还能领取免费的学习资源，目前受益良多。分布式系统中可横向扩展是一个相当重要的特性，加机器能解决的问题都不是问题。那么如何实现一个能够实现横向扩展的消息队列呢? 假如我们有一个单机的消息队列，随着topic数目的上升，IO、CPU、带宽等都会逐渐成为瓶颈，性能会慢慢下降，那么这里如何进行性能优化呢?1.topic/日志分片，本质上topic写入的消息就是日志的记录，那么随着写入的数量越多，单机会慢慢的成为瓶颈，这个时候我们可以将单个topic分为多个子topic，并将每个topic分配到不同的机器上，通过这种方式，对于那些消息量极大的topic就可以通过加机器解决，而对于一些消息量较少的可以分到到同一台机器或不进行分区2.group commit，例如Kafka的producer客户端，写入消息的时候，是先写入一个本地内存队列，然后将消息按照每个分区、节点汇总，进行批量提交，对于服务器端或者broker端，也可以利用这种方式，先写入pagecache，再定时刷盘，刷盘的方式可以根据业务决定，例如金融业务可能会采取同步刷盘的方式。3.规避无用的数据拷贝4.IO隔离结语日志在分布式系统中扮演了很重要的角色，是理解分布式系统各个组件的关键，随着理解的深入，我们发现很多分布式中间件都是基于日志进行构建的，例如Zookeeper、HDFS、Kafka、RocketMQ、Google Spanner等等，甚至于数据库，例如Redis、MySQL等等，其master-slave都是基于日志同步的方式，依赖共享的日志系统，我们可以实现很多系统: 节点间数据同步、并发更新数据顺序问题(一致性问题)、持久性(系统crash时能够通过其他节点继续提供服务)、分布式锁服务等等，相信慢慢的通过实践、以及大量的论文阅读之后，一定会有更深层次的理解。

欢迎大家前往腾讯云+社区，获取更多腾讯海量技术实践干货哦~本文由mariolu 发表于云+社区专栏序言（初衷）设计该系统初衷是基于描绘业务（或机器集群）存储模型，分析代理缓存服务器磁盘存储与回源率的关系。系统意义是在腾讯云成本优化过程中，量化指导机房设备扩容。前半部分是介绍背景，对CDN缓存模型做一些理论思考。后半部分会实际操作搭建一个微型但是五脏俱全的分布式通用系统架构，最后赋予该系统一些跟背景相关的功能，解决成本优化中遇到的实际问题。缓存服务器存储模型架构（背景）：图1 存储模型腾讯CDN的线上路由是用户à分布于各地区各运营商的OC->SOC->SMid->源站。各个层级节点部署的都是缓存服务器。来自用户的部分请求流量命中服务器，另一部分产生回源流量。随着业务带宽自然增长，用户端带宽增长，假设业务回源率不变的情况下，磁盘缓存淘汰更新（淘汰）速率变快，表现为以下业务瓶颈（iowait变高、回源带宽变高，由于磁盘空间大小受限的缓存淘汰导致回源率变高）。为了说明这个原理。我们假设两个极端：一个是设备磁盘容量无限大，业务过来的流量缓存只受源站缓存规则受限。只要缓存没过期，磁盘可以无限缓存，回源流量只需要首次访问的流量，所以这个回源量（率）只跟业务特性（重复率）有关系。另一个极端是磁盘极限小（归零），那么无论业务设置缓存是否过期，客户端访问量都是1比1的回源量。假设业务平均的缓存周期是1个小时。那么这1个小时的首次缓存带宽（同一cache key的多次访问，我们认为是一次）将是这个硬盘的所需要的空间。这个大小是合理的，可以保证磁盘足够容纳业务的量。假设这个量达不到，或者本来达到了，但是由于业务自然增长了，1个小时内地首次缓存带宽变多，硬盘空间也不够用。设备扩容是个解决办法。但是压测系统在这之前，没有客观数据证明需要扩容多大设备。或者扩容多少设备没有进行灰度验证，设备到位拍脑袋直接线上部署机器。我们在实验机器进行线上日志的重放，模拟出存储模拟曲线，来指导线上机房合理的设备存储。这就是建设重放日志系统的意义。麻雀虽小，五脏俱全的重放日志模型（总览）这一章，我们定义了下列模块：模拟日志服务器：下载线上某个机房的一段时间周期的访问日志。一个日志存放10分钟访问记录。机房有几台机器就下载几份日志。日志服务器同时提供任务分片信息的查询服务。假设我们需要重放任务id为pig_120t的任务切片。下图既为任务切片详情。图2 日志服务器的日志分片文件任务控制器：启动任务或者结束任务总开关。任务分配均匀分配给具体的肉鸡和代理服务器。插入任务到Task Pool中，收集服务端的实时总流量、回源流量、总请求次数和回源次数数据并插入到回源率结果数据表。肉鸡：轮询Task Pool的任务表。如果有任务，则按照任务明细（时间、线上机房ip）向日志服务器请求下载该分片的日志。重放请求到指定的代理服务器。代理服务端：提供实时回源数据查询服务。并且安装nws缓存服务器等组件，该机器等同于线上机房的软件模块。实时展示界面：可随时查看实时回源率和一些任务异常状态信息。图3为客户端和服务端的互动图。图4是任务控制端在任务进行中和其他模块的联动过程。图3 肉鸡和代理服务端的架构图4 控制端的任务联动过程分布式系统特点日志重放模型核心是一个高性能压测系统，但是需要添加一些逻辑：日志下载、日志分析重构、结果数据收集、数据上报展示。分布式系统核心是：是否做到了可拓展、可恢复、简易搭建、容错、自动化。以下内容会一一展开。先说说高性能：在一个通用模型中。我们模拟线上日志，这个系统要做到高效、因为我们的重放日志速度要比线上的qps还要快。机器的重放速度决定了分析结果的速度。同时更快的速度，所需要的肉鸡资源更少。笔者在python各个url请求库和golang中，最终敲定使用了golang实现肉鸡。golang做到了和原生c+epoll一样快的速度，但是代码实现容易多了。理论上我们对一台做过代理端性能瓶颈分析。线上日志比模拟日志更复杂，qps适度下降是必然的。Golang这个客户端达到预期目标。可扩展：在我们可能会随时增加模拟机器集群的肉鸡数量，或者更多的闲置代理服务器资源加入压测任务。所以系统在可用机器数据表随时加入新的机器。图5 系统的动态可扩展可恢复：分布式系统不同于单机模式。不能避免可能有各种故障，有时候系统部分节点出错了，我们更倾向于不用这个节点，而不是继续使用未处理完成的结果。即非0即1，无中间状态。还有分布式系统网络传输延迟不可控。所以压测系统设计了一套容错机制：包括心跳检测失败，自动在数据表剔除肉鸡服务端。接口异常容错。超时过期未完成任务去除。crontab定时拉取退出进程等。简易搭建：使用ajs接口，和批处理安装脚本。自动化部署肉鸡和服务端。配置dns解析ip（日志服务器，任务池、回源率结果所在的数据库ip），tcp time_wait状态的复用，千万别忘了还有一些系统限制放开（放开ulimit fd limit，这里设置100000，永久设置需要编辑/etc/security/limits.conf）。如果肉鸡有依赖程序运行库需要同时下载。在肉鸡机器下载肉鸡客户端和配置、在服务端机器下载服务端和配置，下载定时拉起程序脚本，并添加到crontab定时执行。以上都用批处理脚本自动执行。一些设计范式的思考Single-productor and Multi-consumer在肉鸡客户端的设计中：读日志文件一行一条记录，添加到消息管道，然后多个执行worker从消息管道取url，执行模拟请求。消息管道传送的是一条待执行的日志url。IO消耗型程序指的是如果consumer执行访问日志并瞬间完成结果，但是productor需要对日志进行复杂的字符串处理（例如正则之类的），那么它下次取不到数据，就会被管道block住。另外一种是CPU消耗型程序，如果日志url已经预先处理好了，productor只是简单的copy数据给消息管道。而consumer访问url，经过不可预知的网络延迟。那么多个consumer（因为是包括网络访问时间，consumer个数设计超过cpu核数，比如2倍）同时访问，读端速度慢于写端数度。在对一个日志文件进行实验，我们发现处理18w条记录日志的时间是0.3s，而执行完这些url的访问任务则需要3分钟。那么很显然这是一个CPU消耗性进程。如果是IO消耗型的程序。Golang有种叫fan out的消息模型。我们可以这样设计：多个读端去读取多个chan list的chan，一个写端写一个chan。Fanout则将写端的chan，循环写到chan list的chan中。Map-reduce我们有时会做一个地理位置一个运营商的机房日志分析。一个机房包含数台机器ip。合理的调度多个肉鸡客户端并行访问日志，可以更快速得到合并回源率数据。并行机制，经典的map-reduce，日志文件按机房机器ip纬度切片分发任务，启动N个肉鸡同时并行访问，等最后一台肉鸡完成任务时，归并各个肉鸡数据按成功请求数量、成功请求流量、失败请求数量、失败请求流量等方式做统计。同时用于和线上日志做校样。这里的mapper就是肉鸡，产生的数据表，我们按照关注的类型去提取就是reducer。简化的map-reducer（不基于分布式文件系统），map和reduce中间的数据传递用数据表实现。每个mapper产生的日志数据先放在本地，然后再上报给数据表。但是数据表大小的限制，我们只能上传头部访问url。所以如果用这个办法实现，数据是不完整的，或者不完全正确的数据。因为也许两台肉鸡合并的头部数据正好就包括了某肉鸡未上传的日志（该日志因为没有到达单机肉鸡访问量top的标准）。那么如何解决这个问题呢，根本原因在于汇总数据所在的文件系统是本地的，不是分布式的（hadoop的hdfs大概就是基于这种需求发明的把）。如果是状态码纬度，这种思路是没问题的，因为http状态码总量就那么少。那么如果是url纬度，比如说某机房给单肉鸡的单次任务在10分钟的url总数据量达到18万条。只看日志重复数>100的肉鸡数据。这样误差最大值是100*肉鸡数，所以对于10台肉鸡的机房，只要是综合合并结果>1000。都是可信任的。如果是域名纬度，少数头部客户流量占比大多数带宽。 这也就是所谓的hot-key，少数的hot-key占据了大多数比例的流量。所以域名纬度时，这个时候可以把关注点缩放在指定域名的url列表。如果本地上报给数据表的数据量太大，url也可以考虑进行短地址压缩。当然如果不想弯道超车的话，需要硬解决这个问题，那可能得需要hdfs这种分布式文件系统。Stream-Processing我们进行日志客户端系统，需要向日志服务器下载此次任务所需要的日志（一般是一个机器10分钟的访问日志）。首先本地日志会去任务服务器查询重放任务。接着去日志服务器下载。如果该模拟集群是在DC网络组建，那么下载一个10分钟（约150M左右的文件）日志几乎在1两秒内搞定，但是如果这个分布式系统是组建于OC网络，那么OC网络的肉鸡服务器要去DC（考虑机房可靠性，日志服务器架设在DC网络）下载，经过nat转化内网到外网，下载则需要10s左右。如果为了等待日志服务器下载完，也是一笔时间开销。在分布式系统中，所谓的stream-processing，和batch processing不同的是，数据是无边界的。你不知道什么时候日志下载完。而batch processing的前后流程关系，好比生产流水线的工序，前一道完成，后一道才开始，对于后一道是完全知道前一道的输出结果有多少。所谓的流式处理则需要在前一道部分输出结果到达时，启动后一道工序，前一道工序继续输出，后一道则需要做出处理事件响应。后一道需要频繁调度程序。消息系统（message broker）：前一道的部分输出，输入给消息系统。消息系统检测到是完整的一条日志，则可以产生后一道工序的输入。这里我们会碰到一个问题。下载日志的速度（10s）会远远快于执行重放这些日志的速度（3min）。按照一个消息系统可能的动作是：无buffer则丢弃，按照队列缓存住，执行流控同步后一道工序和前一道工序的匹配速度。这里我们选择了按照队列缓存住这个方案。当然在一个严谨的分布式数据库设计，message broker是一个能考率到数据丢失的节点。Broker会把完整数据发给后道工序，同时会把buffer数据缓存到硬盘备份，以防程序core dump。如果对于慢速前道工序，可以进行综合方案配置，丢弃或者流控。这里消息broker不同于数据库，他的中间未处理数据是暂时存储，处理过的消息要清除存储。总结当然：现实中的生产线的分布式系统会远比这个复杂，但是本文实现的从0到1的迷你麻雀分布式系统有一定的实践意义。它不是一蹴而就的，不断地版本迭代。当然该系统也完成了作者的kpi-存储模型分析，在中途遇到问题时，进行的设计思考和改良，在此总结分享给大家。问答文字识别在格式上有什么要求？相关阅读原来你是这样的http2我是怎么一步步用go找出压测性能瓶颈HTTP/2之服务器推送(Server Push)最佳实践 【每日课程推荐】机器学习实战！快速入门在线广告业务及CTR相应知识

本文来自腾讯云技术沙龙，本次沙龙主题为Serverless架构开发与SCF部署实践 演讲嘉宾：黄文俊，曾负责企业级存储、企业级容器平台等产品的架构与开发，目前主要负责SCF腾讯无服务器云函数产品相关。对容器平台、微服务架构、无服务器架构以及DevOps等多种热门技术领域均有涉猎。大家好，自我介绍一下，目前我是腾讯云无服务器云函数产品负责人。我做了很多年后端开发。今天是从一个程序员角度讲解一下我们怎么样用Serverless架构。我将本次讲解分为几块：第一，Serverless架构介绍；第二，对云函数产品介绍；第三，Serverless使用场景。讲Serverless架构之前我们可以来看一下整个云的发展过程，在没有云之前大家可能都是用的物理服务器，早期时候大家都用的物理机托管方式，采购一些服务器在机房里托管，这个时候大家前期要选择物理机型号，要做好IDC网络；如果出了问题还要请IDC人员帮你操作。这些设备的投入和运维成本还是很高的。云时代到来之后，由于虚拟化技术的运用，我们用上了云主机。云主机是大家直接在云上做虚拟机购买，开通就可以使用。这时候我们称之为IaaS(基础设施即服务)，这种情况下就无需物理机运营，直接放到云平台来做。而之后随着容器技术的发展，我们有了容器平台，或者叫PaaS（平台即服务）。在容器平台到来之后实际上还存在一部分基础设施运维问题，但是这时候基础设施逐渐下沉到运维人员进行操作；而从应用开发者角度来看，他们已经不用再去关心虚拟机，或者操作系统。在这种情况下，应用开发人员更多的去关注应用所需要的计算资源或者存储资源的使用。继续向前发展，我们到了FaaS（函数即服务）。这时候运维人员不需要关注底层的运维，而是按需运行的能力。业务开发人员能够进一步做与业务相关的事情。接下来我们来看一下Serverless架构是什么。Serverless从物理机或虚拟机的使用上进行了分离，更关注上层业务的运行情况。Serverless架构包含两块：函数即服务和后端即服务。函数即服务提供的是计算能力。原有的计算能力，无论是容器也好，虚拟机也好都承载在一定的操作系统之上，函数即服务把计算能力进行了进一步抽象，我们在后文再继续进行展开。另外，Serverless还有后端即服务，比如对象存储，数据库应用，缓存服务，我们也可以称之为Serverless，因为这些服务也能够在云上提供开通即服务，开通即使用的能力。在使用这些产品时同样不需要关注它的服务器是什么样的，它的服务器部署在哪里，而是服务开通就可以使用了，后面的运维工作都交给了云，所以不用感知它的最底层服务器，因此我们也可以把它称之为Serverless。这种服务就称之为Serverless后端即服务。这两个合起来可以称为Serverless架构。函数即服务的工作原理是什么样的？在Serverless上是怎样提供计算能力的？大家原来使用容器或者虚拟机的时候都可以知道，我们把代码上传到容器或者上传到虚拟机，然后启动一个进程，代码就可以运行，它就可以接受外部的请求，做一些实时的响应。Serverless和原有的容器或虚拟机不同，实现的是计算托管服务，Serverless用户首先要做的，是把我们称为云函数的代码，提交到平台上进行代码托管；然后要做的是配置触发器。为什么需要配置触发器？因为云函数的运行方式是触发式运行，有触发的时候，代码才会真正运行起来。所以配置触发器意味着我们给它设置了一个触发源，也就是定义了在什么事件下代码才真正运行起来。用户代码托管到平台之后，事件没有到来之前，它仅仅是代码文件和配置存储，代码并没有运行。什么情况下运行？是当事件触发真正到来的时候，云函数才会真正启动一个实例，这个实例就意味着一个计算单元。计算单元被拉起后，这个事件就被传到这个计算单元中进行计算处理。如果这个触发源的事件很多，并发很高的情况下，平台会根据事件的堆积情况，或者事件到达的速度，自动把同一份代码和配置拉起多个实例进行并发处理。因此可以看到Serverless的运行是按需运行，意味着只有在事件到来的情况下，代码才会被拉起，才会运行起来。自动并发，是指云函数平台会根据事件堆积情况自动的进行并发，自动拉起多个实例进行处理。而原有的容器或者虚拟机如果要进行并发的话还是要有一定的手工参与，比如启动更多的容器，或者加入更多的虚拟机来承载高并发的请求。而函数即服务是完全自动的运行。按需运行带来的另外一个特点，是代码在运行起来之后上才会占用计算资源。函数即服务的费用也是根据按需运行来的，也就是函数运行的时候才进行计费；而没有使用的情况下不会计费。实际上大多数互联网业务只有白天的时候，甚至六点之后大家下班之后业务才会迎来高峰，而到凌晨之后实际上没有多少请求的，因此函数即服务能够很好的满足波峰波谷来削峰填谷的能力。从上面的原理可以看出函数即服务的一些特点，比如说代码托管，云函数平台所提供的直接就是运行环境，也就是支持各种开发语言的环境；对于开发者或者函数服务使用者来说，并没有感知到它下面的服务器在哪里，而是由函数平台完成了函数运行的调度。因此实际来讲不需要运维，包括操作系统优化，服务器维护等等这些都是由平台进行承载。而秒级部署意味着函数在真正的被请求的时候才运行。而这个请求才运行代表着当请求到达平台的时候函数才会被实时拉起并运行。运行完成后如果没有后续请求，实例也会退还。由于函数运行是事件触发的，而事件其实包含很多种类，有各种触发器都可以对接云函数。有越多的触发器对接，云函数所能提供的场景也就越多。对于开发者来说，使用云函数的情况下，他真正关注的是应该业务，是使用代码去聚焦他的业务逻辑，例如是拿到这个事件后该进行什么样的逻辑操作，进行什么样的业务存储，而不需要去关注怎么使用业务代码实现高并发，怎么样实现高请求的承载能力。因此这里看到函数即服务能够为应用开发者带来一些便利，而自动并发本身也是函数即服务所具有的特点。而对于腾讯云无服务器云函数，在最开始开发产品的时候，我们目标也是一样，就是把计算进行托管。在计算托管的情况下，我们使用计算就像我们使用腾讯云对象存储一样，在使用的时候不用关心最底层的运维，不用关心虚拟机或者物理机是否安全。和对象存储进行对比也能看到，我们计算也是按照实际使用情况进行计费。当然现在云函数还处于免费期，大家可以随时使用。从使用方法来说，云函数本身，或者说函数即服务这种产品本身的使用方法都是很简单的。我们在开发的时候更多的关注于核心代码的编写。核心代码的意思实际上就是真正的业务逻辑。而且业务逻辑里不需要考虑高并发，因为由刚才给出来的函数即服务这种计算特点来看的话，在高并发请求的时候是通过多个实例处理进行，因此业务代码在编写的时候，就关注单个事件的处理就行。因此，第一步的核心的就是编写核心业务代码，就是用代码要实现什么样的业务。后续就是配置触发方式。配置触发方式就是把函数代码和触发源对接起来。和云平台上其他的产品进行对接，需要什么样的事件，处理什么样的事件，进行什么样的逻辑处理，做好这样的触发源对接后，函数就能够在事件产生的情况下运行。因此，从整个使用方法来看的话，大家真正要做的是两步：第一，编写代码，第二，配置好触发。而对于底层的基础设施，环境配置这块都不需要大家操心的。目前，腾讯云函数从运行环境来说目前已经支持了Python、Nodejs、PHP、Golang、Java等语言的开发运行环境。接下来是触发器，因为触发器越多，云函数所能去使用的场景其实也越多，我们已经实现的触发器有定时触发器；腾讯云对象存储服务，包括文件的上传、删除等时间；CMQ 消息队列服务；API 网关服务，这个是通过serverless 架构实现 API 服务的一款重要触发器；另外，还有ckafka，这个是腾讯云提供的kafka能力。目前kafka算是一个开源产品，我们腾讯云把它包装后放到云上来，也是兼容标准的kafka协议。因此在很多情况下直接迁移到腾讯云不需要任何修改。因为kafka本身作为消息传递的载体，跟腾讯原有的消息队列类似，由消息来执行云函数。下面介绍一下在什么场景下Serverless可以落地？第一，在Serverless场景中最常用到的就是API服务。大家知道实现一个API服务，无论是把API给到浏览器应用，还是给到手机APP使用，还是给到小程序应用，给到它们的时候是以API实现的。要实现这个要有WEB服务器接收连接，对接后端的业务代码，如果你要再进行文件存储，后端的结构化存储，或者有一些缓存需要读写，你的应用服务器后面可能还要对接相应的文件存储，结构化数据库，后续如果想使用缓存，再对接到相应的服务器或相应产品。如果把现有的API服务向Serverless架构演进，那么它将怎么样呈现呢？在不改变 API 的情况下，它的前端浏览器应用、APP、小程序，都可以无缝对接上来。而使用API网关来承接 API 请求，当这个请求来到API网关，由它转发给云函数，触发云函数执行。云函数执行时运行业务逻辑。实际上云函数运行时要求无状态，因此这样的状态存储也需要用到后面的一些存储，无论做缓存也好还是数据库也好都要用上。因此，云上提供的产品一样可以进行对接。像文件存储的话可以用对象存储来进行。数据库的话一样的有相应的数据库产品，结构化还是非结构化数据库都有相应的产品可以使用。同样的，缓存也有相应的产品做对接。云函数通过代码编写，直接进行数据库的读写，或者缓存的读写都是可以的。从整个服务架构来看的话，我们使用最前面的API网关，提供是API能力，甚至进一步能够直提供有SDK服务，更加的方便开发。SDK提供了各种开发语言来直接进行API调用。云函数在中间起到的是业务逻辑处理的作用，而状态数据或者其他业务数据的存储是依赖于后面的文件存储或者数据库进行的。API服务也是Serverless最常用的一种落地形式。这里介绍的场景，都是我们客户在实际使用的场景。在 serverless落地场景中，对对象文件的处理也很常见。对象文件处理指的是对对象文件进行操作后的回调处理。回调通常是在对象文件创建或删除操作后产生的事件。云函数可以在获取到这个事件后进行后续的处理。这里常见的处理逻辑是下面几种，比如说图片处理，针对图片去生成各种尺寸的缩略图或者进行裁剪，然后再次存储到对象存储数据中，之后可以根据不同客户端的请求展示不同大小的图片到前端。文件批量打包，用户需要进行文件筛选和打包的时候可以通过使用云函数来处理。在上传文件后，如果需要选择哪些文件来打包，把文件生成压缩包以供下载，这都可以由事件处理来进行。日志归档分析，以及业务系统回调，也是云函数所承载的业务逻辑。比如说日志归档分析这种用法，用户会把每天的前端应用服务器的日志上传到对象存储中归档，归档后会触发云函数执行，云函数会拉下这些日志文件进行实时分析，它会抽取这些日志中的错误数，或者是其他业务相关或者用户关注的内容，然后再把它抽取到的信息或者统计到的信息写回数据库，供用户后续进行排查、使用。用户自身API调用也是，例如用户生成的一些视频文件上传到对象存储，会触发云函数，将上传文件的信息通知到用户的转码系统，通过视频转码转成不同分辨率然后再进行存储。当然转码是用户自身实现的业务系统，这块通过回调通知，通知它自身的业务系统。这些就是云函数在Serverless架构和对象存储连用的落地场景。再就是CKafka消息处理。CKafka目前比较多的应用场景是做日志存储和日志搜集，例如有多台应用服务器在不断产生日志的情况下，可以把日志写到CKafka，然后CKafka再进行归档和后续分析。而 CKafka和云函数对接是由CKafka收到的信息来进行触发的。日志搜集后，要归档的日志，一般存储到对象存储当中。这种情况CKafka消息，会被推送给云函数，云函数再再把这些消息写到对象存储中去。有些用户不是写对象存储，而是写数据库，以数据库形式归档，其实也是一样的。有的使用场景，需要进行消息分析，会实时拿到消息后立刻分析里面的关键字，如果捕捉到了关键字，会立刻把这些消息推送到ckafka 的另一个topic 中，去及时的发出告警给到业务和运维人员。这也是 serverless 的一种用法，就是对消息的分析和转发。消息队列和CKafka类似，但是消息队列一般不是进行日志的搜集，而是进行业务解耦。消息队列 CMQ 是腾讯云提供的一个高可靠金融级消息队列，通常进行一些业务级消息转发和处理。使用这个产品，实际上做的是业务解耦。云函数在这里承载着消息的逻辑处理过程，它能够在接收到消息后对消息立刻进行业务处理。这个业务处理就是实际的业务逻辑，比如我要根据里面某个消息进行判断，判断它是否合适，要不要进行后续的转发，或者转发到另外的业务系统中去？这就是业务之间执行的逻辑。同时，我们也可以使用云函数，再次进行消息的分派，做状态转移。这个状态转移和后面消息转发都是一样的，它会识别消息里的内容，根据消息里的内容进行转发。这种情况下类似于我们使用云函数进行逻辑处理，把它转移到合适的消息队列，然后再进行处理。这也是我们所见过直接用云函数进行消息派发的使用方式。最后一种形式现在也不少，就是利用定时器触发。原本大家更多是在运维场景下使用定时任务，在原有使用 crontab 脚本的情况下，大家通常还要关心脚本运行是否成功，这台虚拟机是否还在工作。云函数抛弃了大家使用传统的虚拟机或者物理机来去写crontab脚本还要确保可靠性的问题。而在实际使用定时器触发的场景下，这里也有几种用法：一种是业务拨测。这个是周期性的去拨测业务是否还在工作，如果出现异常的情况下能够及时的发出告警，发出邮件或者短信告诉到运维或开发人员。另一个是定时备份，这个是在所需要的周期内，比如每天，或者每两天对数据库进行备份，针对数据库需要做数据导出，导出后再将导出内容以文件的形式存储到合适的地方，例如对象存储中，做好定时备份。还有一个是定时数据计算。因为有些计算是根据一段时间内的统计之后，进行计算并展示。在实际场景中，我们腾讯云内部有业务就是在进行定时数据计算，每两小时做一次统计，然后再把统计数据写到数据库做后续业务的展示以及业务分析。总结：Serverless架构本身给用户带来什么？它实际上就是允许我们更关注业务代码，因此可以更快速的构建业务然后上线。现在互联网开发速度越来越快，因此大家期望的是进一步加快开发和业务真正上线的速度，提高迭代的能力。因此，使用Serverless的话可以更快速让业务上线，让我们更快实现我们的想法。而按需使用是我们这个业务在上线之后，在真正产生请求后，业务才会被调动触发，才会有计算。而如果你的业务产生了爆发式增长，其实也不需要担心平台承载能力或者业务扩展是否跟得上，因为平台提供自动扩展能力，降低了大家对运维的诉求，大家不用关心很底层的东西，而运维人员也可以更偏重流程化和业务相关的运维。这就是Serverless架构给大家带来的一些好处。而作为Serverless里的核心，函数即服务这种产品，是Serverless中所呈现出来的计算型的组件，大家也可以看到它和触发源和后端的各种产品或服务有紧密关联，它可以更多的被看做是云时代的脚本，类似于黏合剂，把前面的触发源和后端的各种存储，数据，服务进行了黏合，真正实现架构落地，才是真正实现业务逻辑落地的能力。Q&AQ：云函数有无限扩展能力，但是整个系统也有可能是有限制的，比如它的背后的数据库和存储，我能不能设这样的一个扩展上限？A：这可以设置上限的。目前可以通过提交工单的方式来设置期望的合适上限。扩展可以在后台设置一个合适值，并发实例扩展到这个就不会再扩展了，避免大量实例连接造成后端的数据库或存储超过连接数限制。Q：实现 API 服务有哪些开发方式？A：云函数实现 API 服务的开发方式有好几种，一个是全部在一个函数里完成，路径和方法解析都在函数里进行。这也是偏传统的开发方式。另外一种是进行拆解，每个函数处理一个 API 路径和方法的请求，这种是微服务的开发方式。而函数和函数之间调用也是可以实现。一种是直接使用云API，一种是使用 API网关包装后的 API。云函数被触发调用的话，除了介绍的很多触发器，在不使用这些触发器的情况下，通过代码或者脚本也可以通过腾讯云的云API调用。Q：在事件触发的时候，就是CMQ事件触发的时候，是否可以保证函数被执行呢？因为不像API网关，调用一下函数可以启动，前端可以感知到。但是CMQ，就是扔到消息队列能否保证这个函数被执行呢？A：因为不像API网关是同步调用。同步调用就是这个调用在运行过程中如果出了问题，无论是平台，比如说资源不足，并发不够，或者比如使用的超时了，这个时候可以立刻感知到。 而像CMQ或者CKafka都是异步的，这样意味着调用后你感知不到，这个消息什么时候执行，执行结果都没法感知。这种解决方法有两种：一种是函数运行后的结果输出，把消息处理后的输出结果再放到另一个消息队列中去，让你外部的业务系统能够感知到。当然这种对外通知也是异步通知。同步通知是另外一种，就是函数里可以对自身业务进行回调API，可以通过代码知道现在的数据处理是什么样的结果，处理完后可以立刻回调到API让业务系统接收到处理结果。Q：像COS触发，拿视频转码来说，这个有可能在300秒内处理不完。现在函数设置时间只能最高300秒，这个有什么解决方案吗？A：为什么各家的云平台，都把这个时间大致定在这个范围内，就是不希望在云函数中进行太重的计算。视频转码就属于太重的计算，而云函数提供的包括CPU能力，内存大小都有限，实际上都不太适合在云函数内进行转码。实际上可以用一些视频服务来实现转码，使用云函数来做这两者之间的桥梁，例如对象存储的事件触发后，云函数拿到这个事件通过调用视频转码服务来转码，而不是在云函数转码。目前腾讯云有这个服务，你可以试试看。获取更多详细资料，请戳以下链接：Serverless 架构.pdf问答 serverless：如何删除一个函数？相关阅读 让业务感知不到服务器的存在——基于弹性计算的无服务器化实践 使用 SCF 无服务器云函数定时备份数据库 云学院 · 课程推荐 | 腾讯专项技术测试组长，结合8年经验为你细说冷热分离法则