1、T 0 p T E C H【DEIB 描。战事在阿里达摩院搞了四年数据库，我来聊聊实际情况lnfoQ T E A M 目录 封面故事 在阿里达摩院搞了四年数据库，我来聊聊实际情况.i 重磅访谈 不到三年覆盖 25 个行业，华润集团系统上云比例超过 99%.1 突围电商大促场景，得物在高可用上的探索与实践.14 用三年替换掉二十年老系统，民生保险数字化转型秘籍.28 从基础架构到用户体验，字节跳动是如何打造移动端架构团队的？.38 一年100%云原生化，众安保险架构演进的探索与实践.48 封 面 故 事 i 中国卓越技术团队访谈录2022 第三季 在阿里达摩院搞了四年数据库，我来聊聊实际情况 嘉

2、宾：汪晟、谭剑和谢炯 作者：罗燕珊 编辑：钰莹 2017 年的云栖大会，阿里巴巴达摩院宣布成立。5 大研究方向，16 个实验室，数据库与存储实验室便是达摩院下设实验室之一。成立伊始，达摩院定位发力硬核基础科技。ii 中国卓越技术团队访谈录2022 第三季 前沿数据库技术，就是发力方向之一。五年时间，社交媒体上每隔一段时间就有人出来问“阿里达摩院搞出来什么成果了？”，“阿里达摩院的技术水平是什么样的？”，“达摩院里面的人平常的 KPI 是什么？”，“什么样的人可以进阿里达摩院？”InfoQ 日前对达摩院数据库与存储实验室的三个核心团队的负责人汪晟、谭剑和谢炯进行了集中采访，了解他们在数据库前沿研

3、究的具体工作，以及这些工作对阿里云数据库实力的加持，同时也一窥达摩院的人是如何开展研究工作的。密态数据管理，重新定义数据要素时代的安全边界 数据有望成为新型生产要素推动社会变革，然而现阶段却面临着巨大挑战。人类社会的演进离不开生产要素的升级：从农业经济时代的土地、劳动力，到工业信息时代的资本、技术。在如今的数字经济时代，全球数据爆炸式增长，大数据、人工智能等技术不断涌现，数据正俨然成为这个时代最核心的生产要素。然而，为使数据真正成为生产要素，我们仍然面临着巨大的挑战：不同于其他生产要素，数据的易复制性、非排他性等特征导致其极易被泄露、难以被限制用途用量，如何在保障数据机密性、隐私性的前提下进行

4、数据的大规模集中管理和跨组织有序流通是数据走向资产化的一大挑战。“博士期间，我的研究方向是传统的数据库系统内核，与数据安全并没有太多关联。加入达摩院后，我逐渐意识到在云计算、数据互联迅速普及的当下，数据管理与流通 iii 中国卓越技术团队访谈录2022 第三季 中的隐私安全是非常严峻的挑战，会成为数据库系统突破其能力边界的一个重要方向。但具体可以做成什么样子，我脑子里起初也很模糊，只是不停地朝着这个方向探索。”汪晟于 2018 年加入达摩院，是数据库与存储实验室的第一位专注基础研究的科学家（Research Scientist）。自加入之后，他就开始探索数据库安全可信方向的研究，并带领团队从

5、0 到 1 完成了全密态数据库技术的研究突破与产品落地，使阿里云成为了全球少数具备全密态数据库管理能力的云厂商。传统数据库系统的安全体系中已经有很多经典的技术，比如存储落盘加密、访问控制、网络传输加密等。但所有这些技术考虑的情境是：数据库管理着企业内部的数据，数 iv 中国卓越技术团队访谈录2022 第三季 据库服务所在的服务器被放置在企业专属的、物理安全的机房中，数据库与服务器的管理人员是完全被信任的企业内部员工，安全防护措施只需要保证没有权限的外部人员无法访问数据库即可。但是，数据应用和云计算的出现改变了数据的使用和管理方式，从而颠覆了上述情境。例如，数据应用业务链路越来越复杂，经常涉及企

6、业自己数据在其他企业的系统中流动（比如电商场景的平台、商家、物流等），不同企业间是不完全信任的；在企业内部，业务团队的数据是由 IT 基础设施团队统一管理的，不同团队间也可能是不完全信任的。也就是说，数据的机密性、完整性、隐私性等问题，这是传统数据库系统在设计时从未考虑过的。因此，业内也开始将研究重点聚焦在全密态数据库上。全密态数据库旨在解决数据全生命周期的隐私保护问题，使得系统无论在何种业务场景和环境下，数据在传输、运算以及存储的各个环节始终都处于密文状态。当数据拥有者在客户端完成数据加密并发送给服务端后，在攻击者（包括黑客、超级用户等任何角色）借助系统脆弱点窃取用户数据的状态下仍然无法获得

7、有效的价值信息，从而起到保护数据隐私的作用。全密态数据库这个概念可追溯至 2010 年 MIT 提出的 CryptDB，该项目不是指某种特定的数据库，而是一种针对加密数据的查询技术，允许用户查询加密后的 SQL 数据库，在不解密数据的情况下返回结果。CryptDB 使用的是特殊的加密算法，包括保序加密、可检索加密、半同态加密等，但各算法支持的计算操作极为有限，安全强度也各异，难以在复杂的业务场景中使用。v 中国卓越技术团队访谈录2022 第三季 此外，全同态加密被誉为密码学领域的圣杯，一旦实现就代表着所有计算都可以在密文上执行，且其安全性也能得到保障，因此受到了学术界的追捧。但其性能非常低，虽

8、然过去几年业内有很多研究机构推出了各种各样的加速方案，但实际效果还是会与其他方案存在数量级上的差距。那么，其他方案具体是指什么呢？第二种方案是多方安全计算。将数据存放在多个互补共谋的云平台之上，单一云平台上的数据显示为毫无意义的字节串，多个云平台的数据组合在一起才可以计算出想要的结果。其缺点是受到多云架构的制约，与集中化、单一的云平台设计初衷相违背，数据计算过程严重依赖跨云或者跨数据中心的网络交互，信息传输成本极高，难以处理大规模数据。第三种方案是基于可信硬件（TEE）的方式实现。相较于普通服务器只需要有根用户或超级用户权限就可以访问任何进程中的任何数据内容，可信硬件内部的资源是由硬件机制保证

9、隔离的，即便拥有上述权限也无法访问由可信硬件保护的区域内部。即便攻击者控制了整个服务器也无法窃取其中的数据。这种模式的缺点是十分依赖硬件的能力，且存在侧信道攻击隐患等。目前国际上比较成熟的是英特尔的 SGX 技术，达摩院内部也已经具备自研的 TEE 技术。汪晟团队对上述三种技术方案均有研究布局，但技术研究和产品落地是两回事，经过多方权衡，团队当前选择了第三种方案进行商业化落地。“阿里云是全球第三的云计算提供商，支撑着无数企业用户。我们希望研究出来的密态数据管理技术可以适用于任何场景下的任何数据库系统，且在硬件加持下，最终的性能损耗是可以无限趋近于零的。如果针对特别敏感的数据子集，不希望依赖硬件

10、安全，我们可以对这部分数据使用同态加密算法做进一步加固，这自然是建立在牺牲性 vi 中国卓越技术团队访谈录2022 第三季 能的基础上实现的，需要企业自行抉择。”在 2020 年初，汪晟团队的研究成果已经开始在阿里集团内部业务试运行，2021 年 9月份，全密态数据库系列产品正式在阿里云对外发布，成为全球第二个全密态数据库云服务。阿里云的几大数据库产品，比如 PolarDB、RDS 均已接入该能力。从性能指标来看，在事务型（OLTP）场景下，性能可以达到明文数据库的 50%到 90%，具体性能损耗与实际运行的工作负载有关，这个损耗与业内其他方案相比已经把控得相当优秀了。当然，用户可以在安全与性

11、能之间自行选择向哪一侧倾斜。从改造视角来看，团队发现实际落地需要考虑的问题不单单是产品技术能力本身，更需要考虑与原有数据库的兼容性、降低迁移成本和提供回迁备案等。基于这些诉求，团队又研发了定制的数据库连接驱动，在业务无感的情况下自动完成数据加解密，无需修改应用侧代码。“提供数据库内的密态数据管理能力只是个开始，最终企业客户希望得到的一定是覆盖整个数据生命周期全链路的密态数据管理能力。只有做到了这一点，才能真正实现数据要素的资产化和市场化，这是个更具挑战但也更有价值的研究问题。”汪晟团队的研究不仅停留在数据库系统层面，面向上述数据全生命周期密态管理的问题，他们最新的研究成果已经转化为学术论文发表

12、在了数据库领域顶会 VLDB2022 上，得到了业界同行的认可。除此之外，他们在防篡改数据存储、隐私增强计算引擎等全方位数据安全技术的研究和产品化上也在进行着持续的探索突破。在汪晟闷头研究数据库安全可信技术的时候，同处一个实验室的谭剑正在思考数据库到底能不能“自动驾驶”。vii 中国卓越技术团队访谈录2022 第三季 AI FOR DB：让数据库实现“自动驾驶”1970 年代，DBMS 的出现简化了应用开发人员对数据进行统一管理的棘手问题。数据库通过关系型模型和 SQL 声明式语法，为事务、存储、查询、性能等一系列问题提供了一个高效的，自动的解决方案。这个阶段数据库的优化工作聚焦在数据库内核的

13、若干基础原子能力，例如针对索引，或分区分表等“点”上的自动优化。1990 年代，主流的 DB2，Oracle 等数据库推出更加全面的专家自动优化系统，可以在一个更大的决策空间中对不同配置下的系统性能进行估计，用来指导系统的自动优化。虽然在之前“点”上的优化进一步扩大到了“面”，但大多时候仍然高度依赖 DBA 的经验和人的手工操作。2010 年代，云计算的兴起对数据库自动驾驶的能力提出了更高的，更直接的要求。在云原生数据库的弹性平台之上，单纯依靠人力已经不可行，迫切要在更丰富的“体”上，对多样的数据库形态实现要求更高的“自动驾驶”。其实关于数据库自治的研究早在十几年前就已经在学术界提出，但真正的

14、大规模商用落地则是在云计算成熟之后的近几年。谭剑团队推出的数据库自治产品 DAS，自成为阿里云产品以来用户数和营收近两年一直保持在 70%到 80%以上的快速增长，就是一个直接的证明。viii 中国卓越技术团队访谈录2022 第三季 Gartner 报告指出，预计到 2023 年全球 75%的数据库都会跑在云上，这与传统数据库的天下发生了本质变化。在这么一个复杂的系统环境中，数据库运行的过程中会出现各种性能问题，概括起来主要分为三类：一是从可观测的角度，数据库性能指标多，难快速形成对故障的可解释性诊断；从可控制的角度，难做到对实例的个性化运维。比如，DAS 支持的一个典型头部客户，一个 DBA

15、 管理了数百个数据库实例，性能问题和故障告警很容易淹没在海量的观测数据之中，故障现场也很难捕捉，要做到故障定位和快速精准恢复就更难了。二是数据库要做到 24 小时永不停歇，持续调优，保持稳定，传统上需要专业的 DBA ix 中国卓越技术团队访谈录2022 第三季 来负责，需要丰富的运维经验。但是，对于云上的大规模数据库，由于人力不足或者经验存在差异，并不总能保质保量的解决问题，而这种不确定性在要求很高的商用生产环境中是要尽力避免的，因为“线上问题无小事”。三是面对发展的业务对资源需求的动态变化，如何做好容量规划和资源优化，避免人工频繁干预，降低运维成本，这些都是在云时代的背景下，企业和开发者对

16、自治数据库的实质需求。从技术层面来看，数据库自治是一系列原子技术的组合，广义上包含两大类：数据库外部运维和内核技术的智能化。外部运维就是最近流行的 AIOps，内核技术则是用 AI技术提升数据库内核的某些性能。目前学术上对后者有很多前沿研究，比如 MIT 提出过使用深度学习网络代替 B-tree 做索引，在一些实例上取得了不错的效果；IBM 使用深度模型做 SQL 执行计划优化等。但是，目前离成熟的、大规模产品落地还有一段距离。“当前，业界的实现路径呈现百家争鸣，百花齐放的状态。我们采取的策略是外围包围内核，先从 AIOps 做起，逐步进入内核智能化的领域。不过有时候这两者界限并非那么明显，我

17、们有的产品能力本身属于内核能力的一种外置。例如我们研发的外置 SQL 优化，对 MySQL 等开源数据库特别适用。商用数据库往往都有很成熟的执行器优化，可惜是几个传统头部数据库公司的商业机密。对开源托管类的数据库，往往是欠缺的状态，而我们提供的外置优化可以直接解决客户很多问题。”数据库自治 DAS 基于全量 SQL 和性能指标的大数据能力，深度融合人工智能和专家经验，可以分成上游的可观测技术，和下游的可控制技术两个系统。上游包括例如异常 SQL 定位，信号异常检测，针对稀疏数据或倾斜分布的高效统计采样，还有把观测 x 中国卓越技术团队访谈录2022 第三季 技术的结果按场景进行归类，用来驱动下

18、游的控制。下游技术包括例如 SQL 外置优化，限流，压测，调参，弹性扩缩容，资源调度，SQL 审计等。这是一个复杂的，包含众多原子技术的体系。通过单点技术的原子能力，加上体系上的构建的丰富的产品功能，和阿里云上独有的规模化的服务，三者的结合构成飞轮效应，呈现给用户智能化的数据库自治能力，让用户聚焦在自己的业务创新和发展上。对自治中可控制技术的部分，数据库可能会通过改变物理设计/参数配置/物理资源等方式进行自动优化，可能会包含多种不同的优化方式。从这个角度来看，阿里达摩院研发的数据库自治产品架构，采用了让多种优化服务通过解耦的方式协同满足客户的需求，在具体业务场景中各种服务会呈现不同的自治形态。

19、一是改变物理设计。例如改变表结构。可能开始 OLTP 表的设计不是特别合理，如一些需要频繁更新的数据和以读为主基本不变的数据大量放在了一起。这从优化的角度会更多以推荐的形式推送给客户，因为除非引擎产品直接支持混合事务分析 HTAP，那么改变表结构需要由客户来评估线上的影响，再决定是否采纳。二是优化参数配置。这是当前比较热门的研究方向，数据库有数以百计的性能参数，通过专家经验可以总结出来一些核心的参数。这些可以与智能压测相结合，对参数进行优化。这里往往也涉及到在线变更的操作，所以需要和数据库领域知识以及业务场景的分析结合起来。三是对资源的优化。例如自动扩缩容，一定程度上已经比较成熟，阿里云数据库

20、多个产品都推出了自动扩缩容的功能。另外一个例子是自动限流，当数据库突然出现 CPU负载高，造成响应异常等问题，我们会自动定位到造成问题的 SQL 语句，对其进行限流，甚至 kill 等操作，通过止血来避免对其他任务造成影响。当然了，这些主动运维 xi 中国卓越技术团队访谈录2022 第三季 的操作都需要客户的事先授权。基于对不同路径的研究及可落地性的考量，阿里云数据库于 2020 年推出数据库自治产品 DAS，以期实现数据库的“自动驾驶”。采访中，谭剑提到，数据库自治关注的是让数据库不但“可用”，还要“好用”。终极的目标就是让数据库运维做到无人自动驾驶。提到自动驾驶，大家就会想到 AI 技术，

