云栖号_高分内容_个人页_阿里云开发者社区

发表了文章 2020-03-26

Alibaba Cloud Linux 2 LTS 正式发布，提供更高性能和更多保障！

在Alibaba Cloud Linux 2（原Aliyun Linux 2）上线一年之际，阿里云对外正式发布Alibaba Cloud Linux 2 LTS版本。LTS版本的发布对于>Alibaba Cloud Linux 2来说是一个重要的里程碑，标致着阿里云将为Alibaba Cloud Linux 2提供长期支持、稳定的更新、更好的服务，为>Alibaba Cloud Linux 2的客户提供更多保障。 Alibaba Cloud Linux 2 LTS版本发布后，阿里云将会为该版本提供长达5年的软件维护、问题修复服务。从2019-03-27开始到2024-03-31结束。包括：免费的服务和支持：Alibaba Cloud Linux 2的客户可以通过阿里云工单系统、钉钉或者社区等途径来寻求阿里云的免费支持服务。软件持续更新和集成：长达五年的维护周期，持续更新和集成软件，保证至少每4个月一次的更新节奏。问题&CVE修复：提供急速的问题和CVE修复支持本次发布的LTS版本更专注于性能的和稳定性的提升，包括：启动优化：对OS启动全流程做了优化，在原来Alibaba Cloud Linux 2的基础上启动性能再次优化40%，相比于其他OS启动时间减少60%；运行时优化：通过对调度、内存、文件系统等多个子系统进行了全方面的优化，使Alibaba Cloud Linux 2在多种benchmark的测试下相比其他OS有10%~30%的性能提升；稳定性提升：阿里云在对Alibaba Cloud Linux 2进行多方面的质量保障，并且经过阿里经济体应用的规模验证，及时发现问题并解决，保证了线上宕机率相比其他OS减少50%；在提升性能和稳定性的同时，该版本还为用户提供了更多、更丰富的功能，包括：多架构支持：全面支持X86 CPU包括：INTEL CooperLake、IceLake；AMD Milan、Rome；HYGON。同时支持多款ARM CPU：Kunpeng、PHYTUIM；资源隔离特性增强:Alibaba Cloud Linux 2在kernel本身就具备的namespace隔离能力的基础上，为容器混合部署场景提供更多的资源隔离手段，提升容器间的隔离性，保证了容器中应用的稳定性。丰富的应用软件：Alibaba Cloud Linux 2在集成了大量丰富的开源软件生态的同时，也将更多优秀的阿里巴巴经济体开源软件向客户开放，包括dragonwell、tengine、dragonfly等。客户的数据安全是阿里云的生命线，安全防护一直是阿里云非常重视的技术，之前Alibaba Cloud Linux 2发布了中国首个CIS benchmark，而本次Alibaba Cloud Linux 2 LTS也发布了多个安全功能，包括：自动修复方案 & 安全告警中心：1、Alibaba Cloud Linux 2 LTS为用户提供了自动CVE修复方案，只需要进行简单的配置即可为用户无感知的完成CVE安全漏洞的修复，极大的提升了系统的安全修复能力； 2、同时Alibaba Cloud Linux 2也发布了自己的安全告警中心，为用户提供CVE安全漏洞的跟踪、修复、记录。可信解决方案：Alibaba Cloud Linux 2 LTS还为用户提供了一套安全解决方案，为系统完整性提供安全基线并且能对非法篡改行为溯源，该方案通过组合了TPM2、IMA、内核模块签名等多种安全特性，实现了从芯片到关键应用的安全可信，可以提升系统整体的完全性防护能力。 Linux操作系统是一个非常庞大而复杂的开源系统，整个系统的持续演进不仅仅需要专业的团队进行维护，也希望有更多的企业、个人和社区一起参与共建，帮助操作系统更好的服务更多的人，欢迎更多的朋友来使用Alibaba Cloud Linux 2 LTS，为我们发现问题、反馈问题、解决问题，一起将Alibaba Cloud Linux 2 LTS做的更好。可以通过如下方式联系我们：产品页：https://www.aliyun.com/product/alinux GitHub地址：https://alibaba.github.io/cloud-kernel/zh/os.html 邮件列表：https://alibaba.github.io/cloud-kernel/zh/MAILLIST.html 钉钉群：Alibaba Cloud Linux OS 开发者&用户群钉钉群二维码：

发表了文章 2020-03-16

开发者七问七答：什么是产品化？

阿里妹导读：之前参加了企业智能部门如何做产品化的讨论，大家对产品化的定义和过程都有各自不同的见解。我觉得这个话题其实可以扩展下，想站在一>个开发人员的视角尝试探讨一下产品化。下面以自问自答的方式来展开。 1、当我们在谈产品化时，我们想的是同一个概念吗？为了更好地理解这个问题，首先要解释“系统、产品、商品”的定义。我不太想用百科上的通用定义，如：商品是用于交换的劳动产品，这对我们今天的话题没有指导意义，我尝试用更贴近我们日常工作上下文的方式来给出定义。系统的定义：各种离散功能组成的功能集合体。产品的定义：有使用价值且封装良好的可复用功能集合体。商品的定义：以交易为目的的，有使用价值且封装良好的可复用功能集合体。举个例子：我用各种零件制作了一个计时系统，具有计时的功能。给身边的小伙伴使用没问题，但拿到市场上去，就会被吐槽的体无完肤，“太丑了，感觉好复杂”。所以我奋发图强，给这个计时系统加上了好看的表盘和表带，封装成一个颜值高，易操作的产品。看上去专业多了，然后拿到市场上去，就会有人来询盘，多少钱啊老板？于是我给这个产品定了个价格，就成了一个商品。由此可见，系统可以转化为产品，产品也可以转化为商品。系统转化为产品的过程就是产品化。产品转化为商品的过程就是商业化。从系统到产品再到商品，是复杂性逐渐降低，体验逐渐提升的过程。 2、我们开发人员天天做的东西，是不是产品？我觉得大部分内部系统开发团队做的都是介于系统和产品之间的一种形态。很难将我们现在手头上的几个应用称之为产品。如果一个应用只能在一个特定场景给一个特定客户使用，这是一个系统，并不是一个产品。产品应该是能快速复制给多个客户使用的。比如：法务、采购、HRM、财务，等用于公司内部运营的应用。可以说是业务能力的集合体，一般满足内部运营都没什么问题。但拿到外面的市场上去绕一圈，晒一晒，不一定有竞争力。更不必说这些系统耦合了很多公司内部的特殊逻辑，依赖了内部的组件，牵一发而动全身，很难直接复制出去给另一个公司使用。所以，公司内的很多系统，为了成为真正的“产品”，纷纷开始做产品化的改造。比如，公司内部项目协作管理平台AONE是很好用的一个系统，但不能说是一个成熟可复制的产品，因此AONE经过产品化的改造，有了云上版本“云效”。 HSF是很好的技术中间件，在公司内部使用广泛，但拿到云上售卖还是得经过产品化封装为EDAS产品。 3、什么团队需要做产品化？如果你觉得你做了几年的系统，积累了较多有价值的业务能力，在行业里也有竞争力，自信除了现有的使用者，还愿意且有能力服务更多客户的话。你就需要考虑下产品化的事情了。例子：X产品本来是公司内部使用的办公协作系统，如今产品化向市场开放。 4、开发团队希望将维护的系统产品化，该怎么做？我手上维护的BUC、SSO、ACL、VDS，这些都是集团内使用广泛的系统。最近一直在做这些系统的产品化，封装成一个产品叫做MOZI（墨子），两年来，目前这个产品已经服务了集团经济体生态20多个BU的200多个业务；同时作为基础能力输出到数字政府领域，已经在多个业务领域证明了产品价值。我从我们自己产品化的经验来讲，如果手头已经有个系统，在这个基础上想做产品化的话，比较粗略的分，开发团队做产品化具体可以分为以下几个步骤： 1）产品能力的积累和建设； 2）低成本的可快速复制； 3）优化用户体验。产品能力的积累和建设比较容易理解，我们需要提升产品的使用价值，使用价值是客户来衡量的。对标业界竞品，有差距的补全差距，有优势的巩固优势。这个过程是持续改进的。低成本的可快速复制产品要有能力快速服务不止一家客户，这里客户使用方式分为saas方式和专有化交付方式，saas方式就必须要支持多租户的能力，专有化交付方式的话，就需要尽可能的降低产品交付的成本，包括需要占用的服务器数量，依赖的三方软件等。去掉不必要的功能，提供最小模块功能集，最好可以让客户自定义功能集，仅对使用的功能付费。优化用户体验这个没啥说的，现在这个时代，颜值就是正义，"dont make me think"。优化视觉，优化交互，优化体验这三件事情要持续打磨。 5、产品化需要多少投入？产品化是个持续改进，无限接近完美的过程，而不是一蹴而就，从0到1的变化。技术部做了个A工单系统，给公司内部的客服人员使用。虽然界面很丑，bug一堆，但独此一家，别无分店，客服只能一边嫌弃着一边继续用。另一个技术部也做了个B工单系统，在产品质量和用户体验上深度打磨，推出以后，口碑越来越好，用户越来越多，大量客服纷纷弃前者而来。从用户视角看，B工单系统的使用价值比A工单系统高。换句话说，B工单系统的产品化程度比较高。B比A更像产品。如下图所示，B比A的产品化成熟度更高。但须知“文无第一，武无第二“，B也没法知道自己的优势能保留多久，也许马上会有其他产品化程度更高的C产品出现。为了保持领先，不得不持续更新自己的产品功能和体验。 6、产品化的建议路径是什么？当然完整的产品化路径并不仅仅是开发的事情，而是PD、UED、运营、开发、交付、商业一起参与的大工程。我尝试梳理了下从0到1做产品化的一般路径，不一定对，以后可能还会补充和删减。 1）定义客户和用户，给出客户画像； 2）定义客户需求痛点以及产品主要解决的问题； 3）定义产品核心功能和护城河； 4）明确价值和市场定位； 5）建设产品能力：面向客户； 6）建设配置能力：面向交付； 7）建设开发工具：面向开发（插件生态，小程序生态）； 8）降低成本，快速可复制； 9）优化和打磨用户体验； 10）定义商业模式和盈利模式（可选）； 11）定义计费方案（可选）； 12）建设标杆应用（对于平台类产品适用，如宜搭）； 13）联合行业领袖建立标准（头部玩家适用，如office）。 7、终极问题：如何做一个优秀的互联网产品？既然是终极问题了，我没法给出标准答案了，欢迎大家在留言区互动、探讨。

发表了文章 2020-03-13

性能提升2.58倍！阿里最快KV存储引擎揭秘

阿里妹导读：阿里云智能数据库Tair团队主要负责自研分布式键值存储(KVS)系统，几乎涵盖了淘宝、天猫、阿里妈妈、菜鸟、钉钉、优酷、高德等阿里巴巴所有核心业务。十多年来，始终如一为阿里业务提供着高可靠、高性能、低成本的数据存储与访问服务。 01 概述近日，Tair团队的一篇论文——HotRing: A Hotspot-Aware In-Memory Key-Value Store 被FAST'20 Research Track接收 (USENIX Conference on File and Storage Techniques (FAST)，CCF A类会议，存储领域顶会，2020年接受率16%)。 HotRing是Tair团队的创新性纯内存KV存储引擎设计。其引擎吞吐性能可达600M ops/s，与目前最快的KVS系统相比，可实现2.58倍的性能提升。HotRing最重要的创新点是：极大的提升了KVS引擎对于热点访问的承载能力。这对于KVS系统的稳定性以及成本控制尤为关键。为了方便大家更通俗全面的理解这篇论文，本文将从阿里巴巴的双十一零点峰值讲起，介绍峰值下数据库整体架构所面临的热点问题，再介绍Tair团队在解决热点方面一次次的优化提升，最后介绍Tair的创新性引擎HotRing。 02 背景零点峰值 2019年天猫双11再次刷新世界纪录，零点的订单峰值达到54.4万笔/秒。有订单就涉及到交易，有交易就需要数据库的事务保证，因此阿里巴巴数据库将在这时面临巨大的冲击。现实往往更加严峻，在业务方面，一次订单随着业务逻辑在后端会放大为数十次的访问；在客户方面，大量的客户只是疯狂的访问，并没有生成订单。因此，在双11的零点峰值，业务实际的访问量级是10亿次/秒。 Tair作为高并发分布式的KVS系统，在这时发挥了重要作用。如下面的逻辑图所示，Tair作为数据库的分布式缓存系统，缓存了大量的热点数据(例如商品，库存，风控信息等)，为数据库抵挡了巨大的访问量。2019年双11，Tair的峰值访问为9.92亿次/秒。热点问题在业务层面，热点问题很好理解，最典型的就是双十一零点秒杀。这会导致数据访问呈现严重倾斜的幂律分布。我们分析了多种业务的数据访问分布，如下图所示，大量的数据访问只集中在少部分的热点数据中，若用离散幂率分布(Zipfian)刻画，其θ参数约为1.22。相似地，Facebook的一篇论文同样也展示了近似的数据访问分布(参考论文[3])。直观上可以用下图来解释。以苹果新手机发售举例。手机的库存等信息只存在KVS的一个节点中。当新手机发售后，大量的果粉疯狂进行抢购下单，业务的访问量基本都聚集在这一个节点上。节点可能无法承载大量的热点访问，进而引发系统崩溃，严重影响用户体验。 **热点优化**为了保证双十一丝般顺滑的购物体验，Tair针对热点问题进行了多层优化：客户端缓存：通过预先标记热点，设置客户端层面的缓存。以上图来理解，就是将访问在业务层面返回，直接减小了KVS系统的负载压力。热点散列技术：通过将热点数据备份到多个KVS节点上，分摊热点访问。以少量成本的资源与系统开销，换取了成倍的系统承载力。 RCU无锁引擎：通过采用Read-Copy-Update的方式，实现内存KV引擎的无锁化(lock-free)访问(参考论文[1,2])。成倍提升KVS引擎的性能，进而提高热点的承载力。 HotRing：在RCU无锁引擎基础上，我们进行索引结构的热点感知设计，提出了一种名为HotRing的新型热点感知内存KVS。HotRing可动态识别热点，并实时的进行索引结构的无锁调整，对于幂律分布场景实现成倍的引擎性能提升。经过十年的技术沉淀，我们已将集团Tair数据库的缓存技术释放到云上，普惠大众，即“阿里云Redis企业版”。 03 HotRing 现有技术现有的内存KVS引擎通常采用链式哈希作为索引，结构如下图所示。首先，根据数据的键值(k)计算其哈希值h(k)，对应到哈希表(Hash table)的某个头指针(Headi)。根据头指针遍历相应的冲突链(Collision Chain)的所有数据(Item)，通过键值比较，找到目标数据。如果目标数据不在冲突链中(read miss)，则可在冲突链头部插入该数据。在链式哈希索引结构中，访问位于冲突链尾部的数据，需要经过更多的索引跳数，即更多次的内存访问。很直观的想法是，如果可以将热点数据放置在冲突链头部，那么系统对于热点数据的访问将会有更快的响应速度。但是，数据在冲突链中的位置由数据的插入顺序决定，这和数据的冷热程度是互相独立的。因此，如图所示，热点数据(Hot Item)在冲突链中的位置是完全均匀分布。设计挑战理想的设计也很直观，就是将所有热点数据移动到冲突链的头部。但有两方面因素使得这个问题非常难解。一方面，数据的热度是动态变化的，必须实现动态的热点感知保证热点时效性。另一方面，内存KVS的引擎性能是很敏感的(一次访问的时延通常是100ns量级)，必须实现无锁的热点感知维持引擎的高并发与高吞吐特性。 HotRing整体设计 HotRing在传统链式哈希索引基础上，实现了有序环式哈希索引设计。如下图所示，将冲突链首尾连接形式冲突环，保证头指针指向任何一个item都可以遍历环上所有数据。然后，HotRing通过lock-free移动头指针，动态指向热度较高的item（或根据算法计算出的最优item位置），使得访问热点数据可以更快的返回。下面通过如下4方面进行介绍：设计1：为什么要实现为有序环？设计2：如何动态识别热点并调整头指针？设计3：如何保证无锁的并发访问？设计4：如何根据热点数据量的动态变化进行无锁rehash？设计1——有序环实现环式哈希索引后，第一个问题是要保证查询的正确性。若为无序环，当一个read miss操作遍历冲突环时，它需要一个标志来判断遍历何时终止，否则会形式死循环。但是在环上，所有数据都会动态变化(更新或删除)，头指针同样也会动态移动，没有标志可以作为遍历的终止判断。利用key排序可以解决这个问题，若目标key介于连续两个item的key之间，说明为read miss操作，即可终止返回。由于实际系统中，数据key的大小通常为10~100B，比较会带来巨大的开销。哈希结构利用tag来减少key的比较开销。如下图所示，tag是哈希值的一部分，每个key计算的哈希值，前k位用来哈希表的定位，后n-k位作为冲突链中进一步区分key的标志。为了减小排序开销，我们构建字典序：order = (tag, key)。先根据tag进行排序，tag相同再根据key进行排序。下图比较了HotRing与传统链式哈希。以itemB举例，链式哈希需要遍历所有数据才能返回read miss。而HotRing在访问itemA与C后，即可确认B read miss。因此针对read miss操作，链式哈希需要遍历整个冲突链；而HotRing利用字典序，不仅可以正确终止，且平均只需遍历1/2冲突环。设计2——动态识别与调整 HotRing实现了两种策略来实现周期性的热点识别与调整。每R次访问为一个周期(R通常设置为5)，第R次访问的线程将进行头指针的调整。两种策略如下：随机移动策略：每R次访问，移动头指针指向第R次访问的item。若已经指向该item，则头指针不移动。该策略的优势是，不需要额外的元数据开销，且不需要采样过程，响应速度极快。采样分析策略：每R次访问，尝试启动对应冲突环的采样，统计item的访问频率。若第R次访问的item已经是头指针指向的item，则不启动采样。采样所需的元数据结构如下图所示，分别在头指针处设置Total Counter，记录该环的访问总次数，每个item设置Counter记录该item的访问次数。因为内存指针需要分配64bits，但实际系统地址索引只使用其中的48bits。我们使用剩余16bits设置标志位(例如Total Counter、Counter等)，保证不会增加额外的元数据开销。该策略的优势是，通过采样分析，可以计算选出最优的头指针位置，稳态时性能表现更优。这一部分的细节设计有很多：采样分析策略如何选出最优位置；针对RCU更新操作的采样优化，热点继承防止冷启动。本文不再详细描述，有兴趣请参考HotRing论文。设计3——无锁并发访问 Tair的RCU无锁引擎是HotRing的设计基础。参考论文[1,2]对如何实现无锁链表进行了详细讲解，后续的所有无锁设计基本都沿用了他们的策略。有兴趣可以读一下。这里我们举一个典型的并发示例进行介绍。如下图所示，在链A->B->D上，线程1进行插入C的操作，同时线程2进行RCU更新B的操作，尝试更新为B'。线程1修改B的指针指向C，完成插入。而线程2修改A的指针指向B'完成更新。两个线程并发修改不同的内存，均可成功返回。但是这时遍历整条链(A->B'->D)，将发现C无法被遍历到，导致正确性问题。解决措施是利用上图(Item Format)中的Occupied标志位。当线程2更新B时，首先需要将B的Occupied标志位置位。线程1插入C需要修改B的指针(Next Item Address)，若发现Occupied标志位已置位，则需要重新遍历链表，尝试插入。通过使并发操作竞争修改同一内存地址，保证并发操作的正确性。利用相同原理，我们保证了头指针移动操作，与CRUD操作的并发正确性。因此实现了HotRing的无锁并发访问。设计4——适应热点数据量的无锁rehash 如背景所述，对于极端的幂率分布场景，大量的数据访问只集中在少部分的热点数据中。因此只要保证热点数据可以位于头指针位置，冲突环即使很长，对于引擎的性能表现并不影响。引擎性能的降低，必然是因为冲突环上存在多个热点。因此HotRing设计了适应热点数据量的无锁rehash策略来解决这一问题。 HotRing利用访问所需平均内存访问次数(access overhead)来替代传统rehash策略的负载因子(load factor)。在幂率分布场景，若每个冲突环只有一个热点，HotRing可以保证access overhead < 2，即平均每次访问所需内存访问次数小于2。因此设定access overhead阈值为2，当大于2时，触发rehash。 rehash过程分为3步进行，结合上面4图进行说明，图一为哈希表，哈希值在rehash前后的变化。剩余三图为rehash三个过程。初始化(Initialization)：首先，HotRing创建一个后台rehash线程。该线程创建2倍空间的新哈希表，通过复用tag的最高一位来进行索引。因此，新表中将会有两个头指针与旧表中的一个头指针对应。HotRing根据tag范围对数据进行划分。假设tag最大值为T，tag范围为[0,T)，则两个新的头指针对应tag范围为[0,T/2)和[T/2,T)。同时，rahash线程创建一个rehash节点(包含两个空数据的子item节点)，子item节点分别对应两个新头指针。HotRing利用item中的Rehash标志位识别rehash节点的子item节点。分裂(Split)：在分裂阶段，rehash线程通过将rehash节点的两个子item节点插入环中完成环的分裂。如图(Split)所示，因为itemB和E是tag的范围边界，所以子item节点分别插入到itemB和E之前。完成两个插入操作后，新哈希表将激活，所有的访问都将通过新哈希表进行访问。到目前为止，已经在逻辑上将冲突环一分为二。当我们查找数据时，最多只需要扫描一半的item。删除(Deletion)：删除阶段需要做一些首尾工作，包括旧哈希表的回收。以及rehash节点的删除回收。这里需要强调，分裂阶段和删除阶段间，必须有一个RCU静默期(transition period)。该静默期保证所有从旧哈希表进入的访问均已经返回。否则，直接回收旧哈希表可能导致并发错误。 04 总结内存键值存储系统由于高性能、易扩展等特性在云存储服务中广泛使用。其通常作为必不可少的缓存组件，以解决持久化存储系统或分布式存储系统中的热点问题。但分析发现，内存KVS内部的热点问题更加严重，其数据访问分布同样服从幂律分布，且访问倾斜愈加严重。现有的内存KVS缺乏热点优化意识，部分数据节点可能无法承载大量的热点访问，进而引发系统崩溃，严重影响用户体验。在本论文中，我们进行索引结构的热点感知设计，提出了一种名为HotRing的新型热点感知内存KVS，针对幂率分布的热点场景进行大量优化。HotRing可动态识别热点，并实时的进行索引结构的无锁调整，进而提供高并发高性能的无锁化访问。与传统的内存KVS索引相比，HotRing采用轻量级的热点识别策略，且没有增加元数据存储开销。但在幂律分布的应用场景中，HotRing的引擎吞吐性能可达600M ops/s，与目前最快KVS相比，可实现2.58倍的性能提升。参考[1] John D Valois. Lock-free linked lists using compare-and-swap. (PODC 1995)[2] Timothy L Harris. A Pragmatic Implementation of Non-blocking Linked-lists. (DISC 2001)[3] Berk Atikoglu. Workload Analysis of a Large- Scale Key-Value Store. (SIGMETRICS 2012)

发表了文章 2020-03-12

如何解决分布式系统中的“幽灵复现”？

阿里妹导读： “幽灵复现”的问题本质属于分布式系统的“第三态”问题，即在网络系统里面，对于一个请求都有三种返回结果：成功，失败，超时未知。对于超>时未知，服务端对请求命令的处理结果可以是成功或者失败，但必须是两者中之一，不能出现前后不一致情况。 1、“幽灵复现”问题我们知道，当前业界有很多分布式一致性复制协议，比如Paxos，Raft，Zab及Paxos的变种协议，被广泛用于实现高可用的数据一致性。Paxos组通常有3或5个互为冗余的节点组成，它允许在少数派节点发生停机故障的情况下，依然能继续提供服务，并且保证数据一致性。作为一种优化，协议一般会在节点之间选举出一个Leader专门负责发起Proposal，Leader的存在，避免了常态下并行提议的干扰，这对于提高Proposal处理的效率有很大提升。但是考虑在一些极端异常，比如网络隔离，机器故障等情况下，Leader可能会经过多次切换和数据恢复，使用Paxos协议处理日志的备份与恢复时，可以保证确认形成多数派的日志不丢失，但是无法避免一种被称为“幽灵复现”的现象。考虑下面一种情况：如上表所示，在第一轮中，A成为指定Leader，发出1-10的日志，不过后面的6-10没有形成多数派，随机宕机。随后，第二轮中，B成为指定Leader，继续发出6-20的日志（B没有看到有6-10日志的存在），这次，6以及20两条日志形成了多数派。随机再次发生切换，A回来了，从多数派拿到的最大LogId为20，因此决定补空洞，事实上，这次很大可能性是要从6开始，一直验证到20。我们逐个看下会发生什么：针对Index 6的日志，A重新走一轮basic paxos就会发现更大proposeid形成决议的6，从而放弃本地的日志6，接受已经多数派认可的日志；针对Index 7到Index 10，因为多数派没有形成有效落盘，因此A随机以本地日志发起提议并形成多数派；针对Index 11到Index 19，因为均没有形成有效落盘数据，因此，以noop形成补空洞；针对Index 20，这个最简单，接受已经多数派认可的日志；在上面的四类情况分析中，1，3，4的问题不大。主要在场景2，相当于在第二轮并不存在的7~10，然后在第三列又重新出现了。按照Oceanbase的说法，在数据库日志同步场景的情况，这个问题是不可接受的，一个简单的例子就是转账场景，用户转账时如果返回结果超时，那么往往会查询一下转账是否成功，来决定是否重试一下。如果第一次查询转账结果时，发现未生效而重试，而转账事务日志作为幽灵复现日志重新出现的话，就造成了用户重复转账。 2、基于 Multi-Paxos 解决“幽灵复现”问题为了处理“幽灵复现”问题，基于Multi-Paxos实现的一致性系统，可以在每条日志内容保存一个epochID，指定Proposer在生成这条日志时以当前的ProposalID作为epochID。按logID顺序回放日志时，因为leader在开始服务之前一定会写一条StartWorking日志，所以如果出现epochID相对前一条日志变小的情况，说明这是一条“幽灵复现”日志，要忽略掉这条日志（说明一下，我认这里顺序是先补空洞，然后写StartWorkingID，然后提供服务）。以上个例子来说明，在Round 3，A作为leader启动时，需要日志回放重确认，index 1~5 的日志不用说的，epochID为1，然后进入epochID为2阶段，index 6 会确认为epochID为2的StartWorking日志，然后就是index 7~10，因为这个是epochID为1的日志，比上一条日志epochID小，会被忽略掉。而Index 11~19的日志，EpochID应该是要沿袭自己作为Leader看到的上上一轮StartWorkingID（当然，ProposeID还是要维持在3的），或者因为是noop日志，可以特殊化处理，即这部分日志不参与epochID的大小比较。然后index 20日志也会被重新确认。最后，在index 21写入StartWorking日志，并且被大多数确认后，A作为leader开始接收请求。 3、基于Raft解决“幽灵复现”问题 3.1 关于Raft日志恢复首先，我们聊一下Raft的日志恢复，在 Raft 中，每次选举出来的Leader一定包含已经Committed的数据（抽屉原理，选举出来的Leader是多数中数据最新的，一定包含已经在多数节点上Commit的数据），新的Leader将会覆盖其他节点上不一致的数据。虽然新选举出来的Leader一定包括上一个Term的Leader已经Committed的Log Entry，但是可能也包含上一个Term的Leader未Committed的Log Entry。这部分Log Entry需要转变为Committed，相对比较麻烦，需要考虑Leader多次切换且未完成Log Recovery，需要保证最终提案是一致的，确定的，不然就会产生所谓的幽灵复现问题。因此，Raft中增加了一个约束：对于之前Term的未Committed数据，修复到多数节点，且在新的Term下至少有一条新的Log Entry被复制或修复到多数节点之后，才能认为之前未Committed的Log Entry转为Committed。为了将上一个Term未Committed的Log Entry转为Committed，Raft 的解决方案如下： Raft算法要求Leader当选后立即追加一条Noop的特殊内部日志，并立即同步到其它节点，实现前面未Committed日志全部隐式提交。从而保证了两个事情：通过最大Commit原则保证不会丢数据，即是保证所有的已经Committed的Log Entry不会丢；保证不会读到未Committed的数据，因为只有Noop被大多数节点同意并提交了之后（这样可以连带往期日志一起同步），服务才会对外正常工作；Noop日志本身也是一个分界线，Noop之前的Log Entry被提交，之后的Log Entry将会被丢弃。 3.2 Raft解决“幽灵复现”问题针对第一小节的场景，Raft中是不会出现第三轮A当选leader的情况，首先对于选举，候选人对比的是最后一条日志的任期号(lastLogTerm)和日志的长度(lastLogIndex)。B、C的lastLogTerm（t2）和lastLogIndex（20）都比A的lastLogTerm（t1）和lastLogIndex（10）大，因此leader只能出现在B、C之内。假设C成为leader后，Leader运行过程中会进行副本的修复，对于A来说，就是从log index为6的位置开始，C将会把自己的index为6及以后的log entry复制给A，因此A原来的index 6-10的日志删除，并保持与C一致。最后C会向follower发送noop的log entry，如果被大多数都接收提交后，才开始正常工作，因此不会出现index 7-10能读到值的情况。这里考虑另一个更通用的幽灵复现场景。考虑存在以下日志场景： 1）Round 1，A节点为leader，Log entry 5，6内容还没有commit，A节点发生宕机。这个时候client 是查询不到 Log entry 5，6里面的内容。 2）Round 2，B成为Leader, B中Log entry 3, 4内容复制到C中，并且在B为主的期间内没有写入任何内容。 3）Round 3，A 恢复并且B、C发生重启，A又重新选为leader, 那么Log entry 5, 6内容又被复制到B和C中，这个时候client再查询就查询到Log entry 5, 6 里面的内容了。 Raft里面加入了新Leader 必须写入一条当前Term的Log Entry 就可以解决这个问题, 其实和MultiPaxos提到的写入一个StartWorking 日志是一样的做法, 当B成为Leader后，会写入一个Term 3的noop日志，这里解决了上面所说的两个问题： Term 3的noop日志commit前，B的index 3，4的日志内容一定会先复制到C中，实现了最大commit原则，保证不会丢数据，已经 commit 的 log entry 不会丢。就算A节点恢复过来, 由于A的lastLogTerm比B和C都小，也无法成了Leader, 那么A中未完成的commit只是会被drop，所以后续的读也就不会读到Log Entry 5，6里面的内容。 **4、基于Zab解决“幽灵复现”问题**4.1 关于Zab的日志恢复 Zab在工作时分为原子广播和崩溃恢复两个阶段，原子广播工作过程也可以类比raft提交一次事务的过程。崩溃恢复又可以细分为Leader选举和数据同步两个阶段。早期的Zab协议选举出来的Leader满足下面的条件： a) 新选举的Leader节点含有本轮次所有竞选者最大的zxid，也可以简单认为Leader拥有最新数据。该保证最大程度确保Leader具有最新数据。 b) 竞选Leader过程中进行比较的zxid，是基于每个竞选者已经commited的数据生成。 zxid是64位高32位是epoch编号，每经过一次Leader选举产生一个新的leader，新的leader会将epoch号+1，低32位是消息计数器，每接收到一条消息这个值+1，新leader选举后这个值重置为0。这样设计的好处在于老的leader挂了以后重启，它不会被选举为leader，因此此时它的zxid肯定小于当前新的leader。当老的leader作为follower接入新的leader后，新的leader会让它将所有的拥有旧的epoch号的未被commit的proposal清除。选举出leader后，进入日志恢复阶段，会根据每个Follower节点发送过来各自的zxid，决定给每个Follower发送哪些数据，让Follower去追平数据，从而满足最大commit原则，保证已commit的数据都会复制给Follower，每个Follower追平数据后均会给Leader进行ACK，当Leader收到过半Follower的ACK后，此时Leader开始工作，整个zab协议也就可以进入原子广播阶段。 4.2 Zab解决“幽灵复现”问题对于第 1 节的场景，根据ZAB的选举阶段的机制保证，每次选举后epoch均会+1，并作为下一轮次zxid的最高32位。所以，假设Round 1阶段，A,B,C的EpochId是1，那么接下来的在Round 2阶段，EpochId为2，所有基于这个Epoch产生的zxid一定大于A上所有的zxid。于是，在Round 3，由于B, C的zxid均大于A，所以A是不会被选为Leader的。A作为Follower加入后，其上的数据会被新Leader上的数据覆盖掉。可见，对于情况一，zab是可以避免的。对于 3.2 节的场景，在Round 2，B选为leader后，并未产生任何事务。在Round 3选举，由于A,B,C的最新日志没变，所以A的最后一条日志zxid比B和C的大，因此A会选为leader，A将数据复制给B,C后，就会出现”幽灵复现“现象的。为了解决“幽灵复现”问题，最新Zab协议中，每次leader选举完成后，都会保存一个本地文件，用来记录当前EpochId（记为CurrentEpoch），在选举时，会先读取CurrentEpoch并加入到选票中，发送给其他候选人，候选人如果发现CurrentEpoch比自己的小，就会忽略此选票，如果发现CurrentEpoch比自己的大，就会选择此选票，如果相等则比较zxid。因此，对于此问题，Round 1中，A,B,C的CurrentEpoch为2；Round 2，A的CurrentEpoch为2，B,C的CurrentEpoch为3；Round 3，由于B,C的CurrentEpoch比A的大，所以A无法成为leader。 5、进一步探讨在阿里云的女娲一致性系统里面，做法也是类似于Raft与Zab，确保能够制造幽灵复现的角色无法在新的一轮选举为leader，从而避免幽灵日志再次出现。从服务端来看“幽灵复现”问题，就是在failover情况下，新的leader不清楚当前的committed index，也就是分不清log entry是committed状态还是未committed状态，所以需要通过一定的日志恢复手段，保证已经提交的日志不会被丢掉（最大 commit 原则），并且通过一个分界线（如MultiPaxos的StartWorking，Raft的noop，Zab的CurrentEpoch）来决定日志将会被commit还是被drop，从而避免模糊不一的状态。“幽灵复现”的问题本质属于分布式系统的“第三态”问题，即在网络系统里面, 对于一个请求都有三种返回结果：成功，失败，超时未知。对于超时未知，服务端对请求命令的处理结果可以是成功或者失败，但必须是两者中之一，不能出现前后不一致情况。在客户端中，请求收到超时，那么客户端是不知道当前底层是处于什么状况的，成功或失败都不清楚，所以一般客户端的做法是重试，那么底层apply的业务逻辑需要保证幂等性，不然重试会导致数据不一致。参考文章： In Search of an Understandable Consensus Algorithm - Diego Ongaro and John Ousterhouthttps://raft.github.io/raft.pdf?spm=ata.13261165.0.0.337d6f55qtohyc&file=raft.pdf Paxos Made Simple – Leslie Lamporthttps://lamport.azurewebsites.net/pubs/paxos-simple.pdf?spm=ata.13261165.0.0.337d6f55qtohyc&file=paxos-simple.pdf Oceanbase列传 – 郁白http://oceanbase.org.cn/?spm=ata.13261165.0.0.337d6f55qtohyc&p=111 关于Paxos "幽灵复现"问题看法 – 陈宗志https://zhuanlan.zhihu.com/p/40175038?spm=ata.13261165.0.0.337d6f55qtohyc zookeeper原理解析 https://www.cnblogs.com/wxd0108/p/6251729.html?spm=ata.13261165.0.0.337d6f55qtohyc

发表了文章 2020-03-11

1分钟出票5万张！阿里电影节抢票技术揭秘

阿里妹导读：对于电影爱好者来说，每次的电影节、影展活动，都是抢票大战的开启，出票速度几乎可以用“秒空”来形容，例如上海国际电影节线上开售的记录是1分钟售出5万张。今天，阿里高级开发工程师念贤主要围绕售票环节，讲述阿里文娱的云智系统是如何支撑高流量并发，保障系统的稳定，不出现重卖等实现方>案背后的技术。一、背景介绍先简单分析一下电影节的抢票业务，典型特征是在大流量抢购、高并发的场景下，让用户极快的锁定座位然后出票，特别是热门的影片，会异常的火爆。第一道压力是查询已售座位列表和锁座，需要能快速的支撑用户的锁座请求，且实时查询到已售卖的座位列表，避免发起无效的锁座请求；第二道压力是出票，如果锁座成功，但一直出票失败，会给用户带来很不好的体验。二、架构设计思考的方向 1．让业务赢在分层设计上，分成渠道接入层、业务层和服务层。在业务层，对外业务和管理后台功能独立，职责清晰，快速支撑业务；服务层沉淀基础服务，构成稳定的业务和基础服务。 2．让系统稳定在架构设计上，接入统一网关让系统安全，有限流，对库存中心和订单中心进行数据隔离，且加入多级缓存方案，让系统稳定。三、实现方案与技术解析 1．高并发流量如何抗？电影节的流量是非常典型的秒杀场景，瞬时流量非常高，对于系统的高性能要求就注定很高，在云智中，我们是如何抗高并发流量的？我们通过以下三点来进行阐述：热点数据隔离、流量削峰漏斗、多级缓存。 1）热点数据隔离在热点隔离这块，云智选择的策略包括：数据隔离和业务隔离。数据隔离：是把查询已售卖座位和已锁定座位等库存相关的热点数据，隔离出来，单独业务数据库，且使用分库分表，减少系统性能压力，提高吞吐量。业务隔离：电影节的业务数据，独立的业务数据生成能力，圈定参与活动的业务数据，进行缓存预热，起到隔离的效果。 2）流量削峰漏斗关键词是“分层削峰”，漏斗式的减少请求流量，在业务链路的过程中，我们会进行业务校验，层层过滤，如用户的账号安全、购买资格，影院、影厅等基础信息状态是否正常，要购买的商品信息状态是否正常、秒杀是否已经结束等，每个层次都尽可能的过滤掉非法的请求，只在最后端处理真正有效的请求，最终减少请求到数据库DB的写操作流量，保证系统处理真正有效的请求。以锁座流程为例子： 3）多级缓存在分层漏斗的前提下，云智采用分布式缓存和本地缓存LocalCache多级缓存的方案来抵抗高并发流量，以下简要介绍一下在系统中使用的策略： a）缓存预热。在指定参加活动的场次后，会在限定时间内停止变更，在开售前，会自动进行预热缓存，避免激增流量击穿缓存； b）缓存失效时长控制，对基础数据实体的VO对象和DO对象采用失效时间长短的缓存控制，静态数据和DO实体使用长失效时长的策略：不失效或24H；动态数据和实体Info使用比较短的失效时长策略：分钟级，比如幂等性KEY的缓存时间为2min； c）本地缓存LocalCache使用的缓存时长策略分3种：2s，60s，122s。优先读本地的缓存，其次读远程分布式的缓存，使得系统可以抵抗瞬间的高并发流量。示例图如下所示：将缓存分2层结构：第一层是本地缓存结构：用户、权限、基础信息等静态数据，我们优先选择本地缓存；第二层是全量的缓存实体信息的DO和VO信息，这层采用的是Tair分布式缓存。 2．系统的稳定性、高可用性如何保证？对于任何档期或者活动，系统的稳定性都是第一要素，针对电影节的活动场景，我们使用了很多设计上的稳定性模式，其中比较核心的有：多轮全链路压测、限流、降级、动态扩容、流量调度、减少单点、依赖简化等方式；除了以上几点，本节我们重点聊一聊我们在电影节过程中是如何保障备战的？ 1）保障备战体系 a）在战前阶段这个阶段的工作会比较多，只有做到事前充分准备，才能有更好的保障结果，主要包括以下几个部分：（1）梳理薄弱点，包括系统架构、系统薄弱点、核心主流程，识别出来后制定应对策略；（2）全链路压测，对系统进行全链路压测，找出系统可以承载的最大QPS；（3）限流配置，为系统配置安全的、符合业务需求的限流阀值；（4）应急预案，收集各个域的可能风险点，制作应急处理方案；（5）安全保障，主要聚焦在账号权限管控，以最小够用原则为准，防止权限滥用，安全无小事；（6）战前演练，通过演练来检验保障体系是否完善，演练开票现场，提高团队响应和处理能力；（7）作战手册，制定作战手册，明确作战流程和关键点节点的任务以及沟通机制。 b）在战中阶段活动开售，我们也称为战中，整个项目组主要专注三件事情，即“监控““响应”和“记录”。项目组的同学都必须要保持作战状态，严格按照应用owner机制，负责巡检应用情况，及时同步技术数据和业务数据是否有异常。同时，在战中，我们临时组建“保障虚拟小组”，用于应对大促期间可能出现的紧急客诉等问题，及时做出决策，控制影响范围，同时也能提高整体作战能力。记录，是在战中过程中必须要记录下各应用的峰值，及时沉淀技术数据，为后续系统建设，流量评估等提供参考借鉴。 c）在战后阶段这个阶段的主要工作是项目复盘，复盘的内容主要包括：项目结果、项目回顾、项目沉淀和改进，将项目过程中收集到的问题和故障进行详细分析，并将项目过程中沉淀出来的，关于系统稳定性保障的经验沉淀到日常，让活动保障的常态化逐步落地。 2）最佳实践 a）精准监控通过监控，实时发现各个服务是否触发限流值，及时进行Review，调整限流值，保证业务成功率和系统稳定。对系统基础值班和业务量指标进行精准监控，如load，内存，PV，UV，错误量等，避免因内存泄露或代码的Bug对系统产生影响，精准监控，提前感知内存泄露等问题。 b）数据大盘通过数据大盘，实时汇总数据，展示业务数据，为系统、为业务提供更加直观的业务支持，也可以更加有效的进行业务备战。 3．如何保证不出现重卖？在业务过程中，我们实现了很多业务，解决了很多困难，我们重点阐述以下两个痛点，一个是恶意锁座，一个是防止超卖。 1）如何解决恶意锁座？首先我们采用的扣减库存方式是预扣库存，用户操作锁定座位时即锁定库存，那我们如何解决恶意锁座呢？ a）锁座订单中会生成一个“库存失效时间”，超过该时间，锁座订单会失效释放库存； b）限制用户购买数量，一人最多只能购买6张票； c）接入黄牛防控系统； 2）如何防止库存超卖？电影票不同于电商业务普通的标品，是不允许出现超卖的情况，否则会出现重票，从而引发客诉舆论问题，所以在库存数据一致性上，需要保障在高并发情况下不出现重票，我们的解决方案是： a）使用分布式缓存，在分布式缓存中预减库存，减少数据库访问； b）使用数据库唯一键，在锁座表中，设定场次Id和座位Id作为唯一键。锁定座位时，如果座位已经售卖，会报出数据库异常，不允许某一个座位重复售卖。四、总结回顾电影节抢票，我们首先想到的是能抗高并发流量，能让系统稳定。通过上述章节我们揭开了高性能、高可用等背后的技术，展示了一个典型抢票大战的技术方案，核心技术包括：让业务赢 = 完整的业务应用 + 支撑核心业务高性能、高可用 = 流量削峰 + 限流降级 + 多级缓存平台成熟化 = 完善的监控 + 保障方案在这个过程中，我们沿着让系统稳定、让业务赢的设计思想，不断的思考和落地这些技术细节，沉淀核心技术，以达到让用户体验流畅的抢票过程。

发表了文章 2020-03-10

新冠病毒药物研发分秒必争，阿里高性能计算如何出力？

阿里妹导读：新冠状病毒疫情发生后，为了帮助抗攻击疫情，阿里云免费向全球公共科研机构提供高性能计算、SCC超级计算集群和>CPU/GPU机器、云超算及AI等技术。近期，不少研究机构和高校在阿里云上E-HPC云超算上进行药物研发相关的数值计算，阿里云超算团队提供了技术支持与跟进。本文主要介绍药物筛选阶段，E-HPC云超算如何帮助研发人员实现大量小分子库的快速并发处理。同时，介绍全球健康药物研发中心GHDDI算>力和成果共享开放平台的阿里云解决方案。病毒、药物研发和高性能计算一款药物的诞生周期极其漫长，从最早的新药研发到上市，至少要经历10年。在疫情这般分秒必争的背景下，时间尤为珍贵。因此在本次过程中，许多科学家会尝试从已有的药物里面，找到能治疗新冠的药，免去了后续大量审批上市等步骤。化合物发现阶段，以往的方法是通过大量实验做筛选，发现可能适合的化合物。如今，科学家尝试通过机器模拟分子化合物与靶点的相互作用，从而筛选出可能有效的化合物做实验。在此过程中，高性能计算（HighPerformance Computing，简称HPC），常被称为“超算”，是现代药物研发必不可少的支持。云计算的兴起更是改变了科学家获取算力、享受超算服务的方式。比如阿里云E-HPC 云超算产品，能够让科学家自助在云上搭建高性能集群系统，满足药物研发人员对计算平台的需求。此外，云上算力规模庞大且灵活，科学家可以按需购买，而不用担心被算力规模限制了研发速度。那么，具体病毒、药物研发和高性能计算之间具体联系几何？我们将从从病毒如何在宿主复制扩散开始讲起，到药物抑制方法举例，最后给出高性能计算在药物研发的作用。病毒和药物研发病毒是由核酸分子（DNA或RNA）与蛋白质构成的非细胞形态，如下图烟草花叶病毒所示。因为是非细胞的，无法通过细胞分裂的方式来完成数量增长，它们通过进入宿主细胞并利用宿主细胞内的代谢工具来合成自身的拷贝，并完成病毒的组装[1]。冠状病毒（CoV）是一种是一组高度同源的，单链正译RNA病毒，其具有以上的病毒特征，可引起多种严重程度不同的呼吸道，肠道，肝脏和神经系统疾病，在过去的12年中出现的两种新型的，即严重的急性呼吸系统综合症（SARS-CoV）和中东呼吸系统综合症（MERS-CoV）[2]，以及目前肆掠的COVID-19都属于这种病毒。病毒进入宿主细胞后，病毒基因组完成复制、转录（除了正译RNA病毒外）以及病毒蛋白质合成，然后组装行成更多数目的病毒，其生命流程如下图所示（无包膜病毒简易示图）。利用药物干扰病毒复制过程，可以有效抑制病毒对机体的伤害。例如，病毒蛋白在合成过程中，需要蛋白酶的介入，如3cl蛋白酶和ProPL蛋白酶，抑制蛋白酶的功能就是抑制病毒的方法之一。蛋白酶上能够被其它物质（配体、药物）识别或结合的结构，被称为靶点(BiologicalTarget)。找到能够与病毒的蛋白酶合适的靶点结合的配体（小分子药物），通过药物的作用改变蛋白酶的立体结构，进而改变其功能，阻碍病毒蛋白合成，导致病毒无法复制，实现抑制病毒复制的效果。[3] 药物研发与高性能计算药物研发是一个非常复杂和非常耗时的过程，药物筛选只是流程前期一个环节。例如，之前提的寻找跟蛋白病毒酶结合的小分子，由于存在不同种类或研究机构的配体（小分子）库，配体（小分子）库数量巨大，每个配体库的配体数量成千上万，甚至更大，通过实验方式一一测试验证是不切合实际的。通过计算机数值模拟进行筛选，对不同配体的结合效果进行打分，筛选出打分高且结合模式合理的一些配体作为候选药物进行实验验证，能够有效加速药物的研究进程。由于配体库巨大，如果在有限时间完成筛选，也是一个巨大的挑战。例如，配体库有10,000个候选配体，每个配体平均处理时间为1.5个小时，总共需要15,000 个小时（625天）。因此，为在规定时间内算完，需要具备以下条件：拥有强大计算能力的计算平台；大容量存储，用于存放处理数据和计算结果；此外，为了保证筛选计算能够高效、顺利完成，还需要计算服务，包括：集群软件运行环境，保证在多机环境下软件运行，以及数据访问；能够支持多任务在多机环境下并发处理的并行方案。除计算平台外，药物筛选还需要高性能应用软件。药物筛选模拟计算包括Docking和分子动力学计算：Docking 耗时相对较小，常用于大量配体的初步筛选，主要软件有dock6、Autodock Vina、Glide 等；分子动力学模拟计算比较耗时，测试作用的时间变化，用于对Docking初选结果进一步分析，主要软件有Gromacs，Namd，Amber等，GPGPU加速效果一般比较明显。 E-HPC高通量药物筛选方案药物研发需要强大计算能力的高性能集群，如何获取这些计算资源和服务呢？伴随着云计算的兴起，从云上获取计算服务器服务成为一个新的途径，同时阿里云提供不同产品服务，如云超算产品E-HPC（Elastic High PerformanceComputing），集群共享文件系统NAS/CPFS，数据库等。其中E-HPC 云超算产品，能够让用户自助在云上搭建自己的高性能集群系统，配置高性能服务器和大容量存储，提供软件多节点运行和高通量任务处理解决方案，直接满足药物研发人员对计算平台的需求。 E-HPC云超算阿里云E-HPC云超算产品是云原生的高性能计算集群解决方案，将阿里云的计算产品（ECS/EGS/裸金属服务器/超级计算集群）、网络（VPC/RoCE）和存储（NAS/OSS/CPFS）等产品进行整合，配置高性能计算作业管理和账户管理，并集成常用的HPC应用软件，实现让用户在页面操作，获取自己的高性能计算集群，拥有root权限，对集群进行管理配置。除功能以外，性能上阿里云提供多种计算实例类型，提供各种计算能力（1vCPU、2vCPU、4vCPU … 104vCPU）、不同内存配比（1vCPU:2GB,1vCPU:4GB, 1vCPU: 8GB）的算例、或配有GPU或FPGA加速卡，CPU类型多为Intel 最新架构。其中，弹性裸金属服务器（ECS BareMetal Instance）是基于阿里云完全自主研发的下一代虚拟化技术而打造的新型计算类服务器产品，兼具虚拟机的弹性和物理机的性能及功能特性，释放整机的计算性能；裸金属服务器配有支持RMDA的RoCE高速网络，变成超级计算集群SCC (SuperComputing Cluster) 产品，满足大规模高并发的应用场景。 E-HPC高通量任务解决方案高性能计算环境提供基础的计算平台，要实现高效的药物筛选，还需要一种高通量任务解决方案。例如，使用DOCK6 处理配体（小分子）库的对接案例，在一个文件夹中，如mol2，存放大量的小分子文件，每个小分子处理流程是一样的，均需要跟相同的受体（如病毒蛋白酶）进行计算。如果使用串行的处理方式，代码如下图所示。其中，dock.in 为DOCK6命令的输入文件，并且需要根据小分子文件名修改相应的参数取值。这段代码遍历mol2文件夹下每个分子文件，对每个文件生成对应的dock.in输入文件，然后运行dock6命令进行处理。串行执行，时间长，无法利用高性能集群的计算能力，如何在集群上多节点、多核并发的处理，实现快速处理呢？实现方法也有多种，如手工的将mol2文件夹分成若干个子文件夹，每个文件夹分得少量的小分子文件，然后在每个子文件串行执行。这种方式需要过多的人工参与，尤其是在有任务出错，需要调整重新提交的场景，很容出现重算、漏算。 E-HPC 高通量任务定义和启动 E-HPC 提供了高通量任务解决方案。对于本案例，通过3个步骤就能够实现大量小分子文件的并发处理。将mol2文件下的分子文件名保存到一个文件文件，如molin。编写处理单个小分子文件的脚本 task.sh，小分子文件名用 $molin 代替，对比串行逻辑，可以看出是直接复制for循环内的处理代码。通过E-HPC 高通量任务处理命令 ehpcarr 提交task.sh运行，并返回作业号2[].manager。此时，任务已经使用96个CPU core进行并发处理了，如果节点包含CPU core数目少于96时，会自动分配到多个节点。例如，使用12 CPU core的实例，所有分子处理任务会在8个节点上运行。 E-HPC 高通量任务状态查询使用ehpcarr命令，根据作业号进行查询任务的并发执行情况。从查询结果可以得倒每个任务当前的处理状态，包括完成(DONE)、运行(RUNNING)、失败(FAILED)、排队(INIT)，每个任务处理的启示截止时间，通过对任务执行时间可以预估下次使用的计算资源。从查询结果可以看出： E-HPC 作业调度器启动了8个节点进行药物筛选处理；不同任务分配到不同的计算节点（0号任务分配到compute001，10520任务分配到compute008）；相同节点有不同的并发任务（0，111都在compute001并发处理）。 E-HPC 解决方案，是基于高性能集群作业调度器的数组作业，并进行了增强：限定任务的并发数量，避免1个任务1个作业引发集群大量排队作业，影响其它集群使用者作业的运行；能够实现任务的动态调度，充分利用计算资源。 GHDDI开放共享平台在新冠状病毒疫情下，资源和研究成果共享，能极大的加速研究者的进展，避免重复的工作。全球健康药物研发中心（GlobalHealth Drug Discovery Institute，简称“GHDDI”）是由比尔及梅琳达·盖茨基金会、清华大学和北京市政府共同创立和建设的一个独立运营、非营利性质的新型药物研发机构。 GHDDI在阿里云之上搭建了开放共享平台，使用E-HPC搭建高性能计算集群，用于药物研发的模拟计算，同时为合作伙伴创建不同的云超算子账户，实现计算资源共享。同时，为了将E-HPC云超算集群上的计算结果共享发布，将阿里云对象存储产品OSS直接挂载到E-HPC超算集群上，把需要发布的结果放到OSS上。此外，在云上新建一个ECS计算服务器，用于搭建web服务器[4]，将OSS访问链接放在web服务器上，供大家浏览、下载。总结药物研发需要强大计算能力的高性能计算集群，如药物筛选需要进行大量小分子的Docking处理。科学家可以利用阿里云E-HPC云超算产品，在云上快速构建高性能集群，获取高性能的计算实例，满足算力的需求。同时，E-HPC提供了高通量任务处理的解决方案，使得药物筛选在多计算节点、多核上并发处理，降低任务整体执行时间。此外，由于E-HPC是云原生的超算产品，因此能够跟其它云产品打通，如对象存储OSS，能够容易、快速搭建计算、信息发布平台。

发表了文章 2020-03-06

以斗鱼为例，揭秘企业大数据上云的挑战与变化

阿里妹导读：今天的文章来自斗鱼大数据高级专家张龙，本文讲述了从 Apache Hadoop 阶段到 Cloudera CDH 阶段斗鱼大数据架构的发展历程。提出了上云过程中斗鱼遇到的问题和挑战，包括数据安全、数据同步以及任务迁移。概括了混合云模式给斗鱼带来资源效率更高和资源成本更低的变化。斗鱼大数据架构发展历程在2014年中期，斗鱼就开始使用大数据，最开始使用的是简单的HBase和Hadoop。在2015年，开始使用CDH运维大数据集群，主要针对可视化运维。在2017年的下半年，斗鱼开始接触阿里云大数据的一些产品，并且与其他产品做了对比。最终选择了阿里云的MaxCompute。 Apache Hadoop阶段由于业务场景比较简单，组件较少，并且使用的人也少，但可以灵活的操作，同时集群规模较小，运维要求低，可以自由的利用开源，培养了许多人才。但在发展过程中也遇到了一些阻碍，例如：组件增多，运维成本高，业务增长快，集群扩容操作繁琐，人员增加，数据安全要求高，物理机操作，环境安全难保障。 Cloudera CDH阶段斗鱼为何选择Cloudera CDH？原因主要有：首先，它能满足业务发展需要，多组件运维成本低，集群扩容操作简单，数据安全及环境安全有保障。其次，CDH在国内被广泛使用。最主要的一点是斗鱼的团队内部有CDH人才。 Cloudera CDH给斗鱼带来了许多便利，包括支持丰富的组件，不用考虑兼容性，可以通过CM统一管理，进行Web化管理，同时支持中文。另外，支持安全管理，以及对Kerberos安全认证。自建集群遇到了发展瓶颈，涉及到资源效率问题和资源成本问题。资源效率问题包括资源预算审批慢、机器采购周期长以及机房部署效率低。资源成本问题包括机器资源成本高、机房成本高还不稳定以及闲时资源空置较多。大数据上云的挑战上云面临的挑战主要是如何保证数据安全，因为数据是企业核心的资源，安全性是非常关键的。其次是如何保持数据同步，是因为云上云下存在着海量数据。最后，因为云下存在大量的历史业务，那该如何将业务安全迁移到云上也是一个问题。如何保证数据安全？对于数据丢失的问题，阿里使用原始数据进行备份，这是很关键的。对于核心数据泄露问题，几率是很小的，因为泄露数据之后所要承担的风险远大于打败竞争对手所提供的收益。对于云环境面向外网，如何保证安全访问的问题，可以增加账号访问IP白名单及审计，设置公司内部才可访问。如何保持数据同步？由于每天会产生PB级历史数据和TB级数据增量。如何快速准确同步数据问题，可以使用数据同步工具，主要是基于DataX的改造。同时提高网络专线能力，增加多根专线，自动地进行异常切换，与云上平台业务进行隔离。利用数据校验工具，校验数据同步任务以及数据量。如何安全迁移业务？业务的安全迁移需要做到三个要求：1.不能引起故障，保证迁移可行性验证。2.迁移成本不能太高，业务侧尽量少改动。3.能上云也要能下云，尽量保证云上云下操作一致性。为了做到不引起故障，要做到三个需要：需要做业务场景测试，保证业务场景全部覆盖到，并且能够识别能够迁移的业务场景。需要数据质量检验，确保相同业务云上云下产出数据的一致性。需要数据效率验证，确保云上任务数据产出时间，同时不影响业务。如何保证较低的迁移成本？斗鱼在IDC中运行的任务主要分两部分，第一部分是Java任务，占比很小，特点是基于封装的HiveClient工具进行查询计算。第二部分是XML配置化任务，特点是基于自定义XML文件，支持HiveSQL统计后导入其他存储。针对这些任务的特点，斗鱼也做了相应的改造。针对封装OdpsClient，可以将HiveClient改成OdpsClient，并且改Hive URL为云环境。针对加模板改URL，可以引入MaxCompute参数模型，改Hive URL为云环境。为了保证能上云也能下云，第一，需要数据能上能下，就是前面提到的数据同步中心。第二，需要完善的配套工具，云上云下环境尽量透明化使用。第三，多使用通用功能，通过SQL+UDF能覆盖大部分场景。混合云模式带来的变化混合云模式带来的变化主要针对资源效率低，难以跟上业务发展，以及资源成本高，企业财务压力大两方面。在资源效率方面，从自建集群到MaxCompute有一些变化，包括提前半年或一年提预算变成按量付费，采购耗时1到3个月变成资源可以无限使用，机房上架1周以上变为无机房概念。相比于IDC自建集群，MaxCompute每年大概节约1000w成本，保障集群零故障。同时也有一些附加的收益，包括阿里云的专业服务，当遇到技术问题时可以请教阿里的专家来帮助解决，以及计算资源可以量化，可以知道钱花在哪些业务了，以及与阿里专家交流，帮助解决业务难题。在自建机房时，斗鱼也做了一些开发，下图所示为数据开发，包括基于Hue的查询计算和云上的DataStudio数据开发，然后将Hue的API和DataStudio的API集中起来形成斗鱼的大数据开放平台，作用是可以提供给数据部门的人使用，也可以提供给业务部门的分析人员使用。此外，斗鱼也做了一些实践，称为多活数据中心，如下图所示。斗鱼通过确立自建机房的数据和阿里云数据在这两个数据中心的角色，保证可以在多活数据中心的状态下支撑更多的业务。混合云带来的变化总结起来，资源成本和资源效率是最大的两个变化，还有可量化的成本、增值服务、额外的专业服务等，不仅可以给我们自己部门人员用，还可以给其他业务部门的人来用，并且他们对使用成本也是直接可见的。

发表了文章 2020-03-05

从新人到技术主管，他只用了2年

阿里妹导读： 1993年出生，毕业2年，团队主管，这是阿里妹对陈琦产生好奇的原因。我问他如何做到，他却调侃道：被高人指点，被能人套路。今天的内容来自于阿里云MVP陈琦专访，读完文章，你会明白：所有的能力和努力，都会被看见。所有伟大都源于一个勇敢的开始我跟可视化结缘是一个巧合，一开始并没有很笃定要做这个方向。2015年可视化的市场还不繁荣，我在创业公司实习，跟领导层一起参加各种创业大赛路演，当时我做的主要工作就是和领导深度沟通，独立梳理逻辑，并用PPT图表和动画的方式阐述出来，其实并不是太复杂的工作。 PPT体现出的逻辑性与视觉的冲击感，使其很容易成为比赛的亮点。几次竞赛经历中，我们的PPT在深度和广度上都深受评委赞赏，于是公司的领导找我约谈，鼓励我在数据可视化方向深度探索，并说“要记住今天的谈话”。当时我对事业还没有明确的方向，也没有意识到这次谈话对我以后将产生什么影响。现在回顾起来，我更愿意引用凯迪拉克的广告语：“所有伟大都源于一个勇敢的开始”，从那个时候起，我走出了勇敢的第一步。其实把兴趣变成工作是有风险的。把热爱的事情暴露在残酷的商业竞争环境里，对任何一个人来说都不会是持续的正反馈的选择。当兴趣和利益关联、和理论挂钩，你的成果受众人审视，被团队寄予厚望，你就不再只是享受它。你需要去思考，如何努力建设更高效的流程、架构，运作模式和方法，关心每个项目的健康程度和投入回报比例。现在一想到可视化，首先占据意识的是利益的博弈、客户的驱动、竞品的压力和公司的期望，不再是单纯为了生产“数据科学的艺术品”。但同时，我的专业知识也在积累，心智更加成熟，还造就了更专业的团队，也是让我欣慰的地方。其实感到挣扎的时刻很多，但我很享受这种博弈的过程；此外也遇到了形形色色的人，被高人指点，被能人套路，种种深刻难忘的经历才成就了今天的我。艺术鉴赏驱动我的技术创新艺术在我的生活中有很大比重，不仅因为数据可视化工作本身与艺术密不可分，也因为它可以提升生活的仪式感。我喜欢音乐，摄影，拍视频，也欣赏电影作品、插画、生成艺术（Generative art）。游戏被称作第九艺术，形成了全球最重要的娱乐市场，我也很乐于鉴赏游戏。从技术上来讲，数据可视化在视觉效果方面会复用游戏界一些成熟的引擎和算法，在故事性、代入感等方面也会向优秀的游戏作品学习借鉴。关于鉴赏游戏的说法，这是对游戏没有深度接触或深度喜爱的人所无法理解的。不仅仅满足于游戏带来的愉悦感，而会去反推游戏的机制和它的实现过程，我对这个过程还蛮兴奋的。比如它如何营造深度沉浸感，让人沉迷其中，甚至忘记自己所处的环境？物理引擎是如何迷人地仿真，并巧妙地节省了性能消耗？某个游戏的制作团队有多大规模？耗费了多少成本？如何优化大规模团队的工作流？每年都会有很多3A级别的游戏诞生，其中不乏一些作品堪称艺术品，当然，想欣赏游戏对阅历和鉴赏能力也有一定要求，每个人的出发点也有所不同。以专业动人，并心怀感恩我们有很多大型国企的客户，对接项目的初期，年龄差距确实可能引发一些信任问题。有时候客户会对我们几个90后的专业能力产生疑问，但这种情况只出现在项目前期。我不会感到不安和紧张，因为这是自己的专业领域，一两次大型会议或汇报后，客户就会对我们充分认同。一些客户对服务可靠性的要求很高，可能希望我全程在现场参与，这必然会导致时间上的矛盾。我解决这个问题的方法很明确，开始培养更多有潜力成为数据可视化行业中某个领域里的一个符号的人才。通过频繁充分的内部沟通，为他们提供很好的知识储备，引导形成自己的风格和专业观点，并且敢于表达自己的观点，对矛盾予以分析和化解。目前，团队的几位主要成员都深得客户信任，都具备在各自领域独当一面的能力。职场给我很重要的感受之一就是要心怀感恩。第一是要感谢自己的平台，我们需要认清自己的真实能力和平台赋予自己的价值，感谢平台对自己的信任，把十几人的团队托付给我。另外则要感谢对手，对手是最强的压力和驱动力。我会花很多时间研究竞品，跟对手保持良好交流，互通有无。让我真正感到紧迫的，往往也是来自对手的压力，然后加速驱动自己本身的进步。最后要保持跟外界的交流。深度沉迷容易形成信息孤岛，切忌盲目自信。一定要多关注前瞻的信息动态、友商和竞品的最新成果、行业宏观的发展情况，积极思考、反推、学习，要清晰地认识到自己的差距。若你也想与行业大咖切磋，了解前沿技术动态；若你热衷技术开发，想要传播自己的技术影响力；若你想参与阿里云产品的超前内测，用技术连接世界，我们等你很久了！

发表了文章 2020-03-05

疫情无阻，第二届阿里巴巴全球数学竞赛启动报名

战疫期，阿里巴巴的全球数学竞赛还办吗？答案：办。新冠肺炎疫情无法阻挡春天的到来，无法阻挡全社会复工复产，更无法阻挡第二届阿里巴巴全球数学竞赛的开启！阿里巴巴今天宣布，第二届全球数学竞赛自3月5日起面向全球数学爱好者启动报名，3月14日正式开赛。还记得马云在2018年首次发起阿里巴巴全球数学竞赛（ Alibaba Global Mathematics Competition）时的盛况吗?这项不限年龄、不限学历、不限职业、不限国籍的赛事，吸引全球10多个国家的近4万名选手参赛。首届大赛共有51人获奖，麻省理工学院、加州大学、北京大学和南京大学的学生各获得一座金奖奖杯。获奖者还有来自谷歌等高科技公司的工程师、中学数学教师、金融分析师、天文系教授等等。数论方向的金奖得主—Allen Liu、几何与拓补方向的银奖得主—张盛桐都是“00后”。颁奖典礼上，马云为选手们颁发了奖杯。马云说：“数学跟哲学一样，是所有科学的基础，是推动整个社会进步的基础。阿里巴巴做数学竞赛，首先是因为乐趣，找到一批把数学当成人生乐趣的孩子，鼓励、帮助、支持他，让更多的人热爱数学，这是我们的目的。数学应该成为年轻人的基础，就像运动、音乐和绘画一样。如果数学基础坚实，人类会更坚实。” 今年，由中国科学技术协会、阿里巴巴基金会、阿里巴巴达摩院共同举办的这项赛事延续了下来。尽管我们刚刚遭遇一场突如其来的疫情，整个社会还处在逐步恢复运转的过程中，阿里巴巴仍然如期推出了第二届大赛，继续点燃社会各界对数学这门基础学科的热情，推动全球数学事业的发展。今年的赛事星光熠熠，阿里巴巴达摩院邀请北京大学、剑桥大学、浙江大学等高校的顶尖数学教师组建了出题组。其中，中科院院士、美国艺术与科学院院士、北京国际数学研究中心主任田刚担任竞赛命题委员会主任、竞赛指导委员会委员。田刚，中科院院士、美国艺术与科学院院士、北京国际数学研究中心主任。1994年获美国国家科学基金委员会第十九届沃特曼奖，1996年获美国数学会韦伯伦奖。他解决了一系列复几何、几何分析及数学物理中的重大问题。他说：“阿里巴巴全球数学竞赛是国内企业独立举办的第一个数学大赛，对于激发大众的数学热情、推动数学教育和中国数学的发展会有重大作用。” 苏黎世联邦理工学院教授、2018年菲尔兹奖得主Alessio Figalli以助阵嘉宾身份参与了本次赛事。 AlessioFigalli的研究领域是变分法和偏微分方程，2007年从比萨高等师范学校和里昂高等师范学院获得博士学位，2018年获得菲尔兹奖。还曾获得EMS奖（2012年）、Stampacchia金奖（2015年）和Feltrinelli奖（2017年）等。他说：“举办数学竞赛非常棒，吸引人们对数学的关注是件好事，对年轻学生来说尤其如此。” 今年大赛分为预选赛、决赛两个环节，比赛方式是线上答题。预选赛两轮，分别在北京时间3月14日、21日举行，赛题8道，包含理论数学题和应用数学题两类。决赛安排在4月18日，赛题均为理论数学题，包含几何与拓扑、数论与代数、数学分析与方程、应用数学与计算数学几大方向。阿里巴巴为决赛选手准备了百万奖金。数学是一切自然科学的基础，也是科技进步的强大引擎，云计算、人工智能、芯片、量子计算等前沿技术的研究都离不开数学。作为一家高科技公司，阿里巴巴有责任引领全社会关注数学、理解数学、欣赏数学、助力数学，加强数学人才的培育，推动数学的原创性研究与突破性进展。附本届大赛赛制一、预选赛（3月14日开始）共两轮，按照总分排名进入决赛。第一轮：北京时间3月14日早8点-16日早8点第二轮：北京时间3月21日早8点-23日早8点比赛形式：个人赛题目类型：贴近实际生活的数学，包含选择题和解答题比赛时长：48小时答题方式：线上答题奖励：参与预选赛完整答题，获得阿里巴巴颁发的参赛电子证书一份二、决赛（4月18日开始）北京时间4月18日比赛形式：个人赛题目类型：解答题OR证明题➤ 几何与拓扑➤ 数论与代数➤ 数学分析与方程➤ 应用数学与计算数学答题方式：线上答题三、决赛奖励金奖（4人）：每人2万美金奖学金银奖（6人）：每人1万美金奖学铜奖（10人）：每人5千美金奖学金获奖选手还有机会获得大师推荐信报名链接：https://damo.alibaba.com/alibaba-global-mathematics-competition

发表了文章 2020-03-04

2020阿里云采购季史上最全攻略

采购季系列直播：https://yqh.aliyun.com/zhibo#J_2695837880 2020阿里云上云采购季3月2日正式拉开序幕，活动覆盖云服务器、云数据库、对象存储、云安全产品、域名与知识产权和企业应用多种产品。开年买的好，降本增效一整年，今年的采购季可以逛些啥？有啥福利呢？来云栖号采购季直播间跟着咱们采购季主播们一起来“买!买！买！”。 1. 今日重磅推荐每天第一时间通知您当天直播，绝对不会错过的精彩内容。今日重磅推荐https://yqh.aliyun.com/zhibo#J_4303175940 2. 7大分会场攻略如果你觉得文字攻略太过于呆板枯燥，那直播带货一定能满足你的购买欲。数据库、IoT、弹性计算、存储、域名&知产等7大分会场陪你整个三月，每天一场直播不重样！是谁的小眼睛还没看过来~ 7大分会场攻略 https://yqh.aliyun.com/zhibo#J_2695837880 3. 弹性计算专场直播目前阿里云为用户提供丰富的云服务器ECS产品，不同系列ECS之间存在较大差异，选择合适的ECS，是业务起飞的第一步！弹性计算专场直播将为大家介绍阿里云ECS产品选型及常见问题、全新产品s6、阿里云ECS迁云工具介绍及演示、云上大数据分析最佳实践、云上CI/CD最佳实践、云计算的内核技术揭秘等等。3月2日至3月31日，每天都有新内容！弹性计算专场直播，每天一场！ECS产品入门，会场攻略，新品发布，省钱买，轻松购！https://yqh.aliyun.com/zhibo#J_8160541300 云栖号--采购季直播间主播带你玩转阿里云采购季，省钱买，轻松购！https://yqh.aliyun.com/zhibo#J_2695837880

发表了文章 2020-03-04

战疫期，钉钉如何扛起暴增百倍的流量？

疫情期间，在线教育、在线办公需求持续井喷，钉钉作为很多企业首选的在线办公软件，用户量激增，特别是钉钉视频会议、直播的需求随之飙升。同时，钉钉为了响应教育部门“停课不停学”的号召，宣布老师们可以免费试用钉钉在线课堂。流量如洪流般涌入钉钉，一场资源扩容的技术挑战拉开了帷幕。中小学生集体对钉钉展开了五星分期与在线写歌“泄愤”的策略，钉钉本钉不得不在线求饶。而在大战间隙，一声感叹传出：流量这么大，钉钉为什么不崩？从1月28日开始，钉钉音视频会议、直播的访问流量倍数级增长。作为一个在云上成长起来的产品，钉钉开启了在阿里云的资源扩容之路，满足了用户在家办公及在家上课的需求，保证了用户良好的体验，钉钉如何做到的？如此大型的扩容，面临着两大困境：效率与资源供应人工扩容困境：效率低下时间太短。面对流量暴增，留给钉钉技术团队时间只有几天。从1月29日起，钉钉团队就已在阿里云上24小时开始全力扩容，截止2月2日，从最初的2W vCPU扩容到3W vCPU，仅做到了数倍扩容，还远未达到业务需求。购买与配置非常复杂。钉钉的系统架构包含多种资源，不同于单一的云服务器ECS服务集群，还包含SLB、MongoDB、Redis、EIP等产品。这些资源都需要一个个购买，其之间的关系也需要技人工自行配置。人工部署效率低、失误率高。钉钉用户群量级大。如果人工部署集群，一个人部署1个集群需要1小时左右，同时也只能操作3-4个集群，还需要大量的配置操作，很容易失误。部署复杂度高。集群的服务能力自闭环，支持无限扩展，但也会相应提升部署复杂度，而这次扩容涉及8个地域、16个可用区，传统部署方式扩容场景效率低下大规模集群管理难度大。需要快速扩容近千集群，才能满足几亿人在家办公及学生在家上课的需求。当资源上千后，就很难管理资源之间的关系了，更何况超百万的资源规模。人工部署，容错率比较差，排查困难。集群之间经常出现偏差，某个集群的SLB监听端口是300，另一个集群是3000，出现问题很难排查。除却以上困难，建立和运维如此巨大的集群规模还会带来更多的技术挑战。利用资源编排服务ROS，实现快速自动部署早在2月2日流量洪峰带来之前，钉钉就通过阿里云的资源编排服务（Resource Orchestration Service，简称 ROS）提高集群部署效率、帮助其快速扩容。而这款服务不负重托，帮助钉钉在短短2小时内新增部署了超过1万台云服务器，这个数字也创下了阿里云上快速扩容的新纪录。什么选择资源编排服务？资源编排服务是一款帮助阿里云用户简化云资源创建、更新和删除的自动化服务。其通过资源栈 (Stack) 这种逻辑集合来统一管理一组云资源（一个资源栈即为一组阿里云资源）。利用资源编排服务，云资源的创建、删除、克隆等操作都可以以资源栈为单位来完成。在 DevOps 实践中，资源编排可以轻松地克隆开发、测试、线上环境；同时，也可以更容易实现应用的整体迁移和扩容。基础设施即代码（Infrastructure as Code）资源编排服务是阿里云提供的基础设施即代码（Infrastructureas Code，简称IaC）的云产品，使用ROS可以帮助最快速地实践DevOps中关于IaC的理念。全自动托管服务 ROS产品为全托管服务，无需购买维护IaC模板本身执行所使用的资源，只需要关注业务所需要使用的资源，即模板中定义的资源。尤其需要创建多个项目（对应多个资源栈）时，全托管的自动化可以更快地完成任务。可重复部署无论客户是需要部署的环境是开发，测试和生产环境，都可以使用同一套模板进行创建。指定不同的参数可以满足环境的差异化，例如，测试环境的ECS实例数是2台，而生产环境的ECS实例数是20台。或是客户需要进行多地域的部署，使用同一套模板可以进行重复的部署，从而提高部署多地域的效率。标准化部署在实践中，不同环境的细微差异往往带来非常复杂的管理成本，延长了问题诊断的时间，从而影响了业务的正常运转。通过使用ROS重复部署，可以将部署环境标准化，减少不同环境的差异，将环境的配置沉淀到模板中。再通过类似代码的严格管理流程，从而保证部署的标准性。统一的身份认证、安全和审计和其它的同类产品对比，阿里云官方出品的ROS与其它阿里云产品有着最佳的集成。集成资源访问管理（RAM）提供了统一的身份认证，而无需为单独建立用户认证体系。所有的云产品操作都通过OpenAPI调用，意味着您可以使用操作审计服务（ActionTrail）来审查所有的运维操作，包括ROS本身。 ROS如何服务钉钉扩容？定义资源模板 ROS帮助钉钉快速创建了描述其所需要用到的阿里云资源（如 ECS 实例、数据库实例等）的模板，以定义它的集群架构。ROS提供可视化编辑器能力，可自动可使用的模板。模板完成后，ROS将自动地创建并配置这些资源，即可实现基础设施即代码（Infrastructureas Code）的理念。模板解析与执行当ROS接收到用户创建资源栈的请求时，在执行创建前，首先会对模板进行解析。解析包括语法检查、参数校验、依赖分析等。依赖分析就是分析出资源间的依赖关系，目的有两个：保证资源创建的正确性：被依赖资源创建完成后才会创建依赖资源。提供并行化创建的能力：无依赖关系的资源可以并行化创建。模板解析完成后，ROS会按照依赖关系创建资源，只有所有前置资源完成创建，后面的资源才会开始创建，类似状态机的机制。该资源模板可以快速地重复部署，尤其多地域、多可用区部署的情况；同时也可以减少环境之间的偏差，将部署过程和结果标准化，减少因为环境偏差引入的系统问题。总结钉钉使用资源编排服务ROS，扩容效率就提升了100倍，陆续为钉钉完成了10万台云服务器的快速扩容和部署，创下了阿里云上快速扩容的新纪录。目前ROS已经拥有平均每分钟1个集群的扩容效率、每天超百万vCPU弹性能力。未来，可以预见到，疫情结束后，数百万资源回收释放也将是一个浩大的工程。资源编排服务ROS具有一键销毁功能，自动回收集群内所有资源，避免繁琐操作及遗漏。弹性是云计算最大的优势，也是云计算对整个社会提供的普惠和便利，而阿里云弹性计算资源编排服务ROS作为阿里云上原生的自动化编排部署服务，让云计算的弹性发挥到极致，为钉钉提供了强有力的支持，让钉钉成为使用最频繁最流畅的平台。

发表了文章 2020-03-03

贾扬清：如何看待人工智能方向的重要问题？

阿里妹导读：今天的内容由阿里CIO学院攻“疫”技术公益培训贾扬清专场整理而来。直播中贾扬清向大家分享了人工智能的工程和产品实践，首先介绍了什么是人工智能以及人工智能的应用；然后和大家一起探讨了人工智能系统中的重要问题，如算法创新背后的算力突破、云上平台能提供的价值；最后给大家剖析了大数据和人工智能之间的关系，作为一个企业应该如何拥抱AI以及智能化年底企业布局的重点。一、人工智能算法目前，AI（人工智能）已经成为科技产业大趋势。各个行业都与“AI”密切相关。与AI相关的领域如下图所示，其中包括与AI强相关的领域和AI间接赋能的的领域。那么究竟什么是人工智能、人工智能的应用以及人工智能系统将在之后一一介绍。人工智能发展的80年，实现了从图灵测试到全民换脸。机器是通过人工智能像人一样来回答问题、创作或者计算分析的，在一些领域，计算机已经能够做的和人一样优秀。例如在2019年网络上的“全民换脸”都是基于人工智能中的深度学习及神经网络等技术的广泛应用的结果。目前，人们生活中以及工业生产中都有很多“AI”技术的应用，用来代替人类的工作。例如比较流行的“ELON MUSK’S”能够模拟人的大脑工作。但随着人工智能的快速发展，也出现了一些对人工智能的反思和一些“假冒AI”。人工智能AI在发展过程中面临了一系列的事件，其中有比较严重的假冒伪劣AI骗取2亿融资的事件。那么人工智能究竟是什么以及它的用途主要有哪些是接下来要重点讨论的问题。在学术界，人工智能的定义也有所差异。人工智能是接受输入的信息，通过信息的整理判断，像人一样对输入的信息做出一系列理性行为和决策。它的主要特征就是“理性的行动”。在这个“感知”到“决策”的反馈中，如何感知外部世界信息成为人工智能能否去行动的关键。既然是要模拟人的大脑，那人去感知的过程其实是一个认识和学习的过程。那也就是人工智能中“深度学习”所要解决的问题。深度学习只有将外部信息（视频，文字，口令等）转换成机器语言才能被人工智能所接受并作出反应。这个问题的思考早在人工智能初期就被科学家所考虑和研究。在这之后人们开始讨论如何通过视觉感知来完成信息的输入，并做了很多研究。2012年，加拿大多伦多大学的ImageNet竞赛冠军获得者Hinton和他的学生Alex Krizhevsky设计的。也是在那年之后，更多的更深的神经网络被提出，比如优秀的vgg,GoogLeNet。这对于传统的机器学习分类算法而言，已经相当的出色。 AlexNet开始的深度学习历程：通俗的说，就是在大量的物体中，准确地识别我们指令中需要的物体。这个模型的应用使得图像识别领域取得了突飞猛进的发展，并被广泛应用。神经网络这种分层学习的模式跟我们人类大脑一样，随着不断地学习，神经网络也变得越来越复杂。假设要在百万级的图片信息中找已标注的信息“猫”，然后把编辑好的视觉网络的模型在一个非常大的数据集中训练。通过模型的迭代实现更复杂的训练。目前，比较普遍使用的“RestNet模型”，深度在一百多层，并加入了一些最新的科研成果,例如最下面图中如拱桥部分的快速链接，可以有效快速的训练如此深的网络。最终解决视觉领域的“感知”问题。阿里云：智慧航空机坪管理通过人工智能来识别机种，登机门，机场车辆，并与实际地图结合起来，以及了解飞机在飞行过程中的运行轨迹等等，这些信息都可以作为输入的信息来通过人工智能管理，使得机场运转更加快捷和高效。上面所说的，深度学习是感知的一个重要形式和方法。深度学习算法主要组成：数据标注算法模型开发高性能分布式训练模型调优模型部署人工智能在“感知”之后，另一个需要做的就是“决策”。深度学习是一个黑箱操作，能够很好地学习和感知外部信息，但是不能给出反馈及如何解释自己感知的问题究竟是什么原因。那就需要“决策”来分析和反馈。传统机器学习的榜样是决策树算法和逻辑回归。例如，银行发放贷款的过程就是一个权衡各方面因素之后的一个决策过程。可以通过决策树的形式，进行“Yes”或“No”的判断来最终决定是否发放贷款。而逻辑回归，指的是两类数据之间的相互关系，通过数学的方式精确求解。其实，深度学习和机器学习是一种互补的状态。深度学习非常好地解决了感知的问题（计算机视觉，语音等等），可以用神经网络的架构来解决非常多的“感知”的问题，但它需要解释这些感知的东西。而传统机器学习则没有这么人性化的感知功能，但它的模型相对较小，我们可以直接解释（例如金融，风控等）。人工智能很早便被应用在广告领域中。早在宋朝就有广告，用来帮助来招揽生意。目前比较典型的广告场景是淘宝广告。厂家首先通过消费者个人的浏览信息了解用户的喜好是什么，然后再通过智能推荐系统来推送消费者所搜索的相关产品。这样的一些智能算法的广泛应用使得用户的信息浏览更加高效和精细化。无论是感知还是决策，都和算法相关。感知。与深度学习算法相关，涉及到数据标注、算法模型开发、高性能分布式训练、性能调优、模型部署等。决策。传统机器学习算法以及深度学习算法相关，涉及到行业行为数据采集、结构化/非结构化数据处理、数据和算法的组合建模、算法开发训练和调优、模型部署和实时训练反馈等。二、人工智能系统在算法发展迅猛的今天，相应的基础设施支持也显得尤为重要，这就需要人工智能系统的支持。构建人工智能或者机器学习系统的两个不可或缺的因素是算法和算力，算法创新的背后是算力的突破。截止到2019年，人工智能对于算力的需求如下图所示。相较于AlphaGo Zero，AlexNet对于算力的需求已经有了30万倍的增长。这种情况下解决算法迭代和算法落地的问题，给系统提出了更高的要求。 AlexNet在2013年的时候所谓的系统如下图所示，简单的一台机器加GPU，当时的训练成本大约是七天每天500瓦，也就是业务模型的迭代周期是一周左右。在业务需要飞速发展的今天，比如广告推荐，一周的模型迭代周期是远不能满足需求的。因此，目前越来越多的人关注如何通过大规模集群或者芯片的方式来为人工智能系统提供更好的算力。MIT在2014年的时候做了一个对比，一个人在一分钟内大概可以处理77张图片，单个GPU相同的时间内可以处理230张，尽管单个GPU的处理速度与人的处理速度相差不大，但是其可以通过GPU集群的方式实现更大规模更快速的计算，比如下图中512个GPU的集群，可以在一分钟内处理60000张图片。人工智能系统在设计的过程中需要关注怎么样做高性能存储，怎么样实现机器之间的快速通信，怎么样保持分布式集群的稳定性。今天，阿里云内部有一个Eflops平台，可以实现三钟内1018次的计算，耗电128千瓦每分钟。这是在2015年以前是无法想象的能力，这一能力的实现主要归功于大规模集群，还有系统底层芯片的伸缩性。目前国内很多家企业致力于更高性能芯片的研发，阿里也不例外。2019年，阿里发布了全球最高性能的AI推理芯片含光800，并在城市大脑和航空大脑的实际测试场景中进行了测试，峰值性能可以达到将近80万张图片每秒，这与上一代的芯片相比，实现了40倍左右的性能提升。系统复杂度上升后，会带来一系列的问题，包括软件复杂度、硬件复杂度、资源管理复杂度、调度效率复杂度、全系统优化复杂度，这在系统发展过程中是比较共性的挑战。需要强调的是，AI集群不等于通用集群。AI在做训练的时候需要子任务周期性同步，不同机器之间需要有高性能的通信，很多时基于GPU或NPU专用部件。不同的计算模型，不同的交互模式目前对于AI训练有比较大的挑战。阿里的各种业务场景都可以用到AI，因此可以通过AI实践打磨平台设计，比如手淘-拍立淘的百万分类模型、淘宝网的语音+NLP和阿里妈妈广告推荐等。打磨后的飞天AI平台分为三层，从最底层的基础硬件，到中间的训练和推理框架，再到开发平台。对于AI平台来讲很重要的平台有以下三个：轻量级AI开发平台：帮助算法和数据科学家实现一键式开发、调试部署 AI和大数据协同开发平台：帮助更加迅速地开发面向大数据型业务的系统 AI推理服务平台：解决推理需要的计算资源问题、模型训练、部署和效果监测以上三个平台支撑了算法API的输出和垂直领域平台以及大脑的解决方案。深度学习领域，斯坦福大学推出了一个名为DAWNBench的测试基准，相比于之前的最有结果，阿里云机器学习实现了性能百分之十左右的优化。AI技术能力在今天对于提升资产利用率、解决不同场景需求具有重要意义。综合的AI技术能力主要涉及以下几方面：基础硬件：用于提供通用的算力以及AI所需要的计算能力，通过IaaS提供云的能力 AI云服务：最基础的PaaS层，通过容易拉起的软硬件环境向绝大多数用户提供适合AI的算力高性能计算：提供核心AI计算引擎加速 AI系统框架：提供AI计算模式的完整抽象以及跨体系结构的建模迭代和部署 AI托管平台：提升算法研发共享部署和输出的效率，以及具有用户粘性的开发平台三、智能计算和数据计算 AI是智能计算，大数据领域是数据计算，二者是相辅相成不可或缺的关系。数据支撑AI 刚才提到的算法和算力背后需要大量数据的支撑，数据是体现算法和算力价值的重要部分。下图分别展示了2005年和2013年教皇登基的场景。当前手机互联网的发展导致了数据的指数型增长，这也可以给深度学习带来性能的提升。 1998年的一个小系统MNIST的训练数据仅有 10MB，2009年的ImageNet有200G，2017年的WebVision有3TB，而典型的产品视觉系统有1PB。海量的数据帮助阿里几乎线性地提升其性能。举一个的生活中的场景来说明数据量对于性能的提升作用。在X光片医学识别领域，有研究显示，医生在X光片上识别病症的效果和其所看过的X光片数量成正比。看的越多，正确率越高。同理，目前的医疗引擎系统可以通过大规模的计算机系统训练更多的数据，实现更加精准的医疗识别。 AI驱动大数据走向智能化下图展示了Forum对大数据领域做的趋势总结，当前大数据领域需要提取更多的信息，要实现实时的计算，实现AI平台和在线预测等，都体现了大数据走向智能化的趋势。多个数据源不同类型的数据，如结构化、半结构化和非结构化，落到数仓后如何发挥其价值，答案是智能计算。以广告推荐场景为例，数据源是用户在淘宝上的点击、浏览和购买行为数据，通过数据集成离线或实时同步、离线或实时ETL的方式将其落到数仓中，再通过数仓或数据湖的解决方案生成各种数据模型对数据进行训练，最后通过数据服务的方式对训练结果进行输出。可以发现，该过程中对于数据的理解和使用方式开始变得智能化。几年前的HTAP，包括OLTP和OLAP两部分，OLAP可以进一步分解为大数据的分析，离线、实时分析，基于数据量的不同选择不同的引擎。而目前数据服务也变得越来越重要，在一些智能客服场景中，需要依赖数据提炼模型，来做实时人工智能推理服务和应用，因此如何把analytics和service结合也很关键。这也是现在考虑在做的HSAP，通过人工智能驱动离线、实时数仓数据价值提取，通过数据服务推送给用户。阿里在自己本身的应用中沉淀出了AI加持的大数据方法论和解决方案，在双十一大促中的离线计算（批处理）、实时计算（流计算）、交互式分析和图计算等场景，和飞天AI平台相结合，为用户提供了AI加持的完整的新一代飞天大数据产品。大数据和AI一样，也非常注重性能。2019年阿里云大数据平台MaxCompute和EMR分别在TPC上的计算性能和性价比优势明显。具体测试结果如下图所示。阿里的阿里小蜜目前为用户提供了智能化的的语音客服交互方式，其应用了深度学习和智能感知的AI技术，同时需要和背后的大数据业务系统紧密联系，如物流、用户数据等，才能实现最后的智能化效果。那么作为一个企业应该如何拥抱AI呢。简单来讲，人工智能需要落地，应该从应用需求出发，逐渐追求技术创新，就像爱迪生发明电灯一样。通过云提供低成本、到高性能和高稳定性的基础设施，但关键应该明确需求是什么。前面几年，AI一直在做算法的创新，做Demo，但这是远远不够的。 AI算法只是系统中的一环，怎样收集数据，获取有用特征，怎样进行验证，怎样进行过程管理、资源管理等等，都是企业在拥抱AI需要考虑的问题。 AI不是万能的，但是忽略AI是万万不能的。当企业拥抱AI的时候，最重要的还是从业务出发。随着数据量越来越大，算法越来越多，核心是需要建立懂业务的数据工程师、算法工程师的队伍，这是当前智能化企业致胜的关键。而前面提到的算法、算力和数据，都可以利用目前云上提供的服务和解决方案来实现，其可以帮助企业更快速的实现AI的落地。

发表了文章 2020-03-02

在阿里，新人如何快速上手项目管理？

阿里妹导读：为防止疫情蔓延，互联网公司纷纷开启SOHO办公模式。停工不停业，尤其与疫情相关的服务工作，都在快马加鞭的进行中。比如优酷的“战疫情”专题、“在家上课”项目，都是数百名互联网人“在家”完成的。今天的文章，阿里文娱项目管理专家常昊和我们聊聊高效率的背后，有哪些项目管理秘籍？一、背景互联网公司除了业务迭代快，大型战役活动也不少，比如阿里巴巴的双11、阿里影业的春节档、优酷的世界杯等等。这些大型战役，不仅考验技术人的代码功底，更考验在超大型项目中团队协作能力、快速应变能力。本文将从PMO的专业能力+技术人的实践视角，详解大型项目及战役的运作流程，将复杂项目做模块化拆解，教你站在项目全局看技术实践，同时例举团队高效沟通的技巧，希望为当下SOHO的互联网人带来启发。二、做好大型项目的五个关键几百人、上千人组成的大型项目/战役有很多挑战，乍一看让人望而却步，但仔细梳理下来好像也没有那么复杂，只需要厘清以下的关键： 1、拿什么结果 -> 项目的目标2、谁是我战友 -> 项目的成员3、啥时候吹号 -> 项目的计划4、怎么来协同 -> 项目的机制5、战后做点啥 -> 复盘和沉淀思路就是: 明确事->找对人->排计划->定机制->收好尾。不过，从项目特质上来说，信息是渐明渐细的，梳理和澄清是一件持续的工作。三、问题厘清有了整体的思路,心里也就有了底气，但也不能眉毛胡子一把抓。不同的阶段重点不同，按照常见的项目阶段来看，可以分为启动期、规划期、执行期、监控期及收尾期。每个阶段需要明确关键目标，锁定核心问题。启动期：明确方向，确认人员，厘清目标，明确机制，制定里程碑计划；规划期：明确目标、确认方案，制定执行计划；执行期：紧盯目标、管控计划、保障落地；监控期：基于目标、运用机制、核查计划、发掘风险，制定预案，管控变更。理论上从规划期到收尾期都属于监控期，但项目的差异，着力点和力度有不同。常见的互联网项目，执行期监控力度最大，所以一些流程上把执行和监控揉和在一起了；收尾期；有序收尾、深度复盘、有效沉淀。这里已经明确了各节点的重点，那如何抓住这些节点值得探讨。作为项目PM或团队管理者，需要把控三点：驱动管理节点，紧盯目标，这个目标是宏观的目标，包括业务目标、进度目标、人员的目标；保障沟通通道，保障信息的上传下达，步调一致，协同各团队有效参与；运用管理机制，包括目标负责制、沟通机制、需求管理机制等；四、操作流程驱动管理节点管理节点一方面要拉齐信息，另一方面要发掘风险和问题，及时做出应对。关键点上核心信息的确认和决策以及同步，当面的会议沟通是非常有效的手段，但保障会议有效是其中的关键。会议前；做好议题收集和准备，特别是会议的前置输入材料和关键信息提前准备好；会议中；聚焦议题和发言顺序，控制会议时间，保障会议有效；会议后；要有结论输出并同步参会人及关联方； SOHO模式下，IM、音视频及共享屏幕工具尤为重要，尽量选择团队日常使用、通用性好、使用复杂度低的工具并分享使用TIPS。整体会议安排上做好协同，避免过度的会议影响正常工作；方向对焦会: 基于项目价值、核心1号位及关键同学，通过会议确认并输出：方向、初步策略、里程碑及运行机制；方案review会: 会议前基于方向对焦会结论，已产出核心方案草案，且在该草案基础上拉通关联团队输出联动业务方案；需求评审会：基于业务方案和平台能力明确当前业务需求，通过需求评审会确认各负责人及落地计划；复盘会：基于目标、方案结合当前完成情况进行复盘，重点是可复用能力的沉淀和发现问题的后续跟进。 2. 保障沟通通道日会：通过项目例会对焦核心信息，同时进行关键工作进度同步、成果验收和快速决策。根据项目所处的阶段和工作的颗粒度，可以调整会议的频率，但不适宜频繁调整节奏和会议室；日报：围绕核心目标、策略、进展、风险等核心信息有效记录和同步，重要信息需和对接人确认并反馈；文档库：提升信息管理效率，降低PM和关键人员沟通瓶颈；促使团队自主联动，有效同步和纪录核心信息，持续沉淀关键信息给后续复盘和项目做好沉淀。 3. 建立和运用机制持续和聚焦目标、策略（方案）、进度（计划）促成高效执行；发掘和同步风险，准备预案消除和降低风险危害。五、关键点 1. K.O.（启动会）: 目的：启动会能够让各个业务部门的人员清楚知道项目的概况，目标、策略、落地计划，懂得如何配合，确保后续各部门人员配合到位，沟通协调效率高，有利于推动整个项目的推进。操作： 1）会前准备明确参会人员：确定他们的时间，并据此确定会议地点。SOHO模式下，选择好协同工具，比如视频会议、视频直播，提前试用告知参会者准备参会设备；划分讲话内容：为发言者圈定讲话范围和时限，让参会者要求准备发言内容；线上沟通，需要比现场沟通更精炼；准备相关资料：包括宣传资料、现场摆设、座位分布、相关配套服务等等。 2）会议通知召开项目启动会通常提前3天发布通知，紧急情况下适当调整，同时要提前与参会的核心人员进行沟通，让参会人员事先了解自己在项目中需要负责的工作和担任的角色。项目团队的所有成员都要参加项目启动会议，即使有人当时不在办公室，也尽可能通过电话参与会议。 3）会议议程由项目负责人介绍项目背景、目标、范围，奠定整个项目的基础；由各业务负责人介绍产品方案；由项目经理介绍项目管理机制，包括安全机制、奖惩机制、沟通机制（日会、周会、日报、周报等）、变更管理等；由项目负责人为各团队负责人颁发委任状或立军令状，并全团队大合影，在SOHO模式下可以选择工作照拼图。 4）会议原则高层的领导尽量邀请到，这样各负责人可以提高重视度，更积极的组织个参与工作。启动会一定要按时开始、按时结束。这代表着项目管理的基调和规则，有利于形成守时、高效的项目管理风格。启动会必须要正式，会议的议程和时间可以缩短，但是会议的规格和对参会人员的重视程度一定要达到标准，要让参会人员觉得会议很重要，老大讲话投屏、横幅、座位牌、水等尽量要有保证。 5）会议总结项目启动会是一种关键信息对焦和拉通形式，所以，需要总结会议的重点内容和后续计划，并把会上领导关键讲话作为项目过程中的指导方针，把团队的合影、军令状、项目的K.O.文件等在会后一并发给大家，推进项目展开。 2. 风险管理风险在各个项目里长期存在，识别、反馈及处理风险是持续工作。在项目里一方面要建立全员风险管理的意识，鼓励风险的及时识别和上报。 3. 相关方管理项目经理需要识别项目相关方，分析其对项目的要求或需求，并且管理好这些要求和需求，满足不同的相关方，从而以确保项目的成功。识别和管理相关方是项目中持续要做的工作，且需要明确反对项目的人或组织同样属于相关方。 1）识别相关方: 2）管理相关方： 4. 复盘目的：基于目标、方案结合当前完成情况进行复盘，沉淀可服用能力，发掘系统缺陷和无效策略，在结束后修复完善漏洞并记录为下一个项目提供支撑和规避；时机：不同的项目复盘契机存在差异，但复盘的目标需要明确，一定要杜绝无效的复盘；时限型项目达到预定时间；例如：3月底完成APP DAU提升XX的目标；目标型项目达到预定目标；例如：Q3完成APP客诉量下降一半的目标；项目出现严重问题；操作：1）复盘原则：多目标以目标纬度复盘，确保链条完整性；子项目复盘在组内进行，保障复盘有效性；鼓励畅所欲言，警惕自我吹捧、禁止互相攻击。 2）会前准备: 明确需要参与人、时间、地点；划分讲话内容，为发言者圈定讲话范围和时限，让发言者要求准备准备相关资料，包括前期方案及过程数据。六、结束语以上是组织一个项目的简要流程。从阿里文娱PMO团队的经验出发，项目过程中会有很多复杂的问题出现，但发挥项目的团队能力，最终都能顺利解决。此外，还可以寻求专业的项目管理团队作为教练赋能，最终实现：目标可预测；资源可调度；变化可控制；问题可见和追溯，使得战役有序打响并取得预期的胜利。

发表了文章 2020-02-28

在家办公，阿里人如何写周报？

职场人几乎都写过周报。对周报，每个人的态度天差地别，有人把它作为协同利器推崇万分，也有人把它归为形式主义深恶痛绝。在家办公以来，不少公司为了帮助大家沟通工作内容，开始实行日报制度。当周报变成日报，矛盾也更加激化：每天花时间精力写这东西，真的有必要吗？为什么要写周报？对管理者来说周报是最高效的沟通载体当团队人数较多时，一对一逐个汇报会花费大量时间，团队成员提交周报后统一阅读，显然是最高效的。通过工作周报，管理者能快速了解团队一些关键事情的进展和一些风险,能从整体上把握项目的质量。有效提升团队信息透明度当团队每个成员只专注自己手上的项目时，常常会出现「见树木而不见森林」的情况。当团队所有成员可以阅读到其他成员周报，尤其是与自己没有合作关系成员的工作，将帮助团队成员获得更好的「全局感」。文字是可沉淀的团队无形资产把团队每个成员的工作「落在纸上」，将成为团队无形资产一直沉淀下来，尤其在团队快速成长过程中，新入职同学能通过阅读过往周报快速了解团队协作模式，帮助磨合落地。对员工来说周报是一次很好的沟通机会工作周报可以让你「名正言顺」地向上级说明你的工作事项有那么多，工作任务有那么重，是争取资源支持和展示自己工作价值的重要机会。一次自我回顾总结工作的总结能够让你回顾本周工作在推进的时候是否存在问题：时间管理是否可以提升？沟通办法是否可以改进？制定的计划是不是要调整？重新对齐目标还有一点经常被忽略，很多人在做事情的时候，做着做着就把事情本身当做了目标，反而把时间耗费在许多对目标没帮助的事情。所以周报也是一次重新对齐目标的机会：周报里写的事情为什么要做？是不是做了一些不该做的事？为什么我们讨厌写周报？周报有这么多好处，但我们为什么这么讨厌写周报呢？事实上，很多人错把周报当成了「证明自己工作很饱和」的工具，便把所有工作内容事无巨细详细罗列，动辄 3000 字起，还要贴不少数据报表，犹如征文比赛。当团队中有一个人写了 3000 字周报，只写 800 字的同学就会心慌，赶紧加字加图加感想，往 4000 字凑…… 最后，篇篇都是长篇累牍，管理者看着也头疼：需要在一大堆文字里提取有效信息，堪比阅读理解。周报从日常汇报变成语文考试，员工不爱写，领导也不爱看。那么，如何让日报脱离形式主义，真正服务团队协同？以下是阿里巴巴语雀团队的周报实操办法：阿里巴巴语雀团队的周报怎么写？ 1、严格控制字数，不写流水账周报都叫「报」了，首要的功能当然是汇报工作，汇报工作只把重点工作写上即可，无需罗列日常事务。每周，我们会用语雀话题知识库建立一个周报话题，在内容说明中详细标明：不要记流水账，尽量在800字以内。（对于日报，我们的字数限制是 200 字）限制字数以后，大家不会再凑字数，而会想办法精炼内容，突出重点，也方便其他人阅览。 2、划重点，标明关键项目进度撰写者讨厌写作文，阅读者也讨厌做阅读理解。为帮助阅读周报的同事快速了解重点，我们会为工作内容划重点，标明关键项目当前是已完成还是待完成，用「列表」和「标签」简单排版就可以让周报层级错落有致，重点突出。 3、不赘述，不做复制粘贴搬运工过于详细的项目细节不做赘述，有需要大家了解的前情可以将相关文档或者表格「嵌入」到周报里，保持周报内容精炼。 4、多讨论，写给团队的周报在语雀团队，周报并不仅仅是「写」和「交」两个动作，更重要的是交完周报之后的讨论。在周报里，大家会聊一聊本周的所思所想，可能是工作相关，也可能是生活中的一些细节，其他同学对这些话题感兴趣，也会在周报下跟帖，深入讨论。这时候，团队周报并不只是下属对上级的一对一的单线汇报，更多的会话交织在团队成员当中，不同职责和背景的同学一起探讨各种各样的话题，经常能带来更多碰撞和启发。 5、常回顾，写给自己的周报周报是写给老板的，也是写给同事的，更是写给自己的。我们用话题知识库收集周报时，可以自动汇拢整理自己提交的周报内容，常回顾，翻一翻，能看到自己一点一滴的成长。以上就是阿里巴巴语雀团队的周报实践，也欢迎来语雀与十万阿里人一起沉淀知识。

发表了文章 2020-02-26

DataWorks 如何撑起阿里99%的数据开发？

阿里妹导读： DataWorks是阿里巴巴自主研发，支撑阿里巴巴经济体99%数据业务建设和治理，每天数万名数据开发和算法开发工程师在使用。从2010年起步到目前的版本，经历了多次技术变革和架构升级，也遗留了大量的历史包袱。技术的创新和业务的发展，相辅相成但也互为掣肘。存在需求接入慢，代码牵一发而动全身，环境复杂等问题，沉疴已久。历次迭代均未从根基上升级DataWorks，仅仅是一些性能提升、工程结构的优化，减少了重复代码等，并未促成根本性的技术革命。本文将探讨如何通过当前大热的微服务架构，来改变DataWorks平台的现实问题，从繁杂的工程中探索出一条切实可行的技术架构变革之路一、痛点让我们先来谈谈DataWorks当前遇到了哪些痛点，这些痛点是倒逼着我们进行技术变革的源动力。 1.1 沉重的历史包袱首先要提的就是历史原因遗留的各种问题，DataWorks历史上多个版本同步开发，前后端技术栈多次变革，应用一旦上线就很难废弃，一个对外暴露的api，很可能是5年前开发的，但依然有业务在依赖，通常情况下连这些古老业务的负责人都找不到了。当我们的服务正常运行的时候，无人搭理，一旦下线，则可能不知道从哪儿跳出几个用户前来投诉。页面上的功能同样如此，有时候只是过去不知道哪位同学开发中引入的一个bug，但也因为我们的用户基数庞大，而变成了真理。历史上曾经出现过的隐藏的很深且用户寥寥的功能点都有自己的忠实拥趸，一旦被我们的开发不小心忽视而做丢了，就会迎来投诉和工单，所以DataWorks平台不愧是千锤百炼磨练出来的大数据开发平台的标杆，朴素的界面之下隐藏了无数细致入微的功能点。如果想重造这么一个被阿里巴巴经济体无数数据开发工程师验证（折磨）过的数据开发平台，都要好好考虑一下这十年来我们的平台到底经历过了什么。 1.2 复杂的软硬件环境 DataWorks面临的运行环境放眼整个阿里巴巴经济体都是及其罕见的复杂，为了混合云（即专有云）这种私有独立且封闭的环境，三合一版本之后我们必须放弃依赖弹内成熟的中间件体系，只能寻找那些同样在三个环境下都存在的技术来支撑。也因此，很多在某个环境下缺失的依赖，如果我们无法用开关的方式搞定，或者我们判断其复杂度不高，就会通过自研或者去依赖一些开源的体系来解决问题。而公有云上各种网络环境的问题几乎都要靠人肉去排查，从每天居高不下的答疑量上就能看到我们受环境问题的影响是多么耗费人力。除此以外，前不久中美贸易战带来的影响也传递给了DataWorks平台，运行环境需要匹配国产芯片，我们的进程不但要运行在X86指令集上，同样也要能运行在基于ARM指令集的国产芯片上。同时为了满足部分中小企业用户的购买欲求，敏捷化也是我们需要去裁剪设计的。 DataWorks平台虽然庞大且复杂，但在种种更加复杂的软硬件环境下，也同样需要能够做到灵活轻便，便于随时随地的拆散组合轻装上阵，以满足不同业务场景下用户的期望。因为挑剔的用户一贯希望用最少的钱购买到最合适的解决方案，DataWorks的竞争力显然也要从灵活且具备演变能力上寻找未来。 1.3 牵一发而动全身工程之间的复杂关联一直是传统SOA（Service Oriented Architecture：面向服务架构）发展到一定规模后的噩梦，无论最初的设计是多么合理，多么领域清晰，一旦经历需求的积累，规模的扩张，人员的交替，都将逐步或多或少的面临着边界模糊的问题。最典型的例子就是单体服务之间的RESTful类型的API，往往这些API的Schema只能增加元素而不能减少，因为被依赖者并不知道有多少其他服务正在依赖这个接口，也许某一天某个服务从沉睡已久的服务器中被唤醒，结果发现你的API的Schema变了，那么一定会把你喊回来修回原来的样子。前后端分离架构下，这类问题更加突出，所以有的前端同学为了减少schema变动带来的影响，干脆让后端透传一个大字符串，即使里面夹带了私货，也不会使得页面莫名崩溃。DataWorks平台也正在经历着这一过程，发展到一定规模后，每个功能的改动都要小心翼翼，生怕对其他模块造成未知的影响，或者有时候我们需要把大量时间投入在调研清楚改动带来的影响上，就算这样严防死守，也依然可能有漏网之鱼，最后功亏一篑，一个故障单就可能把为之付出的努力付之一炬。 1.4 需求变更和频繁发布除了工程架构上的问题，同样存在问题的还有众多开发者在合作方面产生的问题，gitlab帮我们解决了版本之间的代码冲突问题，但并不能解决产品发布周期上的冲突。当多个需求都要对外发布上线，尤其在混合云，需要按月为周期产出大版本，我们一边要快速上线新feature，一边还要按照类似瀑布模型的方式将这些功能打包进专有云版本。弹内、公有云、混合云的发布节奏截然不同，众多feature按照不同的节奏要出现在不同的版本迭代中，过去的熔断机制，更加剧了大家在窗口期集中发布而产生的风险。在SOA中的一个单体服务上，N个开发者开发的M个feature，按照什么样的间隔组合发布上线，使得发布的节奏既不过于频繁，也不会因为发布频次太少而使得版本跨度太大。如果这M个feature之间又存在依赖关系，则进一步放大了发布频次增减之间的矛盾。 1.5 国际化带来的问题国际化的问题向来不简单，时区、夏令时、语言、习惯、本地化图标等等，对于DataWorks这样一个遍布全球20个region的平台来说，这里面的水深的很。我们团队在国际化方面沉淀很多积累，并且将这些优秀的经验对外开源：https://github.com/alibaba/react-intl-universal。 1.6 依赖耦合基于SpringBoot的Starter，我们提升了代码的复用率，且对于Starter的精心设计，确保同学们自研踩过的坑不需要反复由不同的同学来踩。但是这毕竟是不同工程中的共同依赖，当这些Starter暗藏bug的时候，凡是使用到这些依赖的工程都将受其影响，甚至某位同学不小心在修改某个依赖甚广的Starter的时候写进了bug，就有可能触发系统雪崩。 1.7 笨拙的灰度机制我们知道搜索引擎在不同的算法中寻找最优解的方法，是将这些算法灌装到不同的桶里，然后引流通过这些算法桶，通过各种指标的对比，将其中最优的算法挑选出来。这是一种基于架构设计的灰度机制，并不需要人为干预流量的导向，从入口处进来的不同搜索自然而然的就流过了不同的算法桶，随着海量的访问，最优解必然得以显现。但是目前的SOA架构下灰度往往依赖于提前设计好的开关，DataWorks便是如此，当我们需要验证某个功能是否存在问题，传统的办法是找到前端同学，让前端设计一下开关机制，筛选一部分用户进入到新设计的功能里面，经过一段时间的试跑和调整，逐步把问题解决掉，同时对用户的影响也可以控制在比较小的范围。但这显然不是一个可以反复的，随意的，自然而然的灰度机制。人为的干预，为灰度而耗费的设计开发，使得一次灰度的成本居高不下，有些时候我们的同学甚至因为想避免麻烦，而忽视做灰度验证。当我们想通过灰度来验证的功能非常的局部，或者用户无关，工作空间无关的时候，或者我们压根不知道哪些用户会使用到某些功能的时候，灰度机制也会在传统架构下失效，即使我们想去设计，也无从下手。对于SOA下单体服务来说，灰度无法借助于架构的设计，但是DataWorks平台下底层调度服务Alisa的Gateway集群由于机器数量庞大，也可以实现基于架构设计的灰度机制，几百台Gateway中，我们可以取出一小部分，部署待验证的新版本，任务下发后通过不同版本的比对，寻找潜在问题。但这并非DataWorks平台后端的常态，几乎所有单体服务并没有部署到这么多机器中，因此这也几乎是大多数SOA的状态，都面临着不能基于架构设计，而要基于人为干预的灰度机制。 1.8 外部关联服务的不确定性外部关联服务复杂多变，且不可靠不稳定，随时会宕机或者网络中断，甚至是外部服务升级忘了通知我们，从而导致故障频繁。这一点对于数据集成这样一个在几十种引擎，数千个数据库实例中搬运数据的应用来说尤其深有体会。为了应对外界服务的不确定性，我们将有众多依赖的自身应用设计的鲁棒性特别优异，然而这会增加我们自身代码的逻辑复杂度，偶然出现的问题也会被代码的鲁棒性掩盖，问题如果不及时处理，就会逐步积累，当所有出现故障的条件凑齐之后，一次性爆发一个P1级别的大故障。 1.9 紧缺的前端 DataWorks研发平台还面临着前端人手不足的问题，这是富交互产品的研发团队都面临的共通问题。前端受制于交互的不同，样式的迥异，业务的区别，以及研发同学各自对业务理解上的差异，以至于能够复用的前端组件极其有限。在浩如烟海的前端类库、组件、样式中，能够实现成本转移的寥寥可数。在前后端分离，基于主流前端框架的设计模式下，相较于历史上的前后端一体设计体系下的用户体验是有提升的，然而这都是基于前端开发同学辛勤的劳作，一点点的调整样式和交互换来的成果，这里从来没有捷径可走，而我们只能寄期望于能够复用前端开发同学的研发成果，让每一次设计都不要成为只使用一次的劳动。二、合作与竞争 DataWorks研发平台众多功能涵盖了数据开发工程师的日常工作，用户在我们的平台上长年累月的伏案工作，对一些功能点的设计有自己的切身体感，而这些体感是我们平台的研发感受不到的。PD和我们的UED去收集需求去使用去亲自感受，然而毕竟不是专职于数据开发本身，因此很难体会到数据开发工程师长期使用后的那种细微的挫败感。再到细分的垂直业务市场，不同行业下如何使用我们平台，差异更是有天渊之别。面向金融，银行，政府，大型国企，互联网公司，传统企业，民营，教育，等等，他们的用法都是完全不同的，有的行业甚至就不知道拿到DataWorks平台后该做什么。用户的需求千差万别，用户的心智也处于不同阶段。因此，在我们无暇一一顾及的领域，前方的交付团队或者公司，使用DataWorks平台应用到具体的行业中，然后再将行业的专属需求带回给我们的PD进行分析。我们平台本身也会开放一些Api给予前方团队包装成产品提供给特定领域的客户，帮助客户解决实际问题。新的产品规划还在不断制订之中，引擎团队设计好自己的产品也需要在DataWorks平台上降低用户的上手难度，如果永远只是DataWorks平台的开发同学按照排期逐步完成这些接入和订制需求，平台注定难以持续发展壮大。因此，从前后端架构层面，从无数的合作和竞争场景出发，都迫切需要我们进行一次针对自身的技术革命，彻底从SOA中解放生产劳动力，引入更多的用户侧的研发力量，帮助平台向更健全的方向发展。三、架构的变革任何一种技术的变革都是循序渐进的，这和Spring之父Rod Johnson秉持的理念是一致的。他提出了“轮子理论”，也即“不要重复发明轮子”，这是西方国家的一句谚语，原话是：Don't Reinvent the Wheel。除此之外，通过长期的实践后他在著作中总结阐明了循证架构的思想，即“没有最好的架构，只有最合适的架构”。这是架构界进化理论的雏形，意味着我们的架构要不断的演进去配合多变的业务需求。传统的SOA下，服务趋向于稳定和集中，单体服务之间是平等的，或者至少在共通的结构上是类似的，服务与服务之间通过网络通信进行依赖。SOA下每个单体服务可能是多个开发者围绕着进行合作开发，因此替换任何一个单体服务都是一件伤筋动骨的事情，当有大的技术栈的变革，例如从WebX 3.0升级到SpringMVC，从SpringMVC升级到SpringBoot，人力成本消耗都是巨大的，升级周期动辄以年为单位，更不用说假设我们想用Go语言或者Python的Django框架来替换J2EE体系下已经设计好的web服务，这几乎是不可能完成的任务。也意味着当我们进入了这个技术体系，就很难再从这套体系中脱身，更无从谈起架构的演变和进化。在传统SOA下，提升工程效率的手段是极致的代码复用，凡是可复用的代码，都抽取到二方包中设计成类库让不同的单体服务依赖调用。虽然配置越来越复杂了，但的确减少了“重复发明轮子”的事情。还有一个办法，是如我在2015年时候尝试新的架构设计时候采取的方法，即：能抽象成二方包的抽象，不能抽象的通过自动化代码生成工具自动生成。一套演练成熟的SOA架构工程，从目录结构到配置组装都几乎是稳定不变的，即使有变化，也都是按照MVC三层架构进行微调，因此我们可以把一些无法抽象的，或者包含了复杂逻辑，需要灵活调整的代码通过自动化代码生成工具来生成，并且尽可能冗余代码的功能，让开发者从生成的工程代码中尽量做减法或者根据业务逻辑只修改最少量的代码，从而提升了工程的整洁度和开发效率。除了代码的复用，还有服务的复用，我们设计了一些中心化的单体服务，用于将复杂逻辑或启动较慢或需要缓存，等等这样一些功能封装在这些核心服务中，进一步减少围绕中心服务的其他应用的体量和复杂度，当然这也可能会引入单点可靠性的问题，但要确保核心服务的稳定可靠，在一定规模的服务体量下并非难事。即便如此，SOA在效率上的提升依然是有限的，初期工程建立的快速高效并不代表长期业务开发后还能维持这样的效率持续发展。前文描述的痛点逐步展现且缺乏行之有效的解决办法，开发者由于整齐划一的使用同一套技术栈甚至同一套工程目录树结构，虽然在协同的时候更加默契，但也消灭了前沿技术在团队内的赛马机制。研发同学在一套逐渐古老落后的框架下研究怎么压榨出最后的效率和性能，但往往忽视了也许换个框架换个技术栈甚至换个语言，就会带来质变。因此，当基于谷歌的K8S体系成长的生态圈逐步成熟之后，遵循“没有最好的架构，只有最合适的架构”的思想，我们开始思考如何将DataWorks的技术方向转向灵活多变的微服务架构。 3.1 微服务架构提到微服务，理所当然要和云原生关联，所谓云原生（Cloud Native），包含了如下三点： 1）DevOps 开发和运维不再是分开的两个团队，而是你中有我，我中有你的一个团队。 2）持续交付持续交付的意思就是在不影响用户使用服务的前提下频繁把新功能发布给用户使用。 3）容器化容器化的好处在于运维的时候不需要再关心每个服务所使用的技术栈，每个服务都被无差别地封装在容器里，可以被无差别地管理和维护。满足上述三点的云原生环境，对于微服务来说天然适配。当一个产品发展到一定规模，且具备了足够体量，拥有数量众多的子产品，以至于交互和依赖关系日益复杂，则微服务架构将为这样的产品下的工程群带来显然易见的好处。本文不对微服务的基本概念和泛泛的常规做法做详细介绍，网上此类文章汗牛充栋，这里仅推荐两本不错的书《微服务设计》（前几章概念讲解还可以，后面部分一般）和《微服务架构设计模式》，前者适合初步了解，后者适合进阶。本文仅讨论DataWorks在新的架构下的做法，从实践中得真知。对于DataWorks研发平台下众多产品应用来说，微服务架构方向的改造也许不是能破解所有问题的万能钥匙，但一定是当前开发模式所遭受的病痛的解药。 ★ 3.1.1 认清自身 DataWorks研发平台属于典型的PaaS应用，当然也有数据服务这样的产品做到了SaaS层。传统SOA遇到的痛点，以及将来我们要对客户开放的定制化能力，需要借助微服务架构来应对，逐步将研发重心从PaaS移向SaaS。当我们采用基于K8S容器化的微服务架构之后，开发者可以在我们自主研发的微服务平台中集成DataWorks平台开放出来的基础OpenAPI，也可以集成外部应用的API，在微服务中进行数据整合和业务逻辑的编写，最终暴露出一系列在平台前端可访问的API，供前端功能模块使用。在这个过程中，我们可以顺便化解前文提到的一些痛点。 ★ 3.1.2 解决痛点以历史包袱为例，我们可以逐步将年久失修的，陈旧的SOA单体服务中包含的功能进行替换，将这个快变质的大饼切割成一个个低耦合的小饼，实现逐步的更替，而非采用长周期的一次性整体替换。陈旧的工程不必再去发展更新，仅维持基本的运行，避免了整体替换带来的周期长，故障多，回滚困难的问题。而且我们可以很方便的通过金丝雀发布来验证新上的“小饼”是否成功替代了“变质大饼”中一小部分模块的功能，通过蓝绿部署将有问题的小饼快速及时的撤下，也可以做到通过ABTest来验证哪块小饼的性能更好、设计更合理。再以个性化需求为例，当我们开放了和DataWorks业务耦合的微服务平台，具备自研能力的业务团队（如数据/报表开发团队）就可以借助微服务的设计，快速的将自己的需求设计到我们DataWorks平台后端，同时前端页面我们也会留出“自留地”（下文描述的插件化）供业务团队自行设计开发。引擎的接入同样可以参照此模式进行，DataWorks下一部分模块的接入可以更加的傻瓜化，比如检查器，比如功能强大的自定义节点等，用户根据文档经过简单的开发后就可以快速自主接入使用，但对于更加订制的功能，例如当前ADB引擎正在DataWorks平台上进行的可视化建表部分的设计，由于复杂度很高，因此必须通过微服务对接前端插槽（下文描述）来进行开发，从而实现复杂业务逻辑的自主自助接入。再来描述一下基于架构的灰度机制，在微服务架构下，可以轻松的实现蓝绿部署，金丝雀发布和ABTest，我们的微服务设计应该是尽量面向领域的（当然不太可能做到100%的面向领域），高内聚低耦合依然是单个微服务的设计宗旨。我们可以发布多个版本的微服务用来测试某个领域的问题是否得到某方面的改善，也可以发布多个完全基于不同框架甚至是不同语言设计的微服务，来验证某个领域内谁是最优解。借助于基于架构的灰度机制，基于云原生，这一切都将非常高效且可靠，即使出现问题，也可以快速撤下有问题的微服务，避免扩大影响。还有其他一些痛点，不一一描述基于微服务架构的解法，比如牵一发而动全身的问题，在DataWorks平台全面构建到微服务架构上之后，这个问题自然就会消失。每个同学都可以分管多个面向领域的足够小的微服务，当某个接口需要重新设计，不必立即替换老的接口，而可以将这个接口下对应的微服务低成本的重新设计，等待流量切换到新的微服务后，再逐步下线旧版本微服务。再比如SpringBoot下由Starter引入的耦合性，到了微服务框架下，将会通过服务发现来解耦，不再需要通过代码层面的依赖来耦合关联。 ★ 3.1.3 循证架构再回过头来讲讲本文还没提及的一块内容，我们的微服务到底是什么？微服务当然不是一定要以微小为特征，它还是一个SOA，只不过会更加轻量级更加面向领域。以机器人工厂为例，该产品有一个功能是让用户配置一些意图跳转到用户自己设计的应答逻辑中，这部分正在拥抱微服务架构，完成上线后，用户可以根据输入来设计自己的应答微服务，且语言无关。这样做还可以避免用户的微服务在设计不良的情况下崩溃，不至于影响到其他正在运行的微服务，机器人工厂的这个场景也可以设计成FaaS，用户只需要编写函数就可以完成自己的应答逻辑，且按访问量来计量使用情况。 DataWorks团队设计的微服务平台，充分拥抱了现在大热的Service Mesh，即服务网格，通过Mesh将一部分工作封装在前置的微服务里，这些系统级微服务与开发者设计的微服务运行在同一个pod里，使得开发者设计的微服务更加简单，Mesh更像是Spring框架下的HandlerInterceptor或者Filter，面向AOP编程的开发者擅长在工程里开发拦截器和过滤器，到了集成了Service Mesh的微服务框架下，可以方便的使用系统级微服务替代一部分传统拦截器的工作。比如登陆跳转、权限控制、服务发现，比如限流、监控、日志聚合等等。让业务专注于业务本身，避免诸如登录配置、日志配置等对工程开发的干扰，同时我们还设计了不同语言的DMF（DataWorks MicroService FrameWork）框架群，帮助开发者快速上手微服务的开发。“没有最好的架构，只有最合适的架构”，将来我们也会开放DMF的开发设计，让更多业务方贡献自己的“最合适的微服务框架”。为了更好的支持和我们业务强相关的DevOps，我们开发了DataWorks微服务平台（DMSP：DataWorks MicroService Platform），用于管控微服务的部署和发布，以及服务治理等其他运维工作。 3.2 前端的体系配合前面提到的插件化指的是我们前端团队设计的XStudio插件化方案，插件结合后端微服务，成为一套整体的解决方案，DataWorks平台的前端团队希望基于此，尝试探索出一套提升前端研发效率的方法论。XStudio插件化基于 single-spa 和 qiankun框架实现。该框架提供了多实例模式，插槽机制和可视化插件编排等重要特性，进一步提升了插件开发的效率。整套插件化的示意图如下：前端同学在基于XStudio插件化设计的页面上，留好插槽，插槽里面可以是一个按钮，也可以是其他任意类型的组件，这个组件后面绑定一个微服务，我们可以将插槽里面的内容连同后端的微服务一并替换，实现页面功能的快速组装，从而实现一次开发的多处使用。同时，插槽里的内容也可以由业务开发团队来提供，那么业务开发团队也只需要自行设计前后端一体的这样一个插件来放置到前端插槽里，实现个性化需求的订制开发。在传统的插件化设计里，开发者们要么提供一个遵循某种接口协议的二方包、要么提供一系列遵循某种协议的API再由SOA架构向前端输出。这带来的问题要么是对SOA服务有侵入，要么影响了SOA服务整体的安全性和稳定性问题，要么受限于编程语言、要么毫无灵活性，而微服务&插件化完美的解决了这类问题。对于需要占用更多页面空间的设计，我们可以将大片区域设置成可替换组件，比如上图的编辑器部分，让用户自行替换掉这片区域的页面内容，跟后端一个或者多个微服务关联起来嵌入到DataWorks的前端页面中，方便业务团队实现更复杂的自定义业务逻辑。当前ADB的可视化建表部分的设计正是遵循了这套方案，由ADB引擎团队自行开发接入DataWorks平台中。同时，前端体系中还有重要的一环是受访的数据监控和报警，我们设计了各种维度的报表和指标监控，无论是自己的业务还是外部业务团队写进来的组件，不用多写一行代码，都可以通过“自动化全量埋点技术”，观察和了解组件的使用情况。 3.3 插件的运行当前我们已经将部分前端基于XStudio架构的组件与后端微服务配合起来实现了插件化封装，比较优秀的如Terminal，DWEditor，目录树，检查器等插件。以Terminal为例，该插件设计完成后，插入到不同的Studio中对接不同的引擎，并且可以根据用户的使用情况自动拉起或者销毁容器实例，从而节省运行资源。 Terminal插件接入到多个引擎，无论是前端还是后端的微服务都不用针对引擎进行额外的开发，从而实现开发效率的提升。插件化的封装设计，不仅可以节约开发资源，而且可以实现多个应用集中使用一套微服务的目的，而弹性编排和自动扩缩容机制保证了服务的性能，同时不至于浪费机器资源。此外，基于微服务架构，我们还可以构建SaaS的一些实现，例如FaaS、BaaS（Backend as a Service），以及BFF（Backend For Frontend）。以BFF为例，移动端的DataWorks应用BFF后，可以减少移动端H5页面的网络消耗，将后端多个微服务提供的接口通过Gateway组装后提供给移动端，实现微服务的聚合。如果通过BFF做了SSR（Server Side Render：页面同构，相当于在服务器端直接渲染成html输出到浏览器），则可以进一步降低移动端的渲染性能消耗。 ★ 3.3.1 DataWorks微服务平台前后端一体基于DataWorks业务的插件化，也是我们坚持要自研设计开发DataWorks微服务平台（DMSP：DataWorks MicroService Platform）的重要原因。DMSP打通了前端组件的发布和后端微服务的绑定关联，通过Swagger这样的技术手段成功使得前后端在部署后可以迅速成为一个业务插件。让团队的前后端都可以在DMSP里面实现DevOps，以持续交付的方式源源不断的将新功能发布给客户。尤其值得说明的是，DMSP同样是针对三大环境的，即弹内、公有云和混合云，插件开发完成后，我们要通过DMSP持续交付到公有云多达20个region的环境中，还要能够实现微服务在专有云的统一打包部署。并且，DMSP还要让开发插件的同学尽量对复杂的外界部署环境无感。未来我们期望整个DataWorks平台的大部分页面内容都基于插件化设计，从而解决前文痛点里面提到的问题：“灵活轻便，便于随时随地的拆散组合轻装上阵”。架构驱动的不仅仅是开发模式，而且势必还将影响到整个产品的蓝海。四、构造生态构造生态的重要前提是要有竞争，要有优胜劣汰，构造生态的同时就是在构造可以演变，可以适用进化论的技术体系。作为“循证架构”的升华，微服务架构显然在进化方面更胜一筹，循证架构是一种自上而下用进废退的技术演进路线，而微服务架构则是一种自下而上优胜劣汰的技术演进路线。容器化实现了语言无关，框架无关，每个微服务都被无差别地封装在容器里，从而可以针对一个功能开发出多种微服务，类似算法桶的优选机制，从这些完成同一个功能的微服务中挑选出最优解。在理想情况下，无需上层架构师的主动干预，应用就可以在一段时间的进化后自组装成最佳的实践。当然这只是理论上的情形，我们身处的现实世界受很多外界因素的干扰，实际情况下，受限于开发者的技术素养、外界依赖的参差不齐，甚至是受限于KPI的导向，都将使得这种理想下的最佳实践无法达成，但微服务架构给予了我们可以通过团队的协作和努力，从而无限接近理论中的最终解的能力。在微服务架构下，前文提到的垂直业务的定制开发也将成为一种可能性，面向行业的交付团队可以利用DataWorks平台提供的插件化能力，为客户订制完全适配行业特征的智能研发平台。进而在DataWorks研发平台上营造一个有活力的创新生态圈，为客户提供更加丰富多彩的选择。架构将驱动整个生态圈的优胜劣汰，从而不断向更有竞争力的方向进化。我们DataWorks研发团队也寄期望于在这套架构之上，实现弹内弹外的共赢模式的合作，推动云智能事业群下的产品形成合力。五、前后端组合拳所谓架构，不仅是技术上的事情，同时也要对人力的分配组织提供整套的指导方案。在应用了微服务架构之后，DataWorks研发团队的职责显然不能仅仅局限于日常的需求开发，作为微服务架构的倡导者，在推进架构的同时我也对团队的前后端职责进行了思考。首先前后端需要拉出一个框架小组，通过指导前端组件和后端微服务的设计来影响整个架构的进化，团队内需要有关注面向领域设计的研讨，分析每个插件是否是领域性的，同时需要有把关的同学，审核第二方（弹内非本团队的开发者）和第三方（弹外的交付团队或者来自客户的行业开发者）提交的插件设计，防止不良应用破坏体系构建。同时，微服务架构由于语言无关性，还抹平了一些技术上的鸿沟，前端同学很多擅长nodejs，也可以在微服务的设计中一展身手，更使前后端在技术上的交流和沟通会更加有默契。我们的产品线中还有一个特殊的产品：AppStudio，专职于WebIDE的研发工作，将来无论是数据服务提供的数据出口，还是FaaS里的函数，还是微服务本身的开发，都可以与AppStudio结合，由用户自主开发，可以完全不用脱离DataWorks全域大数据平台，就从数据开发到报表设计，再通过微服务编写业务逻辑，达成数据输出的目标，一站式完成用户的订制需求。上图是未来的团队职责分工的一个构思，前后端研发同学在这套组织架构下，打出一套组合拳，直击痛点问题，帮助用户攻克技术难关，实现生态的繁荣昌盛。六、展望未来技术和架构的未来是什么样子的？在我的理想中，软件工程的研发技术应该是一个没有止境和边界，且越来越智能化的领域。DataWorks的产品中已经有很多开始向智能化的方向前进，比如基于VSCode应用了Markov算法的智能编程插件。研发团队的未来很大程度上取决于体系的架构，我们应该鼓励创新，鼓励对技术前沿和边界的探索，不应该人为的制造太多规约从而限制了思考的天马行空。如果有一天，智能化编程终于开始替代人工开发，那么通过改变架构的设计，研发人员也一定可以在新的架构中寻找到新的职责。世界是变化的，也是有规律的，我们的技术愿景应当是为这个变化的世界构建出成熟且不断进化的工程体系。面向未来，拥抱变化，为了无法计算的价值！欢迎识别下方二维码，了解团队信息，加入飞天大数据交流群和DataWorks产品进行交流！

发表了文章 2020-02-25

打破重重阻碍，Flutter 和 Web 生态如何对接？

阿里妹导读： Flutter 设计之初是不考虑 Web 生态的，原因很简单：两种技术设计理念不同，强行融合很可能让彼此都丧失了优势。但是业界又有很多团队在做这种尝试，说明需求是存在的。今天，阿里无线开发专家门柳就来手把手教如何实现 Flutter 和 Web 生态的对接？先说结论：不要对接！不要对接！不要对接！开个玩笑，以上仅代表个人观点，大家也知道这种“三体式警告”根本没有用的，我自己也研究如何对接，说不定做完后就觉得“真香”了。为什么要对接？首先讨论一下为什么要把 Flutter 对接到 Web 生态。 Flutter 现在是一个炙手可热的跨平台技术，能够一套代码运行在 Android、iOS、PC、IoT 以及浏览器上，被认为是下一代跨平台技术。相比于 Weex 和 React Native 可以很好地解决多平台一致性问题，原生渲染性能相近，上层没有 JS 那么厚的封装层次，整体性能会略好一些。但是大部分兴冲冲去学 Flutter 的人疑惑的第一个问题就是：为什么 Flutter 要用 Dart？一个全新的语言意味着新的学习成本，难道 JS 不香吗？JS 不香不是还有 TypeScript 吗！事实上 Flutter 抛弃的岂止是 JS 这门语言，也抛弃了 HTML 和 CSS，设计了一套解耦得更好的 Widget 体系，Flutter 抛弃的是整个 Web，致力于打造一个新的生态，但是这个生态无法复用 Web 生态的代码和解决方案。尤其是之前所有跨平台方案 Hybrid、React Native、Weex 都是对接 Web 生态的，这让 Flutter 显得有些格格不入，也让大部分前端开发者望而却步。下面是我整理出来的，前端开发者使用 Flutter 的各方面成本：因为 Flutter 的开发模式和前端框架比较像（可以说就是抄的 React），所以框架的学习成本并不高，稍微高一些的是 Dart 语言的学习成本，另外还要学习如何用 Widget 组装 UI，虽然很多布局 Widget 设计得和 CSS 很像，灵活度还是差了很多。要想在真实项目中用起来，还要改造整个工具链，以“Native First”的视角做开发，开发 Flutter 和开发原生应用的链路是比较像的，和开发前端页面有较大差异。最高的还是生态成本，前端生态的积累无论是代码还是技术方案都很难复用，这是最痛的一点，生态也是 Flutter 最弱的一环。无论是为了先进的技术理念还是出于商业私心，先不管 Flutter 为什么抛弃 Web 生态，现实问题是最大的 UI 开发者群体是前端，最丰富的生态是 Web 生态，我觉得 Web 技术也是开发 UI 最高效的方式。如果能在上层使用 Web 技术栈开发，在底层使用 Flutter 实现跨平台渲染，不是可以很好的兼顾开发效率、性能和跨平台一致性吗？还能复用 Web 技术栈大量的技术积累。可能这些理由也不够充分，暂且先照着这个假设继续分析，最后再重新讨论到底该不该对接。关于 Flutter 和 Web 生态的对接涉及两个方面：从 Web 到 Flutter。就是使用 Web 技术栈来开发，然后对接到 Flutter 上实现跨平台渲染。对 Web 来说是解决性能和跨平台一致性问题，对 Flutter 来说是解决生态复用问题。从 Flutter 到 Web。就是官方已经实现的 Web support for Flutter，把已经用 Dart 开发好的 App 编译成 HTML/JS/CSS 然后运行在浏览器上，可以用于降级和外投场景。如何实现“从 Web 到 Flutter”？首先分析一下 Flutter 的架构图，看看可以从哪里下手。 Flutter 可以分为 Framework 和 Engine 两部分，Engine 部分比较底层也比较稳定了，最好不要动，需要改的是用 Dart 实现的 Framework。要想对接 Web 生态的话，JS 引擎肯定是要引入的，至于是否保留 Dart VM 有待讨论。图中最上面 Material 和 Cupertino 两个 UI 库前端是不需要的，前端有自己的。关键是 Widget 这部分，是替换成 HTML/CSS 的方式写 UI，还是继续保留 Widget 但是把语言换成 JS，不同方案给出的解法也不一样。有不少方案可以实现对接，业界有挺多尝试的，我总结了下面三种方式： TS 魔改：用 JS 引擎替换掉 Dart VM，用 JS/TS 重新实现 Flutter Framework（或者直接 dart2js 编译过来）。 JS 对接：引入 JS 引擎同时保留 Dart VM，用前端框架对接 Flutter Framework。 C++ 魔改：用 JS 引擎替换掉 Dart VM，用 C++ 重新实现 Flutter Framework。 TS 魔改 TS 魔改就是完全抛弃掉 Dart VM，用 TypeScript 重新实现一遍用 Dart 写的 Flutter Framework。为啥是 TS 而不是 JS？这不是因为 TS 是个大热门嘛，而且向下兼容 JS，现在几乎所有时髦的框架都要用 TS 重写了。这种方案的出发点是“如果能把 Flutter 的 Dart 换成 JS 就好了”，最容易想到的路就是把 Dart 翻译成 TS，或者直接用 dart2js 把代码编译成 js，但是编译出来的代码包含很多 dart:ui 之类的库的封装，生成的包也挺大的，也比较难定制需要导出的接口，不如干脆用 TS 重写一遍，工具链更熟悉一些，还可以加一些定制。理论上讲翻译之后 Flutter 绝大部分功能都依然支持，可以复用各种 npm 包，还可以动态化，但是丧失了 AOT 能力，JS 语言的执行性能应该是不如 Dart 的。而且所有节点的布局运算都发生在 JS，底层只需要提供基础的图形能力就好了，就好像是基于 Canvas API 写了一套 UI 框架，性能未必有现存前端框架的性能高。此外最大的问题是如何与官方 Flutter 保持一致，假如现在是从 v1.13 版本翻译过来的，以后官方升级到了 v1.15 要不要同步更新？这个过程没啥技术含量，而且需要持续投入，做起来比较恶心。另外还需要考虑上层是用 Widget 的方式写 UI，还是用前端熟悉的 HTML+CSS。如果依然用 Widget 的话，那大部分前端组件还是用不了的，UI 还是得重写一遍。反正要重写的话，成本也没降下来，那就用 Dart 重写呗…… 直接用官方原版 Flutter 也避免每次更新都要翻译一遍 Dart 代码。所以既然选择了对接前端生态，那就要对接 CSS，不然就没有足够的价值。然而 CSS 和 Widget 的对接也是很繁琐的过程，而且存在完备性问题。 JS 对接翻译代码的方式不够优雅，那就保留 Dart，把 JS/CSS 对接到 Widget 上面不就好了？当然可以，这种方式是仅把 Flutter 当做了底层的渲染引擎，上层保持前端框架的写法，仅把渲染部分对接到 Flutter。现存的很多前端框架都把底层渲染能力做了抽象，可以对接到不同渲染引擎上，如 Vue/Rax 同时支持浏览器和 Weex，用同样的方式，可以再支持一个 Flutter。这种方式对前端框架的兼容性比较好，但是链路太长了，业务代码调用前端框架接口做渲染，一顿操作之后发出了渲染指令，这个渲染指令要基于通信的方式传给 Flutter Framework，这中间涉及一次 JS 到 C++ 再到 Dart 的跨语言转换，然后再接收到渲染指令之后还要转成相应的 Widget 树，从 CSS 到 Widget 的转换依然很繁琐。而且 Widget 本身是可以带有状态的，本身就是响应式更新的，在更新时会重新生成 widget 并 diff，如果在前端更新 UI 的话，前端框架在 js 里 diff 一次 vdom，传到 Flutter 之后又 diff 一次 widget。如果要绕过 Widget 直接对接图中的 Rendering 这一层，可以绕过 widget diff 但是得改 Flutter Framework 的渲染链路，既然要改 Flutter Framework 那为什么不直接用 TS 魔改呢，还绕过了 JS 到 Dart 的通信，又回到了第一种方案。总结来说，这个方案的优点是：实现简单、能最大化保留前端开发体验，缺点是：渲染链路长、通信成本高、响应式逻辑冲突、CSS 转 Widget 不完备等。 C++ 魔改想要干掉 Dart VM，就需要用其他语言重新实现用 Dart 开发的 Framework，用 JS/TS 可以，用 C++ 当然可以，最硬核的方式就是用 C++ 重新实现 Flutter 的 Framework，然后接入 JS 引擎，通过 binding 把 C++ 接口透出到 JS 环境，上层应用还是用 JS 做开发。把 Framework 层下沉到 C++ 之后，不仅会有更好的性能，也能支持更多语言。原本 Flutter Framework 是在 Dart VM 之上的，必须依赖 Dart VM 才能运行，所以对 Dart 有强依赖；用 C++ 重新实现之后，JS 引擎是在 C++ 版 Framework 之上的，框架本身并不依赖 JS 引擎，还可以对接其他各种语言，如对接了 JVM 之后可以支持 Java 和 Kotlin，对接回 Dart VM 可以继续支持 Dart。这个方案可以增强性能，也能保持和 Flutter 的一致性，但是改造成本和维护成本都相当高。C++ 的开发效率肯定不如 Dart，当 Flutter 快速迭代之后如何跟进是很大的问题，如果跟进不及时或者实现不一致那很可能就分化了。从 CSS 到 Widget 的转换也是不得不面对的问题。几种方案对比把上面几种方案画在同一张图里是这个样子的：图中实线部分表示了跨语言的通信，太过频繁会影响性能，虚线部分表示了其他对接可能性。从下到上，Flutter Engine 是不需要动的，这一层是跨平台的关键。Framework 则有三种语言版本，JS/TS、Dart、C++，性能是 C++ 版本最好，成本是 Dart 版本最低。然后还需要向上处理 HTML/CSS 和 Widget 的问题，可以直接对接一个前端框架，也可以直接在 C++ 层实现（不然需要透出的 binding 接口就太多了，用通信的方式也太过频繁了）。如何实现“从 Flutter 到 Web”？这个功能官方已经实现了，可以把使用 Dart 开发的 App 编译成 Web App 运行在浏览器上，官方文档以介绍用法和 API 为主，我这里简单分析一下内部具体的实现方案。实现原理结合 Flutter 的架构图来看，要实现 Web 到 Flutter 需要改造的是上层 Framework，要实现 Flutter 到 Web 需要改造的则是底层 Engine。 Framework 对 Engine 的核心依赖是 dart:ui，这是库是在 Engine 里实现的，抽象出了绘制 UI 图层的接口，底层对接 skia 的实现，向上透出 Dart 语言的接口。这样来看，对接方式就比较简单了：使用 dart2js 把 Framework 编译成 JS 代码。基于浏览器的 API 重新实现 dart:ui，即 dart:web_ui。把 Dart 编译成 JS 没什么问题，性能可能会有一点影响，功能都是可以完全保留的，关键是 dart:web_ui 的实现。在原生 Engine 中，dart:ui 依赖 skia 透出的 SkCanvas 实现绘制，这是一套很底层的图形接口，只定义了画线、画多边形、贴图之类的底层能力，用浏览器接口实现这一套接口还是很有挑战的。上图可以看到 Web 版 Engine 是基于 DOM 和 Canvas 实现的，底层定义了 DomCanvas 和 BitmapCanvas 两种图形接口，会把传来的 layer tree 渲染成浏览器的 Element tree，但是节点上仅包含了 position, transform, opacity 之类的样式，只用到 CSS 很小的一个子集，一些更复杂的绘制直接用 2D 实现。存在的问题我编译了一个还算复杂的 demo 试了一下，性能很不理想，滑动不流畅，有时候图片还会闪动。生成出来的 js 代码有 1.1MB (minify 之后，未 gzip)，节点层次也比较深，我评估这个页面用前端写不会超过 300KB，节点数可以少一半以上。另外再看一下 Flutter 仓库的 issue，过滤出 platfrom-web 相关的，可以看到大量：文字编辑失效、找不到光标、ListView 在 ios 上不可滚动、checkbox/button 行为不正常、安卓滚动卡顿图片闪烁、字体失效、某些机型视频无法播放、文字选中后无法复制、无法调试…… 感觉 flutter for web 已经陷入泥潭，让人回想起前端当年处理各种浏览器兼容性的噩梦。这些性能和兼容性问题，核心原因是浏览器未暴露足够的底层能力，以及浏览器处理手势、用户输入和方式和 Flutter 差异巨大。实现 Flutter Engine 需要的是底层的图形接口和系统能力，虽然提供了相似的图形接口，如果全部用 canvas 实现的话很难处理可访问性、文本选择、手势、表单等问题，也会存在很多兼容性问题。所以真实方案里用的是 Canvas + DOM 混合的方式，封装层次太高了，渲染链路太长。就好像 Flutter Framework 里进行了一顿猛如虎的操作之后，节点生成好了、布局算好了、绘制属性也处理好了，就差一个画布画出来了，然后交到浏览器手里，又生成一遍 Element，再算一遍布局，在处理一遍绘制，最终才交给了底层的图形库画出来。再比如长页面的滚动，浏览器里只要一条 CSS (overflow:scroll) 就可以让元素可滚动，手势的监听以及页面的滚动以及滚动动画都是浏览器原生实现的，不需要与 JS 交互，甚至不需要重新 layout 和 paint，只需要 compositing。如上图所示，在 Flutter 中 Animation 和 Gesture 是用 Dart 实现的，编译过来就是 JS 实现的，浏览器本身并不知道这个元素是否可滚，只是不断派发 touchmove 事件，JS 根据事件属性计算节点偏移，然后运算动画，然后把 transform 或者新的 position 作用到节点上，然后浏览器再来一遍完整的渲染流程…… 优化方案性能和兼容性的问题还是要解决的，短期内先把 issue 解掉，长线的优化方案，官方有两种尝试： 1、使用 CSS Painting API 做绘制。a、这是还处于提案状态的新标准，可以用 JS 实现一些绘制功能，自定义 CSS 属性。b、目前还未实现，需要等浏览器先把 CSS Houdini 支持好。 2、使用 WebAssembly 版本的 Skia 做绘制。https://skia.org/user/modules/canvaskita、这样可以发挥 wasm 的性能优势，并且保持 skia 功能的一致。但是目前 wasm 在浏览器环境里未必有性能优势，这里不展开讨论了。b、已经部分实现，参考这里的配置启用功能： https://github.com/flutter/flutter/issues/41062#issuecomment-533952994 这两个方案都是想更多的利用到浏览器的底层能力，只有浏览器暴露了更多底层能力，才能更好的实现 Flutter 的 Web Engine。不过这个要等挺久的时间，我们也参与不了，现阶段想要使用 flutter for web，还是得保持现有架构，一起参与进去把 issue 解决掉，优先保障功能，其次优化性能。一种适应性更好的架构如果理想化一点，能不能从架构角度让 Flutter 和 Web 生态融合的更好一些呢？回顾文章最开始的官方架构图，上面是 Framework(Dart)，下面是 Engine(C++)，切分在 Foundation 这一层，双方之间的交互是几何图形信息。如果还保持这个架构，把切分层次划分的更靠上一些，如下图所示，划分在 Widgets 和 Rendering 这一层，理论上讲对 Flutter 的开发者来说是无感知的，因为上层的开发语言和 Widget 接口都是不变的。切分在这一层，Framework 和 Engine 之间的交互就不再是几何图形而是节点信息，Widget 的组合、setState 响应式更新、Widget diff 都还在 Dart 中，展开后的 RenderObject 的布局、绘制、裁剪、动画全都在 C++ 中，不仅有更好的性能，还可以与 Engine 有更好的结合。或者说，还原本保留 Engine 的设计，把下沉的这部分逻辑上划分成 Renderer，就有了如下三层的结构：这样划分出来的每一层都有明确的定位： Framework: 开发框架。为开发者提供可编程 API，实现响应式的开发模式，提供细粒度 Widget 供开发者自由封装和组合。Renderer: 渲染引擎。专门实现布局、绘制、动画、手势的的处理，这部分功能相对独立，是可以与开发框架解耦的，也不必与特定语言绑定。Engine: 图形引擎。实现跨平台一致的图形接口，合成输入的层并绘制到屏幕上，处理好平台力的接入和适配。这样切分除了有性能优势以外，也使得渲染引擎摆脱了对 Dart 的依赖，能够支持多种语言，也能支持多种开发模式。对接到 Dart VM 就可以用 Dart 写代码，对接到 JS 引擎就可以用 JS 写代码，对接到 JVM 还可以写 Java，但是无论怎么写，底层的渲染能力是一样的，一套统一的布局算法，动画和手势的处理行为也是一致的。在这样的架构下，对接 Web 生态就更容易了。Dart 和 Widget 是前端不想要的，希望能换成 JS 和 CSS，但是又想要底层的跨平台一致渲染引擎，那从 Renderer 层开始对接就好了，绕过了所有不想要的，也保留了所有想要的。要实现 Flutter for Web 也更简单了一些。在 Engine 层做对接，一直苦于浏览器透出的底层能力不够，如果是在 Renderer 之上做对接就更容易一些，基于 JS/CSS/DOM/Canvas 的能力封装出一套 Rendering 接口，供 Widget 调用就好了，这样可以使渲染链路更短一些，但是依然要处理 Widget 和 DOM/CSS 之间的兼容性问题。再讨论一遍：为什么要对接？技术上已经分析完了，要想搞定 Flutter 生态和 Web 生态的对接，需要投入很大的成本，所以真正决定做之前，要先讨论清楚为什么要做对接？到底要不要做对接？首先 Google 官方对 Flutter 的定位就是个问题。Flutter 设计之初就是不考虑 Web 生态的，甚至在刻意回避，倡导的是更贴近原生的开发方式。我之所以在开头说不要对接，原因也很简单：两种技术设计理念不同，不是朝着一个方向发展的，生态不通，技术方案不通，强行融合很可能让彼此都丧失了优势。但是业界又有很多团队在做这种尝试，说明需求是存在的，如果 Google 抵制这个方向，那就不好做了。不过现在官方已经支持了 Flutter for Web，已经向 Web 生态迈了一步，未来是否进一步与 Web 融合，也是有可能的。另外就是跨平台技术本身的问题，浏览器发展了二三十年，已经是个很强大的跨平台产品了，几乎是 Web 的代名词了，这一点无人能敌。但是也臃肿不堪，有大量历史包袱，性能和体验不够好，和 Native 的结合度差，尤其在移动和 IoT 平台。虽然硬件性能在不断提升，但这是所有软件共享的，浏览器的性能和体验总会比 Native 差一些，差的这一些很可能就是新业务和新场景的发挥空间。观察一下近几年新诞生的业务场景，很多都是利用到了 Native 新提供的能力才火爆起来的，如 AI/AR/视频/直播等，有因为新的 Web API 而孵化生出来的商业模式吗？关于这个话题，希望大家能发表一下自己的看法。前面都是铺垫，下面才是重点！欢迎大家加入淘系基础平台的跨平台技术部！是支撑小程序、小游戏、Flutter 等跨平台技术的核心团队，有技术广度和也有技术深度，我们需要 iOS、Android、C++、Flutter、Canvas、WebGL、WebAssembly 等各方面的人才。如果你善于学习，这是一个很好的接触跨领域知识的机会！我本人就是一个 title 从 “前端” 变成 “无线” 的案例，欢迎对技术有追求的同学加入！传送门：hanks.zh@alibaba-inc.com

发表了文章 2020-02-24

疫情下，这群工程师抢了“表哥”的饭碗

在疫情防控工作最关键的当下，如何不将时间浪费在填表上，如何避免成为“表哥”、“表姐”？阿里巴巴企业智能&政务钉钉的这群工程师使出了“新招”。面对疫情防控形势的不断变化，他们用互联网技术的新方式，让抗疫工作人员卸下“表哥”重担，有更充足的时间与疫情赛跑。 1、不一样的“开工”饭这是大年初七，支援搭建“新型肺炎疫情防控管理系统”的政务钉钉支援小组的一顿“开工饭”。对政务钉钉支援小组负责人周鹏来说，今年春节的节后“开工”意义非凡。因为疫情的爆发，需要更多智能手段运用在防控工作中。大年初六一早，周鹏接到任务后，就从家里匆匆赶往浙江省大数据局临时项目室，投入到新型肺炎疫情防控管理系统的筹备与建设中。 “支援小组的同学，从接到通知、响应、到达工作现场只用了不到一个小时。大家都是在与时间赛跑、与疫情赛跑。”周鹏表示，在临时项目室中，不光有政务钉钉支援小组的同学，来自浙江省大数据局、阿里云、数字浙江等团队的同学也快速响应，一起并肩作战。只用了24个小时，“新型肺炎疫情防控管理系统”就在浙政钉APP上线。作为全国首个省级落地的政府侧疫情管控系统，在此次疫情期间，为浙江省大数据局提供了信息管理与决策支持。 2、“疫情很快，我们要更快” “新型肺炎疫情防控管理系统”的快速上线离不开一个重要的技术支持“伙伴”——宜搭。作为阿里巴巴旗下的低代码应用搭建平台，用户通过简单的拖拽、配置，即可在宜搭平台上快速完成应用搭建。早在春节前，宜搭已经先一步投入到阿里内部健康打卡系统的开发中。农历二十八，准备赶回老家西安过年的宜搭技术负责人秦龙接到了开发健康打卡系统的需求。到家后还来不及跟家人过多寒暄的他，第一时间进入到工作模式。仅用一天时间便开发完成了阿里健康打卡系统，并在除夕当天顺利上线。分散在世界各地的阿里员工每天会定时收到打卡提醒，并在第一时间提交自己的健康状况，这让公司运营管理更精准高效。 “既然我们有技术可以实现阿里员工健康状况的线上同步，那其他地方也可以不需要用纸笔或excel再一个个登记管理了。”带着这样的想法，宜搭团队马不停蹄地投入到外部更多省市地区的疫情系统支持中。单是秦龙一人，就并行支持了10多个项目开发。这其中包括了大年初二就开始与浙江省卫健委沟通开发的“疫情联防联控上报系统”，以及和ICBU等多部门合作的方便全球供应商寻源的“防疫直采全球寻源平台”。 “我们收到的需求，系统通常是1个通宵做出来上线的。没办法，前线给我们的时间只有一天，一天必须上线。”秦龙说到。 3、这次，我“骗”了我妈今年春节期间，远在汕头过年的宜搭开发人员蔡进坤，也投入到项目紧张的开发支持中。常常凌晨1、2点，蔡进坤还在房间里敲代码。而平时10点就要睡觉的妈妈，总是坚持要给儿子做完夜宵才肯休息。为了让妈妈能早点休息，蔡进坤只能骗妈妈说自己要睡觉了。之后他便关上房门躲进房间继续写代码，这一坐就到了第二天早上6点。 “特殊时期，大家都挺不容易的。每个人都想着能为这次疫情做些什么。作为宜搭团队的一员，能够为抗击疫情贡献一份力量是很荣幸的，辛苦点也没什么，我还年轻！”蔡进坤腼腆地说。在这个“小房间”里，蔡进坤用代码敲出了给上千家政府、企业使用的宜搭免费模板为了让更多政府单位、企业能用上信息化的疫情防控手段，蔡进坤与他的同事们还在项目之余，陆续搭建出许多与疫情相关的通用模板，免费开放给社会单位使用。目前已经有上千家政府机构、企业单位使用到这些模板。 4、要是再快些就好了！通常，系统上线并不意味着结束，还需要根据疫情变化、政策策略的调整来迭代系统。张柳军也是宜搭开发团队的一员，据他回忆，在开发“疫情联防联控上报系统”时，曾接到关于重点人员上报字段的开发需求。本来已按照要求做好一个版本，但随着疫情发展与实际调研情况，有2/3的字段内容要重新设计与开发，这还不包括工作人员对重点人员状态的跟进、修改等一系列的后台逻辑设置。面对这一棘手的需求，张柳军主动接下，花了3小时迭代出一个新的版本。但张柳军似乎对自己并不“满意”：“要是再快些就好了，上一个版本需求我只花了2小时。”张柳军明白，这不是单纯地在跟自己较劲，是疫情留给他的考验时间。 5、24小时上线应用，没问题！抗击疫情，少不了宜搭生态伙伴们的支持。1月26日正月初二的晚上，宜搭合作伙伴——“谷瞰”联合创始人杨建君收到来自浙江省卫健委的电话，急需一套疫情联防联控上报平台，为疫情资源调度和决策提供数据和系统支持。接到紧急命令后，杨建君立马从绍兴家里开车来到浙江省卫健委，同时在路上召集了产品研发负责人吴贵康评估系统实现周期和所需资源，最终两人一致判断可以通过“宜搭平台”来落地这个疫情联防联控上报平台。跟疫情赛跑的路上，没有白天和黑夜之分，谷瞰和宜搭团队一起通宵搭建，仅用了24小时便上线了“疫情联防联控上报系统”，解决了基层疫情上报繁琐、区县市级收集耗时耗力等问题，并面向全国15个省市、100多个区县、10万多个基层医疗单位使用。团队成员李五一初三本来要见丈母娘，得知浙江省卫健委的紧急支援需求，跟丈母娘在高速服务区匆匆见了一面就回杭来到卫健委报到，给整个疫情平台平稳升级和上报提供了完善的测试支持。 “能够在24小时内大家无缝合作，完成一套疫情联防联控上报平台，特别感谢宜搭平台的大力支持，也离不开我们谷瞰人的家国情怀！一群有情有义的人，打一场必须赢的战‘疫’！”杨建君说到。 6、把后背交给他们，放心！随着各地企业节后返工的陆续恢复，新的挑战接踵而至。 2月6日，杭州市政府提出紧急需求：要快速搭建一个“企业复工申报平台”，确保企业的复工复产能够有序推进。于是由支付宝、阿里云、钉钉、政务钉钉、连同宜搭团队组成企业复工平台专班，火速开启协同作战模式。实际上项目最初的进展并不尽如人意：不熟悉对方系统，什么功能该由哪个系统来做不清楚。“当时我们每个人回归初心，就从全局出发，这个功能你做比较快那就你来做，基本上都是这个思路。”秦龙说。从接到需求开始，整个项目就进入近乎不眠不休的工作状态，专班成员们连续奋战近1周只睡了10小时，大家只希望能尽快做出来。 2月10日晚上，专班成员们收到了一条振奋人心的消息：今天的《新闻联播》报道了“杭州市企业复工申报平台”。“真没想到，我们的产品还上了新闻联播！”大家都有些激动。更让人激动的是，目前在宜搭平台上，支持全国各级政府部门、企业单位的疫情相关应用已经超过2000款。其中包括企业复工申请及审批、各级医院发热门诊的高危人群的统计上报、疫情物资的申请与发放、社区疫情防控重点人员摸排、外来流动人员健康登记、居民健康登记及出入登记、企业员工健康打卡及数据上报等多个免费模板。这就像很多人在一起努力着向着前方跑，在这场竞赛中，我们一定会跑赢疫情，一起等待春暖花开。

发表了文章 2020-02-24

102万行代码，1270 个问题，Flink 新版发布了什么？

阿里妹导读： Apache Flink 是公认的新一代开源大数据计算引擎，可以支持流处理、批处理和机器学习等多种计算形态，也是Apache 软件基金会和 GitHub 社区最为活跃的项目之一。 2019 年 1 月，阿里巴巴实时计算团队宣布将经过双十一历练和集团内部业务打磨的 Blink 引擎进行开源并向 Apache Flink 贡献代码，此后的一年中，阿里巴巴实时计算团队与 Apache Flink 社区密切合作，持续推进 Flink 对 Blink 的整合。 2 月 12 日，Apache Flink 1.10.0 正式发布，在 Flink 的第一个双位数版本中正式完成了 Blink 向 Flink 的合并。在此基础之上，Flink 1.10 版本在生产可用性、功能、性能上都有大幅提升。本文将详细为大家介绍该版本的重大变更与新增特性。文末更有 Flink 实践精选电子书，现已开放免费下载~ Flink 实践精选电子书，现已开放免费下载~ 下载地址 https://flink.apache.org/downloads.html Flink 1.10 是迄今为止规模最大的一次版本升级，除标志着 Blink 的合并完成外，还实现了 Flink 作业的整体性能及稳定性的显著优化、对原生 Kubernetes 的初步集成以及对 Python 支持（PyFlink）的重大优化等。综述 Flink 1.10.0 版本一共有 218 名贡献者，解决了 1270 个 JIRA issue，经由 2661 个 commit 总共提交了超过 102 万行代码，多项数据对比之前的几个版本都有所提升，印证着 Flink 开源社区的蓬勃发展。其中阿里巴巴实时计算团队共提交 64.5 万行代码，超过总代码量的 60%，做出了突出的贡献。在该版本中，Flink 对 SQL 的 DDL 进行了增强，并实现了生产级别的 Batch 支持和 Hive 兼容，其中 TPC-DS 10T 的性能更是达到了 Hive 3.0 的 7 倍之多。在内核方面，对内存管理进行了优化。在生态方面，增加了 Python UDF 和原生 Kubernetes 集成的支持。后续章节将在这些方面分别进行详细介绍。内存管理优化在旧版本的 Flink 中，流处理和批处理的内存配置是割裂的，并且当流式作业配置使用 RocksDB 存储状态数据时，很难限制其内存使用，从而在容器环境下经常出现内存超用被杀的情况。在 1.10.0 中，我们对 Task Executor 的内存模型，尤其是受管理内存（Managed Memory）进行了大幅度的改进（FLIP-49），使得内存配置对用户更加清晰：此外，我们还将 RocksDB state backend 使用的内存纳入了托管范畴，同时可以通过简单的配置来指定其能使用的内存上限和读写缓存比例（FLINK-7289）。如下图所示，在实际测试当中受控前后的内存使用差别非常明显。 Batch 兼容 Hive 且生产可用 Flink 从 1.9.0 版本开始支持 Hive 集成，但并未完全兼容。在 1.10.0 中我们对 Hive 兼容性做了进一步的增强，使其达到生产可用的标准。具体来说，Flink 1.10.0 中支持： Meta 兼容 - 支持直接读取 Hive catalog，覆盖 Hive 1.x/2.x/3.x 全部版本数据格式兼容 - 支持直接读取 Hive 表，同时也支持写成 Hive 表的格式；支持分区表UDF 兼容 - 支持在 Flink SQL 内直接调用 Hive 的 UDF，UDTF 和 UDAF 与此同时，1.10.0 版本中对 batch 执行进行了进一步的优化(FLINK-14133)，主要包括：向量化读取 ORC (FLINK-14135)基于比例的弹性内存分配 (FLIP-53)Shuffle 的压缩 (FLINK-14845)基于新调度框架的优化 (FLINK-14735) 在此基础上将 Flink 作为计算引擎访问 Hive 的 meta 和数据，在 TPC-DS 10T benchmark 下性能达到 Hive 3.0 的 7 倍以上。 SQL DDL 增强 Flink 1.10.0 支持在 SQL 建表语句中定义 watermark 和计算列，以 watermark 为例： CREATE TABLEtable_name ( WATERMARK FOR columnName AS ) WITH ( ...) 除此之外，Flink 1.10.0 还在 SQL 中对临时函数/永久函数以及系统/目录函数进行了明确区分，并支持创建目录函数、临时函数以及临时系统函数： CREATE [TEMPORARY|TEMPORARY SYSTEM] FUNCTION[IF NOT EXISTS] catalog_name.function_nameAS identifier [LANGUAGE JAVA|SCALA] Python UDF 支持 Flink 从 1.9.0 版本开始增加了对 Python 的支持（PyFlink），但用户只能使用 Java 开发的 User-defined-function (UDF) ，具有一定的局限性。在 1.10.0 中我们为 PyFlink 增加了原生 UDF 支持（FLIP-58），用户现在可以在 Table API/SQL 中注册并使用自定义函数，如下图所示：同时也可以方便的通过 pip 安装 PyFlink： pip install apache-flink 更多详细介绍，请参考：https://enjoyment.cool/2020/02/19/Deep-dive-how-to-support-Python-UDF-in-Apache-Flink-1-10/ 原生 Kubernetes 集成 Kubernetes (K8S) 是目前最为流行的容器编排系统，也是目前最流行的容器化应用发布平台。在旧版本当中，想要在 K8S 上部署和管理一个 Flink 集群比较复杂，需要对容器、算子及 kubectl 等 K8S 命令有所了解。在 Flink 1.10 中，我们推出了对 K8S 环境的原生支持（FLINK-9953），Flink 的资源管理器会主动和 Kubernetes 通信，按需申请 pod，从而可以在多租户环境中以较少的资源开销启动 Flink，使用起来也更加的方便。更多内容，参考 1.10.0 版本发布日志： https://ci.apache.org/projects/flink/flink-docs-stable/release-notes/flink-1.10.html 结语 2019 年 1 月，阿里巴巴实时计算团队宣布 Blink 开源。整整一年之后，Flink 1.10.0 版本的发布宣告 Flink 和 Blink 的整合正式完成。我们践行着自己的诺言，开放源码，更相信社区的力量，相信社区是开源协作精神与创新的摇篮。我们也衷心希望有更多的志同道合的小伙伴加入我们，一起把 Apache Flink 做的越来越好！

发表了文章 2020-02-21

戴口罩如何刷门禁？阿里工程师亮出“刷脸神器”

1. 背景介绍疫情肆虐，有效隔离是尽快战胜病毒的有效手段，多个地方政府都提出了严格的居民出行管理条例，例如杭州市余杭区2月3日发布了实行“十项从严”管控措施：这给社区管理带来新的挑战，传统门卫盯人存在以下几个问题：进出人员情况全凭人工记录，出现错漏，不能及时对频繁外出居民有效劝阻。缺乏全局角度对居民隔离整体情况的掌控和度量，例如有哪些人频繁出入，出入总人数。为了解决居民出入管理的上述几个问题，阿里云智能数据库向量检索团队免费提供一套高度兼容戴口罩场景下的人脸识别模型，并基于AnalyticDB的向量检索能力，搭建了一套小区人员管理的解决方案, 这个方案将开源给社区。通过该方案可以有效的提升当下疫情中的小区出入管理效率.同时我们免费提供AnalyticDB给用户用于与当前肺炎疫情相关的出入管理应用。下面首先介绍我们的方案，然后会对其中的人脸识别和AnalyticDB向量检索关键技术做详细介绍，方便开发者能够做二次开发，最后我们会附上开源地址。 2. 小区人员管理解决方案介绍 2.1小区人员管理解决方案功能 1)自动登记入册小区人口, 基本信息和人脸特征，界面如下: 2)通过摄像头自动做人脸识别，返回来访者家庭的所有出入记录。方便社区管理者进行高效的出入管理,在当前疫情环境下, 人们普遍佩戴口罩, 去掉口罩会增加肺炎感染的风险, 所以本方案提供一套支持戴口罩情况下人脸识别的算法，演示效果如下： 3)可以通过人脸照片和结构化信息的任意组合来检索住户的来访记录，并提供统计分析能力，为小区管理者提供全局度量数据。 2.2 应用架构总体设计出入管理系统的总体架构如下图所示，前端界面通过HTML和javascript实现, 功能包含支持戴口罩场景下的人脸门禁, 通过人脸识别查询来访者的全部家庭成员2日内的出入记录, 人员登记, 后台通过人脸和结构化信息自由组合搜索来访记录等功能.。人脸识别模块将包含人脸的视频转换成人脸特征向量, 人脸识别模块主要使用了Seetafce引擎的人脸检测和人脸追踪模块和AnalyticDB团队自研的人脸识别, 眼部识别和口罩检测模型.AnalyticDB负责整个应用中的全部的结构化数据和人脸识别模块产生的人脸特征向量的存储和查询。 3. 关键技术介绍 3.1 针对疫情的人脸识别算法算法流程如下图所示, 在人员登记过程中我们分别通过人脸识别模型和眼部识别模型提取登记人的面部整体特征和眼部特征, 并将提取的特征向量写入AnalyticDB。在查询过程中, 我们首先会通过口罩检测模型来检测来访人是否有佩戴口罩, 如果没有佩戴口罩, 我们会使用整体面部的特征在AnalyticDB中检索相似的特征, 如果有特征与来访者面部特征相似度满足阈值, 则返回对应的结果。如果来访者有佩戴口罩, 那么鼻子、嘴巴等特征会缺失, 使用整体面部特征提取模型无法准确的检索到正确的记录。这时我们会使用眼部识别模型提取来访者眼部, 额头等不会被口罩遮挡的部位的特征, 然后再AnalyticDB中检索之前保存的眼部特征。系统中使用的人脸识别模型, 眼部识别模型和口罩检测模型将全部开源给社区。经过测试口罩检测模型的准确率>99.5%. 人脸识别模型和眼部识别模型在学术界常用的数据集上的准确率如下表所示。可以看到仅仅使用眼部特征, AnalyticDB的模型在LFW数据集上仍然有99+%以上的识别准确率.。 3.2 AnalyticDB向量版特性介绍分析型数据库(AnalyticDB)是阿里云上的一种高并发低延时的PB级实时数据仓库，可以毫秒级针对万亿级数据进行即时的多维分析透视和业务探索。 AnalyticDB for MySQL 全面兼容MySQL协议以及SQL:2003 语法标准, AnalyticDB forPostgreSQL 支持标准 SQL:2003，高度兼容 Oracle 语法生态. 目前两款产品都包含向量检索功能, 可以支持人脸, 人体, 车辆等的相似查询和推荐系统。目前AnalyticDB在真实应用场景中可以支持10亿级别的向量数据的查询, 100毫秒级别的响应时间. AnalyticDB已经在多个城市的安防项目中大规模部署。在一般的包含向量检索的的应用系统中, 通常开发者会使用向量检索引擎(例如Faiss)来存储向量数据, 然后使用关系型数据库存储结构化数据. 在查询时也需要交替查询两个系统, 这种方案会有额外的开发工作并且性能也不是最优。 AnalyticDB支持结构化数据和非结构化数据(向量)的检索，仅仅使用SQL接口就可以快速的搭建起以图搜图或者图片+结构化数据混合检索等功能. AnalyticDB的优化器在混合检索场景中会根据数据的分布和查询的条件选择最优的执行计划，在保证召回的同时，得到最优的性能。在我们的出入管理系统中, 我们通过AnalyticDB实现了同时使用照片, 性别, 年龄, 起始时间, 终止时间来查询出入记录的功能。这样的以图搜图+结构化搜索功能, 可以通过一条SQL实现：其中表demo.person存储了每个人的基本信息,demo.face_feature存储了人脸特征向量, demo.access_record存储了所有的来访记录. pid是每个人的独有ID。结构化信息+非结构化信息(图片)混合检索在实际应用中被广泛使用的. 例如在人脸门禁系统被部署在多个小区时, 我们使用一张表存储了所有小区的人脸特征, 在人脸检索时我们只需要检索当前小区的人脸特征. 在这种情况下, 使用AnalyticDB我们只需要在SQL中增加where 小区名 ='xxx' 就可以轻易实现。结尾复制下方链接至浏览器打开或者识别下方二维码，即可查看项目开源详情： https://github.com/aliyun/alibabacloud-AnalyticDB-python-demo-face-recognition

发表了文章 2020-02-20

远程办公安全威胁升级，疫情下企业如何自保？

阿里妹导读：身份认证安全的 AI 化，是未来的一个大的趋势。相信很多安全从业人员对最近两年IDaaS在业界的兴起都耳熟能详。它是Gartner中区别传统IAM产品的一个定义，全称是IDentity as a Service，主要是指云化的身份认证服务。今天，我们就来聊聊身份认证安全如何为远程办公抗疫保驾护航。行业趋势本次2019-nCoV病毒的爆发，加速了办公上云和移动的演变过程。无数企业今年的开工都转到了线上，几万人的直播，这种临时性的波峰需求能良好的适配非云莫属。这场突如其来的变故，也催熟了移动办公的需求。员工都在家里，通过自己的移动设备来参与工作。即使没有这些，IDaaS专注的密码技术的安全挑战在过去也是与日俱增的。如果说通过对称算法的账户密码方式容易被撞库，今天，即使用非对称技术生成的短期令牌，也仍然受到了挑战。通过发一个钓鱼的宏文件，或是一张有恶意脚本的图片，都可以窃取你的会话凭证的，无论它有多少个字节长。企业能做的，就是启用更复杂的安全策略，但是在用户体验上，又带来了更多的诟病。如上所述，企业很快发现更细粒度的去验证用户看起来并不可行。未来，通过引入AI技术，对所有对内和对外的业务系统的访问进行全面分析计算，动态检查和更新现有的安全策略，然后利用适当的自动安全控制，通过后台来决定是否允许对核心系统的访问，会大行其道。所有这些努力都是既安全又不会让用户烦恼。 AI技术发展到今天，除了BostonDynamic那个机器人的惊艳后空翻，在这次抗疫过程中也是大显身手。尽管机场车站人来人往，但是测温设备已经能快速甄别出发热人员。 ESG年度研究报告指出，2020年安全性投资的前4个重点领域排在首位的是：使用AI/ML进行威胁检测的人工智能网络安全技术（32％）。原因很简单，未来的数据是海量的，靠人工去筛选，效率是个大问题。如果不能及时捕获异常，就不能及时响应。国际趋势零信任自谷歌推出“BeyondCorp”后，围绕身份认证交付的零信任安全架构，开始得到业界的普遍认可。这个模型的最大益处，就是把过去IT的一些最佳实践上升到一个理论的高度，特别强调了人和设备的相互认证。有了理论指导实践，很多问题都迎刃而解。比如，正向代理和反向代理IAP（Identity Aware Proxy，上图中的Access Proxy位置所示）在过去20年中被广泛的采用，今天的演进要求是它要和身份认证授权互动起来。同时因为有了这层代理，可以记录所有的请求／返回内容，不仅仅是相对简单的系统日志。它们可以作为后期大脑控制中心ACE（Access Control Engine）的感知输入，作为机器学习的数据基础。如果还不能理解，那么联系到最近爆发的疫情，看看各个小区路段是如何做到管控身份的就知道了。这时候，能被放行的只有小区的业主和相关人员，不仅仅是体温正常的，你还要有本区的户口本，或身份证等等。同时，所有的进出都要登记上报，作为调研和管控的依据。除了谷歌，国际的其它大厂也在快速跟上。2019年，传统的网络和企业安全厂商思科高达20多亿美金收购了认证初创公司Duo Security。通过并购将身份认证集成到思科的安全互联网网关SAG，云访问安全代理CASB，企业移动管理MDM以及其它基于混合云的产品阵容中。国内趋势 2019年，国内的安全厂商也从自己擅长的技术点纷纷切入零信任安全。一拨是传统的VPN厂商提供软件定义边界SDP产品，减少互联网暴露面作为卖点的。值得一提的是，离开了身份为核心的零信任安全是不完整的。身份和边界必须充分结合起来才是完整的零信任，不能盲人摸象。本次抗疫暴露了不少问题，一方面，形势需要，另一方面，仓促上阵。很多企业，还停留在传统的VPN远程办公上。它能满足领导和运维人员已经很好了，上万人开视频会议肯定挂。某国内顶级银行，对基础设施投资数亿每年，但是面对目前海量的在家办公需求，还是卡顿，不得不寻求新的解决方案。可以预见的是，疫情对行业的影响也将是深远的。远程办公，在线教育都会成为热点。IT圈子对围绕身份认证授权的零信任网络也会有更高的热情。但是，罗马不是一天建成的。谷歌自2013年开始，前后花了6年推出了BeyondCorp，企业是不可能在一夜之间将原有的体系推倒，从零搭建零信任体系的。更务实的做法是尽早开始尝试，哪怕一开始是简单的模型，社会事件和安全事件都是很好的推手，加速产业成熟。零信任技术毫无疑问，零信任是复杂的，有10多个不同的组件协同，包括控制中心ACE，接入网关IAP，认证中心IDaaS等。其中作为认证中心的IDaaS覆盖了单点登录SSO，接入协议Radius，和用户管理UD，是整个方案的核心。控制中心整个零信任中，控制中心是大脑，是骨干。首先，大脑是有学习能力的。传统的防火墙安全策略，都是采用预定义规则的方法，主要是管理员按经验来设置，使用繁琐，效果也较差。例如，周一早上9:00是一个开会签到的高峰，一个一万人的企业，到底峰值是一万次／秒，还是1千次／秒？即使通过观察设定好了该时间点的上限，11:00又是一个什么样的数字？通过日志的机器学习，可以很容易的得出这个规律。其次，大脑是有判断能力的。因为引入了IAP，能做到真正的全栈日志审计。用户的每次请求都会被记录，如果和交换机，路由器，防火墙，准入等日志结合起来，可以做到持续自适应风险与信任评估CARTA，更好的对用户的行为进行画像溯源。认证中心零信任有很多可以做的控制点，认证中心是最佳的切入点。同社会一样，网络是由复杂的个体组成，而其中的属性就非常重要。通常，我们对个体的标识可以是一个身份证。通过社会的联防联控，更多属性都是可以附加在一个身份上的。毕竟，检查体温等这种浅层次的属性是容易获取的，但是肺CT，核酸等就不容易啦。安全中对身份的鉴别一直是一个重点。接入中心接入中心是控制流量通断的闸门。控制中心作为大脑虽然很厉害，它的判断也是来自于各个器官。如果没有望闻问切等各种反馈，那么大脑也是聋子和瞎子。有了接入中心和控制中心联动，体系才能更加的智能。比如一个口罩，它可以阻拦95%的大小颗粒就足够好了，再高要求是99%就很勉强，做到100%是非常昂贵的。接入中心一个刚需的能力是更好的解析TCP协议，比如这是一个WEB流量，视频流量，还是一个病毒的广播请求，快速识别有助于系统作出快速响应。综上所述，控制中心，认证中心，接入中心，是要做好零信任安全架构的三个核心组件。 IDaaS解决方案以IDaaS（统一身份认证服务）为核心，阿里云云盾提供的零信任安全解决方案基本完整，类似谷歌的BeyondCorp简化版本。通过Agent终端管控，SPG（Service Provide Gateway）应用接入，和IDaaS身份认证齐头并进，可以提供灵活的组合方案从而满足企业的要求。如上图，公有方式IDaaS和SPG部署在阿里云上，通过VPN隧道，可以接入到企业的内网。这样，在防火墙上只需要配置SPG一个入口IP的ACL规则，从而确保所有能进入企业内网的流量，都是经过阿里云WAF、IPS等清洗过的。身份认证阿里云云盾的IDaaS主要用来保护应用身份安全。为什么说它很重要呢？道高一尺，魔高一丈。现在的很多攻击，都是混杂在正常的流量中的。如果发现系统受到攻击，就去阻断，势必会造成错杀，影响正常业务。这是为什么我们强调自适应认证（Adaptive Authentication ）的原因。为了在整个体系中更好的去伪存真，避免错杀，身份复核是最好的方式。最常见的方法是IDaaS中的AI模块检测到IP，位置，时间等异常行为组合，判断为危险，会杀掉现有会话，弹出一个OTP二次认证的界面，通过后才可以继续，否则会被阻断。 IDaaS将零信任中的控制中心，认证中心合二为一，其用户行为分析UEBA具备了大脑的AI识别和判断能力。例如，通过用户在过去一个月的同一个工作日的登录行为，算出平均值，形成基线。然后，对用户的认证请求作出风险打分，根据程度对管理员钉钉告警，触发2FA双因子认证，直至将IP加入黑名单作出阻断。正如在文章开头提到的，面对海量的网络吞吐流量，如同机场车站的滚滚人流，靠人工筛选的方案是行不通的。UEBA利用了阿里云多年积累的经验和算法，具备快速识别风险的能力。此外，IDaaS还整合了阿里的业务风控能力，包括用户的注册／登录，从而确保用户在第一次使用系统的时候，是安全可靠的。应用代理应用代理很好地解决了VPN带宽不足，暴露面过大等缺点。传统的IPSecVPN一个大的问题是一旦窃取了身份，进入内网后，可以进一步横向访问到更多脆弱的网络设备和服务器，从而提权达到攻击的目的。这个过程在信息泄露和护网过程已经被反复重现了。 SPG产品扮演了IAP的角色，对所有的WEB和TCP请求进行拦截和判断。实践中，开放的端口越少越安全，最好是只有Https的443端口。幸运的是今天很多业务已经前后分离B/S化了。由此，SPG有能力做到不开放更多端口的情况下（如RDP的3389）做到业务可用。因为具备每秒上万并发的处理能力，可以将防火墙内外的请求统统接入。用户在办公室和家里，流程无变化，体验无变化。终端管控 IDaaS中的终端代理（IdpAgent），保证移动和PC终端接入的安全。比如这次疫情，很多人是把台式机留在了办公室，这样就不能正常工作了。但是想要工作不能停，利用家里的电脑BYOD显然是一个好的出路。由此引发的终端管控问题也是一个大的挑战。一台家里的电脑，接入公司的网络，是一个高危的事情。因为你不知道它上面是否有病毒和木马。借助多年实践阿里郎的成功经验，终端代理运行时会检查漏洞补丁，杀毒软件等是否达到基线要求，符合的才能入网。通过MFA身份认证后，将用户身份和设备指纹绑定，可以自动注册自己的PC及手机作为信任设备。下一步，还可以通过下载客户端证书，替代传统的账户密码，进一步减少钓鱼和中间人攻击的机会。除了作为终端准入使用，移动终端的APP还可以被用来作为OTP令牌的生成工具。未来，VPN，DLP等能力，甚至包括电话会议，都可以植入到终端管控软件中。钉钉整合抗疫战斗中，钉钉很好的扮演了在终端上作为应用门户入口的角色。这次在家远程办公的要求之高之急对很多的IT人是没有心理准备的。钉钉连续两天扩容1万多台服务器，就表明了受欢迎程度还是很高的。初期，对钉钉的应用还是浅的，主要是直播会议等。未来，当钉钉真正成为办公入口的时候，内网应用开放给钉钉会带来更大的安全挑战。一个简单的解决方案是通过IDaaS、SPG和钉钉进行整合，灵活的去适配更多应用场景。例如，用户在钉钉上利用内置浏览器打开一个办公应用的时候，可以用两种方式：自动到IDaaS上通过STS利用钉钉的身份去换取一个令牌id_token，然后利用这个令牌去穿过SPG的验证要求；直接利用钉钉提供的Code，在SPG上到钉钉云的后台去交换一个Access Token，并穿过SPG的验证；如上，在方案2中，IDaaS是一个可选的组件，也就是说企业只要提供一个合法的用户身份即可，可以是钉钉，也可以是原有的4A系统利旧。除了公有钉钉，阿里还有专属钉钉，确保重要的文件能够本地存储。专属钉钉对应的解决方案类似，不再赘述。其它部署方式除了提供公有云能力，同时，云盾IDaaS提供了私有云部署模式，可以跑在客户的敏捷PaaS上。IDaaS和SPG的私有云版本，可以部署在企业的防火墙后面，更好的满足金融等用户的合规监管要求。对那些既有公有云，又有私有云的用户，阿里还提供了混合云部署模式，从而满足局部上云用户的需求。展望与总结抗疫过程中，阿里巴巴集团秉承自身的To B基因，除了有全球采购物资等社会担当，同时也展现了很多的技术能力。真正的零信任安全构建体系化，从端到云，需要全链路的保护。终端、接入、AI和云原生是阿里云的核心竞争力。云原生的核心优势在于云上架构可以从IaaS、PaaS、SaaS自下而上构建可信链条，第三方安全厂商是很难中间植入的。除了IDaaS，云盾DDOS, WAF, SDDP，风控，实人，SSL证书等有用武之地，阿里巴巴集团的阿里郎，钉钉，RAM，VPN，SAG，达摩院的AI等等，未来都是整合出更丰富的安全解决方案的弹药储备。最后，不管你乐意不乐意看见，以身份为边界的零信任安全是大势所趋。疫情，让这个春天云和移动的需求迎面撞来，对应的安全防护也越来越外延化。移动终端设备，公有云服务器，都挪到了企业传统的安全边界防火墙的外面，原来的鸡蛋壳式安全模式被打破。如果说20年前的边界主要是围绕IP来构建ACL，防火墙（包括NGFW）需求爆发；10年前WEB2.0带来了WAF的长足发展；那么，零信任也必将带来IDaaS等以身份为新边界的安全需求增长。而此类市场动向，会以重视安全的政府和金融用户为先锋驱动，让我们拭目以待。

发表了文章 2020-02-19

独家下载！阿里如何用 AI 写代码？

阿里妹导读：作为今年阿里经济体前端委员会的四大技术方向之一，前端智能化方向一被提及，就不免有人好奇：前端结合 AI 能做些什么，怎么做，未来会不会对前端产生很大的冲击等等。本篇文章将围绕这些问题，以「设计稿自动生成代码」场景为例，从背景分析、竞品分析、问题拆解、技术方案等几个角度切入，细述相关思考及过程实践。背景分析业界机器学习之势如火如荼，「AI 是未来的共识」频频出现在各大媒体上。简单的、重复性的工作有较大的可能性会受到AI的冲击。并且，白领比蓝领的工作更容易被影响；因为蓝领的工作可能还需要机器人和软硬件相关技术都突破才能被实现，而白领工作一般只需要软件技术突破就可以实现。那AI会对前端这个“白领”工作产生什么样的影响？回看 2010 年，软件几乎“吞噬”了所有行业，带来近几年软件行业的繁荣；而到了 2019 年，软件开发行业本身却又在被 AI 所“吞噬”。你看：DBA 领域出现了 Question-to-SQL，针对某个领域只要问问题就可以生成 SQL 语句；基于机器学习的源码分析工具 TabNine 可以辅助代码生成；设计师行业也出了 P5 Banner 智能设计师“鹿班”，测试领域的智能化结合也精彩纷呈。那前端领域呢？那就不得不提一个我们再熟悉不过的场景了，它就是设计稿自动生成代码（Design2Code，以下简称 D2C），阿里经济体前端委员会-前端智能化方向当前阶段就是聚焦在如何让 AI 助力前端这个职能角色提效升级，杜绝简单重复性工作，让前端工程师专注更有挑战性的工作内容！相关产品分析 2017 年，一篇关于图像转代码的 Pix2Code 论文掀起了业内激烈讨论的波澜，讲述如何从设计原型直接生成源代码。随后社区也不断涌现出基于此思想的类似 Screenshot2Code 的作品，2018 年微软 AI Lab 开源了草图转代码工具 Sketch2Code，同年年底，设计稿智能生成前端代码的新秀 Yotako 也初露锋芒，机器学习首次以不可小觑的姿态正式进入了前端开发者的视野。基于上述分析，我们能够得到以下几点启发：深度学习目前在图片方面的目标检测能力适合较大颗粒度的可复用的物料识别（模块识别、基础组件识别、业务组件识别）。完整的直接由图片生成代码的端到端模型复杂度高，生成的代码可用度不高，要达到所生成代码工业级可用，需要更细的分层拆解和多级子网络模型协同，短期可通过设计稿生成代码来做 D2C 体系建设。当模型的识别能力无法达到预期准确度时，可以借助设计稿人工的打底规则协议；一方面人工规则协议可以帮助用户强干预得到想要的结果，另一方面这些人工规则协议其实也是高质量的样本标注，可以当成训练样本优化模型识别准确度。问题分解设计稿生成代码的目标是让 AI 助力前端这个职能角色提效升级，杜绝简单重复性工作内容。那我们先来分析下，“常规”前端尤其是面向 C 端业务的同学，一般的工作流程日常工作内容大致如下： “常规”前端一般的开发工作量，主要集中在视图代码、逻辑代码和数据联调（甚至是数据接口开发，研发 Serveless 产品化时可期）这几大块，接下来，我们逐块拆解分析。视图代码视图代码研发，一般是根据视觉稿编写 HTML 和 CSS 代码。如何提效，当面对 UI 视图开发重复性的工作时，自然想到组件化、模块化等封装复用物料的解决方案，基于此解决方案会有各种 UI 库的沉淀，甚至是可视化拼装搭建的更 High Level 的产品化封装，但复用的物料不能解决所有场景问题。个性化业务、个性化视图遍地开花，直面问题本身，直接生成可用的 HTML 和 CSS 代码是否可行？这是业界一直在不断尝试的命题，通过设计工具的开发插件可以导出图层的基本信息，但这里的主要难点还是对设计稿的要求高、生成代码可维护性差，这是核心问题，我们来继续拆解。 ★ 设计稿要求高问题对设计稿的要求高，会导致设计师的成本加大，相当于前端的工作量转嫁给了设计师，导致推广难度会非常大。一种可行的办法是采用 CV（ComputerVision, 计算机视觉）结合导出图层信息的方式，以去除设计稿的约束，当然对设计稿的要求最好是直接导出一张图片，那样对设计师没有任何要求，也是我们梦寐以求的方案，我们也一直在尝试从静态图片中分离出各个适合的图层，但目前在生产环境可用度不是非常高（小目标识别精准度问题、复杂背景提取等问题正在解决），因为毕竟设计稿自带的元信息，比一张图片提取处理的元信息要更多更精准。 ★ 可维护性问题生成的代码结构一般都会面临可维护性方面的挑战：合理布局嵌套：包括绝对定位转相对定位、冗余节点删除、合理分组、循环判断等方面；元素自适应：元素本身扩展性、元素间对齐关系、元素最大宽高容错性；语义化：Classname 的多级语义化；样式 CSS 表达：背景色、圆角、线条等能用 CV 等方式分析提取样式，尽可能用 CSS 表达样式代替使用图片；…… 将这些问题拆解后，分门别类专项解决，解决起来看似没完没了，但好在目前发现的大类问题基本已解决。很多人质疑道，这部分的能力的实现看起来和智能化没有什么关系，顶多算个布局算法相关的专家规则测量系统。没错，现阶段这部分比较适合规则系统，对用户而言布局算法需要接近 100% 的可用度，另外这里涉及的大部分是无数属性值组合问题，当前用规则更可控。如果非要使用模型，那这个可被定义为多分类问题。同时，任何深度学习模型的应用都是需要先有清晰的问题定义过程，把问题规则定义清楚本就是必备过程。但在规则解决起来麻烦的情况下，可以使用模型来辅助解决。比如合理分组（如下图）和循环项的判断，实践中我们发现，在各种情况下还是误判不断，算法规则难以枚举，这里需要跨元素间的上下文语义识别，这也是接下来正在用模型解决的重点问题。逻辑代码逻辑代码开发主要包括数据绑定、动效、业务逻辑代码编写。可提效的部分，一般在于复用的动效和业务逻辑代码可沉淀基础组件、业务组件等。接口字段绑定：从可行性上分析还是高的，根据视觉稿的文本或图片判断所属哪个候选字段，可以做，但性价比不高，因为接口数据字段绑定太业务，通用性不强。动效：这部分的开发输入是交互稿，而且一般动效的交付形式各种各样参差不齐，有的是动画 gif 演示，有的是文字描述，有的是口述；动效代码的生成更适合用可视化的形式生成，直接智能生成没有参考依据，考虑投入产出比不在短期范围内。业务逻辑：这部分开发的依据来源主要是 PRD，甚至是 PD 口述的逻辑；想要智能生成这部分逻辑代码，欠缺的输入太多，具体得看看智能化在这个子领域能解决什么问题。 ★ 逻辑代码生成思考理想方案当然是能像其他诗歌、绘画、音乐等艺术领域一样，学习历史数据，根据 PRD 文本输入，新逻辑代码能直接生成，但这样生成的代码能直接运行没有任何报错吗？目前人工智能虽说发展迅速，但其能解决的问题还是有限，需要将问题定义成其擅长解决的问题类型。强化学习擅长策略优化问题，深度学习目前在计算机视觉方面擅长解决的是分类问题、目标检测问题，文本方面擅长 NLP（Natural Language Processing, 自然语言处理）等。关于业务逻辑代码，首先想到的是对历史源代码的函数块利用 LSTM（Long Short-Term Memory, 长短期记忆网络）和 NLP 等进行上下文分析，能得到代码函数块的语义，VS Code 智能代码提醒和 TabNine 都是类似的思路。另外，在分析问题中（如下图）我们还发现，智能化在业务逻辑领域还可以协助识别逻辑点在视图出现的位置（时机），并根据视图猜测出的逻辑语义。综上，我们总结一下智能化现阶段的可助力点：由历史源代码分析猜测高频出现的函数块（逻辑块）的语义，实际得到的就是组件库或者基础函数块的语义，可在代码编辑时做代码块推荐等能力。由视觉稿猜测部分可复用的逻辑点，如这里的字段绑定逻辑，可根据这里文本语义 NLP 猜测所属字段，部分图片元素根据有限范围内的图片分类，猜测所属对应的图片字段（如下图示例中的，氛围修饰图片还是 Logo 图片）；同时还可以识别可复用的业务逻辑组件，比如这里的领取优惠券逻辑。所以，现阶段在业务逻辑生成中，可以解决的问题比较有限，尤其是新的业务逻辑点以新的逻辑编排出现时，这些参考依据都在 PD 的 PRD 或脑海中。所以针对业务逻辑的生成方案，现阶段的策略主要如下：字段绑定：智能识别设计稿中的文本和图片语义分类，特别是文字部分。可复用的业务逻辑点：根据视图智能识别，并由视图驱动自由组装，含小而美的逻辑点（一行表达式、或一般不足以封装成组件的数行代码）、基础组件、业务组件。无法复用的新业务逻辑：PRD 需求结构化（可视化）收集，这是一个高难度任务，还在尝试中。小结目前用智能化的方式自动生成 HTML + CSS + 部分 JS + 部分 DATA 的主要分析如上，是Design to Code 的主要过程，内部项目名称叫做 D2C ，后续系列文章会使用此简称，集团内外的落地产品名称为 imgcook。随着近几年主流设计工具（Sketch、PS、XD 等）的三方插件开发能力逐渐成熟，飞速发展的深度学习那甚至超过人类识别效果的趋势，这些都是 D2C 诞生和持续演进的强大后盾。技术方案基于上述前端智能化发展概括分析，我们对现有的 D2C 智能化技术体系做了能力概述分层，主要分为以下三部分：识别能力：即对设计稿的识别能力。智能从设计稿分析出包含的图层、基础组件、业务组件、布局、语义化、数据字段、业务逻辑等多维度的信息。如果智能识别不准，就可视化人工干预补充纠正，一方面是为了可视化低成本干预生成高可用代码，另一方面这些干预后的数据就是标注样本，反哺提升智能识别的准确率。表达能力：主要做数据输出以及对工程部分接入通过 DSL 适配将标准的结构化描述做 Schema2Code通过 IDE 插件能力做工程接入算法工程：为了更好的支撑 D2C 需要的智能化能力，将高频能力服务化，主要包含数据生成处理、模型服务部分样本生成：主要处理各渠道来源样本数据并生成样本模型服务：主要提供模型 API 封装服务以及数据回流在整个方案里，我们用同一套数据协议规范（D2C Schema）来连接各层的能力，确保其中的识别能够映射到具体对应的字段上，在表达阶段也能正确地通过出码引擎等方案生成代码。智能识别技术分层在整个 D2C 项目中，最核心的是上述识别能力部分的机器智能识别部分，这层的具体再分解如下，后续系列文章会围绕这些细分的分层展开内部实现原理。物料识别层：主要通过图像识别能力识别图像中的物料（模块识别、原子模块识别、基础组件识别、业务组件识别）。图层处理层：主要将设计稿或者图像中图层进行分离处理，并结合上一层的识别结果，整理好图层元信息。图层再加工层：对图层处理层的图层数据做进一步的规范化处理。布局算法层：转换二维中的绝对定位图层布局为相对定位和 Flex 布局。语义化层：通过图层的多维特征对图层在生成代码端做语义化表达。字段绑定层：对图层里的静态数据结合数据接口做接口动态数据字段绑定映射。业务逻辑层：对已配置的业务逻辑通过业务逻辑识别和表达器来生成业务逻辑代码协议。出码引擎层：最后输出经过各层智能化处理好的代码协议，经过表达能力（协议转代码的引擎）输出各种 DSL 代码。技术痛点当然，这其中的识别不全面、识别准确度不高一直是 D2C 老生常谈的话题，也是我们的核心技术痛点。我们尝试从这几个角度来分析引起这个问题的因素：识别问题定义不准确：问题定义不准确是影响模型识别不准的首要因素，很多人认为样本和模型是主要因素，但在这之前，可能一开始的对问题的定义就出现了问题，我们需要判断我们的识别诉求模型是否合适做，如果合适那该怎么定义清楚这里面的规则等。高质量的数据集样本缺乏：我们在识别层的各个机器智能识别能力需要依赖不同的样本，那我们的样本能覆盖多少前端开发场景，各个场景的样本数据质量怎么样，数据标准是否统一，特征工程处理是否统一，样本是否存在二义性，互通性如何，这是我们当下所面临的问题。模型召回低、存在误判：我们往往会在样本里堆积许多不同场景下不同种类的样本作为训练，期望通过一个模型来解决所有的识别问题，但这却往往会让模型的部分分类召回率低，对于一些有二义性的分类也会存在误判。 ★ 问题定义深度学习里的计算机视觉类模型目前比较适合解决的是分类问题和目标检测问题，我们判断一个识别问题是否该使用深度模型的前提是——我们自己是否能够判断和理解，这类问题是否有二义性等，如果人也无法准确地判断，那么这个识别问题可能就不太合适。假如判断适合用深度学习的分类来做，那就需要继续定义清楚所有的分类，这些分类之间需要严谨、有排他性、可完整枚举。比如在做图片的语义化这个命题的时候，一般图片的 ClassName 通用常规命名有哪些，举个例子，其分析过程如下：第一步：尽可能多地找出相关的设计稿，一个个枚举里面的图片类型。第二步：对图片类型进行合理归纳归类，这是最容易有争论的地方，定义不好有二义性会导致最有模型准确度问题。第三步：分析每类图片的特征，这些特征是否典型，是否是最核心的特征点，因为关系到后续模型的推理泛化能力。第四步：每类图片的数据样本来源是否有，没有的话能否自动造；如果数据样本无法有，那就不适合用模型，可以改用算法规则等方式替代先看效果。 D2C 项目中很多这样的问题，问题本身的定义需要非常精准，并且需要有科学的参考依据，这一点本身就比较难，因为没有可借鉴的先例，只能先用已知的经验先试用，用户测试有问题后再修正，这是一个需要持续迭代持续完善的痛点。 ★ 样本质量针对样本问题，我们需要对这部分数据集建立标准规范，分场景构建多维度的数据集，将收集的数据做统一的处理和提供，并以此期望能建立一套规范的数据体系。在这套体系中，我们使用统一的样本数据存储格式，提供统一的针对不同问题（分类、目标检测）的样本评估工具来评估各项数据集的质量，针对部分特定模型可采取效果较好的特征工程（归一化、边缘放大等）来处理，同类问题的样本也期望能在后续不同的模型里能够流通作比较，来评估不同模型的准确度和效率。 ★ 模型针对模型的召回和误判问题，我们尝试收敛场景来提高准确度。往往不同场景下的样本会存在一些特征上的相似点或者影响部分分类局部关键特征点，导致产生误判、召回低，我们期望能够通过收敛场景来做模式化的识别，提高模型准确度。我们把场景收敛到如下三个场景：无线 C 端营销频道场景、小程序场景以及 PC 中后台场景。这里面几个场景的设计模式都有自己的特色，针对各个场景来设计垂直的识别模型可以高效地提高单一场景的识别准确度。过程思考既然使用了深度模型，有一个比较现实的问题是，模型的泛化能力不够，识别的准确率必然不能 100% 让用户满意，除了能够在后续不断地补充这批识别不到的样本数据外，在这之前我们能做什么？在 D2C 的整个还原链路里，对于识别模型，我们还遵守一个方法论，即设计一套协议或者规则能通过其他方式来兜底深度模型的识别效果，保障在模型识别不准确的情况下用户仍可完成诉求：手动约定 > 规则策略 > 机器学习 > 深度模型。举个例子比如需要识别设计稿里的一个循环体：初期，我们可以在设计稿里手动约定循环体的协议来达成根据图层的上下文信息可做一些规则的判断，来判断是否是循环体利用机器学习的图层特征，可尝试做规则策略的更上游的策略优化生成循环体的一些正负样本来通过深度模型进行学习其中手动约定的设计稿协议解析优先级最高，这样也能确保后续的流程不受阻塞和错误识别的干扰。业务落地 **2019 双十一落地** 在今年的双十一场景中，我们的 D2C 覆盖了天猫淘宝会场的新增模块，包括主会场、行业会场、营销玩法会场、榜单会场等，包含了视图代码和部分逻辑代码的自动生成，在可统计范围内，D2C 代码生成占据了大比例。目前代码的人工改动的主要原因有：全新业务逻辑、动画、字段绑定猜测错误（字段标准化情况不佳）、循环猜测错误、样式自适应修改等，这些问题也都是接下来需要逐步完善的。 D2C 代码生成用户更改情况整体落地情况我们对外的产品 imgcook，截止 2019.11.09 日，相关的使用数据情况如下：模块数 12681 个，周新增 540 个左右；用户数 4315 个，周新增 150 个左右；自定义DSL：总数 109 个；目前可提供的服务能力如下：设计稿全链路还原：通过 Sketch、PhotoShop 插件一键导出设计稿图层，生成自定义的 DSL 代码。图像链路还原：支持用户自定义上传图片、文件或填写图片链接，直接还原生成自定义的 DSL 代码。后续规划继续降低设计稿要求，争取设计稿 0 协议，其中分组、循环的智能识别准确度提升，减少视觉稿协议的人工干预成本。组件识别准确度提升，目前只有 72% 的准确度，业务应用可用率低。页面级和项目级还原能力可用率提升，依赖页面分割能力的准确度提升。小程序、中后台等领域的页面级还原能力提升，含复杂表单、表格、图表的整体还原能力。静态图片生成代码链路可用度提升，真正可用于生产环境。算法工程产品完善，样本生成渠道更多元，样本集更丰富。D2C 能力开源。未来我们希望能通过前端智能化 D2C 项目，让前端智能化技术方案普惠化，沉淀更具竞争力的样本和模型，提供准确度更高、可用度更高的代码智能生成服务；切实提高前端研发效率，减少简单的重复性工作，不加班少加班，一起专注更有挑战性的工作内容！

发表了文章 2020-02-18

疫情期，APP 崩了怎么办？阿里工程师公开高可用架构笔记

阿里妹导读：在这场抗击新型冠状肺炎的战役中，普通人能做些什么呢？可能「宅」是现在大多数人能作出的重要贡献之一。在这些深「宅」时光里，用手机或电脑打打游戏、追追剧成了很多人暂时忘掉现实的「良药」。可是！正要上分的游戏突然崩了，正演到关键的剧情突然挂掉，最近“某某 app 崩了”带着广大网友都能领悟的痛频上热搜。网友纷纷呼唤程序员小哥哥快上班，其实疫情期间线上流量激增，很多线上应用都面临着巨大挑战……要解决高流量和突发流量这种业务冲击下，线上应用频繁崩溃的问题，首先需要审视企业目前 IT 架构是否能支撑未来的业务发展阿里巴巴在多年双11 高并发，高可用和高客户体验要求背景下积累了相应的技术体系，并赋能罗辑思维等客户，帮助他们落地全链路压测。本文整理自高用户、突发高流量场景下的真实案例，公布阿里在高可用架构建设过程中的实践笔记，期待帮助更多企业从容应对接下来的高流量场景。你的应用为什么崩了？非常复杂的服务端在我们的日常生活中因为 app 侧相对稳定，“崩”一般发生在看不见摸不着的“服务端”（或者叫云端），而这个服务端有多复杂？以一个较为成熟的云上架构为例，光是阿里云中构建一个在线服务可以用到的云计算基础、安全和企业应用三个分类的云产品数量就达到几乎 200 款。而我们从客户端（App/PC）到达服务端会涉及到的关键节点就有 CDN、动态加速、高防、应用防火墙、4/7 层负载均衡、前后端服务集、缓存、数据库存储、中间件、基础设施层等等，整个链路都面临着不确定性，比如负载均衡中影响流量的产品规格就有 5 个，后端服务的服务规模化问题更是复杂和难以评估检验，这其中任何一个节点出问题都会导致服务不可用，给最终用户一个“崩”的感觉。同样的问题在专有云、混合云和自建 IDC 都有。如何能有效的全面检验服务端吞吐能力、发现所有问题甚至是做好容量规划，具备对峰值的流控调度能力是所有企业都需要思考和应对的。没有提前规划的服务能力如果应用没有对自己的服务能力进行提前规划，没有提前做好关键节点的规划，对线上的应急措施如弹性扩容，线上防护，熔断降级等都不具备，在面对业务突发时，就很难保证核心接口能够稳定对外服务。一旦，出现应用“崩了”的情况下，很多企业无法采取正确的手段，匆匆扩容非但不能解决问题，反而带来更多不可预期的问题，导致“崩了”进一步的恶化。除去因问题发现、容量规划、流控和熔断降级引起的“崩”外，运维态的隐患问题如故障影响面、配置一致性、监控和根因分析相关工具、复杂的人员组织的高可用程度等，如果没有足够的演练和验证方案，一样会在关键时刻让你的应用出现“崩”的情况。阿里巴巴工程师的高可用架构建设笔记下面我们将阿里巴巴工程师在高可用架构建设实践中，积累的真实经验以笔记的形式分享给大家。架构设计首先要实现架构可视化。利用 AHAS 的架构感知可以全面了解云上系统架构，以可视化的方式直观呈现云资源、容器和应用间分层依赖关系。服务器、存储、网络是现代云平台的基础设施。随着上云战略的推进，越来越多的企业将业务、服务、系统构建在云平台上。开源软件和云服务的多样性，开发语言的异构性，以及企业 IT 团队的组织和能力差异，都提高了标准化的复杂性。架构感知功能应运而生，通过采集和分析操作系统及第三方标准接口，捕捉进程级的调用关系，并使用特征库算法识别进程所使用的技术组件，最后在服务器、容器和进程这三个维度上以可视化的方式展示应用架构，给用户一张全面清晰的云上架构地图。围绕这张基础的视图，会持续衍生出云资源、容器和应用架构多维度的架构视图，还有搬站、重构梳理和资产管理等场景化的视图，真正做到CMDB可视化，驱动问题发现助推业务增长，释放云上的更多维度的红利。而关于强弱依赖治理，因为强依赖本身意味着一荣俱荣，一损俱损。结合 AHAS SDK 的引入和预埋，一旦当平台最大吞吐能力到达瓶颈时，除了入口或者web类应用的业务峰值流量限流可以起到第一层的保护作用外，还可以将预先标记为弱依赖的服务平滑下线，从而达到节省更多资源保障核心计算能力的目的，同时还可以去除非核心对核心服务的影响，最终通过合理高效的服务降级最大程度获得业务和成本的平衡。而使用了AHAS SDK之后在编码时，只需要关心如何定义资源，即哪些方法/代码块需要保护，而不需要关注如何保护这个资源。然后通过添加规则来保护资源，规则添加即时生效。容量规划外网仿真压测：首先可以通过 PTS 高效快速构建同模型和量级的业务流量，对于开源主流的 JMeter 脚本可以直接 100%兼容，对于没有现成脚本的情况可以使用PTS自研的可视化交互进行0编码编排，编排完成后从公网的各地域运营商发起，真实模拟特定业务场景下的外网流量，从而全面验证和探测云上或云下整体架构（从网络接入到应用服务内再到存储层和基础设施）的瓶颈和问题。全链路压测：更进一步的，如果在生产环境想直接精准衡量业务容量的情况，可以通过 PTS 相关解决方案使生产环境具备压测流量识别和路由到指定影子存储区域的能力，结合相关影子存储区域的准备，然后做到同样规模基础数据上的业务流量压测同样的生产环境，最终达到精准衡量线上生产环境的能力，当然，对于压测流水数据由于已经隔离开，所以可以方便安全的清理和维护。业务监控面对复杂的应用环境和高速增长的业务，ARMS 能帮助用户快速构建各种环境下完整的监控体系，实现从页面到数据库、从应用性能到基础架构资源、从 IT 到业务的端到端监控。减少故障排查时间，降低跨部门沟通成本，最终降低因为故障和体验差给企业带来的损失。线上管控于运行态或已有应用可以通过 AHAS 探针形态（除AHAS SDK外更轻的方案）在不修改代码的情况下进行业务洪峰的流量强力控制、消息场景的削峰填谷，而对于结构复杂的可以将系统内或外不稳定的因素迅速降级让业务保持稳定，同时还有单机过载保护（根据 RT 动态调节入口流量）的兜底能力，甚至很多时候系统来不及压测或者不知道配置什么规则的时候单机智能过载保护是个很好的功能和方法。以上都在运行态和运维侧即可完成引入和控制。对于线上配置项和业务属性值通过 AHAS 开关模块的轻量级方案进行安全和统一管控，这部分能力即将开放，敬请期待。日常巡检风险的提前暴露，通过 Advisor 智能顾问对云上主要云资源进行全面的巡检和风险识别，规则都来自于阿里云一线TAM同学面向客户的技术体系积累及阿里生态内 SRE 最佳实践的融合。基于前述的架构地图和用户的输入，可进行更深层次的应用/业务架构层面的巡检和建议。常态化演练 AHAS 的故障演练模块遵循混沌工程实验原理并融合了阿里巴巴内部实践的经验，基于此用户可以建立流程完整而且可视化程度很高的故障演练体系，可方便的对基础资源、应用服务、容器服务和云平台4层进行超多维度的编排和定制，同时产品还提供了丰富的成熟故障经验库。从而帮助用户实现包括架构、业务、人员的全面高可用提升。故障演练在依赖治理、业务连续性提升和故障修复验证等场景中都有巨大作用。工具一览表 1、应用高可用服务 AHAS 专注于提高应用高可用能力的云工具产品，提供应用架构自动探测，故障注入式高可用能力评测和一键流控降级等功能，可以快速低成本的提升应用可用性。 https://www.aliyun.com/product/ahas 2、性能测试 PTS 面向所有技术背景人员的云化测试工具。有别于传统工具的繁复，PTS以互联网化的交互，提供性能测试、API调试和监测等多种能力。自研和适配开源的功能都可以轻松模拟任意体量的用户访问业务的场景，任务随时发起，免去繁琐的搭建和维护成本。更是紧密结合监控、流控等兄弟产品提供一站式高可用能力，高效检验和管理业务性能。 https://www.aliyun.com/product/pts 3、智能顾问Advisor 智能顾问 Advisor 根据用户情况，结合阿里云长期以来的客户侧最佳实践，基于TAM（Technical Account Management）服务体系的核心基础能力，全方位地为用户提供云资源、应用架构、业务性能及安全上的诊断和优化建议。现在，越来越多的阿里云云原生客户可以通过 Advisor 便捷地享受专业的 TAM基础服务，更好地用好云。同时，我们也会围绕 Advisor 为有相关需求的客户提供专项深度的 TAM 服务。 https://www.aliyun.com/product/advisor 4、企业级高可用架构解决方案脱胎于阿里巴巴电商业务下的高可用技术体系经过所有的双11流量洪峰考验、日常稳定性考验，已经服务于阿里全生态并开始服务外部的企业客户，解决方案为企业提供的包括营销活动支撑、整体成本控制（全链路压测、容量规划、流量控制、调度）、应急应对能力（开关和预案）、容灾逃逸能力（架构感知、故障演练、异地多活、单元化）。 https://www.aliyun.com/solution/ehasl 5、混沌测试工具 ChaosBlade ChaosBlade 是一款遵循混沌工程实验原理，建立在阿里巴巴近十年故障测试和演练实践基础上，并结合了集团各业务的最佳创意和实践，提供丰富故障场景实现，帮助分布式系统提升容错性和可恢复性的混沌工程工具。 https://github.com/chaosblade-io/chaosblade 6、轻量级流量控制框架 sentinel 以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度来帮助您保护服务的稳定性。

发表了文章 2020-02-14

从大年初一开始，他们在支付宝 7*24 小时工作

“你好，我是支付宝反欺诈中心客服醒醒，系统检测到您刚刚在支付宝上有一笔交易存在被骗风险。可以根据实际情况核对下交易吗？” “你好，我是客服人员小保。你在支付宝购买的好医保长期医疗保险的保障期限一年已经到期……” “你好，我是支付宝客服中心机器人，因春节假期延长，货币基金交易日延后至2月3日……” 这个春节，在全民抗击新型肺炎期间，AI赋能的智能语音机器人走上前台，快速补充人力不足的影响，成为支付宝与客户沟通的主力，7*24小时不间断服务百姓，每日呼出电话服务时长覆盖了10%至60%原有人工外呼，并根据当前情况迅速扩展新的覆盖场景。回访数据显示，大部分用户都没意识到对面不是真人，他们认为，交流顺畅，95%以上点了好评。这是如何做到的呢？本文将详细介绍在这背后蚂蚁金服智能客服技术团队所做的工作。事实上，因为新冠病毒疫情，不少企事业单位也出现了因大量人员不能返岗而导致的人手严重不足的问题。在服务蚂蚁内部各业务的同时，智能客服技术团队也主动将技术能力开放，积极与各行各业的专业人士探索，如何基于各自独特的应用场景，训练个性化的智能机器人。一、智能语音应用场景智能语音机器人来源于支付宝的智能客服热线技术，在历次淘宝、支付宝活动中，支付宝小二需要处理数以十万计的热线电话进线量。忙到什么程度？活动中排除困难最多的客服小二会获得“金膀胱”奖的荣誉，可以想见热线处理多么繁忙。但是，小二们大量宝贵时间都花费在了“问题厘清”、“简单问题疏导”上，而线上还有更多的客户在电话的另一头等待着服务.... 显然，随着业务的持续深入发展，AI赋能客服成为必要的一环。支付宝技术团队研发出了AI语音机器人，在真人客服之前全面覆盖问题、厘清环节，并将近五成的简单问题通过机器人回答的形式进行解决，大量节约了客服小二的宝贵时间，用来解决复杂的问题，安抚客户的情绪。各个行业和部门对于语音机器人也有着同样迫切的需求：在银行、保险等金融行业，行业监管要求在用户购买相关产品后，需要对话式的进行用户回访，保障用户对于金融产品的知情权；再比如支付宝通过支付码改变了整个中国的零售行业，而使用支付码的小商家需要及时了解支付宝的相关产品及活动，更好的转型新零售应对新的挑战；大安全部门每天阻断上万起欺诈交易，保障支付宝会员资金的安全，同时需要了解潜在欺诈交易的情况，向用户说明为何交易会失败，叫醒热线的“醒醒”客服成为网红；客服部门更进一步，及时识别出用户操作路径中可能已经出现的困难，在用户呼入热线前“主动服务”降低求助率，为用户带来更加顺畅的使用体验...... 正是看到了这些需求，依托于成长于智能客服的智能语音机器人技术，支付宝开始全面与网商、保险、商家、安全等多个部门进行深入合作，建立并完善外呼平台。智能的AI客服小二主动出击，化身成了耐心讲解金融产品知识的保险理财客户经理、及时通知最新活动并帮助部置以达到最优活动效果的活动推广专员，化身成了每个人贴身关怀的钱包管家和随身助手。二、智能语音背后的技术解决方案通过半年多的外呼平台搭建，基于部门团队在热线客服、在线客服AI机器人领域的技术沉淀，针对电话交互的特殊业务需求，我们逐步沉淀了较完善的外呼智能交互技术解决方案。针对于外呼智能交互机器人核心的自然语言理解及对话状态跟踪技术，我们发挥算法专长，深入探索。形成了一整套核心算法组件：无流程外呼对话：基于模仿学习和强化学习技术，从历史对话数据中学习当前状态下合适的对话策略、选择合适的外呼话术，自然、流畅地跟用户完成交互，高效达成呼叫的目标；基于小样本学习的意图识别：减少用户语料配置的复杂性。同时配合语料纠错、语料扩充、新意图发现等技术，帮助运营快速、准确地完成意图或流程配置；基于检索和生成模型的用户模拟：可以产生符合一定用户目标和人设的用户回答，模仿真实用户，完成对意图配置、流程和对话模型的自动评估。独有的算法数据标注平台体系。运营可以通过平台直接进行算法模型的标注、训练，同时模型从线上运行数据中提取“标注未覆盖”、“标注错误”等，辅助业务运营同学快速进行语义理解模型迭代。完整的算法闭环体系，将AI交互技术应用门槛大幅降低，不仅可以让运营同学直接上手使用，还能对他们的使用过程进行引导及反馈，对模型配置中的疏忽、错误快速纠正。业务在极少的运营投入的情况下就能够获得完整的外呼语义理解能力。同时，我们与网商、保险、商家、大安全等多个业务方密切合作，形成了一整套的外呼业务流程及意图等通用技术资产沉淀。完善的意图沉淀：我们目前结合商家、保险、银行等金融属性外呼需求，累积沉淀了多个可通用的用户通用意图表达，如正在开车不方便，晚点再沟通；确认外呼人员身份；用户有进一步的问题需要转入人工等。可以快速复用，搭建起新的外呼方案；外呼子流程：针对于用户与外呼主要目的相关的部分疑问，可以通过搭建知识库使用外呼子流程来进行处理。如用户不方便的时候，进入到预约回访时间子流程；用户进行敏感操作的时候，进入到身份证核实子流程先核实身份信息等。使业务运营集中注意力在主要业务目标交互链路优化上，有效保障用户体验的同时提升运营效率；基于业务打磨的技术资产沉淀进一步降低了新业务接入的运营成本。新的业务接入可以借鉴或者直接使用已有的相关流程，将主要精力集中在业务主交互链路打磨上，快速达到业务目标。目前我们将主要业务形式进行抽象整合，形成了完整的外呼运营平台及多种外呼解决方案，进一步提高外呼业务接入效率，可以在几个小时内形成智能的外呼交互能力。运营平台支持拖拽式对话流程配置框架，快速灵活支撑业务落地；支持日呼叫千万量级的外呼调度系统，结合用户特征，对用户的有效拨打时间进行预测；支持实时外呼及预约外呼，有效提高用户接触效率；与沟通平台深入整合，有效在通知、短信、外呼多种渠道进行整合通知。既能在保证接触效果的基础上降低运营成本，又能通过渠道整合，在用户获悉信息的情况下直接将用户带入运营活动信息详细页面，进一步提高用户转化；外呼产品化解决方案，与商家、保险深入合作，打造活动告知、活动参与指导及智能回访等多个解决方案，可以通过填写个表格的方式快速搭建外呼机器人。以上的技术沉淀结合达摩院的语音识别和合成技术，形成了自然流畅的交互机器人，大部分交互的用户认为在与真实客服进行交互（主要业务对话完成率达到80%以上，抽样回访调查，对话满意度达到95%以上），保障了交互的完整性和业务效果。三、智能语音机器人的未来在实现模仿真人人声与客户进行多轮沟通对话之后，智能语音机器人有望改变现有电话业务的工作性质。首先，大批量的电话号码外呼通过智能语音机器人来做，大大节省了时间的同时提高了回访的效果，而且机器人交互的流程更加标准和规范，相比人工水平参差不齐，风险更小，更不容易被投诉。机器人无需培训立即上岗，同时AI语音机器人自身属性保证了业务知识可以不断累积，交互形式可以不断演化，从懵懂新人逐步成长为独挡一面的万事通，不存在资深人员流失带走业务沉淀的情况。随着AI技术的不断发展，强化学习技术可以有效的主动探索更有效的沟通路径，更加快的形成交互策略，甚至可以通过算法及数据分析为运营同学对于业务理解提供更好的数据支撑，更好的了解客户及用户的真实诉求。其次，当天外呼的所有沟通内容，智能语音机器人的工作可自动记录，分析共性，标签化CRM管理，多维度建立接听电话者画像，提升管理效率，助力生成后续的个性化整合服务方案。第三，智能语音机器人能够快速学习人工客服人员的经验，并通过不断汇总、分析、梳理问答信息，能将常见咨询、各行业产品及服务相关的信息扩充成了一个强大的知识图谱，可以保证交流的满意度。最后，可以进行更加灵活的调度和协作，包括机器与机器间的协作、人机协同等。一旦出现某个业务人手不足的情况，可通过随时上岗的AI智能语音机器人无缝转接人工坐席。我们曾经拒绝客服机器人，是因为它们是冷冰冰的，并且无法解决客户问题，但将来，智能语音客服将会和真人一样有温度，甚至比真人提供更好的服务，成为科技改变世界的下一个绝佳案例。

发表了文章 2020-02-13

停课不停学，优酷直播如何将网课点名延迟降到0.6s？

阿里妹导读：受疫情影响，各中小学校延迟开学，优酷宣布发起“在家上课计划”，为无法到校教学的老师们提供免费的直播授课工具，直播课程将于2月10日开始陆续上线，在直播过程中如何提升和保障流畅的互动体验？优酷直播流媒体团队做了低延时流媒体技术的探索实践，实现了在用户体验不下降的基础上，让主播与主播延时<300ms，播与粉丝延时<600ms，解决了直播间各类互动问题。接下来，阿里文娱的乾戒将具体介绍探索过程。一、行业的用户体验分析互动直播场景中有主麦主播、辅麦主播、粉丝三个要素，这三者之间关系构成了直播间的各种互动场景。 1.主麦主播、辅麦主播可以无障碍地进行音视频通话，通常延时在300ms以内； 2.（主麦、辅麦）主播与粉丝互动场景；主播说话，而粉丝以文字、图片、送礼物等方式进行互动；这种差别造成一次互动的延时在3000ms以上，想象一下如下互动场景：进场特效播放完依然没有收到问候；当主播与粉丝一起玩“王者荣耀”时需要偷塔时，无法满足；当主播与主播PK时，其中一个主播最后几秒想拉票时，无法满足； ... ... 如何提升直播过程中三个要素之间的互动，让主播与主播之间、主播与粉丝之间达到一致的用户体验？优酷直播流媒体团队做了低延时流媒体技术的探索实践，实现了在用户体验不下降的基础上，让主播与主播延时<300ms，播与粉丝延时<600ms，解决了直播间各类互动问题。二、作茧自缚：传统解决方案传统直播解决方案中主播之间以实时通信的方式传输延时小于300ms，但是主播与观众之间通过链路传输、CDN分发整个延时往往在3000ms左右，如下图：从图上我们可以看到产生延时的主要原因就是RTMP传输链路、CDN环节、观众播放器缓存三个环节产生；如果想要提升用户的体验，就必然从这三个环节上做改动，尤其是CDN把持了传输链路环节，然而CDN不是你想改就能改的。基于这样的分析我们可以得出这样的结论：视频CDN大大减少了开发人员的工作量；你能做多好，取决于你控制的链路有多长； CDN侧不可控，所以等待CDN的改变也遥遥无期； CDN侧不可控，所以做一个和服务器交互的低延时播放器也没戏；传统的解决方案是一张温柔而又可怕的温床。三、蜕变之痛：低延时直播系统针对上面的问题，我们解决方案简单粗暴：做一个全链路都可以控制的流媒体传输系统，如下图： 1. 山重水复疑无路——项目挑战想好就做，但是蛮干往往没有好结果。这个设计使用CDN的思想改造了整个实时通信系统，既兼顾CDN的大并发分发，又兼顾实时通信的低延时。无论是谈实时通信系统还是谈CDN都不是个小题目，何况两个融合的系统，这里面“水很深”“坑很多”。然而挑战还不止这些，实际的工程中，如何降低延时、如何保证流畅率往往有是相互矛盾的话题，降低延时就要降低播放侧buffer和服务侧的buffer，随之卡顿率就会上升；而想流畅率上升就要增大buffer，随之延时就变得更长；无论怎么调整buffer，问题都这里，如何解决呢？ 2. 柳暗花明又一村——解决方案低延时直播系统根据具体业务需求，融合CDN、私有实时通信协议、WebRTC、云原生等技术完美解决了项目的各类苛刻要求，把问题模型转换为技术角度看： 2.1 延时的产生及可控性分析：从上图我们可以看出来，可控的唯二也就是传输层、播放器buffer两部分了。在低延时项目中RDN系统控制了整个传输过程，优化了每一个细节，把延时降至118ms以内，低延时播放器自适应动态控制buffer大小、严格控制音视频加减速，保证流畅率的基础上又使延时在415ms以内。通过控制播放侧目标延时实现流畅优先、延时优先两种策略，满足主播连麦互动、粉丝互动两种业务场景。 2.2 CDN进阶为RDN系统传统的CDN、视频会议系统可以自行查看网上的方案，RDN系统是一个融合CDN架构，并以视频会议媒体服务器为节点的系统。RDN在进行媒体传输采用懒加载的方式进行，当主播把流传输至接收的边缘节点，此时如果有观众播放流，会通过GSLB返回最近的边缘节点并进行资源的索引把流快速的下发至播放侧的传输SDK。媒体流的分发示意图如下： 2.2.1 唯快不破——传输延时如何降至最低传输延时、播放侧延时是唯二可控的部分，且看我们如何把传输降到最低： 2.3 播放器进阶为低延时播放器低延时播放器是系统中延时控制的重要环节，是系统中唯一延时可控且可调的部分。相比于传统播放器功能既要满足流畅率、秒开率、音画同步等用户指标，又要保证延时足够低。低延时播放器架构图： 2.3.1 用户体验第一——低延时场景下如何保证用户体验低延时播放器通过定制优化后的neteq，抵抗网络的抖动、丢包等问题，显著提升弱网情况下的用户体验，通过滤波后的音画同步方案，保证在音视频快速加减速同时又能保证用户的体验。 2.4 扁鹊全链路监控系统扁鹊系统收集端侧、服务器侧日志，不但整个链路的服务质量，也用于排查各类线上问题。四. 羽化之美：数据报告在流畅率、秒开率不低于传统直播方案的场景下，互动延时指标大幅降低86%。系统自2017年稳定运行至今，为直播用户提供了低延时互动、点击即见、清晰、流畅的高质量互动直播间。并支撑了来疯秀场PK，低延时直播各类场景，保证了来疯两年多的各类比赛顺利进行。五. 回顾历史：我的思考低延时直播系统是由传统直播技术、实时通信技术、WebRTC技术融合，专为互动直播而生的系统。达到了文字和音视频同步的效果，像“欢迎大哥”“拉拉票”、“打他”这些欢迎、拉票等直播互动再也不需要等待。回顾整个系统的诞生，我的技术思想也在逐渐的变化，回想初次接触这三个技术：传统直播技术 = RTMP、CDN、ijkplayer 实时通信技术 = MCU、SIP、RTP/RTCP WebRTC技术 = JSEP、P2P 、SFU、ICE、SDP、neteq 后来深入了解这些技术细节、互动直播业务的需求、开发过程中的痛点，开始思考可以用这些技术再往前走一步，自研一套低延时直播系统一劳永逸的解决这些问题。经过前期详细论证确定正确方向后，虽然过程困难重重，秉着“只要路对了就不怕远”“只要精神不滑坡，方法总比困难多的”精神，最终还是安全的抵达了对岸。

发表了文章 2020-02-11

服务社区抗疫软件与智能外呼机器人！我们已经准备好了

2月10日下午，在国务院新闻发布会上，民政部陈司长发出一个号召：“能不能开发一个服务社区抗疫的软件，这比捐十个亿还管用！” 在此报告，阿里已经准备好了！阿里云联合支付宝、钉钉推出免费的智能社区疫情防控小程序，可以帮助社区一线工作人员完成出入登记、健康打卡、疫情通知、在线问诊、疫情问答、社区生活、患者同行程等工作。而且，很快还将与体温贴、AI摄像头、守门贴等智能硬件产品联网，帮助轻松掌握社区出入人员的健康状况。同时，为保护社区防控基层人员的安全，阿里云推出智能外呼机器人，通过智能外呼应用，社区工作人员可对小区居民，尤其高危群体（疑似病例、医学观察人群）进行逐个电话外呼，在对话中整理体温、腹泻、咳嗽等健康信息，并自动形成报表。守护社区保护家园我们和你在一起 PS：用支付宝或钉钉扫码即可进入专属钉钉群，有专人来引导开通。

发表了文章 2020-02-10

为记录数万人的健康情况，阿里造了1个机器人

什么是“防疫宝”？随着武汉新冠疫情的发展，阿里也紧锣密鼓地行动起来，健康打卡、捐款一个都不能少。但这过程中，大家也发现一些不方便的地方，疫情“实况”好像不是那么“实时”，HRG在一个个群中努力催同学打卡，但同学想要打卡却要在群中到处翻找链接。看到这些情况，阿里云IoT事业部的太博、墨澜、貔阁、齐穹和织夏几位同学在26日下午快速利用机器人工厂和IoT事业部产品IoT Studio开发了一个“防疫宝”钉钉机器人。群主只要花1分钟就能把防疫宝部署在一个钉钉群中，随后防疫宝每2小时推送最新的疫情到钉钉群中，并提醒大家健康打卡，大家在群中也可以@防疫宝，询问打卡链接、捐款二维码、实时疫情、实时问诊等，非常方便。这个机器人一经推出，就受到了各个阿里群的欢迎，已经部署了76个阿里内部群，覆盖了数万阿里人。即用即插简易版群管理员直接点击智能群助手，添加“防疫宝”机器人即可完成问答式机器人的添加。问答机器人可以协助完成日常打卡，疫情报道以及企业最新消息推送。定时推送功能需要进群联系我们手动添加。定制开发完整版如果各位想要添加更多定制化功能，可以尝试从头开始制作自己的“防疫宝”。我们使用的是阿里健康的数据+钉钉机器人+IoT Studio业务逻辑开发的架构。创建项目首先我们需要进入阿里云物联网平台（https://iot.console.aliyun.com），然后点击IoT Studio进入物联网开发工具。创建一个项目，命名为“防疫宝”。创建服务然后进入项目内，打开服务开发，点击“创建服务”，选择“钉钉防疫宝”的模板进行创建。然后进入服务开发工作台，可以看到中间有一个“疫情通报”的节点，专门用于返回阿里健康的实时数据。我们只需要修改后面钉钉机器人节点的Webhook参数即可。配置机器人 Webhook参数来自于钉钉群内添加的“自定义机器人”，注意需要在添加的时候加上安全校验关键字“疫情”“数据”。获取Webhook之后将它粘贴到钉钉机器人的配置项内。然后可以部署启动这个服务了。调试与验证然后点击调试，输入一个模拟的时间，回到钉钉群，看看能否触发实际推送即可。调试完成后发布服务，即完成整个定时推送的配置了！如果需要定制对话机器人，可以基于机器人工厂里的NLP.ai模板进行创建。这里不再赘述。

发表了文章 2020-02-06

不得不在家办公后，技术人如何在线研发？

阿里妹导读：为响应国家号召，各“大厂”纷纷发出在家办公，延迟上班的通知，一时间“在线协同办公”成为热点。不同于大型集团公司，有足够财力和能力构建远程办公系统，中小企业既缺乏足够的预算又缺乏相应的经验。阿里云云效一直致力于成为数字企业的研发效能引擎，在这个特殊时期，我们希望可以将自己的经验和工具分享给中小企业，让他们在家也能安全高效地开发软件。因此我们特别邀请了阿里巴巴高级技术专家张燎原，详解“在线协同开发”的要诀。在线研发协同的基础是高可见性及快速连接为了应对互联网业务的复杂性和不确定性的特点，现代软件开发，逐步过渡到以客户导向，小团队（单兵）作战能力，快速链接生产要素，持续快速高质量地交付有效价值的方式。分工越来越细，整个软件生产的过程，就是分而治之地解决问题，然后持续地集成发布的过程。这种软件开发方式，谁拥有更高的机动灵活响应能力，和更高的协同性，谁就能在竞争中抢占先机。互联网技术让互联互通变得异常简单。通信技术的发展，对互联网应用起到了极大的促进作用。即时通信工具，也已经超越了聊天的功能，钉钉项目群、钉钉视频通话、钉钉视频会议，再到其平台演化出来各种OA应用，助力快速连接。协同的基础之一就是连接，从人之间的连接，到人与物之间的连接，快速实现组织在线、沟通在线和协同在线。生产工具的发展，显著提升了软件生产过程的可见性。研发过程的在线化，让软件工程的可见性到了前所未有的新高度。生产工具的进步，已经让生产过程没有任何秘密可言，隐性的工作逐渐显性化。而协同的基础，就是信息的共享，生产过程的可见性。为人们所熟知的Scrum开发框架中，将透明性（Transparency）列为三大支柱之首。注：Scrum三大支柱分别是：透明（Transparency），检视（Inspection）和适应（Adaption）。软件架构与部署方式的演进，有利于分工协同。根据康威定律：设计系统的架构受制于产生这些设计的组织的沟通结构。那么，反过来，系统设计的架构，也反作用于沟通结构及软件的集成方式。同时，在云开发、中间件、中台化策略的大环境下，业务层更多关注在业务创新上，分工变得越来越细。部署架构的演进，也让系统中的局部，可以独立持续部署。小团队，或单兵的价值体现越来越大，而团队与团队之间，人与人之间的连接，也从传统树状的方式，逐渐往网状的方向演进。协同，就是在这样的网状环境里，能够清晰地识别出需要连接的生产要求，然后快速在线协同。对于知识经济活动，高可见性，快速连接能力意味着灵活协作的可能，而在线化是这一切的基础，在线化让人们有机会在任何时候任何地方，快速集结、组织协作，让SOHO这样的远程办公方式成为可能。在线化，是数字化协作的基础，为未来智能化的演进创造了可能的条件，这是现代化软件研发手段演进的趋势。下面，我们将从“研发协同”， “代码协同”及“发布协同”三个方面，阐述如何在线协同，身处不同地域，不同时区的你我他，能够快速连接起来，真正进入到数字化研发时代。在线项目协同需求协作，从拉通和可视化端到端的价值流动开始可见，是协作的基础。通过电子看板，以需求为流动单元，端到端可视化价值流，以流动效率为核心组织需求交付。可视化端到端价值流必须做到：价值驱动，即每一个流动单元体现的都是体现用户价值的业务需求；前后拉通，即可视化的目标是“端到端”的价值流，始于用户问题的提出，终于用户问题的解决。我们可以通过以下三个标准来检验可视化的效果，即：是否能反映端到端的交付过程是否能即时体现影响价值流动的瓶颈和问题是否能依据可视化的信息进行协作和做决定同时，打通从项目协作到软件发布的全链路，代码提交和发布信息同样可以即时反映到需求卡片上，集中及时的工作状态同步，减少沟通基本靠吼的套路，使得项目管理的目标更关注在价值交付和问题解决上。管理价值流动，构建价值反馈闭环，让交付更可控软件交付的关键，是客户价值的流动，而组织壁垒、沟通延迟、协作阻塞是主要障碍。基于端到端可视化的价值流看板，产品需求排期，还是团队每日站会的任务指派，围绕需求看板，来组织日常的项目协作。自右往左检视需求的交付状态，从测试工程师、开发工程师到产品经理，跨职能协同。同时，需求的任何风险及问题，高亮显性地展示在看板上，以钉钉等即时通信工具，快速反馈到责任人，做到即时发现、即时响应，就问题快速链接集结。形成从需求规划、需求排期、每日站会，再到需求复盘的完整价值反馈闭环。从整体交付节奏上，形成月规划、周排期、日站会的节奏。而这一切，完全可以通过在线化的电子看板进行。限制在线品数量，加速业务需求交付影响需求（价值）流动效率的关键是批量和并行，通过限制在制品数量（我们称之为束水攻沙），加速需求交付。同时，数字化协作，有利于研发过程中，效能数据的沉淀，建立效能改进的基线和愿景目标，以客户响应周期和质量提升为目标，驱动问题的发现和解决，建立持续改进的基础。在线代码协同代码协作是代码集体所有制（Collective Code Ownership）团队成员共同为代码负责。基于Git分布式版本控制系统，实现了基本的代码托管理能力。在当前的代码协作概念中，分支即是协作的载体，世界各地的开发者们可以根据产品需求，建立不同分支，同时开发。恰当的分支模式，让分散的工作，快速集成在一起，并在版本上可追溯。每个代码库的readme信息详细说明代码设计，建立基本的代码质量管理标准（如单元测试和自动化的增量代码静态扫描），保证持续增量代码不会影响到已有功能，让协作成为可能。提升代码的可见性，助力代码协作无论从简单的复杂度、重复度分析、依赖分析，再到领域语言识别，安全敏感信息识别等，像阿里巴巴代码规约等工具，极大提升了代码的可见性，程序员们已经完全可以从大量的代码中，抓住关键信息。同时，借助云端IDE、云端分布式代码托管工具，有效地促进社交化编程，无论是结对编程，还是代码评审，让代码本身及编码过程显性化，可以：促进团队内部知识共享，提高团队整体水平，确保团队统一规范，不出现“天书”代码；同时，工具的早期介入潜在缺陷发现率可以提升30%；透明的代码，多人的讨论可以促进正向鼓励，主动思考和追求卓越。代码安全代码在线化协同，代码共享、复用文化的建立都依赖于代码平台复杂的权限控制体系，这是一把双刃剑，越开放意味着代码泄露的风险越大，但是越封闭意味着协同效率低下。为了让开发者可以更好地享受代码协作带来的红利，需要重点注意以下几个方面：代码中的敏感信息：比如数据库密码，被有意或无意泄露后会导致公司业务出现致命打击。访问权限控制：常见的有访问IP控制，离职权限回收，代码库可见范围设置等。异常行为风险识别：拥有事后审计，事前预警的能力，比如大量下载代码异常行为检测和预警。代码协作是技术卓越的追求，是培养软件匠艺精神的机会，借助先进的代码协作工具及技术手段，促进代码及编码过程的可见性，同时，让每一位程序员能够有信心地提交每一行代码。在线发布协同现代化企业级软件交付过程常常是多人多角色协作，跨越多个系统交互，同时为了保障交付可靠，交付流程往往也是复杂和难以完全标准化。而阿里巴巴为什么能紧跟市场变化，快速写出高质量软件，这得益于多年沉淀出的一套完整DevOps方法论和产品，确保软件交付过程在线高效可靠。从流程标准，工序改进，建立在线发布协作在线发布协同，需要基于同一个交付流水线进行，首先，需要拉通软件集成发布的完整流程。打通从变更到交付的完整系统；将流程工具化，通过工具串起整个集成交付过程；同时，明确流程中各阶段的准入准出标准，下游活动基于上游产出质量。其次，按工序建立质量守护系统，并使每一道工序自动化。再次，建立反馈机制，有问题能够精准定位，即时响应，快速修复。建立相应的度量反馈机制，还能对流程和工序进行持续优化。真正的在线发布协同，应该是满足：流程工具化、部署无人化、测试自动化、反馈数字化的要求。特性分支驱动多人多角色在线协作为了实现多人研发不打扰，代码功能可以自由可靠组合交付，阿里巴巴生产经验积累出一套AoneFlow代码分支管理方法，以特性变更为单元，使用CI/CD 流水线完整的覆盖了从构建、测试到部署整个持续交付过程，过程中的每一个步骤和任务的信息都可以通过消息、邮件、钉钉机器人等告知和追溯，使研发、测试、运维、配管等角色能在线协同，异步工作。用云原生技术打破开发与运维的边界以Kubernetes、Serverless、Service Mesh、Cloud IDE为代表的多项云原生技术在过去一年让人印像深刻。这套开箱即用的开源软件，让中小公司快速的获得了以往互联网大厂才有的精项软件交付能力，比如复杂的流量治理能力，灰度发布能力，A/B测试能力，多环境管理能力，基础设施一键拉起，快速扩缩容能力等等。但在企业采纳新技术的同时，也面临着诸多挑战，比如开源软件复杂的搭建过程，黑屏化的交互设计，缺乏研发管理方法，缺乏企业权限管理能力等。阿里巴巴也在积极将CI/CD工具、测试环境管理方法、应用运维理念、DevOps协同方法论等与云原生技术融合贯通，为开发者提供开箱即用的新技术解决方案。使用“云效”轻松实现一站式在线研发协同工欲善其事必先利其器，云效可以提供从“需求 ->开发->测试->发布->运维->运营”端到端的在线协同服务和研发工具，让你轻松实现一站式研发协同。我们可以这样使用云效来完成一天的工作：晨会上团队基于精益看板进行需求、任务对齐，完成任务指派；开发同学根据特性开发，创建变更分支；通过线下或云端开发环境进行编程工作，然后提交代码；代码自动触发自动的代码扫描，并发送给指定的代码评审员进行评审；完成评审的代码自动触发集成发布流水线，自动化的完成构建，生成Docker镜像，分别在开发环境、集成环境及预发环境进行部署完成相应的验证工作；验证完之后处于待发布状态，触发上线审核流程，运维完成审核发布上线；过程中任何问题通过钉钉，遵循no news is good news的原则，及时反馈到指定负责人，做到准确反馈、即时响应，快速恢复。尽量避免垃圾短信式反馈，过多的噪音，反而会降低协作的效率。我们希望将云效多年积累的研发实战经验和先进的工具分享出来，让小企业，具备大智慧，快速开展在家研发软件工作。关于云效：云效，企业级一站式DevOps解决方案，源于阿里巴巴先进的管理理念和工程实践，致力于成为数字企业的研发效能引擎！云效提供从“需求 ->开发->测试->发布->运维->运营”端到端的在线协同服务和研发工具，通过人工智能、云原生技术的应用助力开发者提升研发效能，持续快速交付有效价值。

发表了文章 2020-02-05

技术阻击疫情，开发者在行动

阿里妹导读：对抗这次的新冠肺炎，我们每个人都责无旁贷。唯有众志成城，才能合力战胜疫情。阿里妹也梳理和汇总了一些能够帮助疫情治理和远程办公、学习的产品和工具，希望可以给予政府、企业、开发者、学生等群体一些帮助。面对疫情，我们始终在一起。今天，阿里妹就给大家介绍一下我们提供的产品和工具具体有哪些。疫情期间的生活类服务工具高德地图为了解决武汉医护人员出行难的问题，春节期间紧急开发上线了公益“医护专车”的功能，还为散在外地的湖北人提供了酒店指引；菜鸟开通了面向武汉地区的社会捐赠救援物资免费输送绿色通道；支付宝上线了公益爱心捐赠及疫情直播项目；阿里健康提供了在线问诊的小程序。除此之外，还有更多产品也在默默帮助和支持人们对抗疫情。利用技术手段助力疫情治理宜搭——免费向社会开放疫情相关应用宜搭是人人都能使用的0代码应用搭建平台。即便没有编码能力，只要通过宜搭的可视化拖拽方式，也能轻松搭建出自己想要的工具。传统模式下需要13天开发完成的应用，用宜搭2小时便可完成。疫情期间，利用宜搭可快速实现帮助社区、政府收集人员信息的功能。小程序云免费助力出入人口登记应用疫情期间，我们基于阿里云的小程序Serverless迅速开发出安全登记应用，可以满足这个特殊阶段出入人口出入管理的需求，帮助企事业单位应对春运返程高峰和人员登记管理。阿里云疫情防控智能服务平台——智能辟谣，健康咨询，回访通知疫情智能在线机器人：向群众提供权威官方疫情咨询及知识普及，权威压倒谣言！智能外呼机器人：提供重点人群排查、回访、通知等多场景外呼服务，省时省力。智能热线机器人：7*24小时不间断服务百姓，人工智能疫情咨询对话问答。智能问诊：初步诊断后可连接业务方人工入口，病症咨询不用再等！疫情小程序综合服务平台小程序云联合伙伴面向政府和企业推出疫情小程序综合服务平台，该平台提供的服务如下： Serverless 的模式，开发者专注于业务开发，快速开发部署小程序。享受小程序云推广期红利，免费使用。通过小程序云快速接入阿里经济体企业服务，生活服务等能力。阿里云AI算力支持阿里云宣布向全球公共科研机构免费开放一切AI算力。免费支持的研究范围包括但不仅限于：免费提供高性能计算、SCC超级计算集群和CPU集群；免费提供超算支持；免费提供通用平台支持；免费提供AI平台和云超算支持。天池实验室——病毒数据开放天池实验室计算资源免费开放，为开发者提供计算资源，并且持续更新新型冠状病毒疫情数据,为疫情贡献开发者的技术力量。工具助力，在家办公也能高效运转钉钉在家办公指南钉钉发布全套免费在家办公解决方案，教育、医疗、培训、新零售、金融、酒店等多行业解决方案一键获取。全新发布的「员工健康」服务可快速收集、实时统计组织成员健康情况，守护组织成员健康。钉钉视频会议也免费开放“302方视频会议”，支持302人同时在线开会。 Teambition——在线管理远程任务协同帮助企业在线管好工作事务，已经将企业版免费开放至 2020 年 5月 1 日，快速实现项目管理、任务协同、日程同步等功能。云效——让中小企业远程办公更加高效简单安全开箱即用，助力中小企业在家高效研发软件，全方位保障代码安全，实现快速交付。支持项目管理、任务协同、日程同步、文档协作、知识共享、数据统计。同时上线了远程协同知识库功能，可用于学习分享。蓝凌智能OA——随时了解工作进度深度集成钉钉，钉钉工作台企业个性化，随时随地移动办公，提供在线表单，疫情期间随时随地了解公司内人员状况，项目管理，远程工作必备，清楚了解工作进展。远程服务——在线办理公司/个体工商户注册每年的开年，都是公司注册的高峰期，一般公司需要线下注册，去工商局递交资料，或者委托注册的公司也需要跑腿。阿里云提供支持远程办理公司/个体工商户注册服务，还支持远程异地办理，无需跑腿。远程课堂，防疫学习两不误钉钉未来校园——学校停课不停学疫情之下，帮助师生做好疫情防控，守护健康，让师生安心在家上课，足不出户即可高效完成收集反馈。健康打卡：关注学生健康，培养健康意识和良好习惯；免费在线教学：停课不停学，不用担心教学进度。网校免费课程计划阿里云联合27家知名教育机构，推出线上免费课程，为全国中小学生带来了课堂同步网校课程、学科类和素质教育的课程，涉及自然拼读、英语语法、写作指导、少儿编程、家庭教育、培优等多个领域，也为社会人士带来了丰富的免费在线学习提升课，如会计考试、会计实操、建造师、消防师、医学、护理、金融、教师资格证、计算机专业、办公能力、语言培训等。高校师生“在家实践”计划阿里云为高校师生免费提供2.68亿小时算力，配套在线培训课程，赋闲宅家成长实践不停步。开发者精品课程免费学提供丰富的在线视频课程和专业的认证体系，涵盖云计算、大数据、人工智能、物联网、通用技术等领域。在疫情期间，云计算、大数据、云安全、中间件ACP认证辅导课仅0.01元，轻松备考ACP；人工智能实战、云上架构设计、DevOps实践、MongoDB等线上精品课限时全免费11个开发者技能路线（3000+视频，3000+在线自测试题）全免费学，助力开发者技能提升。社区21天学习计划学习不出门，进步不停歇！这个正月，阿里云开发者社区为大家准备了全套学习清单，涵盖精品电子书合集、文章、Codesample等内容用21天养成一个良好的学习习惯。共抗疫情，人人有责。除了上述提到的工具和课程外，还有源源不断的新方案与产品在抓紧开发中，阿里妹也会随时为大家更新进度。

发表了文章 2020-02-05

从淘汰边缘到阿里资深前端技术专家，他总结了 8 点

阿里妹导读：思维方式直接决定了一个人在工作上的效能和产出。经验是个人对过往项目的总结和处理方式优化。今天的文章来自于阿里工程师梓骞，从大学第一次接触动态网页到现在的资深前端技术专家，他分享了那些人生中的“大事”，让我们看到他是如何一步步转变思维方式，积累经验，升级打怪。大家好，我在阿里的花名叫梓骞，现在负责业务平台的体验技术部，主营业务是阿里业务中台体系的多端解决方案，同时还负责集团前端几个基础设施：Fusion、ARMS/Retcode前端监控、BizCharts数据可视化图表方案、Node镜像和部分Node中间件等。跟大家分享我过往的经历：如这个路线图中所呈现的，我其实并不是一开始就做前端，用现在的话说属于全栈。工作之后从事过.Net开发和C++，其中C++可以算是有5、6年的开发经验，只不过整个过程都伴随业务前端的开发，直到在2012年因为业务需求专职从事前端开发工作。在整个过程中，有非常多的经历，成长其实也是伴随整个过程一点一滴的积累，仔细回忆下，可以分成几个阶段。这几个阶段，也有一些对我发展起到决定性作用或者转折的事情。热情 2003年~2007年，我在大连读大学，加入了一个计算机社团，维护学校校园网以及另一个校园网站，虽然在之前就接触过HTML开发，做过一个个人主页(当时个人主页很流行，而且名字基本都叫××的家)，但在社团里是第一次接触到动态网页，才知道网站居然还有管理后台，之前以为是一个页面一个页面地复制出来的，也是至此就迷上web开发，从校园网站的内容编辑做起，再慢慢自学ASP开发，大一结束后已经可以独立负责一个站点的技术开发工作。机缘巧合，大二刚开学的时候学校的物理实验室准备做一个选课系统，在学长的鼓励下我去接了这个项目开发，用了几周的时间完完全全由一个人开发完毕，不久就投入到学校运营，还记得是每周二中午实验室会开放下一周的实验课程，因为资源有限，大家一起去抢课程，当时用ASP+Access (是的，确实是Access当数据库) 在一台服务器上撑住了过千的并发，虽然慢但服务没垮，也没出现超卖的问题。现在想来，这不就是秒杀活动吗。这个项目做得还算成功，当时也通过这个项目认识了非常多的老师，这也直接促使后面承接了更多更大的项目，最重要的项目是交通部的一个内容发布系统，也是一个人花了两个月的时间完成，当时在社团的办公室里经常一个人写代码写一通宵，那个时候年轻，也乐此不疲，也没觉得累。大学四年业余生活也是在不断的开发和各种实际项目中度的。大学毕业的时候粗略统计了一下，各种项目加一起代码量大概在10W行左右。也是由于这些实际项目经验，在大四的时候找工作，面试官问的很多问题基本都是实际项目中遇到过的，所以也很顺利拿到了国内一家著名互联网公司的校招offer，也是我第一家服务的公司。打破常规，积极沟通毕业后直接去了第一家公司，在这家公司里，大家叫我的昵称「泡泡」。可能因为做了太多OA类系统的原因，也直接被分配到企业IT部，相当于阿里现在的企业智能事业部，对于毕业生，主要工作也就是开发各种审批流程。随着开发的流程越来越多逐渐发现一些规律，有些审批流的代码几乎一致，只需要修改部分类名和关键信息即可。可能过去在大学开发许多项目的经历，有一个习惯一直保持到现在，那就是最受不了来一个页面做一个页面，如果出现重复性的劳动，我一定会想办法用工具、改进架构、自动化等手段让机器去做。所以当发现许多代码是重复的时候，就特别想改变重复性的coding工作，最开始是批量替换，后来找了个代码自动生成的工具，随着对所负责的系统架构越来越熟悉，逐渐改项目架构，每天下了也是在研究项目架构并自己写demo去验证，到年底总算可以实现对相似流程简单配置一下就可完成。正当自己对结果很开心的时候，认为自己是打破常规，不仅能完成工作也能主动去改变现有研发模式，但人生中第一个考核就是「待改进」，相当于阿里的3.25，当时百思不得其解，跟主管聊过之后才发现自己存在几个严重的问题，比如目标只是完成工作，不关心业务和用户，也不关心用户体验，甚至一个表达用了多种交互形式；再比如，不关心业务质量，甚至bug直接在线修改，也出现过故障；最后，最严重的问题，遇到问题抱怨过多，比如抱怨自己依赖的组件有bug，抱怨基础设施不稳定等等，抱怨为什么方案总在变，一个词概括就是「学生思维」，比较自我总是站在自己的角度去看问题。这次绩效，现在看也一直认为是一个转折点，自那以后基本停止抱怨，能够主动打开心扉去接受现状，去跟其他人沟通把自己的想法跟其他交流，主动去提出自己的改进方案，紧接着的一次考核，居然是A，相当于3.5+或者3.75-。现在想来很庆幸当时遇到一位负责的主管，如果是说保护毕业生在绩效上放过一马，或许再过半年当思维方式定型就改不过来了。「泡泡出品，必属精品」一年半以后自己转岗到业务部门，主要是C++，所以当时也是彻底从.Net技术栈切换到C++。依然保持打破常规、积极沟通，在一线繁忙的业务中完成一个又一个的项目，在业务部门的一个优势就是，可以告诉亲朋好友：“这个功能是我做的”，所以也特别关注业务，关注用户体验，而且当时公司的研发流程是：在提交测试前需要转体验，就是请产品经理体验一下研发人员开发的项目是否是自己想要的，功能是否有遗漏，体验好不好之类。直到有一天，发生了一件我认为对我影响深远的事情。有一次照例转体验，不一会收到产品经理的回复，大概意思是，体验非常棒，泡泡做的简直可以打上「泡泡出品」这个品牌了。这句话，可能本是产品经理一句恭维的话，虽然产品经理经常恭维程序员，但说者无心听者有意，这不就是我一直所期望的吗，经我手的项目，就是质量过硬体验好，泡泡这个名字就是品牌。也自那以后，我的对自己的要求就是提交测试后0 bug，用户体验就是一级棒，用户用起来感受就是“这就是我想要的”。为此，自己模拟各种使用环境自测每一行代码和异常处理，处理好每一个交互细节，比如对于动画延迟，不断去测试延迟100毫秒、200毫秒、300毫秒、400毫秒等参数，最后发现300毫秒是最自然的效果，于是把全站的延迟都调整到300毫秒，已达到全站所有同一个交互表达有统一的表现。持续的投入总会有结果，后来部门期望提升研发流程的耗时，节省测试时间，试行对于简单功能或者开发质量高的同学可以免测发布，而我就是第一批被批准为免测发布的人，我开发的程序可以直接发布上线不需要测试，因为确实在数据中显示，我已经有很长时间没有被发现bug。当然，在这背后也付出不少，除了有心去要求自己，技能也需要一点一滴去积累，也没啥捷径，计算机是一门实践的科学，就是多写代码。在我14年离开这家公司的时候，我的代码贡献量是排到小组前列，离开两年之后还有人告诉我，我的名字还排在前列。个人经验到组织能力和产品能力个人职业生涯另外一个转折点是在2012年，在之前都是C++是前端同时做，到了2012，随着移动设备的兴起，视频的播放从传统的flash过渡到HTML5，并且越来越重视播放体验和变现能力，所以业务的重心也开始向播放体验、广告等方面倾斜，于是我开始专职做前端，主要是从事以HTML5为核心的移动端视频播放和广告播放。 HTML5播放并不是简单的使用video标签就可以解决的，这里面涉及到播放兼容性、播放质量跟踪、清晰度切换、防盗链、CDN、贴片广告、播放后推荐等因素，远不是各种教程里写的简单设置个video标签和src就可以解决的，所以也在实际项目中攻克了很多技术细节。然而视频是互联网最基础的需求之一，越来越多的业务也需要嵌入视频，也需要去适配各种移动设备，前来咨询的人越来越多，我发现我有一半的时间都在帮各种业务解决播放器调用的问题，于是开始写了一个移动播放的白皮书，说明如何实现移动端播放。虽然文档能解决部分咨询的问题，但依然会有各种新的问题来咨询，后来想想，为什么我不把这些调用过程封装成一个JSSDK呢，把想法跟主管沟通后得到大力支持，就这样每天下班回家利用业余时间花了近1个月开发出了这个SDK，只需要传入简单几个参数就可以自动适配平台渲染出播放器，最初被公司新闻App引用，后来又被公司多个具有海量访问的App引用，直到我离职，这个SDK成为当时前端组最核心的工作之一，每天的调用量超过亿次。时隔多年再回首这段经历，才知道无形中做了一件我们称之为“个人经验到产品能力”的事情，就是把自己在长期业务中积累的专家经验，以产品化的思路变成一个技术产品，让不具备对应经验的人也能很低门槛的使用现成的能力，达到经验的可复制，服务更多的业务。 2014年来到当时的阿里巴巴共享业务事业部，也就是我现在所属的业务平台事业部的前身，承载了阿里经济体电商核心，构建阿里巴巴商业操作系统，虽然现在支撑了阿里经济体众多的电商业务，但在当时接手了非常多的淘系业务，而且许多业务都是PC端，大量的页面依赖的Ajax接口返回结果才能正确渲染，然而我们并不知道接口的稳定性到底如何。做前端最尴尬的事情就在于，所有的错误都表现在前端，直观的感受就是前端不给力，进而影响到业务和用户。所以急需对接口稳定性做监测，过去个人是有这方面的经验，但寻找了阿里现存的体系都无法满足诉求，于是主动联合中间件团队发起了早期第一版的retcode监控平台(也就是现在阿里云前端监控产品ARMS的前身），同时配合几个新业务的上线，效果很明显，直接发现了多起线上问题，业务方也很认可，直接帮我们推荐给了其他团队，所以也逐渐开始有其他团队的同学介入。所以对于Retcode，当时我们也面临一个选择，就是到底只小精力投入满足自己需求即可，还是开放出来给其他业务团队使用，因为我们当时根本就没有这么多人力和服务器预算，而且量变到质变，所要处理的数据量越来越大的时候，要投入的技术方案也会发生根本变化，对系统自身的稳定性要求也更高。后来的事情大家都知道了，我们选择了开放出来让大家都接入。我们考虑的原因是：有业务想接入，说明这个需求是真实存在的，Retcode在用户端根据真实体验的数据监测方式大家也是认可的；既然需求存在，即使不开放出来，其他业务也会自己做，那么算上重复投入的人力和机器成本，反而更浪费，而我们开放出来以后，形成规模效应成本反而更容易控制。开放出来以后，其实以开始路也并不顺，开始服务不稳定，容量经常不够，数据不准确，丢数据，还需要解决权限控制等等，以及各个业务也会提出很多需求，功能也需要不断完善，整个过程也是非常的煎熬，当时给团队要求也是坚持一年，一定会有好的结果。一年之后，我们不仅打磨出了一款好的产品，还历练出多位在前端APM领域的人才，在全国诸多技术分享大会上也见到了他们的身影。到了2016年，我们的业务形态是大量的ToB、ToE系统的开发，要适配多个BU的设计风格，技术体系上也在React趋势上行的阶段，急需一套打通设计到前端实现的UI域研发体系。经过一系列的调研和合作沟通，跟ICBU前端团队一起拍了合作的意向，并跟当时的国际UED的设计师一起孵化了Fusion体系。整个过程其实也是将多位设计师长期在项目中的设计分解经验和多位前端技术抽象的经验，通过技术产品化，把多位专家的优秀经验，从组织能力升级成产品能力。Fusion的能力提升，也是随着Fusion支持的业务场景越来越多，逐步将上层业务的需求和用法沉淀下来的，比如一开始是不具备国际化能力的，配置平台和文档也是全中文，这是在支持lazada业务之后才开始具备国际化的能力；一开始也没有信息无障碍能力，也是因为适配国际业务的法务要求才沉淀下来，一开始对这块也没太多经验，部分同学在业务中具备了个人经验之后，再将经验产品化。主动补位，不给自己设限因为过去的项目经历，本身自己算是全栈经历，所以一直认为前端不是因为我们用JavaScript，而是因为我们站在业务最前端，解决业务端的问题，所以我们是前端。这个思想一直作为我从事前端岗位做决策的依据之一，只要认为是跟端相关，影响到用户，那就是我们的职责，或者是我们要去推动解决的。越是开创新战场的打仗团队，其实职责越不清晰。印象最深的就是在lazada Voyager项目中，因为是开辟一个新的战场，时间紧任务重，许多人也是从其他团队抽调临时组建起来的，其实有挺多职责不确定的事情，没有说这是你的职责也没说这不是。遇到这类事情，判断的唯一依据就是，这是不是通过端去影响用户的，如果是，那就是自己的职责，那么剩下的就是兵来将挡水来土掩，排除万难解决问题就好，比如项目中出现过客户端人力不够的情况，那么考虑到业务进度，主动补位可以先用Weex或者H5先顶上，再比如埋点也是一个灰色地带，产品经理也很忙，那就直接主动拉着产品经理一起去梳理。表面看来，多做了一些事情短期没有任何的回报，甚至还额外加了很多班，但利他是最大的占便宜，在项目发布后整个团队受到的评价都是很正向。关于现在和未来，当前主要工作是： •阿里电商操作系统前端解决方案； •设计中台体系建设 —— 服务阿里几千名设计师和几千名前端的设计提效、促进协同的设计体系； •承担在集团部分Node中间件、Node镜像等开发维护工作； •前端大学 —— 阿里经济体前端委员会人才发展方向；其实，这几块工作里，只有第一项是我的kPI目标，而其他的比如第二个设计中台，我个人觉得这是建设商业操作系统UI域解决方案必须要强合作的事情，也由于自己过往在国际UED，对设计师的痛点也相对了解，自己也相信解决几千名设计师和几千名前端的协同合作效率，改变UI域的研发模式，一定会给集团甚至业界带来效率的飞跃，这也是自己长期所相信的相信，既然自己也觉得有价值，跟自己的主要KPI也有关联，那就去做。而其余的事情，其实基本不在自己的KPI里，但也是那句「Not Me，Who」，自己觉得有价值，这个事情也是需要去做的，那就去做好了。也没有给自己设置限制。总结 •兴趣是最好的老师，做一件事情首先是自己要有热情，如果只是当成一份工作，内心就很难让你全情投入； •认真做事能把事情做完，用心做事能把事情做好； •利他是最大的占便宜； •前端不是因为我们用JavaScript，而是因为我们站在业务最前端，解决业务端的问题，所以我们是前端； •计算机是一门实践的科学，多动手是王道，知其然知其所以然； •协同是「两个人」的事，但协同成功是「一个人」的事，想要最终结果是成功，必须放下界限，向对方多走一步。 •除了自己，没人能给你设限。 •做自己认为对的事情，并坚持下来。以上，是我从业前端这个岗位过往的经历和感悟，感谢阅读，共勉。

发表了文章 2020-02-03

10万人的大场馆如何“画座位”？

阿里妹导读：疫情之下，宅在家里就是对自己的保护。我们相信大家能够共度难关，早日迎来与亲友们现场看电影、看球赛的那天。今天，我们就来讲讲10万人的大场馆如何“画座位”？怀念过去的欢聚，期待下一次的再见。说到“画座位”，最常见的场景莫过于影院的在线选座购票。这个场景下的需求，对开发者来说并不难，但你知道10万座位的大场馆该如何画吗？座位不固定，场景复杂等一系列挑战该如何应对？接下来，阿里文娱技术专家莫那和阿里文娱高级工程师土嚎，为你揭秘。一、背景 1、网络售票，需要画座：购票所见即所得大麦主要业务是票务，包括演唱会、体育赛事、音乐节等，品类繁多。卖票就要画场馆、画座位，大家都在网上买过电影票，这不难理解。虽然可以拿电影售票做类比，但底层难度差异很大。没有10W座的电影院，却有10W座的演唱会，而且演出/体育类场馆变化多，挑战相当大。 2、大麦绘座演进：从示意图到实际场景图大麦以前的绘座系统，是安装版的程序，画座位只能一个看台一个看台地画，看台之间完全无关联，画出来几乎每个看台都长一个模样，座位只有相对位置的示意图，没有角度、距离，更谈不上精确定位。图1：老版绘座页面（已淘汰）大麦网从2017年，开始设计新版绘座系统。这里没有修补，没有重构，新版绘座完全重来，连技术栈也由.NET换成了Java，由C/S换成了B/S。新绘座以SVG矢量图为核心，通过Canvas进行绘制，在演进的过程中攻克了大量的性能卡点和技术难点，最终打造成型，堪以重任。图2：新绘座页面二、新绘座：Flash走了，Canvas来了 1、Flash已死，来到路口，别无选择新绘座已诞生2年多，现在回首，这条路似乎早已注定。老版绘座和选座是基于Flash的，悲剧的是，Adobe宣称Flash 2020年后，将不再维护，相关技术会在2020年底全部退役，大麦的绘座和选座系统，都被迫转型。 Flash只是原因之一，看过竞争对手的产品，会发现SVG是条不错的道路，即使没有Flash这一出，大麦网也会朝这个方向迈进。 2、技术选型 1）任何过度使用DOM的应用，都不会快。经过技术调研，发现国外一些场馆座位绘制，选用的是SVG方案，每个座位都是一个独立的SVG元素。但如果直接把SVG搬到浏览器，无法支持几万座位的场馆，因为浏览器无法支持过多的DOM数量，并且，一旦DOM数量太多，操作一定是低效的，“任何过度使用DOM的应用，都不会太快”。于是，技术同学想到了Canvas，Canvas是浏览器上的一个画布，无论上面绘制多少元素，对于浏览器而言，都只是一个DOM元素。对于不了解Canvas的同学，我们可以简单做个说明，Canvas在浏览器上，就是下面一个标签：在Canvas上绘图，就是使用JS获取Canvas对象，使用封装好的方法进行绘制。Canvas画布上的图形变化，完全通过擦除+重绘的方式展现。那么新绘座的目标就变得很明确了，我们就是要在Canvas上绘制出想要的场馆座位图，然后以SVG的格式把图形保存起来，用以选座、售票。 2）Canvas也不是银弹：单个Canvas的大小是有限制的，超限之后也会卡顿。选型初期，技术同学使用Canvas+SVG做了个Demo，模拟了10W座位的渲染，并实现了拖拽、缩放。但真正作为画座组件开发的时候，发现座位达到2W就出现了卡顿，因为Canvas的宽高达到一定的数值，就会出现卡顿。于是，沿着化整为零的思路，技术同学将整个画布，分成了多份Canvas，形成了一个Canvas矩阵，通过对每个Canvas的操作，完美解决了单个Canvas过大引起卡顿的问题。关于Canvas绘图组件，大家可以在网上搜到很多资料，这里不再赘述。 3、新版绘座上线初期：青苹果刚上线的新版绘座，就像个青涩的苹果，虽然漂亮，却没那么好吃。最突出的问题有2个：第1个是变形难用，由于算法比较初级，座位矩阵变形很难满足用户需求；第2个是接口速度慢，打开一个1W座的场馆，好几分钟，超过5W，直接崩溃，根本无法支持。为什么理想很丰满，结果却差强人意呢？根源在于第一版只重功能，忽略了算法效率。与服务端的接口调用，都是整个场馆级别的，几万座位数据，加上关联的看台、票、以及状态等，一个硕大的数据包在前后端丢来丢去，系统不堪重负，用户受尽折磨。 4、艰苦改进之旅新绘座上线后，立刻启动了改进优化工程，主要攻克的难关有三点：1. 页面响应时间；2. 座位自由组合变形；3. 打印顺序计算。 1）交互+接口优化，进入秒开时代首先要解决接口慢的问题，解决效率低的一大法宝：化整为零。从一次load一个场馆的数据，改成一次load几个看台的数据。服务端数据随着前端视口（页面可视范围）的变化，逐渐加载，类似地图常用的“拉框查询”。前端交互也从全加载，改为按视口取数据。仅此一项优化，几万座大场馆的系统响应速度，立刻由几分钟，降到了1~2s，小场馆更是瞬时打开，系统好用了不少。这里面最重要的一个技术点，就是视口计算，原理如下：前端首先获取到屏幕视口在Canvas画布上的坐标，然后和看台的外接矩形进行碰撞检测，两个矩形一旦相交，就说明该看台已暴露在视口之内，于是就加载该看台的数据。从接口优化开始，新绘座逐渐走向成熟。图3：按视口加载原理图2）合并座位矩阵，自由变形座位自由变形包括倾斜、错位、排距、座距、旋转、弧度等多种操作。除了弧度变形，其它基本上是一些数学上的坐标计算，我们不赘述，这里重点说一下弧度变形。新弧度变形，运用贝塞尔二阶曲线原理，根据用户的数据输入，计算出相应的贝塞尔曲线，再把每排座位，均匀排列到曲线上。下面是贝塞尔二阶公式：图4：贝塞尔曲线示意图注释：P0、P2为一排座位的左右端点（一排的第一个座位和最后一个座位）。看似套公式就可以搞定，非常简单的样子。但是这里有一个难点：从图中可以看出，t为比例值，处在线段P0P2不同的比例，所在的弧度位置也是不一样的。如果所有的座位都在P0P2线段上，很好算，但是如果座位之前就是一条弧线呢？中间所有的座位都不在P0P2线段上，要怎么算出中间座位的每个比例？我们通过弧线上的每个座位，做一条P0P2线段的垂线，垂线与线段P0P2的交点，就是这些座位所在这一排的原始位置，计算出这些原始位置的坐标，根据这些原始位置，就可以算出中间所有座位的比例了。这样，弧度变形问题就通过贝塞尔二阶曲线完美解决。图5：弧形座位矩阵贝塞尔曲线变形原理图图6：弧度变形实际操作图7：座位自由组合，随意变形 3）打印顺序计算 “打印顺序”是个什么鬼？这得从大麦的业务特点说起，主办有时候会批量出票并将票配发给相关人群，有时整个看台一起打印。在配票的时候，需要按照座位的物理位置关系排序，避免座位没挨着、“2个情侣”被“拆散”的情况发生。举个例子：下图中，主办期望打印票的顺序是“5-3-1-2-4-6”，而不是“1-2-3-4-5-6”，这样他们就可以按打印顺序配票，而不用担心两张票不挨着。那么，在绘座过程中，我们就要计算出座位的顺序，看似简单，实现起来有难度很大，原因只有一个，场馆形状各异，座位排列多样。图:8：北京奥体中心的某个看台如果说，上图还能按照座位Y坐标对比进行排序，那么下面的几个情形，就不那么好处理了：图9：各种特殊的座位排列场景打印问题，我们通过场景汇总，对场馆进行分区，最终找到了排序的规律，得以解决。打印问题技术方案原理：第1步：将场馆分成8个象限，象限内的座位，已标识出该如何排序（标识出了应该对比X坐标还是Y坐标来进行排序）；第2步：每一组座位矩阵，取出首排，求首尾座位连线的斜率，然后根据斜率将座位矩阵划分到对应象限；第3步：按照对应象限的排序标识，对比座位的X坐标（或Y坐标），进行座位排序。图10：座位排序原理图 4）小彩蛋之“沙发、角度” 效率、变形和打印3个主要问题根解之后，随之出现了大量的产品优化需求，开始着眼于细微之处，小沙发和座位角度就是2个典型的功能。这两个功能虽然难度不大，但却在体验上有了一大步的提升。图11：圆点、沙发效果对比 5）小彩蛋之“撤回” 经过不断优化和添砖加瓦，大麦的绘座系统，越来越像一款专业的绘图工具。好的绘图工具一定需要“前进&撤回”功能。新绘座系统的撤回功能实现原理：设计一个“历史数据”数组，数组里的每个元素，记录一个操作步骤对应的被编辑座位数据以及座位位置信息，回退时，找到对应操作步骤的数组元素，重绘座位位置，这样就回退了整个操作。因为无论座位相对位置如何变形，本质上，其实都是坐标数据的改变，通过记录和重绘历史坐标信息，就达到了撤回操作的目的。三、在正确的路上继续前行到目前为止，新绘座系统已能够承接国内外任何大型场馆的绘座工程，各种细节的优化也日臻完善，效率大幅提升。但产品和技术同学的努力，并没有终止，而是在正确的道路上，继续前行。以下简单列举几个很实用的功能，供大家参考： 1）区域编辑：自由绘制矩形、圆形、多边形等各种形状，并自由变形； 2）一键自动变形：全选看台内的座位，点击“一键变形按钮”，座位瞬间适应看台形状，自动排列。图12：一键变形效果图 3）座位复制、镜像：区用户可以自由复制选中座位，并且支持镜像、翻转等多种复制模式，排号、座位号根据设置自动处理； 4）一键朝向舞台：用户选中一个看台的数据，点击“一键朝向舞台”，系统会自动计算舞台方向和座位角度，瞬间将整个看台座位“摆正”。

发表了文章 2020-02-01

阿里云向全球公共科研机构免费开放一切AI算力

新型冠状病毒感染的肺炎疫情牵动着每一个人的心。为了帮助加速新药和疫苗研发，今天我们做了一个决定：向全球公共科研机构免费开放一切AI算力疫情期间，任何针对本次新型冠状病毒分析、疫苗新药研发的公共科研机构、学校、医院，都可以通过邮件联系阿里云疫情公益小组。我们将在第一时间与相关机构取得联系。联系邮箱wanqing.hwq@alibaba-inc.com 目前，中国疾控中心已成功分离病毒，疫苗研发和药物筛选仍在争分夺秒地进行。新药和疫苗研发期间，需要进行大量的数据分析、大规模文献筛选和科学超算工作。阿里云可以提供强大的AI算力，支持病毒基因测序、新药研发、蛋白筛选等工作，帮助科研机构缩短研发周期。此前，阿里云就曾与基因公司联合打破世界纪录：仅用15分钟，即可完成高精度的个人全基因组测序分析。而在过去，科学界普遍需要120个小时才能完成类似流程。图为全球健康药物研发中心GHDDI 全球健康药物研发中心GHDDI正与阿里云合作开发人工智能药物研发和大数据平台，针对SARS/MERS等冠状病毒的历史药物研发进行数据挖掘与集成，开放相关临床前和临床数据资源，计算靶点和药物分子性质，并跟进新型冠状病毒最新科研动态，实时向科学界和公众公布，为新型冠状病毒科学研究提供重要数据支撑。图为GHDDI针对此次新型冠状病毒蛋白质序列实现部分靶点的同源建模工作同时，阿里云将与合作机构向全球科学共同体免费开放相关药物研发资源，共同加速针对新型冠状病毒的药物研发。马云公益基金会也捐赠一亿元人民币，用于支持加快推进新型冠状病毒的疫苗研发。免费支持的研究范围包括但不仅限于： 1、用分子动力学HPC应用算病毒、蛋白质、药物结构，靶点作用模拟和设计药物筛选的实验，以及使用QD量子动力学等做药物研究——免费提供阿里云高性能计算、SCC超级计算集群和CPU集群；2、对病毒植株和染病者的染病DNA提取，进行基因组计算、基因组学计算——免费提供阿里云超算支持；3、科研机构对全球大规模文献分析和筛选——免费提供阿里云通用平台支持；4、在MD，MM，QD基础上做虚拟筛选——免费提供阿里云AI平台和云超算支持。共抗疫情，我们能赢！本文作者：阿里技术本文来自阿里云云栖号合作伙伴“阿里技术”，了解相关信息可以关注“阿里技术”

发表了文章 2020-01-23

云栖号2019云计算盘点-【教育&科研上云篇】

新年到了，在这里小编祝大家新年快乐，鼠年大吉！回顾2019，2019年教育产业大事频发，行业政策风云变幻。纵观今年的教育事件，既有A股首家破千亿市值教育公司诞生，还有跟谁学A轮融资即登陆美股的故事。2019年，教育行业很热闹；资本寒冬、韦博教育崩盘，也为2019年教育行业蒙上了一层阴霾。小编在此梳理了2019年影响教育行业事件国家大力支持职业教育发展社会的高速发展和产业结构的升级，对人才提出更高的要求，发展职业教育成为国家的重要战略。2月，国务院发布《国家职业教育改革实施方案》。《方案》把职业教育放到了教育改革创新和经济社会发展中更加突出的位置，鼓励社会兴办职业教育。一时间，借着政策东风，职业教育似乎即将迎来全面爆发。 5月，国务院办公厅再次印发《职业技能提升行动方案（2019－2021年）》，并提出更为具体目标任务：2019年至2021年，三年共开展各类补贴性职业技能培训5000万人次以上，其中2019年培训1500万人次以上...... 小区配套幼儿园不得办成营利性幼儿园2019年，国家明确了幼儿园普惠的基调：2020年普惠性幼儿园覆盖率（公办园和普惠性民办园在园幼儿占比）达到80%，民办园一律不准单独或作为一部分资产打包上市，上市公司不得通过股票市场融资投资营利性幼儿园。今年1月22日，国务院办公厅印发《国务院办公厅关于开展城镇小区配套幼儿园治理工作的通知》，再次推进普惠园的建设。《通知》提出，要构建以普惠性资源为主体的学前教育公共服务体系，小区配套幼儿园应按照规定及时移交当地教育行政部门，由教育行政部门办成公办园或委托办成普惠性民办园，不得办成营利性幼儿园。普惠园的未来在哪？保证普惠的前提下，将幼儿园资产通过连接外部资源的方式盘活，同时也可以通过差异化的服务满足多样化的教育需求，以家长为核心提供服务。这可能是一条可以走的路。跟谁学上市6月6日，跟谁学以第一家规模盈利在线教育公司的姿态正式登陆美股市场，同是今年上市的新东方在线、网易有道皆流血上市。跟谁学获得大量的关注同时，也赢得了赞美。与那些长期深陷亏损魔咒的在线教育企业相比，跟谁学的业绩极为亮眼，尤其是在2018年转亏为盈，在该领域获客成本不断高涨的情况下，跟谁学实现了用户的极速增长和盈利。自上市后，跟谁学股价一路上涨，成为今年绝对的赢家。韦博教育崩盘国庆假期还没结束，一则重磅消息登上了各大教育媒体的头条，成立二十一年之久的老牌英语培训机构韦博英语突然陷入关门风波。关门事件引发的多米诺骨牌效应，导致韦博教育全国的门店接连停业。短时间，韦博教育轰然倒塌。自成立以来，韦博教育一直深耕英语教育，业务覆盖线上、线下、成人、少儿、游学等各个领域，韦博英语在全国60多个城市150多家中心，学员数近百万名。据报道，韦博教育此次崩盘，是因为经营不善导致资金链断裂。但纵观其他线下成人英语机构，现状也并不乐观：华尔街英语（中国）因为业绩不理想，两次易主，英孚教育被传正着手出售其部分中国业务。那么教育行业怎么和云计算领域结合，引领产业变革呢。小编总结了教育行业上云三部曲，带你了解教育行业如何上云。教育行业上云三部曲来看看教育行业的同行是怎么做的【掌通家园】“掌通家园”上云百万家长第一时间了解幼儿园的孩子状况掌通家园是做互联网教育管理平台，每次开学会给系统性能和稳定性带来冲击，使用硬件+软件+服务+移动互联网+云技术的解决方案应对开学业务高峰。【全美在线】全美在线监考云上云案例阿里云智能企业服务团队在监考云平稳上线后进行护航保障，确保系统平稳运行，连续圆满支撑了多场大型考试，保障了百万人的监考任务圆满完成！更多案例，请访问云栖号-案例库怎么上云，不同阶段的最佳实践带你一步步上云！初级阶段：在线教育全球部署网络规划最佳实践目前国内在线教育行业主流已经演化到移动互联网时代，部分业务已经步入大数据时代。在线教育的教师大部分和学员不在相同区域，设置不在同一个国家。例如场景的英语类在线教育，教师在北美，学员分布在国内各地区。如何保障跨地区、甚至跨国家的在线教育网络质量，是非常核心的一个技术问题。互联网业务全球化互通组网最佳实践本方案适用从事全球化业务的客户，希望借助全球互通的网络，实现多地域的互通。同时在全球互联的网络下，搭建应用多地部署。如果业务中涉及到高速通道，提供高速通道迁移云企业网的操作演练；涉及到跨账号多VPC下的数据迁移和同步，本方案提供详细的操作步骤，帮助客户快速完成演练。发展阶段：同地域跨可用区容灾最佳实践使用阿里云在少量增加成本的情况下，在迁移上云阶段直接利用云上资源，实现业务的同地域跨可用区容灾能力。容器跨可用区高可用最佳实践使用Redis，RDS和NAS以及阿里云容器服务搭建一个跨可用区高可用的系统，实现跨可用区高可用。创新阶段：跨境直播最佳实践解决跨境直播的两个场景，场景一：主播在国内，观众在海外。场景二：主播在海外，观众在国内。电商网站智能推荐最佳实践基于阿里巴巴领先的大数据和人工智能技术，结合在电商行业的多年积累为开发者提供个性化推荐服务，提升商品购买率和转化率。更多实践，请访问云栖号-最佳实践库涉及到云产品不了解？小编带你云产品快速入门！云服务器ECS云服务器 ECS（Elastic Compute Service）是一种弹性可伸缩的计算服务，助您降低 IT 成本，提升运维效率，使您更专注于核心业务创新。专业的售前技术支持，协助您选择最合适配置方案。云数据库RDS MySQL 版MySQL 是全球最受欢迎的开源数据库之一，作为开源软件组合 LAMP（Linux + Apache + MySQL + Perl/PHP/Python）中的重要一环，广泛应用于各类应用场景。对象存储 OSS海量、安全、低成本、高可靠的云存储服务，提供99.9999999999%的数据可靠性。使用RESTful API 可以在互联网任何位置存储和访问，容量和处理能力弹性扩展，多种存储类型供选择全面优化存储成本。教育类识别适合教育行业人员在试题抄录场景下使用，对比人力录入，能有效提升抄录效率。更多入门，请访问云栖号-入门库 <完结> 还想了解更多不同行业，不同产品的云资讯，云产品入门，上云案例和实践，请访问云栖号

发表了文章 2020-01-23

云栖号2019云计算盘点-【文化产业上云篇】

我们欣喜地看到，这一年文化和旅游产业的发展依然带给我们无限的想象空间。无论是文化和旅游与科技的深度融合，还是文化和旅游与金融的创新合作，亦或是在产业结构调整中文化和旅游产业所发挥的坚实作用，文化产业正在为成为国民经济支柱产业而努力着。回首今年，文化产业领域内发生了很多现象级事件，小编根据其网络热度和社会影响，梳理出大事件。 8k+5G的时代 2019年6月27日，在“2019世界移动大会”举行期间，中央广播电视总台实现了我国首次8K超高清内容的5G远程传输测试。本次传输测试，实现了最高在320兆每秒速率下的8K视频传输。2019年11月，国际电信联盟批准了“数字化艺术品显示系统的应用场景、框架和元数据”标准（标准号H.629.1）。这是继手机（移动终端）动漫国际标准（标准号T.621）后，我国自主原创、主导制定的又一数字文化产业标准成为国际标准。8k+5G的时代，新的终端硬件和内容平台已经“在路上”了。国产动漫《哪吒之魔童降世》 12月28日，根据猫眼数据，国产动漫《哪吒之魔童降世》（以下简称“哪吒”）补录之后的票房已经突破50亿元，为2019年度票房冠军，成为《战狼》后第二部票房突破50亿元的电影。10月份，哪吒通过奥斯卡最佳动画初选，代表中国大陆竞争第92届奥斯卡“最佳国际电影奖”。哪吒“火爆”的背后是国漫正在崛起。同时哪吒成功背后也有云的力量！来看看哪吒制作公司大千阳光上云的故事。马首回归 2019年11月13日，圆明园马首铜像捐赠仪式在国家博物馆举行。随后，马首划拨北京市圆明园管理处收藏，回归原属地，为其百年回归之路画上圆满句号，成为第一尊回到圆明园原址的十二生肖兽首。1860年，十二生肖兽首就开始流离之路，经多次转手、拍卖、捐赠、收藏，迄今有七尊归国，另有龙、蛇、羊、鸡、狗五尊兽首仍流落在外。此次马首“归来”，再次激起海外流失文物归国的全民关注热潮。越来越多海外流失文物期待回家。据统计，从1949年至今，我国通过执法合作、司法诉讼、协商捐赠、抢救征集等方式，促成300余批次、15万余件流失海外中国文物的回归。越来越多的海外文物“回家” 回顾完行业事件，来看看我们文化界的同行上云的故事【目睹科技】目睹科技上云，全面护航“云栖大会”直播目睹平台，国内领先的企业级直播服务平台，致力为万千企业提供直播生产。直播+正成为行业互联网化的时代趋势，目睹通过直播帮助企业传递品牌价值。目睹直播上云以来，阿里云帮助我们梳理了高并发情况下的直播架构，保障了我们的众多大型直播活动，协助了我们出海战略布局。阿里云用稳定的质量和用心的服务支撑了我们飞速的发展。目睹直播今后也将和阿里云一起，用心构建稳定的企业服务！【晨之科】晨之科专注于二次元产业，引领行业创新用户经常面临游戏发行、上线、开服等短期高峰的业务场景，针对游戏行业解决方案特殊，同时针对用户游戏推广初期的业务集中并发场景。阿里云为客户在开服前即进行模块级别的压测，在业务条件允许的情况下，进行全链路压测，以最大限度的消除单点问题和普通测试中无法覆盖的场景，增强了客户游戏的稳定性；在开服重要时刻，为客户建立完善的资源监控、报警体系，做到及时发现，及时排查，及时缓解，保障客户游戏业务的稳定运行。更多案例，请访问云栖号-案例库怎么上云，最佳实践指导你一步步上云！一步步教你如何利用混合云实现云端影视渲染如何搭建一个完整的混合云渲染服务架构？本地与云端的网络以SSL-VPN方式进行互联，可以解决使用批量计算服务管理渲染计算集群并自动加入Deadline渲染计算资源池的问题。更多实践，请访问云栖号-最佳实践库涉及到云产品不了解？接下来小编带你云产品快速入门！初识云数据库Redis，轻松上云云数据库 Redis 版提供内存加硬盘的混合存储方式，支持多种部署方式以满足不同的场景。由浅入深，带您玩转云数据库 Redis 版！EDAS助力全栈式解决方案，助力你的应用轻松上云微服务解决方案,应用托管解决方案,容器托管解决方案3大解决方案，带您了解企业级分布式应用服务 EDAS，快来体验完备的解决方案服务吧！六大场景迁移到RDS云数据库方案攻略RDS提供了针对本地数据库、ECS自建库等6大场景到云数据库的迁移方案，可满足不同上云或迁云的业务需求，在不影响业务的情况下将数据库迁移到RDS。更多入门，请访问云栖号-新手入门还有更多的精彩直播带你回顾更多文化产业的事。 2019阿里云智慧文旅峰会在全域旅游，文化融合的大趋势下，如何应用大数据，物联网，区块链等新兴技术，提升客户体验与开拓产业创新。更多直播，请访问云栖号-直播库 <完结> 还想了解更多不同行业，不同产品的云资讯，云产品入门，上云案例和实践，请访问云栖号

发表了文章 2020-01-23

云栖号2019云计算盘点 -【新零售上云篇】

2019，是新零售继续遍地开花的一年，也是新零售充满变数的一年。新零售在2019留下太多痕迹，此次通过“云栖号2019云计算领域盘点--新零售篇”，让我们一起来了解2019新零售行业的那些事。盒马推出新业态：盒马里 11月30日，在深圳莲塘正式开业的盒马里岁宝是全国第一家实现线上线下打通的社区Mall(购物中心)。盒马里相比此前推出的6个业态，是主打实现“一站式一体化”服务。正如侯毅在视频中透露的，盒马里可以解决用户周末的消费需求，小孩的亲子活动和教育，以及日常生活的便利性服务。华润万家推出萬家Mart 1月5日，首家华润·万家MART借由深圳梅龙店亮相业界。营业面积压缩近一半，约为8500平方米，并新增特色餐饮区小海鲜、面食等。卖场以生鲜区的大圆为中心向两边放射式发散，两边多是餐厨家电和用具、图书、寝具、清洁日化等，搭配大量岛柜、堆头、低矮货架与自选区域。门店还投入大量高科技的应用，移动支付、扫码购、自助称重、自助点餐等在万家MART店都已应用。三只松鼠上市从发展历程来看，三只松鼠是个实实在在的互联网品牌。背靠淘宝店铺起家，有了品牌知名度之后，走到线下，完成“新零售”的转型。2019年7月12日，三只松鼠挂牌深交所创业板，开盘价17.62元，截至收盘报21.14元，涨幅44.01%，当前市值84.8亿元。阿里巴巴收购网易考拉 2019年9月6日，阿里巴巴以20亿美元全资收购网易旗下跨境电商平台考拉。收购完成后，网易考拉将并入天猫国际进出口事业部（隶属于大天猫三大板块之一）。联合阿里，百胜软件持续中台“进化” “零售企业原来的信息化建设重视的是企业流程的管理，今天则更注重数据，更注重运营。技术价值也进行了重构，从数字化转向了数智化。”在零售行业深耕了20年的百胜软件董事长兼CEO黄飞，于2019年12月20日在百胜软件用户大会上表示。数据的驱动下，我们见证了许多行业的变革，也看到了新零售行业从一开始的提出构想到现在的逐步落地，基础进一步牢固，向更高的阶梯迈进。那么新零售行业是如何突破创新的呢？接着往下看你可能会有所启发！新零售行业上云三部曲，一图了解新零售行业上云：同行上云的案例比比皆是…… 【云集微店】云集微店业务上云案例从起步期的一台ECS、到现在1500台ECS。阿里云帮助云集微店不断优化云上系统架构。双11期间，3000台服务器，只有4个运维人员，在以前是不可想像的。【三只松鼠】三只松鼠2019年全平台双11用时19分23秒破亿的秘诀大促服务节点负载压力大，做不到快速补充资源！上云后资源限定优化，订单处理2527笔/min，时效缩短36%，线上发现问题快速滚动迭代，整体感受快、稳、方便。【花生日记】云原生架构助力花生日记双11大促如何稳定度过双11大促一直是花生日记的痛点，架构转到云原生微服务体系后系统整体的弹性能力得到了很大提升，助双十一支撑了平时6倍的业务高峰。更多案例，请访问云栖号-案例库也想像他们一样轻松上云吗？看阿里云最佳实践带你一步步上云初期阶段电商行业解决方案及数据库搬站最佳实践该方案适用于新零售领域的电商行业，包括电商公司初创，满足快速搭建平台；以及中型企业应对发展阶段，满足业务快速占领市场。对于头部客户搬站，方案借鉴参考。本文重点解决阿里云资源的开通配置，以及其他云厂商或自建的MySQL搬迁到阿里云RDS。企业应用上云混合云网络解决方案重点提供一种简单且具备成本效益的混合云网络解决方案，通过云服务器和数据库来搭建云上应用系统，通过部署SLB提供后续业务发展的横向扩展性以及应用容灾。发展阶段互联网、电商行业搜索最佳实践（Elasticsearch版）每一个生活在互联网中的用户，每天都在经历各种各样的“搜索”，查找电商网站商品、信用卡账单、查电子发票、查附近的餐厅酒店、查偶像、查交通等等。相对于传统的关系型数据库，Elasticsearch只需要几毫秒的时间，即可查询 PB 级数据并从中找到匹配信息。利用Elasticsearch高可用性和易用性，能够快速处理网站、APP丢给它的文本、数字、日期、IP 以及地理数据。电商网站数据埋点及分析最佳实践数据埋点是数据产品经理、数据运营以及数据分析师，基于业务需求（例如：CPC点击付费广告中统计每一个广告位的点击次数），产品需求（例如：推荐系统中推荐商品的曝光次数以及点击的人数）对用户行为的每一个事件对应的位置进行开发埋点，并通过SDK上报埋点的数据结果，记录数据汇总后进行分析，推动产品优化或指导运营。成熟阶段基于EMR弹性低成本大数据分析实践方案大数据是一项设计不同业务和技术的领域的技术和工具的集合，海量离线数据分析可以应用于多种商业系统环境，例如电商海量日志分析、用户行为画像分析、科研行业的海量离线计算分析任务等场景。基于阿里云的E-MapReduce(EMR) 、对象存储OSS、日志服务SLS、抢占式ECS实例构建弹性、低成本的计算与存储分离架构的海量离线大数据分析日志分析系统。 AI模型训练解决方案本方案适用于AI图片训练场景，使用CPFS/NAS作为共享存储，利用容器服务Kubernetes版管理GPU云服务器集群进行图片AI训练。介绍了使用阿里云的容器服务ACK搭建AI训练环境的最佳实践。更多实践，请访问云栖号-最佳实践库在这些案例和最佳实践中涉及到的产品都有哪些呢？云栖号带你快速入门~ 云服务器ECS入门云服务器（Elastic Compute Service，简称ECS）是阿里云提供的性能卓越、稳定可靠、弹性扩展的IaaS（Infrastructure as a Service）级别云计算服务。云服务器ECS免去了您采购IT硬件的前期准备，让您像使用水、电、天然气等公共资源一样便捷、高效地使用服务器，实现计算资源的即开即用和弹性伸缩。阿里云ECS持续提供创新型服务器，解决多种业务需求，助力您的业务发展。容器服务 ACK容器服务 Kubernetes 版（简称 ACK）提供高性能可伸缩的容器应用管理能力，支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力，打造云端最佳容器化应用运行环境。容器镜像服务 ACR提供安全的镜像托管能力，稳定的国内外镜像构建服务，便捷的镜像授权功能，方便用户进行镜像全生命周期管理。日志服务 LOG行业领先的日志大数据解决方案，一站式提供数据收集、清洗、分析、可视化和告警功能。全面提升海量日志处理能力，实时挖掘数据价值，智能助力研发/运维/运营/安全等场景。更多云产品入门，请访问云栖号-快速入门库当然，除了这些干货知识，云栖号还为您收集了有趣的活动和大赛飞天战略营：零售智能变革思考借助新一代信息技术，传统零售行业可以从“重构消费者关系”和“突破效能天花板”两方面，实现智能化变革，摆脱经营困境。 Airbnb短租数据集分析赛共享，通过让渡闲置资源的使用权，在有限增加边际成本的前提下，提高了资源利用效率。随着信息的透明化，越来越多的共享发生在陌生人之间。短租，共享空间的一种模式，不论是否体验过入住陌生人的家中，你都可以从短租的数据里挖掘有趣的信息。云栖号：https://yqh.aliyun.com第一手的上云资讯，不同行业精选的上云企业案例库，基于众多成功案例萃取而成的最佳实践，助力您上云决策！

发表了文章 2020-01-23

云栖号2019云计算盘点-【金融行业上云篇】

新年到了，在这里小编祝大家新年快乐，鼠年大吉！春节，是我国最重要的传统节日，一提到春节，大家想到的就是，喜庆、欢乐和一年的丰收。接下来小编就带大家一起回顾一下金融行业热点事件。 2019即将到站！金融热点事件盘点：阿里巴巴香港正式上市 11月26日，阿里巴巴集团阔别七年正式重返港股，股价也一路不断创新高。截至2019年12月24日收盘，阿里巴巴股价涨至210.40港元，市值4.5万亿港元，成功超越长期稳居港交所市值第一的腾讯控股，成为新任“市值第一”。蚂蚁金服获香港金管局颁发的“虚拟银行”牌照香港金管局于去年5月底发布了《虚拟银行的认可》指引，并提出了申请人需要满足“具备足够的财务、科技及其他相关资源；业务计划可信和可行，能提供新客户体验，并能促进普及金融和金融科技发展；有能力发展合适的信息科技平台；准备完备可迅速投入运营”等四项要求。从结果来看，蚂蚁金服凭借科技实力，从众多申请公司中脱颖而出。科创板横空出世 2019年A股的头等大事是什么，毫无疑问是科创板的上市。从2018年11月5日到2019年7月22日，从宣布设立科创板并试点注册制到科创板正式开市，仅仅只用了259天，这个新兴市场带着支持科技创新产业的使命进入投资者眼中。印度支付公司Paytm获10亿美元融资，蚂蚁金服、软银领投 2019年11月25日，印度数字支付巨头Paytm母公司One97 Communications宣布，公司已在新一轮融资中筹集了10亿美元资金，由软银集团和蚂蚁金服领投。本轮融资对One97的估值为160亿美元，使其成为亚洲估值最高的创业公司之一。人民币汇率破“7” 2019年8月5日，人民币在岸、离岸汇率双双破“7”。央行盘中发声，称人民币资产的估值仍然偏低，稳定性相应更强，中国有望成为全球资金的“洼地”。人民银行有经验、有信心、有能力保持人民币汇率在合理均衡水平上基本稳定。回顾完行业事件，金融行业是怎么上云的？看金融行业是如何携手云计算变革大局，跟着小编往下看：来看看金融行业企业的上云故事【招商银行】招商银行信用卡中心智能外呼系统上云案例我们在外呼及客户智能交互中使用阿里云产品。语音识别产品准确率达到业界领先水平，能很好的处理普通话和带口音普通话；语音合成产品拟人度非常高，音库也非常丰富。【红岭创投】红岭创投应用及数据迁移上云案例 ”阿里云为红岭创投提供7*24不间断的护航保障，快速响应，助力业务系统和数据平滑上云，让业务系统平稳度过业务流量高峰。“ 【鹏元征信】鹏元征信混合云架构平滑上云案例我们有大量需要和客户联系的业务，如何在保证和客户沟通质量的前提下，降低运营成本；如何采用智能化的手段加快人员培训，是卡中心要解决的业务难题。【帝国金融】帝国金融平台安全迁移案例作为一个金融机构，为客户提供稳定服务是我们的首要任务。阿里云的企业保障服务帮助我们顺畅的完成平台搬迁，每时每刻都在为我们的服务提供保障。【众安保险】阿里云助力众安保险“双11”大促案例阿里云护航小组对众安保险MaxCompute、ECS、RDS、安全等资源情况进行了整体评估，保障众安业务系统双十一平稳运行。【盒子科技】盒子科技支付业务平滑迁移上云案例历时1个月，盒子科技支付业务平滑迁移到阿里云，解决IT基础设施限制业务发展的难题。依托阿里云优质的BGP网络，盒子科技的商户支付体验大幅提升。更多案例，请访问云栖号-案例库怎么上云？不同阶段的最佳实践指导你一步步上云！初级阶段 Terraform应用使用Terraform工具进行云上业务架构的应用实践和代码示例服务器迁移使用阿里云提供的迁移工具将物理服务器、虚拟机以及其他云平台云主机一站式地迁移到阿里云ECS用于企业上云，提高服务器迁移时的系统还原度，降低操作难度，提高迁移速度。发展阶段弹性裸金属自建ORACLE数据库单机版使用弹性裸金属在云上自建ORACLE数据库，并对ORACLE宕机重新快速恢复进行了介绍，解决如何利用云上强劲资源，如神龙服务器、ESSD存储，支撑数据库高效稳健运行，如何快速备份和恢复数据库数据，保证云上数据的安全性。自建K8S集群迁移ACK弹性裸金属集群从线下IDC自建K8S零改造迁移云上ACK神龙集群，在微服务化改造之后，企业在享受K8S带来应用管理的便利的同时，存在硬件性能不足，本地扩展性差，容器容灾难，K8S管理复杂等问题。创新阶段 GPU AI模型训练使用阿里云基础设施搭建AI训练的容器环境，利用Perseus加速框架进行AI模型训练加速，适用于AI图片训练场景，使用CPFS/NAS作为共享存储，利用容器服务Kubernetes版管理GPU云服务器集群进行图片AI训练。抢占式ECS搭建离线大数据分析集群使用阿里云抢占式ECS实例以及OSS等云上产品构建低成本弹性大数据分析系统更多实践，请访问云栖号-最佳实践库涉及到云产品不了解？小编带你云产品快速入门！快速了解 ECS 资源计费规则，最省钱的使用ECS！介绍云服务器 ECS 的计费资源类型、各种资源类型的计费方式对比和购买资源时的支付方式，便于您更合理地使用ECS。 SLB 一站式学习负载均衡 SLB（Server Load Balancer）是将访问流量根据转发策略分发到后端多台云服务器（ECS 实例）的流量分发控制服务。大数据计算服务 · MaxCompute MaxCompute（原ODPS）是一项大数据计算服务，它能提供快速、完全托管的PB级数据仓库解决方案，使您可以经济并高效的分析处理海量数据。云数据库 RDS MySQL 版 MySQL 是全球最受欢迎的开源数据库之一，作为开源软件组合 LAMP（Linux + Apache + MySQL + Perl/PHP/Python）中的重要一环，广泛应用于各类应用场景对象存储 OSS 比传统存储成本下降25%~75%的强安全企业级存储更多云产品入门，请访问云栖号-快速入门 <完结> 还想了解更多不同行业，不同产品的云资讯，云产品入门，上云案例和实践，请访问云栖号

发表了文章 2020-01-23

云栖号2019云计算盘点 -【医疗健康行业上云篇】

不知不觉，又到了一年的年终岁末。回首2019，国内外医疗界注定不平凡，全球首个3D打印心脏问世、万众瞩目的诺贝尔生理学或医学奖落幕，每一项医学新成果都挑战着人们的想象，聚焦着全世界的目光。至此我们盘点了2019年国内外医疗行业热点事件万众瞩目——诺贝尔生理学或医学奖北京时间2019年10月7日17点30分，2019年诺贝尔生理学或医学奖揭晓，来自美英的三位科学家William G. Kaelin Jr, Sir Peter J. Ratcliffe和Gregg L. Semenza获奖，获奖理由是“发现了细胞如何感知和适应氧气的可用性”。今年诺贝尔奖获得者做出的开创性发现揭示了生命重要的适应过程之一的作用机制。他们为我们了解氧水平如何影响细胞代谢和生理功能奠定了基础。他们的发现也为抗击贫血、癌症和许多其他疾病的新策略铺平了道路。震惊世界——全球首个3D打印心脏 2019年4月15日，特拉维夫大学的研究人员使用患者自己的细胞和生物材料「打印」了世界上个 3D 血管化心脏，并在《Advanced Science》中发表了研究成果。这也是次有人成功设计和「打印」了充满细胞、血管、心室的完整心脏。病魔总是无法预料地出现在一个又一个家庭，而人们在心脏病这种重大疾病面前更显无力和脆弱。但此刻，未来医院都将有器官打印机的那一天，或许离我们又更近了一些。重大突破--脑机芯片让瘫痪患者用意念喝可乐打麻将中国首例，大脑植入电极，高位截瘫病人用意念喝水,据了解此次我国该脑机接口项目的成功主要由三个重要环节决定：微电极植入、神经信号采集分析和人机训练。我国脑机接口研究迈上新台阶但未来还有很长的路要走。达摩院计划推出通才型AI医生在自然语言处理 (NLP) 顶会EMNLP 2019上，阿里达摩院开发的AI获得了微生物群落信息抽取比赛“关系和实体联合抽取”这项任务的冠军。利用大型语料库对关系和实体进行建模；再通过大型语料库与低资源语料库之间的知识迁移，帮AI提升低资源语料中的信息提取能力。而信息提取，对搭建医疗知识图谱来说非常关键。达摩院计划推出业内首个掌握全域医疗知识的通才型AI医生。失独妈妈求助阿里，复制虚拟人通过AI发出女儿声音一位上海妈妈，她的女儿因患T淋巴母细胞性淋巴瘤离世，年仅14岁。怀抱着太多孩子生前未能实现的遗憾，这位妈妈决定将女儿做成“AI”，用另一种方式缅怀她。阿里巴巴人工智能实验室负责人、语音助手首席科学家聂再清接受了这位妈妈的求助。三个月的时间让失独妈妈重新听见女儿的声音。看完这些我们可能在思考一个问题，医疗事业到底是如何取得如此重大进步的。我们也想和他们一样又该如何。到底医疗行业怎么和云计算结合才能助力云计算创新和变革呢？接下来我们就看看医疗行业上云的不同阶段是如何做的？进入这些阶段以后我们医疗界的同行是怎样上云的呢？【燃石医学】燃石医学上云为百万患者而努力燃石医学专注肿瘤患者个体化治疗指导，混合云存储方案解决了数据存储和保存的问题，实现了本地计算和云端计算能力的整合，使患者生存几率大大提高。【华大基因】华大基因数据上云，实现数据分析效率提高数千倍华大基因通过阿里云设计海量存储计算与数据安全等云平台架构，保障云上业务搭建与运转，实现了22小时内达成千人基因组分析的人类梦想。【趣医网】趣医网上云，专人专群支持确保了客户的云上服务公司倾力缔造互联网医疗平台“医院+”，致力于构建可持续发展的互联网医疗生态圈。阿里云服务团队提供企业级的售后服务，专人专项的支持，便捷的IM企业群互动，高效的服务响应，并给出对应的解决方案，确保项目质量以及云上业务的长期稳定。【岗岭集团】岗岭集团上云，加速医生、药店、医院、药企、药品流通商赋能为改变中国大众“看病难、买药贵”的现状。岗岭集团运用创新的互联网和IT技术提供在线诊疗、购药和健康管理等服务业务的快速发展，但每一次大促都是一场挑战。选择阿里云后在每次重大活动期间，提前做好准备工作，在业务快速增长期保证了云上系统平稳。更多案例，请访问云栖号-案例库怎么上云？最佳实践指导你一步步上云初级阶段智能视频监控解决方案可利用监控智能分析工作人员到场情况,线下监控视频通过摄像头实时上传到阿里云。通过视频监控平台做转码存储为数据文件，即可通过智能视觉产品做AI智能分析。服务器搬迁解决方案适用将物理服务器、虚拟机以及其他云平台云主机，一站式地迁移到阿里云ECS，支持迁移主流Windows和Linux操作系统。自动对源服务器进行迁移条件检测。发展阶段 EMR弹性低成本离线大数据分析基于阿里云的E-MapReduce(EMR) 、对象存储OSS、日志服务SLS、抢占式ECS实例构建弹性解决大数据平台运维管理成本高，计算资源弹性能力不足等问题。互联网行业高弹性系统构建适用于在互联网行业的业务中具有突发性业务特点的场景。业务系统能释放冗余的资源达到节约成本的目标。创新阶段 Vina部署到EHPC集群教你如何药物筛选本方案适用于使用弹性高性能计算EHPC和文件存储NAS来搭建基础环境，运行药物筛选应用Autodock Vina的场景中解决使用EHPC运行药物筛选应用。基于弹性计算的AI推理解决方案使用GPU云服务器搭建推理环境，完成图像分类，目标检测，语音识别，语义分析等返回结果的过程。更多实践，请访问云栖号-最佳实践库云产品太多不知道该选择哪个？涉及到云产品不了解？接下来小编带你云产品快速入门！阿里云能为你做什么？阿里云致力于以在线公共服务的方式，提供安全、可靠的计算和数据处理能力，让计算和人工智能成为普惠科技一键了解监控与日志云原生最初来描述云上应用的典型架构与特性，近几年，云原生的概念也不断演进，希望能够让用户最好的利用云的资源、产品和交付能力。 9课时带你走进分布式计算入门大数据分步式计算中的相关技术进行讲解，核心讲解流式计算和内存计算技术，阐述阿里云在处理这些功能时所使用的技术虚拟化技术入门主要讲解云计算技术的核心技术之一虚拟化技术，课程说明了虚拟化技术的主要作用以及常见实现方法，并针对硬件中常用的虚拟化技术进行详细的讲解。更多入门，请访问云栖号-新手入门 <完结> 还想了解更多不同行业，不同产品的云资讯，云产品入门，上云案例和实践，请访问云栖号

发表了文章 2020-01-22

阿里开发者工具盘点：用它！让开发事半功倍

阿里妹导读：工欲善其事，必先利其器。从人工到自动化，从重复到创新，信息技术不断演进，开发者工具也在发展。开发效率低下往往是忽略了工具的使用，正确地使用开发者工具，可以让开发效率获得倍速提升。阿里巴巴将自身在业务场景下的技术沉淀，通过开源、云上实现或工具等形式对外开放，今天阿里妹就对阿里巴巴内部沉淀下来的开发者工具和资源做了一轮盘点，希望能帮助开发者们提高开发效率、更优雅地写代码。一、镜像站稳定高速种类全镜像站对开中国开发者来说可谓必备利器，受国际网络出口带宽的影响，大多数开源软件官网的速度慢，稳定性不足。作为国内最富盛名的镜像站之一，阿里巴巴镜像站利用其在云服务上的优势，提供快速、稳定的镜像分发服务。目前主要包括OPSX，NPM（NodeJS）,composer(PHP)和goproxy。镜像内容方面，以OPSX为例,目前已覆盖了主流操作系统 CentOS，Ubuntu，Fedora，Gentoo，Debian，FreeBSD和对做 docker 镜像帮助很大的Alpine。编程语言覆盖了Python，Ruby，Perl，R。软件方面除了 Apache 下的所有知名软件 Hadoop，Hive，Cassdra，Spark 都有覆盖，还包括 docker，zabbix，ceph，mongodb，mariadb 也都有，基本上主流软件更新都可以在这个镜像站搞定。如果你对镜像有需求，阿里妹墙裂推荐哦。二、开源工具助力开发，全面实用 ★ Alibaba Dragonwell Alibaba Dragonwell 是阿里巴巴内部 OpenJDK定制版 AJDK 的开源版本， AJDK 为在线电商，金融，物流做了结合业务场景的优化，运行在超大规模的，100,000+ 服务器的阿里巴巴数据中心。Alibaba Dragonwell 与 Java SE标准兼容，目前提供JDK8和11两个长期支持（LTS）版。 2019年6月我们发布了Dragonwell8的正式版，您可以通过简单的两步安装Dragonwell8产品：在阿里云开发者社区工具平台-开源工具找到Alibaba Dragonwell的链接，点击进入github地址后选择下载。你也可以通过阿里云yum源或者Dragonwell8 Docker镜像来使用，详情请参考：Dragonwell8Wiki：https://github.com/alibaba/dragonwell8/wiki Alibaba Dragonwell8 提供了两个在阿里巴巴的生产环境中进行过广泛验证的特性：JWarmUp 和 JavaFlight Recorder。 JWarmUp 的原理如下图所示：一个典型的应用场景是当应用需要发布新版本的时候：首先 JWarmUp 在 Beta 环境（或者有着和生产环境类似流量的其他场景）的单台机器上短时间执行 Java 应用，并记录、收集这段时间里面 JIT 编译器所做动作的一些元数据。然后，会把这些元数据复制到生产环境的每一台包含了新版本代码的机器/容器里面。最后，在生产环境机器中通过 JWarmUp 参数加载 beta 环境生成的元数据，来指导生产环境的机器在启动应用的过程中就完成 JIT 预热。这样当用户请求进入的时候，应用就会处于性能最高的峰值状态。 JFR（Java Flight Recorder）是JVM 内置的基于事件的性能分析特性，这是 Oracle JDK7u4 版本开始提供的商业特性，2018 年的时候在 JDK11 上开源了这个特性，但是一直没有针对 JDK8 版本的支持。阿里巴巴和 RedHat、Azul、Amazon 等公司一起合作尝试把这个特性移植回 JDK8上，不过该 patch 暂时还没有合并回 OpenJDK8u仓库，我们在 Alibaba Dragonwell 8 中提供了 Alibaba 移植的 JFR 版本，用于帮助用户提前获取这方面的支持。 JFR 的用法很简单，用户使用命令行参数或者 jcmd 命令控制 HotSpot 输出性能数据到文件中，然后就能使用开源的 jmc 工具在图形界面中打开、分析生成的数据文件了。 2019年12月，阿里巴巴开源了Dragonwell 11项目并发布了11.0.5.1-preview版本，基于最新的LTS版OpenJDK11，提供了JFR Object Profiling特性并默认支持了ZGC策略，希望可以帮助用户享受最新的Java技术红利。 ★ Arthas 阿里巴巴2018年9月开源的Java线上诊断工具，它采用命令行交互模式，提供了丰富的功能，是排查jvm相关问题的利器。具体包括：提供性能看板，包括线程、cpu、内存等信息，并且会定时的刷新。根据各种条件查看线程快照。比如找出cpu占用率最高的n个线程等。输出jvm的各种信息，如gc算法、jdk版本、ClassPath等。查看/设置sysprop和sysenv。查看某个类的静态属性，也可以通过ognl语法执行一些语句。查看已加载的类的详细信息，比如这个类从哪个jar包加载的。也可以查看类的方法的信息。 dump某个类的字节码到指定目录。直接反编译指定的类。查看类加载器的一些信息。可以让jvm重新加载某个类。监控方法的执行，同时可以获取到执行的入参、出参以及抛出的异常。追踪方法执行的调用栈，以及各个方法的调用时间。在线编译，热更新代码生成热点代码火焰图原理图及支持的命令列表： ★ ChaoBlade ChaosBlade 是阿里巴巴开源的一款遵循混沌工程原理和混沌实验模型的实验注入工具，帮助企业提升分布式系统的容错能力，并且在企业上云或往云原生系统迁移过程中业务连续性保障。ChaosBlade 不仅使用简单，而且支持丰富的实验场景，场景包含：基础资源：比如 CPU、内存、网络、磁盘、进程等实验场景。 Java 应用：比如数据库、缓存、消息、JVM 本身、微服务等，还可以指定任意类方法注入各种复杂的实验场景。 C++ 应用：比如指定任意方法或某行代码注入延迟、变量和返回值篡改等实验场景。 Docker 容器：比如杀容器、容器内 CPU、内存、网络、磁盘、进程等实验场景。云原生平台：比如 Kubernetes 平台节点上 CPU、内存、网络、磁盘、进程实验场景，Pod 网络和 Pod 本身实验场景如杀 Pod，容器的实验场景如上述的 Docker 容器实验场景。相关生态图如下： ★ P3C： P3C可以帮助Java开发者检测代码中村在的不规范的位置并给与提示。规约插件采用Kotlin语言进行开发。 ★ Funcraft： Serverless 应用开发调试部署工具。三、阿里云开放平台丰富的API和SDK向开发者提供阿里云开放能力。 ★ API API文档：可以找到阿里云已经开放API的产品及相应的文档地址。 API Endpoint：查询各产品OpenAPI的访问Endpoint，可以直接访问该Endpoint或用于配置SDK。 API 在线调试：支持快速检索、可视化调试 API、在线命令行工具、同步动态生成可执行 SDK Example 代码。 API 错误中心：在这里可以搜索接收到的错误码，并获取简单的解决提示。 ★ SDK 提供多语言的 SDK 为用户封装 API 签名计算，组织请求结构，构建连接池提升请求效率和性能，解析返回结果等。让开发者不用复杂代码即可访问云服务器、云数据库RDS、云监控等多个阿里云服务。阿里云SDK包含：Java SDK、PythonSDK、GO SDK、PHP SDK、.NET SDK、Node.js SDK等。四、阿里云代码示例库经典代码一键复制阿里云CodeSample以场景为维度，支持以云产品和语言为条件选取目标代码。告别CTRL+C,CTRL+V，点击图标一键复制，好用到没朋友。五、云产品工具优质且免费的阿里云产品工具。云产品通用 ★ Cloud Toolkit Cloud Toolkit 是免费的本地 IDE 插件，支持IntelliJ IDEA、Eclipse、PyCharm、Maven、VSCode以及其他版本，帮助开发者更高效地开发、测试、诊断并部署应用。通过插件，可以将本地应用一键部署到任意服务器，甚至云端（ECS、EDAS、Kubernetes、ACR 和小程序云等）；并且还内置了 Arthas 诊断、Dubbo工具、Terminal 终端、文件上传、函数计算和 MySQL 执行器等工具。（产品官网：https://www.aliyun.com/product/cloudtoolkit）通过该插件，你可以：一键部署本地 IDE 内项目到任意远程服务器一键部署本地 IDE 内项目到阿里云 EDAS、SAE 和Kubernetes 本地 Docker Image 打包和仓库推送工具远程服务器实时日志查看阿里云小程序开发工具阿里云函数计算开发工具阿里云 RDS 内置 SQL 执行器内置 Terminal 终端文件上传 Apache Dubbo 框架项目模板&代码生成 Java 程序诊断工具 RPC 服务端云联调 ★ Cloud Shell 网页版命令行工具，允许用户通过命令行管理阿里云资源。 ★ CLI 在Alibaba Cloud SDK for GO 之上构建的开源工具。借助此工具，您可以通过调用阿里云开放 API 来管理阿里云产品。该命令行工具与阿里云开放 API 一一对应，灵活性高且易于扩展。您可基于该命令行工具对阿里云原生 API 进行封装，扩展出您想要的功能。数据库 ★ 数据库备份DBS 为数据库提供连续数据保护、低成本的备份服务。它可以为多种环境的数据提供强有力的保护，包括企业数据中心、其他云厂商、混合云及公共云。 ★ 数据传输服务DTS DTS支持关系型数据库、NoSQL、大数据(OLAP)等数据源间的数据传输。它是一种集数据迁移、数据订阅及数据实时同步于一体的数据传输服务。数据传输致力于在公共云、混合云场景下，解决远距离、毫秒级异步数据传输难题。它底层的数据流基础设施为阿里双11异地多活基础架构，为数千下游应用提供实时数据流，已在线上稳定运行5年之久。 ★ 数据库和应用迁移 ADAM ADAM是一款把数据库和应用迁移到阿里云（公共云或专有云）的产品，显著地降低了上云的技术难度和成本，尤其是Oracle数据库应用。ADAM全面评估上云可行性、成本和云存储选型，内置实施协助，数据、应用迁移等工具，确保可靠、快速上云。基础仓库开放云原生应用中心 ——Cloud Native App Hub，一个面向开发者的云原生应用市场。 ★ 容器镜像服务（ContainerRegistry） ACR提供安全的镜像托管能力，稳定的国内外镜像构建服务，便捷的镜像授权功能，方便用户进行镜像全生命周期管理。容器镜像服务简化了Registry的搭建运维工作，支持多地域的镜像托管，并联合容器服务等云产品，为用户打造云上使用Docker的一体化体验。迁移工具 ★ 迁云工具帮助你完成服务器迁移到阿里云的P2V和V2V。 ★ 闪电立方为用户提供安全、高效、便捷的数据传输服务。支持将对象存储、文件存储从不同设备、不同云服务商迁移和同步到阿里云。它提供在线迁移和离线迁移(闪电立方)两种迁移方式，致力于解决大规模数据传输效率、安全问题等难题。 Serverless ★ FC WebIDE 一款开发Serverless的云端开发工具。 ★ FC VSCode Extension 图形化开发调试及操作函数计算资源工具。六、小程序云开发平台一云多端小程序云小程序云（Mini Program Cloud）是阿里云面向小程序场景提供的一站式云服务，帮助开发者实现一云多端的业务战略，提供了有服务器和无服务器两种模式。云应用是有服务器模式，提供了包括资源编排、应用托管等服务。小程序Serverless是无服务模式，提供了开发、运营、业务增值等服务。跨端开发工具链为开发者提供了一次开发全网小程序运行的能力，并在一朵云内实现统一的资源管理、统一的数据运营和统一的业务设计。 Serverless 阿里云小程序Serverless提供包括云函数、数据存储、文件存储等一整套后端服务。开发者通过API方式即可获取云函数、数据存储、文件存储、音视频、图像处理等服务，不需要关心服务器或底层运维设施，可以更专注于代码和业务本身。跨端IDE uni-app跨平台开发扩展支持在阿里云小程序开发者工具中将uni-app工程编译为微信小程序，并同时打开微信开发者工具。跨端IDE内置跨端框架，支持一次开发多端运营，兼容支付宝、微信等主流小程序框架。本地插件支持通过IntelliJ IDEA、Eclipse、Pycharm等直接发布到云应用服务。点击此处即可使用上文提到的所有开发者工具，建议将链接收藏后在PC端打开哦。原文发布时间：2020-01-22作者：崆峒本文来自阿里云合作伙伴“阿里技术”，了解相关信息可以关注“阿里技术”。

发表了文章 2020-01-21

阿里高级技术专家：整洁的应用架构“长”什么样？

阿里妹导读：作者张建飞是阿里巴巴高级技术专家，入司6年，他创建了COLA。希望可以探索一套切实可行的应用架构规范，这个规范不是高高在上的纸上谈兵，而是可以复制、可以理解、可以落地、可以控制复杂性的指导和约束。本文详述了他对COLA的升级迭代。很多同学不止一次和我反馈，我们的系统很混乱，主要表现在：应用的层次结构混乱：不知道应用应该如何分层、应该包含哪些组件、组件之间的关系是什么；缺少规范的指导和约束：新加一段业务逻辑不知道放在什么地方（哪个类，哪个包）、应该起什么名字比较合适？解决这些问题，正是我创建COLA（https://github.com/alibaba/COLA）的初心之一——试图探索一套切实可行的应用架构规范，这个规范不是高高在上的纸上谈兵，而是可以复制、可以理解、可以落地、可以控制复杂性的指导和约束。自从COLA诞生以来，我收到了很多的意见和建议。同时，我自己在实践过程中，也发现COLA 1.0的诸多不足，有些设计是冗余的并不是很有必要，而有些关键要素并没有囊括。譬如，我最近在思考的应用架构核心和复杂业务代码治理就是对COLA 1.0的反思。结合实践中的探索和对复杂度治理持续的思考，我决定对COLA进行一次全面的升级，于是有了现在的COLA 2.0。从1.0到2.0，不仅仅是数字的简单变化，更是架构理念和设计理念的升级，其主要变动点包括：新架构分层：Domain层不再直接依赖Infrastructure层。新组件划分：对组件进行了重新定义和划分，加了新组件，去除了一些老组件（Validator，Convertor等）。新扩展点设计：引入了新概念，让扩展更加灵活。新二方库定位：二方库不仅仅是DTO，也是Domain Model的轻量级表达和实现。新架构分层在COLA 1.0中，我们的分层是如下图所示的经典分层结构：在COLA 2.0中，还是这些层次，但是依赖关系发生了变化，Domain层不再直接依赖Infrastructure层，而是引入了一个Gateway的概念，使用DIP（Dependency Inversion Principle，依赖倒置）反转了Domain层和Infrastructure层的依赖关系，其关系如下图所示：这样做的好处是Domain层会变得更加纯粹，完全摆脱了对技术细节（以及技术细节带来的复杂度）的依赖，只需要安心处理业务逻辑就好了。除此之外，还有两个好处： 1. 并行开发：只要在Domain和Infrastructure之间约定好接口，可以有两个同学并行编写Domain和Infrastructure的代码。 2. 可测试性：没有任何依赖的Domain里面都是POJO的类，单元测试将会变得非常方便，也非常适合TDD的开发。新组件划分模块和组件的定义首先，先明确一下组件（Component）这个概念的定义，组件在Java中（或者说在本文中），其范围就是Java的包（Package）。还有一个词叫模块（Module），组件和模块这两个概念是比较容易发生混淆的。比如在《实现领域驱动设计》中，作者就说： If you are using Java or C#, you are already familiar with Modules, though you know them by another name. Java calls them packages. C# calls them namespaces. 他认为Module是Package，我认为这个定义容易造成混淆。特别是在使用Maven的时候，在Maven中，Module是一个Artifact，通常是一个Jar而不是Package。比如COLA Framework就包括如下四个Module： <modules> <module>cola-common</module> <module>cola-core</module> <module>cola-extension</module> <module>cola-test</module> </modules> 的确，Module和Component这两个概念很相近，很容易造成混淆。比如，在StackOverflow上有一个提问【1】，就是问Module和Component之间区别的。获得最高赞的答案是通过Scope来区分的。 The terms are similar. I generally think of a "module" as being larger than a "component". A component is a single part, usually relatively small in scope. 这个回答和我的直觉反应是一致的，即Module比Component要大。根据以上信息，我在此对Module和Component进行一下定义说明，在本文中，都会遵照如下的定义和Notation（表示法）。模块（Module）：和Maven中Module定义保持一致，简单理解就是Jar。用正方体表示。组件（Component）：和UML中的定义类似，简单理解就是Package。用UML的组件图表示。一个Moudle通常是由多个Component组成的，其关系和表示法如下图所示： COLA 2.0的组件在COLA 2.0中，我们重新设计了组件，引入了一些新的组件，也去除了一些旧组件。这些变动的宗旨是为了让应用结构更加清晰，组件的职责更加明确，从而更好的提供开发指导和约束。新的组件结构如下图所示：这些组件各自都有自己的职责范围，组件的职责是COLA的重要组成部分，也就是我们上面说的“指导和约束”。这些组件的详细职责描述如下： 1、二方库里的组件： api：存放的是应用对外的接口。 dto.domainmodel：用来做数据传输的轻量级领域对象。 dto.domainevent: 用来做数据传输的领域事件。 2、Application里的组件： service：接口实现的facade，没有业务逻辑，可以包含对不同终端的adapter。 eventhandler：处理领域事件，包括本域的和外域的。 executor：用来处理命令（Command）和查询（Query），对复杂业务，可以包含Phase和Step。 interceptor: COLA提供的对所有请求的AOP处理机制。 3、Domain里的组件： domain：领域实体，允许继承domainmodel。 domainservice: 领域服务，用来提供更粗粒度的领域能力。 gateway：对外依赖的网关接口，包括存储、RPC、Search等。 4、Infrastructure里的组件： config：配置信息相关。 message：消息处理相关。 repository：存储相关，是gateway的特化，主要用来做本域的数据CRUD操作。 gateway：对外依赖的网关接口（Domain里的gateway）的实现。在使用COLA的时候，请尽量按照组件规范约束去构建我们的应用。这样可以让我们的应用结构清晰、有章可循。如此这般，代码的可维护性和可理解性会得到极大的提升。新扩展点设计引入新概念在讨论之前，我们先来明确一下在COLA2.0扩展设计中引入的新概念：业务、用例、场景。业务（Business）：就是一个自负盈亏的财务主体，比如tmall、淘宝和零售通就是三个不同的业务。用例（Use Case）：描述了用户和系统之间的互动，每个用例提供了一个或多个场景。比如，支付订单就是一个典型的用例。场景（Scenario）：场景也被称为用例的实例（Instance），包括用例所有的可能情况（正常的和异常的）。比如对于“订单支付”这个用例，就有“可以使用花呗”，“支付宝余额不足”，“银行账户余额不足”等多个场景。简单来说，就是一个业务是有多个用例组成的，一个用例是有多个场景组成的。用淘宝做一个简单示例，业务、用例和场景的关系如下：新扩展点的实现在COLA 2.0中，扩展的实现机制没有变化，主要变化就在于上文中引入的新概念。因为COLA 1.0的扩展设计思想来自于星环，所以当初的扩展粒度也是copy了星环的“业务身份”。COLA 1.0的扩展定位的方法如下图所示：然而，在实际工作中，能像星环那样支撑多个业务的场景并不常见。更多是对不用用例，或是对同一个用例不同场景的差异化支持。比如“创建商品”和“更新商品”是两个用例，但是大部分的业务代码是可以复用的，只有一小部分需要差异化处理。为了支持这种更细粒度的扩展支持，除了之前的“业务身份（BizId）”之外，我还引入了Use Case和Scenario这两个概念。新的扩展定位如下图所示：可以看到，在新的扩展框架下，原来只能支持到“业务身份”的扩展，现在可以支持到“业务身份”，“用例”，“场景”的三级扩展，无疑比以前要灵活的多，并且在表达和可理解性上也比以前好。在新的扩展框架下，例如我们实现上图中所展示的扩展：在tmall这个业务下——的下单用例——的88VIP场景——的用户身份校验进行扩展，我们只需要声明一个如下的扩展实现（Extension）就可以了。新二方库定位关于二方库的定位表面上来看，是一个简单问题，因为服务的二方库无外乎就是用来暴露接口和传递数据的（DTO）。不过，往深层次思考，它并不是一个简单的问题，因为它涉及到不同界限上下文（Bounded Context）之间的协作问题。它是分布式环境下，不同服务（SOA，RPC，微服务，叫法不同，本质一样）之间如何协作的重要架构设计问题。 Bounded Context之间的协作如何实现不同域之间的协作，同时又要保证各自领域的概念的完整性是有一套方法论的。总体来说，大概有两种方式：共享内核（Shared Kernel）和防腐层（ACL，Anti-Corruption Layer）。 1. 共享内核（Shared Kernel） It’s possible that only one of the teams will maintain the code, build, and test for what is shared. A Shared Kernel is often very difficult to conceive in the first place, and difficult to maintain, because you must have open communication between teams and constant agreement on what constitutes the model to be shared. 上面是引用《DDD Distilled》（作者是Vaughn Vernon）关于Shared Kernel描述的原话，其优点是Share（减少重复建设），其缺点也是Share（团队之间紧耦合）。 2. 防腐层（ACL，Anti-Corruption Layer） An Anticorruption Layer is the most defensive Context Mapping relationship, where the downstream team creates a translation layer between its Ubiquitous Language (model) and the Ubiquitous Language (model) that is upstream to it. 同样是来自于《DDD Distilled》, 防腐层是隔离最彻底的做法，其优点是没有Share（完全解耦，各自独立），其缺点也是没有Share（有一定的转换成本）。不过我和Vernon的观点差不多，都比较赞成防腐层的做法。因为增加的语义转换陈本，相较于系统的可维护性和可理解性而言，是完全值得的。 Whenever possible, you should try to create an Anticorruption Layer between your downstream model and an upstream integration model, so that you can produce model concepts on your side of the integration that specifically fit your business needs and that keep you completely isolated from foreign concepts. 二方库的重新定位在大部分情况下，二方库的确是用来定义服务接口和数据协议的。但是二方库区别于JSON的地方是它不仅仅是协议，它还是一个Java对象，一个Jar包。既然是Java对象，就意味着我们就有可能让DTO承载除了getter，setter之外的更多职能。这个问题以前没有引起我的重视，但是最近在思考domain model的时候，我发现，我们是可以在让二方库承担更多职责的，发挥更大的作用。实际上，在阿里，我发现有些团队已经在这么实践了，而且我觉得效果还不错。比如，中台的类目二方库，在这个事情上就做了比较好的示范。类目是商品中比较复杂的逻辑，里面涉及很多计算，我们先看一下类目二方库的代码是怎么写的：从上面的代码，我们可以发现这已经远远超出DTO的范畴了，这就是一个Domain Model（有数据，有行为，有继承）。这样做合适吗？我认为是合适的：首先，DefaultStdCategoryDO用到的所有数据都是自恰的，即这些计算是不需要借助外面的辅助，自己就能完成。比如判断是否是根类目，是否是叶子类目，获取类目的名称路径等，都是依靠自己就能完成。其次，这就是一种共享内核，我把自己领域的知识（语言、数据和行为）通过二方库暴露出去了，假如有100个应用需要使用isRoot( )做判断，你们都不需要自己实现了。什么？不是说不推荐共享内核的做法吗？（好吧，小孩子才分对错，好吗）。此处的共享内核我认为是有积极意义的，特别是类目这种轻数据、重计算的场景。不过，共享带来的紧耦合也的确是一个问题。所以如果我是类目服务的Consumer的话，我会选择用一个Wrapper去对Category进行包装复用，这样既可以复用它的领域能力，又可以起到隔离防腐的作用。 COLA中的二方库说到这里，我想你应该已经理解我对二方库的态度了。是的，二方库不应该仅仅是接口和DTO，而是领域的重要组成部分，是实现Shared Kernel的重要手段。因此，我打算在COLA 2.0中扩大二方库的职责范围。主要包括两点：二方库中的domain model也是领域的重要组成部分，是“轻量级”的领域能力表达，所谓“轻量级”是说表达是自恰和足够内聚的，类似于上面说的StdCategoryDO的案例。当然，能力的表达也需要遵循通用语言（Ubiquitous Language）。不同Bounded Context之间的协作，要充分利用好二方库的桥梁作用。其协作方式如下图所示。注意，这只是建议，不是标准。实际上，我们永远要在共享和耦合之间做一个权衡，世界上没有完美的架构，也没有完美的设计。合不合适，还需要你自己根据实际场景自己去定夺。 COLA框架的扩展机制至此，关于COLA 2.0的改动点我已经交代的差不多了。再追加一个彩蛋吧。泄密一下COLA作为一个框架（Framework）是如何支持扩展的。框架作为一个组件是被集成在系统中完成某一特定任务的，比如logback作为一个日志框架是帮助我们解决打印日志、日志格式、日志存储等问题的。但面对各种应用场景，框架本身没办法预测你想要的日志格式、日志归档的方式。这些地方需要一个扩展机制，赋能用户自己去配置、去扩展。就扩展的实现方式而言，一般有两种方式，一种是基于接口的扩展，一种是基于数据配置的扩展。基于接口的扩展基于接口的扩展，主要是利用面向对象的多态机制，先在框架中定义一个接口（或者抽象方法）和处理该接口的模板，然后用户实现自己的定制。其原理如下图所示：这种扩展方式在框架中使用很广泛，例如Spring中的ApplicationListener，用户可以实现这个Listener来做容器初始化之后的特殊处理。再比如logback中的AppenderBase，用户可以通过继承AppenderBase实现定制的Appender诉求（往消息队列发送日志）。 COLA作为一个框架，这样的扩展能力在所难免，比如，我们有一个ExceptionHandlerI，在框架中我们提供了一个默认实现，代码如下：但是，并不是每个应用都愿意这样的安排，因此我们提供了扩展，当用户提供了自己ExceptionHandlerI实现的时候，优先使用用户的实现，如果用户没有提供，使用默认实现：基于数据配置的扩展基于配置数据的扩展，首先要约定一个数据格式，然后通过利用用户提供的数据，组装成实例对象，用户提供的数据是对象中的属性（有时候也可能是类，比如slfj中的StaticLoggerBinder），其原理如下图所示：我们一般在应用中使用的KV配置都属于这种形式，框架中的使用场景也很多，比如上面提到的logback中对日志格式、日志大小的logback.xml配置。在COLA中，我们通过Annotation对扩展点的配置@Extension(bizId = "tmall", useCase = "placeOrder", scenario = "88vip")，也是一种典型的基于数据的配置扩展。如何使用COLA 2.0 源代码 COLA 2.0的源代码在 https://github.com/alibaba/COLA 生成COLA应用 COLA 2.0 提供了两套Archetype，一套是纯后端应用，另一套是Web后端应用，他们的区别是Web后端应用比纯后端应用多了一个Controller模块，其它都一样。Archetype的二方库我已经上传到Maven Repo了，可以通过如下命令生成COLA应用：生成纯后端应用（没有Controller） mvnarchetype:generate -DgroupId=com.alibaba.demo -DartifactId=demo -Dversion=1.0.0-SNAPSHOT-Dpackage=com.alibaba.demo-DarchetypeArtifactId=cola-framework-archetype-service-DarchetypeGroupId=com.alibaba.cola -DarchetypeVersion=2.1.0-SNAPSHOT 生成Web后端应用（有Controller） mvn archetype:generate -DgroupId=com.alibaba.demo -DartifactId=demo-Dversion=1.0.0-SNAPSHOT -Dpackage=com.alibaba.demo-DarchetypeArtifactId=cola-framework-archetype-web-DarchetypeGroupId=com.alibaba.cola -DarchetypeVersion=2.1.0-SNAPSHOT 我们假设新建的应用叫demo，那么执行命令后，会看到如下的模块结构，上部分是应用骨架，下部分是COLA框架。在生成的应用里面有一些demo的代码，可以直接用"mvn test"进行测试。如果是Web后端应用，可以运行TestApplication启动Spring Boot容器，然后直接通过REST URL http://localhost:8080/customer?name=Alibaba 访问服务。 COLA 2.0整体架构最后，按照老规矩，还是给两张全局的架构视图。以便你可以从全局上把握COLA。注意：COLA有两层含义，一层含义是作为框架的COLA，主要提供一些应用中所需共用组件的支持。另一层含义是指COLA架构，是指通过COLA Archetype生成的应用骨架的架构。这里所说的架构视图是应用架构视图。依赖视图调用视图参考资料：【1】https://softwareengineering.stackexchange.com/questions/178927/is-there-a-difference-between-a-component-and-a-module?spm=ata.13261165.0.0.12296659zlPIXl 原文发布时间：2020-01-21作者：从码农到工匠本文来自阿里云合作伙伴“阿里技术”，了解相关信息可以关注““阿里技术”。

发表了文章 2020-01-20

百万TPS高吞吐、秒级低延迟，阿里搜索离线平台如何实现？

阿里妹导读：阿里主搜（淘宝天猫搜索）是搜索离线平台非常重要的一个业务，具有数据量大、一对多的表很多、源表的总数多和热点数据等特性。对于将主搜这种逻辑复杂的大数据量应用迁移到搜索离线平台总是不缺少性能的挑战，搜索离线平台经过哪些优化最终实现全量高吞吐、增量低延迟的呢？作者简介：王伟骏，花名鸿历，阿里巴巴搜索推荐事业部高级开发工程师。2016年硕士毕业于南京邮电大学。Apache Hadoop && Flink && Eagle Contributor。目前负责阿里巴巴搜索离线平台Runtime层相关工作。另外，陈华曦（昆仑）给了本文很多建议，文中部分图由李国鼎（石及）贡献。前言在阿里搜索工程体系中我们把搜索引擎、在线算分等ms级响应用户请求的服务称之为“在线”服务；与之相对应的，将各种来源数据转换处理后送入搜索引擎等“在线”服务的系统统称为“离线”系统。搜索离线平台作为搜索引擎的数据提供方，是集团各业务接入搜索的必经之路，也是整个搜索链路上极为重要的一环，离线产出数据的质量和速度直接影响到下游业务的用户体验。搜索离线平台经过多年沉淀，不仅承载了集团内大量搜索业务，在云上也有不少弹外客户，随着平台功能的丰富，Blink（阿里内部版本的Flink）版本的领先。我们在2019年年初开始计划把主搜（淘宝天猫搜索）迁移到搜索离线平台上。主搜在迁移搜索离线平台之前的架构具有架构老化、Blink版本低、运维困难、计算框架不统一等不少缺点，随着老主搜人员流失以及运维难度与日俱增，重构工作早已迫上眉睫。对于将主搜这种逻辑复杂的X亿数据量级应用迁移到搜索离线平台总是不缺少性能的挑战，业务特点与性能要求决定了主搜上平台的过程中每一步都会很艰辛。为了让性能达到要求，我们几乎对每个Blink Job都进行了单独调优，最初的理想与最后的结局都是美好的，但过程却是极其曲折的，本文将主要介绍主搜在迁移搜索离线平台过程中在性能调优方面具体做了哪些尝试。主搜迁移搜索离线平台的完成对于平台来说有里程碑式的意义，代表搜索离线平台有能力承接超大型业务。搜索离线平台基本概念搜索离线平台处理一次主搜全增量主要由同步层和数据处理层组成，它们又分别包括全量和增量流程。为了读者更好理解下文，先简单介绍几个关于搜索离线平台的基本概念。集团内支撑业务目前搜索离线平台在集团内支持了包括主搜，AE在内的几百个业务。其中数据量最大的为淘宝天猫评价业务，数据量达到了X百亿条，每条数据近上X个字段。场景处理用户的数据源（mysql或odps）表，将数据经过一系列的离线处理流程，最终导入到Ha3在线搜索引擎或ES中。平台相关技术栈如下图，搜索离线平台目前数据存储基于HDFS/盘古，资源调度依赖于YARN或Hippo，计算框架统一用Flink/Blink执行。全量全量是指将搜索业务数据全部重新处理生成，并传送给在线引擎，一般是每天一次。这么做有两个原因：有业务数据是Daily更新；引擎需要全量数据来高效的进行索引整理和预处理，提高在线服务效率。全量主要分为同步层与数据处理层。增量增量是指将上游数据源实时发生的数据变化更新到在线引擎中。这也就意味着在我们的场景中对于增量数据不需要保证Exactly Once语义，只需要保证At Least Once语义。基于该背景，我们才能用全链路异步化的思维来解一对多问题（下文会详细讲解）。与全量一样，增量也分为同步层与数据处理层。一对多在搜索这个领域某些业务数据需要用一对多的形式来描述，比如商品宝贝和SKU的关系即是个典型的一对多数据的例子。在搜索离线基于Hologres（阿里巴巴自研分布式数据库）存储的架构中，一对多的数据存储在单独的一张双pk的HoloTable中，第一、二主键分别的宝贝ID与SKU_ID。有了上面这些概念之后，在后续的段落中我们会看到搜索离线平台针对主搜各Blink Job的性能调优，先简要概括下主搜业务特点与性能要求。数据存储方式搜索离线平台以前用HBase做镜像表时，是用一张多列族大宽表来存储业务单维度所有数据。经过详细调研之后，我们决定用Hologres替换HBase，所以需要对存储架构做全面的重构。用多表来模拟HBase中的多列族，单HoloTable中包括很多业务数据源表的数据。重构后的数据存储方式大致如下：同步层所谓同步层，一般是将上游数据源的数据同步到镜像表，供数据处理层高效处理。由于业务方单维度的数据有很多Mysql表或odps表组成，少则X张，多则像主搜这样X张。所以将同纬度数据聚合到一张Holo表中时，如果多张表两两join的话会产生大量shuffle，所以我们采取异步upsert方式，不同数据源表的数据写Holo表中不同的列来解决海量数据导入问题。数据处理层所谓数据处理层，是指将同步层得到的各镜像表（HBase/Holo）的数据进行计算，一般包括多表Join、UDTF等，以方便搜索业务的开发和接入。主搜业务特点与性能要求下面首先介绍下主搜业务特点与性能要求，再详细介绍我们进行了怎样的调优才达到了性能的要求。主搜业务特点 ★ 数据量大主搜有X亿（有效的X亿）个商品，也就是主维度有X亿条数据，相比于平台其他业务（除淘宝评价业务）多出X个数量级。这么多数据我们能否在X个多小时完成全量？如何实现高吞吐？挑战非常大。 ★ 一对多的表很多主搜业务有很多一对多的表需要Join，例如一个商品对应多个SKU，部分商品对应了接近X个SKU信息。这些信息如何能够高性能的转换为商品维度，并与商品信息关联？ ★ 源表的总数多主搜有X多张表（包括一对多的表），平台其他业务的源表个数一般都在个位数。源表数量多会导致一系列的问题，比如读取ODPS数据时如何避免触发ODPS的限制？拉取大表数据时如何做到高吞吐？这些问题都需要我们一一解决。 ★ 热点数据主搜有一些大卖家（饿了么，盒马等）对应了很多商品，导致在数据处理层出现非常严重的数据倾斜等问题。如何解决大数据处理方向经常出现的SKEW？主搜性能要求 ★ 全量（同步层 + 数据处理层）高吞吐！全量要求每天一次，在有限的资源情况下每次处理X亿的商品，这么大的数据量，如何实现高吞吐，挑战非常大！ ★ 增量（同步层 + 数据处理层）低延迟！增量要在Tps为X W的情况下达到秒级低延迟，并且双11期间有部分表（例如XX表）的Tps能达到X W，增量如何保证稳定的低延迟？值得思考！下面一一描述我们是如何解决这些问题来达到性能要求的。 Blink Job性能调优详解根据上述主搜业务特点与性能要求罗列出下图，左边与中间两列表示主搜哪些特点导致某阶段任务性能差。所以我们要对相应阶段Blink Job进行调优，调优完成也就代表着平台能满足图中最右边一列主搜所需要的全量高吞吐与增量低延迟的性能要求。下面按照全量，增量，解一对多问题的脉络来给大家介绍我们是如何解决上述五个问题之后达到全量高吞吐以及增量低延迟的性能要求的。全量高吞吐性能调优全量主要包括同步层与数据处理层，必须实现高吞吐才能让全量在X个多小时之内完成。同步层在短时间内要同步约X张表中的上X亿全量数据，且不影响同时在运行的增量时效性是一个巨大的挑战。数据处理层要在短时间内处理X多亿条数据，Join很多张镜像表，以及UDTF处理，MultiGet等，最后产生全量HDFS文件，优化过程一度让人频临放弃。这里重点介绍数据处理层的性能调优历程。该Job的调优历时较长，尝试方案较多，下面按照时间顺序讲解。 ★ 初始形态首先提一下IC维度为商品维度，UIC维度为卖家维度，并且最开始我们的方案是没有FullDynamicNestedAggregation和IncDynamicNestedAggregation的（后文会详细提到这两个Job）。Scan IC维度单Pk表之后做一系列的DImJoin、UDTF、MultiJoin。在测试过程中发现DimJoin多pk表（一对多表）的数据时，性能非常低下，全链路Async的流程退化成了Sync，原因是我们一对多的数据存在单独的一个SaroTable（对多个HoloTable的逻辑抽象）中，对指定第一pk来取对应所有数据用的是Partial Scan，这是完全Sync的，每Get一次都要创建一个Scanner，虽然我们不但对于DimJoin加了Cache，并且对于主搜特有的MultiGet也加了对于SubKey的精准Cache。但是测试下来发现，性能还是完全得不到满足，所以尝试继续优化。 ★ 引入LocalJoin与SortMergeJoin 由于性能瓶颈是在DimJoin多pk的SaroTable这里，所以我们想办法把这部分去掉。由于一对多的SaroTable只有两个维度具有，所以我们尝试先分别将IC维度与UIC维度的所有表（包括单pk与多pk）进行LocalJoin，结果再进行SortMergeJoin，然后继续别的流程。首先介绍下Local Join。由于HoloStore保证相同DB中所有表都是按照相同的Partition策略，并且都是按照主键字典序排好序的，所以我们可以将同纬度同Partition的数据拉取到一个进程中进行Join，避免了Shuffle，如下图所示。所以拓扑大概变为：经过测试，由于业务上面存在大卖家（一个卖家有很多商品），导致SortMergeJoin之后会有很严重的长尾，如下图所示，Uid为101与103的数据都是落到同一个并发中，我曾经尝试再这个基础之上再加一层PartitionBy nid打散，发现无济于事，因为SortMergeJoin的Sort阶段以及External Shuflle对于大数据量的Task需要多次进行Disk File Merge，所以该长尾Task还是需要很长时间才能Finish。 ★ 加盐打散大卖家所以我们需要继续调优。经过组内讨论我们决定对大卖家进行加盐打散，从ODPS源表中找出Top X的大卖家ID，然后分别在主辅维度Scan + Local Join之后分别加上UDF与UDTF，具体流程图与原理示例见下面两幅图：如上图所示，Uid为101与103的数据被打散到多个并发中了，并且因为我们在SortMergeJoin之后加了UDTF把加的Salt去掉，所以最终数据不会有任何影响。 ★ 最终形态这样全量FullJoin总算完成了，并且性能也勉强达标，所以我们开始调整增量流程（IncJoin），这时发现IncJoin跟FullJoin的初始形态存在一样的问题，追增量非常慢，永远追不上，所以组内讨论之后决定在同步层针对全量新增一个FullDynamicNestedAggregation Job（下文会详细提到），这是一个Blink Batch Job它将各维度一对多的SaroTable数据写到对应维度的主表中，然后在FullJoin最开始Scan时一起Scan出来，这样就避免了DimJoin多pk的SaroTable。最终达到了全量高吞吐的要求，全量FullJoin最终形态如下：增量低延迟性能调优增量性能主要受困于数据处理层IncJoin，该Job最开始是一个Blink Stream Job，主要是从SwiftQueue中读出增量消息再关联各个镜像表中的数据来补全字段，以及对数据进行UDTF处理等，最后将增量消息发往在线引擎SwiftQueue中。基于“流批一体”的思想，经过一系列尝试，我们增量数据处理层Job的最终形态如下。与全量不同的是由于增量是实时更新的，所以更新记录不仅要写到Swift Queue中，还要写入SaroTable中。另外，我们根据业务特点给各个Job分别加了按pk对记录去重的window。解一对多问题主搜有很多一对多的表，在数据处理层如何高效的将数据Get出来转换为主维度之后进行字段补全，困扰我们很久。为了提升效率我们必须想办法提升Cpu利用率。所以Get记录改为全链路异步来实现，由于我们一对多数据存在多pk的HoloTable中，指定第一pk去获取相关数据在Holo服务端是以Scan来实现的。这样由于异步编程的传染性，全链路异步会退化为同步，性能完全不达标。 ★ 解决方法为了将“伪异步”变成真正的全链路异步，经过多次讨论与实践之后，我们决定将一对多表中相同第一pk的多条数据Scan出来GroupBy为一条数据，将每个字段转化为Json之后再Put进主表中，主要步骤如下图所示。我们针对全量与增量在同步层加Job来解决，分别为FullDynamicNestedAggregation（Blink Batch Job）与IncDynamicNestedAggregation（Blink Stream Job），这两个Job大致流程为如下图所示。值得一提的是，正如前文介绍增量时提到的背景，我们的场景中对于增量数据不需要保证Exactly Once语义，只需要保证At Least Once语义。所以基于该背景，我们能够将数据处理层增量Job拆分为两个Job执行，一对多的问题得以解决。这样我们在数据处理层就不需要去Scan HoloTable了，从而可以用全链路异步化的方式来提升增量整体性能。 ★ 截断优化为了避免将多条数据转为一条数据之后由于数据量过大导致FullGC的“大行”问题。基于业务的特性，我们对于每个一对多表在Scan时支持截断功能，对于相同的第一pk记录，只Scan一定条数的记录出来组装为Json，并且可以针对不同的表实现白名单配置。 ★ 加过滤Window优化针对业务的特点，一对多的很多表虽然可以接受一定时间的延迟，但是为了避免对离线系统以及在线BuildService造成太大的冲击，所以更新不能太多，所以我们加了30min的去重窗口，这个窗口作用非常大，平均去重率高达X%以上。结语经过一系列优化，主搜不仅在资源上相对于老架构有不少的节省，而且同时实现全量高吞吐与增量低延迟，并且在2019年度双11 0点应对突增流量时表现的游刃有余。对系统进行性能调优是极其复杂且较精细的工作，非常具有技术挑战性。不仅需要对所选用技术工具（Flink/Blink）熟悉，而且对于业务也必须了解。加window，截断优化，加盐打散大卖家等正是因为业务场景能容忍这些方法所带来的相应缺点才能做的。除了本文提到的调优经验，我们对同步层全增量Job与MultiGet也进行了不少调优，篇幅原因与二八原则这里就不详细介绍了。主搜成功迁移也使得搜索离线平台完成了最后一块拼图，成为阿里巴巴集团搜索中台以及核心链路的基础模块。原文发布时间：2020-01-20作者：鸿历本文来自阿里云合作伙伴“阿里技术”，了解相关信息可以关注“阿里技术”。

发表了文章 2020-01-19

对话阿里云 MVP：跨界半生，不改赤子之心

阿里妹导读：今天，我们走近阿里云 MVP ，对话汇付天下的首席数据官裔隽。我从没想过会用“少年感”来形容一位40+岁的商界人士。裔隽在很多时候像一位人生导师，儒雅随和，不吝于分享自己的人生经验与谆谆教诲，也会在提起项目时难掩兴奋：“我们最近在做一个新业务，蛮好玩的。”隔着电话，我似乎都能看到他眼里有光。投身未知，挑战符合我的个性从心理学到计算机，从新闻主编到首席数据官，于外人看来，我的跨界虽然较大，但整个职业生涯一直有自己的主线。我10岁的时候就对计算机很感兴趣，觉得未来电脑会走进千家万户，一直学习到现在，也始终把它看作一个工具。在90年代初，国外已经有心理学和计算机结合的成果表现，这也是我选择心理学专业的原因之一。大三的时候我还写过一套认知心理学的软件包，毕业论文也是用电脑编程做的心理学实验，包括我当时的导师也让我关注人工智能这方面。现在看来，这条路选对了。大学毕业时，赶上银行信息化的风潮，我想了解银行是如何应用计算机的，于是到了这里。经历了业务转服务器、不联网到联网、网点内外打通、跨银行协作的整个过程，8年时间见证并参与了IT技术之于金融行业的变化，作为从业者深深感受到了科技的力量，也坚定了自己“改变些什么”的想法。 2003年创业汽车网，同时兼任新闻主编，在很多人还不常上网的时代，我们已经在网络上做汽车买卖、配件保养这件事情了。对于IT改变世界这件事，我们始终相信并践行着。在2011年，结合自己感兴趣的IT、金融、互联网，最终选择了汇付天下。我做了很多年的产品，任事业部产品副总。2011-2015年是手机APP崛起的时代，我觉得好玩于是投身其中。从2011年开始开始尝试云计算的内容，包括亚马逊和微软的都用过，直到后来招标遇到阿里云，才仿佛打开了新世界的一扇大门。智能手机改变了应用的发布模式，云计算推翻了旧的基础设施，这些进步让我们不用再费力研究IT,可以聚焦更多资源到业务上。突破自我，保持好奇和危机感这个时代的技术发展日新月异，只有不断学习才能防止被淘汰。一般到了我这个岁数的人，会选择自己熟悉的、稳定的方向。但我是个好奇心和危机感很强的人，坚持不断学习与输入，直到现在我也经常会自己编写代码。动力则是来自于陪伴我少年成长起来的梦想与内驱力。跨界的基础就是不断学习，突破自我，比如目前我所负责的新业务，我再次从后台走向业务，放下身段去倾听市场需求，而这次的跨界之旅也反哺了我专业能力。其实现在全球的高度信息化为学习提供了极大便利，知识获取成本降低很多，但不少年轻人不利用这个优势，我觉得很可惜。大家看一篇文章，5分钟就能明白云计算是什么，但没多少人愿意花3个月去学习人工智能的课程。想要卓越，就不能满足于碎片化的知识快餐，不论什么时代，学本事都是要扎实下功夫的。 4G刚出来的时候大家没想到会改变社会的支付方式，也没预料滴滴和摩拜会影响到全民的出行。云计算催生了Serverless、K8s、云原生这些东西，我们都会迅速跟进、试验学习。当你的客户都在迁移上云，自身不进行数字化转型怎么会有共同语言呢？不光互联网行业，大家都要拥抱内部和外部的变化，保持好奇心和进取心，改变思维模式，才会不被时代的浪潮抛下。薪火相传，用感性平衡技术思维论技术我不算最优秀，也不是最好的管理者，我更喜欢教练的角色，以Coach来定位，传道授业解惑。跟你的学生比技术没有太大意义，教练的存在是为了制定战略与计划，带领团队走向成功。写《企业迁云之路》也是这个目的，当时几乎没有企业视角的上云指南，都是云计算厂商角度的介绍。在摸索一段时间后，我们把自己的方法论汇编出来分享，不仅有技术理念、迁移上云的方法，还有产品测试，甚至复盘总结的内容。凝聚了自己和阿里朋友几十年的经验，它不光是一本技术手册，更是帮助决策者创业者的利器，预测可能出现的问题，提供一些启发。在35岁之后，我才渐渐对当初心理学的内容有所感悟。诸如哲学、心理学、人类学的内容，无法像理工科知识立马解决问题，但会在你认知世界的过程中帮助丰富世界观。现在每年都会读几本心理学的新书，这种真正研究人类规律、描述思考过程的学问，可以帮助你认识自己，更好地与世界沟通。在企业管理中，对于情商、同理心、团队激励等方面也有相当的益处。尤其面对90后甚至00后的新生代员工，需要了解他们精神层面等诉求，这就更像导师的角色了。业余时间我喜欢摄影，发现美的过程使我放松。人生不像代码那样只有0和1、非黑即白，真正的世界和人都是感性的。我很感激心理学，给我提供了更多的视角，也让我离梦想更近。在这里我给年轻人一些建议。首先愿意吃苦，肯沉下心学3个月课程，当然比读5分钟文章的人走得远。其次能受委屈，能力越大责任越大，承担的东西也就越多。最后三观要正，明晰并坚持自己的目标。每天都很努力的人不会有危机感，中年危机都来自于年轻时不够努力，希望大家没有这种危机。阿里云 MVP裔隽像是一直走在时代前沿的探索家，也像是个跃跃欲试的少年，永远年轻，永远热忱，他的征途是星辰大海。 “点击此处”，申请成为阿里云 MVP。原文发布时间：2020-01-19作者：阿里云 MVP本文来自阿里云合作伙伴“阿里技术”，了解相关信息可以关注“阿里技术”。

发表了文章 2020-01-19

入职阿里5年，他如何破解“技术债”？

作为一名技术人，你常常会听到这样的话： “先快速上线”“没时间改”“再缓一缓吧”“以后再解决”“先用临时方案处理”…… 当你埋下的坑越来越多，不知道哪天哪位同学就会踩上一颗雷。特别赞同“人最大的恐惧就是未知，当技术债可说不可见的时候，才是最让人不想解决的时候。” 作为一个程序员，我们反对复制粘贴，但是我们经常会见到相似的代码，相同的二方包，甚至整个代码库复制，似而不同的应用比比皆是。图片来源：https://www.monkeyuser.com/ 当新人加入团队，老人总要顶着新人鄙夷的目光解释：当初是什么原因，才导致系统设计得如此丑陋。一边是产品经理突然心血来潮的需求变动让人暴跳如雷，一边遗留代码和遗留系统让人望而生畏，直到有一天整个崩溃，也不知道锅落谁家。渐渐地，我们学会了用技术债当借口。“之前欠了太多债，所以开发慢”、“历史遗留问题，我也没办法”，后来，我们失去了热爱开发的灵魂，只剩下痛苦而缓慢的完成业务的躯壳。这些背后都是技术债带来的问题。然而，作为程序员的我们，当我们听到《没有理想的人不伤心》中“我不要在失败孤独中死去”，我们还是会热血沸腾，还会想要迎难而上，所以，今天就让我们搞懂技术债，进而搞定技术债。一、技术债是什么? “技术债”是1992年被沃德·坎宁安提出来。在金融领域通过短期的借贷获得充足的资金加快发展，代价就是除了本金之外还要付出利息。软件领域也是一样，为了尽快上线，暂时不顾代码质量，从而欠下技术债。而后续的开发持续降低开发效率，就像还利息一样。经济债务相对容易衡量，只需要计算归还多少本金和利息。而技术债更像不规范的高利贷，不仅不容易衡量，而且很容易陷入无限还债的深渊。我们经常会把代码称之为宝贵的资产，因为技术债在代码层面的普遍存在，所以我们也可以说，代码就是债务。只要你是程序员，可以说你的一生都会被技术债所影响。所以，技术债本身是对项目或者代码质量的重要衡量指标。二、技术债的恶性循环首先，技术债肯定会不断地降低开发效率，每加一个功能都困难重重，进而拖慢业务进度。之后，业务上的挫败感会给程序员自身带来更大的挫败感。就像每天被人上门讨债的负债者，当杨白劳的滋味相信没人喜欢。再之后，团队开始无休无止的争论，新人想要改革，老人害怕风险，每个人固守自己的业务不敢接受升级，N变更带来的N*N的风险，没人愿意承担。在这之后，长期技术不升级导致技术落后，这个团队的技术竞争力下降，每个人都能感受到团队无论是技术能力还是商业价值都在下降，进而导致更大的挫败感。最终，上面这些问题还是会反过来影响业务，影响商业价值，让整个团队陷入恶性循环之中，最怕人才流失，又让新人更难融入。当团队(公司)业务(商业)价值降到最低的时候，也就是宣告解散(破产)的时候。三、技术债是如何产生的？ “复制-粘贴式开发模式。” 技术债的认为感知是有延迟的，就像你在高速上超速开车，直到一周后你收到罚单，才知道自己要付出代价。很多团队不顾后果的复制粘贴，直到体会到业务发展缓慢，但是已经来不及了。 “我们必须马上上线。” 技术界流传最广的三大借口：“我们的领域非常复杂，所以我们有很陡峭的学习曲线”、“我们的情况特殊，所以没办法写单元测试”、“我们时间紧急，必须尽快上线”。首先这些假设从来没被证明过，其次假设“我们时间紧迫，所以必须牺牲质量”成立，但是不代表着“牺牲质量就能赶时间”。最后，在一个必须马上上线的论调充斥的团队中，那些想要做更多重构和更优设计的人会有深深地负罪感，陷入不断创造技术债的怪圈。 “我们暂时赶一下进度，后面再重构。” 如果能够经过合理分析，为了短时间赶工做出一定的牺牲，后面再有计划地重构升级，技术债本身并不一定是全是坏事。但是很多时候这句话成了空头支票，最后，就是变成了上一种恶性循环。 “解决问题的最好办法是写代码。” 我们最喜欢的一句话就是“用代码改变世界”。但是恰恰相反的是，如果能够不写代码就能解决问题，才是最好办法。我们喜欢崇拜代码量，但是无休止的复制黏贴带来的大量代码不但没有价值，反而带来更大的成本。四、如何解决技术债让技术债可衡量是解决技术债的第一步根据观察者效应，将问题暴露出来本身就是一种解决问题的办法。人最大的恐惧就是未知，当技术债可说不可见的时候，才是最让人不想解决的时候。 1、Jarchitect是一款根据一定的规则，评估代码技术债的工具。可以在平时开发中，不断的观察技术债的变化。图片来源：https://www.jarchitect.com/ 2、同时因为很多“复制-粘贴式”代码是跨代码库的，所以评估工具也只能参考，最好能够多仓库横向对比。解决技术债的方案直接宣布破产（整个重写）：下线老的系统，用新的系统替代，很多团队都这么干过。尤其当你接手了一个很老的遗留系统，维护成本高，新特性需求积压严重，用新的系统替代可能是更好的办法向后兼容的不断迁移：新做一个系统兼容老的功能，或者直接在老的系统中直接加入新的流程，在测试用例的保证下，将功能随着业务升级一点一点的迁移，慢慢放弃老的系统，删掉代码，最后完成整个升级，将技术债像手术一样切除掉。最后，请不要再引入技术债可以参考技术债产生的原因，所有的因素都是想法的偏差，只要调整正确的态度，技术债就是可以规避的。五、我在阿里五年的技术债解决经历回想我加入阿里的五年时间，第一个系统就是在做这个系统重写的迁移，老的系统已经严重导致业务发展迟缓，这时候用到的就是“破产清算”，系统重写的方式。后面做另一个系统，随着产品的增多，应用不断增加，最后我们用一个应用承接了所有业务，将老的应用全部下线，做了整个向后兼容的迁移。后记最近读了一篇文章《二十年的编程，教会我的五件事》，发现作者作为一个咨询师的角度在几年的时间内写了很多关于软件项目的文章，其中几篇技术债的文章以我的英语读起来很困难，所以为了搞懂技术债，决定边翻译边学习。本文引用： [1]https://www.monkeyuser.com[2]https://www.jarchitect.com[3]https://daedtech.com/5-things-ive-learned-in-20-years-of-programming 原文发布时间：2020-01-19作者：都铎本文来自阿里云合作伙伴“阿里技术”，了解相关信息可以关注“阿里技术”。

发表了文章 2020-01-16

我要上官网，上云案例征集活动启动啦！提交案例，得大奖！【阿里云】

云产品是什么，公司业务需要上云吗，怎么上云？大量用户对上云不了解，怎么办？看同行业别人怎么上云的！不同行业不同发展阶段的上云案例库将助力千千万万企业和个人0门槛的轻松上云！云栖号正式面向全网发起：阿里云上云案例嘉年华（第一季）- 面向全网收集优质的上云案例和最佳实践。奖品超出你的想象！顶级流量曝光；阿里云大礼包；云栖号案例库专属证书！让你的案例千万人看得到！上云案例和最佳实践是什么？上云案例：你上云的那些故事和经历，内容需包括：基本介绍（公司/个人名称及简介），为什么要上云（业务痛点），怎么上云的（上云方案），上云带来什么价值，上云选用的产品。参考demo：https://yqh.aliyun.com 案例频道最佳实践：就是手把手的上云指南。比如：你如何一步步做的服务器迁移，建站，小程序部署等等。参考demo：https://yqh.aliyun.com 最佳实践频道活动流程及日程 1月15日-2/21日：案例提交，上云案例和最佳实践都可。 2/22-2/23：初审，内容符合活动的要求。 2/24-3/1：终审，通过初审的案例将全部上线云栖号-案例集活动频道，根据用户的实际点击量来最终评选。 3/4：在云栖号频道（yqh.aliyun.com）公布获奖名单。云栖号介绍：阿里云云栖号（https://yqh.aliyun.com）是阿里云官网内容平台，旨在为用户提供第一手的上云资讯，云产品快速入门，来自不同行业精选的企业上云案例，基于众多成功案例萃取而成的最佳实践，助力用户进行上云决策，0门槛更轻松的上云。上云就看云栖号！评选标准初审：内容是否符合比赛基本要求终审：案例对外上线之后，用户的真实点击量决定你的排名，点击量前15名即获奖。通过初审的案例将全部上线云栖号频道-案例集活动频道（yqh.aliyun.com）。一周的时间，所有案例根据用户的实际点击量来决定名次。点击量前5名，一等奖。第6-15名，二等奖。奖品一等奖：5名奖品：顶级流量曝光（云栖号全站，云栖号新媒体矩阵，云栖号社群矩阵，文档中心案例库等）一周时间；云栖号案例库专属证书；阿里云福袋大礼包（阿里云背包；阿里云公仔；机械键盘；蓝牙手环等等神秘惊喜礼物）二等奖：10名奖品：阿里云福袋大礼包（双肩背包；阿里云公仔；罗技键盘；随身音响等等神秘惊喜礼物）；云栖号案例库专属证书提交地址上云案例参考模板：模板下载地址 https://yq.aliyun.com/download/3888上云案例，最佳实践 demo参考：https://yqh.aliyun.com 案例频道，最佳实践频道案例/实践请提交给云栖号邮件组：yunqihao@list.alibaba-inc.com 主办：阿里云官网云栖号（https://yqh.aliyun.com/）; 阿里云文档中心（https://help.aliyun.com/）

发表了文章 2020-01-16

2020 云原生 7 大趋势预测

过去的几年，是云原生技术和理念得到广泛接受的几年。在这个快速发展的领域，预测未来显得尤其困难，但是我们又有着一些坚定的信念，相信以开放创新为支撑的云原生领域会持续重塑软件生命周期，带来不断的价值。 2019，在众多热门技术趋势中，云原生的关注度居高不下，很多开发者都对由此而兴起的一众技术十分追捧，众多企业开始探索云原生架构转型落地。在中国，开发者们经历了从关注“云原生概念”到关注“云原生落地实践”的转变。在筹备阿里云首届云原生实践峰会的过程中，我们展开了对云原生技术的应用和研究领域的探索，邀请了 17 位云原生技术专家从 Serverless、Service Mesh、Kubernetes、边缘计算、容器实例与容器引擎、云原生基础架构、云原生应用开发 7 个发展方向，回顾 2019 云原生领域进展，描绘云原生技术的新十年。 2020 云原生标志性事件预测展望 2020，在云原生技术的应用和研究领域，我们预见会有这些标志性事件。第一，云原生技术关注重心在上移，Serverless 和应用管理重点。过去的几年我们看到，云原生技术重心围绕容器和容器编排。Docker 和 K8s 的成功几乎成了云原生的代名词。很多人说，Kubernetes is becoming boring，这是对于技术的趋势来说。云原生关注重心即将上移：应用的定义和配置、发布和线上的自动化运维，成为开发和运维人员关心的核心内容。阿里巴巴和微软联合推出的 Open Application Model (OAM) 就是这个方向的一个重要项目。作为云原生技术的延伸，无服务器计算（Serverless）将进一步释放云计算的能力，将安全、可靠、可伸缩等需求由基础设施实现，使用户仅需关注业务逻辑而无需关注具体部署和运行，极大地提高应用开发效率，同时这个方式促进了社会分工协作，云厂商可以进一步通过规模化、集约化实现计算成本大幅优化。相信在 2020 会有更多的创新和落地实践在这个领域涌现。第二，云原生技术成为云服务商的创新和竞争力的主阵地。随着以容器为基础的云原生技术被用户广泛接受，可以肯定的预期，容器会很快成为云和用户的基本界面。因此对于云的服务提供商来说，基于容器、微服务、无服务器、服务网格等新型云原生技术的领域，必将是云厂商未来创新和竞争力的主阵地。虚拟化未来 3 年还会是云上资源增量的主体，但是硬件虚拟化加速的裸金属和安全沙箱容器的组合，正在加速企业的上云和容器化过程。云厂商未来技术竞争力的关键，在云传统的优势包括规模、稳定性、成本发挥到极致的前提下，必将通过云原生技术和产品的持续创新来服务客户来获得客户的认可。云原生产品领域将成为云厂商竞争白热化的必争之地。第三，云原生从数据中心走向云边端一体化，将无处不在。云原生技术起源于数据中心内的应用和服务，并在过去几年逐渐扩展到边缘场景甚至端上的计算。相信未来随着 5G/IoT 的快速发展，云边端一体化的云原生技术将深入更多的企业和更丰富场景，将无处不在。第四，云原生将经历企业落地之痛，云原生上云将成为趋势。云的技术发展会领先于企业落地的速度。尽管云原生技术已经被广泛接受，其在企业技术栈的落地仍然需要时间，也面临不少挑战。如容器化过程中改变传统虚拟机模式下的运维习惯，企业传统应用分布式微服务化的改造涉及 re-architecturing 等因素。云原生被企业接受之后，落地的过程需要解决这些挑战。运维管理含有丰富组件并快速演进的云原生的基础设施也对企业 IT 人员的技术技能提出了更高的要求。然而我们相信，云原生技术带来的资源成本降低，研发运维效率提升等巨大价值，会驱动企业迎接这些挑战。在这个过程中，使用云原生上云，基于容器和服务网格等标准界面和混合云方案，将极大的降低迁云复杂度，使企业可以更快迁移到云上标准服务。通过云原生上云最大化使用云的能力，高效的社会分工，使企业聚焦于自身业务发展，相信将成为企业的共识。 2020 云原生 7 大技术领域趋势 1、Serverless 2019，行业中的各大 Serverless 计算平台的能力有了长足进步，变得更加通用。例如通过预留资源完全消除冷启动对延时的影响，使得延时敏感的在线应用也能够使用 Serverless 方式构建。Serverless 生态不断发展。在应用构建，安全，监控报警等方面涌现了很多开源项目和创业公司，工具链越来越成熟。用户对 Serverless 的接受度不断增加。除了互联网等迅速拥抱新技术的行业，传统企业用户也开始采用 Serverless 技术。站在新的一个十年， Serverless 领域将发生如下演进： Serverless 将进一步从偏离线业务进入在线业务。真正的按请求次数计费和从零到一的响应时间是一个天然的矛盾，以 FaaS 为代表的 Serverless 技术一开始都是从对响应时间不敏感的，事件驱动的偏离线业务入手。但是今天我们已经看到，包括 AWS Lambda Provisioned Capacity 和 Azure Functions Premium plan 在内的产品特性，都在让用户稍微付出一点额外的成本以换取更低的响应时间。这对于在线业务来说，无疑是更适合的。 Serverless 不仅是应用或者函数的能力，也会加速推动基础设施和服务 Serverless 化。业务代码托管给 Serverless 平台之后，即能享受到自动弹性，按请求计费能能力。但是如果基础设施和相关服务不具备实时的扩缩容能力，那么对于业务整体来说，就不是弹性的。我们已经看到 AWS 围绕 Lambda 对 VPC 网络、数据库连接池等资源做了大量实时弹性优化，相信其他的厂商也会跟进，进而行业整体会加速基础设施和各类云服务的 Serverless 化。以 Knative 为代表的开源解决方案将得到越来越多的关注。尽管各个云厂商都在大力推广自己的 Serverless 产品，但是开发者普遍还是会担心被厂商绑定，因此具备一定规模的组织会基于开源方案，如 Knative，搭建自己的 Serverless 平台。而一旦某个开源方案成为主流，云厂商就会主动去兼容开源标准并增大社区投入。 Serverless 开发者工具和框架会进一步繁荣。 IDE，问题诊断，持续集成/发布等配套的工具和服务的用户体验会更加完整。我们将看到更多的成功案例和最佳实践。在前端开发等领域将会出现为 Serverless 而生的应用框架，将工程效率发挥到极致。 Java 持续进击，将成为 Serverless 平台主流语言之一。 Serverless 平台要求应用的镜像足够小以能够快速分发，同时要求应用的启动时间极短。虽然在这些方面，Java 和 NodeJS 和 Python 等语言有差距，但是 Java 社区在不断努力。我们看到 Java 通过 Java 9 Modules 以及 GraalVM Native Image 等技术在不断努力“减肥”，主流框架 Spring 也开始拥抱 GraalVM，而新的框架如 Quarkus 和 Micronaut 也在做新的突破。期待 Java 在 Serverless 领域给人焕然一新的感觉。解决 FaaS 状态传递的中间层（加速层）研究或产品有望得到突破。 Serverless 在 Function 场景下未来最大的挑战是 function 之间串联需要状态（state）传递、function 处理需要频繁和外部存储交互等带来的时延放大。传统的架构这些都是在一个程序进程内部处理完毕。解决上述挑战需要可计算中间层（加速层），可计算中间层（加速层）是未来学术研究和产品攻坚发展方向之一。基于 WebAssembly(简称 WASM) 的 FaaS 方案有望出现。 Docker 的创始人之一 Solomon Hykes 曾说，“如果2008年有 WASM 和 WASI，我们当时就没有必要创造 Docker 了”，这句话在一定程度上说明了 WASM 的重要性。虽然当下 WASM 更多作为一种运行在浏览器端的技术被人了解，但是它具备非常优秀的安全隔离能力，极快的启动速度，以及对于超过20种语言的支持，那么为什么不能让它运行在服务端呢？这些技术特性都非常契合 FaaS 的要求。 2、Service Mesh 在 2019 年，Service Mesh 的整体解决方案逐渐显现了寡头垄断的局面。一个解决方案能否得到行业的普遍认可，关键在于其背后的技术团队对分布式应用治理复杂度是否有深刻洞见，以及能否打造一个被所有云厂商都采纳的事实标准。事实标准对于使用 Service Mesh 的客户来说，意味着分布式应用能根据自己的需要在多云和混合云上方便部署。站在新的一个十年， 2020 年 Service Mesh 领域将有如下变化： 2019 Service Mesh 热度持续上升，落地的问题将在 2020 得到解决。 2019 年，Service Mesh 在部分公司如蚂蚁金服迎来大规模的落地，整个业界的热度在持续上升，大大加大了国内公司对于 Service Mesh 的信心，目前几乎每家稍微大一点的互联网公司都已经开始实践 Service Mesh，包括美团、头条、百度等公司。当然，在 2019 年业界落地遇到的各种问题，包括 Sidecar 大规模运维的问题等等，以 OpenKruise/kruise 的为代表的 SidecarSet 虽然已经在做一些努力，但是目前仍然存在升级 Pod 过程过于复杂的问题，这些问题有望在 2020 年得到解决。 Istio 将更加成熟，更加适合大规模集群的落地。 2020 年 Istio 作为控制平面的一种技术实现仍将在 Service Mesh 领域扮演核心角色。Istio 获得业界广泛关注的原因，在于背靠 Google 公司的内部工程实践，以及对工程实践的再思考和重新提炼。Istio 在过去一年的重要工作是完善功能和改善稳定性确保小规模生产可用，在 2020 年随着阿里巴巴采用这一技术实现大规模落地将为 Istio 的规模化运用提供真实的场景，这将使得 Istio 在接下来的一年在支持集群规模的能力上大幅提高。此外，随着探索，Istio 的可运维性和架构的合理性在 2020 年也将迎来积极的变化，其部署和运维的复杂性高等问题将得到解决。Istio 所采纳的 Envoy 开源项目，在新的一年依然保持 Service Mesh 数据平面的事实标准这一领导地位，Istio 和 Envoy 两大开源社区因为紧密协作而更好地推动 Service Mesh 向前演进。 Serivce Mesh on EdgeService 热度持续 Service Mesh & IoT。 2019 年 Serivce Mesh on Edge 的热度在逐渐提升，Edge 本质上要提供更快的响应提升体验。对于 Service Mesh 来说，被从“舒适”的云端下放到 Edge，要解决性能，低资源消耗，安全，高可用等问题，具体 Kernel Bypaasing，Sidecar as Node+WASM，SmartNic 软硬件结合, IoT Identity 结合，secret 保护，低输出成本，非可靠网络环境等，当下看还非常有挑战，这些问题将在 2020 年得到部分解决。 More Than Service Mesh。 Service Mesh 作为解耦应用与基础设施的关键技术，在 2020 年将有更多的产品通过与 Service Mesh 结合去完成 BaaS 化，这除了减少没有必要的重复建设，还使得云产品因为将那些与应用无关的内容剥离出来下沉为基础设施的一部分而加速自身的演进速度，以及给云产品的使用者带去更棒的软件开发和维护体验而加速业务的探索效率和降低探索成本。我们看到 Envoy 也提供了 MySQL、Redis、MongoDB、DynamoDB 的协议支持，能够支持请求解析、请求级统计、失败统计等通用的可观测性特性。后续 Mesh 将继续发展，成为整个网络层面的一个基础设施，用以管控所有应用层面的出/入口流量。展望 2020 年，Service Mesh 将会成为解决异构系统通信、混合云架构等方向上的必备组件，在混合云、新老架构的场景下，Service Mesh 和原有基础设施的结合能力将成为 Service Mesh 落地的关键，比如对于 VM 场景的支持，对于传统服务注册中心的支持等等，相信会有更多的公司通过实践而对 Service Mesh 的价值更有体感，通过创造更多的成功客户故事而加速 Service Mesh 的普及。也许，2020 年将成为 Service Mesh 的普及年。 3、Kubernetes 2019 年，在社区头部参与者的持续推进下，“规模”与“性能”终于成为了 Kubernetes 项目的重要关键词，这不仅真正意义上打通了 Kubernetes 在企业生产环境中大规模落地的最后一公里，也让 Kubernetes 第一次成为了 “双11” 等顶级互联网规模化场景中实实在在的技术主角。站在新的一个十年， 2020 年 Kubernetes 领域将有如下变化： Kubernetes 将成为用户和云计算新的交互界面。随着云原生计算的普及，越来越多的应用负载都部署在 Kubernetes 之上，包括数据库、大数据、AI智能和创新应用，Kubernetes 已成为云原生计算的基石。得益于 Kubernetes 的大规模应用管理能力、多云混合云的支持能力，在 2020 年，Kubernetes 会成为用户和云计算新的交互界面。从架构的角度，Kubernetes 成为了 IaaS 层的控制平面，并进一步推动底层 IaaS（计算、存储、网络）的能力优化，来满足容器带来的一二个数量级的高密度和高动态性要求。 Kubernetes 掌控能力成为企业运维团队的核心技能，并和 AIOPS 相互促进发展。 Kubernetes 的大规模使用是否会带来企业运维人员的失业？实际上，随着越来越多的企业 IT 架构，从 on Kubernetes 到 in Kubernetes，大量的 CRD、自定义 Controller 和服务网格的引入，给 Kubernetes 的稳定性和性能优化带来大量的挑战。Kubernetes 的掌握深度逐渐成为企业运维团队技术能力的重要评估标尺，而企业运维人员的技能也会从自动化向数据化和智能化发展。预测在 2020 年，围绕着 Kubernetes 的 AIOps 会逐渐涌出，来进一步完善 Kubernetes 的成本优化、故障检测和集群优化。而 Kubernetes 等云原生技术也会让 AIOps 不再雾里看花： 1）得益于 Kubernetes 的良好设计，包括声明式API、不可变架构、优雅的扩展机制，可以促进应用发布和运维的操作归一化（Normalization）； 2）结合 GItOps、Tekton、SecOps 等自动化流程的落地，应用的生命周期更加标准化（Standardization）； 3）随着 OpenTelemetry、CloudEvents 等项目的推进，应用可观测性领域在日志、监控、Tracing、事件等领域进一步标准化和融合，使得多指标、根因分析的数据集更加丰富，从而提高 AIOPS 的 AI 层面的准确率和覆盖率。新内核、新硬件助力容器优化 OS 的演进。容器技术经过了多年的发展，从早期的 Docker、rkt、CRI-O 等，到 containerd、Kata Container、gVisor，已经成为 Kubernetes 运行的重要基石。然而无论是 runc 场景的进一步隔离，还是安全容器场景的进一步性能优化，还需要持续的打磨和增强。随着新内核技术包括 CGroup V2、namespace、virtiofs 等的逐步成熟，可以进一步增强容器运行时的能力。另一方面，一些新硬件包括 NPU、MoC、NUMA 等的引入，也给容器和 K8s 调度带来了更多的优化空间和场景。得益于这些能力的加成，为容器场景量身定制的容器优化 OS 成为可能，并会快速发展。容器网络和 Mesh 网络将进一步融合。 Service Mesh 经过多年的市场培育，2020 年将会成为 Service Mesh 技术的普及年。而 Service Mesh 的性能优化也会成为重头戏，一些下沉方案也在选择基于 CNI（容器网络接口）和内核技术进一步优化网络转发性能。而容器网络自身也在逐渐演进，从面向 ip 到面向 Identity，从单容器网络平面到多网络平面，并进一步优化网络转发性能和零可信安全。在 2020 年，我们相信容器网络和 Mesh 网络将进一步融合，在 Network ServiceMesh、NFV等场景进一步集成。 4、边缘计算随着 5G 和万物互联时代的到来，联网智能终端设备数量将急剧增加，传统云计算中心集中存储、计算的模式已经无法满足终端设备对于时效、容量、算力的需求，将云计算的能力下沉到边缘侧、设备侧，并通过中心进行统一交付、运维、管控，将是云计算的重要发展趋势。 IDC 预计，到 2020 年全球将有超过 500 亿的终端与设备联网，超过 40% 的数据要在网络边缘侧进行分析、处理与存储，这对边缘计算提供了充分的场景和想象空间。站在新的一个十年，2020 年边缘计算领域将有如下变化：以 Kubernetes 为基础的云原生技术，经过近几年的高速发展，适用范围、落地场景、技术成熟度等均有了长足发展，其核心价值之一是通过统一的标准实现在任何基础设施上提供和云上一致的功能和体验。将云原生技术和边缘计算相结合，可以快速实现『云-边-端』一体化的应用分发，解决在海量边、端设备上统一完成大规模应用交付、运维、管控的诉求；在安全方面，云原生技术可以提供容器等更加安全的工作负载运行环境，以及流量控制、网络策略等能力，能够有效提升边缘服务和边缘数据的安全性；在边缘网络环境下，基于云原生技术的边缘容器能力，能保证弱网、断网的自治性，提供有效的自恢复能力，同时对复杂的网络接入环境有良好的兼容性；依托云原生领域强大的社区和厂商支持，云原生技术对异构资源的适用性逐步提升，在物联网领域，云原生技术已经能够很好的支持多种 CPU 架构和通信协议，并实现较低的资源占用。目前已经有不少厂商在进行云原生边缘计算的尝试，并有了部分成功案例，相信在 2020 年随着 5G 的快速铺开，云原生边缘计算的发展将大大提速。 5、容器实例与容器引擎在 2019 年的最后一个月 AWS 终于发布了 Fargate for EKS 产品，这也宣告了云上 Kubernetes 使用 Serverless 容器实例作为底层运行时资源的产品形态得到了业界更广泛的认可。通过容器实例作为底层运行实体可以让用户专注于构建自身的业务和服务，无需再配置和管理服务器，摆脱基础设施运维的复杂性。同时通过真正的按需付费和实时扩容来降低用户的使用成本。无论是亚马逊的 Fargate，微软的 ACI 还是阿里云的 ECI，各产品当前在对接 Kubernetes 的具体架构上仍然有分歧，以 Fargate 为代表采用的是透传 Node 信息的方式来提供对 Kubernetes 功能的完整支持；以 ACI/ECI 为代表则采用 virtual kubelet 方式对接 Kubernetes 对容器实例进行管理。但无论采用何种对接方式，容器实例产品的核心依然需要构建在弹性、成本和 Kubernetes 兼容性上。通过弹性实现用户服务的按需实时扩容，用户无需选择实例和集群容量，不需要为额外的服务器预置而付费；通过实时扩容实现真正的按使用资源付费，降低用户的使用成本；Kubernetes 已经成为容器编排领域的事实标准，对 Kubernetes 功能的兼容性决定着容器实例的适用范围。站在新的一个十年，相信在 2020 年容器实例产品会在这三个方面继续改进和完善，持续提升弹性能力，降低用户的使用成本，并不断完善与 Kubernetes 的集成。同时也会有更多的云原生应用迁移到 Kubernetes+ 容器实例上，享受云原生的技术红利。从上述各厂商的同类产品中我们也可以看到此类产品在设计上的共同之处：一个实例对应一个 Pod 对接 Kubernetes 安全容器作为底层容器引擎这其中使用安全容器作为底层容器引擎是各家都很重视的底层基础能力。在 2019 年安全容器技术的隔离性越来越被看重，作为一个隔离层，不仅提升云原生平台的安全性，也对可运维性、服务质量和用户数据保护有显著效果。不过，回归初心，用户选择云原生的本质是容器带来的敏捷性，他们可以快速地调度并启动容器，并且可以灵活地使用资源，这方面安全技术尚不能达到传统容器的水平。不论是 Kata Containers 还是 gVisor，开源安全容器引擎在 2019 年都取得了很多进展，Kata Containers 明确提出了“做面向云原生的虚拟化”作为 2020 年的目标：在沙箱间共享资源，同时保持沙箱边界仍然清晰。即时、动态地按需为沙箱提供资源，而不是像分区那样进行固定的资源分配。主机的用户态工具、VMM、乃至应用的内核联合起来，彼此协同为沙箱中的应用提供服务。在 2020 年，Kata 代表的虚拟化容器会与传统虚拟化渐行渐远而更加“应用中心”，gVisor 为代表的进程级虚拟化也期待更多为应用的优化。我们相信在 2020 年的时候，我们还不会有一个统一的安全容器技术，但展望 21 世纪 20 年代的头几年，我们期待软硬件的共同发展会让主流的容器引擎都具有更好的隔离性。 6、基础架构演进基于 Kubernetes 的 Serverless Infras 架构演进一直是各大云厂商和社区关注的焦点。2019 年 12 月 AWS 在拉斯维加斯召开了一年一度 re:Invent 大会上宣布了 EKS on AWS Fargate 产品正式 GA，这个消息在云市场和社区里掀起了不小的波澜。 EKS on Fargate 提供了标准的 Serverless Infra.的用户体验，即用户购买了 EKS 的服务后，不再需要购买额外的 Infra 云资源（如VM，Nitro），就可以使用原生 K8s API 部署自己的应用，并且支持按量计费。 Serverless Infra.架构使得用户无需关注计算、网络、存储等底层基础设施细节，真正让用户回归到面向POD应用资源部署形态上去；同时管控面与数据面的强隔离能力将会是 Serverless Infra.架构的关键，除了对用户屏蔽底层基础设施细节外，Serverless Infra. 需要提供给用户一个安全可信的租户隔离环境。 2019 年随着经济体全面上云，底层调度系统全面升级到云原生 Kubernetes + 轻量级容器架构演进，并且大规模部署在神龙裸金属实例上；同时基于 kata-container 的安全容器运行时技术趋于成熟，已经具备大规模铺开的条件。站在新的一个十年，预计2020 年，将是经济体全面迈向基础设施 Serverless Infra. 的一年，Serverless Infra.架构将会基于神龙+安全容器架构，通过构建软/硬多租户能力，弹性能力和高度的容器自愈能力，为用户提供极致的安全、稳定、隔离性的用户体验。同时底层资源池共享也能有效提升整体资源利用率，并池后资源互通将会有效降低整体机器成本。 7、应用开发展望 2020，我们认为云原生+智能化将成为下一代研发平台最重要的两个特性，它将进一步降低开发者采纳复杂技术的门槛以及通过工具释放生产力。当所有复杂度都卸载到云上以后，我们将回到 10 年前开发单机程序时的高效。站在新的一个十年， 2020 应用开发领域将发生如下演进：从 Web-IDE 演进为 Cloud-Native IDE 2019 年是 VS Code 生态继续高歌猛进的一年，得益于其模块化的设计，VS Code 中的几个核心组件Monaco编辑器，插件体系，Language Server Protocol(LSP)等成为了Web-IDE的标准选型。社区也出现了code-server这样基于 VS Code 一行命令拉起 Web-IDE 的方案。除了 VS Code 之外，Theia 也继续演进，尤其是基于 Theia 的gitpod.io 让人眼前一亮，通过把 gitpod 按钮集成在诸如 GitHub README 页面上，一键实现了从代码到预览的顺滑体验。另一方面，大厂已有的 Web-IDE 方案也需要回过头来拥抱社区，彻底如 Facebook 完全从自研的Nuclide 转而投向 VS Code，而无论是 Amazon的Cloud9 还是 Google 尚未对外的 Cider，如果要在商业化上更进一步，支持 VS Code 的插件体系想必也是理所当然。从 Local-IDE 到 Web-IDE 让我想起了当年从 PC 到移动端。虽说时至今日，不少专业工具 PC 端的体验仍然是移动端难以企及的，但移动端的主导地位早已不容置疑。 Web-IDE 具备开箱即用，环境一致可控以及和其它Web服务无缝集成的先天优势。接下来要做的除了继续补齐和 Local-IDE 在端功能的差距外，还可以结合分布式编译构建，集中式代码仓库，海量代码索引分析，云端协同等，提供真正的 Cloud-Native IDE。工具 -> 平台 -> 标准 GitHub 今年推出了 GitHub Actions，通过它可以在工作流中灵活地集成各种第三方服务。GitLab 也在更早的时候就推出了可定制化的 CI 流水线配置。无论是 GitHub 还是 GitLab，它们都从早期单纯的代码托管工具成长为了一站式 DevOps 平台。最早以 IntelliJ 工具起家的 JetBrains 不再满足于仅仅打磨 IDE，今年也推出了 Space，力图打造一站式研发团队平台。以项管工具 Jira 起家的 Atlassian，一直是自研收购两架马车并驾齐驱，今年通过收购又在自己研发平台的版图上增加了针对管理者视角的 Jira Align。后起之秀如 sourcegraph 干脆直接在网站上号称自己是 The new standard developer platform。不管是基于 Dev 工具的右移，抑或是基于 Ops 工具的左移，当年的工具们都或多或少地长成所谓的一站式 DevOps/DevSecOps 平台。那接下来，在这些平台之上是否能提炼出通用的标准？比如 CI 领域，是否能有一套 CI 流水线定义可以一统CircleCI，GitLab，GitHub Actions 诸如此类？是否也有一套 workflow 标准可以让用户在 AWS Step Functions, Argo, Tekton 之间无缝迁移？在更高的抽象层面，诸如 Open Appliction Model(OAM) 这样的标准是不是能真正架起从业务架构到基础架构的桥梁。虽然如今的研发平台已然是诸侯割据的局面，但在云原生，标准先行的理念下，我还是会期待有离业务层更接近的云原生标准去串联起整个研发平台。开发者工具从本地工作到云端协作当前的开发者工具绝大多数采用的是 lift and shift 的方式从本地平移上云，产品设计针对的还是单人人机交互，移到云端的研发工具还没有很好地利用云端多人实时交互的能力。无论是多人协作（云已经让我们离彼此更近），还是人机协作（云已经让机器变得更强），我期待着出现进一步挖掘云端协作能力的创新点。更多云原生研发平台涌现以 Kubernetes、Serverless、Service Mesh、Cloud IDE 为代表的多项云原生技术在过去一年让人印象深刻。我们意外的观察到，以中小互联网公司为代表的技术群体开始快速拥抱这个技术体系，并且通过云原生落地，快速的获得了以往互联网大厂才有的精英软件交付能力，比如复杂的流量治理能力，灰度发布能力，A/B Test 能力，多环境管理能力，基础设施一键拉起，快速扩缩能力等等。但在企业采纳新技术的同时，也面临着诸多挑战，比如开源软件复杂的搭建过程，黑屏化的交互设计，缺乏研发管理方法，缺乏企业权限管理能力等。因此一大批软件供应商开始基于云原生技术体系开发相关的管理平台，比如 QingCloud，Rancher，阿里云容器服务。作为云上研发协同平台领导者的云效也在积极将 CICD 工具、测试环境管理方法、应用运维理念、DevOps 协同方法论等与云原生技术融合贯通，为企业提供开箱即用的新技术解决方案。数据和智能的工具时代到来云原生是一套开放标准的技术体系，核心贡献者就是当今世界的互联网云厂商巨头企业。随着技术的发展和影响力的增强，逐步将企业的私有技术壁垒打破，并且开始采纳云上现成的云原生产品来改造自身的技术体系。技术的收敛带来了统一数据规范的可能，而数据是所有智能化的基石。我们观察到最近一年 AWS、微软、Facebook、ebay 等厂商都在积极布局智能化工具，从传统的“代码”智能工具逐步扩展到“服务”智能工具。比如最近 AWS 发布的CodeGuru，它是一个用于代码审查自动化和性能优化推荐的机器学习服务。它能找出最影响程序性能的代码行，并让提供修复或改进代码的具体建议。这就是代码大数据和运行时服务大数据结合的智能工具。 2020 如何兑现新技术给业务带去的价值对于云原生从业者来说，2020 年最大的挑战可能是兑现新技术给业务带去的价值。虽说过去一年对云原生的价值有不同层次、不同视角的解读，但更多还是从技术层面，鲜有各行各业的客户成功案例阐述新技术所带来的直接业务价值。从市场的角度：仍存在大量的传统行业的企业处于物理机或虚拟机时代，受资产状况的影响他们很难一下子将核心业务搬迁到云原生之上而体会到新技术的巨大价值；另一方面，对于早已进入容器时代的那些企业，他们在软件资产上过去多年持续地投入了大量的资源做建设，从功能层面早已建立起了与云原生等同的软件资产，不会很快从自建转变为云原生。这是市场面对新技术普及之前的正常姿态，行业客户从两端正在被改变，今天大家正逐步对云原生这一概念达成有具象的共识。站在新的一个十年起点，云原生从业者应当坚定自己对于新技术价值的理解和洞察，沉下心去将云原生的基础能力建设好。同时，需要特别重视以合适的方式和时机去兑现业务价值，通过更多的成功客户故事去加速市场对新技术的接受，让自己的成果更快、更好地被市场认可，创造行业趋势，为云计算的发展做出自己的贡献。原文发布时间：2020-01-16作者：叔同、谷朴、不瞋、育睿、许晓斌至简、典违、鲁直、改之、小剑、汤志敏白慕、循环、文卿，喽哥、水鸟、神秀本文来自阿里云合作伙伴“阿里技术”，了解相关信息可以关注“阿里技术”。

发表了文章 2020-01-15

10年后，阿里给千万开源人写了一封信

阿里妹导读：年末将至，阿里巴巴开源技术委员会负责人贾扬清写了一封信，想要和热爱开源的你说一声：谢谢。未来，我们希望与更多开源人一起，用技术普惠世界。阿里巴巴开源技术委员会负责人贾扬清当我们回想起为什么做开源的时候，也许理由都没有那么的高大上：也许就是单纯想分享一下代码，也许就是觉得社区很有意思，甚至也许不知道什么原因，代码放出去了，有人用了，于是我们开始开心地找同路人。逐渐地，我们发现，开源变成了我们的一个共同的信仰：我们喜欢它，我们用心呵护它，然后我们希望更多的人加入一起培养它。在这样朴素的想法下，我们逐渐发现，这一群人发明了在互联网时代最好的大规模协作方式，也创造了技术最大的公约数。无关语言和肤色，开放分享、平等普惠的开源精神有效地弥补了技术代差，推动了这个时代不断前进。 2010年夏天，阿里工程师在杭州开源了第一个项目。10年之后，阿里开源项目数已超过一千个，覆盖大数据、云原生、AI 、数据库、中间件、硬件等多个领域，全世界有七十多万朋友为我们点亮 GitHub Star，成千上万的人参与到项目贡献中。阿里开源取得的这一点小成绩，来自全球开发者的贡献与信任：早在2017年，OpenMessaging 成为首个由中国发起的分布式计算领域国际标准，这是我们共同的成就。过去的10年里，阿里也是与社区合作最为紧密的中国公司之一，受邀成为十多个国内外开源基金会成员，积极贡献开源：不仅是 Java 全球管理组织 JCP 最高执行委员会的唯一中国代表，也是 Linux、RISC-V、Hyperledger、MariaDB、OCI 等多个基金会的重要成员。至今有四个顶级项目捐赠至 Apache，超10个项目进入 CNCF Landscape。我们相信，社区是开源协作精神与创新的摇篮。与社区共建开源，我们坚定不移。2019年双11核心系统100%上云，Apache Flink 突破了实时计算消息处理峰值25亿条/秒的记录，技术架构愈加成熟。我们的大数据工程师们和业界的朋友们建立了紧密的联系，成为了工作和生活中的好朋友，通过紧密的合作，让越来越多的企业使用 ApacheFlink 建设新一代的大数据流处理平台。 GitHub 2019年度报告显示，在全球4000万用户中，中国贡献者数目已升至第二。开源已成为中国技术的一张亮眼国际名片。海德堡大学的一位法学研究生“酷巴”，用 Ant Design 开发了一套漂亮的法律文书管理系统，已成为很多当地律师的得力助手。各种成就的背后，离不开每一个开发者的耕耘和创造。我们经常发现，当各种喧嚣归于平静，当各种繁华归于平淡，我们的工程师们都依然不变初心，在追求着自己的梦想：通过代码这一种最直接的语言，通过开源这一种最简单的方式，寻找着技术路上的下一个突破点，寻找着技术对于社会创造的更多价值。开源是开发者最大的同心圆，未来，我们希望与更多开源人一起，用技术普惠世界。十年牧码，初心未改。感谢所有开源路上的同行人。阿里巴巴开源技术委员会负责人贾扬清2020年1月14日附上阿里十年开源小结，看看我们一起走过的路。阿里开源就看这里阿里开源知多少？“点击此处”阿里开源等你了解。原文发布时间：2020-01-14作者：贾扬清本文来自阿里云合作伙伴“阿里技术”，了解相关信息可以关注“阿里技术”。

发表了文章 2020-01-13

如何打造“智能助理”？阿里对话开发平台这样做

阿里妹导读：一个合格的智能助理能够帮你预约开会时间，处理日常办公需求，还能打电话提醒你要还信用卡了，作为用户或者消费者，我们已经越来越习惯对话机器人提供的各色服务。但对于企业来讲，搭建提供这些服务的对话机器人是一件门槛及成本都很高的事情。阿里巴巴达摩院小蜜Conversational AI团队的高级算法专家李永彬（水德）为我们带来了分享——小蜜智能对话开发平台，围绕平台来源、设计理念、核心技术、业务落地四大维度讲述了如何赋能各行各业开发自己的对话机器人。平台由来为什么要做一个平台？我觉得还是从一个具体的任务型对话的例子说起，在我们日常工作中，一个很高频的场景就是要约一个会议，看一下我们内部的办公助理是怎么来实现约会议的：我说“帮我约一个会议”，它会问“你是哪一天开会？”，跟它说是“后天下午三点”，接下来它又会问“你跟谁一起开会啊？”，我会把我想约的人告诉它，这个时候它在后台发起一次服务调用，因为它要去后台拿到所有参会者的日程安排，看一下在我说的这个时间有没有共同的空闲时间，如果没有的话它会给我推荐几个时间段。由于我说的那个时间段大家没有共同的空闲时间，于是我改了时间。我说“上午十一点吧”，它会接着问，“你会持续多长时间”，我会告诉它“一个小时”，它再问“会议的主题是什么”，于是，我跟它说“我们讨论一下下周的上线计划”，到此为止它把所有的信息收集全了，最后，它会给我一个 summary，让我确认是不是要发送会议邀约，我回复确认以后，它在后台就会调用我们的邮件系统，把整个会议邀约发出来。这是一个非常典型的任务型的对话，它满足两个条件，第一，它有一个明确的目标；第二，它通过多轮对话交互来达成这个目标。像这样的任务型对话在整个办公行业里面，除了约会议以外还有查考勤、请假、定会议室或者日程安排等等。如果我们把视野再放大一点的话，再看一下电商行业，电商行业里面就会涉及到开发票、催发货、查物流、改地址、收快递等等，也会涉及到很多很多的这样的任务型对话场景；视野再放大一下，我们再看一下电信行业或者整个运营商的行业里面，会有查话费、查流量、买套餐、报故障或者是进行密码的更改服务等，也会有大量的这种任务型的对话场景。如果我们再一步去看的话，像政务、金融、教育、文娱、健康、旅游等，在各行各业的各种场景里面我们都会发现这种任务型的对话，它是一种刚需，是一种普遍性的存在。所有的这些场景落地到我们小蜜家族的时候，是通过刚刚介绍过的三大小蜜来承载：阿里小蜜、店小蜜和云小蜜。我们不可能给每一个行业里面的每一个场景去定制一个对话流程，所以我们就沿用了阿里巴巴一贯做平台的思路，这也是我们整个智能对话开发平台的由来。这款产品在内部的名字叫对话工厂（Dialog Studio）。以上主要是给大家介绍我们为什么要做智能对话开发平台，总结起来就是我们目前面临的业务，面临的场景太宽泛了，不可能铺那么多人去把所有的场景都定制化，所以我们需要有一个平台来让开发者进来开发各行各业的各种场景对话。设计理念再看第二部分，对话工厂的一些核心设计理念。整个设计理念这块我觉得概括起来就是“一个中心，三个原则”。一个中心就是以对话为中心，这句话大家可能觉得有点莫名其妙，你做对话的，为何还要强调以对话为中心呢？这是有来源的，因为在过去几年全世界范围的技术实践以及直到今天很多巨头的对话平台里面，我们能看到的基本还是以意图为中心的设计模式，它把意图平铺在这里，比如你想完成音乐领域的一些事情，可是你看到的其实是一堆平铺的意图列表，完全看不出对话在哪里。我们在这次对话工厂的设计中彻底把它扭转回来，对话就是要以对话为中心，你在我们的产品界面里面看到的不再是一个个孤立的意图，而是关联在一起的、有业务逻辑关系的对话流程。以意图为中心的设计中，你看到的其实是一个局部视角，就只能实现一些简单的任务，比如控制一个灯，讲个笑话，或者查个天气，如果你想实现一个复杂的任务，比如开一个发票，或者去 10086 里开通一个套餐，它其实是较难实现，很难维护的。我们把整个理念转换一下，回到以对话为中心以后，就会看到全局视野，可以去做复杂的任务，可以去做无限的场景。整个对话工厂刚刚也说过了，它是一个平台，要做一个平台就会遇到很多挑战。第一个挑战就是对用户来说，希望使用门槛越低越好；第二个挑战是要面对各行各业的各种场景，就要求能做到灵活定制；第三个挑战是上线以后所有的用户肯定都希望你的机器人，你的对话系统能够越用越好，而不是停留在某一个水平就不动了。这就是我们平台所面临的三大挑战。为了应对这三个挑战，我们提出了在整个平台的设计以及实现过程中始终要遵循三个原则。第一个原则是冷启动要快，其实就是要让用户的使用门槛低一点；第二个原则是要有灵活定制的能力，只有这样才能满足各行各业的各种场景需求；第三个是要有鲁棒进化的能力，就是模型上线以后，随着时间的变化，随着各种数据的不断回流，模型效果要不断提升。这三个原则里面，冷启动这一块，其实就是要把用户用到的各种能力和各种数据都尽量变成一种预置的能力，简单来说就是平台方做得越多，用户就做得越少；第二块关于灵活定制，就要求我们把整个对话平台的基础元素进行高度抽象，你抽象的越好就意味着你平台的适应能力越好，就像是经典力学只要三条定律就够了；第三块就是鲁棒进化，这一块就是要在模型和算法上做深度了，语言理解的模型，对话管理的模型，数据闭环，主动学习，在这些方面能够做出深度来。以上说的都是一些理念和原则，接下来给大家介绍一下具体在实现过程中是怎么来做的。核心技术讲到技术这块的话，因为我们做的是一个平台，涉及到的技术非常广，是全栈的技术，从算法到工程到前端到交互所有的技术都会涉及到。我摘取里面算法的核心部分来给大家做一个介绍。对话工厂首先是用来做对话的，人机对话有两个主体，一个是人，一个是机器，人有人的逻辑，人的逻辑使用什么来表达呢？到今天为止主要还是通过语言，所以我们需要有一个语言理解的服务来承载这一块；机器有机器的逻辑，机器的逻辑到今天为止还是通过代码来表达的，所以我们需要一个函数计算的服务；在人和机器对话的过程中，这种对话过程需要有效的管理，所以我们需要一个对话管理模块。整个对话工厂最核心的三个模块就是语言理解、对话管理和函数计算。第一个模块是语言理解。我们先看一下这个图，在整个这个图里面，横轴是意图的多样性，纵轴是频次，这样说有点抽象，我举一个具体的例子，比如说我要开发票，这是一个意图，如果去采样十万条这个意图的用户说法作为样本，把这些说法做一个频率统计，可能排在第一位的就是三个字“开发票”，它可能出现了两万次，另外排在第二位可能是“开张发票”，它可能出现了八千次，这些都是一些高频的说法，还有一些说法说的很长，比如“昨天我在你们商铺买了一条红色的裙子，你帮我开个发票呗”，这种带着前因后果的句式，在整个说法里面是比较长尾的，可能只出现了一次或两次。我们统计完以后，整个意图的说法的多样性分布符合幂律分布。这种特征可以让我们在技术上进行有效的针对性设计，首先针对这种高频的部分，我们可以上一些规则，比如上下文无关文法，可以比较好的 cover 这一块，但是基于规则的方法，大家也知道，规则是没有泛化能力的，所以这时候要上一个匹配模型，计算一个相似度来辅助规则，这两块结合在一起就可以把我们高频确定性的部分解决的比较好；对于长尾的多样性的这一部分，基本到今天为止还是上有监督的分类模型，去收集或者去标注很多数据，把这一块做好；在规则和分类模型之间，我们又做了一部分工作，就是迁移学习模型，为什么要引入这个模型呢？我们看下一张图。在冷启动阶段，用户在录入样本的时候，不会录入太多，可能录入十几条几十条就已经很多了，这个时候按照刚才那个幂律分布，二八原则的话，它的效果的话可能也就是 70% 多，它不可能再高了。但对于用户的期望来说，如果想要上线，想要很好的满足他的用户需求，其实是想要模型效果在 90% 以上，如果想要达到这个效果，就需要复杂的模型，需要标注大量数据。所以其实是存在一个 gap 的，我们引入了迁移学习模型。具体来说，我们把胶囊网络引进来和 few-shot learning 结合在一起，提出了一个网络结构叫 Induction Network，就是归纳网络。整个网络结构有三层，一层是 Encoder层，第二层是 Induction，归纳层，第三层是 Relation 层。第一层负责将每一个类的每一个样本进行编码，编码成一个向量；第二层是最核心的一层，也就是归纳层，这里面利用胶囊网络的一些方法，把同一个类的多个向量归纳成一个向量；然后第三层 Relation 层把用户新来的一句话和每一个类的归纳向量进行关系计算，输出他们的相似性打分。如果我们想要一个分类结果就输出一个 One-hot，如果不想要 One-hot，就输出一个关系的 Relation score，这是整个 Induction network 的网络结构。这个网络结构提出来以后，在学术圈里面关于 few-shot learning 的数据集上，我们以比较大的提升幅度做到了 state-of-the-art 的效果，目前是最好的，同时我们将整个网络结构上线到了我们的产品里面，这是语言理解。第二块我们看对话管理。对话管理其实我刚刚也说过了，如果想要让平台有足够的适应性的话，那么它的抽象能力一定要好。对话管理是做什么的？对话管理就是管理对话的，那么对话是什么呢？对话的最小单位就是一轮，一个 turn，我们进去看的话，一个 turn 又分为两部分，一个叫对话输入，一个叫对话输出；在输入和输出中间，有一个对话处理的过程，就像两个人互相交流一样，我问你答，但其实你在答之前是有一个思考过程的，如果你不思考就回答，那你的答案就是没有质量的，所以就会有一个中间的对话处理过程。我们把对话抽象到这种程度以后，整个平台就三个节点，一个叫触发节点，一个叫函数节点，一个叫回复节点。触发节点是和用户的对话输入对着的，函数节点是和对话处理对着的，回复节点是和对话输出对着的。有了这一层抽象以后，无论你是什么行业的什么场景，什么样的对话流程，都可以通过这三个节点通过连线把你的业务流画出来。举两个例子，先看一个简单的，你要查一个天气，很简单，先来一个触发节点，把天气流程触发起来，中间有两个函数节点，一个是调中央气象台的接口，把结果拿过来，另一个是对结果进行一次解析和封装，以一个用户可读的形式通过回复节点回复给用户。这里面稍微解释一下就是增加了一个填槽节点，填槽节点是什么意思呢？就是在任务型对话里面，几乎所有的任务都需要收集用户的信息，比如你要查天气，就需要问时间是哪一天的，地点是什么地方的，这样就叫做填槽，填槽因为太常用太普遍了，就符合我们冷启动快里面做预置的思想，所以通过三个基础节点，我们自己把它搭建成填槽的一个模板，需要填槽的时候从页面上拖一个填槽节点出来就可以了。我们再看一个复杂的场景，这是在线教育里面的一个外呼场景，家里有小孩的可能知道，这种在线教育特别火，在上课之前半小时，机器人就会主动给用户打电话，指导软件下载，指导怎么登陆，登陆进去以后怎么进入教室，所有的这些流程都可以通过机器人进行引导。通过这两个例子我们就可以看到，无论是简单还是复杂的场景，通过这三种抽象节点的连线都可以实现。有时候我们开玩笑就会说，整个这种连线就叫一生二，二生三，三生万千对话。讲了抽象以后，再看一下具体的对话管理技术。从实现上来说，这张图和大家刚才看到的语言理解那张是一模一样的，因为很多东西的分布其实是遵循着共同规律的，区别在与把意图换成了对话。举一个例子，比如像查天气这样的，如果采集十万个查天气的样本，对这些用户的说法进行一个频率统计的话，大概就是这样一个曲线，用两步能够完成的，比如说查天气，先填槽一个时间再填槽一个地点，然后返回一个结果，通过这种流程来完成的，可能有两万次；中间可能会引入一些问 A 答 B 的情况，这样的 B 可能有各种各样的，就跑到长尾上来了，这样整个对话其实也遵循一个幂律分布。对于高频确定的部分，可以用状态机进行解决，但状态机同样面临一个问题，它没有一个很好的容错能力，当问 A 答 B 的时候，机器不知道下面怎么接了。在这种情况下，需要引入一个类人能力，对状态机的能力进行补充，状态机加上类人能力以后，基本上可以把高频的对话比较好的解决了。对于长尾上的对话，目前对于整个学术界或者工业界都是一个难题，比较好的解决方式就是上线以后引入在线交互学习，不断跟用户在对话过程中学习对话。在状态机和在线交互学习之间其实是有 gap 的，因为状态机自己没有学习能力，所以需要引入增强学习。接下来我会介绍在类人能力以及增强学习方面的一些工作。先看一下类人能力。我们把人说的话，做一下分类大概可以分为三种：第一种就是用户说的话清晰明了只有一个意思，这种其实对机器来说是可理解的；第二种机器压根儿不知道在说啥，也就是 unknown 的；还有一种就是用户表达的意思可以理解，但是有歧义，有可能包含着两个意图、三个意图，就是uncertain，不确定的。确定性的，状态机其实是可以很好地捕捉和描述的，类人能力主要关注拒识的和不确定性的。对于拒识这块，比如还是在线英语的这个例子，机器人打来一个电话，问现在方不方便调试设备，这个时候从设计的角度来说希望用户回答方便或者不方便就OK了，但是一旦这个用户回答了一个比较个性化的话，比如，“呃，我刚扫完地，过会儿可能有人要来”，这时候我们的语言理解模块很难捕捉到这是什么语义，这时候需要引入一个个性化的拒识，比如说，“您好，不好意思，刚才没听明白，请问您现在是否方便调试，如果您不方便，我过会儿再给您打过来”，这个就是对话的兜底，是对 unknown 的处理。第二个我们看一下澄清，用户说的一句话里面，如果是模糊不清的怎么办？我们通过大量的数据分析发现这种模糊不清主要出现在两种情况下，一种是用户把多个意图杂糅在一段话里来表达；第二种是用户在表达一个意图之前做了很长的铺垫，对于这两种长句子现在的语言理解给出的是意图的概率分布，我们把这个概率分布放到对话管理模块以后就需要让用户进行一轮澄清。比如这个例子，这是移动领域的一个例子，这句话理解有三种意图，到底是想问花费明细，还是套餐的事情还是想问合约的低保，把这三个问题抛给用户进行澄清就可以了。从技术上来说是怎么实现的呢，我们看一下这个图，开发者负责把对话流程用流程图清晰描述出来，然后像澄清这种其实是我们系统的一种内置能力，什么时候澄清是通过下端的这两个引擎里面的能力来决定的，第一块是 Error Detection，它用来检测用户当前说的这句话是否需要触发澄清，一旦它觉得要触发澄清，就会交给下一个模块，究竟用什么样的方式澄清以及怎么生成澄清的话术，这是目前我们整个智能澄清这块做的工作。再看一下我们在增强学习方面的工作。在对话管理模型里面，经典的分成两个模块，一个是 neural belief tracker，用来做对话状态追踪的，另一个是 policy network，用来做行为决策的。在整个框架下，要去训练这个网络的时候，有两种训练方式，一种是端到端的去训练，用增强学习去训练，但这种方式一般它的收敛速度会比较慢，训练出的结果也不好；另外一种方式是先分别做预训练，这个时候用监督学习训练就好了，不用增强学习训练，训练完以后再用增强学习对监督学习预训练的模型进行调优就可以了。无论是端到端的一步训练还是先预训练再调优，只要涉及增强学习这一块，都需要有一个外部环境，所以在我们的实现架构里面，引入了模拟器的概念，就是user simulator。模拟器这主要分为三大块，一个是 user model，用来模拟人的行为的；第二个是 error model，模拟完人的行为以后经过 error model 引入一个错误扰动，用 user model 产出的只是一个概率为 1 的东西，它对网络训练是不够好的，error model 会对这个结果进行扰动并给他引进几个其他的结果，并且把概率分布进行重新计算一下，这样训练出的模型在扩展能力或者泛化能力上会更好一些；第三个模块是 reward model，用来提供 reward 值。这是我们今天在整个增强学习的对话管理这块的一些工作。最后看一下函数计算。函数计算是什么东西呢？还是举一个例子吧，比如说，10086 里面用户说要查一下话费，10086 那边的机器人就会回复一句是发短信还是播放语音，表面看来就是简单的一入一出，其实在这背后要经过多轮的服务查询，才能完成这个结果，因为当要查话费的时候，先要经过函数计算查一下现在是哪一天，如果是下账期的话是不能查话费的，就是每个月的最后一天不能查话费，如果可以查话费的话，先看一下用户是否存在话费，如果存在花费的话第三步调用的服务看是不是停机了，因为停机了的话只能语音播报不能接收短信。所以看一下在一个简单的一入一出的对话背后，是走了一个复杂的流程的，这些流程今天都是在机器端用代码来实现的。函数计算的引入，使对话工厂可以去处理复杂的任务。业务应用最后我们看一下对话工厂的业务应用情况。这是我们在浙江上线的 114 移车，当有市民举报违规停车挡路后，就会自动打一个电话让他移车。第二个是在金融领域里面关于贷款催收的例子。在刚刚过去的双十一里面，对话工厂在整个电商里面也有大量应用，主要是在店小蜜和阿里小蜜里面。店小蜜主要是一些开发票、催发货、改地址这样的流程，这里是一个开发票的例子，用户可能会先说一个开发票，进来以后要进行复杂的流程，一种是在说的时候其实他已经把它的订单号送进来了，如果没有说订单号的话需要去后台系统查订单号，查出来以后弹一个订单选择器选择订单，接下来如果是个人发票就走这个流程，如果是公司发票走另一个流程，接下来会问是普通发票还是增值税发票，如果是普通发票接着往这儿走，如果是增值税发票需要获取企业增值税的税号，最后汇总到一个节点，调用后台开发票的系统，把发票开出来。这是这次双十一里面用到的开发票的一个例子。阿里小蜜主要是负责阿里巴巴集团内部各个 BU 的业务，手淘是一个最大的业务，进入手机淘宝以后，进入“我的”里面有一个客服小蜜，就是阿里小蜜；上个月我们刚刚在优酷上线了优酷小蜜，星巴克是 9 月份上的，是属于新零售的一个最大的尝试点，还有很多其他的场景。在钉钉上，通过智能工作助理，对话工厂为千万企业提供智能考勤、智能人事等对话服务。最后看一下我们整体的落地情况。目前整个对话工厂在阿里巴巴经济体内部各业务（如淘宝、优酷、盒马等）、淘宝天猫上的商家、钉钉千万量级的企业、公有云企业、私有云重点行业（政务行业、运营商行业、金融行业等）、国际化（东南亚新加坡、印尼、越南、泰国、菲律宾、马来西亚等6国）等业务中开始大规模应用，赋能各行各业开发者自主构建对话机器人。原文发布时间：2020-01-13作者：李永彬本文来自阿里云合作伙伴“阿里技术”，了解相关信息可以关注“阿里技术”。

发表了文章 2020-01-09

如何快速上手 AB Testing ？阿里技术专家秘方公开

阿里妹导读：A/B 相信大家都或多或少做过，但是你对 A/B 测试的了解有多少，A/B 仅仅是分流吗？怎么样才是科学的 A/B 实验。下面阿里前端技术专家会结合最近的一些学习，系统性和通俗性地说一说 A/B Testing，希望对大家有所帮助。什么是 A/B Testing？关于A/B 有很多层的定义，通俗来说，A/B 是一种工具，通过分隔 A 和 B 两个版本，统计数据，进而看哪个版本的数据效果更好，对产品目标更有帮助。在这里我更多想从 A/B 本身的意义来说一下它的定义。以我们的业务迭代为例，我们会定义产品的业务数据指标（这些指标通常是可以直接和间接反映我们的业务目标的），然后我们在业务迭代中不断提出假设，期望通过做这些假设的改变来提升相对应的业务指标。而在这里A/B 就是用来衡量我们提出的业务改进假设是否有效的一种方法，从统计学意义上说是一类假设验证的方法。我觉得这样定义的好处是，A/B 不仅仅是一个工具，更多是一种与业务发展融合在一起的迭代思路，并且在 A/B 背后实际有着科学的统计学的依据支撑着，你也会更加关注每一个业务假设是否真的是有效的。用户增长中最忌讳的是盲目套用其他业务线的增长手段，而忽视了自己业务的分析和推导的过程，凡事是否正确，需要我们测一测才知道。产品在什么阶段适合 A/B Testing？对于一个初创项目，产品刚刚孵化，这种时候不太适合做 A/B 测试，因为这个时候我们的目标相对是比较明确的，就是快速形成“原型”产品和大框架，把“产品生下来”，因此也基本上不会有太多抠细节的部分。而当产品到了一定的阶段，模式已经成型比较稳定，相对处于快速迭代的阶段，就比较适合利用 A/B Testing 来助力业务发展了。 A/B Testing 的步骤说 A/B Testing 的步骤之前，我想说，A/B Testing 实验不是说你做了一次实验拿到结果就再也不用做 A/B 了，它更多是一个不断优化和理解产品以及用户的过程。因此，这里所说的 A/B Testing 的步骤不是指我们如何在平台上面配置一次 A/B 实验，而是更大范围的，如何用 A/B Testing 优化产品的步骤。总的来说，业界一般会给 A/B Testing 划分为8 个步骤。这是我学习看到的 8 阶段 A/B 划分，可以看到我们技术同学最关注的创建 A/B 实验，实际上只是其中的第 4、5 步，而除此之前，我们还有很多工作要做，那么要科学做 A/B 我们究竟每一步应该做些啥呢？我们来看一下。 1. 建立产品漏斗这一步往往在我们的工作中会被忽略掉，我觉得，不管是业务还是技术同学，我们都有必要了解自己的产品链路以及用户的漏斗，知道了用户从哪里来，我们希望用户去哪里，才能够有准备的做增长。例如用户拉新的流程，它的漏斗大致可以是： 2. 确定产品链路核心指标在明确了产品的漏斗之后，我们需要明确要观察产品链路中的哪些核心指标。如果你的关注点仅仅是一个页面，那你可能更多需要细看当前页面的用户指标；如果你关注的产品链路比较长，你应该关注整个链路上各个节点之间的指标。以上面“用户拉新”的例子来说，我们可能要关注每一个节点的用户量（PV/UV），还要看每一层的转化率（例如: 点击/曝光）等等。确定了指标之后，我们就需要把这些指标纳入长期的观察中。 3. 观察指标，提出优化假设接着我们的产品同学就可以根据指标分析当前的业务状况，然后结合需要优化的数据指标，提出相对应的业务假设。这里开始，就有统计学知识入场了。这里我们说假设实际上包含了两种：原假设，又叫零假设、无假设（Null Hypothesis），代表我们希望通过试验结果推翻的假设。备择假设（Alternative Hypothesis），代表我们希望通过试验结果验证的假设。可以看得出原假设是悲观主义的。为啥要这么分一下，说实在我自己一开始也很懵逼。我们这里先提出这两个概念（原假设、备择假设），他们的作用在后面几步会看到。假如说我们的场景是：优化页面上面按钮的点击率，而我们的预计做法是加大按钮的尺寸。那么原假设的表述就是：加大按钮的尺寸，按钮点击率不会有任何变化。而备择假设的表述则是：加大按钮的尺寸，按钮点击率会有影响（我觉得影响包含提升和降低，不过大多数的讲解中这个假设只会写提升，我理解我们正常不会假设为数据降低，这点可以探讨一下）。另外要注意的是，在假设检验中，原假设和备择假设有且只有一个成立。确定了假设，接下来我们就进入实验的设计了。 4. 设计A/B 实验方案实验设计上，我们要明确一些信息：我们要写明，实验目标是什么，包括上面说的假设。在实验分组上，我们要考虑如何划分分组，是否要有 A/A 对照，要切多少流量来做实验？另外在投放上，我们的实验要针对谁做？是否要投放在特定的地区？或是投放在特定的端？另外，A/B 实验中最好每次只做一个“变量”的改变（虽然受限于时间你也可以同时做多个变量，例如经典的奥巴马参选的 A/B 版本海报），这样对于后续的数据分析和拿明确的结论会比较有好处。 5. 开发 A/B 实验这一步，是我们最熟悉的阶段，一般的项目需求评审都是从这里开始的，开发同学会借助 Runtime SDK 编写 UI 逻辑、分桶逻辑等，这里先不赘述里面的细节。 6. 运行实验开发完成后，我们就要准备上线了，这时要设定实验运行时的配置，例如：我们主要需要设定：指标的样本量（反过来样本量也决定了实验的运行时长）。实验的显著性水平（α）、统计功效（1-β）,一般业界普遍设定 α 为 5%，β 为 10%~20%。为什么要设置显著性水平（α）、统计功效（1-β）？这是因为，所有的实验，在概率统计学上都是存在误差的，而误差会导致我们做出错误的判断。这里常见的错误判断包括：第 I 类错误(弃真错误)：原假设为真时拒绝原假设；第 I 类错误的概率记为 α(alpha)，对应就是显著性水平值。第 II 类错误(取伪错误)：原假设为假时未拒绝原假设。第 II 类错误的概率记为 β(Beta)，取反后（1-β）对应就是统计功效值。再白话一些，以上面的例子来说：第一类的错误是指，加大按钮的尺寸，按钮点击率实际没有什么变化，但因为误差，我们认为有变化。第二类的错误是指，加大按钮的尺寸，按钮点击率实际产生了变化，但因为误差，我们认为没有变化。这里如果觉得绕，可以多感受几遍。设置好这些，发布完代码后，我们就可以发布实验了。 7. 实验数据分析我们前面说过: A/B Testing 的统计学本质就是做假设检验。当然在开始假设检验前，我们要先验证一下，我们的数据本身是正确的。然后我们就要根据实验的数据看：实验显著性是否满足要求？实验的结论是否证实了假设对数据的提升？实验是否带来了漏斗中其他数据变差？关于实验的显著性，这里我们还会用到一个 z-test 计算 p 值的方式来进行校验。 p 值表示，我们观察实验样本有多大的概率是产生于随机过程的，p 值越小，我们越有信心认为原假设是不成立的，如果 p 值小于显著性水平（α），则我们可以认为原假设是不成立的。 8. 实验结论最后，我们根据这次实验的分析结果，总结实验结论。例如：这次实验我们具体通过做了 xx 提升了 xx 指标，并且没有对其他的指标产生影响，通过这次实验的结论，我们推理出在 xx 场景下，适合使用 xx 方式来提升 xx 指标。当然如果没有达到预期的目标，我们就要调整策略提出更进一步的优化假设。这 8 步，有时候我们也会缩减为一个5 步的循环：总的来说，所做的事情是差不多的。在电商业务中做 A/B Testing，我们面临什么挑战？说了这些，我们再来看看目前在电商中做 A/B 测试，我们都面临什么样的挑战？我个人觉得主要的挑战就是： A/B 测试直观感觉成本高，业务有接受门槛。电商业务都讲究跑得快，这点我也和不少同学聊过，其实大家对于接受做 A/B 测试这件事情，感觉不是这么的 buy-in，原因还是直观感觉成本高，开发得开发两（n）个版本，耽误了上线时间。不过讲道理来说，我们不仅仅要追求“跑得快”，还得“方向对”。相信前面说了这么多，我们可以看到结合 A/B Testing 来做业务，是一个比较科学的过程，有 A/B Testing 我们在业务过程中会更加注重假设求证、数据推导以及验证，同时 A/B 上线相比“一把梭上功能”也可以降低迭代带来的业务风险，甚至结合 A/B 你可以发掘业务中存在的问题，更加了解你的用户的行为，此外通过 A/B 获得的业务的增长经验可以沉淀下来通用化。另外 A/B 不是一次性的事情，而是一个长期迭代的过程，大家做 A/B 是要以“不断优化”的心态来做，而不是“一次到位”。从 A/B “平台”的角度来说，要帮助业务解决这些挑战，我们有很多的问题要解：解决A/B 成本高的问题（这里我们从几个角度来解决）： 1.平台的操作效率（是否简单易用），平台工具是否通俗易懂（A/B 那么多统计学的概念的理解成本能否被我们平台侧抹平）。 2.开发更加规范，我们需要从开发 sdk 上规范业务的定制 A/B 开发，提供开发。 3.开发效率提升：从工程侧，我们可以利用代码脚手架、代码生成等方式来提升效率。从平台功能上来说，我们可以提供 UI Editor 等之类的工具，把一些“静态配置”类的部分开放给运营和产品，允许他们做改动来做 A/B 实验，减少开发人员自己的投入。 4.A/B 的能力需要融入到其他的流程、平台、系统里面。未来运营在使用其他平台的时候，不会感觉 A/B 配置是一个割裂的部分，当然这里的方案也是需要我们好好思考的，现在 A/B 的能力要融入到其他平台的成本还是非常高的。我想这些也是我们接下来一步步需要解决的问题。原文发布时间：2020-01-09作者：乔福本文来自阿里云合作伙伴“阿里技术”，了解相关信息可以关注“阿里技术”。

发表了文章 2020-01-07

不用 H5，闲鱼 Flutter 如何玩转小游戏？

阿里妹导读：最近APP游戏化成为了一个新的风口，把在游戏中一些好玩的、能吸引用户的娱乐方式或场景应用在应用当中，以达到增加用户粘性，提升DAU的效果，成本较低。同时在一些需要对用户有引导性的场景，游戏化还可以使用户更易于接受并完成引导性任务，并通过激励的形式鼓励用户持续沉浸在任务当中，形成良性循环。基于这个思路，闲鱼开发了互动引擎Candy。什么是Candy引擎？ Candy 是闲鱼技术团队设计开发的一款引擎： APP嵌入式的、轻量级的、易于开发、性能稳定的互动引擎；绘制系统高度融合Flutter体系，游戏场景和Flutter UI支持无缝混排；动画系统对主流格式的支持友好且易扩展。本文讲解我们为什么要做这款引擎以及我们是如何设计这款引擎的。缘起目前APP内嵌小游戏一般采用H5小游戏的方式，而这个方式存在一些隐患，并不被很多应用商店推荐。因此我们需要寻找一种新的安全的方式来实现APP内嵌小游戏，并且我们希望这个方式开发友好、性能稳定、功能齐全；所以我们遵循这三点去寻找一种新的方式。思考我们主要通过下面三种思路来探讨APP内嵌小游戏：采用Native的游戏能力目前Native开发游戏生态并不是特别成熟，而且采用Native开发，就必须面临双端两套代码的问题，开发成本和后续维护成本都会比较高。采用游戏引擎，比如Cocos-2dx、Unity等虽然游戏引擎目前非常成熟，但是游戏引擎一般用于开发重度游戏，所以引擎大小一般比较大，引入游戏引擎会导致包大小增幅不小。而且游戏引擎比较复杂，所以引擎启动耗时较多，比较难做到游戏页面秒开；游戏引擎加载进来后内存消耗都会比较大。游戏引擎和APP间的通信互动相对较为麻烦，目前没有比较好的混合栈支持。游戏引擎的UI能力较弱，无法胜任复杂的APP UI逻辑，若采用游戏引擎开发内嵌小游戏，无法融合小游戏页面内游戏场景和Feeds等UI。采用Flutter的轻量级互动引擎 Flutter本身是基于Skia这个2D绘制引擎实现的跨端APP解决方案，所以它天然具备2D绘制能力，所以采用Flutter来实现App内嵌小游戏存在可能。目前Flutter存在一些轻量级游戏引擎，比如Flame，这款引擎支持简单游戏逻辑和动画能力，同时整个游戏是以一个Widget的形式最终插入到APP中，可以让小游戏页面中游戏部分和UI部分完美融合。综上考虑，我们决定采用Flutter的轻量级互动引擎。 Flame？还是自主设计？ Flame引擎目前是Flutter生态中比较不错的一款小游戏引擎，但是依然存在很多问题：游戏系统不完善：引擎只有Game和Componet，没有Scene和GameObject概念，这样会导致游戏对象嵌套复杂，对多场景不友好。引擎完全采用Canvas来实现，游戏场景中无法实现局部刷新，存在性能隐患。缺少GUI系统，场景内嵌套UI比较难。缺少手势事件系统。动画支持格式不主流：骨骼动画是通过Flare支持的，不支持DragonBones。粒子动画最近才上，对主流格式支持也不太友好。资源管理存在内存问题，资源加载后一直不会释放。缺少机型适配能力。基于这些考虑，我们决定重新设计一款Flutter互动引擎：对标集团的EVA引擎和业界的Unity引擎，完善游戏系统。复用Flutter局部刷新。复用Flutter UI作为GUI。复用Flutter手势管理。实现支持主流格式的骨骼动画和粒子动画。复用APP资源库（图片库）。实现全局750适配。其中2-4点本质上是将互动引擎的绘制系统融合入Flutter的绘制体系中，本文下面按解决上面问题的思路依次介绍我们的引擎设计。 Candy引擎设计框架设计首先分析游戏化业务需要哪些能力，分析我们的业务场景，得出游戏化业务需要图4-1所示的能力：图4-1 游戏化业务能力需求拆解后，互动引擎需要有游戏系统、绘制系统、生命周期系统、GUI系统、物理系统、动画系统、资源系统、事件系统（手势管理）。根据我们之前的定位，互动游戏绘制融合到Flutter绘制体系中来，基于这个思路，我们可以复用Flutter的UI系统，同时需要融合Flutter和游戏的手势管理。最终我们得出如图4-2所示的框架图：图4-2 互动引擎架构整个互动引擎架构共分为四部分：接口层对外暴露的游戏接口，主要包含创建游戏、创建游戏对象、添加游戏组件等接口，同时还封装了一些常用游戏对象、常用游戏组件的工厂接口。游戏系统游戏世界的管理系统，主要管理Game、Scene、GameObject和Compoent间的组织关系，还控制游戏子系统和绘制系统的启动与关闭。游戏子系统游戏化能力补充，主要包含生命周期系统、物理系统、动画系统和资源系统，被游戏系统调用。绘制系统负责游戏的绘制，本引擎的绘制系统会高度和Flutter绘制逻辑融合，所以兼容了GUI系统和事件系统（手势管理）。游戏系统对标Unity设计，游戏系统有下列四大元素： Game：游戏类，负责整个游戏的管理，Scene的加载管理以及各子系统管理与调度。 Scene：游戏场景类，负责游戏场景中各游戏对象的管理。 GameObject：游戏对象类，游戏世界中游戏对象的最小单位，游戏世界中的任何物体都是GameObject。 Component：游戏组件类，表示游戏对象的能力属性，比如SpriteComponent表示精灵组件，表示绘制精灵的能力。 GameObject通过组合Component的形式来让自己拥有各种能力，不同的组合让GameObject相互之间不一样。整个游戏系统的组织关系如图4-3所示：图4-3 游戏组织形式生命周期对标Unity和Flutter特性，我们设计了如表4-1所示的生命周期，共有八个回调，基本可以满足互动游戏业务开发。表4-1 生命周期渲染系统基于融合Flutter绘制体系思考，我们就不能全盘用Canvas来做整个游戏的绘制管理，我们需要将游戏对象和Flutter的绘制对象RenderObject结合起来，如图4-4所示：图4-4 渲染映射首先是Game的对象数和Flutter的三颗树有效融合，所以每一个GameObject必须对应一个Widget、Element和RenderObject。融合过程主要需要解决以下问题：游戏的坐标系与Flutter的布局转换融合。动态添加和删除游戏对象的处理。动态修改游戏绘制深度的处理。 Flutter Inspector对游戏对象的支持。整个绘制融合相对复杂，需要解决很多BadCase，后续会另撰文详述互动引擎绘制融合Flutter绘制体系的过程，本文不再赘述。 GUI系统由于绘制已经融合到Flutter体系，GameObject都会对应Widget，所以我们可以设计一个特殊的GameObject，支持插入一段Flutter Widget树，这样我们就不需要另外实现GUI了，复用Flutter UI作为GUI即可。这个逻辑和绘制融合思路比较一致，将插入的Widget树作为GUIWidget的孩子即可，在GUIRenderObject中打通layout、paint和hitTest逻辑即可。这里给一段我们GUI的示例实例代码，开发过程相对简单： final GUIObject gui = IdleFishGame.createGUI( 'gui', child: GestureDetector( child: Container( width: 100.0, height: 60.0, decoration: BoxDecoration( color: const Color(0xFFA9CCE3), borderRadius: const BorderRadius.all( Radius.circular(10.0), ), ), child: const Center( child: Text( 'Flutter UI示例', style: TextStyle( fontSize: 14.0, ), ), ), ), behavior: HitTestBehavior.opaque, onTap: () { print('UI被点击了'); }, ), position: Position(100, 100), ); game.scene.addChild(gui); 事件系统在绘制融合到Flutter体系的基础上，我们融合了事件系统，增加了手势处理组件GestureBoxComponent，如图4-5所示：图4-5 手势竞技整个融合过程分下列几步： GestureBoxComponent将开发者注册手势回调方法注册到手势识别器中。 GameObject对应的RenderObject复写hitTest逻辑，按Flutter规范来处理点击的hitTest。通过GestureBoxComponent来判断点击是否该被消费。 GameObject复写handEvent来将点击事件传递给GestureBoxComponent消费。 GestureBoxComponent收到点击事件后，传递给手势识别器处理。手势识别器在将点击传给手势竞技场开始手势竞技，最终将胜出的手势返回手势识别器，最终返回并做出手势事件响应，当然这一步属于Flutter逻辑了。动画系统我们目前动画主要支持骨骼动画和粒子动画，骨骼动画资源目前支持DragonBones，粒子动画资源目前支持EgretFeather。资源系统目前互动引擎的资源系统相对简单，本文就简单介绍下。资源系统的设计思路是复用APP的资源系统，确保整个APP只有一份资源库，减少内存开销和增大资源复用率。资源系统架构如图4-6所示，在游戏系统和资源系统中间增加了一层代理，兼容APP资源系统和兜底资源系统。若我们没有注册APP的资源系统，系统会自动调用兜底的资源系统。兜底资源系统目前分两部分：兜底图片库，复用Flutter的ImageCache，复用Flutter的能力做内存管理。动画JSON资源管理，目前只实现了JSON读取逻辑，由于JSON复用性不高，所以目前并没有实现缓存管理。图4-6 资源系统目前资源系统没有做远程加载和预加载的能力，这部分在我们的后续规划中，后续我们再撰文分享具体设计实现。说在最后本文主要讲述了Candy互动引擎的设计，而我们在设计实现过程中遇到了很多问题，如发现了Flutter在绘制过程中存在一定的内存泄露，内存回收不及时等，我们后续会详述这些问题的排查与解决，同时还会对Candy引擎的性能与稳定性方面做详细测试分析。原文发布时间：2020-01-07作者：然道本文来自阿里云合作伙伴“阿里技术”，了解相关信息可以关注“阿里技术”。

发表了文章 2020-01-06

为什么 APP 纷纷开发“暗黑模式”？优酷最佳实践总结

一、缘起随着iOS 13和Android 10的正式发布，一个名词"暗黑模式(Dark Mode)"逐渐走入了大家的视野。各大APP都将暗黑模式的适配列入了开发日程，舆情上用户们对暗黑模式支持的呼声也非常的高。优酷主客也顺应时势，启动了相应的技术预研。从2019年11月开始，优酷主客Android端和iOS端使用了两个版本的时间，推动各业务方基本完成了主要使用路径上数十个页面的改造，还使用同一套方案同步完成了部分Weex页面和H5页面的适配，并完整地通过了UED的视觉验收。当前，到APP Store和各大Android市场下载的优酷APP最新版本，均已全量支持“暗黑模式”。我们邀请了参与优酷APP暗黑模式设计/开发/测试的同学们编写《优酷APP全量支持“暗黑模式” 设计与技术完整总结》，全面介绍了整个项目的实施流程和经验教训，也是对整个项目做一个完整的总结，感兴趣的同学可下翻至文末下载。二、什么是暗黑模式？不考虑计算机工业早期的黑色底，绿色字符的终端界面，暗黑模式的概念主要来源于MacOS，该系统为用户提供两个外观，即"浅色"和"深色"。自从有了这个概念之后，很多网站都为用户提供了“浅色”和“深色”两套界面，便于用户根据自己的习惯或爱好进行切换。在MacOS之后，很多APP和Android定制ROM也加入了所谓"深色模式"的支持；在iOS 13和Android 10发布之后，"暗黑模式" 终于被添加到官方支持的特性列表。三、为什么要支持暗黑模式？根据Apple官方的说法，暗黑模式可以“改善电池寿命，改善视力不佳和强光下的人的可视性，以及在弱光环境中更好地使用设备”。 1. 改善电池寿命从下图中notebookcheck的功耗分析可以看出，在使用OLED屏幕时，屏幕上显示的内容决定了功耗。当屏幕基本全黑时，OLED屏在任何亮度下的功耗都保持恒定。显示了白色内容的屏幕，功耗曲线会随着亮度提高而逐渐变陡。图片来源：https://www.notebookcheck.net/Display-Comparison-OLED-vs-IPS-on-Notebooks.168753.0.html 2. 改善视力不佳用户的可视性我们面对的用户群体中有一部分是色盲或者色弱用户，暗黑模式对于色盲/色弱用户群体是非常友好的。 3. 弱光环境中的使用在温暖的被窝中也可以舒服地看剧了，再也不用害怕被白色背景闪瞎眼了。 4. UI风格的统一业务开发中难免会用到系统默认控件，而系统默认控件都支持了暗黑模式。如果自定义控件不支持的话，当用户打开暗黑模式后，就会发现风格不统一的情况。以iOS为例，在下图的界面中， Tabbar已经被转成暗黑模式的样式，但画面上方的组件、文字因为都是自定义颜色/样式，并没有随着模式切换而自动调整，这也让整个画面看起来不太协调。如果短时间内没有精力支持暗黑模式，也可以在开发阶段强制指定不支持暗黑模式。对于iOS，需要在APP的Info.plist里面添加名称为User Interface Style, 类型为String的项目，将User Interface Style 的值设置为Light，声明"只支持 Light Mode"，就可以避免系统控件转换为暗黑状态。对于Android，需要在APP的Application里面调用下面的代码，声明不支持暗黑模式。 AppCompatDelegate.setDefaultNightMode(AppCompatDelegate.MODE_NIGHT_NO); 四、设计方法 1. 产品印象：尽量保留产品的核心视觉特征深色模式的切换就像拉上了家中的窗帘，光线暗下来但不会改变壁纸和家具的固有色。我们主要对优酷五大栏目头部氛围和底栏图标进行了深色的第二套设计，让他们在深色上看起来和谐。 2. 主背景色选择：保证与内容的兼容度基于对内容兼容度的考虑，我们选择了足够深的深色但比黑色浅一些。这样能够与包含黑色的媒资图片拉开空间层次，同时与前景色有足够大的对比度，保证在弱光和强光环境下的识别度。深色模式的主背景色应该保持安静不抢戏，给定制主题场景包括运营场、垂类频道、会员场，保留发声的空间。所以选择相对中性的颜色。色调协调，要考与主场景的氛围融合，优酷主要涉及到五大栏目导航栏和首焦吸色。 3. 色彩框架：包容且一致我们将现有色彩进行归类，并归纳出每个类型的用途，从而建立色彩框架。这样可以帮助我们确保同一用途的色彩包含的深色模式和浅色模式两个色彩组合的唯一性，而不是单个色彩的唯一性。例如：白色会同时使用在背景和有些按钮文字上，我们不能在深色模式中规定白色变成深色，因为在按钮上不适用。我们应该规定背景色的浅色模式是白色，深色模式是深色，这样按钮文字就不会受到影响。值得注意的是要先抓住一般类型，再看特殊个例。类如：我们将文字、图标归纳为信息层并划分三个层级，而不是归纳为主标题、副标题、按钮文字、底栏图标、顶导航图标。用一般类型归纳色彩的用途可以涵盖绝大部分的色彩类型，而特殊类型可以用场景、状态、组件等维度来划分，例如：“少儿一级背景色”、“可以隐藏的分割线”“黑色导航栏”。主要类型： 1）对比度的阶梯：清晰降噪我们在背景的对比度上设置均匀的阶梯变化，这种均匀的变化有利于建立背景层级的秩序感。值得注意的是与浅色模式不同在深色模式下背景的视觉感受是逐步被抬高的层，海拔越高明度高。文字的对比度阶梯则不同于背景，在深色和浅色模式下文字的对比度阶梯是趋同的。原因是我们希望主标题和副标题要有足够大的反差使主标题足够醒目，而副标题与置灰文字的反差则不需要那么大。值得注意的是需要适度提升次要层级文字的对比度。更好的对比度阶梯有利于在复杂信息密度界面的视觉降噪。 2）可读性：跨场景测试深色的外观很可能受到用户的喜欢，要考虑到用户在深夜弱光的环境中使用深色模式的同时也不能排除白天强光的使用场景。手机屏幕的自动亮度调节会给实际的比度带来影响。我们观察到 iOS 深色模式的设计提升了几乎所有元素的对比度，这值得我们有所考虑。所以尽可能在这两种极端环境中测试我们的最终设计，保证信息的可读性。 3）规范化：建立深色模式色板基于色彩框架以层级划分色彩为主，特殊类型作补充，在对应的浅色模式的层级下添加深色模式的色彩。同时我们需要在产品的真实场景中反复的对比尝试确保实际效果是满足要求的。另外，一些细节上的处理仍然值得我们的关注： 1）图标：面型图标在深色下识别性更优深色模式下线条型的图标有时会显得过于单薄缺少份量感导致关注度降低，为改善这种情况我们可以替换为块面型的图标。此外有研究表明多数情况下块面型的图标会比线条型的图标有更好的易用性，他们会被更快速的识别。 2）分割线和阴影：转换为填充色来区分深色模式多数情况下对于层级的区隔来说，使用填充色会比分割线和阴影更有效。五、执行策略深色模式不是简单的颜色的明暗变化的处理，它是一套全新的设计风格，涉及的场景与团队非常多，按照常规做法会耗费巨大的开发成本，如何快速实现优酷双端的深色模式适配是当前面临的主要问题。优酷去年设计主导与开发共同搭建视觉产品化能力，设计侧针对优酷业务属性把视觉进行不同颗粒度的拆解抽象，把影响视觉风格调性的最基础属性（颜色、字号、间距、圆角、尺寸）进行了统一design token命名，设计与开发团队共同维护一套可扩展的视觉属性。视觉属性与框架布局分离并与开发逻辑相互对应，通过SDK 的方式统一管理，一处替换全端生效，遍于控制并快速定义产品风格。在视觉产品化能力下进行深色模式的适配与落地相对来说比较容易。在两个风格的转化中主要需要适配：色彩、图片。 1. 色彩：使用语义命名交付设计整个优酷系统颜色体系分：静态色（在浅色模式下与深色模式下不需要变化的）、动态色（在深色模式下需要变化）。动态色根据不同的层级进行重新语意化工程命名，底层还是保留静态色design token 。整个颜色会由一个sdk 进行统一控制，也保证了整体的一致性。同时，我们遵循了 iOS HIG 中的语义命令方式，这对于设计师和开发都非常友好。语义命名实际上是为深色模式的动态色建立一个令牌，例如，命名一个叫“主背景色”的动态色，它实际包含了深色模式的主背景色和浅色模式的主背景色。设计师把“主背景色”标注在界面中相应的元素上，开发就可以实现这个元素两种模式的色彩切换。当然我们还要为开发同学准备一份动态色的对照表。 2. 复用与滤镜对于深色模式的图片处理，我们给出以下建议： 1）设计侧尽可能一套图片适配两个模式, 例如，使用不透明度设置这类淡彩色可以同时适配浅色和深色模式，这是一种取巧的做法；2）开发侧可以选择代码滤镜；3）对于一些无法复用的重要图片，需根据深色界面增加一套新的切图资源。 3. 工具化：设计的输出与维系通常设计完成后与开发之间的协作是通过sketchMeasure直接一键导出标注即可。那我们对基础属性进行统一design token命名后，后续的标注设计要如何标注？需要对照表格手动标注么？开发怎么看design token？盖亚是优酷设计主要在用的一个提效工具，不同于sketch Measure 导出RGB色值，盖亚导出标注会对属性的值进行符号化处理，显示属性对应的值的同时会显示对应的designtoken。从而解决了设计输出与开发实现的效率问题。六、暗黑模式的官方文档暗黑模式的官方设计指南，可以参考iOS和Android的官方文档： iOS:https://developer.apple.com/design/human-interface-guidelines/ios/visual-design/dark-mode/Android:https://developer.android.com/guide/topics/ui/look-and-feel/darkthemehttps://material.io/design/color/dark-theme.html 要支持暗黑模式，绝不是将界面上的浅色元素改为深色元素就大功告成; 否则我们只需要编排一份浅色和深色色值的颜色转换表，以及一份适用于暗黑模式的素材, 然后简单地对APP进行改写就可以了。以iOS为例，为了支持系统级别的暗黑模式主题，以及系统内置APP同步支持暗黑模式下的界面，iOS系统在屏幕(Screen), 视图(View)，菜单(Menu)和组件(Controls)上使用了 Apple 新定义的 "Darker Color Palette"。这套 Color Palette 的主要目的，在于透过调整颜色的饱和度, 做出视觉层级，提升颜色的对比性，让所有组件能够以合适的状态在暗黑模式中进行操作。基于暗黑模式进行的界面设计并不是一个颜色调整一下就可以快速解决的任务。由于暗色系的一些特性，原本用来建立视图层级（例如阴影）或者色彩对比（白底黑字）的概念都需要被重新设计，设计师们需要以全新的思维去应对视觉上的每个细节。也因为新增暗黑模式支持这一大幅度的改动，Apple 也重新定义了自己的UI设计指南，除了强调设计师们应该 "更专注于内容"，也在原有的设计 "Light Mode"基础上，提出5个原则进行调整。维持操作上的熟悉性维持平台上的一致性清楚的信息层级无障碍操作保持简单暗黑模式带来的是一整套的全新设计理念。对应而来的，就是对现有APP设计元素的全盘重构，这在设计和开发侧来讲，都是庞杂繁琐的工程，涉及优酷几乎全部业务的的界面适配。在《优酷 APP 全量支持“暗黑模式” 设计与技术完整总结》电子书中，优酷的 UED 们讲述了他们对于暗黑模式在优酷 APP 实际落地的深度思考，“点击”即可下载或在线阅读。原文发布时间：2020-01-06作者：阿里文娱技术本文来自阿里云合作伙伴“阿里技术”，了解相关信息可以关注“阿里技术”。

发表了文章 2019-12-31

阿里技术 2019 年度热文 Top10 出炉，你错过哪些？

年关将至，在2019的最后一天，回首这一年，你把哪些记忆深藏在心？过去这一年，阿里技术依旧给你带来了满满的干货。今天，我们就来盘点2019年大家最爱的文章 Top10 (非新闻信息类，仅以阅读量为参考指标)，看看你记住了多少？ Top 10 Go语言出现后，Java还是最佳选择吗？——梁希随着大量新生的异步框架和支持协程的语言(如Go)的出现，在很多场景下操作系统的线程调度成为了性能的瓶颈，Java也因此被质疑是否不再适应最新的云场景了。4年前，阿里JVM团队开始自研Wisp2，将Go语言的协程能力带入到Java世界。既享受Java的丰富生态，又获得异步程序的性能，Wisp2让Java平台历久弥新。 TOP 9 从P4到P9，在马云家写代码到双11前端PM—— 舒文今年的双11已经是阿里资深前端技术专家舒文来阿里的第11年，从应届生到双11前端PM，他一路升级打怪，实现了岗位上从P4到P9的晋升。这第11届双11顺利结束之际，他把在阿里这些年的成长经历做一个总结和分享，希望你能在他的故事中得到些许启发。 TOP 8 如何用30分钟快速优化家中Wi-Fi？阿里工程师有绝招—— 艺超现代人离不开手机，更离不开Wi-Fi。很多同学经常吐槽家中Wi-Fi用得不爽，打游戏看视频又卡又慢。针对大家常见的问题，和坊间各种“谣传”，我们为大家做全面的梳理分类，希望让每一位同学都能享受如丝滑般顺畅的Wi-Fi体验。 TOP 7 如何成为优秀的技术主管？你要做到这三点—— 云狄技术主管，又叫「技术经理」，英文一般是 Tech Leader ，简称 TL。随着工作经验的不断积累，能力的不断提升，每个人都有机会成为Team Leader。然而在机会到来前，我们必须提前做好准备，对TL的工作职责有一定了解。当然，这也会为当下更好地配合TL工作打下基础。这篇文章，作者将结合自己多年的经验，从开发规范、开发流程、技术规划与管理三个角度出发，分享对技术TL这一角色的理解与思考。 TOP 6 阿里研究员吴翰清：世界需要什么样的智能系统？—— 吴翰清吴翰清，被大家亲切地称为“小黑”“道哥”。他是阿里巴巴研究员，更是一位“白帽黑客”。15岁，考入西安交大少年班，毕业后应聘阿里。23岁，成为阿里最年轻的高级技术专家。32岁，被评选为2017年度全球35位35岁以下的青年科技创新人才（TR35）。网上有许多关于他的猜测，然而，他始终保持低调，专注于自己热爱的事业。2014年之后，他几乎不再写文章；但在今天，他有话想说，关于自己，关于科技，关于未来，说给你听，说给世界听。 TOP 5 毕玄：我在阿里的十年技术感悟—— 毕玄在阿里，我们习惯尊称毕玄老师为“毕大师”。他2007年加入阿里，一手打造了HSF，十多年来更见证、参与了阿里在基础技术上的演进与发展：如淘宝在2007-2009年的分布式应用架构升级、2013-2016年的阿里电商异地多活架构升级等。但很少有人知道，他大学读的是生物专业。左手代码右手诗，亦是生活亦是痴。毕玄将为你讲述十多年开发经历的收获与感悟。 Top 4 贾扬清：我对人工智能方向的一点浅见——贾扬清贾扬清，浙江上虞人，毕业于清华大学自动化系，在加州大学 Berkeley 分校获得计算机博士学位。作为 AI 大神，贾扬清让人印象深刻的可能是他写的AI框架Caffe ，那已经是六年前的事了。经过多年的沉淀，他对人工智能有哪些新的看法？ Top 3 如何画出一张合格的技术架构图？——三画技术传播的价值，不仅仅体现在通过商业化产品和开源项目来缩短我们构建应用的路径，加速业务的上线速率，也体现在优秀工程师在工作效率提升、产品性能优化和用户体验改善等经验方面的分享，以提高我们的专业能力。这篇文章，作者将分享自己和团队在画好架构图方面的理念和经验。 Top 2 在阿里做了五年技术主管，我有话想说——云狄互联网公司的技术团队管理通常分为2个方向：技术管理和团队管理，互联网公司的技术TL与传统软件公司的PM还是有很大的区别，传统软件公司的PM更多注重于对项目的管理包括项目任务拆解、项目进度以及风险等。这篇文章，作者将从管理的角度分享技术TL的核心职责，主要包括团队建设、团队管理、团队文化、沟通与辅导、招聘与解雇等。 Top 1 开工第一天，阿里工程师如何解锁晨会新姿势？——洪永潮俗话说，一年之计在于春、一日之计在于晨。2019年后开工的第一天，阿里工程师来解锁晨会的新姿势：“站会”。站会到底有没有必要开？如何才能高效地开好站会？总结是为了更好的前行，读完这10篇精华干货，让我们更好地迎接2020。 “点击此处”即可一次性阅读这10篇好文。原文发布时间：2019-12-31作者：阿里妹本文来自阿里云合作伙伴“阿里技术”，了解相关信息可以关注“阿里技术”。

发表了文章 2019-12-30

未来，仅凭几个前端工程师，就能 hold 住一家企业吗？

阿里妹导读：微前端架构旨在解决单体应用在一个相对长的时间跨度下，由于参与的人员、团队的增加，从一个普通应用演变成一个巨石应用(Frontend Monolith)，随之而来的应用不可维护问题。这类问题在企业级 Web 应用中尤为常见。今天，我们就来聊聊拥抱云时代的前端开发架构：微前端。微前端的价值阿里云提供的很多商业化产品和服务，本质上是对外提供「能力」，普惠中小企业。目前，能力输出主要是通过 OpenAPI，用以集成到企业自己的业务场景中，这里主要解决的还是企业底层的能力问题——无需雇佣算法工程师，就可以拥有语音、图像识别等能力。安全也是一样，不需要找安全专家，普通的工程师就可以通过控制台高效地处理各种安全事件。但是，随着云技术不断的下沉，与产业结合的越来越紧密，OpenAPI 唯有把粒度做得越来越细，才能满足各种各样的业务场景，但同时企业侧的学习成本和开发复杂度自然就上去了。控制台做为管（理）控（制）这些能力的工具，目前也只能算是「标品」，必须为了满足不同体量、不同业务特点的需求，灵活地组合和部署，就像是用户自己开发的一样。综上所述，微前端的价值有 3 点：解决产品侧的扩展性和组合性。化整为零，自由组合。解决能力输出的「最后一公里」。云生态中的「新物种」 — 微应用。如果微前端只存在工程上的价值，那它是不值得大张旗鼓去做的。我认为，前端团队需要在这个方面做出业务价值。如果你问我 Ant Design 有什么技术价值？它的价值就是有大量的企业在用，形成某种能力依赖，不需要找设计师或者多么资深的前端工程师，就可以做出看上去很专业的后台界面。在这条价值链路上，OpenAPI 太底层，控制台不灵活，UI 库太通用。其中的空白点是绑定能力的商业化组件。举个例子，企业的后台管理页上，可以直接 inside 一个「漏洞管理」的微前端应用，和一个 DataV 的微前端应用展示数据，只需要简单配一下即可，不用开发，就能做到“就像自己开发的一样”。反过来也一样，ISV 在阿里云的产品平台上，不仅可以通过小程序的形式，也可以通过微前端应用的形式输入自己的服务。微前端的问题域简单地说，搞微前端目的就是要将产品原子化（跟原子化的 OpenAPI 一个道理），再根据客户业务场景组合。每个功能模块能单独迭代，自由集成当然好，但维护成本怎么控制。怎么调试、公共组件版本控制、众多同窗微应用之间怎么“和谐相处”等等。微前端并非只是解决在页面上异步加载一个模块就完事了，更多的是将改造引发的一系列问题需要通过体系化的方案解决，否则就变成反生产力工具。目前，阿里的微前端方案有 qiankun(乾坤)、Magix、icestack、以及内部很多的微前端解决方案。或多或少都带有一些自身的业务特色，没有明确提出标准，或者明确定义微前端的技术体系到底包含哪些内容。这方面有项目落地的团队真应该再进一步瞄准更高的价值点做，同时广泛交流，这样才能更快得出标准化的东西。我们团队也在实践中，这里我抛出一些开放性问题讨论。首先必须明确微前端不是框架、不是工具/库，而是一套架构体系，它包括若干库、工具、中心化治理平台以及相关配套设施。微前端包括 3 部分：微前端的基础设施。这是目前讨论得最多的，一个微应用如何通过一个组件基座加载进来、脚手架工具、怎么单独构建和部署、怎么联调。微前端配置中心：标准化的配置文件格式，支持灰度、回滚、红蓝、A/B 等发布策略。微前端的可观察性工具：对于任何分布式特点的架构，线上/线下治理都很重要。微前端具体要解决好的 10 个问题：微应用的注册、异步加载和生命周期管理；微应用之间、主从之间的消息机制；微应用之间的安全隔离措施；微应用的框架无关、版本无关；微应用之间、主从之间的公共依赖的库、业务逻辑(utils)以及版本怎么管理；微应用独立调试、和主应用联调的方式，快速定位报错（发射问题）；微应用的发布流程；微应用打包优化问题；微应用专有云场景的出包方案；渐进式升级：用微应用方案平滑重构老项目。通过问题理解问题是一种思考方式，相信大家能沟通通过微前端三大组成部分和它要解决的 10 个问题，能够有一个大概的理解。下面，看一下我归纳的微前端的架构体系（如图）：通过上图，很明显的看出前后端分工，以及线上微应用相关配置流程。整体运行环境以及开发流程是非常复杂的，留到大会的时候再详细讲解。微前端的基本原理如下图所示，微前端的工程化是从传统前端工程化体系升级上来的。比如构建，增加微应用类型的项目构建，有动态的打包策略。传统项目管理工具通常是命令行工具，包括构建、发布、测试，会升级为项目工作台，通过 Web 界面管理项目。一个项目包括哪些微应用，版本，发布策略等在配置中心统一管理。一个大型应用被「碎片化」后，还要能做到「一目了然」。哪个模块报错，加载失败等异常发生第一时间反应在配置中心里。下面的原型图，就是一个最基本的配置中心的样貌。微前端体系要可控、可观察。通过多个微应用的组合，能够在变化如此复杂的需求中，更好的更快的赋能业务。云时代的前端开发模式前端开发从 PC 时代到移动时代，从刀耕火种的原始运维到云计算时代，回顾起来，我们会发现——开发模式跟时代背景真是密不可分。前端奋斗 20 年才把页面写好，而现在又变成「切页面」了，只是此「切」非彼「切」。云时代的开发模式注定是「碎片化」的，开发是面向模块的，而页面只是一种组合场景，一种运行时容器。我想，未来的产品开发主要时间是在「编排」——编排服务、编排逻辑、编排组件、编排访问策略、编排流程。到了云时代，一家企业只要招几个前端工程师就可以了，兼顾开发和运维、资产全部上云，运维任务通过控制台就能完成。开发借助 Serverless 和编排工具就能实现无服务端。在未来，无论是前端工程师还是全栈工程师，都将不复存在，应该叫端到端(F2E -> E2E)工程师了。原文发布时间：2019-12-30作者：克军本文来自阿里云合作伙伴“阿里技术”，了解相关信息可以关注“阿里技术”。

云栖号_个人页

个人介绍

擅长的技术

Alibaba Cloud Linux 2 LTS 正式发布，提供更高性能和更多保障！

开发者七问七答：什么是产品化？

性能提升2.58倍！阿里最快KV存储引擎揭秘

如何解决分布式系统中的“幽灵复现”？

1分钟出票5万张！阿里电影节抢票技术揭秘

新冠病毒药物研发分秒必争，阿里高性能计算如何出力？

以斗鱼为例，揭秘企业大数据上云的挑战与变化

从新人到技术主管，他只用了2年

疫情无阻，第二届阿里巴巴全球数学竞赛启动报名

2020阿里云采购季史上最全攻略

战疫期，钉钉如何扛起暴增百倍的流量？

贾扬清：如何看待人工智能方向的重要问题？

在阿里，新人如何快速上手项目管理？

在家办公，阿里人如何写周报？

DataWorks 如何撑起阿里99%的数据开发？

打破重重阻碍，Flutter 和 Web 生态如何对接？

疫情下，这群工程师抢了“表哥”的饭碗

102万行代码，1270 个问题，Flink 新版发布了什么？

戴口罩如何刷门禁？阿里工程师亮出“刷脸神器”

远程办公安全威胁升级，疫情下企业如何自保？

独家下载！阿里如何用 AI 写代码？

疫情期，APP 崩了怎么办？阿里工程师公开高可用架构笔记

从大年初一开始，他们在支付宝 7*24 小时工作

停课不停学，优酷直播如何将网课点名延迟降到0.6s？

服务社区抗疫软件与智能外呼机器人！我们已经准备好了

为记录数万人的健康情况，阿里造了1个机器人

不得不在家办公后，技术人如何在线研发？

技术阻击疫情，开发者在行动

从淘汰边缘到阿里资深前端技术专家，他总结了 8 点

10万人的大场馆如何“画座位”？

阿里云向全球公共科研机构免费开放一切AI算力

云栖号2019云计算盘点-【教育&科研上云篇】

云栖号2019云计算盘点-【文化产业上云篇】

云栖号2019云计算盘点 -【新零售上云篇】

云栖号2019云计算盘点-【金融行业上云篇】

云栖号2019云计算盘点 -【医疗健康行业上云篇】

阿里开发者工具盘点：用它！让开发事半功倍

阿里高级技术专家：整洁的应用架构“长”什么样？

百万TPS高吞吐、秒级低延迟，阿里​搜索离线平台如何实现？

对话阿里云 MVP：跨界半生，不改赤子之心

入职阿里5年，他如何破解“技术债”？

我要上官网，上云案例征集活动启动啦！ 提交案例，得大奖！【阿里云】

2020 云原生 7 大趋势预测

10年后，阿里给千万开源人写了一封信

如何打造“智能助理”？阿里对话开发平台这样做

如何快速上手 AB Testing ？阿里技术专家秘方公开

不用 H5，闲鱼 Flutter 如何玩转小游戏？

为什么 APP 纷纷开发“暗黑模式”？优酷最佳实践总结

阿里技术 2019 年度热文 Top10 出炉，你错过哪些？

未来，仅凭几个前端工程师，就能 hold 住一家企业吗？

Alibaba Cloud Linux 2 LTS 正式发布，提供更高性能和更多保障！

开发者七问七答：什么是产品化？

性能提升2.58倍！阿里最快KV存储引擎揭秘

如何解决分布式系统中的“幽灵复现”？

1分钟出票5万张！阿里电影节抢票技术揭秘

新冠病毒药物研发分秒必争，阿里高性能计算如何出力？

以斗鱼为例，揭秘企业大数据上云的挑战与变化

从新人到技术主管，他只用了2年

疫情无阻，第二届阿里巴巴全球数学竞赛启动报名

2020阿里云采购季史上最全攻略

战疫期，钉钉如何扛起暴增百倍的流量？

贾扬清：如何看待人工智能方向的重要问题？

在阿里，新人如何快速上手项目管理？

在家办公，阿里人如何写周报？

DataWorks 如何撑起阿里99%的数据开发？

打破重重阻碍，Flutter 和 Web 生态如何对接？

疫情下，这群工程师抢了“表哥”的饭碗

102万行代码，1270 个问题，Flink 新版发布了什么？

戴口罩如何刷门禁？阿里工程师亮出“刷脸神器”

远程办公安全威胁升级，疫情下企业如何自保？

百万TPS高吞吐、秒级低延迟，阿里搜索离线平台如何实现？

我要上官网，上云案例征集活动启动啦！提交案例，得大奖！【阿里云】