ucc

9 月 18 日，2020 杭州云栖大会期间，阿里巴巴正式成立云原生技术委员会（以下简称委员会），阿里巴巴高级研究员蒋江伟担任委员会负责人，达摩院数据库首席科学家李飞飞、阿里云计算平台高级研究员贾扬清、阿里云原生应用平台研究员丁宇等多位阿里技术负责人参与其中。同时，阿里云推出包括软硬结合的沙箱容器 2.0、离线实时一体化数据仓库 MaxCompute、云原生多模数据库 Lindorm 在内的多款云原生产品。 云原生是一种新型技术体系，被视为云计算未来的发展方向。云原生应用也就是面向“云”而设计的应用，在使用云原生技术后，开发者无需考虑底层的技术实现，只需做好自己的业务，就可以充分发挥云平台的弹性+分布式优势，实现快速部署、按需伸缩、不停机交付等。 蒋江伟表示，委员会将大力推动阿里经济体全面云原生化，并沉淀阿里巴巴 10 多年的云原生实践，对外赋能数百万家企业进行云原生改造，提升 30% 研发效率的同时降低 30% IT 成本，帮助客户迈入数字原生时代。 此次委员会的成立，也意味着阿里已经将云原生升级为新的技术战略方向。蒋江伟介绍，阿里拥有 10 多年的云原生实践经验，从 2009 年首次上线核心中间件系统，到 2011 年淘宝天猫开始使用容器调度技术，再到推出自研云原生硬件神龙服务器、云原生数据库 PolarDB。2019 年 双11，阿里电商核心系统 100% 上云

作者 | 贾之光（甲卓） 阿里巴巴高级开发工程师，专注于 Kubernetes 安全沙箱和机密计算领域，主要参与 Incalvare Containers 社区开发。 8 月 26 日，我们发起了第 6 期 SIG Cloud-Provider-Alibaba 网研会直播。本次直播主要介绍了机密计算的概况， InclavareContainers 开源项目架构、已支持的功能和迭代计划，以及阿里云 ACK-TEE 的发展现状和规划。 本文汇集了此次直播完整视频回顾及资料下载，并整理了直播过程中收集的问题和解答，希望能够对大家有所帮助~阿里巴巴云原生公众号后台回复“826”即可下载相关 PPT。 直播视频回顾链接： https://v.qq.com/x/page/z3143a6agsg.html 机密计算简介 1. 应用容器安全现状 Portworx and Aqua Security 发布的《2019 容器接受度调研》报告显示， 安全性 成为了用户使用容器技术和业务上云面临的最大挑战，其中 数据安全 问题最为突出；根据 Risk Based Security 发布的数据泄露报告显示，2019 年数据泄露事件发生的数量和泄露的数据量与 2018 年相比均增加了 50%+。 2. 机密计算时代到来 数据在整个生命周期有三种状态：At-Rest（静态）、In-Transit（传输中）和

作者 | 宿何 阿里巴巴高级开发工程师 Sentinel 是阿里巴巴开源的，面向分布式服务架构的流量控制组件，主要以流量为切入点，从限流、流量整形、熔断降级、系统自适应保护等多个维度来帮助开发者保障微服务的稳定性。Sentinel 承接了阿里巴巴近 10 年的 双11 大促流量的核心场景，例如秒杀、冷启动、消息削峰填谷、集群流量控制、实时熔断下游不可用服务等，是保障微服务高可用的利器，原生支持 Java/Go/C++ 等多种语言，并且提供 Istio/Envoy 全局流控支持来为 Service Mesh 提供高可用防护的能力。 近期， Sentinel Go 0.3.0 正式发布，带来了 熔断降级特性支持 ，可以针对 Go 服务中的不稳定调用进行自动熔断，避免出现级联错误/雪崩，是保障服务高可用重要的一环。结合 Sentinel Go 已经提供的 gRPC、Gin、Dubbo 等框架组件的适配模块，开发者可以快速在 Web、RPC 调用层面配置熔断降级规则来保护自身服务的稳定性。同时 0.3.0 版本也带来了 etcd 动态数据源模块，开发者可以方便地通过 etcd 来动态调整熔断降级策略。 Sentinel Go 项目地址： https://github.com/alibaba/sentinel-golang 为什么需要熔断降级 一个服务常常会调用别的模块