21、这在数据库自治上同样适用，只不过这里的 AI是更广义的角度，不局限于现在大家比较熟悉的深度学习技术，还包括传统的控制，统计，优化等方法。更重要的是，这些 AI 技术需要和数据库的领域知识结合起来。从产品角度，数据库自治提供了自感知、自决策、自恢复、自优化、自安全的能力，保障服务稳定、安全和高效。从技术角度，谭剑提到“可以形式化借用编程 class 的语言来描述：DAS 是一个继承了多种数据库引擎内核能力，实现了 AI 和大数据两个接口的一个子类”。DAS 支持的引擎包括 Redis、PolarDB、MySQL、PostgreSQL、Mongo、SQL Server 等多种内核，在原引擎基础上提

22、供的一种增值能力。这对自建数据库也是一个很好的场景。在此基础之上，DAS 实现了两个接口：一是 AI 算法，提供智能化决策能力；二是大数据技术，基于用户全量 SQL 的日志数据和性能指标数据，实现感知和审计能力。上述两者之所为称为接口，是因为对不同的数据库引擎有具体的实现差异，不同的业务场景也有不同的产品需求。“今年以来，系统的可观测性概念火了，其实从数据库自治的角度，还有一个对偶的概念叫做可控制性。事实上，二者在控制理论中存在严格的对偶关系。可观测性和可控制性两者的有机结合，才构成了数据库自治的完整链路。”xii 中国卓越技术团队访谈录2022 第三季 这种能力具体到阿里云自研的 Polar

23、DB 数据库上是如何体现的呢？PolarDB 是一个分布式数据库，支持水平和垂直扩缩容。从自动扩缩容 Auto Scaling 的角度，需要考虑是优化只读节点还是写入节点以及两者的关系；从负载的角度，需要进行针对性的优化；从迁移角度，当客户从其他数据库迁库转到 PolarDB 时，为了不影响在线业务和评估容量，可以使用 DAS 提供的智能压测能力，将原有数据库与目标数据库（PolarDB）做一次性能评测和容量评估。DAS 支持不同速度的回放，保障多次回放过程的数据库运行时状态一致，便于客户进行评测，这些都可以对 PolarDB 进行特色支持。自治能带来一些什么具体的业务价值呢？流利说的基础架构

24、负责人表示：“阿里云数据库的自治使得运维人效大幅提升，实现团队转型升级”。捷顺的运维总监则表示：“自治大幅降低了数据库故障时间，提高了系统的可用性。”可见，自治数据库已经在企业中落地并获得了实际的业务价值。在谭剑团队忙着“落地”数据库自治技术的时候，谢炯团队正被“空天数据”问题深深吸引。空天数据库引擎：天地乾坤，万象合一 随着对地观测技术、物联网和数字孪生技术的快速发展，车联网/自动驾驶、视觉定位、物流配送等位置服务将随时在、随地在、随身在。与之而来，多维空天数据呈现爆发式增长，给数据存储、处理与分析计算带来极大挑战。在谢炯看来，空天数据有狭义和广义之分。狭义上，空天数据（aerospace

25、data）主要来自天基和空基，例如，基 xiii 中国卓越技术团队访谈录2022 第三季 于天基平台的 GNSS（全球导航卫星系统）数据和各类卫星遥感数据等，基于空基平台的倾斜摄影、航拍影像、视频数据等。广义上，则可以将空天数据定义为涵盖 Spatial（空，即地理空间）和 Space（天，即宇宙空间）的地、海、空、天各类与位置相关数据。天问一号携祝融号在火星的登陆为我们传来大量火星遥感影像和空间信息，使大家最直观地感受到来自地球之外的空天大数据。谢炯在浙大教过本科，在中科院做过研究，也曾经和一群伙伴创过业，一直热衷于数据库技术。2018 年，他选择加入阿里云，这被他认为是人生中很重要的一个选

26、择。“当时，云计算发展迅速，我认为这代表着未来的演进方向，阿里云在国内做得最早，xiv 中国卓越技术团队访谈录2022 第三季 影响力最大，当时脑海里奔出四个字，“顺势而为”。此外，阿里很擅长将技术转化为产品，不仅内部有高德、菜鸟、本地服务等大量位置服务场景，通过阿里云这个平台能辐射更广阔的行业和客户，这和我做研究是不一样的。”在他看来，传统的空间数据库（spatial database）主要处理点、线、面等空间几何对象，这类数据体量和结构复杂性相对可控。但现今遥感影像、时空轨迹、倾斜 3D 等大量位置传感型数据面临着数据结构复杂多样难以管理，数据动态变化要求更高维度计算，大数据和大计算场景性

27、能不佳以及智能化需要多模态数据融合管理等一些列难题。这类新型多模态数据无论在存储上，还是计算上，都需要基于云的池化能力和弹性能力，才能在性能、成本、规模化上达到有效平衡。谢炯认为，将空天信息处理融入 PaaS 服务（Platform as Services），以云数据库与存储平台为核心解决空天数据的实时接入、高效存储和弹性计算，是支撑传统时空信息云化架构向纵深发展的必走之路。在谢炯看来，这种架构演进具体可分解为平台即服务、多模融合、计算下推和云原生四个方向。1、平台即服务 是将空天数据处理内置于云上 OLTP 数据库、OLAP 数据仓库、NoSQL 多模数据库等不同系统，相比传统中间件方案在易

28、用性、计算效率和事务一致性处理上存在先天优势。难点在于技术融合之后涉及数据库内核技术、图形图像技术和空天数据专业处理技术的跨学科交叉，这三个方向各自的技术门槛都不低，同时熟悉这三个方向的技术人才则是少之又少。xv 中国卓越技术团队访谈录2022 第三季 2、多模融合 是跨结构的多模态数据融合和一体化处理。有两个层次，首先在空天数据层次，不同空天多模态数据有非常大的结构差异和计算方式，只有模型打通，数据结构打通，算法才能真正打通（高效率）；其次是泛空天求解，把独立的空天数据处理能力嵌入到时序、图、文本等更多通用模型中，实现时序时空、空间/时空图、空间文本等跨界融合，这些不同模型之间数据结构和计算

29、方式差异巨大，融合的挑战自然更大。3、计算下推 是将空间信息系统业务关键计算下推数据库系统，让计算离数据更近。难点在于生态共建，已有上层的 CIM/BIM/GIS/RS 等涉空间系统都需要升级换代。谢炯谈到，差不多十年之前我就在推动这一架构转型，但面临很多挑战。直到最近几年，大家看到了这一技术架构带来的利好，不少行业厂商和数据库厂商才主动加入这一方向阵营。4、云原生 新一代空天数据库一定要与云原生能力紧密结合，与公有云结合，并由公有云走向混合云。谢炯团队认为，云服务的本质是算力经济，数据要灵活，算法去补；而算法要灵活，算力去补，即借助足够弹性的算力来保障算法的纯粹性和普适性。公共云厂商在这方面

30、具有独特优势，因为可以把空天计算能力下沉到存储、硬件等更底层次做垂向优化。Ganos 是在综合以上四个方面基础上，实验室研制推出的首个云原生、跨数据库平台的空天数据库引擎。该引擎已内置于了云关系型数据库 RDS PG、云原生关系型数据库 PolarDB PostgreSQL、云原生数据仓库 AnalyticDB PostgreSQL 和多模数据库Lindorm 中，将传统空间数据、新型空天数据和其他类型数据实现了多模一体化处理。用户可以按不同数据库产品独立使用，也可以基于产品组合构建空天数据库大数据一 xvi 中国卓越技术团队访谈录2022 第三季 体化底座。谈到 Ganos 与传统空间数据库

31、的区别，谢炯认为主要有三点：一是云原生，Ganos 从诞生就在云上，充分利用了云原生能力进行设计。二是专业特性上突出了多维、动态、场景化。多维是既兼容传统 2D，也支持 3D；动态是指时空变化的表达能力，比如移动对象数据库；场景化是指视觉和行为信息处理，比如原生支持各类 3D 建筑的视觉信息处理，共享单车（移动对象）的开锁、闭锁事件描述等。Ganos 分别在 2018 年和 2021 年在业界首个推出了基于云的移动对象数据库和 3D 场景数据库，并在今年的 VLDB 2022 数据库顶会上作了整体介绍，获得了业界同行的认可。而传统空间数据库对多维、动态、场景化仅提供非常有限的支持。三是跨数据库

32、平台，Ganos 未来的目标是一站式空天/时空数据处理平台。业界对于多模态数据的处理和支持大多处于早期落地阶段，虽然学术届开展了长期、广泛的学术探讨，但真正商品化提供服务的一直未见有成熟系统。空天数据是一类最典型，且应用广泛的多模态数据。早在 2018 年，Ganos 就结合 PolarDB 推出了完全自研的移动对象数据库，并在这几年快速迭代发展。这背后得益于与阿里内部场景的广泛结合，所谓的“母体带动”。在达摩院，Ganos 在支持包括自动驾驶实验室的小蛮驴，机器智能实验室的 AI Earth，XR 实验室的 3D 空间计算等各类创新场景；同时，Ganos 也在支持包括高德、网商银行大山雀、本

33、地生活等各类位置相关业务场景。据不完全统计，云上 Ganos 引擎被创建次数达到 3 万 6 千多次，目前已广泛应用到航空航天、自然资源、共享出行、灾害应急、交通物流、远程银行、农业/海洋/水利以及社交/健身/O2O 等总计 45 个不同行业/应用方向。天地乾坤，万象合一，这个“一”就 xvii 中国卓越技术团队访谈录2022 第三季 是万物在时空中的位置，也正因此，空间计算业已成为数字化浪潮中的关键基础设施。达摩院眼中云原生数据库的未来 过去几年，达摩院的前沿技术研究与阿里云数据库的产品商业化服务形成相互促进的“飞轮”，前沿技术研究保证了数据库产品技术及时更新换代，带给客户更多价值，同时大规

34、模服务客户遇到的丰富场景推动达摩院不断在前沿技术研究领域获得突破。这种良性互动的“飞轮效应”体现在阿里云数据库自研产品 PolarDB 等云原生数据库技术创新中：PolarDB 在业内率先实现了一种全新的架构计算、内存和存储的三层解耦，首次实现内存池化。这种架构创新能够帮助下一代云原生数据库显著提升性能和弹性，大幅降低成本。在汪晟团队的努力下，阿里云成为全球仅有的两家实现了全加密数据库产品商业化输出的云厂商之一（另外一家是微软）；在谭剑团队的努力下，达摩院丰富的智能算法在数据库领域的深度应用，让 PolarDB 等数据库产品拥有了“自动驾驶”能力，方便客户简便、智能、高效地使用；在谢炯团队的努

35、力下，PolarDB 可以高效管理多维、动态、场景化的空间/时空/网格数据，更好地支持数字孪生城市等复杂 3D 多模态数据管理场景。接下来，汪晟、谭剑和谢炯所在的数据库与存储实验室将继续为云原生数据库的未来努力着。今年初，中国信通院对数据库领域关于智能化数据库、关系型数据库的安全能力，自 xviii 中国卓越技术团队访谈录2022 第三季 动运维能力，全密态、防篡改等标准均在起草中，达摩院数据库与存储实验室深入参与了每一个标准的制定。在全密态数据库的技术层面，汪晟团队接下来将会思考如何做出一个可信密态的数据管理体系，涵盖数据全生命周期的安全性，这是从技术视角要解决的一个问题；在业务价值的层面，

36、团队希望能够将当前的能力进一步标准化，让不同的数据库均可无缝接入到该体系；在生态建设层面，将密态数据推广到数据管理的各个层面，从数据收集到数据处理，再到数据共享等环节都能通过生态化共建的方式进一步完善现有能力。DAS 目前已经是首批通过信通院数据库管理系统智能化标准的两大厂商之一。而且，该标准和 DAS 目前的产品能力高度一致。未来一年，谭剑所在团队会主要解决如何更好地将自治技术与数据库领域知识结合，用来解决复杂的根因诊断问题，将数据库领域的知识和经验沉淀下来，和 AI 结合让客户真正能够从可解释性的角度更好地运维和优化数据库，并理解其运行状态。除了 AI for DB 的数据库自治，谭剑团队

37、最近也推出了 DB for AI 产品，将 AI 的能力直接构建在 DB 的内核之上，让客户通过数据库直接获得原生的 AI 能力，为其提供价值挖掘能力和解决方案。例如今年 7 月，通过PolarDB 推出的 Polar for AI 产品，可以对数据库典型场景和客户提供各种 AI 解决方案。在 Ganos 的未来发展上，谢炯团队会面向云原生和云孪生结合，朝向大规模空天数据一站式管理方向演进。系统层面，向下会从多模态并行查询、扩展存储引擎等方向发力，向上会从算法层面针对轨迹、影像、3D 等新型空天数据实现高性能分析计算，把整体能力做深做精；我们会重点把云和 LBS、数字孪生/元宇宙等业务结合，借

38、助数据库产品与行业 ISV 开展更广泛的生态合作，把解决方案做好，实现从技术到产品到产业化应用的快速迭代。xix 中国卓越技术团队访谈录2022 第三季 在达摩院做科研是种什么体验（因本文三位嘉宾均来自数据库与存储实验室，故此处只从他们的视角谈科研体验。）做研究，拥有自由探索的空间 从数据来看，阿里云数据库团队过去几年在国际顶级会议上发布的论文数量不断创下新高，从2018年的2篇增长到2022年的15篇。在刚刚结束的数据库顶会VLDB2022上，数据库与存储实验室向 Industrial Track 投稿的五篇论文被全部接收（该 Track 全球共接收 22 篇），这也意味着实验室的相关探索得

39、到了业内的广泛认可。实验室内部对论文的质量审核极其严格，这也是一投即中的重要原因。从实际感受来看，三位嘉宾认为实验室的整体氛围还是不错的，实验室总负责人李飞飞在对技术方向的把控上十分到位，并会给予大家自由的探索空间，达摩院的品牌效应及阿里内部广泛的落地场景给研究带来了极大优势。“做研究和做产品不同，团队氛围非常重要，产品商业化之后可以立刻收到市场反馈，但研究有时候没那么快与商业产品相结合，实验室中的资深专家们会及时对大家的工作成果给出评价反馈，让大家更容易认可和强化手头工作的研究价值。”汪晟在采访中表示。实验室 70%成员是博士，欢迎交叉学科人才加入 数据库与存储实验室内部有很多相对年轻的成员

40、。“技术的未来需要更多颠覆性创新，xx 中国卓越技术团队访谈录2022 第三季 因此我们非常欢迎年轻的同学加入进来”。目前，该实验室 70%左右的同学都是博士，来自海内外各大名校，研究方向也非常多样化。此外，虽然实验室的定位是数据库，但并不是只接收数据库背景的人才，也欢迎交叉学科的同学加入。嘉宾介绍 汪晟，计算机博士，毕业于新加坡国立大学，达摩院数据库与存储实验室系统与安全方向负责人，全面负责下一代云数据库安全可信与隐私计算体系的科学研究和产品落地。新加坡国立大学计算机博士，研究领域为大规模实用数据管理系统，主要研究兴趣包括云原生数据库系统、隐私与机密计算、云数据库安全、数据分析系统、区块链等

41、，在SIGMOD/VLDB/ICDE等数据库与存储领域顶级会议上发表学术论文近40篇，获得 IEEE ICDCS 2020 最佳论文奖、ACM MM 2015 最佳论文奖提名。谭剑，电子与计算机系博士，毕业于美国哥伦比亚大学，阿里云数据库自治服务和达摩院智能数据库方向负责人。曾先后任职 IBM 沃森实验室研究员和俄亥俄州立大学电子工程与计算机系终身制教职。研究兴趣包括分布式计算系统的资源与性能优化，AIOps 系统设计与实现，随机系统的数学建模与算法分析，优化算法的理论与应用。五次获得最佳论文奖，在俄亥俄州立大学曾获美国自然科学基金支持，并在多个著名学术会议中任执行委员会成员。谢炯，博士，毕业

42、于浙江大学，达摩院空天数据库方向技术研发负责人，CCF 计算机协会数据库专委会委员，中国测绘学会智慧城市专委会委员。近十五年来聚焦多模态 xxi 中国卓越技术团队访谈录2022 第三季 数据处理和空间数据库系统研究，感兴趣于三维对象数据库、遥感图像数据库、轨迹大数据处理和 NoSQL 时空分布式系统等领域，研发成果曾获得了科技部国产优秀软件奖、国家科技进步二等奖、中国电子学会科技进步一等奖等奖项。重 磅 访 谈 1 中国卓越技术团队访谈录2022 第三季 不到三年覆盖 25 个行业，华润集团系统上云比例超过 99%采访嘉宾：肖海山，华润数科技术委员会主任、华润云总经理 冯铮，华润数科华润云事业

43、部 SRE 服务部技术总监 2019 年 11 月，华润云正式上线。从这时起算，华润集团要求所有板块要在 3 年之内完成上云工作，也就是说，2022 年底就是最后期限。充满挑战性的任务背后，承载的是华润集团全面深化数字化转型的决心。华润集团智能与数字化部在十三五期间提出“智慧华润”建设愿景，制定了“云优先，智生长”技术战略，构建转型的技术基础和关键实施路径。本文将从华润云的视角，深入了解大型传统集团型企业对于上云的思考和实践，以及是如何探索数字化转型之路。从华润云的建设说起 2015 年开始，伴随着华润集团统一数据中心的建设，华润集团开始布局云的建设。2019 年底华润云已完成基本的 IaaS

44、、PaaS、及部分 SaaS 产品研发及建设，在 2019年 11 月份宣布华润云正式上线，并开始为全集团 25 个行业提供云计算及相关服务。2 中国卓越技术团队访谈录2022 第三季 在华润集团开展上云工作的同时，华润云也坚持自主研发和持续迭代，到 2022 年 7月，云计算（IaaS/PaaS）相关产品每半年发布一个迭代版本，逐步丰富出了覆盖私有云、混合云、边缘云、公有云、信创云场景的产品系列。肖海山表示，华润集团的数字化道路走得比较早，在 2013 年就已经有大面积的信息化尝试。比如华润万家涉猎电商、O2O，门店运营业务数字化。只是当时大家仅认为这是降本增效的一种办法，鲜少人提“数字化”

45、这个词，但放到今天的语境来看，这都属于数字化场景实践。华润集团大多数行业都面向民生，伴随移动互联网的发展，这些年集团内也有大量 C端业务做了数字化场景探索。因此华润早就意识到数字化转型是需要解决什么关键问题：井喷式增长的业务数字化需求和有限的 IT 能力之间的矛盾。具体而言，这里的 IT 能力主要体现在两方面：一是组织能力，是否有专业的人以及人才的数量是否足够；二是这些人是否有足够强的武器去打赢这场仗。“武器”指的是 IT 用的平台、工具或者能力，华润云认为最核心的答案是云平台，将企业数字化转型所需的各种能力定位成不同的 PaaS 平台能力。在华润云出现之前，华润集团内有不少子单位已经用上了云

46、，并且不少业务跑在公有云上。但在集团看来，无论是作为央企的责任驱动或是从数据安全挑战的角度考虑，由集团层面牵头统一建设云是势在必得的，而且这件事迫在眉睫。“再不统建云，下面好多单位就要自己建了。”3 中国卓越技术团队访谈录2022 第三季 云架构思考 为了打造自己的云，华润集团依托华润数科成立了相应的华润云事业部。当时团队把市场上国内外所有主流厂商的云“都摸了遍”。一番调研过后，团队发现，由于这些厂商做云的初衷是解决自身的业务需求，因此其架构设计理念还是围绕互联网的场景出发，或者就是纯粹为了卖服务器。很多中小企业做的是互联网业务、游戏业务，那么采用主流的云就会觉得很合适，很方便。”肖海山说道。

47、但对于传统企业，情况则大不相同“传统企业对云的诉求跟公有云提供的服务还是有很大差异。”肖海山表示，互联网应用日常就有可能出现有百万人或千万个人的访问量，因此其公有云服务的性能要求是“高弹性、高并发”。然而，传统企业很少面对高并发的压力，一个系统有 1000 人同时并发访问已经称得上是“很有压力”。从华润集团自身来说，尽管信息化建设在央国企阵营算是走在前列，但大多数系统还是传统架构，还有些系统访问量虽然很低，甚至低至几个人，但数字化的场景是主要是 2B 类型（工厂、库存、物流等等）其后台运算逻辑的复杂性不小，对后台运算的压力比互联网应用要大很多倍，且更重视架构的“稳定性、安全性、高性能”。另一个

48、关键问题是：当时多数私有云厂商提供的是最基本的 IaaS 服务，但是 IaaS 能力对于传统企业来讲，能够创造的价值非常有限，因为离业务太远。离业务越近的 IT能力才是业务侧所需要的，那就是 PaaS 层。4 中国卓越技术团队访谈录2022 第三季 肖海山指出，虽然互联网厂商也提供不少 PaaS 层的能力，但基本是依据互联网的场景设计，这意味着如果传统企业直接拿互联网厂商的公有云架构来用，最终可能会发现“IaaS 能力不是自己想要的、PaaS 层也没有相应的 IT 组织能力用。”华润要做的云平台，是要让自己所有的互联网应用和传统应用都能在上面跑起来以传统企业的线下场景为主，辅以互联网场景。其技

49、术架构设计，不仅要能支持主流与前沿技术架构，还要兼容大量传统应用。拒绝敏捷开发，对分布式和微服务架构持谨慎态度 对于大量企业应用，业务需求有明确的业务确认方，因此华润数科的研发团队并不照搬互联网模式“敏捷开发”模式。“必须是先想明白，想明白了，业务确认了再来做，这样才能做出好东西来，这一点是跟很多互联网企业有很大的差异。”据肖海山介绍，华润云的整个架构设计是进行了充分的研讨过后才定下来。而华润云下面所有产品的架构设计都需要经过他亲自把关判断产品适用于哪些行业、哪类企业、多大规模和处于什么发展阶段的企业等，而这些判断背后的依据是其过去十余年的咨询经验以及在华润工作十多年的经历。除了不照搬敏捷开发

50、模式，华润云也不推崇大量采用分布式、微服务等前沿技术架构。微服务架构体系在前几年就已经非常流行，尤其备受各大互联网公司青睐，微服务允许研发人员以松耦合的模式来开发应用，尽管其具备灵活部署、可扩展、技术异构等优点，但同时也大幅增加了所需的服务器等资源成本，也显著增加了后期运维的复杂性和成本。对大多数企业应用而言，大量应用微服务、分布式技术最后往往得不偿失。5 中国卓越技术团队访谈录2022 第三季 事实上，团队内部对于微服务的采用与否、如何用产生过不少思想碰撞。肖海山一开始便对微服务持谨慎态度，“微服务的理念很先进，它并没有错，但很多企业应用要全部走到微服务这一步，还需要很多年，投入很多成本。”

51、但由于华润云研发团队在组建初期从互联网行业吸纳了很多人才，因此也有不少人是倾向用微服务模式。等真正用过之后，大家才逐渐发现，微服务架构反倒会让产品研发效率变慢，并且需要非常多的服务器资源才能部署出一套系统。以华润云门户为例，在产品设计之初就采用微服务架构，投入大量的人和资源，最终做出来却发现业务侧的可配置性存在较大的问题。“大家一开始容易把大量的时间和精力花在微服务的设计上，而对业务侧的可配置性欠缺考虑，不够重视。因为大家原来在互联网公司都是专注做某款面向 C 端客户的产品，而不是卖软件，采用敏捷开发模式，产品体验有不合适就改，快速响应变化，不断迭代。”但是要卖软件，这要求他们做出来的东西具有

52、高度可配置性，面向不同企业可以做动态调整，提高项目开发效率。到 2021 年，肖海山意识到这样下去行不通，每做一个项目都需要投入大量的人做研发，成本太高。他决定大面积改造华润云产品把微服务颗粒变粗，把“写死”的代码变成可配置化。“这是个很痛苦的过程。”除了云门户，肖海山表示，像监控中心、ITSM（IT 服务管理）等好几个产品项目最终都被强制改过来，还是微服务架构，但颗粒变粗了、可配置性也变强了，客户部署起来也简单很多。“微服务的方向可以走，但是不要走太急，微服务的做法可以有，但是不要拆得非常 6 中国卓越技术团队访谈录2022 第三季 细，我们还是要选择一个平衡，就微服务颗粒度要科学、要合适，

53、这样才能保障在有限的人、有限的资源的情况下，让产品做得更好。”聚焦大中型企业数字化转型各方面痛点，华润云采用了一套独特的云架构，从底层 IDC共享到整个 IaaS、多云管理平台，再到各种能力中台。这套能力中台能让企业快速实现数字化转型，让企业仅用很少的 IT 人员就能完成数字化转型，只需极少人员即可运维。总的来说，从华润云的观察和实践来看，传统集团型企业对云计算的诉求，IaaS 是占比最小的，但也是“最特别”的。传统集团型企业要求的不是提供多厉害的弹性服务，更关心的是所提供的服务性能有多好、稳定性有多高、运维有多简单。数字化转型策略 华润集团采取“云优先、智生长”的数字化转型策略。“云优先”是

54、指华润集团借助云计算这样一个高效和安全的平台，作为华润集团未来 7 中国卓越技术团队访谈录2022 第三季 信息化建设、数字化转型、智能化发展的基础，帮助华润集团更好地落地各种转型，同时赋能华润数十万家上下游企业和行业伙伴。“智生长”是从业务价值的角度出发，拥抱新一代信息技术，探索符合行业特性、华润特性的数字化转型道路，鼓励探索新模式、孵化新业态、培育新产业，塑造新的核心竞争能力。显而易见，在该策略下，云是数字化转型历程的前置条件。其主张新业务尽可能云上部署，已有业务逐步云化部署，进而结合自身的产品优势，逐步实现数字化、智能化转型升级。从观望到信任 过去两年多，随着华润云平台不断迭代，目前华润

55、云的 PaaS 及 SaaS 产品序列在华润内部已经覆盖了 26 个业务单元。尽管是华润集团统建，但这朵华润云，在刚面世之时还是会引来不少质疑声。从在内部被质疑到被信任的这个过程，肖海山认为大致经历了三个阶段。第一个阶段是观望，这时华润集团内的各个板块、各业务单元均在观望，大家都等着看集团“敢不敢上”、“上得怎么样”。因此，首当其冲的必须是华润集团总部的财务、人力资源等多个核心系统，“因为你敢把财务搬上去，敢把人力资源搬上去，就说明这个平台是足够稳定，因为如果财务、人力资源系统搬上去华润云后出了问题，那无疑会波及华润集团两千多家子公司和 37 8 中国卓越技术团队访谈录2022 第三季 万人。

56、”“开始搬集团的系统的时候，产品团队的人着急，其他平行部门也不放心，就觉得 万一这个不稳定，出了问题责任在我身上怎么办？”肖海山回忆到，“我劝说没关系，第一，出了问题责任都是我的。”“第二，你先搬一些系统来测试，你先上去看看。测试没问题再搬生产。第三，反正我兜底了，出了问题任何责任都是我的，他们就放心了，那就搬。”当集团敢于把总部系统搬到华润云后，其他一些业务单元也开始“将信将疑”地上华润云了，这时开始集团上云进入第二阶段。肖海山回忆道，当时某个千亿级单位的财务系统上云之后，整体性能提升至少 5 倍。上云后程序运行跑得快多了，这种变化让业务侧很是感触。据悉，在华润万家的财务系统上云之后，华润万

57、家财务特地给华润云发了封感谢信。对于华润集团内的许多一线业务单位来说，系统运行“效率低、性能差”是老大难问题，而有着架构师背景的肖海山也意识到这跟架构性能问题有很大的关系。因此，在思考“如何在不给成本带来很大的变化的情况下，能让企业有上云的动力”之时，他想到的突破点是“性能”，“上云之后，我要让大家明显看到性能带来的巨大变化。”系统性能可以说是华润云架构自设计之初就被重点考虑的因素。另一方面，架构的安全可靠也是核心要素。肖海山表示，以往数据中心传统资源池，每年至少会发生一次重大安全事故。而华润云上线之后，至今出现重大安全事故的次 9 中国卓越技术团队访谈录2022 第三季 数为零，其架构在设计

58、之时就奔着“不允许任何一个单台物理设备的故障影响业务”的目标而来。进入第三个阶段，华润集团旗下多个业务单元对于华润云产生信任，纷纷主动找上门，希望能尽快搬到云上。肖海山强调，华润云给各业务单位带来的明显变化是可以用财务指标来衡量的。以华润万家财务系统为例，其上云之前每年在 IBM 小型机折旧加维保的成本大概在 100万至 200 万，而从 IBM 小型机换到云上后，其一年只需花费 20 万便已足矣。上云的价值 从上云的出发点和路径来看，华润集团旗下企业上云可以大致分为以下三类：1.第一类是响应集团战略，将系统搬至云上。很多系统的架构无法进行大的调整，就直接迁移上云，并做架构高可用的优化调整，同

59、时也去掉了小型机。2.第二类是为了降本增效，希望通过上云能省一些资源，整体容器化，应用代码和架构不做任何改造，也可以大幅度提升资源利用率。3.把应用做微服务架构改造，再单独容器化。“目前第一类占比居多，第二类和第三类加起来的比例不到一半。”肖海山坦言，过去华润在信息化过程中购买了许多套装软件，这类软件难以改造，要将其都解耦重构需要一定的时间。那么，在 IT 资源有限的情况下，基于华润云的 PAAS 能力，如何让数字化转型可以更 10 中国卓越技术团队访谈录2022 第三季 高效地推进？肖海山举了个华润建筑重构 ERP 的例子，其中发挥核心作用的是华润云PaaS 能力平台：“数字化平台”。为优化