作者 | Halimao Java、go 爱好者（ https://github.com/halimao/ ） 【Arthas 官方社区正在举行征文活动，参加即有奖品拿哦~ 点击投稿 】 生产环境的 bug 开发环境无法复现怎么办？关键位置没有打印日志信息不足怎么办？莫慌，骚年。让强大的 Arthas法师来 carry，带你去生产环境"遨游"闯关。 刚接触 Arthas，就被它能够 watch 方法的输入参数和返回值的功能震惊到了。这简直太酷炫了，让你可以像本地单步调试一样，跟踪到每一步的执行结果和获取当前的变量数值。以前要定位线上问题，信息不足就需要加日志打印，定位问题，可能需要反复重启应用。用了 Arthas，根本不需要加日志打印，重启应用这些操作。花了大概一个周末下午，在本地跑了下官方 demo，熟悉了下常用操作。脑子里对 Arthas 能够做什么，能解决什么，怎么解决，已经有了大概的了解。后面需要用的时候，就能派上大用场了(学了就一定有 bug 会找上门的=.=)。 下面介绍一个特意找上门的 bug。 背景：同一个聊天交友类产品，对外以一个主品牌以及多个新品牌进行发布。服务端是共用一套数据的，但是所有对外展示的信息，涉及到品牌相关的，需要进行文案替换。在同一个群组里，主品牌和新品牌的用户可以互相聊天。 问题现象： 线上某个群组里面，同一条聊天消息涉及到需要替换文案的内容时

作者 | 车漾（阿里云高级技术专家）、顾荣（南京大学 副研究员） 导读 ：Alluxio 项目诞生于 UC Berkeley AMP 实验室，自开源以来经过 7 年的不断开发迭代，支撑大数据处理场景的数据统一管理和高效缓存功能日趋成熟。然而，随着云原生人工智能（Cloud Native AI）的兴起，灵活的计算存储分离架构大行其道。在此背景下，用户在云上训练大规模深度学习模型引发的数据缓存需求日益旺盛。为此，阿里云容器服务团队与 Alluxio 开源社区和南京大学顾荣老师等人通力合作寻找相关解决方案，当前已经提供 K8s 上运行模型训练数据加速的基础方案，包括容器化部署、生命周期管理以及性能优化（持续中），从而降低数据访问高成本和复杂度，进一步助力云上普惠 AI 模型训练。 AI 训练新趋势：基于 Kubernetes 的云上深度学习 1. 背景介绍 近些年，以深度学习为代表的人工智能技术取得了飞速的发展，正落地应用于各行各业。随着深度学习的广泛应用，众多领域产生了大量强烈的高效便捷训练人工智能模型方面的需求。另外，在云计算时代，以 Docker、Kubernetes 以主的容器及其编排技术在应用服务自动化部署的软件开发运维浪潮中取得了长足的发展。Kubernetes 社区对于 GPU 等加速计算设备资源的支持方兴未艾。鉴于云环境在计算成本和规模扩展方面的优势

作者 | 王夕宁 阿里巴巴高级技术专家 参与阿里巴巴云原生文末留言互动，即有机会获得赠书福利！ 在服务网格技术使用之前，为了更快更灵活地进行业务创新, 我们常常会把现有应用进行现代化改造, 把单体应用程序分拆为分布式的微服务架构。通常来说, 在微服务架构模式的变迁过程中, 最初都是面向代码库的模式。 对这些微服务治理的实现, 往往是以代码库的方式把这些服务治理的逻辑构建在应用程序本身中，这些代码库中包括了流量管理、熔断、重试、客户端负载均衡、安全以及可观测性等这样的一些功能。这些代码库随着功能的不断增强, 版本也随之变更，因为版本不同导致的冲突问题处处可见。此外，库的版本一旦变更，即使你的应用逻辑并没有任何变化，整个应用也要随之全部变更。由此可见, 随着应用的增长和团队数量的增加，跨服务一致地使用这些服务治理功能会变得非常复杂。 服务治理的能力 Sidecar 化 通过把这些服务治理的能力 Sidecar 化，就能够把服务治理的能力与应用程序本身进行了解耦，可以较好地支持多种编程语言、同时这些 Sidecar 能力不需要依赖于某种特定技术框架。这就是我们常说的面向 Sidecar proxy 的架构模式。 随着这些 Sidecar 代理功能的增强，原本需要在代码库中实现的服务治理功能被抽象化为一个个通用组件, 并被逐渐地下沉到代理中。这些服务治理能力的标准化、统一化

作者 | 江建明 阿里巴巴高级无线开发专家 **导读：**精英人数的增长速度持续加快后，很多人开始焦虑，我也焦虑，深知要走出焦虑不容易，我想把走出焦虑快速成长的认知和方法写成文章分享给更多人，做成【技术人成长系列】文章给更多人面对面分享，该系列总共三篇，分别是《完成自己的认知升级》、《自我成长的方法》、《学会自我培养或培养他人》。本文是快速成长第一篇：“完成自己的认知升级”，内容偏长但值得仔细阅读。 如何阅读本文？ 找一个固定不被打扰时间仔细阅读 在碎片化的时间中，每次读完一段内容 最重要的是每次做到只字不差的阅读，然后停下，带着批判性思维从本文中提取出你觉得对的思考方式，并把思考方式关联和迁移到自己身上，经过实践内化成自己的认知，就是非常成功的一次阅读。 开始认识“认知升级” 第一次 ：从文章中看到认知升级，认为认知升级是洗脑，是鸡汤，我对此不屑一顾，道理谁都懂，大部分人还不是过得一样，没啥区别。 第二次 ：从会场里听到认知升级，一个活人站在那里讲认知升级，觉得认知升级有点意思，开始慢慢去理解认知升级，但还是不懂认知升级的价值。 第三次 ：从实践中觉知认知升级，发现“鸡汤谁都懂，但依然过不好这一生”，还有另外一个版本“用好喝鸡汤的工具：汤勺，可以把这一生过得很好”，最简单的开始就是从时间管理认知升级开始，感受到认知升级的强大力量。自从换了一种时间管理思考方式之后，自己逐渐变得自律