60、建筑行业管理效率，已经使用 5 年的 ERP 已经成为企业数字化转型的障碍。华润建筑需要逐步解耦其 ERP 系统核心模块，以开发出更符合其业务需求的建筑行业核心平台。“基于华润对传统企业业务的场景的理解，我们把很多常见的、共性的东西，全部包装成了标准组件。”肖海山进一步介绍道，数字化开发平台具有完备的技术组件、通用组件、开发工具能力，让企业可以在不增加 IT 人员的情况下，进行数字化转型，通过小步快跑的模式，低成本高效率完成大量数字化转型应用的建设。最终，华润建筑 ERP 改造任务仅花费一年半时间以及投入 12 个人便完成。华润集团内现有超过 5 家单位基于数字化开发平台进行 ERP 系统的解

61、耦重构或新增的大量数字化应用建设。SRE 一体化运维 在华润集团实现整体上云的过程中，SRE 运维团队起着关键作用。目前，该团队主要面向华润集团内外部提供一体化运维服务（如整体运维、整体上云、国产数据库迁移等）和运维体系咨询规划及建设。据华润数科华润云事业部 SRE 服务部技术总监冯铮介绍，目前 SRE 运维团队规模约100 多人，技术栈覆盖操作系统、数据库、容器、中间件、大数据、集成，以及重载商业套装应用系统 Oracle EBS 和 SAP。SRE 紧紧围绕着华润云的愿景与目标，提供 11 中国卓越技术团队访谈录2022 第三季 华润云整体上云+一体化运维服务的一站式解决方案。”上云迁移是

62、一项复杂而严谨的系统性工作，在进行上云迁移过程中，必须要有一套完整周密的方法来指导、支撑上云迁移过程。冯铮表示，针对某项上云服务，华润云 SRE团队基本上先对其系统架构进行梳理和评估，比如现有的架构有哪些缺陷和问题，如何让架构变得更科学，通过哪个上云方案能够达到什么样的效果等等。据了解，SRE 运维团队所提供的上云服务主要涵盖 6 大步骤：系统现状梳理和评估：采用“调研模板+现场/远程访谈”的方式，对企业系统现状进行收集、梳理和评估；上云技术路线规划：遵循“可落地、可优化、可迭代”的原则建设技术体系，规划适合企业的上云技术路线；试点上云规划：选择和规划合适的上云试点，对后期上云技术路线规划、云

63、平台特性验证提供参考；整体上云规划：基于上云迁移策略要求，制定系统迁移计划和方案、风险应对方案等，并建立团队提供及时响应和服务保障支持；试点/整体上云实施：提供详细的需求调研和方案设计，通过评审、测试等机制，确保上云实施的执行结果与计划的一致性。信创迁移服务：基于华润云自研全国唯一的信创一键切换平台，能够快速将原来大量存在的国外数据库迁移到国产数据库，确保数据库结构、数据、程序的全自动处理。同时，团队经过长期迁云实践，总结出一套通用上云迁移管理流程“四阶八步”，为集团及各业务单元在实施云迁移工作时提供方法指引和参考：12 中国卓越技术团队访谈录2022 第三季 四阶：迁移准备、迁移实施、系统测

64、试、割接上线。八步：1.迁移准备；2.云资源申请；3.数据库部署；4.应用部署；5.功能验证；6.集成测试；7.数据同步；8.业务割接。“上云不仅是物理位置的变化，更重要的是一次架构梳理、优化提升的过程，其目的在于提升 IT 管理水平和管理效率。”冯铮强调道。数字化转型不只是 IT 的事情 上云，一方面是为了资源层面的成本下降，其更多的价值体现在企业的信息化、数字化、智能化建设的全面铺开。如今，华润云已在华润集团全面应用，华润集团下属 25 个行业全面使用华润云，华润集团系统上云比例超过 99%，上云应用系统共计 800 多个；数字化方面，华润云提供完整的数字化解决方案，已在快消品、燃气、水泥

65、、医药、电力、地产等 8 个行业应用，涉及 100+个 PC 数字应用，40+个移动应用。华润云上线后，华润集团整体的资源交付效率提升 432 倍、基础设施成本降低 30%、项目建设效率提升 70%、项目建设成本降低 45%。“企业数字化转型要回答几个问题，第一，为什么转？第二，往哪里转？第三，怎么转？”肖海山总结说，从企业侧的角度，数字化转型可以分为三大类型：企业战略转型。基于自身行业化的特点，再结合数字化的技术，衍生出一种平台级或者生态盟主级别的新业务模式。而战略转型也分为主动战略性和被动转型，主动 13 中国卓越技术团队访谈录2022 第三季 转型的企业很罕见，一万家企业可能只有一家企业

66、发现主动战略转型的机会。被动转型则比较常见，来自异业竞争、互联网跨界等等威胁，行业龙头企业需要积极应对，躲不掉就要直接面对。企业生态转型。数字中国下的企业，必须匹配数字生态，离 C 端越近的企业被迫响应社会的变化，C 端上游也被迫跟着变化。这时候企业进行生态转型的选择主要有二：大企业主动打造生态，基于企业的行业领导地位，让行业的上下游以我为中心，巩固企业的生态地位，共同抵御异业竞争的行业冲击；中小企业加入行业生态，融入互联网的数字化链条。加强自身的企业核心竞争力，在生态中保持存在的地位和价值。管理、运营和用户体验的转型。让传统的信息化从办公室走出来，让信息科技服务能覆盖到企业的方方面面，让原来

67、想管但管不了的场景有科技支持，让信息科技服务所有必要的业务场景，进一步降本增效、提升体验、节能减排等等。进入数字经济时代，数据被视为生产要素，针对有些企业一做数字化转型就先建个大数据中台的现象，肖海山认为这是典型的“没有从业务的角度来看 IT 的作用”的体现。“很多时候企业没想明白，只简单把数字化转型的事当做 IT 的事，IT 只是工具。数字化转型永远是业务的事。”在肖海山眼里，企业做数字化转型必须先把业务场景想明白，比如在什么场景下需要数据、需要什么数据、需要用数据创造什么价值等等，否则建设的大数据中台只会沦为摆设。“把业务想明白了，这时 IT 配合去落地就行。用最快的速度、最低的成本帮业务

68、做出来数字化转型的效果，这就是 IT 应该带来的价值。”这也是华润云的使命所在，从业务价值的角度出发，以云为基础平台和技术，把有限的 IT 资源放到创造价值最大的领域，推动华润集团“上云用数赋智”，为华润集团及旗下业务单元的数字化转型提速。14 中国卓越技术团队访谈录2022 第三季 突围电商大促场景，得物在高可用上的探索与实践 采访嘉宾：金思宇、陈贞宝、胡强忠 编辑：辛晓亮 大型电商系统并非一开始就具有完整设计的高可用特性，而是随着用户的不断增加与业务的快速增长逐步演进与完善的。当前高可用架构体系是互联网企业系统架构的基础要求，随着公司的业务发展，尤其是对于电商平台，每次发生稳定性故障带来的

69、影响越来越大，提供稳定的服务，保证系统的高可用已经变成了整个技术部面对的问题。基于此，我们深度采访了得物技术团队核心成员，探索他们在高可用架构上的实践、演进，深入了解大促备战是如何进行的？异地多活体系是如何建设的？全链路压测是怎么实践的等过程。得物高可用架构演进 和大多数互联网公司一样，得物目前也是采用主流的微服务架构来应对高可用的挑战。同样的，得物也是从大单体演进而来，经历了涵盖服务规划、服务拆分与合并、存储拆分等过程的微服务构建，集成并自研了基础开发框架及其脚手架、微服务通讯框架、微服务治理体系、微服务生命周期管理平台、微服务支撑基础设施、微服务安全设施，从大单体架构逐步演化成微服务架构。

70、15 中国卓越技术团队访谈录2022 第三季 在这一过程中，得物结合自己的业务背景，自研了符合自己特色的微服务架构支撑平台，比如网关、流量回放平台、预案平台、DAL、全链路压测平台、灰度发布系统、微服务发布平台、微服务统一调度平台等，并在分布式核心场景中沉淀自己的最佳实践设计，如服务的无状态化、服务的幂等、分布式锁、分布式事务、缓存失效的设计等。回顾过去，得物高可用架构的整体演进与中国电商平台的业务架构的演进阶段比较相似，大致可以分为四个阶段。第一阶段，得物早期，业务场景比较简单，功能不复杂，团队的规模也较小，使用的开发语言是 PHP，采用的是单体架构，在高可用的建设上也比较少，当时的主要目标

71、是为了快速满足基础的交易需求。随着业务规模的逐步增大，团队规模也越来越大，单体架构已经不能支撑业务的快速发展。得物开始做架构升级，语言从 PHP 转到了 Java，框架上使用的 SpringCloud全家桶，业务域也进行了拆分，独立出了订单、出价、优惠、商家、商品几个应用，但这个阶段在服务治理上的建设还比较薄弱。时间来到 2019 年下半年，由于业务发展速度太快，得物的交易系统开始暴露出更多问题。一方面系统架构无法承载高并发的流量，经常出现性能问题；另一方面，前期业务模型的设计对日渐复杂的业务需求支撑也不友好。于是得物启动了“五彩石项目”，按照领域驱动设计的思路，对得物交易体系重新规划和设计。

72、只用了 3 个月的时间，就完成了整个系统的重构。新的架构形成新的 6 个核心域，对大数据量场景也做了分库分表，得物也开始逐步建设自己的监控体系、服务治理体系、预案系统，在基础设施中不断升级，来确保系统的高可用。16 中国卓越技术团队访谈录2022 第三季 关联阅读：业务百倍增长，得物如何在三个月完成交易平台重构？第四阶段，随着业务的进一步快速发展，业务规模越来越大，对交易系统的高可用、稳定性有了更苛刻的要求。一旦业务出现问题就会被快速放大，甚至出现舆情。得物就在原有架构不断治理、升级的基础上，逐步启动了异地双活、容器化项目，让系统的高可用、可扩展、跨地域的容灾能力得到新的提升。异地多活混合云架

73、构体系建设 前文提到，得物位了应对规模更大更复杂的业务情况，在高可用架构上做了异地多活、多机房部署等升级。灾备架构选择 目前常见的灾备架构有冷备、热备、双活、多活等几种。冷备：只有主数据中心承担业务请求，备份数据中心定期同步主数据中心的数据或者在停机的情况下才开始对主数据中心的数据进行备份，当主数据中心挂掉，需要停机一段时间，手动拉起。从严格意义上讲，在当前对分布式系统高可用的要求下，冷备技术不能算真正的灾备技术，恢复时间过长，对业务影响较大。热备：只有主数据中心承担业务请求。主数据中心会实时向备份数据中心实时同步数据，当主数据中心挂掉，可以通过控制中心自动切换到备份数据中心，通过这种方式来实

74、现高可用。还有一种概念是暖备，与热备架构类似，只不过不能够自动切 17 中国卓越技术团队访谈录2022 第三季 换，需要人工介入。双活/多活：分为同城双活/多活，异地双活/多活，跨国多活。多个数据中心都会承担业务流量，不同的架构，在具体的落地细节上的复杂度也是相差较大。而且在不同的业务体系下，也会有不同的流量路由、机房部署方式。得物目前采用的是热备+双活的模式。热备成熟可靠，在存储层采用热备，发生故障情况下，可以快速切换到备份节点进行恢复，备份节点一般不对外提供服务，因此热备的资源利用率相对来讲比较低。此外得物双活，基于双数据中心，两个数据中心同时对外提供服务。这里杭州为主数据中心，主数据中心

75、承担主要的流量（一般为 70%），在发生故障时，将流量切换到另一个数据中心。双活资源利用率高，相对一个数据中心，更加的可靠，但是技术难度高，需要投入比较大的时间和人力成本进行技术建设，针对核心买家链路、微服务框架、微服务治理体系、微服务基础设施等做了相应的技术改造来实现。按需配置多机房部署方案 多机房部署模式一般分为同城、异地（跨城）、跨国几种，异地一般又分为远端城市和近端城市两种。一般情况在部署地区上有以下几个方面需要考虑：两个机房部署在同一个城市，如果遇到城市级别的停电或者自然灾害，很容易出现两个机房都不可用的情况，达不到灾备的要求。两个机房部署在异地，那么相对同城来说，同时遇到自然灾害的

76、概率要小一些。但是选择两个较远的城市还是选择两个较近的城市需要根据自己的业务场景、用户属性、数据同步延迟的要求以及实际需要解决的问题来决定的。18 中国卓越技术团队访谈录2022 第三季 选择两个比较远的城市，比如北京和深圳，那适合的业务场景是对用户以及中心数据进行分区，北方的用户访问北京的机房，南方的用户访问深圳的机房，比较适合本地生活服务类的业务场景。一个机房能够满足用户的实用需求，能够接受较长时间的数据同步延时。得物虽然是多机房部署，但不是这种模式，得物多机房部署的目的是可以对用户进行调度，当一个机房出现问题的时候，自动调度到另外一个机房，面临大流量或者促销活动的时候，通过流量调度来确保

77、系统稳定。而且对于目前电商的业务模式，商品中心的数据需要确保两个机房的实时性，远端城市的部署方式是不适合的。得物在综合技术、人力、业务复杂度、业务场景、时间成本等情况后，决定部署异地双活-近端城市的架构模式，后续会逐步演进发展到两地三中心、异地多活并且结合混合云的部署架构。异地双活要解决的核心问题是“确保在极端情况下买家核心链路依然可用”，聚焦于买家链路的稳定性保障。在故障发生时，能够将买家流量从一个数据中心调拨到另一个数据中心。从技术上，需要解决的一个难题就是如何确保买家跨数据中心调拨后，依然能够保证事务的一致性。这一点非常的困难。举一个例子，比如用户订单数据，该数据写入杭州数据中心，但是当

78、流量调拨到上海中心时，用户依然能够在之前的事务上下文访问到正确的数据。这意味着用户订单相关数据必须保证两个机房都能够正常访问到，即使数据双向同步。这里的数据会涉及到 MySQL、Redis、ES、HBase、MQ 等。同样的，这条链路的服务依赖需要隔离在 19 中国卓越技术团队访谈录2022 第三季 同一个机房，服务路由需要就近路由避免跨机房路由，具体一点，假设数据都存储在MySQL 的话，那么 DB 的数据就存在仅中心机房部署、中心写单元读部署、单元化部署（双边写并双边同步）。这就要求从基础设施到业务服务进行技术改造来实现。基础设施的建设与改造 为了更好的支持异地多活，需要做一些基础设施，为

79、双活奠定基础。首先需要做一个双活控制台，用于整体控制流量调拨并监控双活的运行状态。之后对基础设施进行技术改造以支持双活，在这里会涉及到网关 DLB 层、RPC 服务路由与注册中心、配置中心、MQ、TOC、Redis、MySQL、ES、HBase 等，还定制了数据复制中心（DRC）、数据巡检中心（DCP、DAL）来实现流量的调度。确保流量调度后，在新的数据中心能访问到正确数据，与之前事务上下文保持一致。业务系统的改造 业务系统的改造专注于核心买家链路，并不是对所有的链路进行单元化，有些面向 B端的应用系统甚至完全不用改造。不同的买家链路架构改造方式不同，比如库存链路的 DB 会完全采用中心化部署

80、的方式；商品详情链路中商品库会采用中心写单元读模式；订单链路则完全采用单元化部署方式。买家链路的改造需要从流量入口开始梳理，先进行单元化链路标记，接着梳理上下游，根据上下游是否需要单元化并进行改造。然后再梳理 MQ、Redis、MySQL、TOC 等中间件，确定相应的单元化方案。双活的业务复杂度很高，对业务系统的影响也比较大，得物目前一共有 70 多个业务系统涉及单元化改造。这么大的改造对测试同学的挑战也非常大，除了需要测试正常 20 中国卓越技术团队访谈录2022 第三季 的业务场景，还需要验证双活场景下的流量调度是否正确。高可用平台治理方案 应对“天灾人祸”为了预防突发事件，高可用架构需要

81、在设计时提前考虑很多的异常场景，即所谓的“天灾人祸”，比如机器宕机、集群节点宕机、网络抖动、网络攻击、下游服务异常、服务自身代码 bug、消息堆积等。因此在做技术设计&实现时要做好相应的防灾难设计与措施，比如通过机器冗余、集群故障失效转移、主从复制断点续传、业务隔离、性能压测、限流/降级、流量回放、变更控制等手段来保障系统的高可用。这里，可以把“天灾人祸”的原因归为几类：1）硬件问题，比如机器宕机、集群节点宕机、网络抖动、网络攻击，一般依赖于企业的基础设施和相应的支撑团队，这种情况一般通过灾备来解决和预防，得物通过自建异地双活来实现极端情况下硬件问题的故障防控。2）软件问题，比如服务本身异常、

82、下游服务异常、代码 bug、中间件异常等，这里是故障防控的重点，也是故障频发的部分。软件问题具体可以归因为：（1）80%故障是变更引起的故障；（2）流量和容量变化引 21 中国卓越技术团队访谈录2022 第三季 起的故障；（3）依赖故障；（4）机房、网络等环境故障；（5）其它：比如幂等失效、分布式 Id 溢出导致的故障。得物一般是建立变更故障防控、大促故障防控、日常故障防控，对软件问题进行预防，从微服务本身、微服务上下游依赖、微服务依赖的技术环境三个部分梳理潜在问题，并提前做好相应预案，在问题发生时可以通过执行相应的预案来预防和进行故障的快速恢复。3）人为问题，一般涉及到各种线上误操作，通过软

83、件产品自身的完备性、成熟的技术规范、操作 SOP、管控措施、CheckList 来应对。此外在得物的系统链路中都有自定义的限流、熔断手段，当埋点数据触发阈值时，会执行指定的异常处理方法，进行限流或者对下游进行熔断、甚至是通过业务开关直接对指定的业务进行降级。除了系统链路中自动的熔断、降级措施外，我们还在自研的预案平台中有配置的各种预案，当出现异常情况，会人工或基于埋点的自动执行，来实现优雅降级，确保系统的高可用。全链路压测平台 得物全链路压测平台于 2019 年 8 月底完成，在 2020 年的 618 大促首次使用生产环境进行压测，经历了多次大促实战，目前已经能够非常顺滑的验证核心链路应对大

84、促突增流量的稳定性。去年双十一和今年 618，在限流和预案开启或关闭的情况下，得物采用梯度递增、脉冲、稳定水位进行流量验证，分别经过 3 轮和 2 轮压测后，核心链路达到预期的压测目标，并且在大促当天所有核心链路均符合预期表现。得物整个全链路压测平台建设及实施涵盖了以下内容：22 中国卓越技术团队访谈录2022 第三季 1）由 Fusion 封装了压测接入 API，所有中间件必须按照统一规范接入和使用；2）构建流量漏斗模型，即外部流量从网关入口开始，在每个调用链路上的变化比例，流量配比参考历史双十一峰值 QPS；3）通过 Mock 模块处理外部依赖的调用链路；4）流量标透并建立影子中间件，包括

85、 MySQL、Redis、MonogoDB、Kafka、RocketMQ、HBase、ES、分布式锁等；5）流量标透传并进行核心链路改造，基于 Fusion 框架识别测试流量标，进行相应改造；6）建设测试环境和仿真环境；7）构建测试用户和测试数据；8）实施单机接口测试、单机混合链路测试、全链路压测。得物的流量标方案，就是要解决数据隔离问题，压测产生的脏数据不能写入线上环境，通过中间件平台封装的 fusion 脚手架，在 RPC、Redis、DB、MQ、跨线程中透传压测标，如果识别是压测流量，产生的数据会写入到影子库，以此来实现数据的隔离，确保线上稳定，为全链路的压测奠定了基础。在全链路压测平台

86、的建设中，我们也逐步摸索出了得物特色的全链路压测流程。得物的全链路压测流程包括：系统摸高，限流演练，预案演练。通过全链路压测，帮助发现系统性能瓶颈，限流配置，预案缺失等诸多问题。大促备战经验分享 大促是考验电商高可用平台的最好时机，首先作为前提的是，每一次大促都会有一个 23 中国卓越技术团队访谈录2022 第三季 目标策划，确定本次大促的业务和技术目标，之后进行大促备战。得物大促备战主要涵盖三个部分：1）整体稳定性保障；2）业务需求交付；3）组织保障。大促需要以保障稳定性为前提，做好按时的业务需求交付，同时整个组织需要具备强悍的项目管理能力。到目前为止，得物整个大促备战从整体保障、域内保障、

87、组织保障都有清晰的 SOP 和系统化的沉淀。一般分为启动阶段、规划阶段、各域执行交付阶段、压测&验收阶段、作战阶段、作战复盘阶段实施等等，大促备战是井井有条的。首先，得物有专门的 PMO 组织来整体保障需求的流水线交付，保障大促需求的按质交付，下面介绍得物的稳定性保障，主要分为两大部分：大促整体备战；各业务域备战。大促整体备战，顾名思义从全局视角关注突增流量对全域买家链路的影响，确保在大促当天这些核心买家链路应对突增流量的稳定性。因此，首先会先对业务目标进行拆解，之后确定各个链路的流量，做好链路的容量评估以及各个服务的扩缩容。之后会从链路的稳定性入手，梳理链路的架构风险、链路自身的风险，做好链

88、路的预案和演练。最后，通过几轮的压测，确保各个主要链路满足既定业务目标的流量。整体上会规划好大促推进的节奏，准备当天的大促备战。各业务域备战，则是围绕着业务域的核心链路稳定性展开，这些链路一般是 P0 链路，规划需要做的事情，并在总体节奏上符合整体大促备战的节奏。总的来说，链路稳定性保障一般会从几个部分来展开：1）架构大图、业务链路梳理；24 中国卓越技术团队访谈录2022 第三季 2）可见性建设；3）风险识别与架构治理；4）可控性建设。下面做简单描述。架构大图，涵盖业务架构、IT 架构，关于架构图，大家都很熟悉了，推荐一个架构模型C4，可以使用 C4 的 L1、L2 来清晰描述 IT 架构。

89、接着是域用例梳理，通过域用例推导业务链路，业务链路一般是域用例的顶级服务交互。一个业务链路的入口，一般就是一个服务，这个服务由服务自身、服务上下游依赖关系、服务依赖的底层技术环境（如 RPC、DB、缓存、MQ、Job、JVM、容器、物理机等）三个部分构成。通过架构大图、业务链路梳理，就可以把域内系统和链路描述的比较清晰，使我们对构建的系统就有比较全局性的理解。这一步相当于我们稳定性建设的目标判断。可见性建设，得物聚焦在系统监控大盘、业务链路大盘、域业务监控大盘，以及系统和业务链路精准报警几个部分构成。通过可见性建设，我们可以实时观测系统、业务链路的运行状况，及时发现正在发生的风险以及潜在的风险

90、。风险识别和架构治理，聚焦在链路风险识别并制定治理方案。有了可见性建设，我们可以从链路通讯的历史数据，主要围绕 P0 链路进行体系化的链路风险分析，一般涵盖架构变更风险、SLA 风险、超时和重试合理性风险、强弱依赖风险、链路调用风险、链路依赖技术环境风险、集群或拓扑风险等，之后针对识别的风险制定相应的架构治理方案。可控性建设聚焦于风险识别与预案体系。风险识别，我们会通过精准告警、SLO 巡检来识别，SLO 巡检有相应的 CheckList 判断是否系统有故障发生，并查看风险发生链路对应的预案。在故障发生之后，可以对故障快速定位和止损，理想的目标是每一个故障都有相应的预案应对。实际中，并不是所有

91、的故障都有预案，但可以根据历史故障和一些先验知识将故障进行归类，建立相应的预案。另外，预案要能方便执行和触发。25 中国卓越技术团队访谈录2022 第三季 得物在出价库存域大促稳定性保障方案，整体方案主要涵盖以下内容：大促作战手册：梳理大促前、大促进行时、大促结束时需要按照时间节点完成的作战事项；业务链路稳定性保障：容量评估、预案与演练、接口限流、流量治理、压测与复盘；架构治理：架构分析与核心链路梳理、慢链路治理、DB 治理、Redis 治理、JVM治理、定时任务/数据回流与商家后端管控；资损防控：梳理资损点、应急工具、处理 SOP 等；应急工具：数据核对、出价应急处理等。写在最后 高可用是互

92、联网企业系统架构的基础要求之一，从架构师所能解决的问题的能力划分，小到解决一个子域或模块，大到一个组织，要求的能力完全不同。架构师需要具备准确的定义问题能力和解决高可用系统面临的技术挑战的能力，这要求架构师具备强的思考力以及解决问题的技术能力。构建高可用的系统一般要求架构师能够：1）具备合理的架构设计推导逻辑；2）理解业务并将业务挑战映射到技术挑战；3）从 0 到 1 构建一个满足业务目标的高可用系统；4）在快速业务迭代演进的过程中保持系统高可用。首先，架构设计推导逻辑，是架构师最基本的要求，要求架构师能够从用户问题洞察出发，理解用户问题的解决路径，定义商业流程及组织角色，构建出系统业务架构；

93、接着，从业务架构推导 IT 架构，即应用架构、技术架构和数据架构。这就要求架构师 26 中国卓越技术团队访谈录2022 第三季 具备架构分析、设计的相应方法论、工具。比如 TOGAF 企业架构方法论、DDD 方法论、C4 架构模型、UML 建模工具箱、四色模型等等，形成一套自己实战的方法论。第二，理解业务并将业务挑战映射到技术挑战，就要求架构师在业务理解下，能够设计合理的架构方案并引导架构活动实施。架构方案要从明确的业务或技术目标展开并对目标合理性进行一定的干预，基于当前的商业环境、企业技术基础设施、企业技术文化，在有限资源和成本约束下，通过合理的架构活动满足目标用户需求，最终确保技术方案实施

94、能够实现商业价值。架构师不是仅仅解决用什么技术、什么架构去实现的问题，而是要考虑业务的方向，从技术角度如何合理的实现，为企业业务支撑带来更高的 ROI。最后，架构师需要具备较强的微服务架构及其支撑的基础设施相应储备，微服务架构一般包含服务拆分与合并、微服务开发框架、微服务治理体系、微服务生命管理平台、微服务支撑基础设施、微服务安全体系等等能力。整体知识非常的庞大，当架构师对微服务架构有深入理解和支撑基础设施较为广度及深度的知识储备，并且通过实践进行验证积累实践经验，就能够从高可用目标出发，进行合理技术选型，实现服务规划、构建和治理，使得服务构建和之后的演进都能满足高可用目标。27 中国卓越技术

95、团队访谈录2022 第三季 嘉宾介绍 金思宇：得物技术 Leader 毕业于东北大学，先后在中兴通讯、阿里巴巴、唯品会任职，并有 2 次创业经验。对电商及上下游有比较丰富的开发及业务架构经验。19 年加入得物 App，目前主要负责交易平台及中间件平台，带领团队支撑得物 App 交易域的业务需求，完善业务基础能力；同时负责中间件团队的管理及技术演进规划。陈贞宝：得物出价&库存 Leader，曾在 Sybase、厦门锐特、阿里巴巴任职，有 5 年创业经历。曾负责 2 次 S 级大促以及多次的域内稳定性保障，在架构设计与治理、大促稳定性保障有较多实战经验和体系化思路。21 年加入得物 App，目前主

96、要负责得物出价&库存团队，带领团队完成技术规划、业务交付、稳定性保障等工作。胡强忠：得物业务架构师，曾在中国航信的不同分支机构任职，有过一次创业经验。对 OTA、电商行业有较丰富的开发、架构经验。19 年加入得物，目前主要负责交易域的架构演进规划、业务领域建模、稳定性治理等工作。28 中国卓越技术团队访谈录2022 第三季 用三年替换掉二十年老系统，民生保险数字化转型秘籍 采访嘉宾：沈勇毅、孔伟、苏彦春 作者：Tina 作为传统 IT 铁三角的核心腹地，金融行业过去十年的“去 IOE”运动备受关注。这种在过去 30 年中被广泛使用的集中式架构逐渐难以适应金融业务的线上化、数字化、智能化需求，正

97、在逐渐被替换。因为需要修改底层技术，涉及到很多代码的重写、技术架构的重组和迁移，去 IOE 基本上是一种“小步慢走”的过程，本身就是 5-10 年的工作。金融行业的变革从银行开始，逐渐带动了保险行业。这几年保险行业的数字化转型走得特别快，一众头部保险公司都在自我改革以适应时代的改变。金融企业的数字化转型，通常是规划长远、实施复杂的项目，需要有懂技术、有大型项目经验的人，做出既稳妥又大胆的决策，而一般的企业不可能无限制在技术上进行投入，那么在投入有限、人才缺乏、技术实力储备不足等刚性约束条件下，转型之路究竟该怎么走？绝大多数机构并没有清晰的答案。作为一家中型金融机构，民生人寿保险也曾面临上述困难

98、。2019 年的时候，民生开启了一场快节奏、深层次的数字化转型，将用了近二十年的架构，一举搬上了混合云架构上。原来需要 5-10 年时间的项目，也只花了 3 年就宣告完成。民生保险探索出来的这条数字化转型路径，或许也能给亟需变革的其他中小型企业带来一点启发。29 中国卓越技术团队访谈录2022 第三季 重构核心系统，一次性到位进行转型 在1955年首届财富500强名单中，只有12.2%的公司在2014年仍然保持在该位置。虽然一些下滑是因为品牌重塑或并购，但其中大部分反映了许多曾经的大牌未能在现代社会中生存下来的事实。在技术不断进步的环境中，未以正确的方式接受变革并进行创新，这些衰亡的企业是带有

99、警示意义的例子。一般企业都是循序渐进的发展，但是新技术的革新，让企业的 IT 环境可能进行革命性的变化，没有壮士断腕的决心，可能真的无法适应业务的发展而被淘汰。一边是当前企业都有变革的压力，另一边是金融企业里的特殊现状。金融行业有自己的特性，使用的是一些成熟的技术或者在其它领域已经应用多年的技术。而现在，数字化转型普遍是将已有互联网的技术、流程、实践置于服务的构思和交付方式的核心。这也就是说，彻底、全面的转型意味着“不破不立”。民生人寿保险面临的状况也是如此。在 2003 年成立的时候，受制于当时的技术环境，民生人寿保险采用了传统的 IOE 架构，以及单体应用。技术架构的层面发展到现在，已经变