实时历史库需求背景 在当今的数字化时代，随着业务的迅速发展，每天产生的数据量会是一个惊人的数量，数据库存储的成本将会越来越大，通常的做法是对历史数据做归档，即将长期不使用的数据迁移至以文件形式存储的廉价存储设备上，比如阿里云OSS或者阿里云数据库DBS服务。 然而在部分核心业务的应用场景下，针对几个月甚至几年前的“旧”数据依旧存在实时的，低频的查询甚至更新需求，比如淘宝/天猫的历史订单查询，企业级办公软件钉钉几年前的聊天信息查询，菜鸟海量物流的历史物流订单详情等。 • 如果这时从历史备份中还原后查询，那么查询时间将会是以天为单位，可接受度为0 • 如果将这些低频但实时的查询需求的历史数据与近期活跃存储在同一套分布式数据库集群下，那么又会带来以下两大挑战 存储成本巨大，进而导致成本远大于收益，比如钉钉聊天信息数据量在高度压缩后接近50PB，很难想象这些数据不做压缩会带来多大的资金开销 性能挑战巨大，随着数据量越来越大，即使针对数据做了分布式存储，单实例容量超过大概5T以后性能也会急剧下滑，进而影响到近期活跃数据的查询性能，拖垮整个集群 运维难度巨大，比如针对海量数据下发一个表数据结构变更操作，很难想象全部完成需要多长时间 实时历史库场景需求分析 通过上面的分析，不管是冷备份还是在线历史数据混合存储在同一张物理表上的方法都是不可取的，一般实时查询历史数据库的场景

在日常工作中，我们一定遇到过需要快速构建系统的工作情形： 作为资源管理人员，需要接收一定数量以及配置的资源申请，这些申请要求网络、存储设备按需到位； 作为开发人员，需要将一套开发环境，复制一份测试环境以及线上环境； 架构师规划一套系统，需要在云上进行搭建。 这些场景都展现着我们日常所遇的各种困难： 对各类云端资源需要进行广泛支持与管理 ：这其中需要包括常用基础IaaS 资源及 PaaS 服务，比如主机、路由器、负载均衡器等计算网络资源以及各种数据库、缓存、大数据、存储服务； 资源编排使用难度大 ：技术栈复杂而难用，实现复杂拓扑关系需要系统化知识与丰富经验； 大量机械重复的手动配置操作 ：不仅是各资源及其拓扑关系按配置进行手工部署，各资源间的拓扑关系更是令人头疼； 学习成本高 ：过往的资源管理依赖于通过命令行调用API 的方式，提升了操作难度和学习成本。 由此可见，自动化运维成了运维人员的业务刚需，各大云厂商也相继推出各自的资源编排服务（Resource Orchestration，以下简称 ROS）。ROS 的理念是“基础设施即代码”，一方面是用代码思维的版本管理来记录基础设施变化，另一方面通过代码实现自动化运维，简化编写代码复杂度，用户通过使用 Json / Yaml 格式模版描述多个云计算资源（如 ECS、RDS、SLB）的配置、依赖关系等

写了多年的代码，始终觉得如何写出干净优雅的代码并不是一件容易的事情。按 10000 小时刻意训练的定理，假设每天 8 小时，一个月 20 天，一年 12 个月，大概也需要 5 年左右的时间成为大师。其实我们每天的工作中真正用于写代码的时间不可能有 8 个小时，并且很多时候是在完成任务，在业务压力很大的时候，可能想要达到的目标是如何尽快的使得功能 work 起来，代码是否干净优雅非常可能没有能放在第一优先级上，而是怎么快怎么来。 在这样的情况下是非常容易欠下技术债的，时间长了，这样的代码基本上无法维护，只能推倒重来，这个成本是非常高的。欠债要还，只是迟早的问题，并且等到要还的时候还要赔上额外的不菲的利息。还债的有可能是自己，也有可能是后来的继任者，但都是团队在还债。所以从团队的角度来看，写好代码是一件非常有必要的事情。如何写出干净优雅的代码是个很困难的课题，我没有找到万能的 solution，更多的是一些 trade off，可以稍微讨论一下。 代码是写给人看的还是写给机器看的？ 在大部分的情况下我会认为代码是写给人看的。虽然代码最后的执行者是机器，但是实际上代码更多的时候是给人看的。我们来看看一段代码的生命周期：开发 --> 单元测试 --> Code Review --> 功能测试 --> 性能测试 --> 上线 --> 运维、Bug 修复 --> 测试上线 --> 退休下线