100、得陈旧，应用之间的耦合度也非常高，很难去适应现在快速业务的变化。在过去二十年的时间里，民生保险在集中化的 Oracle 数据库中积累了大量数据，但各方面的指标口径没有进行统一，数据也缺少标准治理。民生保险的转型目标是，用“民生保险”公众号和官网将 90%常用的业务实现线上处理、用“掌上民生”实现保单销售全流程线上化，通过引入人工智能实现运营服务的自动化，打造了“业务中台”和“数据中台”双中台模式，以支撑公司转向以客户为中心的经营 30 中国卓越技术团队访谈录2022 第三季 模式。图源：https:/ 技术选型是项目中最大的风险点 寿险行业的数字化转型在此之前并没有成熟的案例。作为求稳的金融企

101、业之一，民生保险没有在老系统上进行“修修补补”，而是进行彻底变革。民生新一代的 IT 建设分为两大部分，一部分是建设新一代的业务核心系统，另一部分是重建技术架构。在基础架构选型的时候，民生保险探索过多种路径，包括超融合，自己搭建Kubernetes集群支撑应用，基于 MySQL、PostgreSQL、CDH 用开源搭建大数据平台，但考虑到 31 中国卓越技术团队访谈录2022 第三季 使用的效果和维护的成本，最终还是放弃了完全使用开源的实现方式。原来使用的 Oracle 产品有自己的特色，能同时适用于交易场景和分析场景，所以在这一块儿上并没有一个对等的可取代它的软件。现在，互联网的实现思路是将

102、交易型的数据库和分析型的数据库拆解开来，再加上大数据平台去做海量数据的建模或者计算能力的支撑。基于此，民生选择了分布式数据库 TDSQL、TBase 等来替换掉 Oracle。同时考虑到新一代的业务架构是基于分布式 Kubernetes 集群，适应未来 5 到 10 年的发展变化，核心应用比较倡导微服务网格化和基于云的研发应用一体化的模式，所以底层基础架构一开始定位为公有云服务。但在把主流国内云厂商看了一遍之后，从数据资产的私有化来考虑，发现公有云的方式不完全满足现在金融行业的需求，于是民生保险跟腾讯深度合作，为大部分的数据和核心应用建立了一个私有云，再用公有云承载对外流量，以及实现活动场景下

103、的弹性扩展预留。新一代业务系统和新一代云数据中心都是采用的最新的技术，跨度很大，选择新技术也意味着接受挑战。针对复杂的技术和业务场景面临很多未知的情况，前期在做第一轮试验性“掌上民生”App 产品时候，怎么运行，怎么快速解决技术上的问题，没有一个可以用来参考的标准，还需要充分融合整个应用架构和云平台 PaaS 的能力，来寻找一个最佳的均衡点，所以这个项目中最大的风险也是来自于初期。整体的架构设计和探索“花了大概 5、6 个月的时间才能定下来”，民生保险数据服务部副总沈勇毅表示，这也是整个项目开头最难的一个点。32 中国卓越技术团队访谈录2022 第三季“采用新技术总会有一定的风险，作为吃螃蟹的

104、人，总归是要慢慢摸索”，沈勇毅介绍说。但经过了半年的并行期以后后面就很顺了，因为已经很清晰地知道自己的技术路线怎么走，业务转型的时候要考虑哪些问题，就相对来说按部就班地去做，只是看时间到底拉的多长。传统金融机构的技术架构升级有着复杂的步骤，比如先建立一个数据中心，再建立第二个数据中心，逐步考虑兼容，是一个 5 到 10 年长远的发展过程。民生保险的数字化转型从 2019 年启动，采用比较先进的混合云基础架构和云原生的业务架构，一步到位地实现了两地三中心、同城双活、灾备，到投产上线、存量迁移，总共只花费 3年时间，创造了一个行业里少见的案例。技术投入要讲究一个“均衡点”CXO 控制着整个项目的风

105、险系数。在企业的转型过程中，技术只是一个应用，任何改变，如果没有考量到“人”的因素，必然无法达到真正的转型。人的因素可以分为两个部分。一方面是面向“消费者”。数字化转型的根本起源是“业务诉求”。因为人口众多，所以各行业都大量增加了线上业务，进行深加工，所以底层的数字化转型它其实不是一个技术层面的推动，它是一个业务层面的推动，是出于业务的需要。民生保险在转型是将视频、图章、监管、报送等等这些系统业务进行线上化，线上业 33 中国卓越技术团队访谈录2022 第三季 务还需要有数据的二次加工和分析。在具体业务场景上，推动业务层面去使用“新技术”，改变业务模式、运营模式、服务体系，这些都是面向消费者的

106、事情。另一方面，“组织内部的人”更是转型的成败关键。技术和产品的问题总能够去解决，引入新技术不是最难的事情，这可以通过引入比如腾讯这样的云服务商作为合适的合作伙伴，借助于各行各业的经验支撑技术的转型。而业务上的问题，主要靠组织和管理层面。“一把手”董事长的决心和战略决定了“转型”的基调，然后管理层才能从公司层面明确建设目标，制定规划，内部各部门的协调和合作，从顶层向下推动整个公司转型。在数字化转型中，CTO 或 CIO 也起着比较决定性的作用。一方面，作为“总设计师”，他需要根据企业的实际情况来去选择一个最佳的路径。数字化转型的路径不止一种，基础好一点的可能循序渐进，每年可能动一点点，但是它的

107、代价可能是花费的时间会很长很长。之前的基础差一点的，在技术大的变革时代，可能采取相对大胆激进的策略，能够在比较短的时间内能实现弯道超车，达到既定的目标，但是可能执行起来的整体风险也会比较高。一步到位还是逐步迭代，这些需要CTO 或者 CIO 来做决策和选型。“CTO 控制整个项目的风险系数，在不同的阶段去调整不同的风险”，作为民生保险信息化服务部门负责人，沈勇毅的角色也相当于 CTO 或者 CIO。另一方面，CTO 还需要靠确定整个组织架构，构建符合数字化的新的人才和体系。“民生这个项目的周期跨度 3 年，这也是我们有史以来最长的一个项目。参与的人数 34 中国卓越技术团队访谈录2022 第三

108、季 也很多，就我们自己民生和各个厂商的参与人数基本上全部加起来高峰的时候有 400-500 号人。”在多厂商的管理上，合作能力的配合上，实施能力的管理上，包括民生自己内部多部门的管理和协调上，其实都有一些挑战。另外是人员能力，涉及到很多新技术引入，虽然很多新技术在互联网行业已经成熟，但对民生这样的一个金融企业来说，这个技术却是全新的。对民生保险来说，项目的实施需要很多懂技术，又有很多有大型项目经验的人员去推动。而且项目实施之后，技术怎么去沉淀，怎么去传承，怎么去保证确保所有的技术迭代和稳定的运转，这都是需要想办法解决的问题。这也是大多数转型中的中小企业需要面对的问题：作为一个甲方企业，不能无限

109、制的在技术上去投入。沈勇毅表示技术人员的投入也要讲究一个“均衡点”，民生的办法是借助于腾讯这样的厂商来接一部分基础云平台的部署和持续运维问题，同时也要清楚双方边界。但在应用层面还是要做到自主可控，培养自己的技术队伍。民生已经有专门的技术架构的团队，也是为了适应整个云的变化，近几年重构了这个团队，从原有的 IOE 的模式直接进行了转型，更多地去实现管理的职能或职责，做好资源分配和运用。切割二十年的老系统 民生保险混合云有着自己的模式，基于国产自主生态的私有云、公有云、信创云混合的新一代基础设施。35 中国卓越技术团队访谈录2022 第三季 民生将内部区域划分为几个大功能区，公有云更多是服务一些外

110、网的业务，比如官微、官网、掌上民生。在项目实施过程中，开箱即用的公有云还承担着一个比较大的作用，就是在紧急的时候充当测试环境，毕竟私有云的搭建还包括购买服务器和网络等。办公和核心放在了私有云上，这也是比较传统一些的 IT 交付模式。私有云基于腾讯云专有云全栈解决方案 TCE（Tencent Cloud Enterprise）打造，包括 70%节点基于通用 x86 架构的私有云和 30%节点基于全国产芯片为基础的私有云。腾讯专有云和公有云由同源同构的一套代码实现而来。腾讯专有云在金融行业落地时，还在网络、硬件、服务、网络安全、防护上，针对金融用户的属性做了深度定制。作为腾讯云金融的主打技术产品之

111、一，TCE 最早的实践案例可以追溯至微众银行，逐步扩展到交通、工业制造、传媒、零售、政府、泛互联网等行业，打造了建设银行、深证通、中国银联、永辉零售云、央视频等多个行业标杆。据腾讯介绍，TCE 本身历经数十次版本迭代，增强的功能和特性超过 500 项，涉及代码数百万行，也有完整的交付管理流程和自动化工具，从需求调研包括高低阶方案的设计，到基础设施包括云平台的实施，以及数据跟业务的投产迁移。民生保险于今年 5 月 1 号开始切割，当时处于疫情全封闭的状态，数百名项目参与人员居家隔离，实现远程“云上线”。关键线上业务还挺多，需要去做一些协同和管理。“大家都是各自在家里，去做了一个这么大的切换。这还

112、是挺厉害的”，沈勇毅感慨。项目切换过程中，大家的工作有一个“完整的清单”，每一个任务由谁负责，大家都要清楚自己在做什么，明白自己执行到了哪一个步骤，都需要非常明确和细致。在各个组织结构上分得很清楚，由“总控”去整体把控，底下有各个执行组、指令组，各个平台的支撑组、支持组，还有各模块的用户验证组，以及腾讯也有一支支持队伍，大 36 中国卓越技术团队访谈录2022 第三季 家不断地相互之间去协调和通信，经历一个月的多轮预演，最后正式切换。难度和风险最大的有两个，第一个技术选型，在第一次引入新技术试错的时候，第二个是最后一次性切割的时候。“按照我们现在整个策略，迁移过程当中绝对不大会有一次性迁掉的那

113、种模式，但是就算分阶段，分步骤慢慢去切割，到最后也有一次整个的最后切割。就像 5 月份云切割就是最终的一个版本，最终的一个全量的扫尾切割。失败的可能性最大的就是存量扫尾切割这一块。”“因为所有的历史的问题，历史的债，肯定需要在那个点上做一个切割和梳理。我们也是一个快 20 年的一个公司，那么积累的历史问题不会少。其实在最后一次迁移过程中，我们还是遇到了一些不一定需要临时去解决的问题，这些问题我们会放到后面慢慢再梳理。”减少风险的办法，就是“最后一次切割之前，一定要把风险看得清楚，把问题理得清楚，再去做这件事情。”如今，“新一代”的业务系统已经稳定运行数月，各方面能力得到了明显提升，也曾在切割之

114、后支撑了民生有史以来并发量最高的一个业务节点。另外，云平台成本提供同样的计算资源的情况下，要比原来至少节省一半以上的成本。且从安全性上来说，应对一些重保也是会比原来要好很多。37 中国卓越技术团队访谈录2022 第三季 写在最后 数字化发展和数字化转型已成为全球多个国家的战略。可以说企业进行数字化转型不是可选项，而是必答题。企业数字化转型的动力也是现实的：在疫情时代，数字化协同能让企业能够去高效地运转下去；线上化和新渠道上的用户运营是企业活下去的关键动力；新技术能够更加地降本增效，提升服务体验。民生保险的弹性、稳定的云原生方案，也是保险企业转型的一个典型样本。对比国内外保险行业，沈勇毅认为，无

115、论是全球还是亚洲的同类企业，虽然他们在业务逻辑设计和敏捷方法论上更为先进，但国内企业借助敏捷加上分布式交付，以及云厂商的成熟运转模式，在引入新技术的速度上比国外企业要快不少。服务过几千家金融企业的腾讯专家也表示，不管在保险行业还是在金融行业，甚至在一些现在比较特殊的制造行业来看，中国在各个业务场景，各个行业的业务场景上面是足够丰富的，也是领先于其它国家的。在使用所谓的互联网技术或者使用所谓的数字化转型技术上，几乎所有的行业都不落后于国外，甚至快于国外。最重要的是，互联网企业在创新和创造的过程之后，能将这些技术变成了一种成熟的基础架构技术，赋能给金融行业、制造行业等，让这些技术应用得比国外更快、

116、更强。采访嘉宾 沈勇毅，民生保险数据服务部副总经理 孔伟，腾讯云专有云产品中心首席产品架构师 苏彦春，腾讯金融云交付总监 38 中国卓越技术团队访谈录2022 第三季 从基础架构到用户体验，字节跳动是如何打造移动端架构团队的？采访嘉宾：孙念、杨萍 采访：Tina、闫园园 编辑：闫园园 2012 年，字节跳动成立，到今年，正好是它的第十个年头。虽然在年龄上，这家公司还非常年轻，但从影响力上来看，它早已成长为移动互联网时代的新兴势力。如今提起这家公司，外界给它贴上了很多标签，其中令人印象深刻的无外乎：庞大、低调。的确，字节跳动鲜有发声，这也使得它与一众互联网巨头相比，多了几分神秘的色彩。不过，如果

117、要探寻字节成功的原因，引用一位大佬总结，创始人张一鸣的一句话或许能成为答案：字节跳动的核心竞争力，直接来说是我们的产品，产品背后是我们的技术系统，技术系统背后是我们的团队和文化。如今，再过多去渲染字节的产品稍显多余，毕竟对于开发者群体来说，目光也更多的聚焦在后半句持续、丰富的 APP 研发的背后究竟有着怎样的技术支撑。在本期访谈中，InfoQ 有幸采访到了字节 AppInfra 团队。作为字节跳动移动端基础技术的研发团队，他们主要负责字节跳动的移动端基础设施建设，支持的产品包括但不限于抖音、今日头条、西瓜视频、飞书等，在与他们的交谈过程中，我们沿着团队一路成长轨迹探寻到了字节跳动移动端基础设施

118、的构建之路，以及支撑如此冗杂的工作背后的 39 中国卓越技术团队访谈录2022 第三季 团队精神和文化，现整理此文，希望能对读者有所启迪。现象级 App 爆红带来团队成长 2018 年，抖音日活破 2 亿，一跃成为中国头部 App 之一。这一年，也被外界称为“字节跳动成为巨头，与 BAT 们正面交锋的一年”，自那时候起，字节业务开始触及多个领域，扩大旗下 App 矩阵，其中，多款 App 获得了成功。在外界看来，这是字节的高光时刻，但人们看不到的是，彼时字节的内部也开始做出转变来应对业务的高速发展。以本文的主角 AppInfra 团队举例，其前身可追溯到之前支持移动平台的基础技术部门。2017

119、 年之前，基础技术部门大约只有十几个人规模；2018 年之后，业务的迸发促使部门开始扩张，“2019 年至今，我们吸纳了不少领域内的专家，一方面帮助团队支撑起平台职能；另一方面也开始投入做一些技术研究。”杨萍谈到。在此过程中，基础技术部门逐渐孵化出今天的 AppInfra 团队。业务多，场景也随之多样化，对于技术团队来说，堆人头、拼时间势必不是长久之计，这种情况下，整个公司开始更加注重技术复用。对于 AppInfra 来说，他们的主要职责，正是将场景中的通用技术能力抽象出来，加以建设，沉淀出通用工具再落地到业务中去。AppInfra 的应用基建过程覆盖了整个开发周期中的各个环节，包括本地编码、

120、代码审查、测试、打包、部署、性能优化等。发展至今，整个 AppInfra 团队的规模已经逐步扩大，并且进一步细化为了四个子团队AppHealth 团队、Research Center 团队、端智能团队以及 Devops 团队。AppInfra 团队使命是提升移动端效能、性能质量、产品核心指标和智能化水平，并关 40 中国卓越技术团队访谈录2022 第三季 注新技术研究与落地。那么为什么要分化出这四个方向呢？对此，另一位受访嘉宾孙念总结为团队的定位是为支持业务而生。他表示，与其说团队的架构是自顶而上规划而出，倒不如说是随着业务的需求慢慢生长出自己的形状来的贴切。“拿 AppHealth 团队来说

121、，当应用达到一定量级，性能、稳定性等指标会直接影响用户产品体验。随着业务规模持续增长，这部分问题一旦开始凸显，团队也会加大这些方面的投入。”由此也可见，组织架构的演变其实是和技术、业务息息相关的。当业务改进时，新技术就会通过架构的分支与原有技术连接在一起，共同工作，更高效率的解决业务需求。如果把组织架构的成长分为支持业务而生、赋能业务中去、引领业务发展三个阶段的话，目前看来，AppInfra 团队已经同时迈入了第二阶段与第三阶段。那么，对于一个通用技术建设团队来说，它们是如何与业务团队进行有效协作，从而发挥技术能力的最大价值，更好的赋能业务呢？对于这个问题，杨萍是这样回答 InfoQ 的：第一

122、，明确职责是前提。在字节内部，双方团队的职责是比较明确的：业务团队主要是以需求迭代和业务交付为目标，他们的侧重点在于保障需求侧的交付；而 Infra 团队主要是以技术方向为目标，侧重点在于技术的实现情况以及解决技术难点。第二，保持紧密的协作关系。在业务团队提出需求后，背后的技术或者中台团队会迅速调整去做支撑，同时技术团队还充当业务团队的智囊团角色，以应对业务团队可能会面临的各种突发技术状况。另一方面，业务团队在长期需求迭代过程中也会有比较多的业务视角经验，他们会将这种经验传导到技术团队中，从而沉淀出典型的解决方案或者技术上的经验，赋能给更多业务。“可以说，这两个团队之间更多的是一个哺育与反哺育

123、的关系。”41 中国卓越技术团队访谈录2022 第三季 性能优化已成移动端开发重要议题 我们做优化，到底优化到什么程度才算可以呢？我想字节文化中的敢为极致能够给予我们这个答案。从 2007 年兴起，移动端已经经历了十几年的发展。目前来看，移动端的技术栈，可以用百家争鸣来形容：原生 App 技术栈：安卓平台的 Java 技术栈，iOS 平台的 Object-C 技术栈或 Swift技术栈。混合 App 技术栈：典型代表有 PhoneGap、Cordova、Ionic 等框架。跨平台 App 技术栈：典型代表有 React Native、Xamarin、Flutter 等。对于字节来说，移动端的主

124、要技术栈也无外乎如此，“我认为，近几年来看移动端开发的架构或者框架演进过程并没有发生质的变化，技术栈的出现也属于渐进式变化，包括底层编程语言以及 UI 层面。”杨萍介绍道。同时她也谈到一个新的趋势，相较现如今比较成熟的技术栈来说，大家开始更关注 App 体验和性能的优化。对于拥有旗下多款 App 的字节来说，这一趋势显然更需要提起重视。也因此，其中一部分重担落到了AppInfra 子团队 AppHealth 团队身上提升全产品线的性能、稳定性和工程效率。作为 AppHealth 团队的负责人，孙念毕业后的第一份工作是在高通集团，“当时主要是做安卓底层和芯片比较紧密的系统软件的优化”。后来随着手

125、机厂商的快速发展，他转而加入手机厂商做安卓系统的相关优化。如今，再总结这两段工作经历，孙念感触颇深，他认为自己的工作层面从偏底层转而到应用层面，明显对自己的技术视野和深度上有相当大的帮助。42 中国卓越技术团队访谈录2022 第三季 2019 年，孙念加入字节，他回忆当时摆在自己面前的第一个任务就是组建团队。最开始，团队成员中拥有做监控能力的开发者比较多，“所以，当时的我们主要是做性能监控，一方面是加强线上的归因能力，另一方面是加强线下深入分析的相关工具建设。”他进一步介绍，对于线上和线下来说，其实想要监控的指标和发现的问题其实是一致的，但更希望能把问题在线下就处理掉，以避免线上造成更大范围的

126、损失。因此，线上层面，团队着重制订更好、更合理的指标，同时，建立整套问题的报警、响应、解决流程，来及时发现、解决问题；而线下层面，则从性能角度建立了较为精细的防劣化机制。所谓劣化，是指在业务迭代和架构优化过程中，遇到了很多不符合架构设计的代码，而导致架构出现劣化。“比如，我们会去定制 Android 手机 ROM，通过固定ROM里面的参数控制硬件的波动，来减小数据测量的误差，来达到更加精准防劣化，”通过建立精细化防劣化机制及时发现问题，并进行拦截和消费，来保持项目整体架构持续正向演进。在解决性能监控问题的同时，AppHealth 团队也开始在全球各地吸纳更多单点技术领域和方向的人才，开启更多通

127、用技术能力的探索。其中，“编译器成为我们重要发力点之一”，孙念介绍，对于工具链的探索主要有两个原因：第一，工具链的改造能直接缩小包体积或者提升应用性能，但对于开发者来说只需要替换工具链，而没有其他感知；第二，移动端工具链的潜力挖掘的还不够充分，可做的事情比较多。目前，AppInfra 团队在包体积方面也已经得到了初步效果。孙念举例，团队通过定制自己的链接器替换苹果默认链接器，可以做到消除全局重复代码，从而将 iOS 二进制文件优化百分之十几左右。“这块目前业内还是做的比较少的，之后我们也会将实践做更详细的分享。”43 中国卓越技术团队访谈录2022 第三季 前沿技术的相关探索 务实是我们团队非

128、常重要的一个业务视角，也是我们反复强调的一点。如果说性能优化是目前大厂们做产品势在必行的大事之一，那么与此相对，四个子团队中的 Research Center 团队的工作似乎与业务相去甚远，毕竟从介绍来看，Research Center 主要负责前沿技术创新，以及与一些学术机构的合作。然而在实际中情况却恰恰相反，对于字节来说，Research Center 团队的存在不仅不是“可有可无”，甚至已经成为 AppInfra 团队更好地去服务业务发展的重要一棋。“我们的理念并不是做一个单纯的学术研究部门，我们做的是技术研究，终归还是要讲究去落地的。”杨萍谈道。与孙念的经历相似，Research Ce

129、nter 团队的负责人杨萍同样有着丰富工作经验。研究生毕业后，她选择供职于英特尔，工作内容主要涉及与手机摄像头相关的软件，且以应用层为主。2018 年，杨萍加入字节，最初在 AILab 字节跳动人工智能实验室工作负责 QA 技术团队的搭建。2020 年，杨萍所在的团队开始转型技术方向探索，更名为 Quality Lab，Quality Lab 的主要职责是探索前沿技术如何进一步测试能力从而去赋能业务。“这个过程基本上延续到今年年初，我们的研究方向以质量测试技术、效率和自动化为主。”同时她也坦言，在这个过程中，团队面临了不少挑战，也做了很多变化去应对：第一，组织架构角度，除了算法工程师以外，加入

130、更多客户端、服务端的工程师来做产品化支撑；第二，拓展与高校、机构等深度的交流和学术合作。“未来，我们再去看组织定位时也会发生一些变化，变化主要在于 DevOps 或者极致的性能与体验的优化。”随着组织定位的进一步清晰，在公司战略调整下，AppInfra 44 中国卓越技术团队访谈录2022 第三季 正式成立了 Research Center 团队。“Research Center 会持续跟进加深一些学术合作，继续前沿技术的探索；另外，我们也会继续在自动化测试上的投资；最后，我们还尝试将主攻方向从端延伸到整个代码，去做针对程序方面的探索。”那么对于 Research Center 来说，为什么会

131、选择从自动化测试入手开展现有工作呢？杨萍介绍，这主要在于测试技术在开发过程中属于比较关键的节点，能够在研发、QA甚至其他决策方等多个方面为项目带来明显的优化以及提升。首先，越是在项目、业务众多的情况下，开发者团队越能体会到代码审查的必要性，可以说不做代码审查基本相当于背着定时炸弹前进，时刻有炸了的危险。而在代码审查中，测试是关键的一环。一般来讲，单元测试成本最少，代价也最小，“但对于开发者来说，需要面对快节奏的迭代任务，多半情况下可能并没有多余的精力去维护好单测。”因此，自动化测试的重新定义及探索也显得尤为迫切。回顾字节整个自动化测试平台建设，杨萍总结为一路朝着集成、一体化方向发展的。“201

132、8 年时，字节并没有所谓的测试平台的概念”，并且早期服务端测试还是空白的，主要依靠客户端测试同学去兼顾。随着业务规模的扩大，字节设置了专门的服务端 QA的角色，来填补相应技术层面的空白。同时，性能稳定逐渐被重视，字节也随之设置了服务端性能测试平台来提供相应支撑。这样一来，字节的整体自动化测试平台发展到今天，既具有了从客户端到服务端广度，又具有从功能到性能的深度，能够从更加全面的维度为项目及业务做支撑。当然，建设自动化测试平台中，Research Center 团队也在做观察及调研，他们发现市面上针对客户端测试的自动化测试工具有很多，比较典型的有 Facebook 研发的Sapienz 以及 A

133、ndroid 自带的随机测试工具 Monkey 等，但其中对 iOS 系统的软件 45 中国卓越技术团队访谈录2022 第三季 测试工具基本上没有，并且，类似字节多业务现状这种情况，也没有一个自动化测试工具能做到完全的适配。“整体评估过后，我们决定自己探索这部分问题。”杨萍介绍。因此，2019 年，字节在自动测试方面加大投入，研发了智能化测试服务 Fastbot。杨萍进一步谈道，Fastbot 最核心的技术本质上是如何在海量的数据中更好、更快的遍历完整个测试地图，“当我们抽象出来这个问题之后，就可以在低层去做多端或者 OS层面的兼容。”这也意味着 Fastbot 不仅可以支持安卓，还能支持 i

134、OS，甚至做到了支持跨端框架。当然，对于新技术的探索，点滴成功的背后无疑是多次的失败，Research Center 团队也并不例外，“自动化的工具，过程中会有非常多的技术探索，也会面临很多失败，但这些失败其实并不足以改变我们的初衷，我们希望用更多的新技术去解决业务中的实际测试问题。”人的问题才是根本性问题 本次访谈中，InfoQ 照例与两位团队的负责人聊到了他们眼中团队亟需解决的问题。令人印象深刻的是，除了谈及技术以及业务上的规划，本次两位负责人还不约而同谈到了他们对于“人”的问题的理解。对于 AppHealth 团队来说，孙念认为目前还是需要进一步建设好人才梯队。“我们还是会持续再补充一些

135、优秀同学进来，包括在海外的招聘进度。”同时他也谈到，虽然字节在海外的知名度已大有提高，但与 Google，Facebook 等国际巨头的影响力差距仍然存在，这是需要承认，并不断努力提高的一点。46 中国卓越技术团队访谈录2022 第三季 而对于 Research Center 团队来说，杨萍谈到，他们目前最需要的则是正视目前潜在的人才结构化的风险。展开来讲，作为前沿技术探索领域的先行者，一方面，团队需要引进更多资深的青年学者，去做更多技术探索，但也应该注意到，研究型人才的加入可能会削弱团队本身的工程和业务视角。因此，另一方面，她直言接下来团队引入更多来自业务领域的技术专家角色，使团队更好地传承

136、以技术研究落地为主的使命和愿景。写在最后 近年来，不少公司将目光放远，向国外大厂学习，学习他们那些极客精神，对产品的极致打造。这是一个极好的现象和趋势，代表了国内技术圈子追求进步的脚步从未停止。但同时，我们也应该意识到，这些优秀经验的背后，大多也源自这些公司本身的文化和精神。谈及各自团队的文化，孙念是这样告诉 InfoQ 的，他说：“我们做优化，到底优化到什么程度才算可以呢？我想字节文化中的敢为极致能够给予我们这个答案。”而杨萍则告诉 InfoQ：“务实是我们团队非常重要的一个业务视角，也是我们反复强调的一点。”至此，回到文章开头，或许我们能从 AppInfra 团队窥探到字节跳动的核心竞争力

137、所在。47 中国卓越技术团队访谈录2022 第三季 嘉宾介绍 孙念 字节跳动终端基础架构部门 AppHealth 方向负责人，专注于 App 性能、稳定性方向，带领团队通过对操作系统资源利用、虚拟机、编译器工具链，高性能基础库等方向的深度优化和建设各个核心指标全链路的监控体系和分析调试工具，协助字节各业务提升产品质量和体验。杨萍 字节跳动终端基础架构部门 Research Center 团队负责人，负责端架构基础研究与智能化能力建设，带领团队孵化并落地多个行业领先的端质量产品（Fastbot，精准测试），也对目前 AI 技术在大前端研发体系的应用有较多了解。48 中国卓越技术团队访谈录2022

138、 第三季 一年100%云原生化，众安保险架构演进的探索与实践 采访嘉宾：欧昀、鄢晶 编辑：辛晓亮 金融行业的蓬勃发展，业务规模的不断扩张，用于支撑业务运行的系统和基础设施也日趋庞杂，强监管安全合规的属性又使得他在云原生的选择上比其他行业多了一丝谨慎，面临更多挑战。众安保险从 2016 年就开始探索实践云原生相关技术，在服务治理、自动化运维等方面积累了大量的经验。为了深入了解众安在金融保险领域的探索和思考，近日，InfoQ采访了众安保险技术团队，围绕金融保险云原生架构治理问题逐一展开探讨。众安云原生之路：从追随者到实践者 2016 年，众安就开始逐步尝试云原生技术，届时众安已充分意识到云原生技术

139、本身适用于任何行业，慢慢地众安对云原生的理解也从早期概念的追随到现在大规模落地的实践者甚至是布道者。这个模式的转换更多的是依据云原生的定义搭配众安自身的演进实现，同时结合业务实际，由浅至深，由点到面的过程。早期云原生在定义过程中，主要是应用的容器化，以及面向服务架构，容器编排等等。随着云原生生态的逐渐成熟，众安现在更关注的是标准实践之后的深度治理，比如在 49 中国卓越技术团队访谈录2022 第三季 不可变基础设施，微服务三要素等落地规范的定义下，如何最大化的实现云原生技术红利，并不断探索云原生标准的最佳实践等。众安对云原生理解总结为一个词就是弹性。主要分为三个方面，分别对应弹性基础设施，弹性

140、应用架构，以及弹性研发交付流程，也分别对应容器、微服务和持续交付相关技术。容器轻与快的特性能够让企业实现按需的编排使用，对于需要使用的资源实现快速的弹性伸缩。微服务应用架构则是作为部署与交付的介质，低耦合的设计能够充分发挥容器和持续交付的能力。此外借助 DevOps 实现的持续交付流程则能够使众安更快、更敏捷的去响应需求的变化。总的来说，云原生为众安提供了一套指导思想，让企业以更轻更快的方式去实现构建部署以及交付应用。众安架构演进：迈向云原生 同其他互联网公司相似，众安的技术架构也是一直在演进与升级的，整体可以分为三个阶段。第一阶段是在成立之初采用的传统单体架构，满足业务快速上线。第二阶段，随

141、着互联网业务对新开通高并发、低延时的要求，众安开始进行微服务架构的升级，这个阶段又可以细分为闭源与开源两个过程，最初使用国内大厂闭源的技术组件，之后慢慢拥抱开源生态。第三阶段就是现阶段，采用基于 K8s 构建云原生的架构，包含了容器化的基础设施、微服务架构、服务治理、DevOps 体系建设等等。众安在进行架构演进的过程中，首先会进行目标架构的规划，解决方案的规划也会成为目标架构演进过程中的目标路径。这就意味着方案规划需要符合长期的目标架构，50 中国卓越技术团队访谈录2022 第三季 同时在中短期也要能够解决当前或者即将面临的问题。另外众安将技术架构的关键能力聚焦在业务复杂度提升和数据量变高带

142、来的海量数据、低延时高并发等互联网式的极端流量问题之上，这也要求众安停下来去审视当前的技术架构是否能够支撑业务形态的转变，以适应未来五到十年的变化为目标去进行架构规划。云原生架构建设思路 众安在云原生架构上的建设思路，恰如众安对云原生的定义理解，也是分为三个层次，包含基础设施层，应用架构层，以及研发管理层。基础设施层次建设改造主要是指的是容器化的改造，包含容器服务，容器编排，以及如何将应用部署在容器当中等。其重点在于容器云平台的搭建，众安采用 K8s 并在其之上自研了一套自己的多集群统一管理容器云方案，实现了全公司全环境容器服务以及编排的统一管理。另外，通过镜像可视化编排、镜像插件等手段去标准

143、化约束基础镜像，实现业务系统快速进行容器环境的适配。在此之上面向云原生设计并落地了新一代数字化保险系统称之为无界山2.0。在应用架构与研发管理层，众安主要采取架构标准化与微服务治理和自研 DevOps 体系的思路，我们在下文服务治理段落将进行详细讲解。关于标准化的约束，众安集成在流程与工具当中，形成一套事前自动生成、事中标准指导以及事后检查的机制。在体系建设方面众安采用核心能力拥抱开源，服务能力进行自研的方式建设基础设施、应用架构和持续交付体系。在开源工具的选择上，众安会充分考虑一些 CNCF 认证的项目与规范，同时也会采取像社区共建、团队贡献、定制私有等方式，和社区保持长期稳定的一种参与关系

144、。51 中国卓越技术团队访谈录2022 第三季 此外众安在云原生安全方面也有着非常重要的考量，一方面会借助云上的安全产品去建设基本硬件级的安全防护能力。另一方面众安面向金融场景，围绕容器、应用、数据、业务方面进行安全能力自研孵化网络安全、应用安全、数据安全产品，形成面向不同行业和场景的安全合规、业务安全的风险管理解决方案。同时众安将安全能力和研发管理流程深度集成形成了现有的 DevSecOps 体系，这些都是众安在规划架构上的思考。强监管行业安全上云 保险银行证券都是属于强监管的金融行业，上云对于他们来说既是挑战，也是机遇。最基础最关键的就是如何选择一个好的云服务商，根据行业的一些特性，可以从

145、合规、安全、数据一致性等高要求来考虑。因此在架构升级上众安会主要从两个方面考虑。首先在业务方面，传统的金融产品和服务，存在一定的门槛，效率低下，同质化严重，可能无法满足客户的特定需求，客户更多的需要线上化、个性化、场景化的金融产品和服务。其次在技术层面，金融行业属于信息化程度相对比较高的一个行业，传统的金融 IT 架构存在较多问题，比如研发周期长，协作沟通问题，运维成本高、创新比较慢等等，还会遇到人才储备不足的难题。结合目前数字转型在整个行业的深化，众安看到了越来越多的云原生技术在行业上的运用。众安开始逐步尝试云原生技术在生产实践中的运用，充分利用和发挥云的优势，同时做到灵活、低成本的方式构建

146、弹性和可扩展的应用。在帮助研发的过程中，将研发的焦点，由资源为中心转向以应用为中心，利用弹性的概念去充分发挥云的优势，52 中国卓越技术团队访谈录2022 第三季 帮助提升产研的能力，支撑业务的创新。整体来说的话，众安认为云原生技术能够为金融行业，尤其是互联网金融行业带来巨大的红利，为众安构建新一代的数字化基础设施，以及帮助企业数字化转型带来强大的推力。最大挑战只有一个：技术升级不能影响业务 技术升级最不缺的就是挑战，整个架构升级切换的过程，众安的技术专家表示，就像大家说的“开着飞机换引擎”，最主要的挑战就一个，技术升级的同时不能影响业务。在整个迁移的过程中，遇到了大家熟知的微服务问题，容器化

147、，DevOps 等等，既不能影响生产业务，又不能影响日常开发的运维流程，挑战还是比较大的。众安主要分了两个阶段去尝试：第一阶段，众安早期的业务形态，主要是围绕电商场景去开展，这个时期需要在很短的时间内做更多的生态，比如健康生态、汽车生态等等。早期的业务架构并不是很匹配未来的业务情况，因此早期有业务架构升级的需求，所以众安在做业务架构的同时，也将底层的技术架构做了升级，完成了早期云原生基础设施的转换。第二阶段，有了云原生的基础，通过云原生的基础能力，众安对基础设施进行了底层的封装之后，确保上层应用运行环境的稳定，同时众安加强了 PaaS 层服务能力的建设，降低开发者对底层基础设施和公用组件的使用

148、门槛和成本，这也可以帮助后续做到无感升级。同时为了降低日常运维的流程，众安还自研了 DevOps 产品，实现从构建到部署的自动化，并将标准化延伸业务交付。53 中国卓越技术团队访谈录2022 第三季 从探索容器到服务治理 众安云原生的发展阶段也可以分为三个阶段：容器探索阶段、微服务化、服务网格治理。前面提到，众安从 16 年就开始起步探索容器技术，以 Docker Swarm 为技术核心建设了第一代容器管理和应用平台，在一些边缘应用上进行了小规模的试点应用。实践下来，在网络及其稳定性方面存在比较大的问题。时间来到 18 年，这个时期众安以 K8s 为技术核心建设云原生基础设施，将微服务应用部署

149、到容器环境。在容器微服务化阶段众安的迁移改造已经比较彻底，实现了业务应用 100%容器化。目前正处于第三服务网格服务治理阶段，当下众安主要以 Istio 和 Agent 为技术核心实现网格化的服务治理，对以 K8s 为主的云原生基础设施进行进一步的增强。总的来说，阶段二的迁移最具挑战，迁移的过程耗时将近一年，无论是涉及到的系统规模，还是复杂度都是最高的。另外由于底层基础设施形态的转变，技术复杂度也比较高，众安通过蓝绿验证的方式，通过网关的能力进行流量的逐步切流，利用这种手段做到业务逐步迁移，保证了迁移过程中业务的连续性不中断，实现业务的无感迁移。提及转向云原生收益之前先介绍一下众安的基建规模，

150、众安这边的主机规模，按照4C8G 这种机器的规格去计算的话大概是在一万加以上，应用规模是一千多个，技术人员的规模大概是在两千以上。众安技术架构在转向云原生之后，结合资源弹性编排带来的成本节省，以及 DevOps 体系建设和落地，有效提升了需求交付率，缩短了交付周期。从统计的数字上来看，21 年众安发布次数在 12 万次以上，相交于云原生之 54 中国卓越技术团队访谈录2022 第三季 前增长了 22 倍，关于转向云原生，众安还是获得了非常明显的收益。目前的难题 架构演进是一个持续的过程，企业会不断面临各种各样的问题与挑战，众安分享了其中一个多语言环境下架构治理问题。关于如何看待多语言，首先众安

151、保险不希望开发语言成为公司吸纳各路人才的阻碍，不同的编程语言也会有他适合的一些应用场景，比如说人工智能 Python 会比较适合，云原生 Go 会比较适合，企业级的一些业务系统可能 Java 会比较适合。在语言栈选择上众安秉承着开放的策略，但语言栈的开放带来的就是维护复杂度、治理困难的问题。为了实现统一架构的治理目标，将治理能力不断下沉到基础设施是众安认为唯一的标准答案。众安方案的抓手是流量劫持，从东西向流量和南北向流量这边分别去展开。对于南北向流量众安将治理的能力放在网关层，同时众安的目标也是建设 API、业务、安全的三合一网关；对于东西向流量众安则是依托服务网格技术，在全公司全场景覆盖，提

152、供基础设施级的流量权限与可观测能力。众安架构服务治理方案 随着众安技术伴随整个业务发展进入第九年，公司在业务形态和体量上都发生了巨大的变化，整个技术架构如何去支撑业务的线上运营与发展就就变成了非常有挑战的课题。55 中国卓越技术团队访谈录2022 第三季 众安保险内部架构治理遵循公司统一架构目标，以技术架构、业务架构作为支撑点，主要分为三个方面。第一，基础设施层面众安要求百分百部署在云上，充分使用云服务提供的计算、存储、网络等能力；第二，在技术架构方面，众安基于云构建了技术中台，能够向业务系统提供统一的容器、中间件等 PaaS 能力；最后在应用层面，业务系统统一使用类 Spring Cloud

153、 生态的微服务架构。总的来说，目前众安已经形成了较为完善的云原生生态的建设，治理着超过上万服务的大规模集群。强监管的金融行业属性 首先金融保险属于强监管的行业，安全合规是红线，金融保险架构治理也会有一些特殊的地方。因此众安在做基于架构标准的时候就会设定一些合规性的下限，在业务设计的过程中要帮助和指导大家去考虑合规性需求的扩展和一致性。其次，由于整个金融行业存在一些“历史包袱”，尤其是一些中小型金融企业，对于技术改造存在较大的风险和挑战。所谓金融企业的“历史包袱”，可以从两个方面展开来讲。第一是业务上的挑战，第二是技术方面的挑战。大家可能知道，组织结构会决定技术的架构，众安早期遵循的一套架构叫做

154、“胖前置，瘦核心“，这是因为众安前期强调的业务形态是前台的业务部门高效迭代的能力。在整个架构升级过程中，尤其上发展到现在业务稳步发展的阶段之后，就会更加关注业务的效率和质量，然后持续加大一些业务中台和技术中台的投入。最后在整个过程中不但有底层的业务架构的升级，以及匹配到技术架构的升级，整协同过程中组织架构的一些调整也会有冲击。还有一点可以补充的是，像传统的金 56 中国卓越技术团队访谈录2022 第三季 融行业的业务系统，大家可能知道企业使用的像小型机，重量级的一些数据库，甚至闭源的厂商，都是比较普遍的。关于这个方面，金融企业上云也会存在一些阻力。不过受访专家表示，众安也相信技术先进性会让之前

155、的一些业务开展由不可能会变成可能，同时也在不断鼓励金融创新，鼓励技术先进性的探索也会成为众安架构治理的一个重要环节。此外，在服务治理的过程中也会发现新的一些架构和交互对于传统的业务流程和组织结构带来的一些冲击，众安也发现转变企业的文化，打破部门的一些壁垒，夯实数字化的一些群众基础也是非常重要的事情。三大企业架构治理方案 众安在企业架构治理课题上具体来讲有以下几个方向：首先是微服务治理，众安根据自身业务覆盖广、周期长的特性，使用开源体系落地实践的方案。以 Spring Boot 为基础，在此基础之上建设了可递进、可共建的统一微服务应用框架，为业务系统提供框架组件版本的统一管理能力，同时开放共建能

156、力也可以让各事业线的技术团队参与到标准的制订以及演进过程当中。众安采用无侵入为主、多语言的异构体系为辅的技术方案。尽量避免对业务代码产生侵入，升级也能够做到尽量减少对业务这块的一些感知与影响。简单来说就是 Istio 配合 Agent，或者称之为 Agent 加 Mesh 双治理的体系。众安应用服务技术体系，虽说是拥抱多语言，但实际上更多还是以 Java 占据绝对的比例。目前众安使用这两种技术体系共同完成不同业务场景的覆盖，这也是金融保险行业比较先进的治理方式。再谈数据治理，众安作为国内较早开始数字化转型的企业之一，非常注重数据带来的 57 中国卓越技术团队访谈录2022 第三季 价值，为此众

157、安还成立了专门的数据治理组织。数据治理上众安保险主要关注两个方面，一是数据质量，二是数据安全，目前两个方面众安都是通过一些平台化的能力进行治理。数据质量方面众安搭建了企业内部的数据质量平台，通过不断去维护运营过程中积累的像业务和数据的一些相关规则。比如说保险，保险是受强监管的，在业务处理的事前、事中、事后都要及时地对相关数据进行质量监控。另一方面，在数据安全上，众安自研了关于数据管理方面的平台，取名绿洲数据服务中心，通过系统对数据的一些流转和使用，进行相应的数据相关的一些权限和安全的控制。最后是 DevOps 治理方面，或者叫研发过程的治理。这里众安是以一站式研发管理作为指导思想来建设一体化的

158、 DevOps 平台，并且从文化、组织和工具层面对众安的研发一体化的体系进行落地。众安整个 DevOps 体系的设计遵循了两个理念，一个是运维 N+1 的一个理念，一个称作“小工具大平台”的理念。什么意思呢？首先运维 N+1，指的是一个基础运维，N个运维场景，也可以理解为是一个运维中台，N 个运维平台。众安使用运维控制管道概念去提供基础的调度能力，去屏蔽底层比如容器调度、主机调度甚至文件调度，实现统一的命令和文件管道，同时上层工具平台遵循统一的数据和 API 标准。在此标准之上众安建设了像持续交付，可观测，数据治理包括 ITSM、IT治理等众多的应用场景。“小工具大平台”则指的是众安运维体系模

159、块化的设计，通过微前端等的一些技术手段，去实现模块的按需组合，并且按照研发角色例如开发运维测试等形成不同的工作视图。58 中国卓越技术团队访谈录2022 第三季 金融基建新挑战 此外，信创基础设施作为当下较为火热的课题，众安在此方面亦有相关动作。金融安全关系国家命脉，在自助可控的重要性方面尤为突出。众安积极响应国家战略，在基础设施、核心系统方面的信创适配工作有着很大的投入并产生了不错的成果，面向行业推出了安全、运维、基础架构等领域的众多满足信创要求的产品。另外，众安保险具备金融、互联网双重行业特性。同时区别于传统公司，众安的基础架构体系 100%构建于云上，是在云上进行大规模生产实践的典型案例。在与云商等产业机构联合共创之下，快速设计了有众安特色的信创云方案并进行尝试，目前已经有一定比例的科技投入。同时众安也非常愿意以科技赋能行业为目标持续输出相关产品与经验。写在最后 中国信通院云大所云计算部副主任陈屹力曾提到，云原生是保险行业新一轮数字化升级的必经之路，众安在金融保险领域的成功实践也验证了这一点，尽管目前大多数企业还处于探索阶段，但在未来几年，金融保险行业将全面迎来云原生时代。