云原生

作者：当贝技术团队 随着业务飞速发展，当贝的传统 IT 资产也渐显臃肿，为了防止制约倒退的瓶颈，痛定思痛，技术团队果决改革：外围业务云原生化之后，运维效率、整体稳定性和研发效率均失去了全面晋升。 本文次要简述当贝技术团队云原生之路的背景诉求、落地办法和播种成绩。 前言当贝成立于 2013 年 8 月，中国出名的智能大屏增值服务提供商之一，中国大屏应用软件分会会长单位，是一家横跨软件、硬件和操作系统全生态的大屏端互联网平台型公司，致力于成为亿万家庭 AIoT 的外围入口和生存娱乐中心，间断多年入选将来独角兽榜单，国家级专精特新“小伟人”企业。 当贝云原生架构实际历程传统运维体系的三大痛点随着当贝的业务规模飞速发展，背地的 IT 技术也在不断更新迭代，IT 资产规模也在高速回升，不可避免地迎来一些挑战。其中，以运维体系的挑战最为显明，经团队总结，有以下三个较为突出的痛点。 人工运维效率低，危险大，老本高，资产治理艰难传统运维体系下，有大量人工参加。从各环境代码公布，到顶峰低谷的扩容缩容，再到各类证书、云服务器等云资产治理，这些环节，人工参与度越高，危险越大，即使运维人员有着超高程度，也很难保障短暂状况下不呈现任何失误或忽略。 同时，人工参与度越高，效率也就越低，合作老本越高。为保障稳定性，每一次线上零碎变更，都须要协调大量跨部门配合，常常须要研发、运维、测试等多个岗位的同学深夜参加。 随着当贝 OS、当贝音乐、当贝市场等业务倒退多点开花，IT 规模也急剧扩张，云资产治理也成为了较为突出的痛点。 稳定性挑战大，异样排查及复原老本过高当贝对系统稳定性、业务连续性有着极高要求。随着流量疾速减少，特地是在一些如春节联欢晚会这种状况下，流量往往以十倍乃至数十倍激增，对稳定性和容量布局造成极大压力。 同时，当生产环境产生异样，在传统的运维体系下，有着依赖链路简单、排查难度大、定位工夫久、牵扯人员广等外围痛点。 对此，整个服务端部门定下了 1-5-10 快恢及 99.95%可用性两大要求，精准洞察问题外围，同时领导了解决思路。 在当贝各项业务高速倒退的状况下，落实这两大要求，是整个服务端团队火烧眉毛且必须打赢的攻坚战。 自建可观测体系落地简单，易用性和稳定性差，运维老本高任何成规模的 IT 零碎，可观测体系都是极其重要的底层基石，它使 IT 架构的整体设计如依赖拓扑、调用链路追踪、技术标准、运行状况、稳定性等诸多信息清晰出现，除了定位排查以外，更有助于提前发现历史的架构设计缺点、零碎瓶颈并及时解决，在保障业务间断的同时，高效撑持业务倒退与迭代。 在晚期阶段，为保障各项零碎疾速上线、业务高速迭代，存在一些技术架构考虑不周、设计有余的状况，具体表现为选型不一、业务高度耦合、调用链路过长、云资源抉择不合理、治理不清晰等。这些因素组合在一起，造成宏大的历史包袱，在过来传统的运维体系下，曾自建一些可观测组件或框架，但却面临着稳定性差、运维老本高难度大、易用性差、体系不对立等各方面问题，以至于未能齐全施展其应有的价值。 现在，在当贝业务规模继续减速成长的背景下，亟需落地一套全面易用、平安稳固、性价比高的可观测体系，以反对公司行稳致远。 云原生架构的建设面对传统运维体系非常突出的三大外围痛点，为防止其在将来对当贝可继续倒退的策略造成制约，当贝技术团队进行了宽泛钻研、深入分析、踊跃调研，最终将眼光瞄准在了云原生架构上。 正如阿里云在《云原生架构白皮书》中所言：云计算的下一站，是云原生；IT 架构的下一站，是云原生架构。 当贝技术团队极为认同这个观点，云原生是一个确定的技术发展趋势，越来越多的公司拥抱云原生，利用云原生实现更高效率的倒退及翻新。 经全局视角下的充沛评估，当贝技术团队在研发总监张子枭的领导下，提出云原生化、中台化、微服务化、数字化四大技术战略目标，决定全面转型云原生架构。 只有利用云原生架构，齐全解决传统运维体系危险高、效率低下的痛点，能力具备对局部积弊已久、陈疾顽疴的老零碎进行中台化和微服务化革新。 而在云厂商的抉择上，思考到阿里云是国内云计算的布道师与发挥者，实力寰球当先，对云原生技术倒退的奉献引人注目，同时其汇聚了业内最顶尖的人才、最丰盛的教训案例、最牢靠的成熟度，以及其“客户第一”的价值观，当贝技术团队最终抉择借力阿里云落地云原生架构转型。 容器化上云在云原生架构基础设施畛域，Kubernetes 是当之无愧的领头羊。 相比于依赖虚机自建集群而言，由阿里云提供的 ACK 服务，有着更优弹性、更优韧性、免运维、更高效的资源管理等长处，同时无缝集成了大量阿里云产品。 依赖 ACK 及其集成的大量产品，当贝技术团队极快地实现了外围服务的容器化革新，并顺利完成灰度公布、全面切流等工作。值得一提的是，在新架构落地过程中，当贝技术团队不可避免地会遇到疑难杂症困扰，但正因为有阿里云大量的教训案例撑持、最佳实际领导，包含容量布局、可观测、平安防护、稳定性等诸多方面，使整个上云过程始终处于牢靠状态。 实现上云后，这些外围服务从开发态测试态，变更与运行态，贯通服务整个生命周期，效率都失去了极大晋升。 利用云原生 Devops，我的项目公布与协同效率晋升 300%，完全避免人工运维干涉的高风险性；利用 ACK 服务与服务器资源人造解耦的个性，齐全解脱了基础设施运维的低效困扰；利用 HPA+CronHPA，从容应对流量顶峰低谷…… 不仅如此，这些外围服务整体资源利用率晋升了 20%，运维效率更是晋升了 500% 以上，使更大规模的 IT 资源管理成为可能。 在深度参加上云革新的过程中，当贝技术团队积淀了大量的常识与教训，为公司技术储备添砖加瓦，同时仍在积极探索云原生技术。 云原生网关在引入 ACK 作为云原生的基础设施的同时，当贝技术团队也引入了 MSE 云原生网关作为流量治理组件。 ...

4 月 11 日，由中国科协领导，杭州市人民政府、民建浙江省委、中国投资倒退促进会联结主办，主题为 “大江东去 —— 奔竞浪潮之巅” 的第七届万物成长大会在杭州圆满闭幕，这是杭州市守业翻新畛域的年度盛事。来自国内外翻新守业创投畛域的千余名企业家、投资人及创业者相聚钱塘江畔，探讨数字经济时代的翻新逻辑、生态以及门路。在本次盛会上，拓数派新晋 2023 杭州市准独角企业榜单，创始人兼 CEO 冯雷（Ray Von）荣膺杭州市惟一 2022 年度守业人物！ 图为：大会现场照片 图为：万物成长大会 颁奖典礼谷雨，意味着万物逐步成长，方兴未艾，通过杭州市科学技术局、杭州日报报业团体等近半年的评比，依据参选自荐和社会各方面举荐的状况，以当年守业翻新成就和影响力为规范，兼顾新经济的各种业态，由专家团队遴选出了 20 位 “守业人物”、1 位 “年度守业人物”，并由公众网络、微信票选和专家评审，最终评定出获奖者。拓数派创始人兼 CEO 冯雷，作为从浙江走出的外乡企业家，完满体现了浙江人的精力，面对未知挑战，所展示的无畏的勇气，宽敞的胸襟，和获得的巨大成就，也体现了企业家的使命感和敢于担当的责任感，怯懦地站在 “风口浪尖”，以新思维推动翻新，克服困难与险阻，携手达到胜利的此岸。 图为：拓数派创始人兼 CEO 冯雷（Ray Von）领奖照片 “感激杭州市政府为企业倒退发明的良好环境，感激组委会和专家评审团队将这一殊荣授予咱们拓数派！” 拓数派创始人兼 CEO 冯雷在获奖感言中示意：“拓数派作为 Day-1 准独角兽，成立至今极速倒退，短短一年多的工夫，失去业界和泛滥出名投资机构的关注和认可，这离不开团队每一个人的付出，我本人也有幸参加了一份平凡的事业，见证了不同时代数据库行业的变更与翻新倒退。对于拓数派而言，咱们始终保持做‘极难而长期正确的事’，心愿可能在这个科技巅峰竞逐时代，奔竞逐梦，笑傲浪潮之巅！” 图为：2023 杭州准独角兽企业榜单节选 当今世界，新一代科技反动和产业革命突飞猛进，翻新曾经成为转换经济倒退形式、推动高质量倒退的重要引擎，万物成长大会作为杭州着力打造的守业翻新畛域影响力最大的平台，会聚了杭州守业翻新最澎湃的力量，继续打造立足杭州，聚焦长三角、大湾区重点城市，辐射全国乃至寰球翻新洼地。拓数派也将以本次大会为契机，保持以技术创新为外围，深耕云上数据计算畛域，助力行业高质量倒退。  

拓数派旗下旗舰产品 PieCloudDB ，采纳当先的数仓虚拟化技术，为企业构建高平安，高牢靠，高在线「坚如磐石」的云原生虚构数仓。本系列文章将为大家介绍 PieCloudDB Database 最新动静和全新性能。相干视频：链接产品试用：https://app.pieclouddb.com 随着计算资源和网络资源的丰盛，计算平台经验了从大型机年代，PC 机年代，到现在的云时代的三代平台变更。在第三次改革中，服务器虚拟化技术的冲破引领了云计算时代的到来。   三代计算平台变更  为了充分利用云带来的红利，拓数派打造了一款全新的云时代的数据库治理平台：PieCloudDB。 PieCloudDB 将用户数据，元数据和计算引擎三个逻辑外围组件进行拆解并在云上重组。这种存储和计算拆散的架构带来了云上的高弹性，并具备了软硬拆散的高容错和高在线能力。用户能够依据本身需要，按需进行存储或计算资源的弹性扩大。   数仓云原生虚拟化技术冲破引领数据计算时代到来  自2022年10月24日以来，拓数派陆续公布了 PieCloudDB 社区版和企业版，以及一体机版本。在3月14日 Day，拓数派公布 PieCloudDB 全新版本：云上云版。至此，PieCloudDB 实现了对裸硬件，公有云，和私有云三种部署形式的全面反对。 PieCloudDB 的多种部署形式  在新版本中，PieCloudDB 全面实现数据仓库上云虚拟化。云原生数仓虚拟化冲破了传统 MPP 数据库的泛滥瓶颈，实现了云上 eMPP 全新架构，做到多个云原生虚构数仓并发执行。从而取得云上新架构提供的泛滥红利，包含突破数据孤岛，秒级扩缩容，动静调配资源，按需付费等。   PieCloudDB 实现云上eMPP架构   新的版本实现了泛滥全新性能，带来了性能和稳固全方位的晋升，让 PieCloudDB 做到了真正的「unbreakable」坚如磐石，包含：  汇集下推性能失去加强 在数据库的剖析型场景下往往存在大量的汇集运算。PieCloudDB 实现的汇集下推性能通过把汇集操作下推到连贯操作之前去执行，能够大大减少链接操作须要解决的数据量，让查问性能显著晋升。  经测试，汇集下辞让 PieCloudDB 在某些简单查问的利用场景下失去了近百倍甚至千倍的晋升。  汇集下推性能  Block File Skipping 优化PieCloudDB 的用户数据以行列混存的数据格式被存储在对象存储中。 同时，PieCloudDB 以 block 文件为存储单位。Block 文件按列存储，从而取得高效的压缩，节俭存储空间； PieCloudDB 在全新版本中实现的 Block File Skipping 的优化机制  在数据库运行查问语句时，通过预计算每个 block 文件中列汇集信息 ，在执行期间跳过非必要的数据块，从而缩小数据读取量，进步查问性能。  PieCloudDB 行列混存  实现极速 Analyze“Analyze” 操作能够剖析数据库表的内容，收集无关每个表的每一列中值散布的统计信息。数据库查问引擎会利用这些统计信息生成最佳查问打算。 对于大部分的数据库系统，Analyze 往往是手动执行，或由 AUTO VACUUM 主动执行，对于数据量较大的大表的查问，工夫过长。 在全新版本中，PieCloudDB 实现极速Analyze，能够在数据发生变化时主动实现Analyze，及时生成更为精确的查问布局统计信息。 全新的缓存机制针对元数据，PieCloudDB 实现了元数据层全新的缓存机制，无效缩小了拜访元数据服务器带来的网络通信开销和元数据服务器的负载，进步元数据拜访的速度。 反对疾速 ETL/ELT、和内部数据源的查问PieCloudDB 在全新版本中，原生反对 Kafka 流数据导入。copy 操作由原先的单节点优化至整个集群，性能失去大幅晋升，与集群尺寸成正比。 ...

 IaC 是 DevOps 的必要撑持。 近日，在极狐TechTalk 直播上，极狐(GitLab) 高级网站可靠性工程师SRE 戚加欣，从 SRE 视角登程，与大家分享了 IaC 基础知识、工具和办法和基于极狐GitLab 的具体实践经验。 以下内容整顿自本次分享，你也能够点击观看视频回放。enjoy～ 何为 IaC？基于 Thoughtworks 公司云实际领导人 Kief Morris 在《基础设施即代码》一书中对基础设施即代码的定义： 基础设施即代码 (Infrastructure-as-Code，IaC) 指的是通过代码而不是手动流程，来治理和配置基础设施。它把基础设施、工具和服务以及对基础设施的治理自身作为一个软件系统，驳回软件工程实际 (SRE)，以可反复的、牢靠的办法来设计、扭转和部署软件环境，以申明性的形式取代手工操作。 IaC 倒退至今，从概念到落地，从小众到遍及，随之诞生了许多 IaC 风行工具（如下图），帮忙 DevOps 团队以最佳形式自动化基础设施部署和治理。 为什么 IaC 很重要？大数据和云计算时代下的新挑战SRE 的职责之一是为业务提供根底资源，保护各种服务的性能和稳定性。 在传统工作流程中，业务方向运维团队提供一个资源需要工单，运维团队依据需要工单，手动配置软硬件根底资源给业务方。在企业规模小、业务变动小的前提下，可能一台虚拟机就能够撑持公司的所有业务，该形式能够根本满足需要。 随着大数据和云计算时代的到来，依附分布式服务器构建起来的 “云” 集群带来了弱小的计算能力；资源的动静伸缩、高扩展性也使得集群的架构变得更加简单多元，给 SRE 的工作带来了新的挑战： ➤ 日益增长的需要企业信息化和数字化水平一直晋升，IT 基础设施规模和复杂度也在一直减少。 ➤ 手动操作瓶颈大规模简单集群给手动操作带来瓶颈，通过人力运维必然是不可取的，依附自动化工具进行治理成为必然。 ➤ 脱离的反馈长期以来，开发者和运维人员的合作形式是决裂的，沟通反馈环是互相脱离的，导致生产效率低、故障排除慢。 ➤ 手动操作谬误手动操作不可避免地会有失误，规模扩充导致更大的人为失误。 IaC 帮忙企业降本增效，并实现 GitOps 指标GitOps 是一个软件开发框架，它使组织可能继续交付软件应用程序，同时应用 Git 作为繁多事实起源无效地治理 IT 基础设施。 GitOps 是 DevOps 的一个子集，它联合了 IaC 和 DevOps 最佳实际，创立了一个操作模型，用于治理架构并依据 Git 存储库的状态即时复制零碎的云基础架构。 IaC 帮助企业以多种形式治理其 IT 基础设施需要，基于以下次要劣势，帮忙企业降本增效；同时，联合 Git 的代码治理与版本控制，和 CI/CD 自动化，能够实现更高一级的 GitOps 指标。 ...

近日，国内权威剖析机构Gartner公布了《Tool: Vendor Identification for Container Management in China》报告，该报告旨在帮忙IT基础架构畛域相干人员抉择在中国提供容器治理服务、解决方案和平台的供应商，为容器产品选型提供业余领导。灵雀云实力入选容器治理平台举荐厂商。 采纳容器治理服务已成必然趋势据Gartner预测，容器市场将在2025年达到14亿美元，复合年增长率为25.1％。到2025年85%的企业将应用容器治理服务。这意味着采纳容器治理服务已成必然趋势，更早采纳容器治理服务的企业将在数字化转型中取得更多收益。在这一背景下，如何抉择适宜本人公司的容器治理产品和供应商成为了企业关注的新焦点。 家喻户晓，容器治理市场在中国有许多不同的子市场，涵盖了多种多样的解决方案和服务。本次Gartner公布的IT领导者工具，旨在帮忙IT基础架构和经营(Infrastructure and Operations)畛域相干人员，依据本身的技术现状、产品用意和不同的应用场景，更方便快捷地抉择在中国提供容器治理服务、解决方案和平台的供应商。 容器治理服务有哪些类别？在Gartner此前公布的《Market Guide for Container Management》报告中，已经对容器市场进行了定义，并将容器治理服务分为以下几个类别: ● 容器管理软件此类软件能够是由企业外部或第三方在本地公有云环境中部署和治理，也能够由供应商作为云服务来提供，在云上自动化部署和治理。容器管理软件使得容器化工作负载在大规模部署和治理时变得更加轻松。 ● 边缘优化解决方案这类计划是通过简化的容器治理平台（次要是Kubernetes），能够近程部署，且对服务器的需要很小。这类计划越来越多地将编排和操作系统性能联合起来。 ● 容器实例服务这是初代无服务器容器服务，服务会主动配置容器主机，因而用户不用配置或治理此类节点，底层的容器编排性能对用户不可见。大多数次要的云服务提供商都提供这种类型的服务。 ● 无服务器Kubernetes这是一种容器实例服务的变体，放弃与 Kubernetes 应用程序和 API 的兼容性。该服务有后劲成为一种具备吸引力的新部署模式，比惯例 Kubernetes 服务须要更少的经营工作。 ● 集群管理工具这类计划使企业可能同时部署和操作来自不同供应商的 Kubernetes 发行版。它最重要的性能是多集群生命周期治理，简化了多个供应商的 Kubernetes 集群的配置、降级和经营。 IT决策者如何抉择容器治理平台供应商？● 不存在“最佳”供应商，适宜才是最重要的组织应该依据本身需要来做出购买决策。“适宜”的服务提供商，是合乎组织评估规范，包含性能和非功能性要求，以及总领有老本（TCO）。同时，还须要有最合适的文化符合度。 ● 更大不肯定更好服务提供商的规模（以支出或人数计）并不意味着高质量。一些其余规范，例如行业教训和生态体系，也应该被视为非功能性评估规范之一。 ● 从立项的开始，就要做危险和供应商治理一旦组织开始评估和抉择服务提供商，风险管理的意识必须开始发挥作用。每个评估和抉择过程的步骤都应该波及危险评估和供应商治理的所有因素，这样能力确保平台选型的胜利。 对于供应商评估和抉择过程的倡议步骤1：依据企业本身状况和需要，确定服务类别● 容器实例服务● 容器治理● 多个Kubernetes集群治理● 无服务器Kubernetes● 集群管理工具● 容器实例服务● 边缘优化服务或解决方案● 其余 步骤2：定义交易参数● 范畴● 所需规模● 文化符合度● 高级抉择规范：包含但不限于业余技术常识、特定行业教训、平台性能、地理位置和语言等 步骤3：扫描整个市场● 利用Gartner的市场扫描办法，辨认服务提供商，组装供应商的长名单● 间接分割产品供应商，或搜寻供应商网站进行穿插参考● 审查Gartner工具包、供应商评级、魔力象限和市场指南 步骤4：确定入围名单● 从市场扫描的长名单中确定最终的供应商入围名单进行评估 为什么灵雀云ACP可能入选Gartner举荐容器治理平台?作为迄今为止入选Gartner报告次数最多的外乡容器厂商，灵雀云基于对云原生技术的前瞻摸索和客户场景需要的敏锐把握，一直进行产品迭代。最新推出的新一代全栈云原生混合云平台ACP ，涵盖了云原生基础设施、云原生利用架构、云原生DevOps、云原生数据服务和云原生数智五大平台。全平台采纳容器原生架构，以K8s为底座和管制立体，反对一键部署、主动运维，继续降级，并具备凋谢、灵便、可扩大等个性。 同时，ACP 具备弱小的生态集成能力，不仅兼容了大量成熟的社区开源工具和软件服务，还对接了各大云计算厂商、云原生周边生态厂商的第三方优良产品、解决方案和服务，产品能力深度买通，目前为止已集成上百家合作伙伴的产品和解决方案，帮忙金融、能源、运营商、政企、制作、航空、汽车等畛域的数百家客户重构平台、重塑业务，打造了诸多极有代表性的云原生落地案例。 点击此处，具体理解灵雀云ACP如何助力您取得数字化转型劣势，与灵雀云工程师独特探讨容器治理的最佳实际，即刻开启全新的云原生之旅。 ...

点我立刻报名~

01 前言CNStack 2.0（以下简称 CNStack） 作为阿里云云原生最佳实际的输入载体，其指标是提供一个凋谢、共享、标准化的云原生生态系统，使企业可能更加轻松地构建和治理云原生利用。其中，在平台侧能力扩大方面，CNStack 基于“云服务” 及 “云组件”标准规范及相应工具链，提供了凋谢、规范、易用的能力。 目前，CNStack 已公布的云服务包含：多集群治理，分布式应用治理、分布式存储、虚拟化服务、云边协同、服务网格等，后面几篇文章中，也已陆陆续续的专文介绍了多集群、虚拟化、云边协同等云服务。后续也会有更多的云服务&云组件上架 CNStack 并专文介绍。 本文将针对云服务&云组件本身及其相干工具链进行一个零碎的分享。 02 云服务&云组件简介在具体介绍云服务&云组件之前，首先咱们须要论述一下云服务&云组件的定位以及其存在的意义。 在 CNStack 体系内，咱们心愿每个面向用户提供的服务既互相解耦又可无缝合作，同时还能够简略疾速复用CNStack 平台提供的根底能力。针对此指标与冀望，咱们提出了云服务的概念，通过云服务： 基于 CNStack 平台，可在其上一直的增长新的云服务，以实现能力的扩大。各云服务之间的生命周期与公布可齐全解耦，包含与 CNStack 平台之间（实际上 CNStack 本身也是一个云服务）。基于 CNStack 平台，可疾速简略应用平台提供的用户、租户、鉴权、审计、许可证、多集群部署、UI 框架等根底能力，以及与平台既有能力或其余云服务无缝的合作能力。云服务作为一个整体提供特定的服务，而其背地真正的实体还是由云组件组成。同时思考到组件维度更细粒度的应用场景，在 CNStack 体系内，将云组件辨别为如下几种类型： 云服务组件，作为云服务中组件的一员，其生命周期和云服务统一；云服务下的组件依据其部署个性又辨别为管制面和数据面，其中：管制面组件，即管控类组件，仅在主集群上部署。数据面组件，即非管控类组件，能够在主集群/客用集群部署，其生命周期和健康状况，在集群之间互相独立。集群组件，由集群管理员独自保护，生命周期由集群管理员负责，其往往集群维度内全局惟一。我的项目组件，由我的项目管理员在我的项目命名空间中部署，其可与用户自研软件一起编排实现业务流程，其生命周期由具体使用者负责。 非凡申明：云服务&云组件本身与社区已存在的 Helm Chart、OAM（Open Application Model）等利用定义并不抵触，而是将这些利用定义做为云服务&云组件的其中一种反对形式（以后云服务&云组件仅反对 Helm Chart）。03 基于 cn-app-operator，实现云服务&云组件的残缺生命周期治理针对云服务&云组件的生命周期治理，CNStack 基于 cn-app-operator 组件以 Kubernetes CRD 模式进行治理，对于云服务方来说，只需将云服务/云组件的定义丢到集群里，接下来就交给 cn-app-operator 组件即可。 上述是 cn-app-operator 在用户提交一个云服务/云组件后，其针对云服务/云组件的生命周期的治理（注：所有云服务&云组件的申明都是在主集群中）： 依据云服务&云组件申明主动达到终态依据云服务+云服务配置申明，主动创立出对应的云组件（注：也可独自提交云组件）针对云服务，容许提供独自的云服务配置，针对云组件局部参数进行笼罩（云组件默认参数与笼罩参数的 merge 由 cn-app-operator 主动实现），以实现定义和配置的解耦针对集群组件（即集群范畴内惟一的云组件），其生命周期独立于云服务。其部署行为为：如果集群内未部署该组件，则进行部署；如果集群内已部署该组件，则仅在更高版本被申明时，进行降级；否则不做任何行为扭转依据云组件申明，通过 helm install/upgrade/rollback 等形式，使其达到云组件定义的冀望状态具体 action 会执行 helm install/helm upgrade / helm rollback， 由 cn-app-operator 主动判断监听云服务配置，多集群信息等触发上述行为的主动变更针对云服务&云组件的每次变更，基于 Kubernetes ControllerRevision 记录历史变更保护云服务&云组件的状态信息通过 LabelMarker，将所有属于云服务/云组件的 workload 打标，workload 列表通过解析 helm manifest 获取云服务&云组件 status 控制器，会依据云服务&云组件相干标签，获取并聚合 workload 的状态信息，作为云服务&云组件的实在状态高扩大能力反对，如通过扩大云组件部署器，反对多集群，边缘节点等简单场景部署基于 OCM(open-cluster-management)，扩大 cn-app-operator 组件部署器，将 helm release 下发到相应的集群中。其中决定云服务组件须要部署到哪些集群上，通过匹配云服务中组件的 ClusterLabelSelector 定义与多集群 ManagedCluster 对象的 Labels来决定。云边协同云服务，通过扩大 cn-app-operator 组件部署器，反对将 helm release 部署至边缘节点上同时为保障云服务服务质量，cn-app-operator 为云服务提供受权爱护服务，次要为云服务提供 License 信息的加密爱护以及根底部署管制（CNStack 本身的商务 License 也是基于该形式进行管控）。云服务提供方，须要针对受权环境，提供相应的服务质量保障。 ...

新一代云原生虚构数仓 PieCloudDB「云上云」版（Cloud on Cloud）已于 2023 年 3 月14日重磅公布。本篇博客将从导入数据⼊⼿，联合虚构电商销售数据等实例，具体展现查问计算和查问历史等性能，疏导您疾速理解和上⼿ PieCloudDB 云上云版本。具体的视频解说请参照疾速上手PieCloudDB视频。 本篇内容大抵分为以下五个局部： 建设虚构数仓新建文件夹和SQL文件简略实例：建设数据库和表简单实例：数据上传 -- 虚构电商销售数据查问评估：查问历史性能利用数字计算第一步：虚构数仓登录PieCloudDB云上云版本（app.pieclouddb.com），进入主界面，在左侧菜单栏点击「虚构数仓」。 进入「虚构数仓」界面，点击右上角「新建虚构数仓」创立一个新的虚构数仓。 填写虚构数仓名称，节点数，节点大小和备注。实现后，点击「确认」启动虚构数仓。 期待虚构数仓状态从启动中更新为运行中，即可应用该虚构数仓执行SQL工作。 新建文件夹和SQL文件虚构数仓创立实现且处于运行中后，咱们点击「数据洞察」进入「数据洞察」界面。点击图中的文件夹图标创立文件夹。 填入文件夹名称，点击「确认」。 点击如图所示文件图标，建设一个新的SQL文件。 点击文件栏内文件名右侧「···」按钮，可重命名、挪动、删除或导出文件。 点击「重命名」，将文件重命名为“demo_query”，点击「确认」实现重命名。 创立SQL文件后，即可在文件内书写查问语句，执行SQL工作。PieCloudDB会主动保留更新的SQL文件。 简略实例：建设数据库和表在确保有可用的虚构仓库后，关上一个SQL文件（这里咱们以先前创立的文件demo_query为例），输出以下查问语句。 create database testdb; 在运行以上查问前，抉择对应的数据库和虚构数仓执行SQL工作。这里咱们抉择初始数据库「openpie」，并抉择一个可用的虚构数仓「虚构数仓1」。 选中该语句并点击执行，执行该查问语句。 结果显示如下，数据库已创立胜利。 若想在新建的数据库中创立新表，按如图所示将执行查问的数据库切换为新建的数据库「testdb」。 执行以下语句，创立一个存储电影数据的数据表。 create table test_table (ID char(10),Name char(50),Length int,Date char(10),Type char(20));和先前创立数据库的例子类似，在PieCloudDB中选中并执行该语句。 数据表建设后，运行以下SQL语句，在该表中新增两条记录。 insert into test_table VALUES('B6717', 'Tampopo', 110, '1985-02-10', 'Comedy'),('HG120', 'The Dinner Game', 140, '1985-02-10', 'Comedy');运行以下select语句，在数据表中查看新增的记录。 ...

更多技术交换、求职机会，欢送关注字节跳动数据平台微信公众号，回复【1】进入官网交换群近日，《火山引擎云原生数据仓库 ByteHouse 技术白皮书》正式公布。白皮书简述了 ByteHouse 基于 ClickHouse 引擎的倒退历程，首次具体展示 ByteHouse 的整体架构设计及自研核心技术，为云原生数据仓库倒退，及企业数字化转型实战使用提供最新的参考和启迪。 以下为 ByteHouse 技术白皮书作业执行流程版块摘录。 技术白皮书（上）(中)精彩回顾：https://xie.infoq.cn/article/5c9471c7adb58e4bb43b69c4dhttps://xie.infoq.cn/article/086b4e706965a6bd81f6a6ff2 ByteHouse作业执行流程ByteHouse 中的作业依照响应优先级分为 3 大类：Read query、Write query 和 Background 的作业。 不同类型的作业，依照后面所述，能够运行同一个工作节点上，也能够拆散开来。 数据查问流程服务节点负责响应和承受用户查问申请，并调度到相应的计算组中去执行，并回传后果给服务节点。 各个计算节点执行完子查问之后， 很多时候会有相应计算结果要集中处理，如果心愿这一层有计算组的隔离，务节点的局部性能例如聚合最终后果须要下放到计算组中的计算节点中去。 Read Query 模块交互图 Query 的执行过程：1.用户提交 Query 到服务节点2.从元数据服务获取须要的元数据信息，对 Query 进行 Parse，Planning，Optimize，生成执行打算3.服务节点对 Query 进行调度4.计算节点接管到 Query 子查问5.Query 从近程文件系统获取原始数据，并依据 Query 的执行打算在计算节点上执行，并发回计算结果给服务节点汇总。 数据写入流程ByteHouse 实现了读写拆散，有独自写入节点来执行写入申请，写入申请分为几类：insert values, insert infile, insert select，insert values 可能蕴含大量数据集，为防止网络传输开销间接由服务节点本地执行 insert 而无需转发给写入节点来执行。 Write Query 模块交互图 Query 的执行过程：1.用户提交 Write Query 到服务节点2.服务节点从元数据服务获取须要的元数据信息，对 Query 进行 parse，planning，optimize，生成执行打算，依据写入类型分为以下两种模式来执行： Local 模式：insert values 操作间接由服务节点跳转到步骤四间接执行分布式模式：对于 insert infile/select 模式间接将执行打算信息分发给一个写入节点执行3.服务节点对写入申请依据调度策略抉择适合的写入节点执行4.写入节点从读取节点(insert select)或者内部存储(insert infile hdfs)读取数据流5.写入节点写入数据到本地盘6.写入节点 导出 本地盘到云存储7.写入节点 更新元数据后台任务为了更好的查问性能，会有一些作业在后盾对写入的数据进行更进一步的解决。ByteHouse 中次要包含如下 3 种后台任务。 ...

云原生利用的遍及为企业带来高效、便捷的应用体验，但也带来了新型攻打门路和平安问题。本期，京东云资深平安专家将为你揭秘云原生时代面临的五大平安危险以及京东外部的平安应答最佳实际 嘉宾介绍 邱雁杰 京东云事业群云产品研发部架构师 目前负责京东云平安产品部平安技术总监，有超过十年的大型互联网公司平安技术实践经验，次要关注云原生平安、利用平安、平安产品架构、红蓝反抗、平安经营等方面，主导研发过多个云平安产品，深刻理解平安产品在企业具体实际落地的重要性。

云原生下的服务治理在云原生技术的演进过程中，依靠云原生技术能力，造成一个能够向下治理基础设施，向上治理业务利用的技术中台，越来越成为企业冀望的云原生技术落地趋势。随着云原生技术中台 CNStack 公布具备变革意义的新一代 2.0 版本，其提供的云原生技术能力不仅能够撑持大规模业务零碎，也能够将外部不对立的体系集中管理起来，通过中台化的形式输入云原生技术能力。通过 CNStack 能够低成本实现业务利用的云原生革新，并且 CNStack 云原生平台能够为接入的利用提供业务监控、流量治理、服务凋谢等多种能力。 深刻到微服务体系中，CNStack 平台为简单的微服务架构零碎提供了多方面的服务治理与可视化监控能力，其中通过配合可视化数据监控与限流降级能力，运维人员能够确保业务零碎不论是在失常运行时、公布变更过程中、还是流量猛增的状态下，都能够安稳对外提供服务。诸如常见的线上突发流量导致服务流量超过承载能力、服务上游依赖呈现不可用导致影响本身服务稳定性等场景，CNStack 提供了全方位的流量防护能力，以流量与容错为切入点，从流量管制、不稳固调用隔离、熔断降级、热点流量防护、零碎过载爱护等多个维度来帮忙保障服务和网关的稳定性，同时提供秒级的流量监控剖析性能。 疾速玩转流量防护一键接入防护能力CNStack 平台提供了十分便捷敌对的利用接入形式，通过工作空间下的利用治理能力能够疾速创立利用，并且通过利用治理接入的利用均会默认主动接入流量防护能力，能够为利用疾速全方位配置流量防护。抉择 Java 类型创立的托管利用，会通过挂载探针的形式接入流量防护能力，不须要对业务代码进行任何埋点革新，对业务利用无侵入。 通过 CNStack 平台接入的利用，能够取得秒级业务监控、限流熔断防护、自定义行为配置等多项能力保障服务稳固运行。相比社区风行的开源 sentinel 等流量防护接入形式，应用 CNStack 平台不须要任何代码革新，也不要增加任何额定的配置，能够一键针对所有接入利用开启防护能力。并且 CNStack 平台原生地为所有接入利用提供了更加弱小的流量防护能力，以及稳固的秒级监控零碎，能够在平台上一站式实现线上系统维护。 为了疾速玩转 CNStack 流量防护能力，接下来针对一些常见的线上业务场景，介绍如何在 CNStack 中通过配置流量防护规定，保障业务利用在各类不稳固场景下失常提供服务。 场景 1. 线上流量激增线上流量有很强的随机性与不可预测性，因为重要新闻公布、流动促销等因素都会导致突发的激增流量。然而线上零碎的容量是无限的，如果突发增长的流量超出了零碎承受能力，会导致大量申请解决沉积，CPU/Load 飙高，申请解决迟缓甚至报错。因而，在零碎设计时须要针对这种突发流量设置保护措施，在尽可能解决申请的同时保障服务不被打垮。 例如当下火爆的 ChatGPT，在公布短短数天工夫内用户量达到百万级别，注册用户之多甚至导致服务器爆满，国内也有多个团队及公司公布类 ChatGPT 的对话机器人，用户注册同样火爆。构想这样一个场景，企业研发并上线了一个类 ChatGPT 对话机器人业务，业务利用集群部署的规模预期能够承载数万用户同时拜访，但随着业务上线受到宽泛关注并且涌入大量用户注册应用，线上用户规模迅速激增至十万，在对线上零碎不做流量爱护的状况下，大量用户的拜访申请可能会将零碎间接打垮，导致整个服务瘫痪陷入不可用。然而在 CNStack 流量防护场景下应用流控规定，能够预防线上的突发激增流量，保障系统在可接受的范畴内稳固运行。创立一条流控规定的配置参数能够参考下图： 依照上述示例中配置的流控规定，流控策略会将每秒拜访 /startTalk 接口的申请次数限度为 600，每秒 600 次以内的申请会全副失常通过，当一秒内的申请量达到 600 后会触发限流，限流后超出 600 个的申请会依照程序排队期待通过，排队等待时间超出 500ms 后疾速失败。最终流控成果如下图所示，当初始流量较低时，所有申请均失常通过，当流量快速增长达到阈值 600 时会触发限流，每秒放行 600 个申请通过，其余申请会被回绝，保障了阈值范畴内流量的失常拜访。 场景 2. 微服务自我爱护微服务架构中不同的服务之间可能会存在依赖关系，例如调用第三方的 API、数据库、近程服务，并由不同服务之间互相调用，组成简单的调用链路。然而，被依赖服务的稳定性是不能保障的，如果依赖的服务呈现了不稳固的状况，申请的响应工夫变长，那么调用服务办法的响应工夫也会变长，线程会产生沉积，最终可能耗尽业务本身的线程池，服务自身也变得不可用。 假如如下场景，微服务通过数据库查问用户信息，所有的查问工作会提交至线程池队列，异步去数据库查问用户信息。因为数据库索引变更或者刷脏页等起因产生了慢 sql，进而使得查问的线程池工作沉积，并最终导致线程池耗尽整个服务不可用。在 CNStack 流量防护场景下，能够针对这样的场景配置熔断规定，对于不稳固的依赖调用进行主动熔断降级，避免上游依赖问题导致本身线程池沉积影响服务稳定性，达到保障整体零碎稳固运行的成果。创立一条熔断规定的配置参数能够参考下图： ...

背景最近，云原生计算基金会 CNCF 下的 App Delivery TAG （利用交付畛域小组）公布了《CNCF 平台工程白皮书》，KubeVela 被纳入“对立 API 层”我的项目。 原文下载链接：https://appdelivery.cncf.io/whitepapers/platforms/回溯 2019 年，Kubernetes 逐步成为部署和治理基础设施的事实标准。越来越多的平台工程师开始在 Kubernetes 之上构建平台，并向最终用户提供服务。容器化部署和申明式 API 大大降低了简单零碎操作的难度。 然而，当集群中存在数千个工作负载和相干资源时，操作人员很难辨认逻辑关系，并依据其外部关系进行精确且合乎业务须要的治理。 同时，像 Helm 或 Kustomize 这样的工具曾经摸索了 打包和交付 Kubernetes 资源的解决方案。这些已被证实是十分无效的，显然 Helm Chart 当初是在 Kubernetes 中打包和散发制品最受欢迎的形式。 另一方面，各种我的项目也开始定义应用程序。这些尝试不仅是简略地打包资源，而是从自上而下的视角寻求解决方案。与将离散的对象分组以更方便使用相比，应用程序旨在弥合业务利用的研发者和基础设施之间的认知差距。凋谢利用模型 Open Application Model（OAM）[1]及其对 KubeVela 的实现正是从这里开始。 Pic 1. OAM is proposed to bridge the gap between app developers and the use of underlying infrastructures 应用程序模型的诞生由微软和阿里云反对的凋谢应用程序模型（OAM），其指标是为云原生应用程序应该是什么样子提供一个实践模型。它最后被设计为不与 Kubernetes 绑定，并且偏向于为操作应用程序提供对立的接口。OAM 提出了组件和个性的概念，以对应用程序架构进行形象。这对于原生 Kubernetes 用户来说是一个很大的改革，但这是有起因的。 在 Kubernetes 中，Deployment 或 Service 等资源侧重于实现。每种资源类型都提供特定的性能。一些低级性能，（如运行容器），会转到 Pod 等根本单元。一些更高级别性能，例如容器编排，解决回滚的性能，（例如 Deployment 或 StatefulSet），则是建设在较低级别的性能之上的。毫无疑问，“为平台构建者服务的平台”这个定位取得了微小的胜利。但对于利用开发人员来说，社区正在迫使他们成为 Kubernetes 专家能力使事件失常运行。此外，对低级资源的浮浅了解实际上可能导致不正确操作带来的显著危险。 ...

前言大家好！我是 Rainbond 创始人刘凡，往年是 Rainbond 创建和开源的第七年，这个过程中我见证了Docker、K8s、云原生等技术的演进，Rainbond 也进化成为一体化的云原生治理平台，基于这么多年的产品研发及行业积淀，我来分享咱们对云原生的一些思考，以及云原生技术为企业数字化转型带来的新模式。 集体数字化三大驱动力谈到企业数字化，首先咱们来回顾一下集体数字化的历程和驱动力，通过剖析和总结集体数字化，对咱们了解企业数字化有借鉴意义。家喻户晓集体数字化最大的驱动力是挪动互联网。挪动互联网定义了技术实现和用户体验，催生了大量利用场景，为咱们的生存带来了极大的便当。上面咱们具体解析一下挪动互联网的驱动力。 集体数字化三个最要害的驱动力，别离是易用性、生态建设及服务化。 易用性：Android、iPhone手机等终端产品，能够做到较强易用性，小孩都能顺畅应用，是由其触摸屏及苹果定义的Iphone交互体验所决定的，易用性让挪动终端的用户快速增长，从而为集体数字化提供了松软的用户根底。生态建设：iPhone建设了App Store（利用商店）模式，通过利用生态，更多厂商能够为挪动设施开发利用，产生了大量能够应用的利用，这些利用能笼罩到集体数字化生存的方方面面，生态建设为集体数字化提供了更多利用。服务化：软件自身是没有价值的，只有把软件变成服务，能力给用户带来价值，而服务订阅是可继续倒退的商业模式，它让集体数字化可能良性倒退。云原生驱动企业数字化的四种模式而对于企业数字化，云原生技术等同于集体数字化时代的挪动互联网，在整个企业数字化过程中表演十分重要的角色，已驱动着企业数字化。基于对集体数字化的总结，咱们来剖析一下企业数字化的驱动力。 企业数字化中利用多且简单，与集体数字化有很大不同。所以除了集体数字化外面所提及的易用性、生态建设、服务化三个关键点，咱们还须要关注利用全生命周期赋能，它是企业数字化的最底层驱动力。上面我别离从易用性、生态建设、服务化、利用全生命周期赋能这四个方面来解说一下具体的实现模式。 1、云原⽣的“易⽤性”模式 - 应⽤级形象模型易用性越高，受众人群越大，易用性每进步一点，用户基数出现几何倍数减少。云原生的易用性，波及三个档次。 最上面一层是Kubernetes和容器技术，Kubernetes和容器技术解决了运维治理中环境治理和自动化调度问题，晋升了对简单利用运维治理的易用性，但K8s和容器技术门槛比拟高，要应用起来还是须要专门的学习，适宜专职的工程师。如果要让更多人能应用起来，还须要更加易用。第二层是通过利用级形象模型搭建利用治理平台，使用者不须要关怀容器和K8s等底层技术，只须要关注业务自身，治理的领域也扩充到利用的全生命周期，应用的关注点上移，重心在业务发明，体验上实现现积木式业务模块拼装和能力按需扩大。在这一层面，易用性相比容器形象，大幅度晋升，所有开发人员都能够疾速上手，应用人群能进一步扩充。最上层，提供服务级应用体验，应用群体能够齐全不必懂技术，相似手机App Store的应用体验，即点即用，用户实现自助装置和降级，这层的易用性适宜所有企业用户。 2、云原⽣的“⽣态建设”模式 - 云原生应⽤市场企业数字化的生态建设与集体数字化相似，也须要通过利用市场来实现。然而，因为企业数字化中利用和资源的复杂度较高，要实现利用市场，须要建设利用和资源的规范和标准，并且要可能齐全解耦。此外，在交付的状态也更为简单，须要解决各种企业场景的交付问题。 为了适应实在的企业数字化场景，云原生利用市场须要解决这些问题： 在利用供给方面，软件供应商能够自助退出和上架利用，依据不同颗粒度的软件有不同类型的软件厂商退出。小颗粒根底能力厂商提供业务组件、技术组件、中间件、API等；中等颗粒度的行业产品和通用产品厂商提供通用软件产品和行业软件等；大颗粒度的行业解决方案厂商和集成商提供残缺的解决方案，或基于能力和产品拼装行业解决方案。在计算资源供给方面，厂商也能够自助将本人的资源退出，前提是要合乎K8S、API等规范。这样，利用市场就领有了各种资源、各种利用、各种底层等模块。在交付能力方面，对于行业中小用户来说，可间接全自助交付，强调服务化和低成本化；另一方面，对于行业大型用户来说，能够基于他们本身的基础设施，实现软件自动化装置，供应商可近程对基础设施进行保护治理及定制开发。总的来说，云原生生态建设须要通过利用市场的形式来落地，真正激活整个生态及整个软件行业，并实现最终用户自助的灵活性和生产利用场景的多样性。只有这样，能力适应实在的企业数字化场景，推动云原生技术的进一步倒退和利用。 3、云原⽣的“服务化”模式 - ⾃服务SaaS随着数字化的减速倒退，越来越多的企业开始应用云原生技术来构建本人的数字化平台。云原生技术的一个重要利用就是自服务SaaS，通过自动化的运维过程，实现自助式的SaaS服务交付，大幅度晋升企业数字化的效率。 自服务SaaS，顾名思义，就是利用云原生技术将企业软件自动化为SaaS服务的形式，提供给企业用户应用。这种服务模式不仅能够帮忙企业降低成本，还可能进步数字化服务的交付效率，为企业带来更大的价值。 自服务SaaS的实现须要从以下五个方面思考： 第一，企业软件。通过将企业软件进行云原生革新，实现自动化的运维过程。这样，企业能够疾速部署利用，进步数字化服务的交付速度和效率。 第二，计算资源。通过云原生技术实现自动化计算资源调度，将企业应用交付到本人的计算资源中，解决数据安全问题，并降低成本。 第三，主动装置。通过云原生技术实现自动化的装置过程，用户只需简略操作，即可疾速应用企业应用，进步数字化服务的用户体验。 第四，主动运维。通过云原生技术实现自动化的运维过程，实时监控利用的运行状态，并主动修复故障，进步数字化服务的可靠性和稳定性。 第五，多租户。通过云原生技术实现多租户机制，为不同用户提供独立的应用服务，并实现资源的隔离和共享。 4、云原⽣为应⽤全⽣命周期赋能，实现企业应⽤⼀体化治理云原生为企业应用生态赋能，次要波及利用生命周期的四个方面。 首先，从开发角度看，云原生能够实现源代码的自动识别和构建，并提供云端开发、云端调试以及一体化的开发环境。这样能够让开发人员专一于业务代码的开发，而无需进行太多的迁徙工作。 其次，从架构角度看，云原生能够实现可拼装的业务逻辑、无侵入的微服务架构以及按需扩大的服务治理能力。这些个性最终带来的价值是模块化的复用率大幅度提高，所有厂商都能够找到适合的定位，从而实现积木式的拼装体验。因而，每个企业都能够通过云原生疾速落地数字化转型。 第三，从交付角度看，云原生能够通过利用模版实现一键装置和降级，并主动适应各种交付环境，从而实现自动化交付和灰度公布，进步迭代和交付效率，同时进步交付过程的标准化。 最初，从运维角度看，云原生能够让底层的零碎运维环节变得更加简略，应用层运维变得更加自动化。这不仅能够为企业带来效率晋升，同时也让开发者除了编写代码以外，还可能实现对整个开发过程的可控，从而进步资源利用率。 企业数字化的iPhone时刻 这些驱动力形成了云原生的根底，使得企业可能更快地进行数字化转型，并且通过新模式来进步数字化转型的效率和品质。我置信随着云原生技术的一直倒退和遍及，很快就会呈现“云原生的iPhone时刻”，这将助推企业数字化建设全面开花。

2022年Q2季度，中国信通院、中国通信标准化协会在云原生产业大会上重磅公布了《云原生产品目录》。作为国内首家专一于云原生智能运维的公司，成都元来云志科技有限公司（简称“MIAOYUN”）旗下产品秒云容器云平台胜利入选。 中国信通院《云原生产品目录》★寰球数字经济进入高速发展期，数字化浪潮愈演愈烈，在麻利、高效、降本需要的驱动下，全面云原生化已是大势所趋。企业必须紧跟云原生倒退路线，减速产业转型和系统优化，施展技术创新价值，放弃市场竞争劣势。 《云原生产品目录》是中国信通院为解决云原生用户选型窘境，全面拉齐行业认知，推动我国云原生产业蓬勃发展而发动、征集和评比进去的。共收录云原生技术服务产品及解决方案251个，波及容器、微服务、服务网格、无服务器、云原生存储、云原生数据、云原生平安，以及云原生交融服务等多个类别。本次秒云容器云平台入选《云原生产品目录》，成为中国信通院权威举荐的容器产品，标记着MIAOYUN在云原生畛域的技术实力和产品服务再获权威认可。 MIAOYUN容器云平台★秒云容器云平台基于Docker容器技术和以后最风行的Kubernetes容器编排引擎。依靠于容器人造的劣势，和丰盛的容器调度和编排机制，重点解决企业生产环境中的基础设施云化，利用部署简化，运维治理自动化等难题。MIAOYUN云原生之路★作为国内首家专一于云原生智能运维的公司，自成立以来，MIAOYUN始终秉持着“一秒入云，一键智维”的理念，继续深耕云原生赛道，长期退出Linux基金会会员和CNCF云原生计算基金会会员，并通过 KCSP（Kubernetes Certified Service Provider）认证，成为 CNCF官网认证的Kubernetes服务提供商。 此外，MIAOYUN在云原生畛域的技术积也累失去了业界生态的认可，2021年入选VIN威睿减速打算第二期，2022年入选阿里云首期云原生加速器，2023年入选《2023爱剖析·云原生智能运维中台市场厂商评估报告》和《开源GitOps产业联盟生态图景2.0》。 云原生时代，云上翻新成为常态，企业须要紧跟云原生倒退路线，减速产业转型，施展翻新技术价值。将来，MIAOYUN将继续聚焦云原生，加大在云原生畛域的摸索与翻新，不断丰富云原生产品、服务和解决方案能力，帮忙企业降本增效，为企业云原生转型赋能。

作者：杨奕  华为云技术布局专家在以往的文章《云原生微服务治理技术朝无代理架构的演进之路》中，咱们介绍了几种微服务架构模式，如下图所示。注：图片起源 https://twitter.com/bibryam/status/1026429379587567616 明天次要是介绍，第一种SOA/ESB架构，在Java语言场景下，如何朝第三种 云原生ServiceMesh架构 的演进的问题。 SOA/ESB架构简介和问题概览首先咱们来看看 SOA/ESB 架构模式 在目前私有云上的典型参考架构。 如下图所示，以华为云为例，以该模式部署利用时，其应用到的典型云服务为 弹性负载平衡 (ELB) + 弹性伸缩(AS，蕴含ECS)。在这种场景下， 须要发动调用的客户端程序，通过配置好的域名或地址，间接调用到ELB上，通过ELB去调用到后端的ECS服务器。ELB上须要配置后端服务器的多个IP地址。当然，个别这类操作能够简化为增加某类弹性伸缩组。这样，当ECS产生弹性伸缩时管理员无需解决ELB配置，ELB即可主动刷新ECS的IP列表的变动。 (配置操作可参见：https://support.huaweicloud.com/usermanual-as/as_01_0102.html)值得注意的是，以上的模式可能存在几种变种。对于ELB，可能会采纳API网关代替，或者用户自建的KONG, APISIX,Envoy等，具体取决各个企业的本身业务场景。例如，某些互联网公司偏向于采纳企业自建的KONG，其次要起因是除了根本的服务发现和负载平衡能力以外，网关还须要解决面向外部跨域调用的一些鉴权状况解决。对于弹性伸缩，可能也会间接采纳Kubernetes的Deployment + HorizontalPodAutoscaler代替。这当然取决于企业外部的基础架构采纳状况，看是更偏向于应用虚拟机架构还是容器架构。以上架构尽管在隔离性、安全性上存在肯定长处，然而短板也非常明显。性能和资源开销。这个比拟好了解，绝对微服务架构，SOA/ESB架构上网络减少了额定一跳，而且ELB的引入也会导致资源的额定耗费增多。运维老本。毕竟额定引入了一个ELB的组件，因而在微服务之间调用时，瓶颈在哪里，ELB是否须要扩缩容，都是问题。微服务和云原生架构革新的一些办法和问题对于如何革新 SOA/ESB 架构，朝微服务架构或云原生架构演进，业界也有很多办法。次要是以下两类。 通过批改代码，将利用革新为微服务架构。例如间接在代码中引入比方SpringCloud的服务注册发现和负载平衡等组件。当然，这种革新往往也并不简略，次要取决于现有利用已采纳的开发框架，等。比方利用自身没有采纳spring来进行开发，那么间接采纳SpringCloud可能会为利用带来海量的革新老本。采纳istio计划，通过无限革新利用，将架构降级为ServiceMesh架构。之所以该计划说是无限革新，而不是无革新，也是因为在服务调用形式上，istio计划对利用并不是齐全无限度。其至多须要在客户端将调用的http调用地址革新成为k8s原生的服务地址，调用的服务治理能力被envoy无效接管。当然，革新结束后，用户在接下来在面向边车的性能衰减，更简单的调用运维问题上，恐怕一个也不会少。综上所述，两种计划都存在比拟显著的短板。接下来剖析下采纳Sermant形式进行架构革新，如何补救上述两种计划的短板。Sermant对SOA/ESB架构降级的一些思路采纳Sermant (https://sermant.io/zh/) 对SOA/ESB架构降级，实质上的最初的架构终态是Service-Mesh。然而因为采纳的办法稍有不同，从而导致计划在性能和运维问题上都不存在短板。次要是以下两点： 首先，Sermant采纳Java Agent来动静注入加强的服务逻辑治理，因而利用侧实践能够做到齐全不必改代码。其次，因为Sermant的外围逻辑是以AOP (面向切面编程) 形式，Java Agent和业务属于同一过程，因而在性能方面不存在sidecar状态的特地大的损耗。Sermant计划架构如下图所示。在核心技术点上，Sermant革新计划的性能次要有以下几个方面： * 内置的服务注册发现机制。(上图中的第一点和第三点)  插件自身会带服务注册性能，在Provider利用启动的时候主动到注册核心进行服务注册。在Consumer利用进行URL服务调用的时候，通过微服务服务发现+负载平衡机制代替原先的服务直调。* 域名到服务名(有时也称利用名)的转换。(上图中的第二点) 服务发现时，因为原先的调用采纳URL直调，并不蕴含利用信息。这就须要一个调用关系到利用名的映射。对于这块内容，将来咱们打算做成了一个动静配置，存储到配置中心里。这样当有利用须要发动调用时，Sermant间接将URL转换成利用名，就能够在注册核心获取响应的利用IP列表。通过URL获取Provider利用名后，因为在革新过程中，不必Provider利用并不是同批次公布携带Sermant Java Agent，因而还须要有个白名单机制，来配合灰度公布。* 加强的客户端侧负载平衡、重试、隔离、降级机制。(上图中的第四点) 联合上一步，残缺的商用计划，Consumer调用Provider除了须要满足根本的负载平衡性能以外，还须要更进一步进行重试、容错隔离、以及对上游的限流降级解决。此外，对于一些必要的东西向流量的治理能力，如服务间的3A认证，等，也须要进一步在Sermant端补齐。以上便是Sermant革新计划的次要性能点。另外，在实操中如何针对现有环境进行降级还是须要肯定办法，防止对现有环境进行太大冲击。以下具体叙述。 采纳Sermant对SOA/ESB架构降级的计划实操利用革新在具体局点上不可能欲速不达，因而在具体上施行上必定是一个缓缓灰度的过程。以Kubernetes容器场景为例，介绍下在上百个微服务利用上千实例的状况下，如何采纳Sermant对SOA/ESB基于灰度进行平安可控的云原生架构降级。 以下为筹备工作： 筹备步骤一：本身利用是否反对。以后Sermant反对的微服务降级的Java框架能够在该文档中查问。如未反对，能够思考给社区提Issue解决。 参考链接：https://sermant.io/zh/document/plugin/springboot-registry.htm...筹备步骤二：在Kubernetes中装置Injector，不便以非侵入形式让Java利用主动挂载Sermant Java Agent. 本步骤可选。如跳过，则须要手动扭转利用部署脚本加载Sermant Java Agent。 参考链接：https://sermant.io/zh/document/user-guide/injector.html 以下介绍具体施行过程。假如初始架构如下。一共三个App，其中App1通过ELB连贯到App2和App3。为简化表述，图中为利用均为单实例，理论生产中的实例可能会有多个。 接下来，在Kubernetes中对新版本的App1, App2进行公布(图中为V2版本)，并在公布时携带Sermant Java Agent，以及激活SpringBoot注册插件。然而此时能够先不配置Provider白名单规定，因而公布后，利用流量应该还是走ELB，未产生任何变动。 接着在配置核心，将App2退出到白名单中。此时，对辨认到App2的利用，挂有Sermant Java Agent的App1实例 (图中的V2实例) 会对App2的实例以负载平衡形式间接发动调用。与此同时，App1拜访App3的流量没有变动。 验证胜利后，删除App1、 App2的V1版本，App1到App2的流量通过注册核心的注册发现，齐全实现直连。同时，App1拜访App3的流量维持不变。至此，应用Sermant对App1、App2的云原生架构降级完结。后续其余App利用，能够依照相似计划，进行灰度降级，直至所有利用全副挂载上Sermant，实现微服务直连革新。 结束语Sermant 作为专一于服务治理畛域的字节码加强框架，致力于提供高性能、可扩大、易接入、功能丰富的服务治理体验，并会在每个版本中做好性能、性能、体验的看护，宽泛欢送大家的退出。 Sermant官网：https://sermant.ioGitHub仓库地址：https://github.com/huaweicloud/Sermant增加Sermant小二（微信号：sermant-support）退出社区交换群或扫码退出Sermant社区交换群 

5月30日-6月2日，作为疫情后的第一场线下会议第17届 PostgreSQL 国内开发者大会（PGCon 2023），将在加拿大渥太华隆重举行。拓数派将作为黄金赞助商，受邀参加本次盛会，与寰球数据库爱好者们共聚加拿大。此外，拓数派 PieCloudDB Database 技术专家 Richard Guo 也受邀在本次大会中发表主题演讲，将具体介绍拓数派打造的全新优化器「达奇」和执行器的相干实践与实际。 PGCon 是面向 PostgreSQL用户和开发者的年度会议，每年都汇聚了来自各个国家的泛滥 PostgreSQL Committer，Contributor，和资深用户，被誉为是PostgreSQL届的『朝圣』大会。自2007年开始，迄今曾经举办了 16 届。这一年一度的技术盛会上，会议委员会精心筛选出泛滥演讲话题，内容优质、主题丰盛，涵盖了数据库治理、性能调优、数据安全、技术细节与实现等泛滥深度方向，为寰球的数据库技术爱好者们打造一场技术盛宴。   PostgreSQL 作为世界上最先进的开源关系型数据库之一（官方主页：”The world’s most advanced open source database”），因为其代码开源、安全可靠、和扩展性等劣势，变得越来越风行。据数据库排名网站 DB-engine 的数据显示，PostgreSQL 风行度从2013年最低点的167分，攀升到本月的616.5分，增长了近2.7倍，并长年排在排行榜前五的地位中。PostgreSQL用户群体也日渐宏大，生态更加凋敝。  拓数派作为搭档社区，始终沉闷在 PostgreSQL 开源社区中，以代码奉献、会议资助、演讲布道、文章撰写等多种形式参加到 PostgreSQL 的社区奉献中。其中，在代码奉献方面，拓数派研发团队的多名共事在PostgreSQL 11、12、13、14及最新公布的15版本中均有代码奉献，引领PostgreSQL中国代码奉献力。（具体内容请参考相干文章） 除了代码奉献，在 PostgreSQL 社区举办的各类流动中也常常能看到拓数派的身影。在过来一年中，拓数派参加了PostgreSQL生态大会、PostgreSQL技术大会等泛滥技术会议，踊跃进行数据库技术步道。拓数派多位共事被选为 PG ACE 贡献者；在2022 PostgreSQL年度技术评比中，拓数派被授予为「科技冲破企业」证书。这些问题充分证明了拓数派弱小的技术实力和「拥抱凋谢」的公司文化。   除了上文提及的对 PostgreSQL 社区的奉献，拓数派始终器重与对寰球前沿数据库技术的投入和生态体系的构建。 拓数派旗下产品 PieCloudDB Database 已公布云上云版、社区版、企业版与一体机，满足企业不同业务场景需要。PieCloudDB 在eMPP分布式专利技术、服务器无感知（Serverless）和TDE等多项核心技术加持下，为企业构建高平安，高牢靠，高在线「坚如磐石」的云原生虚构数仓，助力企业实现数据价值最大化，更好地赋能业务倒退并走向绿色，成为新一代AI数据计算基础设施的一个榜样。 

更多技术交换、求职机会，欢送关注字节跳动数据平台微信公众号，回复【1】进入官网交换群I. 传统数仓的演进：云数仓近年来，随着数据“爆炸式”的增长，越来越多的数据被产生、收集和存储。而开掘海量数据中的实在价值，从其中提取商机并洞见将来，则成了古代企业和组织不可漠视的命题。 随着数据量级和复杂度的增大，数据分析解决的技术架构也在一直演进。在面对海量数据分析时，传统 OLAP 技术架构中的痛点变得越来越显著，如扩容缩容耗时长，导致资源利用率偏低，老本居高不下；以及运维配置简单，须要业余的技术人员染指等。 为了解决这类问题，云数仓的概念应运而生。和传统数仓架构不同的是，云原生数仓借助于云平台的根底资源，实现了资源的动静扩缩容，并最大化利用资源，从而达到 Pay as you go 按理论用量付费的模式。 ByteHouse 作为云原生的数据平台，从架构层面动手，通过存储和计算拆散的云原生架构完满适配云上基础设施。在字节跳动外部，ByteHouse 曾经反对 80% 的剖析利用场景，包含用户增长业务、广告、A/B 测试等。除了极致的剖析性能之外，ByteHouse 开箱即用，按理论应用付费的个性也极大地升高了企业和集体的上手门槛，可能在短短数分钟内体验到数据分析的魅力。 Talk is cheap, 接下来就让咱们通过一个实战案例来体验下 ByteHouse 云数仓的弱小性能。 II. 疾速上手 ByteHouse——轻量级云数仓本章节通过应用 ByteHouse 云数仓进行 SSB 基准测试，在率领读者理解产品性能的同时，也一并相熟产品中各个模块的性能，开启你的数据分析之路，通过剖析海量数据，减速数据洞察。ByteHouse 的架构总览如下。 SSB 基准测试SSB（Star Schema Benchmark）是由麻省州立大学波士顿校区的研究员定义的基于事实商业利用的数据模型。SSB 是在 TPC-H 规范的根底上改良而成，次要将 TPC-H 中的雪花模型改成了更为通用的的星型模型，将基准查问从简单的 Ad-hoc 查问改成了构造更加固定的 OLAP 查问，从而次要用于模仿测试 OLAP 引擎和轻量数仓场景下的查问性能。因为 SSB 基准测试较为中立，并贴近事实的商业场景，因而在学界及工业界有宽泛的利用。 SSB 基准测试中对应的表构造如下所示，能够看到 SSB 次要采纳星型模型，其中蕴含了 1 个事实表 lineorder 和 4 个维度表 customer, part, dwdate 以及 supplier，每张维度表通过 Primary Key 和事实表进行关联。测试通过执行 13 条 SQL 进行查问，蕴含了多表关联，group by，简单条件等多种组合。更多详细信息请参考 SSB 文献。 ...

近日，龙蜥社区系统安全 MeetUp 圆满结束，来自 Arm、阿里云、海光、Intel、统信软件、AMD、达摩院、蚂蚁团体、中科微澜及北京大学等 42 位专家、学者和意见首领加入了本次流动。会上正式公布《商用明码技术最佳实际白皮书》和《云原生秘密计算最佳实际白皮书》两大龙蜥社区操作系统平安白皮书，致力于帮忙宽广面临 OS 平安问题的用户深刻理解操作系统标杆产品实际，让业务翻新与技术摸索有安全可靠的基座，为 OS 平安行业奉献龙蜥力量。 （图/龙蜥社区系统安全 MeetUp 现场合照） 会议伊始，龙蜥社区平安委员会主席、阿里云资深技术专家龙勤分享了龙蜥社区平安委员会的定位与布局，总结了龙蜥社区几大平安技术 SIG 的工作成绩，并示意，“作为龙蜥社区规划与布局的八大技术方向之一，构建从硬件到云原生的全栈平安技术体系，保障用户操作系统的平安可信，让业务翻新和技术摸索领有安全可靠的基石，将是龙蜥社区平安委员会和平安技术 SIG 的独特指标。” （图/龙蜥社区平安委员会主席、阿里云资深技术专家龙勤） 随后，龙蜥社区平安委员会 Contributor、统信软件服务器操作系统与云计算产线平安研发经理曹佩庆，为现场嘉宾带来《UOS 系统安全架构简介》主题演讲，与大家独特探讨统信操作系统平安体系架构，以及重点关注的平安倒退方向。 （图/龙蜥社区平安委员会 Contributor、统信软件服务器操作系统与云计算产线平安研发经理曹佩庆） 龙蜥标准化 SIG Owner、阿里巴巴标准化部总监刘大鹏，达摩院技术专家郑耿分享了《标准化助力龙蜥社区标准及平安倒退》。 （图/龙蜥标准化 SIG Owner、阿里巴巴标准化部总监刘大鹏） 刘大鹏为大家具体介绍了龙蜥社区标准化 SIG 及正在制订的标准。标准化 SIG 的指标是联结 Anolis OS 生态搭档独特制订 Anolis OS 的工程规范并确保社区产品合乎行业国家相干的规范 ，确保 Anolis OS 在产业链上下游应用的兼容性、一致性，助力 Anolis OS 凋敝生态建设。标准化 SIG 制订的龙蜥社区治理标准，通过在龙蜥社区中引入软件物料清单等内容，促成龙蜥社区标准、平安倒退，后续将会与龙蜥社区平安相干 SIG 严密单干进行标准落地。 （图/达摩院技术专家郑耿） 开源供应链平安是近些年平安畛域的热门话题。针对开源供应链的攻打有着攻打面广、影响面大、防备难度低等特点。郑耿分享了龙蜥社区如何通过标准化伎俩治理社区，晋升社区透明性和安全性的实际。龙蜥平安团队通过和标准化 SIG 的单干，以社区标准的模式引入了社区 SBOM 标准，为后续通过 SBOM 去晋升软件的透明性，排查软件合规危险、晋升安全事件响应效率打下了松软的根底。 龙蜥破绽治理负责人、阿里云技术专家张世乐，中科微澜王宁做了《龙蜥破绽管理体系》主题演讲。 （图/龙蜥破绽治理负责人、阿里云技术专家张世乐） 安全漏洞治理是操作系统平安防护的重要组成部分，张世乐在演讲中向嘉宾介绍，龙蜥社区已建设基于危险的安全漏洞治理流程，从安全漏洞情报感知，威逼剖析与危险评估，到破绽修复，平安布告公布全生命周期的管理体系。龙蜥社区现已获取CNA资质，并胜利申报多个CVE，也积极开展社区平安单干，与多个平安组织及三方平安厂商在破绽扫描与破绽开掘上开展单干，共建龙蜥平安生态。 ...

作者：王晓彬：政采云资深开发工程师，负责根底服务相干工作 徐锡平：政采云资深开发工程师，负责根底服务相干工作 对云岛业务构造的公司来说，云平台属于公司外部、齐全可控的局域网，而岛端则是有本人平安网络策略的独立外部网络。须要云岛通信时，会基于需要，按客户要求走流程开明一些端口，这个过程须要肯定的老本且不齐全可控。业务上，如果这种跨网需要增多，则会逐步变成痛点。如果能够搭建一个通明的跨网传输网络，配合良好的顶层设计，就能够在业务撑持、平安管控和运维老本中寻求较好的均衡。 本文将介绍政采云基于 Dubbo 的跨网计划落地过程中面临的技术挑战、社区单干以及更深层次形象的一些思考。 在政采云这种政企业务场景中的数据跨网，与业界私有云、自建公有云的公司相比，既有共性又有本人的特点，心愿能为大家提供新的思路或者启发。 前言稳固、高效、牢靠的基础设施是互联网企业应答业务顶峰流量的底层基石。作为政采云的根底技术平台，根底平台部始终致力于通过业内前沿技术的落地，保障公司外部所有业务在线生产零碎所依赖的根底技术平台能稳固、平安、低成本、可继续地运行与倒退。 因为公司对 Dubbo 框架的重度应用，跨网数据传输零碎个别基于 Dubbo 个性开发，在政采云外部就有多个版本的实现。 早在几年前，政采云就上线了基于 Dubbo Filter 转发的计划，它解决了岛到云的单向数据传输，平安认证等问题。另外，业务部门也有依照本人的需要，推出网状点对点的计划，实现了肯定水平的通明传输。 联合前两年的摸索实际以及业界相干畛域技术的成熟度，2022 年下半年，咱们对各跨岛计划，进行了整合降级，也就是当初的高速公路计划，保障跨岛标准化同时，解决了之前计划实际过程中面临的很多业务痛点，包含： 单向传输：因为架构起因，如需双向须要对等重新部署一套，老本较大。白名单开明老本高：点对点的网状架构，须要两两开明白名单，因为政企网络特殊性，开明流程简单且慢。平台保护老本高：业务各自一套数据传输平台，反复建设且运维老本高。公共性能的缺失：外围性能，业务能够按需开发，然而数据审计、链路追踪、可观测性等公共个性，往往没有足够投入。跨网数据传输零碎演进1.1 历史架构 图一 自左向右、自下而上进行模块介绍： 业务 Web：业务 Web 作为数据发送方，调本地集群 Provider 时，携带跨岛信息过来（Dubbo 上下文）。岛业务 Center：本地虚构 Provider，通过 Filter 拦挡跨岛申请，通过 http 传送到云平台 Dubbo 网关，返回数据后反序列化返回岛业务 web。Dubbo 网关：接管 Http 申请，通过泛化调用云端 Provider，解决数据后返回业务 Center。云业务 Center：一般 Dubbo Provider。1.2 高速公路架构 图二 1.2.1 隧道机制隧道技术是一种通过应用互联网络的基础设施在网络之间传递数据的形式。应用隧道传递的数据 (或负载) 能够是不同协定的数据帧或包。 高速公路架构中，应用了隧道这个概念。两端（业务层）是 Dubbo 公有协定，跨网传输过程中，则应用了 http 协定，http 协定能够更好的被中间设备、网关辨认转发。这个机制的最大便当在于对业务的低侵入性。对于业务集群的利用齐全不须要批改。 图三 除了路由标记，进口 / 入口 Dubbo 协定字节流没有任何业务外信息，所以能够路由任何 Dubbo 申请。 ...

报告引自：Sysdig 2023 Cloud-Native Security and Usage Report 近日，云和容器平安畛域公司Sysdig，公布了2023年云原生平安和应用报告。往年报告聚焦于两个主题，揭示了供应链危险和零信赖架构筹备度是云和容器环境中最大的未解决平安问题。该报告还揭示了因为适度调配容量而导致的数千万美元的云收入节约。 通过理论数据，第六期年度报告揭示了寰球各行各业不同规模的公司如何应用和爱护云和容器环境。数据集涵盖了Sysdig客户在过来一年中操作的数十亿个容器、数千个云账户和数十万个应用程序。 报告要点· 87%的容器镜像存在高危或要害破绽：因为古代设计的个性以及开源镜像的共享，平安团队面临着大量容器破绽。理论状况是，团队无奈修复所有破绽，并且他们难以找到正确的参数来优先解决破绽并缩减其工作负载。 · 然而，报告还发现只有15%的可用修复程序中有重大或高危破绽，这些修复程序是在运行时加载的。通过筛选理论应用的容易受攻打的软件包，组织团队能够将重点放在可修复破绽的较小局部上，这些破绽代表真正的危险。将破绽数量缩小85%至15%为网络安全团队提供了更具可操作性的数字。 · 90%的受权权限未被应用：零信赖架构准则强调组织应防止授予过于宽泛的拜访权限。报告数据显示，90%的权限未被应用。如果攻击者夺取了领有特权拜访或适度权限的身份的凭据，则在云环境中他们将领有“地狱之钥”。 · 59%的容器没有定义CPU限度，69%的申请CPU资源未被应用：在Kubernetes环境中没有利用信息，开发人员无奈确定他们的云资源在何处适度或调配有余。所有规模的组织都可能超支40%，对于大规模部署，优化环境能够均匀节俭1000万美元的云生产账单。 · 72%的容器存活工夫不到五分钟：容器隐没后收集故障排除信息简直是不可能的，而容器的寿命在往年缩小了28%。这种缩小反映了组织在容器编排应用方面的成熟度，强调了须要与云的短暂性相适应的安全性。 “ 回顾去年的报告，容器的采纳持续成熟，这从容器生命周期的缩短中能够看出。然而，配置谬误和破绽依然困扰着云环境，而供应链正在放大平安问题的体现。用户和服务的权限治理是另一个我心愿看到人们更加严格的畛域，” Sysdig 的网络安全策略总监 Michael Isbitski 说道，“往年的报告显示了微小的增长，并概述了最佳实际，我心愿团队们在 2024 年的报告中驳回这些实际，例如查看理论危险曝光状况，以理解真正的危险，并优先解决对业务产生真正影响的破绽。” 论断咱们的钻研表明，只管人们意识到所需的工具和零信赖办法的益处，但云平安流程依然落后于云采纳的疾速步调。从咱们钻研的实在客户数据中，有几个平安实际畛域须要改良以升高危险： · 身份和拜访治理：授予权限与所需权限之间的微小差别突显了定期测量和管理权限以缩小攻打机会的紧迫性。· 破绽治理：因为大多数容器镜像在生产中运行具备危险的破绽，团队必须通过基于理论运行时危险的破绽优先级来解决镜像臃肿问题并集中其修复工作。· 检测和响应：特权降级和进攻躲避攻打是咱们客户威逼清单的首要问题。为了赶上一直变动的威逼环境，威逼检测规定应定期更新以发现歹意流动。 除了平安之外，往年的数据表明，组织通过解决未应用的Kubernetes资源能够升高云老本。投入工夫进行容量布局能够取得弱小的回报。通过施行适当的容器资源限度和继续监控，组织将可能在不影响应用程序性能的状况下优化老本。 咱们第六期年度报告的次要趋势突显了容器环境持续增长，和越来越依赖开源解决方案，咱们须要稳固运行和爱护它们的平安。针对云和容器设计的自动化和可扩大工具的市场在不断扩大，这能够帮忙团队更无效地发现威逼和危险，防止脱漏，聚焦于具备最大影响力的口头，避免浪费工夫。 平安左移：灵雀云ACP的云原生平安实际在云原生安全策略方面，Sysdig认为，云原生平安防护的外围在于规定。规定定义和保护，都须要平安人员基于本身安全策略的规定进行定义和保护，因为规定的定制化还可能存在规定被绕过的状况，只有融入到具体情况千差万别的生产环境中，平安经营团队继续地采纳多种检测伎俩穿插验证、造成闭环，能力真正无效发挥作用。灵雀云在云原生平安实际时也秉持着同样的安全策略。 为了更好地帮忙企业用户实现云原生转型的平稳过渡，实现数字化转型，灵雀云始终把产品和服务的安全性放在首位，遵循平安“左移”设计准则，通过以下几点构筑了弱小的云原生平安防线： · 欠缺的用户安全策略为确保用户登录平安，灵雀云ACP反对设置用户安全策略，包含明码平安、用户禁用、用户锁定、明码告诉、访问控制等策略。晋升平台用户的安全性，升高歹意攻打危险。· 服务化的IT平安治理反对中小型企业的多租户治理场景，实现细粒度权限管制和自助IT治理；对立治理和监控不同基础设施环境上的资源，通过平安审计机制，保障系统安全性。· 全生命周期的DevSecOps在利用的整个生命周期内确保安全性；实现平安防护自动化，以爱护整体环境和数据；同时在构建/测试/部署过程中通过配置安全策略（比方镜像破绽扫描策略、代码平安扫描策略）来保障利用整体的安全性；通过主动执行对立的平安质量标准，从而确保组织交付更平安的软件；反对集成实用于容器的安全性扫描程序。 在实际方面，以某全国性大型银行为例，该银行全栈云容器平台作为驱动金融数字基础设施建设的重要引擎，通过建设上述平安“左移”的云原生平安防护模型，践行安全可靠的DevSecOps理念，实现了企业级的全生命周期自适应平安、IT零碎智能化检测、牢靠的容器平安治理、麻利化DevSecOps流程、零信赖平安危险评估，大大晋升了其业务零碎的平安危险免疫能力。 分割咱们，具体理解灵雀云ACP如何帮忙您的企业晋升应答IT危险的免疫力，与灵雀云工程师一起布局探讨，云原生平安最佳实际。 理解更多

3月9日，“2023金融API平安论坛”胜利在线举办。本次论坛由工商银行金融科技研究院、《中国金融电脑》杂志社、神州云科联结主办，工商银行业务研发核心专家苏建明为会议致辞，来自工商银行、招商银行、众邦银行以及神州云科的多位专家在线发表了精彩演讲，并围绕多层次的API平安体系建设、将来发展趋势等问题开展了深入探讨。 致辞工商银行业务研发核心专家 苏建明 工商银行业务研发核心专家苏建明在致辞中示意，以后，数字竞争力已成为国家、企业整体竞争力的重要组成部分，而凋谢API作为一种新兴商业模式，可助力企业进一步延长业务能力、减速场景翻新。在此背景下，凋谢银行的呈现不仅扭转了产业服务与银行服务彼此孤立的场面，实现客户资源和服务场景的双向共享，同时也促使生产数据与金融数据深度交融，减速了金融服务的普惠过程，互利共赢的新生态正逐渐成型。在推动凋谢银行生态倒退的过程中，工商银行始终将平安建设作为重中之重，通过发展事先、事中、预先管控，构筑了多层次、全流程、平面平安的进攻体系。例如，针对合作方治理，工商银行基于通信协议层和应用层实现了敏感数据加密爱护，并通过网关实现了访问控制和限流机制等。着眼于整个行业，API平安建设是以后金融行业网络安全工作的一个缩影。心愿通过本次论坛，可能搭建起一个交换共享的平台，进一步晋升API平安管控能力，更好助力凋谢银行建设和银行数字化转型。 演讲招商银行信息技术部 架构治理团队架构师 沈明杰 招商银行信息技术部架构治理团队架构师沈明杰在题为“数字招行开放平台——平安可信拜访实际总结”的演讲中指出，数字招行开放平台重点解决了四个方面的外围诉求：一是针对企业接入治理，平台提供了对立的API公布、接入治理和企业治理性能；二是针对平安问题，平台提供了齐备的鉴权和密钥管理体系；三是针对API治理和运维，平台实现了线上化的API全生命周期治理，以及多租户API的数据分析和监控性能；四是针对密钥治理，平台提供了轻量级的密钥治理服务，反对用户按需配置密钥对与API服务的组合。  谈及拜访安全控制，沈明杰示意，招商银行在数据立体重点采纳了三大策略：一是API鉴权认证，该过程次要由API网关实现，只有通过鉴权认证的申请能力达到业务后端，从而使业务端可更好地聚焦于业务自身。二是敏感数据加密，通过应用国密算法和数字信封技术，无效解决了长报文加密性能问题和对称密钥传输平安问题。三是速率限度，即基于API网关进行流量限度，可反对IP限度、速率限度以及基于速率限度的IP黑白名单等多种模式。 神州云科高级解决方案参谋 林夏 神州云科高级解决方案参谋林夏在题为“API平安可信拜访，助力数字经济行稳致远”的演讲中指出，API波及的平安场景次要可分为四类：一是接入管制，包含认证鉴权、越权管制、参数管制和威逼管制等；二是零信赖拜访，包含继续认证身份、继续认证权限属性、继续监控动静策略，以及继续集成、交付等；三是网络安全，包含加密流量、DDoS攻打、CC攻打、BOT攻打等；四是利用平安，包含注入攻打、资产梳理、敏感数据预计日志输入剖析等。 谈及应答策略，林夏示意，神州云科API平安可信解决方案以API平安防护平台为外围，基于API业务场景化，全面笼罩四大平安因素及Gartner评估的API平安能力矩阵，提供了加强混合型Token认证。同时，通过申明式API，神州云科API平安网关能够疾速实现平安即代码，反对疾速融入DevOps流水线。此外，基于“神州云科API前置平安网关+神州云科API平安微网关”的独特设计，造成了交融对立的一致性策略，反对疾速部署，可无效升高运维老本。 众邦银行金融翻新部负责人 彭磊 众邦银行金融翻新部负责人彭磊在题为“凋谢API平安之道”的演讲中指出，众邦银行的API倒退次要经验了三个阶段：一是摸索阶段，初步摸索凋谢银行输入形式，次要实现场景搭建和欠缺根底服务能力，以及应用外联网关平台简略进行凋谢API加解密治理；二是倒退阶段，联合行内需要及《商业银行利用程序接口平安治理标准》的要求，搭建互联网开放平台，从技术和治理两方面欠缺金融API的治理和平安治理；三是成熟阶段，进行渠道的对立治理建设，买通自营渠道和内部渠道的隔膜，实现业务场景配置化、渠道产品个性化、凋谢API服务化等指标。 谈及云原生时代的API平安，彭磊指出，新一代平安防护模式应具备如下特色：一是将平安防护笼罩云原生利用的全生命周期，从需要剖析、软件开发、软件测试、软件公布始终延长到软件运维；二是将平安防护工具集成到软件开发流程的工具链中，以便于在继续集成之初就实现对代码的动态平安检测；三是全面扫描制品和云配置，并与运行时的可观测性和配置平安相结合，以确定危险优先级，合力安顿补救措施。 工商银行金融科技研究院 平安攻防实验室高级经理 姜城 工商银行金融科技研究院平安攻防实验室高级经理姜城在题为“凋谢银行API摸索与实际”的演讲中指出，凋谢银行API面临的危险给需要、研发、测试监控等流程带来了微小挑战：一是需要管控挑战，思考API危险的复杂性，须要多部门合作，从源头即开始管制危险；二是平安研发挑战，在开发人员将原有服务封装或批改后提供给网关调用的过程中，如果疏忽内部威逼降级，维持原有的安全等级，易引发平安危险；三是平安测试挑战，即API测试普遍存在接口格局非凡、加密数据测试难、测试周期短等诸多困难；四是安全监控挑战，凋谢银行将外部能力裸露到互联网，从而使网络防护边界变得更加含糊，传统监控办法亟待降级。 谈及工商银行实际，姜城介绍，面对愈发简单的网络安全环境，作为网络安全、数据安全、业务平安的交汇点，API面临的平安危险正逐渐浮现。对此，工商银行围绕多层次全流程平面平安进攻体系建设，重点从API合规性治理、API应用方治理、研发测试流程治理、平安风控模型建设等方面强化管控措施。例如，针对合规性，重点发展了差异化的服务公布管控与全生命周期的上线管控；针对应用方，施行了精细化的合作方准入与全链路的技术管控；针对研发流程，构建了全流程的平安测试体系；针对平安风控，基于风控模型一直强化剖析决策能力，打造了全维度的安全监控体系。 论坛最初，工商银行金融科技研究院云计算实验室高级经理王炳辉作为主持人参加了探讨环节。谈及不同技术体系的有机联合，与会嘉宾示意，API平安是一个跨畛域的简单问题，需引入多重防御机制做好平安管控，包含在制度层面笼罩全生命周期治理、部署细粒度的拜访策略、搭建对立平安治理平台，以及兼顾业务和技术畛域的不同需要等，着力构建多层级、多维度的纵深平安防护体系。谈及将来发展趋势，各位嘉宾示意，零信赖及数字信封等技术或将成为后续支流的技术钻研方向；同时也包含利用人工智能、大数据等技术构建危险模型，对API异样行为进行剖析检测；以及联合用户权限和拜访门路调优，打造更为灵便的平安验证体系等。与会嘉宾统一认为，通过业界多方携手，合力打造更为平安、稳固的API生态，将更好推动金融业实现数字化转型与高质量倒退。

云原生的一直成熟让大量基础设施层的能力能够被业务利用间接应用，然而宽广的开发者们却苦于很高的上手门槛和学习老本，始终没有机会深刻理解云原生生态的工具体系。明天咱们将为你介绍一个好用的工具，它可能在离线环境帮你疾速装置 Kubernetes 集群，低门槛的上手业务利用部署，还能具备多集群、云资源等一系列高阶能力，而你只须要筹备一个可能运行 Docker 的零碎环境。 这个工具就是 VelaD[1]，它能够帮忙开发者从零开始，在三分钟内疾速搭建基于 K3s 和 KubeVela 的云原生利用管制立体。 筹备工作如果你应用的是 Mac 或者 Windows，须要筹备 Docker 环境，举荐应用 Docker Desktop[2]。如果你应用的是 Linux，则无需筹备工作。 装置 VelaDMac/Linux curl -fsSl https://static.kubevela.net/script/install-velad.sh | bashWindows 应用 Powershell 运行 powershell -Command "iwr -useb https://static.kubevela.net/script/install-velad.ps1 | iex"装置中须要你输出以后用户的明码来装置到 PATH 中，用以下命令确认你曾经装置胜利： velad versionCore Version: v1.7.5VelaD Version: v1.7.5一键装置 Kubernetes 和 KubeVela 管制立体最简略的状况下，应用 VelaD 创立多集群管制立体，只须要一条命令： velad install整个装置过程是离线实现的，只须要 1 分钟左右便可装置实现，除了 Kubernetes 以外，还会装置 KubeVela 这个现代化的云原生利用交付和治理平台，帮你轻松上手云原生利用的部署。不仅如此，你还能够通过增加更多节点和数据库来保障集群数据的更高可用性（见“增加集群”大节）。另外，以上命令所创立的管制立体并不会主动将集群裸露给公网。如果你须要通过公网拜访你在近程服务器上创立的管制立体，参见近程拜访文档[3]。 该命令的背地是基于 K3s/K3d 技术为你在机器上创立一个单节点的 Kubernetes 集群，并在其中装置 KubeVela，及其命令行工具 vela。基于这个环境，你能够立即开始交付你的业务利用。 开箱即用的利用交付性能开启 VelaUX随着 velad install 的执行，广受欢迎的控制台插件 VelaUX 也一并在你的机器上就绪了。留神 velad install 执行完结后的提醒： ...

KubeVela 1.7 版本曾经正式公布一段时间，在此期间 KubeVela 正式升级成为了 CNCF 的孵化我的项目，开启了一个新的里程碑。而 KubeVela 1.7 自身也是一个转折点，因为 KubeVela 从一开始就专一于可扩大体系的设计，对于控制器外围性能的需要也开始逐渐收敛，咱们开始腾出手来更加专一于用户体验、易用性、以及性能。在本文中，咱们将重点筛选 1.7 版本中的工作负载接管、性能优化等亮点性能进行介绍。 接管你的工作负载接管已有的工作负载始终是社区里呼声很高的需要，其场景也十分明确，即曾经存在的工作负载能够天然的迁徙到 OAM 标准化体系中，被 KubeVela 的利用交付管制面对立治理，复用 VelaUX 的 UI 控制台性能，包含社区的一系列运维特色、工作流步骤以及丰盛的插件生态。在 1.7 版本中，咱们正式公布了该性能，在理解具体怎么操作之前，让咱们先对其运行模式有个根本理解。 “只读” 和 “接管” 两种模式为了适应不同的应用场景，KubeVela 提供了两种模式来满足你对立治理的需要，一种是只读模式，实用于外部曾经有自建平台的零碎，这些零碎对于存量业务仍旧具备次要的控制能力，而新的基于 KubeVela 的平台零碎能够只读式的对立观测到这些利用。另一种是接管模式，实用于想间接做迁徙的用户，能够把已有的工作负载主动的接管到 KubeVela 体系中，并且齐全对立治理。 “只读”（read-only）模式顾名思义，它不会对资源有任何“写”操作。应用只读模式纳管的工作负载，能够通过 KubeVela 的工具集（如 CLI、VelaUX）做可视化，满足对立查看、可观测方面的需要。与此同时，只读模式下生成的纳管利用被删除时，底下的工作负载资源也不会被回收。而底层工作负载被其余控制器会人为批改时，KubeVela 也能够察看到这些变动。“接管”（take-over）模式意味着底层的工作负载会被 KubeVela 齐全治理，跟其余间接通过 KubeVela 体系创立进去的工作负载一样，工作负载的更新、删除等生命周期将齐全由 KubeVela 利用体系管制。默认状况下，其余系统对工作负载的批改也就不再失效，会被 KubeVela 面向终态的管制循环改回来，除非你退出了其余的管理策略（如 apply-once）。而申明接管模式的办法则应用 KubeVela 的策略（policy）体系，如下所示： apiVersion: core.oam.dev/v1beta1kind: Applicationmetadata: name: read-onlyspec: components: - name: nginx type: webservice properties: image: nginx policies: - type: read-only name: read-only properties: rules: - selector: resourceTypes: ["Deployment"]在 “read-only” 策略中，咱们定义了多种只读规定，如样例中只读选择器命中的资源是 “Deployment”，那就意味着只有对 Deployment 的资源是只读的，咱们仍旧能够通过运维特色创立和批改 “Ingress”、“Service” 等资源，而应用 “scaler” 运维特色对 Deployment 的实例数做批改则不会失效。 ...

近日，PostgreSQL 中国技术大会在杭州拉开帷幕。作为 PostgreSQL 技术畛域的年度盛会， PostgreSQL 中国技术大会曾经间断 12 年，为所有酷爱数据库技术的小伙伴们提供了一个凋谢单干、共享互助的平台。而本届大会，围绕着安全可靠、冲破、进化等主题，招集泛滥业内大咖和技术高手在这里进行技术切磋与思维碰撞。   作为国内云上数据和数据计算畛域的 Day-1 准独角兽，拓数派技术专家郭峰受邀缺席本次大会发表主题演讲。  在演讲中，郭峰介绍了 PieCloudDB Database 打造的全新优化器 ——「达奇」。「达奇」名称起源于一款深受年轻人青睐的游戏：《荒野大镖客》。游戏中一位名为「达奇」的 NPC 人物的口头禅正是「I have a plan」，和优化器的次要作用 “不约而同”。 优化器是数据库系统中的一个重要组件，它 “负责” 对用户的查问申请进行解析、优化和执行打算的生成，使得查问后果可能以最快速度和最高效率失去返回。优化器通过生成最优的查问执行打算，来达到优化查问性能的目标。而执行打算的好坏往往会造成成千盈百的性能差别。PieCloudDB 打造的优化器「达奇」实现了大量的优化个性，作为数据库系统的 “智囊团”，助 PieCloudDB 晋升性能。  四大阶段的优化个性和 PostgreSQL 相似，PieCloudDB 查问优化的处理过程个别被分为四个阶段：预处理阶段，扫描 / 连贯优化阶段，扫描 / 连贯之外的优化阶段，后处理阶段。「达奇」在这四个解决阶段均做了大量优化。  在预处理阶段，优化器「达奇」会通过逻辑上的等价变动，将查问树转换为更加简略高效的等式。因为还未取得一些统计信息来帮忙计算代价信息，本阶段个别会通过一些被证实的规定来进行散发约束条件，简化表达式和连贯树打消无用连贯等操作。  把 IN, EXISTS 等类型的子查问转换为半连贯 PieCloudDB 会基于子查问所在的地位和作用的不同，将子查问分为子连贯（SubLink）和子查问（SubQuery）。子连贯因为呈现在 WHERE/ON 等约束条件中，常随同着 ANY/ALL/EXISTS 等谓语动词。如果执行器依照子连贯的形式解决，会对查问效率造成影响。且因为会产生子打算（SubPlan），优化空间无限。因而，在查问优化的预处理阶段， PieCloudDB 会尽可能地把子连贯转为 semi-join 或 anti-join，从而具备更大的优化空间。  以上面一段的 SQL 查问为 例： SELECT … FROM foo WHERE EXISTS (SELECT 1FROM bar WHERE foo.a = bar.c);其中 EXISTS 里是一个子查问，PieCloudDB 会在预处理阶段将其变成一个 Semi-Join： ...

更多技术交换、求职机会，欢送关注字节跳动数据平台微信公众号，回复【1】进入官网交换群随着数据的利用场景越来越丰盛，企业对数据价值反馈到业务中的时效性要求也越来越高，很早就有人提出过一个概念：数据的价值在于数据的在线化。 实时计算起源于对数据加工时效性的严苛需要：数据的业务价值随着工夫的流逝会迅速升高，因而在数据产生后必须尽快对其进行计算和解决，从而最大效率实现数据价值转化，对实时数仓的建设需要自然而然的诞生了。而建设好实时数仓须要解决如下几个问题： 一、稳定性：实时数仓对数据的实时处理必须是牢靠的、稳固的；二、高效数据集成：流式数据的集成必须不便高效，要求能进行高并发、大数据量的写入；三、极致性能要求：实时数仓不能仅限于简略查问，须要反对简单计算能力，且计算结果可秒级返回；四、灵便查问：须要具备自助剖析的能力，为业务剖析提供灵便的、自助式的汇总和明细查问服务；五、弹性扩缩：须要具备良好的扩展性， 必须架构对立具备扩展性，可为 IT 建设提供灵活性。 针对以上问题，火山引擎一直在业务中摸索，总结了基于 ByteHouse 建设实时数仓的教训。 抉择 ByteHouse 构建实时数仓的起因ByteHouse 是火山引擎在 ClickHouse 的根底上自研并大规模实际的一款高性能、高可用企业级剖析性数据库，反对用户交互式剖析 PB 级别数据。其自研的表引擎，灵便反对各类数据分析和保障实时数据高效落盘，实现了热数据按生命周主动冷存，缓解存储空间压力；同时引擎内置了图形化运维界面，可轻松对集群服务状态进行运维；整体架构采纳多主对等架构设计，架构安全可靠稳固，可确保单点无故障瓶颈。 ByteHouse 的架构简洁，采纳了全面向量化引擎，并装备全新设计的优化器，查问速度有数量级晋升（尤其是多表关联查问）。 用户应用 ByteHouse 能够灵便构建包含大宽表、星型模型、雪花模型在内的各类模型。ByteHouse 能够满足企业级用户的多种剖析需要，包含 OLAP 多维分析、定制报表、实时数据分析和 Ad-hoc 数据分析等各种利用场景。 ByteHouse 劣势一：实时数据高吞吐的接入能力面对业务大数据量的产生，须要高效牢靠实时数据的接入能力，为此咱们自研了 Kafka 数据源接入表引擎 HaKafka ，该表引擎可高效的将 Kafka 的数据接入 ByteHouse ，具备有如下个性： 1.数据接入高吞吐性，反对了多线生产 Kafka topic 对应 Partition 的数据，满足大数据量实时数据接入的需要。 2.数据接入高可靠性，通过 Zookeeper 来实现主备生产节点治理，比方，当线上呈现某个节点呈现故障或无奈提供服务时，能够通过 Zookeeper 心跳感知机制主动切换到另一个节点提供服务，以此来保障业务的稳定性。 3.数据接入原子性，引擎自行治理 Kafka offset ，将 offset 和 parts 进行绑定在一起，来实现单批次生产写入的原子性，当中途生产写入失败，会主动将绑定的 parts 撤销，从而实现数据生产的稳定性。 具体流程原理如下图所示 ByteHouse 劣势二：基于主键高频数据更新能力随着实时数据分析场景的倒退，对实时数据更新的剖析需要也越来越多，比方在如下的业务场景就须要实时更新数据能力： 第一类是业务须要对它的交易类数据进行实时剖析，须要把数据流同步到 ByteHouse 这类 OLAP 数据库中。大家晓得，业务数据诸如订单数据天生是存在更新的，所以须要 OLAP 数据库去反对实时更新。第二个场景和第一类比拟相似，业务心愿把 TP 数据库的表实时同步到 ByteHouse，而后借助 ByteHouse 弱小的剖析能力进行实时剖析，这就须要反对实时的更新和删除。最初一类场景的数据尽管不存在更新，但须要去重。大家晓得在开发实时数据的时候，很难保障数据流里没有反复数据，因而通常须要存储系统反对数据的幂等写入。基于以上业务场景的需要，咱们自研了基于主键更新数据的表引擎 HaUniqueMergeTree，该表引擎即满足高效查问性能要求，又反对基于主键更新数据的表引擎，有如下个性： ...

近日，灵雀云全栈云原生开放平台ACP（以下简称灵雀云ACP）胜利通过了金融信创生态实验室适配验证，在金融科技领域的技术实力和业余程度失去了权威认可。 金融信创生态实验室（以下简称“实验室”）是由中国人民银行领导，中国金融电子化团体有限公司牵头组建，专一金融信创的重要基础设施和专业化试验平台。实验室基于国产芯片、操作系统、数据库、中间件等根底软硬件构建的技术底座和技术路线，组织发展各类金融利用与之适配、验证、调优和攻关，旨在汇聚产业各方力量，解决金融共性问题，推动金融信息技术生态的继续倒退。 实验室对灵雀云ACP 进行了全面测试验证，测试后果100% 合乎通过，全面展现了灵雀云ACP的功能性和兼容性充沛满足金融信创的各项规范，为金融企业和机构在云原生零碎选型方面提供参考，同时助力保障金融行业云原生利用的安全性和稳定性。 云原生技术赋能金融行业数字化转型在数字经济背景下，金融科技曾经成为金融行业倒退的外围驱动力。在金融机构数字化转型的过程中，云原生等新兴技术成为了重要的赋能工具。金融机构迎来全新的服务场景和商业模式，同时也面临着更加多样化、个性化、碎片化的用户需要，新型利用层出不穷。如何利用云原生技术，助力企业麻利、牢靠、高效地开发、测试、交付利用，将成为金融机构长期关注的课题。 作为金融行业首选云原生服务提供商之一，灵雀云依靠寰球当先、超大规模云原生平台的开发、运维和治理教训，帮忙中信银行、光大银行、长沙银行、郑州银行、中原银行、国泰君安证券、国泰君安期货、上海证券、合众人寿等近百家金融机构重构平台、重塑业务，减速构建、运行及治理现代化利用，实现数字化转型。 将来，灵雀云将继续深耕金融科技领域，以全栈云原生技术劣势及成熟的平台化能力，为更多用户打造面向未来的企业数字化基座。

2023 年 1 月 6 日，稀土掘金技术社区首次举办「掘金将来大会」，并在大会上重磅公布了《 稀土掘金 2022 中国开发者生态报告 》，报告联合 10 位领域专家 进行定性采访，以行业视角窥见当下开发者群体和企业所面临的技术难题 。 采访中，统信软件服务器操作系统与云计算产线总经理孟杰 示意，云原生零碎的倒退，将会进一步推动开源我的项目的倒退，所以在开源畛域，云原生会越来越遍及。同时，孟杰提到，云原生在疾速倒退和利用过程中，也面临本身的安全性问题，平安自身会有一个较大的潜在市场。 在孟杰看来，无论企业还是集体，对云原生技术的理解水平参差不齐，企业想摸索时会存在肯定的担心。另外，企业在人才的数量和品质上仍存在缺口，对新技术的学习须要一个过程。为此，云原生不能把本人的信息化建设成关闭的孤岛，须要一直地和当初的社区或者上游新技术放弃肯定的接轨 。 以下为稀土掘金与统信软件服务器操作系统与云计算产线总经理孟杰的对话全文： 云原生技术处在比拟炽热且疾速的倒退阶段稀土掘金：目前，最炽热的云原生技术利用现状是怎么样的？ 孟杰： 云原生和操作系统的倒退是一个相辅相成的关系。云原生是一个比拟晚期的概念，2013 年云原生是一个思维的汇合。在过来 3 年里，随着 Linux 开源的疾速倒退，以及互联网企业的疾速倒退，云原生在企业中失去比拟好的落地。云原生是企业实现数字化转型的一个底层技术趋势，云原生技术由容器、微服务或者 DevOps 为代表的麻利基础架构组成，次要用来帮忙企业疾速、继续、牢靠以及规模化地交付业务软件。 在数字化转型浪潮下，企业上云曾经成为企业和政府的广泛共识，在传统八大行业中正在疾速地倒退和推动。同时，云原生畛域开发者也迎来了一个比拟好的时代，凭借降本增效、易于开发、可进步继续交付等劣势帮忙千行百业从踊跃拥抱云计算向着更为精确的云原生利用方向倒退。而云原生也因而被视为将来社区数字化转型的无效武器。在国内，比拟典型的服务器操作社区有 2 个，一个是欧拉社区，一个是龙蜥社区，统信软件也在其中参加相干的工作，因而，整个云原生技术还是处在一个比拟炽热且疾速的倒退阶段。 稀土掘金：目前还是利用比拟多的状态？ 孟杰： 是的，在传统八大行业里，特地是一些大的企业把原有的业务零碎逐渐往云化上迁徙，过程中无意接触云原生技术利用到本身业务畛域中。 稀土掘金：提到云原生技术，目前哪些技术是利用比拟宽泛且行业认可度较高？或者仍在初摸索阶段？ 孟杰： 它是一个疾速倒退和迭代的过程，比拟底层的像云原生操作系统曾经逐渐在国内的社区中展示一些成绩，在一些非凡或要害畛域也有利用和推广，再往上的像相应的容器技术用得比拟多。此外，在给客户推出的一些深度解决方案中也蕴含间接把客户的业务零碎、容器化迁徙到云原生体系里，心愿可能带来可继续地倒退和迭代。 稀土掘金：是否举例谈谈哪些畛域利用得更宽泛？ 孟杰： 金融和交通畛域用得比拟多，这和国内的倒退现状无关，除了传统的互联网以外，在推动的过程中或多或少会受信创产业的影响，在金融体系下信创自身的倒退会比拟靠前，其次，交通畛域也略微靠前。此外，在做信创的同时也会摸索一些新的技术点，让企业享受到开源的红利。随着整体国产化，以及信创的倒退，将来传统八大畛域中都会逐渐失去利用，只是依据每个行业倒退的阶段不同可能会有一个先后顺序。 云原生平安，会有一个较大的潜在市场稀土掘金：您认为云原生将来有哪些值得关注的发展趋势？ 孟杰： 依照目前市场的需要与云原生技术的倒退，以及企业业务上云的迫切水平，在边缘计算场景中，云的状态将进一步从混合云向分布式云倒退，云原生技术将进一步向下延长实现 laaS 与 PaaS 的交融。在整个信创大生态环境下，开源生态会减速凋敝，软硬交融的云原生一体机也会大放异彩，无服务器计算失去疾速倒退，低代码工具也会失去更宽泛的利用。 云原生在疾速倒退和利用的过程中，面临本身的安全性问题，平安自身会有一个较大的潜在市场。2022 年，除了根底的镜像平安，容器引擎平安，编排，调度引擎平安外，联合着 Service Mesh 或者 eBPF 等新技术也将为云原生的运行时的安全性带来更多的观测和保障能力，这也是将来的发展趋势。 稀土掘金：您提到 “云原生正在吞噬开源”，怎么了解？ 孟杰： 云原生和开源有一个根本关系，晚期大家说软件正在吞噬世界，或者开源正在吞噬世界，特地是云原生畛域，其产出于 CNCF、云原生计算基金会，依靠 Linux 社区来倒退的一个新的技术，而 Linux 社区通过二三十年的倒退，其对应的软件组件性能和数量都超出了大家的设想。随着云原生零碎的倒退，将会进一步推动开源我的项目的倒退，所以在开源畛域，云原生会失去越来越多的广泛应用和遍及。 反对和拥抱开源，是企业将来倒退方向稀土掘金：您如何对待目前的开源？ 孟杰： 从几个维度来看，一是态度踊跃；二是反对和拥抱开源；三是回归开源。晚期，从业者通过吸取开源的个性或成绩逐渐成长起来。对于企业而言，基于开源社区的一些 Demo 或者我的项目成绩，依据搬运成品的定位和诉求做二次开发，而后产生商业软件发明商业价值。同时，在取得社区的成绩和红利之后，可能有一部分的精力回馈于开源，在社区做奉献，让整个社区出现一种衰弱倒退的状态。凋谢和自在是开源社区的魅力之一，企业或集体享受开源红利后，能够在开源畛域里提一些 issue 、PR，做代码提交，甚至是提一些好的意见都是能够的。 稀土掘金：目前来说，中国开源的利用现状如何？处在一个什么样的阶段？ 孟杰： 随着开源在国内生根落地，开源平台近五年来一直在壮大。开源的倒退离不开政策反对，在激励万众翻新背景下出现蓬勃发展的态势。任何新兴事物的产生都须要工夫来缓缓适应，能力找到与现有事物的平衡点。尽管当初国内的开源局势整体较好，但倒退开源并不是一帆风顺的，比方，开源须要精力保护，开源我的项目取得关注度的形式无限，开源我的项目的回报率在不同的企业中不一样。此外，区别于商业我的项目，开源我的项目属于迭代式倒退，自在分散式的开发模式，有更多复杂度和不确定性。 从趋势上看开源社区的倒退，各个企业，尤其是大的企业纷纷拥抱开源，利用开源进行商业布局，因而有充沛的理由认为开源是能够进行商业化的。国内晚期，大家基于开源的一些成绩进行二次开发而后商业发行，近几年，华为成立欧拉社区，阿里云联结统信软件成立龙蜥社区，吸引了芯片厂商、硬件整机厂商踊跃地退出开源中，再加上每个企业在生态圈的地位不一样，大家可能有侧重点地分工协作，保护一个比拟好的生态，把整个体系建设得更好。整体而言，国内的开源倒退曾经走上一个比拟好的倒退门路，置信将来会有越来越多的企业退出到开源建设中，共建开源社区生态。 与商业我的项目不同，开源商业化的问题要用开源的形式解决稀土掘金：开源我的项目怎么实现商业化？ 孟杰： 开源和商业化其实是两个纬度的事，开源更关注技术的倒退和翻新，而商业化侧重于交付。在各个社区中一直探讨一个问题——社区与企业如何可能协同倒退？社区是开源的一个组织，如果社区和企业做的工作是重叠的，天然就会呈现一些不衰弱的问题。而社区中各个厂商更强调从技术的纬度做翻新，以及如何疾速的倒退和迭代。同时，商业厂商要思考商业化的产品、竞争性和稳定性，还要思考到产品交付之后对客户的服务，这些都不一样。 稀土掘金：您认为开源会给软件行业、开发者行业以及企业和开发者自身带来什么样的影响？ 孟杰： 对于开发者而言，开源提供一个更好的平台，不便开发者去做翻新，去做奉献，比方，国内成立的凋谢原子开源基金会，从更高层做社区治理，给国内提供一个更好的平台；对于企业而言，防止各自为战，反复造轮子。通过社区和开源共享、分工协作、一直地盖一个高楼。此外，每个企业在开源中一直做奉献的同时，能够看到技术的倒退方向以及将来的技术趋势。每个企业依据社区层面联合本身市场方向，以及将来潜在客户的画像，从新定义本身的商业软件或者商业发行版，达到一个更好的协同。对于一个企业来讲，本人做所有的货色老本较高，很多重复性工作没必要做，相当于一些根底、技术创新的货色能够放到社区中，企业在社区根底上关注本身潜在客户的关注点，业余地做一个商业版本，达到共创、共建、共享。 针对开源还有肯定的艰难，首先，对于企业和集体而言，开源须要付出很多精力保护，不能依附集体的力量去治理和保护，反之导致一些我的项目倒退不顺利。其次，开源我的项目的获取，关注度的形式是无限的。一个我的项目从孵化到应用过程中，开源者大多是须要经验孤军奋战或无人问津的场面，再加上工作和生存上的压力，很难均衡开源和工作两件事，导致海量的我的项目胎死腹中。再者，开源我的项目的回报率较低，我的项目的优良与否更多体现在技术上的认可度，物质方面比拟欠缺，导致一些我的项目因资金的问题而中断。从工程的维度上看，开源我的项目不是一个商业化的团队，大家都靠趣味和喜好一起参加到我的项目的工作中，这些人的程度和事件判断上还参差不齐，如果开源爱好者对我的项目前瞻性不够，或者信念有余，也会导致我的项目中断。最初，开源过程中还有一些不可预知性，一些开源问题须要引起更宽泛的关注，但总体来讲开源的问题要用开源的形式来解决。 稀土掘金：是否具体聊一聊为什么会呈现因信念有余导致开源我的项目没有继续上来的状况？ 孟杰： 开源我的项目和商业我的项目不一样。商业我的项目是由一个商业的公司或者组织主导，开始前有明确的市场洞察、客户或者市场需求的剖析，而后组织一些专门项目组，能保障资源的投入和成绩产出，针对预期市场和用户冀望都会有比拟明确的指标。而开源我的项目是自发式、集市式的开发模式，通常是自底向上的，可能短少对整个架构的扫视和对将来的前瞻性有余。 国内的欧拉社区和龙蜥社区是比拟典型的好例子。对于一个服务器操作系统社区建设来讲，它的投入规模较大，依赖于现有国内的操作系统厂商很难独立打造，在这种状况下，作为比拟大的头部企业，华为、阿里云牵头组织好国内做CPU、整机、操作系统等软件开发商组建社区，每个企业在外面分工协作，绝对来讲投入的资源比拟无限，企业能够负担得起的，大家一起在社区中做一些共性的问题，解决技术创新的问题，以及产业合作的问题，很大水平上可能防止资金等事实问题，而且这些企业最终都会享受到社区的成绩，因而，由多个厂商一起累赘社区共建是一个比拟好的解决形式。 稀土掘金：您比拟关注哪些技术畛域的一个开源动向？ ...

更多技术交换、求职机会，欢送关注字节跳动数据平台微信公众号，回复【1】进入官网交换群面对庞杂的海量数据，稳固高速的实时数据处理能力，成为了当下企业数智降级过程中备受关注的点。 ByteHouse 是火山引擎旗下基于开源 ClickHouse 的企业级剖析型数据库，在字节跳动外部积淀迭代多年后，凭借新一代的云原生架构，高效不便的运维模式，以及高性能更灵便的实时查问能力，于 2021 年正式通过火山引擎对外服务。 为了助力企业抓稳数字化倒退时机，减速企业数智能力降级，自2023年2月1日开始，火山引擎ByteHouse特地推出为期一年的企业级特惠流动。 企业通过本次流动购买ByteHouse服务，包年1年可享8.3折，包年2年可享7 折，包年3年可享5折。除根底优惠之外，企业包年购买后，还可取得大量额定资源收费赠送，买二送一， 买三送二，买五送三（赠送资源与包年应用期限统一），且以上两项优惠可叠加享受！ 面对企业级数据处理需要，相比起原生的 ClickHouse，火山引擎 ByteHouse 基于独家自研的高可用引擎及查问优化器，能够为企业提供疾速、稳固、平安的查问服务和数据写入性能。 在云原生架构下，火山引擎 ByteHouse 提供了极致扩大的对立数据分析平台，具备杰出的弹性伸缩和可扩展性，确保资源能够灵便地程度扩大；同时，ByteHouse 反对多级资源隔离，为用户资源提供更安心的平安保障。 除了高可用的根底能力，火山引擎 ByteHouse 还从业务角度登程设计了免运维的托管服务，帮忙企业轻松理解业务状态，更加不便地进行故障排查与问题诊断，升高企业运维老本，从而专一于本身业务逻辑的实现。 截至目前，中国地震台网核心、海王团体等都已与火山引擎 ByteHouse 达成单干，率先通过海量数据实时剖析的极速体验，辅助决策落地，减速业务洞察，实现本身数字化降级的进一步减速。 点击跳转 ByteHouse云原生数据仓库 理解更多

摘要：本文整顿自阿里云资深技术专家吴威(无谓)在 阿里云EMR2.0线上发布会 的分享。本篇内容次要分为三个局部：1.兼容开源阶段2.奉献开源阶段3.超过开源阶段兼容开源阶段开源这个词在最近这几年异样的火爆，各行各业的各个厂商纷纷发表拥抱开源并且反对开源生态。尤其在大数据这个畛域，开源技术曾经成为了推动整个大数据技术演进和行业倒退的最重要的一股力量，同时开源技术栈也成为大数据行业的一个技术标准。阿里云EMR 作为开源大数据平台，集成了泛滥支流开源引擎比方 Spark、Flink、 StarRocks 等，这些引擎独特基于 EMR 计算资源底座以及数据湖存储底座，在适配阿里云生态技术栈的同时，兼容开源是 EMR 团队的一项重要工作。 事实上，阿里巴巴团体在十三年前就开始投资开源大数据畛域，通过十几年的倒退和提高，当初咱们的开源大数据平台曾经成为阿里巴巴大数据技术体系中的中坚力量。 接下去我简略分享一下阿里开源大数据技术的演进路线。 2008和2009年，阿里巴巴最主力的业务线是淘宝和天猫，其上的电商业务爆发式增长，同时业务数据也呈现了大暴发，咱们须要大数据技术去解决海量的业务数据，过后一度呈现技术跟不上业务倒退的节奏。咱们在2009年抉择了 Apache Hadoop 技术去撑持大数据分析业务，上线的第一个集群就达到200台规模，并且在一年内快速增长到1000台，在2014年具备跨数据中心的集群治理能力，单个开源 Hadoop 集群达到过万台的规模。开源大数据技术对阿里巴巴外围业务的倒退起到了十分要害的撑持作用。这个阶段阿里巴巴是开源的受益者。 奉献开源阶段2014年之后，因为咱们在外部业务上积攒了大量开源应用教训，做了不少最佳实际积淀，咱们的开源团队也转到了云上，并于2016年在阿里云推出了 EMR 产品，发现云上有更加旺盛的开源大数据的需要。 与此同时，2015年在阿里巴巴搜寻举荐广告业务线上，数据实时化的需要十分强烈，咱们心愿搜索引擎可能搜寻到实时更新的宝贝并依据用户的实时行为进行举荐，过后咱们抉择了 Apache Flink 作为新一代的实时计算引擎，在2016年将其上线并失去了十分好的成果。在2018年的时候，Flink 和 EMR 一样开始上云。2019年咱们不仅收买了 Flink 在欧洲的开创公司，还把阿里巴巴积攒多年的 Flink 分支 Blink 齐全奉献给了 Apache 社区。同时咱们也一直地对 Flink 进行了技术创新，推出了 Flink CDC、Flink Table Store 等新的开源技术我的项目。 回过头再看 EMR，自2016年在私有云上线之后，曾经服务了数千家中小企业，反对他们在云上更好地应用开源大数据。目前 EMR 也通过了技术升级， 从经典的 Hadoop 架构降级到了数据湖存算拆散的架构。与此同时咱们也放弃了整个开源大数据平台的开放性，跟国内外出名的开源大数据厂商比方 Elasticsearch、Cloudera、Databricks 等建设了亲密的合作伙伴关系，并且联合推出了开源大数据的产品，在云上共建开源大数据生态。 以 Apache Celeborn 我的项目为例，能够看到阿里巴巴从2009年开始应用开源大数据技术，经验了十数年回馈和共建，最终心愿进入到一个引领开源，推动开源倒退的阶段。 2022年10月份阿里巴巴向 Apache 孵化器捐献了 Celeborn 我的项目（也就是原来的 EMR Remote Shuffle Service 我的项目 ），这是在阿里云上诞生的第一个 Apache 孵化我的项目。随着大数据上云趋势越来越显著，云原生架构和理念也在一直强化和推广，比方存算拆散架构等都是云上特有的架构属性。在此技术背景之下，咱们发现在 Spark、Hive 、Flink 等都有数据 Shuffle 的需要，并且因为云原生架构上没有 Hadoop YARN NodeManager 等服务，无奈很好的反对 Shuffle 场景，也无奈实现动静资源伸缩等外围性能。因而，阿里云EMR 率先提供了 Remote Shuffle Service，用一套数据 Shuffle 服务反对所有大数据计算引擎。Remote Shuffle Service 我的项目诞生后，又吸引了以小米为代表的多家阿里云上公司的趣味。在2021年12月，咱们和这些阿里云客户一起将这个我的项目开源，之后吸引了更多如 Shopee、网易等企业的开发者退出，这就是云带来的变动，云与开源联合后产生了化学反应。为了让更多公司参加共建，让我的项目产生更大的影响力，咱们决定将这个我的项目募捐给 Apache 基金会，并且正式命名为 Celeborn，从孵化器我的项目起步，也心愿 Celeborn 可能成为 Apache 的顶级我的项目。 ...

作者：CNStack 容器平台、龙源电力：张悦超 、党旗龙源电力容器云我的项目背景龙源电力集团是世界第一大风电运营商， 随着国家西部大开发策略推动，龙源电力曾经把风力发电场铺设到全国各地，甚至是交通极不便当的偏远地区，这使龙源电力成为寰球装机容量、风电占比最大的运营商，但与此同时企业也面临诸多基础设施建设和保护的挑战。分设在全国 30 多个省的 240 多座风电场站有近千台服务器，因为大多地理位置偏远，所以核心到边、端保护不便；另外，风电场站计算资源无限，网络 IP、带宽等资源稀缺给 IT 架构布局、治理带来较高老本。同时，运行在省核心、风电场站的不同业务利用对计算、存储、网络资源需要差异性大，也须要兼顾存量资源的对立治理，场站利用零碎的保护更新须要大量重复性工作，治理老本高、难度大等问题逐步成为企业倒退的瓶颈。 CNStack 利用与龙源电力的最佳实际CNStack（云原生技术中台）是阿里云云原生最佳实际的输入载体，它能够在多云、混合云场景下集中纳管基础设施资源，对立编排和调度工作负载，帮忙客户高效构建高性能、高可用、高牢靠和平安合规的现代化利用，晋升企业数字化转型的整体效力。CNStack 致力于帮忙企业 IT 架构重组升维，提供用最低的老本构筑业务倒退护城河，产生更大的市场利润技术原动力。CNStack 在过来两年继续打造企业级分布式基础设施 OS，帮忙利用开发者屏蔽底层计算、网络简单拓扑，和异构差异性，并通过适应性优化 IaaS+ 服务，向以业务为核心的企业提供更多指标为导向的组合效用输入。 2.1 分布式云计算和服务2.1.1  基于 OpenYurt 的云边协同  龙源我的项目是典型的边缘场景，尽管云核心到省核心架设专线实现了全网算力节点的网络互通，然而因为广袤的地理分布，导致网络带宽资源稀缺，网络传输品质无奈保障。省核心、风电场站不仅是天文上的概念，也是业务多租户隔离的独立单元，在这些单元外部，因为天文上绝对凑近，其网络品质及带宽限度绝对宽松。基于 OpenYurt的 CNStack 云边协同服务（CNStack EdgePaaS）很好地解决弱网环境下云边协同和边缘自治问题。OpenYurt 是阿里云开源的业界首个以无侵入形式将 Kubernetes 扩大到边缘计算畛域的我的项目，于2020年9月成为 CNCF 沙箱我的项目。OpenYurt 针对边缘场景中网络不稳固、云边运维艰难等问题，对原生 Kubernetes 无侵入加强，重点提供了边缘节点自治、云边运维通道、边缘单元化的能力。        OpenYurt 提出的“节点池”概念，对应龙源我的项目的组织拓扑，实现了下图的部署构造： “节点池”带来的可不仅仅是资源分组治理这么简略，OpenYurt 还提供了更多专门针对边缘场景的个性： 利用单元化区别于传统的利用多单元治理，边缘场景下的业务单元数量会显著减少。如果采纳传统的散发模式，边缘UnitedDeployment 部署模型将用户的工作负载部署在不同的节点池中，业务的实例数、版本、镜像、配置等信息都能够依照节点池的维度进行对立治理、对立散发，而不是每个单元独立治理。 服务拓扑在边缘场景下，业务负载会依照站点的维度创立多实例。不同站点之间的利用，只能通过本站点的利用拜访，而不能由相邻站点拜访。为此，OpenYurt 提供了服务拓扑的能力，确保边缘节点利用只能由雷同节点池的节点拜访，或者只能由本节点拜访。 边缘自治传统的 Kubernetes 对网络有着很高的要求，一但产生了网络中断，Kubernetes 会基于可用性的起因，将工作负载调度到别的能够联通的节点上。这个个性在中心化的集群是很棒的个性，然而这个个性在边缘场景下反倒会带来很大的负面影响。因为这种中断通常只会产生在边缘与核心之间，这种中断一但产生，用户冀望的后果是边缘侧的工作负载持续工作，待网络复原后，核心侧复原比照边缘业务负载的治理即可。通过 OpenYurt，核心侧会在边缘节点不可用的状况下，阻止工作负载的驱赶，同时确保和核心断联的节点上的工作负载持续运行。 2.1.2 云边网络优化部署在边缘节点上的 CRD Controller，或者 DaemonSet 类型的管控组件都可能对集群不同范畴的资源做list/watch，可能造成边缘节点到核心节点较多开销的网络 I/O 累赘。为此设计的 OpenYurt Pool-Coordinator  组件，会为节点池维度的资源提供边缘侧缓存，从而升高因为这些资源的大量 list/watch 申请造成的云边网络带宽问题，相比原生 Kubernetes 云端进口流量峰值升高90%。 ...

KubeVela 是一个开箱即用的现代化利用交付与治理平台，它通过对立的利用模型、可编程可扩大的架构，帮忙企业构建对立的平台，向上为不同场景的业务团队按需提供差异化、且开箱即用的平台层能力，大大降低了云原生技术的应用门槛。除了外围的云资源交付、利用治理、多集群、工作流等技术，KubeVela 还提供了全栈的申明式可观测能力，帮忙业务开发者灵便定制，轻松洞察各类简单的云原生工作负载。 本文咱们将聚焦 KubeVela 的可观测体系，介绍云原生时代的可观测挑战及 KubeVela 的解决方案。 01 云原生可观测的挑战通常状况下，为了给下层业务提供可观测性能力，运维团队会通过“熟练掌握” 业务团队的应用场景，而后将运行应用服务的基础设施与各类可观测性基础设施连接，通过绝对固化的脚本和零碎，将采集指标、收集日志、聚合解决、图表剖析等一系列流程合并，从而将最底层的运行态实时反馈到监控报警零碎中，为运维团队本身及下层业务团队做预警，并在第一工夫发现异常、排查故障。 （图 1）CNCF landscape 的插件曾经达到 1000+，且每天都在新增 随着云原生生态的一直凋敝，平台工程的理念逐步深入人心，一个根底平台团队往往须要服务下层多个微服务化的业务团队，而业务团队的架构也随着基础设施的丰盛逐步产生了多样性，这就突破了传统保姆式地从“熟练掌握”到“硬编码”的可观测体系建设门路。举例而言，业务团队刚开始构建业务的时候可能应用根底的 ingress 做服务网关，而半年之后可能随着需要的复杂化会切换成以 istio 为外围的流量治理计划，这意味着从 API 到下层架构相干的可观测能力都要跟着扭转。如图 1 所示，在 CNCF landscape 的凋敝生态里，每个子畛域都能找到多个替换计划。传统模式下绝对固定的可观测性体系构建形式不再实用，平台团队须要依据业务层的架构灵便定制和扩大可观测计划。 而“割裂”则是可观测畛域面临的第二个微小挑战，这通常会体现在三个维度。第一个维度是不同业务间数据的割裂，从基础设施（计算/存储/网络）、容器、利用到业务，从挪动端、前端、后端到数据库和云服务，企业的不同部门通常会采纳不同的监控计划，监控数据彼此造成孤岛，无奈买通。第二个维度是不同基础设施配置的割裂，随着云时代到来，企业面临多云、多集群、多账号的治理，可观测数据分布在不同云和集群内，多云多集群的可观测无奈对立配置。第三个维度是数据链路的割裂，例如开源社区的 Prometheus(Exporter)、Grafana 别离有本人凋敝的社区，但他们的采集源和大盘往往没有很好的连贯在一起，经常是一头输入大量有效数据占用存储资源，另一头则展现谬误或者提早很高的数据。 （图 2）社区找到的具备对应关系的大盘和 Exporter 通常无奈间接应用 而传统监控零碎采纳的基于图形界面点击的配置形式显然也不再实用，尽管上手简略，然而迁徙、复制老本极高。在多集群治理下，监控配置不易于复制，漏采、漏配很常见。也难以与利用交付的配置绑定，无奈实现监控随着利用生命周期而被动变动。 如果沿着云原生申明式对立 API 的理念去思考，你就会发现咱们也须要一套申明式的配置形式，让咱们可能以对立的形式、灵便的对接可观测基础设施，按需串联和定制全套的可观测能力，主动实现监控探针装置、采集、存储、展示、告警等配置的多环境对立下发和治理。这个模式咱们也能够称之为全栈申明式可观测（Full Stack Observability as Code）。 02 全栈申明式可观测尽管云原生时代的可观测存在诸多挑战，然而也得益于云原生开源技术的倒退，以 Prometheus、Grafana、OpenTelemetry 为代表的可观测基础设施正在逐步成为各自畛域的事实标准，周边生态的集成正在以滚雪球的态势累积，这让可观测基础设施的对立成为了可能。选型这些开源我的项目为外围构建可观测解决方案成为了十分天然的抉择，不仅帮忙咱们对立了技术和数据，还能够让咱们借力生态，疾速满足业务场景的须要。 对立的申明式可观测 API一个要害的挑战是如何将可观测基础设施的能力变成申明式的？你可能容易想到 Kubernetes 的 CRD（自定义资源）Operator 技术，的确曾经有相当一部分可观测能力能够间接应用 CRD 这样的申明式 API。比方 Prometheus 就能够通过装置 Prometheus-Operator 取得 ServiceMonitor 这个申明式 API。然而还有一部分其余我的项目（比方 Grafana），以及大量的云服务，他们并不具备成熟的 CRD Operator。为每个服务都编写 CRD Operator 存在不小的技术难度，不仅费时费力，同时还要耗费额定的 Pod 资源，整体老本比拟高。 咱们天然会想，是否有一种形式能够这些服务的 API 主动转换成合乎 Kubernetes 规范的申明式 API？针对这种状况，Kubernetes 的 Aggregated API Server（简称 AA） 模式提供了答案，即通过开发合乎 Kubernetes API 标准的 REST 服务，通过 APIService 对象将其注册到 Kubernetes apiserver 上，从而达到扩大 Kubernetes apiserver 能解决的申请类型的成果。相较于 CRD + Operator 的模式，AA 模式提供了与 CRD 对立的 API，但处理过程并不是面向终态的，它可能提供同步的申请解决，灵活性和交互性较高。而 AA 模式的毛病则是它本身不具备调谐重试的能力，须要配合额定的伎俩针对出错等异样状态做面向终态的重试。 ...

01 什么是 CPU 混部CPU 混部是指将不同类型的业务部署到同一台机器上运行，让它们共享机器上的 CPU 资源以晋升 CPU 利用率，从而升高机器的洽购和经营老本。然而，对于有些类型的工作来说，它们对延时十分的敏感，比方电商、搜寻或 web 服务等，这类工作的实时性很高，然而通常对资源的耗费却不是很多，咱们称之为在线工作；还有一类工作，它们更多的关注计算或者批处理，对延时没有要求，然而耗费的资源绝对较多，咱们称之为离线工作。 当这两类工作同时部署到同一台机器上时，因为离线工作对资源的占用较多，资源竞争导致在线工作的延时受到了很大的影响，而且，在超线程架构的机器上，即便离线工作和在线工作跑在不同的超线程 CPU 上，流水线和 cache 的竞争也会导致在线工作的运行受到影响。于是，CPU 混部技术诞生了，来解决离线工作对在线工作延时的影响，同时还能进一步晋升 CPU 资源的利用率。 （图 1/混部单机 CPU 利用率示意图） 02 内核 CPU 混部技术CPU 混部技术，次要是通过单机操作系统调度器来实现的，通过工作类型来决定所调配到的 CPU 资源。龙蜥社区的三大原生技术为 Koordinator 社区提供了弱小的 CPU 混部底层技术支持，包含： Group Identity 混部技术Plugsched 调度器热降级技术CPU 混部插件产品 2.1 龙蜥 Group Identity 技术龙蜥社区的 CPU 混部技术——Group Identity 给操作系统内核提供了 CPU 混部能力，例如 Alibaba Cloud Linux 2/3 和 Anolis7/8 OS 发行版均应用的是该技术。Group Identity 技术是在原有的 CFS 调度器中新增了另一个运行队列来辨别在线和离线工作，而且，为了防止对端 CPU（超线程架构）上离线工作的烦扰，Group Identity 会对其进行驱赶。龙蜥的 Group Identity 技术曾经通过阿里双十一等大型流动以及大规模商业化的验证，其 CPU 混部能力也失去宽广用户和开发者的认可。 ...

近期公布的 JuiceFS CSI Driver v0.18 版本中，咱们提供了一种全新的形式拜访文件系统，即 JuiceFS 客户端以 Sidecar 形式运行于利用 Pod 中，且客户端与利用同生命周期。 这个全新的性能将帮忙用户在 Serverless Kubernetes 环境中应用 JuiceFS；与传统的 Mount Pod 模式相比，问题排查更不便、客户端治理更简略。 明天在这篇文章中，将为大家介绍 Sidecar 模式的工作原理以及利用场景， 另外在文末还附上了用户关怀的问题与解答。 What is a sidecar in cloud?Sidecar 是一种常见的设计模式，这个概念在容器和微服务的畛域中十分风行。回到 sidecar 的字面意思，如下图所示，就是指摩托车边上装置的这个小车，以减少摩托车的承载能力，它十分形象地表白了Sidecar 容器和利用容器的关系。在云环境中，他们成为一体，共享 Kubernetes pod 的环境，并且同一 pod 内的所有容器生命周期统一。 根底介绍一些名词解释• Pod：能够在 Kubernetes 中创立和治理的、最小的可部署的计算单元• Deployment / DaemonSet / StatefulSet / Job：申明式资源，对 Pod 的不同治理形式• PV（PersistentVolume）：集群中的一块存储• PVC（PersistentVolumeClaim）：表白的是用户对存储的申请• StorageClass：为管理员提供了形容存储 "类" 的办法• CSI（Container Storage Interface）：容器存储接口 如何应用存储的治理是一个与计算实例的治理齐全不同的问题。PV 示意的是集群中的一块存储，能够由管理员当时创立；或者应用 StorageClass 来动态创建，而后用户在 Pod 中通过指定 PVC 来应用。依据 PV 的创立形式，能够分为动态配置和动静配置两种应用形式，上面一一介绍。 ...

导读：2 月 17 日，由中国开源软件推动联盟 PostgreSQL 分会 & 中科院软件所 & CSDN 联结举办的 “中国 PostgreSQL 数据库生态大会” 隆重召开。拓数派（OpenPie）作为冉冉升起的新一代云原生分布式数据库厂商，受邀加入本届大会。本文为演讲的文字版摘要，次要内容包含： 通明加密的设计思路通明加密模块的架构三级密钥的实现密钥治理的实现分享嘉宾：PieCloudDB 资深技术专家 王淏舟 回访视频：https://www.bilibili.com/vide... PPT 链接：https://openpie.com/download/... 一、数据安全的重要性往年来，对于数据安全的政策和热点新闻层出不穷。无论是政府、企业或是各个厂商都对数据安全给予了很高的器重。过往的案例表明，如果呈现敏感数据的泄露或失落，将给企业和用户带来微小的损失。 对于云上用户来说，云上数据的平安更是其最关注的需要之一。 作为一款存算拆散的云原生数据库产品，PieCloudDB 做到了三大区域的平安个性设计，全链路地保障用户数据安全，包含： 云原生平安存储平安计算平安其中，针对云原生平安，PieCloudDB 实现了传输层加密和缓存数据加密。作为一款云原生的 eMPP（弹性大规模并行计算）数据库，数据会在不同节点间进行传输，因而对于传输过程的数据加密至关重要。在执行用户查问时，PieCloudDB 会生成相应的缓存数据，用以减速查问后果的生成。缓存数据中会蕴含一部分的用户数据，对缓存数据的加密将更好的保障用户的数据安全。 针对存储平安，元数据作为数据库的「心脏」，一旦呈现失落或损坏，将导致数据库的不可用。为此，PieCloudDB 实现了对于元数据的长久化存储。PieCloudDB 的用户数据被多正本加密存储，以保障用户数据的彻底平安。 针对计算平安，PieCloudDB 采纳 eMPP 存算拆散架构，并反对 ACID，在集群繁多节点或更多节点生效的状况下，不会造成用户数据的失落或损坏。 本文将着重介绍 PieCloudDB 是如何通过通明加密模块实现云原生平安层的缓存数据加密，和存储平安层的用户数据加密存储的。 二、PieCloudDB 通明加密设计思路PieCloudDB 打造的通明加密模块让数据从传统的明文存储转为加密存储，能够无效地避免数据被零碎运维人员间接读出，保障存储在数据文件中的数据安全。通明加密是指密钥生成、密钥治理和加解密过程由数据库管理系统主动实现，用户无感知。也就是说，通明加密的加密和解密过程对用户来说就是通明的，用户读写数据十分不便，数据写入主动加密，读取主动解密。此外，PieCloudDB 的通明加密模块不依赖于私有云 / 公有云 / 零碎自带的加密，真正实现了自主可控，同时满足数据安全审计和业务平安审计等用户合规需要。 PieCloudDB 通明加密模块的设计和实现过程中，研发团队充分考虑和总结了用户需要与技术挑战，让通明加密模块实现了以下几个个性： 用户侧，PieCloudDB 通明加密模块合乎审计流程，做到用户无感知，可能与用户业务拟合，无需对业务进行扭转。研发侧， PieCloudDB 通明加密模块作为一个独立模块，与数据库存储模块联合，不影响内核迭代，不便后续扩大，无历史包袱。三、PieCloudDB 通明加密的实现细节PieCloudDB 通明加密模块采纳目前支流的多级密钥机制和无效的密钥管理机制防备了数据泄露危险，确保了用户的数据安全。每个租户数据齐全隔离，领有独立的密钥体系。 密钥治理的实现在 PieCloudDB 中，主密钥是由用户自主生成、保留与管制的，保留于用户的信赖域中，PieCloudDB 的通明加密模块不会尝试拜访主密钥，确保主密钥的平安。 此外，PieCloudDB 的最小加密单位为数据页，每个数据页都由单个密钥进行加密。加密密钥反对轮换，能够按一段时间、或某些条件进行新的密钥的轮换，来最大化保障数据安全。同时，在轮换时，须要防止中断服务，无需停机。 PieCloudDB 采纳三级密钥机制，轮换下级密钥无需从新加解密数据，只需加解密密钥。同时，PieCloudDB 通明加密模块反对按页 / 按表轮换密钥，防止整个用户集群停机轮换密钥，最大限度的缩小对用户业务的影响。 密钥保留是通明加密模块中十分重要的局部，一旦密钥失落，数据将无奈解密，从而彻底无法访问。PieCloudDB 通明加密模块的所有次级密钥均进行了长久化存储，保障密钥的平安，底层页级密钥与数据共存，数据多正本备份，避免页级密钥的失落造成无法挽救的损失。此外，因为页级密钥可能会很大，页级密钥与数据的共存，也能防止在拜访密钥时频繁拜访长久化存储，缩小查问的提早。 ...

文/OpenAnolis Kernel SIG 01 什么是 CPU 混部CPU 混部是指将不同类型的业务部署到同一台机器上运行，让它们共享机器上的 CPU 资源以晋升 CPU 利用率，从而升高机器的洽购和经营老本。然而，对于有些类型的工作来说，它们对延时十分的敏感，比方电商、搜寻或 web 服务等，这类工作的实时性很高，然而通常对资源的耗费却不是很多，咱们称之为在线工作；还有一类工作，它们更多的关注计算或者批处理，对延时没有要求，然而耗费的资源绝对较多，咱们称之为离线工作。 当这两类工作同时部署到同一台机器上时，因为离线工作对资源的占用较多，资源竞争导致在线工作的延时受到了很大的影响，而且，在超线程架构的机器上，即便离线工作和在线工作跑在不同的超线程 CPU 上，流水线和 cache 的竞争也会导致在线工作的运行受到影响。于是，CPU 混部技术诞生了，来解决离线工作对在线工作延时的影响，同时还能进一步晋升 CPU 资源的利用率。 （图 1/混部单机 CPU 利用率示意图） 02 内核 CPU 混部技术CPU 混部技术，次要是通过单机操作系统调度器来实现的，通过工作类型来决定所调配到的 CPU 资源。龙蜥社区的三大原生技术为 Koordinator 社区提供了弱小的 CPU 混部底层技术支持，包含： Group Identity 混部技术Plugsched 调度器热降级技术CPU 混部插件产品2.1 龙蜥 Group Identity 技术龙蜥社区的 CPU 混部技术——Group Identity 给操作系统内核提供了 CPU 混部能力，例如 Alibaba Cloud Linux 2/3 和 Anolis7/8 OS 发行版均应用的是该技术。Group Identity 技术是在原有的 CFS 调度器中新增了另一个运行队列来辨别在线和离线工作，而且，为了防止对端 CPU（超线程架构）上离线工作的烦扰，Group Identity 会对其进行驱赶。龙蜥的 Group Identity 技术曾经通过阿里双十一等大型流动以及大规模商业化的验证，其 CPU 混部能力也失去宽广用户和开发者的认可。 ...

前言 容器 / 镜像破绽扫描的利用场景 应急检测 云平安建设：CI/CD veinmind-vuln 的应用 如何解决镜像的破绽事件？1、前言在镜像平安的建设中，镜像破绽扫描是保障镜像利用依赖（Dependencies）平安的重要形式之一，也帮忙用户辨认镜像中的软件破绽。 依据 snyk 公布的 2022 年开源平安报告显示，均匀每个利用中会呈现 5.1 个重大等级的破绽，利用依赖导致的破绽占据了总数的近 40%。 而镜像之间的依赖关系，会进一步的放大这个比例： 当一个存在破绽的镜像作为了另一个镜像的根底镜像，很大概率该镜像也会存在这个破绽，减少了平安危险。 因而，利用破绽是镜像平安的一个重要局部。 2、容器 / 镜像破绽扫描的利用场景应急检测在云原生环境或生产环境中，当软件 0day 破绽暴发时，仅通过白盒代码审计（SAST）的形式来排查利用是否应用了 0day 组件，并不可能百分之百的保障线上业务的安全性，因为咱们并不分明整个容器在启动或运行的过程中，是否做了其余操作，或引入了其余依赖。因而，对生产容器进行平安扫描能够清晰、明确的获取到容器软件信息，并精准的与 0day 信息进行匹配。  云平安建设：CI/CD在云平安建设的过程中，咱们仍旧心愿可能尽早的、在开发构建阶段发现平安问题，并阻断自动化测试 / 部署流程，通过平安前移的形式来疏导开发者在开发阶段提前解决平安危险。咱们能够通过设定破绽的阈值，对事件进行解析，从而判断是否要进行阻断，并推送给开发者进行修复。  3、veinmind-vuln 的应用veinmind-vuln 插件是由 veinmind-asset 插件降级而来，在资产信息扫描的根底上，对所有的资产信息进行了 CVE 破绽匹配。能最大水平上发现并检测镜像利用破绽信息。能够通过下方命令疾速对主机上的镜像进行扫描，并将列出所有组件以及他们对应的破绽 ID:./veinmind-vuln scan image  如果心愿获取到破绽更加具体的信息，能够应用 -v 进行展现：./veinmind-vuln scan image -v  如果只须要获取镜像的资产信息，能够通过 --only-asset 参数仅对镜像的资产进行扫描：./veinmind-vuln scan image --only-asset   4、如何解决镜像破绽信息对于扫描出的破绽信息，咱们能够次要分为两大类： 通过降级镜像版本进行修复。通过降级利用本身的组件版本或配置进行修复。举两个例子，如，同样是发现 CVE-2019-10129 (PostgreSQL 缓冲区谬误破绽)，如果该破绽呈现在 alpine:3.9 的镜像中，你须要手动降级 postgresql 的版本；而如果破绽呈现于 postgres:xxx 的镜像中，你只须要尝试将镜像降级为最新的 tag 进行修复即可（如果官网更新了该问题）。除此之外，对于镜像扫描呈现的 CVE 信息，咱们也能够依据软件起源来进行粗略的优先级辨别，如：来自应用层的破绽往往会比零碎 os 利用的破绽问题更加重大，因而举荐先关注利用组件产出的破绽，最初再关注零碎组件产出的利用。 ...

受中国PostgreSQL数据生态大会邀请，OpenPie资深技术专家郭峰将于3月3日16:20-16:50与大家分享《云原生数据库PieCloudDB Database性能优化之路》。届时，会为大家解析PieCloudDB优化器——「达奇」的残缺设计思路，及针对OLAP剖析型场景（人工智能、商业智能背地的弱小撑持技术）的多阶段汇集、汇集下推、Block Skipping等一系列性能优化。扫描海报二维码，与咱们一起探索「实现大数据愿景」背地的机密。

公司介绍Soul 是基于趣味图谱和游戏化玩法的产品设计，属于新一代年轻人的虚构社交网络。成立于2016年，Soul 致力于打造一个“年轻人的社交元宇宙”，最终愿景是“让天下没有孤单的人”。在 Soul，用户能够无顾虑地表白本人，认知别人，摸索世界，交换趣味和观点，取得精力共鸣和认同感，在交换中获取信息，并取得有品质的新关系。 问题与挑战 2.1 多层网关链路长Soul 在 2020 年开始逐步试探容器服务，在 ECS 转型容器阶段，呈现了容器入口网关(Ingress-Nginx)，微服务网关，加上对立接入层的 SLB+Tengine；造成了多重网关的架构；链路太长不仅带来老本和 RT 的问题，而且导致排查一个申请异样，须要拉十分多的人解决，定位问题代价十分大。 2.2 Ingress-Nginx 开源问题往年 Ingress-Nginx 社区反馈稳定性和平安问题比拟多，临时进行接管新性能，对 Soul 是一个微小隐患。 2.3 Grpc 转发负载不平衡问题 内网局部服务凋谢 gRPC 入口，gRPC 是基于 HTTP/2 之上的，而 HTTP/2 被设计为一个长期存在的 TCP 连贯，所有都通过该连贯进行多路复用。这样尽管缩小了治理连贯的开销，然而在负载平衡上又引出了新的问题。因为咱们无奈在连贯层面进行平衡，为了做 gRPC 负载平衡，咱们须要从连贯级平衡转向申请级平衡。换句话说，咱们须要关上一个到每个目的地的 HTTP/2 连贯，并均衡这些连贯之间的申请。这就意味着咱们须要一个 7 层负载平衡，而 K8s 的 Service 外围应用的是 kube proxy，这是一个 4 层负载平衡，所以不能满足咱们的要求。目前应用独立 evnoy + headless 计划解决 gPRC 转发不平衡问题，slb 裸露 envoy 的端口供其余服务调用；但保护老本较高，evnoy 节点资源节约较为重大 2.4 Ingress 稳定性及局限性1.因为业务的不确定性，随着业务申请的稳定，nginx ingress controller 会呈现连接数突增，导致 ingress controller 健康检查不通过；nginx ingress controller上游的检测须要工夫及 fail 次数积攒，导致这一阶段用户申请大量失败或重试。(如下图) ...

网易云音乐最近开源了 Horizon 利用部署平台，旨在为基于 Kubernetes 的云原生利用部署提供牢靠、平安、高效的标准化计划。Horizon是一个基于 Kubernetes 的云原生继续部署平台，并且全面践行 GitOps。PlatForm Team能够自定义创立版本化的服务模板，为业务应用程序和中间件定义合乎统一标准的部署和运维。Developer能够抉择事后定义的模板，进行自动化的服务部署，确保基于Kubernetes的对立最佳实际。通过Horizon GitOps机制，确保任意变更（代码、配置、环境）长久化、可回滚、可审计。 Horizon 受 Argo CD 和 AWS Proton 的启发，并由网易云音乐、网易数帆等团队合作开发，当初 Horizon 已被大规模利用到了网易云音乐和网易传媒的理论生产环境中。 开源背景网易云音乐全面启动云原生、容器化的工夫并不是十分早，大概在2020年，云原生的倒退也是突飞猛进，诸多技术计划基于Cloud和Kubernetes都有被从新打造的后劲和趋势。过后咱们关注到GitOps畛域的倒退，以及CICD畛域的云原生的前沿停顿，决定基于这些最新的理念和计划去打造一款可能中长期满足公司久远倒退的CD平台。 目前该我的项目曾经全面落地到网易云音乐，以及其余事业部。网易云音乐通过Horizon全面治理国内外7大机房，反对各种类型的业务，包含在线利用（Web服务）、Serverless（反对音视频）、实时计算、AI推理、中间件等的部署和运维。基于Horizon的日均构建和公布达到上千次，各类微服务集群8K+。全面高效撑持了云音乐实现云原生容器化的技术迭代和转型，并且无效地反对了公司降本增效指标的落地。 通过2年多来，协同业务一直地打磨、迭代，以及大规模业务落地实际，咱们认为Horizon 在 GitOps 继续部署畛域相比业界解决方案领有劣势。正好，网易团体也激励咱们做翻新做开源。所以此次，咱们将Horizon正式全面开源，心愿Horizon同样帮忙更多同行和公司，发明更大的价值。当然咱们心愿社区和有趣味的同仁可能参加到Horizon的开源建设，一起交换，一起学习，一起提高。 劣势与个性劣势标准化部署：抉择Horizon的一个要害起因是Horizon标准化的利用部署。尽管 Kubernetes 灵便而弱小，但也是宏大而简单的，交融诸多视角的关注点，比方平安、架构、sre等等，这使得开发人员难以全面了解 Kubernetes，更难以遵循最佳实际。Horizon 通过引入模板（基于Helm Template）解决了这个问题。Horizon提供了标准化模板化的能力，平台管理人员能够自定义合乎本身需要的模板，帮助业务进行最佳实际落地。例如，Horizon 治理团队能够在自定义模板中提供几个根本资源选项，比方，默认状况下只提供 tiny（0.5 core，512 MB）、small（1 core，1 GB）和 middle（2 core，4 GB）等，防止出现资源的碎片化且保障用户接口的更加敌对而简洁。平安和牢靠：Horizon 的另一个长处是平安和牢靠。Horizon 100% 基于GitOps，通过 Horizon 对应用程序所做的每个变更都是长久化的、可回滚和可审计。保障牢靠平安的状况下，仍然可能助力业务进行麻利实际。凋谢且可扩大：Horizon 还反对各种类型的工作负载，包含根本的 Kubernetes 工作负载和云原生工程师自主研发的CRD。基于通用的申明式API，实现宽泛的兼容与凋谢。大部分状况下，Horizon平台不必任何前后端代码研发，即可疾速将各种云原生能力赋能到业务一线研发。多云反对：Horizon 提供了对立的应用程序平台来治理多云和混合云，这使得 Horizon 成为各种应用场景下的现实平台。高效：Horizon 治理团队可能基于模板以及低代码的能力疾速交付合乎最佳实际的利用部署，疾速赋能业务全面实际 DevOps。个性GitOps: Horizon 基于 GitOps 部署利用，Git 仓库贮存了所有的配置及其变更，使每个应用程序的更改都是长久化的、可逆的和可审计的。Horizon模板: Horizon 基于 JSON Schema 简略拓展了 Helm Template System（兼容 Helm Template），Horizon 治理团队能够在 Template 中定义 默认Kubernetes 资源的根本配置（例如 security, affinity, priority, resource 等）确保业务开发可能恪守最佳实际；并且各种底层申明式的能力能够面向业务进行进一步的更好的产品化。用户抉择模板后，Horizon 基于模板中的 JSON Schema 文件和 React JSON Schema Form 渲染一个简略对立的 HTML 表单。Template 简略而灵便，能够基于 Template 定义本人的最佳实际。RBAC & Member: Horizon 提供了一个与 Gitlab/GitHub 相似的 RBAC & Member 零碎，Horizon 治理团队能够轻松地创立合乎本身需要的 Role（与Kubernetes 的 role、rolebinding 相似）和 Member。在咱们的生产实践中，咱们定义了 PE、Owner、Maintainer、Guest 等角色。Owner 领有读（查问Pods，读取配置等），写（部署，构建部署，重启，公布，删除等）权限，Guest 只有读权限。内部集成：Horizon 反对提供了 OpenAPI、OAuth2.0、Webhooks、拜访令牌等性能，用户能够不便地将 Horizon 集成到本身外部零碎中。并且 Horizon 也能够作为 OAuth 客户端，接入内部 OAuth 服务器。 ...

本篇文章咱们将具体介绍怎么轻松在 Anolis OS 上应用 Kata Containers 平安容器，咱们将介绍 Kata Container 社区于 2022 年 10 月 10 日最新发行的 Kata3.0.0 的装置部署形式，3.0.0 版本蕴含了基于袋鼠 RunD 开源的最新 Rust Kata runtime + 内置Dragonball 和Go runtime + VMM（本文默认装置了QEMU）两套架构。 目前社区打算在将来 1-2 年的工夫内逐渐由 Go Runtime 迁徙至 Rust Runtime，Rust Kata runtime 是 Kata 社区将来的倒退方向，在整体资源耗费、启动速度等方面都有显著劣势，同时提供内置沙箱 Dragonball 进一步提高应用体验，目前还处于疾速倒退阶段。 本教程默认装置 Rust Kata Runtime + Dragonball，并会提供繁难教程帮忙您切换到Go Kata Runtime + QEMU，另外，咱们提供的 Guest Kernel 基于龙蜥 OS, rootfs 基于专门为容器场景优化的 LifseaOS。 01 Kata Container 3.0.0 (Rust Runtime + Dragonball)RunD 是龙蜥社区开源的下一代平安容器解决方案，相比于社区的 Kata 2.0 而言，RunD 最大的特点是提供了基于容器场景深度优化的内置 Dragonball 沙箱，缩小了虚拟化内部依赖，带给用户开箱即用的优质体验。同时极大晋升了整体容器的启动速度；其次通过引入全新的异步 Rust Runtime 机制，进一步升高 Kata 平安容器整体的资源开销。RunD 目前已开源成为 Kata Containers 社区上游 3.0 版本规范。之前文章里介绍了 Kata 3.0 背地的设计与思考，其中一体架构、轻量平安容器虚拟机 Dragonball、异步 Rust Runtime 等翻新给 3.0 版本带来了低资源开销、极速启动速度、易于运维等劣势。 ...

11111111

随着数字化浪潮的降临，云原生技术正在扭转着各行各业，通过IT改革驱动业务翻新倒退，促成企业本身以及产业生态的转型降级。 因而，灵雀云联结云原生技术实际联盟（CNBPA）和行业内头部厂商F5，独特发动了《第五期（2022-2023）传统行业云原生技术落地调研——金融篇》，将持续以聚焦行业的模式，深入探讨云原生技术对金融行业带来的冲击与改革。 本期调研将连续2018年以来此系列调研的钻研办法，从云原生技术全栈视角，对金融企业目前高度关注的容器、微服务、DevOps、平台工程、FinOps等热门技术畛域和行业趋势动手，全面摸底云原生技术的利用状况和落地成熟度，心愿能为2023年度金融行业IT建设提供借鉴，减速数字金融倒退。 如果您也对金融科技充斥热诚，是云原生技术落地的推动者，欢迎您一起参加本次调研，独特摸索2023云原生落地倒退新方向。 调研对象金融企业中的IT部门主管及开发、运维等技术人员 调研工夫即日起至2023年3月31日 调研问卷扫描上方二维码，即可参加调研 为感激各位对金融行业云原生落地实际的关注，咱们还为大家筹备了惊喜礼品哦~ 前50名符合条件的敌人将有机会取得由主办方提供的惊喜礼品盲盒！ 盲盒礼品领先看……P.S. 惊喜礼品盲盒为随机发送，先到先得~快来填写问卷，支付精美礼品吧！ 点击查看往期调研报告：第四期（2021-2022）传统行业云原生技术落地调研报告——金融篇第四期（2021-2022）传统行业云原生技术落地调研报告——央国企篇 相干举荐：

北京工夫 1 月 30 号公布的 OpenYurt v1.2.0 版本，社区呼声最高的几大个性终于落地，OpenYurt 的特点更加显明，次要特点包含：Kubernetes 无侵入，云边端全协同，可编程的资源访问控制，以及申明式云原生设施治理。 v1.2 版本聚焦在节点池治理，重点打造 OpenYurt 零碎的差异化技术竞争力，次要个性有升高云边通信的流量老本，边缘自治能力加强，更丝滑的跨地区通信能力等。 大幅升高云边通信流量老本在云边协同场景下，边缘通过公网和云端连贯，当集群中部署了大量的业务 Pod 和微服务零碎(引入大量 Service 和 Endpointslices)，边缘节点和云端之间须要耗费大量带宽，给用户带来极大的公网流量老本压力。 社区对升高云边通信流量始终有比拟强的诉求，如何在不侵入批改 Kubernetes 的根底上满足需要，首先大家比拟容易思考到的计划是在节点池内减少一个 sync 组件，实时同步云端的数据，而后再分发给节点池中的各个组件。然而这个计划落地将面临不小的挑战，首先数据拜访申请都是边缘被动向云端发动的，sync 如何拦挡这些申请并散发数据呢？同时如果 sync 组件故障，边缘的申请将面临中断，而保障 sync 组件的高可用会十分辣手。 OpenYurt 社区独创基于 pool-coordinator+YurtHub 的云边流量复用机制，既与原生 Kubernetes 的云边通信链路无缝交融，又优雅的保障了通信链路的高可用(YurtHub Leader 选举)，实现云边通信老本的消减。 在节点池内，节点从云端获取的数据，能够分为两种类型： pool scope data: 组件从云端获取的数据完全一致，如每个节点的 kube-proxy 获取到的 endpointslicesnode scope data: 组件从云端获取的数据和本身节点相干，如每个节点的 kubelet 获取到的 pods同时通过测试[1]发现，真正占用云边带宽的数据是 pool scope data。OpenYurt v1.2 中通过在节点池中复用 pool scope data，从而大幅升高云边的数据通信量。如下图： 节点池中所有 YurtHub 组件通过节点池中的 Pool-Coordinator 进行选举产生 Leader，只有和云端网络连接失常的 YurtHub 才会成为 Leader。当 Leader 节点的云边网络连接异样时，Leader 将被其余 Follower 主动接替。Yurthub Leader 被动从云端实时获取 pool scope data(如 Endpointslices)，而后存入节点池的 Pool-Coordinator 组件中。节点上组件(如 Kube-Proxy)通过 Yurthub 来获取 pool scope data 时，Yurthub 将从 Pool-Coordinator 返回实时的数据。通过 Pool-Coordinator 和 Yurthub 的协同，繁多节点池内云边只有一份 pool scope data 通信数据，从而大幅升高云边的通信数据量，相比原生 Kubernetes 云端进口流量峰值升高 90%。 ...

要说时下科技圈最火的新技术话题，那就非 ChatGPT 莫属了。由它引发的各类 “人工智能（AI）是否取代人工” 的探讨狂飙不停，抛开法律和道德层面的争议，ChatGPT 的确能够精确地答复用户大部分的通用常识问题。那么大家是否会好奇，ChatGPT 是依附什么取得了这样 “无所不知” 的超能力呢？  作为一款交换机器人，ChatGPT 的全称是 Chat Generative Pre-trained Transformer（生成式预训练转换器），由 OpenAI 公司研发，并于 2022 年 11 月公布。ChatGPT 应用了基于 GPT-3.5 （最新凋谢版本）架构的大型语言模型，并通过强化学习在 Microsoft Azure 的超级计算机上进行训练，而后通过近端策略优化算法进行微调，参数量多达 1750 亿个。用一句话来概括：ChatGPT 的背地，技术底座是大型语言模型，外围竞争力是算力。   ChatGPT 对算力的需要之大能够通过这样一组数据出现，GPT-3.5 的训练应用 Microsoft 专门建设的 AI 计算零碎，由 1 万个 V100 GPU 组成的高性能网络集群，总算力耗费约 3640 PF-day，即如果每秒计算一千万亿次，须要计算 3640 天。于此同时，ChatGPT 的算力耗费也在一直扩张，其大型语言模型经验了三次迭代，GPT、GPT-2 和 GPT-3 的参数量从 1.17 亿减少到 1750 亿，预训练数据量从 5GB 减少到 45TB，其中 GPT-3 训练单次的老本就曾经高达 460 万美元。以理论场景为例，咱们每问 ChatGPT 一个问题，它就须要破费几美分来计算。所以对于 OpenAI 而言，如何继续一直地取得算力反对并管制昂扬的计算成本是至关重要的。目前 ChatGPT 和 Microsoft 提供的零碎是强绑定的关系，OpenAI 也示意：无论当初还是未来，Microsoft Azure 都会是 ChatGPT 惟一指定的云计算供应商。这么一来，Microsoft 的投资逻辑也就显而易见了，我先借资金和算力给你，日后再靠你一直扩张的算力需要来赚钱，Microsoft 十分分明地意识到了数据计算背地的商机。   换言之，哪怕取得了这个简单大模型的代码，也不是谁都能够跑得起来的。所以，ChatGPT 的胜利不仅是简单算法的功绩，更是依赖了云计算服务的撑持，OpenAI 从 Microsoft 取得的不只是资金层面的反对，更是技术层面的系统优化，其中包含但不限于计算、存储、数据库和网络等方面的资源配置。对于 ChatGPT 来说，借助云的特点在 Microsoft Azure 上实现高性能计算、数据存储和解决、寰球可用性、弹性治理资源、老本效益是零碎失常运行的根底。比方近日 ChatGPT 身处舆论的风口浪尖，寰球各地拜访网站的流量激增，Microsoft Azure 能够主动为模型提供更多资源（如 CPU 和内存），以解决减少的负载。相同，当流量下降时，它也能够缩减配置资源以节省成本。与此同时，ChatGPT 也不须要建设本人的数据中心，能够从 Microsoft Azure 云计算服务那里租用所需的资源，按需付费，还省去了运维费用，将老本效益最大化。  ChatGPT 的爆火反映的不只是 AI 技术畛域的冲破，更是大数据在行业利用的发展趋势。数据计算上云、资源租赁代替购买是大方向，解决宏大数据时能实现弹性伸缩资源，让企业降本增效，这正是 PieCloudDB Database 的设计初衷。  此答复仅供参考，请以官网产品描述为准   利用云计算的技术改革，云原生数据库 PieCloudDB Database 能够实现 IT 零碎从购买到租赁的转变，真正交付在 PC 机时代未能交付的大数据承诺。举个例子，对于一类脉冲式场景（如双十一），当天可能须要素日上百倍的算力来反对，PC 构造的设计迫使客户不得不投入上百倍的机器，并且只为一年 365 天中的某几天。这种状况下，客户有两种抉择，一是放弃脉冲式场景的数据计算，二是在后期投入宏大的资金，这也使得客户的投入产出比降落、错失了一些套利机会。尤其对于像 ChatGPT 这样资源耗费极高的场景，如何均衡网站流量激增或下降时的资源需要，是保障公司无效利用资源、管制总体收入的必要前提。   在 PieCloudDB 里，存储和计算各自作为两个独立变量，各自在云端弹性伸缩。用户能够在云端传输海量数据，云中的存储也会随之主动减少，这个舒展过程无需用户懊恼，PieCloudDB 能够主动实现。如果用户须要更大的算力，只需开启更多的虚拟机或者容器，PieCloudDB 会霎时扩容。在用户实现脉冲计算当前，能够敞开和放大计算的集群，从而节约在云中的计算费用。通过计算与存储的解耦合，得以实现资源的池化。用户从而能够通过租赁的形式来应用池中的资源，按使用量进行付费。PieCloudDB 让用户能够专一于应用，无需思考运维和降级等工作。   在这样一个零碎中，用户会继续将所有数据存储在云上，让已有的利用和将来的利用真正实现数据共享，PieCloudDB 从而帮忙用户真正实现大数据愿景（Big Data Promises finally Come True）。   ...

目录1.   钻研范畴定义2.   云治理服务（MSP）市场定义3.   厂商评估：华创方舟4.   入选证书 1.    钻研范畴定义 数字化时代，利用成为企业发展各项业务的落脚点。随着业务的疾速倒退，利用的性能迭代变得越来越频繁、业务零碎变得越来越简单、对IT资源的需要也变得越来越弹性。如何正当高效调配利用底层IT资源、治理下层利用、均衡二者关系，成为企业当下数字化建设中的重要关注点。云原生作为一套以云操作系统为外围，为灵便调度、按需分配云等基础设施的资源而专门设计的全新的IT技术体系，以其对立的资源调度能力和灵便弹性扩缩容能力，成为了企业应答上述问题的最优解。为此，爱剖析将于2023年Q1公布《2023爱剖析·云原生厂商全景报告》，为甲方选型提供参考。如云原生市场全景地图所示，爱剖析将市场划分为基础设施、根底软件、利用定义与开发、一站式云服务、运维治理、平安六类，囊括云原生存储、云原生数据库、云原生中间件、开发运维一体化（DevOps）、云治理服务（MSP）、智能运维中台、云原生平安等细分市场。在报告中，爱剖析综合思考甲方关注度和云原生实际状况等因素，将重点选取云治理服务（MSP）、智能运维中台等市场进行深入研究。图1：云原生市场全景地图 在上云过程中，云原生作为一种较为新兴的架构，对技术能力不强的企业存在肯定壁垒，对技术能力尚可的企业而言又需消耗肯定的人力及资源老本，因而采纳笼罩企业上云全周期的一站式云治理服务，对少数上云企业而言是降本提效强需要下的无效门路。这一背景下，通过深刻调研，爱剖析遴选出具备成熟解决方案和落地能力的厂商，供企业在做云治理服务（MSP）厂商选型时提供参考。同时，在该市场下，爱剖析重点选取了云治理服务商华创方舟进行能力评估。    云治理服务（MSP）市场定义市场定义：云治理服务（MSP）是指依靠CMP多云治理平台，为上云企业提供全流程反对，包含上云前的征询、计划布局服务，上云时的迁徙、施行、优化服务，上云后的监控、运维、治理服务，帮忙企业实现业务零碎的稳固上云迁徙，赋能企业数字化降级。甲方终端用户：企业IT部门甲方外围需要：传统上，企业业务部署在本地物理机房，随着业务的一直增长，多种问题一直凸显：第一，零碎扩缩容能力有余问题日益加剧，易呈现闲时节约、忙时紧缺的状况；第二，业务系统升级运维不便，零碎迭代速度无奈适应业务迭代速度；第三，不足对数据信息的平安管理控制，物理设施损坏会导致业务系统故障，企业零碎及业务平安能力有待晋升；第四，传统物理机房的硬件费用较高，不合乎企业降本增效的指标。因而，将传统部署在物理机房的业务迁徙至云端，是企业进行业务数字化降级、冲破业务倒退瓶颈的极为要害一步。在进行业务零碎上云迁徙时，企业往往有以下需要：上云前，需基于业务架构梳理，实现比照选型与架构设计等系统性建设布局。一方面，市面上私有云/公有云/混合云产品多样，标准化的服务难以解决企业上云需要，企业需在个性化需要剖析和利用零碎梳理的根底上，进行利用上云评估、上云品种抉择和云厂商抉择；另一方面，企业需深度诊断本身业务痛点，联合业务特点实现根底/应用软件的架构设计，制订具备高可行性的残缺迁徙计划并确认迁徙工具、迁徙时长等计划细节。上云时，需在最小化对业务影响的前提下，疾速实现业务上云迁徙与优化。一方面，企业需在不影响或大量影响整体业务运行的前提下，实现环境部署与安全策略配置，并逐渐实现全量数据、文件、服务器、主机、利用等的迁徙与残缺业务性能验证；另一方面，企业需在迁徙结束后，依据本身业务状况与行业个性，进行存量利用的适配性优化与增量利用的编排开发，保障业务安稳迁徙与交割。上云后，需实现对底层资源及下层利用的业余监控、运维，保障业务稳固。上云后，一方面企业需继续监控底层资源与下层利用，能力在呈现故障时及时响应、保障业务平安稳固；另一方面，云计算架构与传统架构差别较大，对运维管理人员能力要求较高，若依附企业本身人力及资源进行监控、运维，能力可能绝对欠缺且需破费额定老本。因而，尽可能以低成本、高业余实现对云根底及利用的管控，并及时进行运维，是企业上云后的要害需要。上云后，需反对多云治理与多云资源最优调配，以适应企业简单的多云环境。随着企业IT架构的日益复杂化，多云策略已根本成为当下少数上云企业的抉择，企业需可能以弱小的治理平台实现对简单混合云环境的撑持与调配。此外，除进行根本的对多云资源的治理外，企业对以智能化、自动化伎俩优化资源调配、赋能数据分析、晋升治理效力，也有肯定需要。 厂商能力要求：为实现上述甲方外围需要，企业往往需引入MSP云治理服务商，厂商需具备全方位服务能力和业余云治理平台产品，具体而言需满足以下能力要求： 厂商需具备征询能力，为企业客户提供零碎和软件的选型、布局、设计服务。首先，厂商需具备较为深度的行业认知，并能对企业客户业务需要进行疾速、残缺的梳理，在此基础上帮忙企业评估上云与否、上云工夫、上云业务及场景等，并实现平台选型。其次，厂商需具备系统性的计划架构能力，可能在零碎架构、数据架构评估的根底上，帮忙企业制订欠缺的、充分考虑细节与危险的上云迁徙与实施方案。厂商需具备业余的迁徙施行能力，帮忙企业顺畅实现业务上云。向下，厂商一方面需具备弱小的资源集成能力，能和多家云厂商形成良好的单干关系，实现云资源的疾速集成；另一方面需具备优质的迁徙交付能力，领有在垂直行业长期深耕的交付施行团队，且需具备欠缺易用的迁徙工具，助力企业实现对数据库、中间件等底层资源及业务利用的上云迁徙和验证。向上，厂商需能联合企业理论业务状况，进行行业利用的从新编排与开发，满足客户个性化需要。厂商需能提供根底的托管服务与业余全面的运维服务。一方面，厂商需能向企业提供日常的数据库治理、中间件治理、平安治理、备份治理、容器治理等服务，帮忙企业进行数据库等的监控、巡检、故障告警、日常保护配置等；另一方面，厂商需能提供及时牢靠的服务响应，以弱小的专家服务团队、通过多种渠道响应客户需要。值得一提的是，厂商若能提供DevOps产品，则是加分项。厂商需能提供CMP多云治理平台，并反对云资源灵便调配。依靠这一平台，厂商需能接入多家云厂商的云产品，且能对多云资源进行对立治理、对异构资源进行对立纳管，向企业清晰地出现资源详情和费用，并反对资源灵便调配。此外，具备AI能力，可能撑持智能化云资源调度、智能路由、智能数据分析等，是该平台的加分项。 入选规范阐明： 合乎市场定义中的厂商能力要求；2022年云治理服务（MSP）付费客户数量≥10个；2022年云治理服务（MSP）合同支出≥8000万元。厂商全景地图：   3.    厂商评估：华创方舟 厂商介绍：北京华创方舟科技团体有限公司（简称“华创方舟”）成立于2006年，是一家业余的独立智能化云治理服务提供商，为企业和政府客户提供包含云业余服务、云治理服务及云治理产品在内的定制公有云和混合云治理服务。成立以来，公司已在全国范畴内设立二十余分支机构，依靠业余的销售、服务及技术团队，服务笼罩金融、政府、电信、能源、交通等多个行业的超二百家客户。产品服务介绍：基于本身在云治理服务市场数年深耕，华创方舟向客户提供混合云全栈云服务，具体包含三大类产品及服务——云征询、云迁徙、云施行等云业余服务，云经营、云运维等云治理服务，以及蕴含混合云治理平台、自动化运维平台、运维服务治理平台、麻利运维平台等在内的云治理产品，为企业进行从云布局选型、迁徙施行到治理运维的全流程赋能。厂商评估：华创方舟在全栈的服务体系、业余的云治理产品、丰盛的落地教训及良好的云厂商单干根底四方面，具备显著劣势： 端到端的全栈服务体系。基于长期在云服务市场的业余积攒，华创方舟构建了三位一体的全流程服务体系，可能帮忙企业实现全周期、端到端的云治理服务。上云前，华创方舟可能为企业客户提供云化策略征询、云架构布局征询和云平安征询等服务，帮忙客户进行业务利用零碎上云需要调研、上云厂商选型、迁徙门路设计、可行性剖析及危险剖析；上云时，华创方舟可能帮忙企业进行“云组织”转型建设与施行、混合云平台建设与施行、混合云平安体系建设与施行以及云迁徙施行，帮忙企业进行云上基础架构搭建、利用、数据库、存储等的上云迁徙；上云后，基于ITIL规范服务流程，华创方舟可能一方面通过云计算架构治理、运维流程治理、运维能力治理等为客户提供全栈根底运维服务，另一方面以租用的形式为用户提供计算、存储、网络、平安资源和全生命周期的业务托管及经营服务，以专属资源池、云上等保计划、云灾备计划等为客户提供业余的数据安全和自主性保障服务，同时华创方舟还装备经验丰富的技术支持工程师和服务专家，实现平安、高性价比、灵便及时的服务响应，保障企业业务稳固。业余的云治理产品。华创方舟秉承双态运维、智能运维等核心理念，造成了以智能监控平台和混合云治理平台为外围的云治理产品矩阵，撑持云运维治理和云经营治理。一方面，华创方舟以智能监控平台实现了对存储、网络、服务器、中间件、数据库、容器、下层利用等的根底监控以及智能剖析与预测。如在国家税务总局某市税务局我的项目中，华创方舟基于智能监控平台构建了智能运维能力，实现了所有基础设施、服务器、存储、网络、安全设备、系统软件等的一站式监控和自动化运维，升高了因为扩散和低效运维带来的额定老本、晋升了运维效率，并通过可视化大屏实现了对数据中心环境的全方位展现；另一方面，华创方舟以混合云治理平台实现了对AWS、VMware、阿里云、品高云等支流云厂商各类云平台的异构云治理，进行对云和非云资源的对立纳管，实现多云资源调配，具备较强的开放性和可扩展性。丰盛的客户侧落地实践经验。一方面，华创方舟领有丰盛的行业案例积淀，在金融、政府、电信、能源等行业均有落地，可能结合实际疾速深挖不同行业客户的实在需要，从企业业务倒退角度，提出最优解决方案，继续帮忙客户晋升技术能力；另一方面，基于长期的实际，华创方舟造成了标准化的运维交付流程，可能在企业上云过程中提供残缺牢靠的交付反对。良好的云厂商单干根底。华创方舟依靠本身过往的系统集成和经营服务教训，不仅与H3C、ZStack、EasyStack等公有云厂商放弃密切合作，还与腾讯云、阿里云、华为云等私有云厂商建设了稳固的单干关系，凭借与私有云、公有云、混合云以及其余硬件厂商等较强的合作配合，可能对不同云产品的性能造成全面的了解，可能进行产品服务的联结迭代优化。 典型客户：中国邮政储蓄银行、中国进出口银行、国家税务总局北京市税务局、中国电信、中国移动、中国信息通信研究院 4.    入选证书  

点击此处，返回流动现场！

文/云原生 SIG 01 背景随着云原生的蓬勃发展，越来越多的企业在本人的生产或者测试环境应用云原生技术，而容器镜像正是云原生技术中利用的理论运行环境。一个好的容器运行环境即容器镜像会真正关系到利用的体验、演进和保护。那么抉择一个好的容器镜像须要思考哪些方面呢？具体如下： 长期的反对与保护：容器镜像提供的环境是分层的，企业容器利用往往是在一些根底镜像(base image)之上构建本人的利用镜像，而根底镜像提供了利用中所依赖的库、软件包等。对根底镜像上软件包的保护更新、问题修复、新性能反对等，是咱们构建一个好的、牢靠的、稳固的利用镜像的必要条件。平安：企业应用的生产往往是开发人员将本人的利用与第三方利用(包含根底容器镜像)通过构建打包成可部署的制品内容，而后利用到生产环境中，这个过程暗藏着两个平安诉求：须要保障所应用的容器镜像的安全性。须要保障在整个软件生命周期中，软件包的源头以及制品的完整性、可追溯性证实也就成了平安的关键环节。性能/最佳实际：以后很多用户应用的容器镜像都仅仅是提供了通用的应用环境，针对各类场景短少性能优化、短少最佳实际计划，那么是否为用户提供优化的容器镜像、为场景提供最佳实际的容器镜像计划就成为很多用户思考的方面。基于下面的用户诉求，龙蜥云原生容器镜像（Anolis Container Image）应运而生。明天，很快乐地发表龙蜥云原生容器镜像正式公布，同时也构建了局部镜像提供给社区用户进行下载，包含根底 base 镜像、根底语言镜像、根底利用镜像等（下载应用办法见下文）。 02 龙蜥云原生容器镜像龙蜥云原生容器镜像旨在建设一个继续优化的、长期反对和保护的、安全可靠的容器镜像生态，为宽广云原生用户、开发者和搭档提供一个最佳云原生运行环境： 社区保护能力。龙蜥社区基于不同 OS 版本都会保护根底软件 RPM 包，以及根底的语言、利用等软件包，可提供丰盛的 base 镜像，并且会定期进行保护更新等，这些都保障了基于龙蜥软件包构建进去的容器镜像具备残缺的生命周期治理能力。将来在社区会提供上面三类容器镜像能力：Anolis Base Container Image：包含 Anolis 7、Anolis 8、Anolis 23、Alinux 2、Alinux 3 等 （Alinux 即 Alibaba Cloud Linux 的简称，是由阿里云操作系统团队以 Anolis OS 为根底构建的阿里云操作系统发行版。目前阿里云操作系统团队也将其奉献到了龙蜥社区云原生 SIG 的容器镜像生态中）。Language Container Image Base Anolis/Alinux：C++、Java、Python、Nodejs、Go 等。Application Container Image Base Anolis: nginx、postgres、redis、httpd、mongo、mysql 等。平安保障。社区次要有两方面保障，一是从容器镜像软件包起源上，社区会定期对镜像中软件包进行定期 CVE 修复，保障从源头上解决平安能力；二是从容器镜像完整性上，咱们构建过程中会对镜像进行数字签名，这样 Release 的镜像都是带有签名加固，理论下载镜像的用户使用者能够进行验签。而绝对于传统的签名计划，咱们在云原生场景能够反对更加便捷的 Keyless Signatures 模式，能够更加敌对、易用地进行加签和验签。 性能最优。龙蜥社区有丰盛的软件计划，其中 KeenTune 提供 AI 算法和专家知识库智能调优，咱们在一些利用镜像中默认集成了 KeenTune，能够让业务运行在最优的环境中。同时龙蜥云原生容器镜像面向开发者与搭档提供了一站式的开发集成设施，从容器的构建平台到测试平台，再到散发平台等，能够帮忙开发者低门槛奉献容器镜像。开发者只须要在社区代码仓库中提交对应镜像的 Dockerfile，社区基础设施能够实现残缺的容器构建与测试、散发流程，代码仓库见下：https://gitee.com/anolis/dock...。 03 以后停顿与将来布局目前咱们曾经构建了局部的镜像，并能够提供给社区用户进行下载，将来一年咱们会提供更多的高频应用容器镜像，同时在下载的镜像中带有平安数字签名，初步路标如下图所示： ...

作者：珑乘、锕蛮 业务高速倒退，业务敏捷性和稳定性面临挑战波司登国内控股有限公司(简称波司登) 始于1976年，旗下品牌包含“波司登”、“雪中飞”等，波司登羽绒服滞销美国、法国、意大利等72个国家寰球超2亿人次在穿。 作为全国最大的品牌羽绒服生产商，波司登间断26年全国销量当先，在疫情黑天鹅的冲击下，线下销售渠道增长瓶颈，波司登减速推动数智策略。但因为波司登外围业务零碎别离由不同的软件开发商开发建设和保护，架构老旧、以传统单体利用为主，且版本迭代很慢，无奈满足波司登线上业务的高速增长带来的高并发、弹性扩大、敏捷性等更高的要求，为此波司登迫切须要进行外围业务零碎的云原生化革新降级，以撑持业务的高速倒退。 全程贴身服务保障，外围零碎一次性上线胜利在波司登尝试通过本身技术团队进行云原生化革新过程中，第一套云原生化革新的商品经营IMOS零碎上线后零碎在订货期间呈现链路阻塞，对业务造成了重大影响。此外，陆续还有线上平台订单治理OMS零碎和门店收银POS零碎以及用户治理CRM零碎须要同时革新上线，如何最快速度实现三套外围零碎革新和平滑切换上线成为波司登面临的难关。 收到波司登需要后，阿里云服务团队第一工夫赶到波司登现场，具体介绍了阿里云云原生革新计划以及波司登案例，帮忙波司登量身定制云原生革新所需可观测性体系、全链路压测，零碎变更与调优、全链路资源查看等计划、并为波司登建设专属应急保障体系。 在零碎上线前，阿里云服务团队深刻波司登业务场景，欠缺云原生架构下的可观测性和云产品监控，全量利用以及对应业务日志接入ARMS和SLS，显著晋升了对于分布式系统谬误的被动发现和白盒化定位能力。通过PTS产品结合实际业务场景，对11个外围业务场景进行了全链路性能压测和调优，提前发并排除现2个重大危险，联合压测后果和最佳实际对全链路30多个产品以及几百个Pod的资源进行全面巡检和调优，实现Hologres和PostgreSQL等实例容量扩容的同时，通过对200多条SQL的优化，大量慢SQL问题的危险失去了及时收敛。 在零碎上线期间，阿里云服务团队全程驻场，第一工夫响应解决波司登上线的紧急问题，疾速处理了两起突发异样。一是数据库连接池没有管制好，Hologres局部work节点的并发连接数被打满，导致数据迁徙失败和利用启动异样，通过现场疾速定位连接数暴涨的利用，并优化Hologres侧的闲暇链接开释参数帮忙波司登疾速躲避问题。二是PostgreSQL数据库的SQL诊断优化性能触发index_advisor插件的BUG导致对应的PostgreSQL实例异样重启，紧急叫停波司登应用SQL诊断优化性能，并优先确保数据库稳固确保零碎失常。 通过波司登技术团队和阿里云服务团队的的集中技术攻坚，圆满完成OMS、POS、CRM三套外围零碎的容器化和分布式革新，且一次性上线割接胜利，放慢推动了数智化策略的过程。 绘就微服务治理大图，完满撑持双11业务洪峰零碎上线之后利用变更变的加频繁，简直每天都有发版，而且在白天变更时常常会导致前端利用异样，重大影响应用体验，使得变更只能在晚间进行这样极大的减少了研发人员的累赘也违反了麻利开发的初衷。零碎上线之后性能不现实，在并发不大的状况下次要利用的POD数量达到20个以上，须要靠堆资源来晋升零碎的解决能力，而且往年是云原生革新之后的第一个年，离双十一大促只剩下短短的三个月，如何疾速实现服务治理革新，进步零碎零碎的稳定性和性能，保障系统可能顺利扛过双十一流量洪峰，成为了波司登技术人员的重要考量。 理解到波司登的痛点之后，阿里云服务团队依据波司登业务特点联合阿里云微服务治理和稳定性治理体系的最佳实际以及波司登案例，帮忙波司登制订了利用无损公布，灰度公布，容量布局，限流降级等计划，并与波司登一道实现计划的落地。 利用无损公布可无效防止利用公布时前端异样的问题，晋升用户的应用体验，让零碎在变更时更加顺滑。 为了放慢落地并缩小工作量，充分利用ACK和MSE的能力，通过配置preStop和MSE无损下线实现利用优雅退出，通过配置健康检查并开启MSE上线流量预热性能爱护利用平安启动，无效躲避利用公布所呈现的流量损失。联合波司登现状，为波司登定制云效流水线、ACK和MSE微服务治理能力相结合的利用公布计划，在利用公布的过程中即可实现无损高低线，无需减少额定操作，给技术人员减负。 灰度公布在利用上线之后呈现重大异样时可能及时回滚疾速切流，能够小流量试错新版本。 利用MSE提供Agent接入的形式，基于HTTP的Header中的某个字段给流量染色，利用Kubernetes的申明式部署对利用版本打入灰度标识，这样就能够限度只有被染过色的流量才会进入打上了灰度标识的版本，实现基于逻辑隔离机制的全链路灰度能力，从而实现新版本公布后业务小规模的流量验证，一旦发现新版本存在任何问题，能够及时回滚，把对业务的影响降至最低。 全链路压测是发现零碎瓶颈确定零碎容量的最佳伎俩 。 波司登技术团队和阿里云服务团队针对云上5套外围零碎梳理出50余个压测场景，设计全链路压测计划、数据模型与压测脚本。通过Hologres SQL执行优化、表分区键以及shard优化、索引调整，利用日志异步化，JVM参数优化，代码优化，Redis缓存，MQ架构革新等十几项调优伎俩，在进步零碎稳定性的同时零碎整体性能进步50倍以上，云上资源利用率也显著进步，整体资源费用升高5%以上。 限流降级能力能够为零碎装置一个牢靠的保险绳。 因为慢SQL较多且工夫紧迫来不及优化，为了防止重大的慢SQL产生后拖垮整个数据库，对线上业务产生阻断性的危险，波司登应用了MSE的数据库治理能力，基于压测后果评估流量峰值，配置SQL限流规定，在数据库流量过大时有选择性的让SQL进行期待或者疾速失败，把不确定的流量变为确定性的流量，保障数据库的稳固从而确保整个业务的稳固。 波司登通过阿里云AMS服务，减速各种云原生计划的落地，用一年工夫实现外围零碎云原生化革新，极大的晋升了零碎的稳定性和性能，订单解决能力最高达到50万单每小时，顺利扛过双十一流量洪峰，也为线上业务的简单与多变性提供了强有力的技术保障，线上零售额在疫情冲击下逆势同比增长66%以上 。 在满是「不确定性」的后疫情时代，线上渠道通过数智化降级胜利实现高质量增长。 双十一的顺利度过以及线上业务的增长使波司登实现了自证预言，走出了一条自住可控的数字化改革之路，将来波司登将持续拥抱云计算，通过更先进、更高效的技术，更数字化的经营形式，激发翻新生机，与各行各业的时代改革者独特成长，持续引领行业潮流。 采纳的阿里云服务阿里云可运维性咨询服务 https://www.aliyun.com/servic... 运维服务 https://www.aliyun.com/servic... 云管平台服务 https://www.aliyun.com/servic...

随着近几年云原生生态的一直壮大，泛滥企业纷纷发展了用云上云的工作，学习和理解云原生及容器技术对于古代工程师是必不可少的，本文次要为大家介绍云原生及其在容器方面的利用。 1、对于云原生 1.1 什么是云原生 云原生技术有利于各组织在私有云、公有云和混合云等新型动静环境中，构建和运行可弹性扩大的利用。云原生的代表技术包含容器、服务网格、微服务、不可变基础设施和申明式 API。 这些技术可能构建容错性好、易于治理和便于察看的松耦合零碎。联合牢靠的自动化伎俩，云原生技术使工程师可能轻松地对系统作出频繁和可预测的重大变更。 云原生计算基金会（CNCF）致力于培养和保护一个厂商中立的开源生态系统，来推广云原生技术。咱们通过将最前沿的模式民主化，让这些翻新为公众所用。 1.2 云原生的设计哲学 云原生零碎的设计理念如下： 面向分布式设计（Distribution）：容器、微服务、API 驱动的开发。面向配置设计（Configuration）：一个镜像，多个环境配置。面向韧性设计（Resistancy）：故障容忍和自愈。面向弹性设计（Elasticity）：弹性扩大和对环境变动（负载）做出响应。面向交付设计（Delivery）：主动拉起，缩短交付工夫。面向性能设计（Performance）：响应式，并发和资源高效利用。面向自动化设计（Automation）：自动化的 DevOps。面向诊断性设计（Diagnosability）：集群级别的日志、metric 和追踪。面向安全性设计（Security）：平安端点、API Gateway、端到端加密。1.3 云原生应用程序 微服务 作为单个实体进行治理和部署的应用程序通常称为单体利用。最后开发应用程序时，单体有很多益处。它们更易于了解，并容许您在不影响其余服务的状况下更改次要性能。 随着应用程序复杂性的增长，单体利用的好处逐步缩小。它们变得更难了解，而且失去了敏捷性，因为工程师很难推断和批改代码。 凑合复杂性的最好办法之一是将明确定义的性能分成更小的服务，并让每个服务独立迭代。 平安及扩大 遥测和度量规范用于解决以下问题： 应用程序每分钟收到多少申请？有没有谬误？什么是应用程序提早？订购须要多长时间？弹性扩大弹性是基础设施的责任，但云原生应用程序也须要承当局部工作，利用横纵向扩大。 申明式 因为云原生应用程序被设计为在云环境中运行，所以它们与基础设施以及相干依赖应用程序的交互方式不同于传统应用程序。在云原生应用程序中，与任何事物的通信都须要通过网络来进行。很多时候，网络通信是通过 RESTful HTTP 调用实现的，简化应用程序并使其更强壮。 2、云原生应用程序 2.1 Kubernetes 与云原生的关系 2.2 Kubernetes 架构 Kubernetes 次要由以下几个外围组件组成： etcd 保留了整个集群的状态。apiserver 提供了资源操作的惟一入口，并提供认证、受权、访问控制、API 注册和发现等机制。controller manager 负责保护集群的状态，比方故障检测、主动扩大、滚动更新等。scheduler 负责资源的调度，依照预约的调度策略将 Pod 调度到相应的机器上。kubelet 负责保护容器的生命周期，同时也负责 Volume（CSI）和网络（CNI）的治理。Container runtime 负责镜像治理以及 Pod 和容器的真正运行（CRI）。kube-proxy 负责为 Service 提供 cluster 外部的服务发现和负载平衡。2.3 容器设计模式 统信容器云治理平台-有雀（统信容器云平台解决方案） 以 CRI-O、Kubernetes、OKD 为根底，以利用为核心的企业级容器云 PaaS 平台，提供主动伸缩、配置管理、资源管理、主动运维等性能，实现对容器化利用的全生命周期治理。 ...

如果用两个词来总结 2022 年云原生的倒退态势，您会有哪些评估？ ——凋敝和普惠。“凋敝”代表以后云原生的技术和产品蓬勃发展；“普惠”代表云原生技术从互联网走向金融、批发、政企等行业，普惠千行百业构建丰盛利用。（阿里云智能云原生利用平台产品负责人李国强） 2022 年，云原生技术日趋成熟，随同容器、Serverless、微服务等技术疾速倒退，已逐渐构建出凋敝的技术体系。现在云原生凭借降本增效、进步继续交付能力、易于开发等劣势，正在一直激活利用构建范式，引起企业零碎架构、生产方式、商业模式等产生改革，毋庸置疑，云原生已成为企业数字化转型的最短门路。 那么，2022 年云原生畛域有哪些新进展？将来咱们须要关注云原生哪些倒退？ 对此，在第三届云原生实战峰会期间，阿里云智能云原生利用平台产品负责人李国强承受媒体采访，为咱们解读云原生的最新倒退与阿里云在云原生畛域的最新实际。 云原生热门技术发展趋势容器容器作为云原生的代表技术，正在一直重塑云的应用形式。据 Gartner 公布的《寰球容器治理预测》中指出，在减速的数字化转型驱动下，更多企业采纳基于云的容器治理服务，在 2025 年85% 的大型企业将更多地应用容器治理。 往年容器技术仍旧倒退强劲，李国强察看到容器在云原生 FinOps、云原生大数据、混部、分布式云等领有良好发展趋势。 第一个发展趋势是越来越多的新型负载类型容器化。 往年在游戏畛域、AI 大数据畛域的容器化愈发显著，企业将外围负载运行在容器上，以进行对立的资源调度，帮忙企业更好地利用弹性。 在混部上，阿里云往年开源了云原生混部我的项目 Koordinator，它在 K8s 上提供了对编排调度能力的加强，反对针对不同类型的工作负载，资源效率晋升100%，实现差异化 SLO 保障，让低优先级的工作对提早敏感型工作的影响< 5% 。 第二个发展趋势是分布式云。 企业可基于容器分布式云的形式，来构建线上线下联结的混合云计划，既兼顾了线下利旧兼容，也兼顾到上云效率的晋升。2021年 9 月，阿里云容器服务全面降级为 ACK Anywhere，让企业在任何用云的中央都能取得统一的容器基础设施能力。 阿里云通过分布式云容器平台 ACK One 和边缘容器服务 ACK@Edge，以笼罩更多企业用云的场景。通过 ACK One 帮忙企业构建线上线下对立计划，便捷对立治理利用。可能反对数据中心弹性到公共云，公共云能力下沉到客户数据中心等丰盛场景。出名主动驾驶科技公司元戎启行基于 ACK@Edge 将主动驾驶车辆通过边缘容器进行治理，疾速笼罩到泛滥智能车载设施，无效升高治理老本，运维效率晋升 60% 以上。 阿里云容器服务产品家族曾经成为企业的云原生操作系统。基于阿里云容器服务，阿里巴巴实现了100%业务云原生上云。 另外，往年云原生 FinOps 倒退良好。后疫情时代，如何通过云原生技术帮忙企业更好地降本增效，成为摆在云厂商背后的新思考题。阿里云联合业财一体化实际和 FinOps 理念，推出 ACK FinOps 套件，通过数字化伎俩和智能化办法，帮忙企业实现老本可视化、可优化、可管制。 在服务网格畛域，2022 年 4 月，谷歌提议将 Istio 捐献给 CNCF，9月 Istio 正式成为 CNCF 孵化我的项目。更加凋谢的 Istio 社区治理模式，将会失去更多企业和开发者的反对，推动更多的翻新和技术成熟。2022 年，Istio 发表引入全新的无 sidecar 数据立体模式 Ambient Mesh，通过将数据立体性能从 sidecar 容器转移到网络基础设施来解决常见的操作挑战，能够说Istio 的倒退将来可期。阿里云服务网格 ASM 产品，是业内首个全托管 Istio 兼容的服务网格产品，往年，ASM产品取得了首批通过可信云服务网格性能测评先进级认证、排名第一、全项满分。 ...

Rainbond 是一个云原生利用治理平台，应用简略，不须要懂容器、Kubernetes 和底层简单技术，反对治理多个 Kubernetes 集群，和治理企业应用全生命周期。次要性能包含利用开发环境、利用市场、微服务架构、利用交付、利用运维、利用级多云治理等。 龙蜥云原生套件 Anolis Cloud Native Suite（ACNS）是由龙蜥社区云原生 SIG （Special Interest Group）推出的基于 Kubernetes 发行版本为根底而集成的套件能力，能够提供一键式部署、开箱即用，以及丰盛的云原生根底能力，次要包含： Kubernetes 基于 ACK-D , 作为开源的发行版以及 ACK 的上游，ACK-D 通过大规模的生产的验证，保障了组件的稳定性、可靠性；同时在网络插件上反对 Calico、Hybirdnet，可同时反对网络的 Overlay 与 Underlay，除了 Overlay 满足容器网络的同时，能够部署成 Underlay 模式是使得 POD IP 间接被内部拜访，同时提供比拟好的性能；存储插件上反对本地存储 Open-Local、利用 LVM 提供了灵便的本地磁盘能力，以及共享存储 Minio。Runtime 同时反对 runC、runD 和 Kata，以及 runE (将来版本)，满足各种对共享、隔离以及平安场景下应用。镜像治理上提供了开箱即用的 Nydus + Dragonfly，应用 Nydus 能够在集群外部使镜像按需加载，能够大大提高集群的动静弹性的能力；Dragonfly 则是提供镜像在集群的 P2P 的能力，这两个能力次要面向 Kubernetes 集群提供 Serverless 服务，以及动静弹性的场景，AI 大数据镜像数据集群内散发的场景等。部署 ACNS 与 Rainbond服务器信息： 操作系统IPAnolis OS 8.6 ANCK172.31.98.243Anolis OS 8.6 ANCK172.31.98.242部署龙蜥 ACNS在任意节点上下载 sealer 可执行文件： ...

Hello 大家好，明天的分享大抵分为三个局部：云原生的倒退历程，云原生的平安治理，以及平安产品介绍。对于倒退历程这一部分，次要会从云原生历史的角度登程进行讲述，以及从历史中咱们学习到了什么。第二局部平安治理，次要就目前的局势，咱们应该怎么做好平安治理这方面动手。这两大点都是从一个宏观的视角登程，在之后的云原生平安公开课中会更多从宏观角度去剖析，包含：问脉底层的 SDK 到底怎么实现；咱们做一些比拟难的技术挑战时，是怎么解决问题的······大家能够关注一下之后的课程。 那么咱们来到第一局部“云原生的倒退历程”，说到云原生，大家会想到什么货色呢？有的人可能会想到 K8s ，有的人可能会想到 Docker。但其实最早的都不是这两个货色。最早是来源于 Linux 内核所提供的两个个性：一个叫 Cgroup 、一个叫 Namespace。这是 Linux 内核很早就提供了的性能：Cgroup 反对对于过程资源的应用限度，Namespace 提供了对于过程资源的隔离限度。在 Kernel 层咱们发现 Cgroup 做了限度，比方你想占用多少 CPU 资源、内存资源，都是由 Cgroup 决定的。而 Cgroup 上是由 Namespace 限度的，对过程信息、网络信息等不同力度等资源做了限度。这两个外围的能力，就是咱们所谓的容器化，是最根底的基石。 2009年的时候就诞生了一个我的项目，叫 Linux Container，俗称 LXC。这个我的项目就是最早的沙盒化利用，它容许使用者以一个虚拟化的形式去运行本人的利用。但有的同学可能会比拟纳闷，“为什么2009年就有 LXC 了，可是我感觉云原生是最近几年才火起来的。”我感觉这是一个很好的问题，为什么 LXC 在2009年的时候始终没有失去宽泛的推广或利用呢？起因很简略，因为 LXC 它只用了 Cgroup 和 Namespace ，就导致了我在一台机器上用 LXC 跑起来了某个 application，在另外一台机器上可能跑不起来了。因为一个 application 可能会存在一些 libc 的依赖，在动静编译的状况下必须跟另外一台机器保持一致能力用这个 LXC。所以 LXC 在2009年推出来之后没有实现大范畴推广。 直到2014年 Docker 的横空出世，它在 Github 下面开源 ，扭转了云原生畛域的倒退历程。 Docker 实质上和过后的其余容器化我的项目没有特地大的区别，然而却做了一个十分奇妙的微翻新，那就是将操作系统的文件系统也打包到利用当中。这个微翻新使得所有基于 Docker 打包的 application，真正做到了 build once, run everywhere。 然而 Docker 这个我的项目，即便播种了大量的社区关注，仍然被外界认为仅仅只是玩具。起因在于，Docker 自身并没有方法帮忙开发者实现大规模场景下的利用部署。 ...

Loggie萌芽于网易严选业务的理论需要，成长于严选与数帆的长期共建，继续倒退于网易数帆与网易传媒、中国工商银行的严密合作。宽泛的生态，使得我的项目可能基于业务需要不断完善、成熟。目前曾经开源：https://github.com/loggie-io/...1. 背景严选日志平台初期，应用filebeat采集云内日志，用flume采集云外日志。期间经验了一段苦楚的运维排障期间，被问的最多的几个问题： 某条日志为何没有采集？某条日志为何反复采集了？是否将漏采集的那条日志补采集？某个日志文件为何没有采集？某个日志文件的采集速度怎么这么慢（提早超过30s）？服务从新公布后，之前的日志怎么没有了？…而且同时保护了2套日志采集agent，保护老本高。不论是filebeat还是flume都存在以下几点重大的问题： 采集性能低： 大促工夫，局部节点的日志打印速度超过100MB/s，然而filebeat的采集性能下限只有80MB/s左右，flume更差一点。资源占用高： filebeat单节点采集文件超过100个，cpu使用率超800%；flume空跑内存就得占用200MB+，大促期间不得不开启限流以防止影响外围业务零碎。扩展性差： fliebeat简单的架构以及单output设计无奈满足多变的业务需要。同时也调研其余开源的日志采集agent，或多或少都存在上述问题，且都没有足够的可观测性和运维伎俩（工具）来帮忙运维排障，更不用说残缺的日志解决方案。 因而咱们走向了自研的路线。 loggie在2022年初已开源：https://github.com/loggie-io/... 欢送大家应用，与社区一起成长！ 2. 架构设计 基于golang，借鉴经典生产者-消费者模式的微内核设计。一个pipeline只有source、queue、sink、interceptor4个组件概念，且interceptor也不是必须的。pipeline反对配置热加载，组件热插拔，pipeline之间强隔离，避免相互影响。 2.1 pipeline设计 pipeline的设计初衷次要是为了隔离性。之前运维遇到的一个重大问题：云内应用filebeat采集多个业务的多个日志文件，然而其中一个日志文件的采集配置的topic被误删，导致发送到kafka失败而阻塞，进而导致整个物理机几点的所有日志都阻塞。因而咱们须要一种泳道隔离伎俩，来隔离不必业务、不同优先级的日志，防止相互影响。 2.1.1 易扩大 pipeline的简洁设计使得咱们的扩大极其便捷。在概念上，一个pipeline只有4种组件：source、queue、sink、interceptor，而且interceptor不是必须的。越少的概念，扩大者者就有越少的学习老本。并且，为了进一步提高扩展性，pipeline中的所有组件都形象为component，所有的组件领有统一的生命周期与实现形式。不仅不便了扩大，也不便了loggie对组件的对立治理。 2.1.2 隔离性与reload基于pipeline，咱们实现了配置热更新，组件热加载。reloader与discovery组件能够基于K8S CRD、http监听等形式（预留接口，能够对接例如zookeeper、consul、apollo等配置核心），以pipeline维度进行reload。因而，在保障了reload能力的同时依然满足了pipeline隔离的目标。 2.1.3 性能加强：interceptorinterceptor在loggie中是一个可选的组件，却在loggie中扮演着十分重要的角色。loggie中绝大多数的加强性能都是基于interceptor实现的，例如限流、背压、日志切分、encode&decode、字符编码、结构化等。用户能够依据理论状况抉择对应的interceptor晋升loggie的适应能力。 残缺内置interceptor：https://loggie-io.github.io/d...3. 日志采集对于一个日志采集agent来说，通常须要重点关怀以下3点的设计与实现： 高效采集： 高效指的是高性能的同时低能耗，即如何采集的快服务器资源占用有小。公平性： 例如写入快的文件不能影响写入慢的文件采集、最近更新的文件不能影响之前更新的文件的采集，删除文件的正当采集与开释。可靠性： 日志不失落。包含过程解体重启、服务公布&迁徙&容器漂移、上游阻塞等状况。3.1 高效采集日志采集，咱们关怀的是这么几个问题： 如何及时发现新创建的文件？如何及时发现最新的写入？如何疾速读取文件？这其实是两方面的问题： 事件感知： 及时发现文件事件。例如文件新建、删除、写入。文件读取： 高效读取文件内容。尽可能快的读取文件内容，缩小磁盘io，cpu可控。3.1.1 事件感知如何做到文件事件感知呢？业界有两种做法： 定时轮询： 定时查看目录文件状态。OS事件告诉： 注册OS文件事件，由OS告诉具体的文件事件。两种形式各有利弊： 定时轮询： 长处：实现简略，安全可靠。毛病：轮询的工夫距离不太好确定，距离太短耗cpu，距离太长发现事件就太慢。OS事件告诉： 长处：可能第一工夫发现文件事件毛病： 实现老本高（不同OS的实现形式不同，须要适配）。存在bug：例如在最罕用的linux零碎中存在一些bug（https://man7.org/linux/man-pa...） ，其中影响最大的几点：告诉失落、注册数量有下限、文件改名事件无奈告诉改名后的文件名。应用有限度：例如无奈对通过 NFS（Network File System） 挂载的网盘&云盘失效，无奈对 FUSE（filesystem in userspace） 失效等。因而loggie联合两者独特实现了一个安全可靠，却又能及时感知事件的计划： 同时启用定时轮询和OS告诉，应用OS告诉而后搭配一个绝对较长（loggie默认为10s）的定时轮询，将两者发现的事件进行合并以缩小反复解决，这样就能同时兼具两者的长处。 然而理论测试下来，咱们发现了cpu占用回升，剖析起因： OS事件过多： 特地是写文件的时候，对应有两个os事件（chmod+write），一旦文件写得频繁，os的事件将十分多，loggie疲于解决零碎事件。所以，咱们从新剖析，什么样的事件是咱们真正关怀并须要及时感知的呢？ 文件写事件？当咱们无奈及时发现文件写事件，会有什么影响呢？有两种状况： 如果这个文件正处于采集中（持有文件句柄），那这个文件的写事件没有影响。因为正在读这个文件，后续的写入天经地义能被读到。如果这个文件处于不沉闷状态（即文件曾经读取到了开端，并且肯定工夫内没有发现新内容，甚至文件的文件句柄被开释了），这个状况咱们心愿能及时感知文件的写事件以不便咱们及时采集最新的写入内容。因而，重要的是“不沉闷”文件的写事件。 文件新建（滚动）事件？当咱们没有及时发现新建事件，会有什么影响呢？ 首条日志写工夫到发现工夫之间的日志将会提早采集（对于loggie来说，最大提早在10s左右，因为默认的轮询工夫距离为10s），然而一旦感知到事件，采集能够很快追上进度。因而新建事件不那么重要。 文件删除事件？当咱们没有及时发现删除事件，会有什么影响呢？有3种场景： 文件被删除后，心愿未采集实现的文件持续采集：这种状况，删除事件早退不总要。因为当文件还未采集完，及时发现的删除事件没有意义；当文件采集完后，未及时发现的删除事件仅影响文件句柄开释提早。文件被删除后，心愿尽快开释磁盘空间：仅仅导致文件句柄开释提早，即磁盘空间开释提早（大略在10s左右）。文件被删除后，心愿未采集完的文件给予肯定的容忍工夫再开释磁盘空间：这种状况近会导致文件最终开释提早的工夫=容忍工夫+事件早退工夫。因而，删除事件不重要。 文件改名事件？同上，不重要。然而如何得悉文件改名以及改成什么名的确个值得好好思考的问题！（暂不开展）所以，真正重要的是不沉闷的文件写事件。因而咱们的架构调整为： 成绩： 节俭大量不必要的目录和文件的零碎事件注册和监听以及对应监听产生的大量事件，进一步升高了CPU的损耗。事件处理这一层去掉了事件合并这一步，因为所有事件都是无效事件，进一步升高了CPU的损耗。3.1.2 文件读取文件读的快的准则： ...

软件架构倒退至今，经验了从单体架构、互联网分布式架构、到当初的 Serverless 架构。2022 年，云原生技术以势不可挡的之势，大规模在不同行业落地，并仍然霸占技术话题热度榜首。2023 年随着企业业务的疾速复原，对于云的应用将会达到新的程度，如何用好云也将成为企业角力的要害。 本次对话，心愿通过阿里云云原生利用平台负责人丁宇（叔同）的察看和了解，帮忙更多的企业决策者厘清技术价值，提供借鉴参考。 01 云原生畛域 2022 年有哪些印象粗浅的事件？叔同：有两个方面我的感触比拟深，一个是开源的倒退，一个是利用的构建。我解释下，过来几年阿里云有很多技术进行了开源，尤其是这两年开源的速度变得更快了。很大水平上受到了容器与 K8s 倒退的推动。目前，容器和 K8s 进入了一个安稳推动和遍及的阶段。然而在这之上还有大量的畛域须要从新定义，开源在肯定水平上是逐步帮忙各个领域建设规范。 举两个例子，一个是往年 3 月 Knative 进入 CNCF 孵化，5 月 OpenFunction 进入 CNCF 孵化，以及 9 月 Serverless Devs 进入 CNCF 孵化。这三个典型的我的项目意味着新的趋势正在到来。像函数计算、事件驱动这样的架构状态，逐步有了开源体系的撑持。 从开发者的视角，大家的技术认知经常是通过开源我的项目去理解一个新的畛域，当这些架构师感觉开源我的项目不错，就会推动在企业场景中利用，缓缓地造成了宽泛落地的趋势。所以，通过大量的函数计算、事件驱动类的我的项目进入 CNCF 孵化，也会给行业带来一些正向的、陈腐的技术血液。 从利用侧，我举两个例子来阐明。一个是阿里外部的案例，从 2021 年到 2022 年这两年工夫里，阿里云实现了外围产品的云原生化，这是业界惟一做到的云厂商。一家企业要做容器化，对于新利用来说绝对容易一些，而老利用往往会面临很多挑战，须要工夫去革新。而对于阿里云这样的平台，能把外围产品容器化并顺利完成，是一个里程碑。 从内部案例，阿里云撑持了云上大型体育赛事，实现外围零碎百分百上云，以云原生的形式去应用云，可能在云上疾速构建利用。这也向业界开释了一个信号，无论是历久弥新的零碎，还是海量拜访的零碎，或者是不同周期、状态不同的零碎，都能够实现云原生化。 从云服务商的视角，2022 年 11 月云栖大会上，阿里云发表外围产品全面 Serverless 化，咱们认为 Serverless 将成为云原生下一阶段重要趋势。 从函数计算、事件驱动到容器化为根底，最初会造成对立的软件架构的方向，缓缓地业界上云用云的蓝图逐步残缺，指引企业如何演进利用架构，云应该如何倒退，研发范式如何降级等，所有这些变动的本源都是云原生和 Serverless 驱动的。 02 为什么往年是 Serverless 暴发的元年？叔同：咱们从一家企业的 IT 诉求来看，如果一家企业正处于业务高速增长阶段，没有太多资金压力，那么降本往往不是最高的诉求，然而提效会十分重要。因为要撑持业务的疾速倒退，须要非常灵活麻利的架构，各种状态的业务可能疾速试错；如果说一家企业在业务倒退上遇到了压力，须要将精力投入到降本中，但降本的背地也须要老本，无论是工夫老本还是人力老本。 企业在不同的倒退阶段会有不同的取舍点，也会对技术团队提出不同的诉求。然而业界其实短少了一个普适化、能够解决大家降本提效诉求的技术。 上云可能解决过来一代的技术问题，在过来的十年里，行业逐步造成了上云的思路转变，然而在下一个阶段，云上利用构建又面临新的挑战，只管业内有十分多开源我的项目，能够应用很多云产品，然而没有一套通用的规范和技术，购买服务器、抉择规格、部署服务、定制利用及运维等，都须要消耗研发和架构师大量的精力。 云服务自身其实也在发生变化，从提供资源到提供能力。云的弹性能力很强，然而如果说云上的服务没有弹性，云上的利用没有弹性，就很难施展出云的价值。 从企业的视角也是如此，如果 A 企业技术水平较高，有 2000 个工程师，的确能够将利用、服务保护得很好；然而国内大部分的企业很难具备这个工程师的体量，尤其是咱们心愿越来越多的守业公司能够尽快将外围放在业务倒退上，而不是根底资源、技术层面的工作，越来越多的企业心愿云来承当这样的角色，具备标准化、开箱即用的能力。对于企业而言，取用能力即可。 所以，随着容器成为新的云计算基础设施，帮忙企业标准化地享受到 Serverless 服务。这就是从需要侧到供应侧带来的降本提效，并且是企业和云服务商一拍即合、自驱演进的方向。 ...

作者：余凯 本系列文章由余凯执笔创作，联结作者：阿里云容器服务 谢石 对本文亦有奉献 前言近几年，企业基础设施云原生化的趋势越来越强烈，从最开始的 IaaS 化到当初的微服务化，客户的颗粒度精细化和可观测性的需要更加强烈。容器网络为了满足客户更高性能和更高的密度，也始终在高速的倒退和演进中，这必然对客户对云原生网络的可观测性带来了极高的门槛和挑战。为了进步云原生网络的可观测性，同时便于客户和前后线同学减少对业务链路的可读性，ACK 产研和AES联结共建，合作开发 ack net-exporter 和云原生网络数据面可观测性系列，帮忙客户和前后线同学理解云原生网络架构体系，简化对云原生网络的可观测性的门槛，优化客户运维和售后同学解决疑难问题的体验 ，进步云原生网络的链路的稳定性。 鸟瞰容器网络，整个容器网络能够分为三个局部：Pod 网段，Service 网段和 Node 网段。这三个网络要实现互联互通和访问控制，那么实现的技术原理是什么？整个链路又是什么，限度又是什么呢？Flannel， Terway有啥区别？不同模式下网络性能如何？这些，须要客户在下搭建容器之前，就要根据本人的业务场景进行抉择，而搭建结束后，相干的架构又是无奈转变，所以客户须要对每种架构特点要有充沛理解。比方下图是个简图，Pod 网络既要实现同一个 ECS 的 Pod 间的网络互通和管制，又要实现不同 ECS  Pod 间的拜访， Pod 拜访 SVC 的后端可能在同一个 ECS 也可能是其余 ECS，这些在不同模式下，数据链转发模式是不同的，从业务侧体现后果也是不一样的。 本文是[全景分析容器网络数据链路]第二局部，次要介绍 Kubernetes Terway ENI 模式下，数据面链路的转转发链路，一是通过理解不同场景下的数据面转发链路，从而探知客户在不同的场景下拜访后果体现的起因，帮忙客户进一步优化业务架构；另一方面，通过深刻理解转发链路，从而在遇到容器网络抖动时候，客户运维以及阿里云同学能够晓得在哪些链路点进行部署观测手动，从而进一步定界问题方向和起因。 系列一： 全景分析阿里云容器网络数据链路（一）—— Flannel 系列三： 全景分析阿里云容器网络数据链路（三）—— Terway ENIIP 系列四： 全景分析阿里云容器网络数据链路（四）—— Terway IPVLAN+EBPF 系列五： 全景分析阿里云容器网络数据链路（五）—— Terway ENI-Trunking 系列六： 全景分析阿里云容器网络数据链路（六）—— ASM Istio Terway ENI 模式架构设计Terway  ENI 模式下，ENI 的网络都是和 VPC 同样的网段，ENI 网络就是从 Aliyun 的 VPC 网络中创立和绑定一个弹性网卡 [ 1] 到 ECS 节点上， 而后 Pod 利用这个弹性网卡和别的网络互通，这里须要关注的是弹性网卡的数量是有限度的，具体的依据实例类型有不同的配额 [ 2] 。 ...

2021年8月，阿里云联结 Linux 基金会公布云原生人才培养打算2.0，协同开源生态力量，为云原生畛域提供更具专业性的定向人才培养形式，帮忙云原生时代的开发者更好地享受云红利，发明新价值。阿里云开发者社区联结云原生技术团队，面向对云原生感兴趣的开发者、企业客户、学生提供训练营专项培训，蕴含技术课程、企业案例解读、产品应用教学，从学到用一站式服务，让用户会用云、用好云。 明天在云原生、大数据时代，音讯队列未然成为各行各业数字化转型的刚需根底技术。在利用架构场景中，业务利用进行云原生架构革新时，不论是微服务还是 Serverless，都须要基于音讯的事件驱动来进步业务麻利度、零碎韧性和研发效率；在数据架构场景中，随着 IoT、实时数据的利用遍及，音讯队列成为越来越多 IoT 数据、实时数据的流量入口，在实时数据架构中承当数据接入、数据存储、数据散发、实时剖析等作用，是 IoT、实时数据架构最重要的基础设施之一。 在过来的几个月里，开发者社区联结阿里云音讯产品团队开设了 RocketMQ 训练营，在极短时间内有上万名开发者报名学习。 往年12月，开发者社区与阿里云音讯产品团队再次联结出品音讯产品全家桶训练营，本次训练营笼罩了 RocketMQ、Kafka、RabbitMQ、MNS、EventBridge 多种音讯产品及接入场景，10+音讯团队专家授课，帮忙开发者在不同的业务场景用好消息。 点击此处，立刻报名加入

近日，在2022 T-EDGE寰球翻新大会暨钛媒体十年致敬盛典上，2022 EDGE AWARDS企业榜正式公布，灵雀云凭借云原生畛域的杰出体现，入选「翻新场景50」年度最佳场景实际榜单。 2022 EDGE AWARDS评比是兼具行业权威性和敏锐洞察力的翻新大奖，邀请权威行业专家、王牌分析师、业余投资机构、用户代表独特评审，综合专业性、影响力、创新性三大维度，历时超两个月，全面打造年度最强翻新企业名单。  其中，「翻新场景50」奖项颁给在过往一年中入选“翻新场景50”的数字化厂商，联合ITvalue社区近百位CTO的打分，在泛滥重要细分畛域评出TOP50，腾讯云、灵雀云、飞书、安全银行等企业最终上榜。 作为云原生场景的惟一获奖厂商，灵雀云斩获了本次「翻新场景50」的【最佳云原生场景实际】奖项。上面特将灵雀云的入选实例分享给大家，心愿可能给大家带来启发。 此次的获奖实例以灵雀云全栈云原生开放平台ACP为根底，笼罩企业应用的全生命周期，用户能够在任何云上轻松构建一个开箱即用、全面反对微服务架构和DevOps的云原生平台，仅需简略操作就能疾速应用ACP的弱小性能，减速实现外围利用现代化、开发运维全流程服务化、基础设施平台化。 灵雀云ACP可服务于不同规模的企业、不同的数字化业务场景，反对治理各种复杂度的基础设施环境，让资源配置更好地适应业务利用的理论需要，从而改良基础设施的敏捷性、自动化、效率和老本优化，以平台化能力疾速赋能企业数字化转型，驱动业务翻新增长。 将来，灵雀云也将持续以先进的云原生技术和丰盛的落地实践经验，助力更多企业减速数字化转型，解锁更多数字化翻新场景！

前言监控域名和 URL 是可察看性的一个重要方面，次要用于诊断可用性问题。接下来会具体介绍如何应用 Blackbox Exporter 和 Prometheus 在 Kubernetes 中实现 URL 监控。 Blackbox Exporter 简介Blackbox Exporter 是 Prometheus 的一个可选组件，像其余 Exporter 一样， 次要用于将监控数据转换为 Prometheus 可了解的指标格局，即 Prometheus exposition format。 Endpoint 监控Endpoint 监控是指监控外部和内部 Endpoint（HTTP/S、DNS、TCP、ICMP 和 grpc）的各种参数，包含 HTTP 响应工夫、DNS 查问提早、SSL 证书过期信息、TLS 版本等等。 在 Kubernetes 中，不仅仅是内部 Endpoint 须要被监控，外部 Endpoint 也须要被监控响应工夫和其余参数。这些指标是基础设施的一个重要局部，以确保服务的连续性、可用性和合乎一些平安认证。 白盒（WhiteBox）与黑盒（Blackbox）监控白盒监控是指对系统外部的监控，包含利用 logging、handlers、tracing 和 metrics。与之绝对，黑盒监控次要从内部发动探测，探测影响用户的行为，如服务器停机、页面不工作或网站性能降落。 Blackbox ExporterBlackbox Exporter 用于探测 HTTPS、HTTP、TCP、DNS、ICMP 和 grpc 等 Endpoint。在你定义 Endpoint 后，Blackbox Exporter 会生成指标，能够应用 Grafana 等工具进行可视化。Blackbox Exporter 最重要的性能之一是测量 Endpoint 的可用性。 下图显示了 Blackbox Exporter 监控一个 Endpoint 的流程： ...

12月14日，云原生本地存储开源我的项目 Carina 通过了寰球顶级开源基金会 CNCF 技术监督委员会（TOC）的评定，正式成为 CNCF 沙箱级我的项目（Sandbox Projects）。Carina是由博云于2021年10月主导发动的云原生本地存储开源我的项目，旨在为云原生环境中的有状态利用提供高性能、免运维的本地存储解决方案，具备存储卷生命周期治理、本地设施治理、智能调度等能力。Carina 是有状态利用而生的本地存储计划，已在多个金融机构的生产环境中稳固运行多年。 Sandbox 是 CNCF 创立的旨在为开源我的项目提供一个无益的、中立的家园，以促成开源我的项目的单干与开发。入选沙箱的我的项目，是被 CNCF TOC 认可的，并值得进行试验和开发的后劲我的项目。 Carina 基于 Kubernetes 及 LVM 实现，提供了数据库与中间件等有状态利用在 Kubernetes 中运行所必须的高性能的本地存储能力，极大缩小了存储系统的运维压力。Carina 最大的特点是高性能和免运维，为中间件、数据库等有状态服务提供了匹配本地磁盘的高 IOPS 和极低提早的性能指标，同时易装置、自运维能力又极大地加重了存储系统的运维压力。另外，Carina 还提供了本地磁盘治理能力、PV 高级调度能力、PV 主动分层技术、卷拓扑能力、主动 failover 能力、动静 IO 限速、监控告警、多种存储供应能力等高级性能。 Carina 自公布以来，继续迭代开发，截至目前已公布5个版本。在最新公布的v0.11.0 版本中，对多项性能进行了重磅降级，详情可见《Carina 全新版本 v0.11.0 上线！重磅降级不可错过》。 往年4月，Carina 本地存储我的项目被纳入 CNCF 最新版本的云原生全景图（Cloud Native Landscape）云原生存储（Cloud Native Storage）板块。此次正式入选沙箱级我的项目，意味着 Carina 进一步失去了云原生开源社区的认可，同时通过沙箱捐献给 CNCF，进一步保障了我的项目的中立性，有利于开发者、合作伙伴等独特参加我的项目建设，合作共赢。 在此感激每一位参加的社区搭档对 Carina 的帮忙和反对，也欢送更多使用者和开发者参加体验和应用 Carina。 更多信息Github：https://github.com/carina-io/...会议回放：https://space.bilibili.com/52...退出社区：扫码增加，入群暗号 Carina

前言因为工作起因须要应用 openEuler，openEuler官网文档部署K8s集群比较复杂，并且网上相干材料较少，本文是通过实际与测试整顿的 openEuler 22.03 部署 Kubernetes 1.20.2 集群操作方法。这篇文章仅供学习参考，请勿间接用于生产环境。 1. 装置筹备在开始之前，部署 Kubernetes 集群机器须要满足以下几个条件： 操作系统：openEuler 22.03硬件配置：2GB或更多RAM，2个CPU或更多CPU，硬盘30GB或更多集群中所有机器之间网络互通能够拜访外网，须要拉取镜像1.1 服务器布局主机名称角色IP地址配置openEuler.master01Master节点192.168.123.208CPU 2核，内存 4G，硬盘 40GBopenEuler.node01Node节点192.168.123.167CPU 2核，内存 4G，硬盘 40GBopenEuler.node02Node节点192.168.123.213CPU 2核，内存 4G，硬盘 40GB1.2 服务器环境配置批改主机名称# master01 执行hostnamectl set-hostname openEuler.master01# node01 执行hostnamectl set-hostname openEuler.node01# node02 执行hostnamectl set-hostname openEuler.node02配置host映射vim /etc/hosts192.168.123.208 openEuler.master01192.168.123.167 openEuler.node01192.168.123.213 openEuler.node02敞开swap# 长期敞开swap分区swapoff -a敞开防火墙# 敞开并禁用防火墙systemctl stop firewalld && systemctl disable firewalld2. Kubernetes集群装置2.1 Master节点装置2.1.1 装置Docker# 装置dockerdnf install -y docker# 启用dockersystemctl enable docker && systemctl start docker# 查看docker版本docker --version2.1.2 装置配置Kubernetes组件# 装置kubeadmin、kubelet、kubernetes-masterdnf install -y kubernetes-kubeadm kubernetes-kubelet kubernetes-master# 装置conntrack组件（k8s依赖组件）dnf install -y conntrack# 配置kubelet开机自启systemctl enable kubelet.service && systemctl start kubelet.service# 装置Kubernetes，apiserver-advertise-address 请替换成理论环境中的master节点ip地址，本文环境应用192.168.123.208kubeadm init --apiserver-advertise-address=192.168.123.208 --image-repository registry.aliyuncs.com/google_containers --kubernetes-version v1.20.2 --service-cidr=10.1.0.0/16 --pod-network-cidr=10.244.0.0/16# 命令选项阐明：# --apiserver-advertise-address：apiserver通告给其余组件的IP地址，个别应该为Master节点的用于集群外部通信的IP地址，0.0.0.0示意节点上所有可用地址# --image-repository：指定要应用的镜像仓库，指定为aliyun镜像减速下载# --kubernetes-version：Kubernetes程序组件的版本号# --pod-network-cidr：Pod网络的地址范畴，其值为CIDR格局的网络地址# --service-cidr：Service的网络地址范畴，其值为CIDR格局的网络地址看到如下提醒装置胜利保留kubeadm join信息 ...

这个时代，堪称是云原生的黄金时代。 站在这个云原生的风口，年轻一代的开发者如何对待本人所处的环境？他们眼中的云原生将来是什么样？ 明天咱们就将走近一位年老的“云原生原住民”，听听他作为开发者的成长经验。 Warren Wong 现职跨云利用经理，为企业优化绩效，管制老本，并爱护简单混合的企业应用程序与环境。致力于香港市场推广云端科技，帮忙程式开发公司和初创公司独特打造解决方案，以满足香港市场对云端的需要。 缘起 Azure 的云技术之旅如果说学生时代的经验，是一张帮忙咱们决定开启哪扇职场大门的门票，那么不可否认的是，毕业后抉择的第一份工作，则往往决定了咱们将来五到十年的人生落点。对此 Warren 深有体会，正是第一份工作，让他开始从浅浅理解到深刻利用微软 Azure，与云技术结下了不解之缘，就此开启了他退职场的技术花路，去摸索充斥有限微妙可能的云世界。 给本人加码充电想要从时机遍地的云时代中大浪淘金，那么具备高超的云技术能力，注定是开发者们立足的胜利之匙。正所谓千金在手不如一技傍身，底气十足的 Warren 敢想、敢做、敢尝试。品味到“技术魅力”的他凭借着乐趣和学霸属性的加持，化身考据达人，踊跃考取业余畛域相干证书，并一连拿下十多个微软 Azure 认证。而这段疯狂的考据之旅，不仅帮忙他对微软 Azure 等相干产品和云原生前景有了更粗浅的理解，也同时为他的职业生涯提供了更多抉择的机会，为本人赢来了更加广大的职场前路。 致力打造有温度的技术对话而对技术的乐趣，让他不仅退职场上从容前行，也帮忙他意识结交到了更多对技术常识感兴趣、气味相投的好敌人。在技术交换社区里，他用他开朗激情的一面，成为乐于助人的社区卡司。空闲时光，大家会一起交换探讨最新的技术观点，分享技术教训，敌人圈里总是有聊不完的技术话题。 此外，Warren 心愿让技术对话不再仅是局限于文字之间，而是可能和煦的、面对面去进行技术碰撞，进而绽开出更大的价值，因而他热衷于参加并组织一些教育培训讲座，常常亲自参加教学，并分享他做的一些深度我的项目。他构建的面向全行业开发者的 API 网关- warching/kong-azurepipeline-agent，作为继续集成和部署过程的一部分，帮忙越来越多的开发者构建和部署 Kong API 网关，目前下载量已高达500K+！ 技术和游戏双重 ACE生存中，Warren 也展示着年轻人洒脱率性的一面。在谈及兴趣爱好，Warren 脱口而出游戏。他坦言喜爱游戏之中的好奇感，尤其是卡牌游戏，最近他迷恋上了一款卡牌游戏，而为了可能跟更多人一起对战，点满开发技能点的他钻研并“顺便”开发了一个中文版本（小编不禁感叹，难道这就是学霸的任性？Respect！）。令他欣慰的是，游戏外面的玩家数量也在逐步宏大，乐趣翻番！ 而除了游戏，Warren 还喜爱骑摩托车在城市穿梭，享受飞驰的高兴。用他本人的话说“有些货色没想通的时候，骑车去山里、海边兜兜风，让思路放飞，或者会有出乎意料的惊喜”。 最初在谈到对将来的畅想时，Warren 对云原生将来的倒退充斥了信念：“最间接来说就是你能够用到云的劣势来帮你实现你想要做的事件，并借助开源的工具，在本人私有化的部署中实现操作，享受云原生带来的便捷与智慧。”而对于这样的云原生世界，小编也是充斥了有限的神往和期待~ 12月 MSDN 特地专栏《技术狂旅》讲述了四位技术狂热爱好者的精彩故事：热衷投身于教育事业的琳立，热爱赛车的管理者 Edward，能理能文的 Jiadong，以及年老的云原生住民 Warren。心愿通过解读他们的人生旅程，为你带来了一些启发和激励，开始探寻本身更多的可能性。 咱们置信，属于微软开发者的故事仍在产生。欢送所有喜好技术的人，分享您或身边人的技术故事，与咱们一起奔赴《技术狂旅》！ 点我退出微软 MVP~

导读｜基于 K8s 的云原生容器化曾经在腾讯外部海量业务中大范畴落地实际。业务从传统的虚拟机部署状态无缝切换到容器部署状态，运行在 K8s 上的利用从无状态服务扩大到有状态服务，这个过程经验了哪些革新？同时，K8s 如何禁受住业务状态简单多样、模块数量宏大的考验？遇到哪些新的挑战？如何优化？成果怎么样？腾讯云高级工程师林沐将为你解答。 在线业务资源容器化部署的问题与优化计划 腾讯平台的业务根本都属于在线业务。这些业务以前在虚拟机部署时，是通过物理机操办的形式生产出很多虚拟机，对于业务来说是不感知的。当业务发现虚拟机负载较低时，可将多个在线业务混部来进步资源利用率。 这种资源管理形式到容器化部署时产生了一些变动，次要有四方面的内容。 容器交付。每个 Pod 在交付的同时须要申明规格大小，规格大小要扭转时 Pod 必须销毁重建，无奈通过混部来新增业务。节点平衡。K8s 每个节点上部署多个 Pod，每个节点上的 Pod 类型、数量也都不雷同，要保障节点平衡是一个挑战。K8s 的云原生个性，也就是弹性，是否可能合乎在线业务在生产环境中的需要？集群池化。K8s 是按集群维度治理，而平台有上万个业务，这么多业务如何映射到不同的集群实现条带化治理？ 针对上述问题，腾讯采取的优化伎俩是： 第一，资源利用率晋升——动静压缩和超卖。咱们面临一个痛点是用户配置的容器规模不合理，广泛偏大，这样节点装箱率和负载比拟低。所以第一个优化形式就是 Pod 资源动静压缩，Pod 申请双核处理器 4G 内存，在调度时压缩成单核 4G 内存。因为 CPU 属于可压缩资源，内存属于不可压缩资源。这里批改的只是 Request 大小，并不批改 Limit，所以不影响容器理论能应用的上限值。这样能进步节点的装箱率。接下来是 Node 资源动静超卖，依据负载状况超卖更多 CPU 外围。 第二，节点负载平衡——动静调度和重调度。资源压缩超卖能进步节点的装箱率和负载使用率，但 Pod 是共享Node 的，压缩和超卖会加剧它们之间的烦扰。于是咱们开发了动静调度器，当每一个 Pod 调度时，可能感知存量 Node 以后的实时负载状况，从而对增量 Pod 在 Node 当中平衡解决，掉到一个低负载的节点上。存量 Pod 在节点上也有可能产生高负载，这时咱们在节点上部署 Pod-Problem-Detecor、NodeProblem-Detecor，检测出哪个 Pod 会导致节点高负载，哪些 Pod 属于敏感 Pod，通过事件上报通知API Server，让调度器将异样 Pod、敏感 Pod 从新调度到闲暇节点。 第三，K8s 业务弹性伸缩——协同弹性。在线业务最关怀业务稳定性。有时业务负载超出预期时，因为最大负载数配置过低，导致业务雪崩。所以咱们对 HPA 进行优化，退出 HPAPlus-Controller，除了反对弹性最大正本策略之外，还可能反对业务自定义配置进行伸缩。第二个是 VPAPlus-Controller，能够 Pod 突发高负载进行疾速扩容，对有状态的服务也能够进行无感知扩缩容。 ...

编者按：随着近几年来云原生生态的一直壮大，泛滥企业纷纷发展了用云上云的工作，学习云原生及容器技术对于古代工程师是必不可少的。本文整顿自龙蜥大讲堂 54 期，统信高级研发工程师参加技术分享，为大家介绍了云原生的介绍及其在容器方面的利用。 以下为此次分享内容： 01 对于云原生1.1 什么是云原生云原生技术有利于各组织在私有云、公有云和混合云等新型动静环境中，构建和运行可弹性扩大的利用。云原生的代表技术包含容器、服务网格、微服务、不可变基础设施和申明式 API。 这些技术可能构建容错性好、易于治理和便于察看的松耦合零碎。联合牢靠的自动化伎俩，云原生技术使工程师可能轻松地对系统作出频繁和可预测的重大变更。 云原生计算基金会（CNCF）致力于培养和保护一个厂商中立的开源生态系统，来推广云原生技术。咱们通过将最前沿的模式民主化，让这些翻新为公众所用。 1.2 云原生的设计哲学云原生零碎的设计理念如下： 面向分布式设计（Distribution）：容器、微服务、API 驱动的开发。面向配置设计（Configuration）：一个镜像，多个环境配置。面向韧性设计（Resistancy）：故障容忍和自愈。面向弹性设计（Elasticity）：弹性扩大和对环境变动（负载）做出响应。面向交付设计（Delivery）：主动拉起，缩短交付工夫。面向性能设计（Performance）：响应式，并发和资源高效利用。面向自动化设计（Automation）：自动化的 DevOps。面向诊断性设计（Diagnosability）：集群级别的日志、metric 和追踪。面向安全性设计（Security）：平安端点、API Gateway、端到端加密。1.3 云原生应用程序微服务作为单个实体进行治理和部署的应用程序通常称为单体利用。最后开发应用程序时，单体有很多益处。它们更易于了解，并容许您在不影响其余服务的状况下更改次要性能。 随着应用程序复杂性的增长，单体利用的好处逐步缩小。它们变得更难了解，而且失去了敏捷性，因为工程师很难推断和批改代码。 凑合复杂性的最好办法之一是将明确定义的性能分成更小的服务，并让每个服务独立迭代。 平安及扩大遥测和度量规范用于解决以下问题： 应用程序每分钟收到多少申请？有没有谬误？什么是应用程序提早？订购须要多长时间？弹性扩大弹性是基础设施的责任，但云原生应用程序也须要承当局部工作，利用横纵向扩大。 申明式因为云原生应用程序被设计为在云环境中运行，所以它们与基础设施以及相干依赖应用程序的交互方式不同于传统应用程序。在云原生应用程序中，与任何事物的通信都须要通过网络来进行。很多时候，网络通信是通过 RESTful HTTP 调用实现的，简化应用程序并使其更强壮。 02 云原生应用程序2.1 Kubernetes 与云原生的关系 2.2 Kubernetes 架构 Kubernetes 次要由以下几个外围组件组成： etcd 保留了整个集群的状态。apiserver 提供了资源操作的惟一入口，并提供认证、受权、访问控制、API 注册和发现等机制。controller manager 负责保护集群的状态，比方故障检测、主动扩大、滚动更新等。scheduler 负责资源的调度，依照预约的调度策略将 Pod 调度到相应的机器上。kubelet 负责保护容器的生命周期，同时也负责 Volume（CSI）和网络（CNI）的治理。Container runtime 负责镜像治理以及 Pod 和容器的真正运行（CRI）。kube-proxy 负责为 Service 提供 cluster 外部的服务发现和负载平衡。2.3 容器设计模式 统信容器云治理平台-有雀（统信容器云平台解决方案） 以 CRI-O、Kubernetes、OKD 为根底，以利用为核心的企业级容器云 PaaS 平台，提供主动伸缩、配置管理、资源管理、主动运维等性能，实现对容器化利用的全生命周期治理。 03 畛域利用3.1 云原生 OS、运维治理、CI/CD、安全策略运维治理问题次要包含如下几个方面： ...

前言：曾经成为数字化时代显学的云原生并非单项技术，而是一种重塑了软件开发和和业务运行利用的设计思维，是一套技术体系和方法论。云原生“Cloud Native”的Cloud 是指云平台，Native则示意应用程序从设计之初即应用云环境、天生为云而设计，充分利用和施展云平台的弹性+分布式劣势。据相干机构（Gartner）预测，部署在云原生平台上的数字工作负载将由 2021 年的 30%增长至 2025 年的 95%。对象存储作为最早的云服务，已广泛支持各种云业务，在数据湖畛域更是成为对立存储的不二之选。 一 何为云原生1.1 云原生定义随着技术倒退，云原生定义也在一直演进，如下是云原生计算基金会 (CNCF，Cloud Native Computing Foundation)目前的云原生定义： “云原生技术有利于各组织在私有云、公有云和混合云等新型动静环境中，构建和运行可弹性扩大的利用。云原生的代表技术包含容器、服务网格、微服务、不可变基础设施和申明式API。 此形容的前一句论述云原生的利用场景和指标，后一句则介绍云原生会应用到的相干技术。目前，以容器、微服务、DevOps 为代表的云原生技术已在金融、电信、互联网等多个行业失去实际和验证，为企业提供了具备弹性、韧性及拓展性的用户体验。 1.2 云原生技术特色依据云原生的技术架构，它能够宽泛部署到公共云、公有云、混合云等云环境。 通过CI/CD继续集成实现麻利利用开发。 采纳容器的轻量化运行环境升高资源开销、优化老本，基于服务网格（例如Istio）来管控利用的各模块、实现灵便调度，通过微服务架构理念将利用切分多个模块化服务，基于分而治之的办法让多团队疾速迭代开发。 不可变基础设施，则是通过容器镜像（Docker Images）来交付软件，将软件和运行环境打包公布，缩小环境适配的复杂度；而提供软件包，再到客户环境部署、调试、运行的计划，则须要思考各种兼容状况，非常复杂。某些场景下，基于镜像的部署工夫只有基于软件包部署工夫的1/10，极大优化软件交付。 申明式API，相似 K8S（Kubernetes）只需提交定义好的 API 接口来“申明”，示意所冀望的最终状态，一次调用就可实现。而软件包部署形式下，须要通过执行命令实现一步一步交互，最终实现公布，这种“命令式API”相较于K8S的“申明式API”效率低下。所以，通过“申明式API”能够让零碎之间的交付更加简略，无需关注过程细节。 1.3 云原生对存储的需要在上述的云原生技术架构下，对存储提出了诸多需要，包含： 容器的安全性不论是CI/CD，还是容器、微服务，通常都运行在虚构网络（VPC）环境中，如何实现VPC容器下的平安数据拜访是根底要求。 微服务的隔离性基于服务网格、微服务架构，利用须要划分为泛滥的子服务，升高子服务间的烦扰、实现子服务间的数据拜访隔离至关重要。 弹性扩大能力微服务架构中的子服务模块会引入突发流量，例如10,000+的容器并发拜访数据将会带来拜访洪峰。而不可变基础设施的容器镜像批量启动风暴，也会带来集中的刹时流量，因而须要存储提供弹性扩大能力。 高可用、高牢靠微服务架构会产生大量的子服务，它们都须要高可用、高牢靠的底层存储，从而实现企业级利用要求的5个9可用性。 单位存储密度的性能，可预期的带宽、时延、OPS容器化的细粒度运行环境，在公共云上实现了秒级计费能力，比弹性计算服务器的小时级更精密。所以，存储提供单位密度的带宽规格（每TB的Gbps带宽能力）、稳固的申请时延和OPS（99.99%的申请在指定工夫T内实现），能够无效地帮忙微服务评估应用存储的时长，从而能够按需开释容器，取得最合适的性价比。 二 对象存储如何反对云原生2.1 对象存储合乎云原生定义对象存储作为数据寄存的平台，人造反对构建和运行可弹性扩大的利用。而且容器、服务网格、微服务在设计开发的晚期就应用对象存储来存放数据，容器镜像数据寄存的罕用技术也是对象存储。对象存储的Restful API齐全匹配申明式API要求，因而对象存储是云原生数据存储的现实之地。 2.2 云原生给对象存储带来的挑战对象存储利用到云原生，是典型的存算拆散架构；同时对象存储作为数据底座，它的高牢靠、高可用以及弹性扩大能力，已在云上失去宽泛认可。 云原生利用正在引领各个应用领域实现云原生化的同时，也在粗浅扭转着应用服务的方方面面。对象存储作为利用运行的基石，在服务云原生化过程中遇到了更多的挑战。安全性、隔离性、单位密度的性能，都是对象存储的面临的新挑战，须要集中解决。 2.3 对象存储该做些什么增强针对VPC环境的容器拜访对象存储安全性实现VPC运行环境和对象存储桶的平安拜访绑定能力。限定在VPC内只能拜访指定的对象存储桶，防止“内鬼”从企业VPC将企业的对象存储数据拷贝到集体的对象数据桶，这须要对象存储提供VPC Endpoint性能；也须要限定对象存储桶只能被指定的VPC拜访能力，防止内部黑客盗取密钥后导致数据透露，须要对象存储提供Bucket Policy性能。 微服务的PoD级拜访对象存储桶的灵便权限相似云计算服务器绑定拜访存储的Access Token，须要为PoD绑定拜访存储的Access Token，通过Token的临时性，防止Access Key这样的长期密钥被盗取，从而带来影响微小的平安危险。 面向微服务的隔离性拜访隔离。利用的不同子服务，能够应用同一个数据存储桶，但须要为每个子服务提供不同的拜访域名，并绑定不同的拜访策略，管制拜访门路、权限，实现拜访隔离，须要对象存储提供Access Point性能。 流控隔离为利用的子服务，提供用户级、子用户级、对象存储桶级的流量控制能力，限度子服务能应用的带宽，防止利用被异样流量冲垮。 提供单位存储密度性能的规格通过不同存储类型，提供差异化的单位存储密度性能。例如高性能存储类型，为每TB容量提供不同带宽能力，带宽性能规格越强，价格越高。从而可能依据理论性能需求，为利用抉择不同的存储类型。 保障稳固可预期的时延和OPS存储的数据拜访时延存在稳定，即便大部分时候都是低时延，但大量的长尾高时延，也足以让云原生利用的运行时长不可预期，只能依照最坏的长尾高时延设计。所以，对象存储的各种存储类型都应该提供稳固的时延和QPS，而不是一味谋求极致低时延。 热点数据性能减速容器批量启动风暴和并行计算框架，都会带来大量热点数据的反复读。提供凑近容器可用区（AZ）部署的对象存储热点数据加速器，能够进步容器加载速度和疾速实现并行计算工作。 三 如何做好云原生下的数据湖数据湖是解决大数据存储与利用的无效伎俩。如下图所示，为了更好地适配云原生利用，数据湖除了更强的高可靠性、高可用、弹性扩大需要外，还须要在安全性、隔离性、反对计算引擎的接口和性能上提供更强的性能。为了更好的利用云原生容器的细粒度运行环境，还须要单位存储密度的性能，实现可预期的带宽、时延和OPS，以及性能减速能力，从而让微服务的数据拜访时长可建模计算，使得利用能够准确申请和开释容器，达到老本优化。 除了这些变动外，还须要关注如下的点： 数据湖撑持云原生计算的接口适配云原生理念被宽泛承受，基于云原生架构构建的数据分析计算引擎遍地开花。而基于对象存储的数据湖，要反对丰盛的计算引擎，包含存量的历史引擎（如Hadoop生态）、以及新的引擎（如Spark、Iceberg、Hudi、Delta Lake等）。数据湖要反对额这些引擎，就必须要适配数据拜访接口，特地是历史的Hadoop生态拜访的HDFS接口。 可观测的运维因为云原生采纳微服务架构，利用通常由多个微服务组成，它简化了部署难度，但随着数据链路减少，也增大了排查问题、剖析性能、度量零碎的运维难度。因而云原生须要架构相干模块提供可观测的运维，对象存储作为数据存储也须要提供可观测运维的Log/Metric/Trace能力，被云原生利用集成。 可编排和调度的资源云原生通过编排和调度实现利用的灵便部署和治理，对象存储须要提供编排和调度的接口，并整合到云原生平台中，从而让存储资源按需疾速可用。 云原生充沛开释了云计算的红利，将来将有更多的业务利用生于云，长于云。因而，随着云原生架构的利用拓展到更多的畛域，新需要将如雨后春笋般涌现，在这样的背景下，数据湖将会一直演进，进而更好满足业务的理论需要。 ...

在过来几年里，勒索软件始终是企业平安团队关怀的头等大事，而以后软件破绽问题数量也在逐步低头。基于云的应用程序和服务的爆发式增长以及数字化工作的减少，对黑客来说是一大利好，他们正在利用开发人员和 DevOps 团队疾速迭代的工作来满足他们的希图。有人预计说，过来十年里40%的零日攻打都产生在2021年。  造成这一景象增长的起因有很多。开发人员重复使用代码，使得谬误的配置和破绽在不同的程序中重复呈现，而且应用多云服务使得安全措施无奈残缺地施行，升高了代码的可见性。因而，开发人员和平安专家更偏向于在整个软件开发生命周期（SDLC）中更关注平安，特地是晚期阶段。  平安左移准则与挑战零日攻打的激增导致人们对左移的趣味愈发浓重，认为这是一种使平安成为开发过程中优先级靠前的形式。左移文化将平安问题在软件生命周期的晚期阶段（即软件部署之前）引入，而不是在用户报告谬误之后再打补丁。这种后发制人的办法有助于打消那些可能影响应用程序平安情况的破绽，而这些破绽可能连防御者都很难检测进去。  当开发者在云平台上构建应用程序时，如 AWS、Azure 等，左移准则也可能加强安全性，因为在这些平台上，对自研代码和平台平安工具的可见性可能无限。在左移文化中，DevOps 将最小权限准则利用到云工作负载的日常工作中，以爱护网络基础设施，防止对这些工作流程授予过多权限。例如，在 Kubernetes 容器上设置基于身份的访问控制（RBAC）以加强集群上的最小权限模型并防止过多的权限，它们可能导致数据泄露。与此同时，从 CI/CD 工作站移除治理证书，阻止黑客利用流水线作为攻打媒介。  平安左移是一个很好的概念，但在执行中经常会遇到阻碍，次要是因为开发团队之间外部的矛盾——业务团队心愿放慢开发进度，但平安人员则更为审慎。这就导致了摩擦，开发人员正告说回绝拜访会影响他们的工作并导致部署延误，而平安分析师则放心太多的用户领有未经审核的管理权限会造成数据泄露。要解决这些摩擦须要转变观念，即 DevOps 须要将平安了解为开发流程的一部分，同时管理人员信赖开发人员曾经领有了安全意识。同时还须要将现有工具和培训与平安左移实际相结合，例如，满足CISO平安需要（赋予网络基础设施代码更大的可见性）和DevOps敏捷性需要（自动化平安防护和受权）的平台。最终目标是构建 DevSecOps 模型，将开发、平安和运维集中到一个麻利、平安、高效的工作流程中。  如何在云端实现平安左移？以下是4个最佳实际，帮忙您在云端实现 DevSecOps：  获取深度可见性随着企业常常在多云环境及混合云环境中工作，对软件资产的可见性通常会受到影响，这会导致难以及时觉察危险。企业可能清晰地晓得环境中的所有身份、权限、配置和资源，以及对特定资源的所有拜访门路，有助于建设云资产的上下文清单，以更好地治理它们并进行策略剖析。  危险优先级排序风险管理是所有平安我的项目的外围实际，但来自多个云厂商及零碎的大量告警会让平安团队不堪重负。自动化工具能够在从开发到生产的整个云环境中帮忙团队搜寻并对危险进行优先级排序，发现关联问题并加重跨多个环境和阶段对告警进行手动分类的工作量，从而使开发及平安人员可能腾出工夫来解决更高优先级的危险修复工作。  即时拜访零信赖架构曾经成为大多数平安进攻的规范，但因为治理拜访权限十分困难，因而零信赖架构经常蒙受挑战。即时拜访（JIT），即授予限时、可撤销的拜访权限，是一个有用的工具，能够建设一个零信赖的平安架构，并且可能保护最小权限策略。踊跃治理和监控开发者拜访云环境的技术工具，包含对特权流动的亲密审计跟踪，为平安提供了一个执行JIT拜访和零信赖的伎俩。  发现并阻止破绽和谬误配置IaC 通过应用虚拟机、容器、微服务等，使软件在云中的部署更加灵便和高效。然而，在搭建云计算基础设施时，平安问题往往是预先才想到的，无论是否在生产环境中。企业应该扫描代码是否违反安全策略和存在其余危险，以便在它们进入生产之前进行修复。通过在开发工作流程中建设反馈和主动拦挡机制，DevOps 和平安团队能够升高代码中的平安危险。  与零信赖一样，左移正在成为保障网络安全的规范做法。然而，建设一个 DevSecOps 模型须要的不仅仅只是一个欲望。它须要执行该模式的实际、工具和培训，以及整个企业和内部云及平安合作伙伴的独特单干。只有个人的致力能力提供麻利企业所需的云平安保障。  参考链接：https://devops.com/implementi...

作者：vivo 互联网容器团队- Pan Liangbiao 本文依据潘良彪老师在“2022 vivo开发者大会"现场演讲内容整顿而成。公众号回复【2022 VDC】获取互联网技术分会场议题相干材料。 2018年起，vivo以容器作为根底底座，打造了一站式云原生机器学习平台。向上撑持了算法中台，为算法工程师提供数据治理、模型训练、模型治理、模型部署等能力，为广告、举荐和搜寻等业务赋能，胜利为算法实现了降本、提效，让云原生和容器价值初露锋芒。基于机器学习平台的试点成绩，通过算法场景的试点实际和价值剖析，对外部策略做了降级。确定基于云原生理念去构建行业一流的容器生态，实现规模化的降本提效指标。 本文会具体介绍vivo在容器集群高可用建设中的具体实际，包含在容器集群高可用建设、容器集群自动化运维、容器平台架构降级、容器平台能力加强、容器生态买通等层面的打磨和建设。目前，vivo容器产品能力矩阵逐步趋于欠缺，并将围绕全面容器化、拥抱云原生和在离线混部三个方向持续发力。 云原生和容器，是当下比拟炽热的话题，其中 Kubernetes更是成为容器编排畛域的事实标准。 国内外各企业在外部落地云原生和容器的过程中，基于本人的业务场景和倒退阶段，会遇到各种问题和挑战，本文是vivo在云原生容器畛域的摸索和落地实际，心愿能对读者有一些借鉴和帮忙。 一、容器技术和云原生理念首先是容器技术和云原生理念的介绍。 1.1 容器技术简介 容器技术不是一个新技术，从1979年unix零碎的chroot诞生到当初，历经40多年的倒退，共通过了四个阶段，别离是：技术萌芽期、技术爆发期、商用探索期和商用拓展期。 每个阶段，解决了不同的技术问题，别离是：环境隔离、软件散发和编排、商用服务状态、规模化和场景拓展。 相比于虚拟机，容器技术少了一层虚构操作系统的损耗，因而它比虚拟机具备更好的性能体现。另外容器在系统资源、启动工夫、集群规模、高可用策略等方面，也有非常明显的劣势。 2020年CNCF中国云原生调查报告显示，承受考察的中国企业，有68%曾经在生产环境应用容器技术。 从行业倒退看，不论是云厂商还是各大科技公司，都在基于容器技术构建本人的新一代基础架构，推动企业数字翻新。容器技术曾经失去宽泛的认可和遍及。 1.2 云原生理念介绍 容器技术催生了云原生思潮，云原生生态推动了容器技术的倒退。那么云原生的精确定义和含意是什么呢？ 云原生其实没有规范定义，如果非要给他一个定义，行业有两种观点： 一个定义来自Pivotal 这家公司，它是云原生利用的提出者，是云原生的先驱者、探路者。Pivotal最新的官网对云原生的介绍有四个要点，别离是：DevOps、继续交付、微服务和容器。另外一个定义来自CNCF，CNCF建设于2015年，它是一个开源组织，其存在的目标，是反对开源社区开发要害的云原生组件，包含 Kubernetes、Prometheus监控等。它把云原生分为3种核心技术和2个核心理念： 3种核心技术：别离是容器、微服务、服务网格。2个核心理念：别离指不可变基础设施和申明式API。然而，不论是那一种定义，容器都是其根底，是云原生落地的外围技术手段。 1.3 云原生价值剖析 任何技术和理念，都必须有理论的业务价值。从效率、老本、品质三个维度，来剖析云原生和容器的技术价值，可总结如下： 效率：可实现继续交付部署快、镜像封装可移植、弹性计算秒扩容。老本：可实现按需分配不节约、对立调度高填充、混合部署少碎片。品质：可实现运行状态可观测、故障产生可自愈、集群治理可运维。二、vivo 容器技术摸索与实际新技术的引入带来新的价值，也必然会引入新的问题，接下来介绍vivo在容器技术上的摸索和实际。 2.1 试点摸索 在vivo的算法场景中，机器学习平台负责算法模型迭代，是互联网算法业务中外围的一环，晚期的平台基于传统的架构，在效率、老本、性能和体验上均有肯定的有余，无奈满足算法业务快速增长的诉求。基于此，咱们首先在算法场景进行容器的试点摸索。从2018年开始，咱们以容器作为根底底座，打造了vivo的一站式云原生机器学习平台，向上撑持了公司的算法中台，为算法工程师提供数据治理、模型训练、模型治理、模型部署等能力，为广告、举荐和搜寻等业务赋能。 vivo的云原生机器学习平台具备如下5大劣势： 场景全：业务端到端，笼罩举荐、广告、搜寻多场景。体验好：排队工夫短，用户体验优，工作P99排队时长小于45分钟。成本低：调度能力好，资源利用率高，CPU利用率均值大于45%。效率高：网络规模大，训练跑得快，训练速度8.3亿样本每小时。后果优：算法迭代稳固，训练成功率高，训练成功率大于95%。vivo云原生机器学习平台，胜利为算法实现了降本、提效，让云原生和容器价值初露锋芒。 2.2 价值开掘 基于后面机器学习平台的试点成绩，咱们深入分析和开掘容器和云原生的价值，联合vivo的状况，咱们发现容器和云原生是企业大规模降本和提效的最佳计划。 1）在降本方面 以后咱们外部服务器资源的利用率较低，以CPU利用率为例，以后vivo服务器整体利用率均值在25%左右，相比行业一流程度的40%～50%，还有不少的晋升空间。 容器在资源隔离、对立调度和在离线混部等方面的劣势，均是晋升资源ROI的无效技术手段。 2）在提效方面 以后咱们在中间件版本升级、机器迁徙、测试环境治理、突发流量应答和全球化部署的环境一致性等方面均有业务痛点。 容器的疾速交付、弹性自运维、微服务、服务网格等云原生技术和架构，则是提效的无力措施。 2.3 策略降级 通过算法场景的试点实际和价值剖析，咱们对外部策略做了降级， 确定基于云原生理念去构建行业一流的容器生态，实现规模化的降本提效指标。 为了更好匹配策略落地，拥抱云原生，咱们还对外部技术架构从新布局和降级，新增引入对立流量接入平台、容器运维治理平台、对立名字服务、容器监控等平台和能力，撑持容器生态在公司外部的全面建设和推广。 2.4 面临挑战2.4.1 集群挑战 要提供大规模的生产可用的容器服务，容器集群的可用性首先会面临诸多挑战。上面介绍vivo容器化，在生产集群建设过程中遇到的4个比拟大的挑战。 集群规模快速增长：vivo集群服务器规模上万个宿主机节点，治理的集群数十个，单集群规模2千+，实例数10万+，对集群性能和机器治理挑战极大。集群运维、经营和标准化：因为晚期集群治理不标准，黑屏化操作和人为误操作等问题层出不穷，集群运维人员每天因为各种救火忙得焦头烂额。集群容器监控架构和可观测性：随着集群规模快速增长，容器的监控组件面临极大压力，对容器监控的采集、存储和展现，提出更高的要求。线上K8s版本升级迭代：面对Kubernetes版本的疾速迭代，须要实现给航行的飞机换引擎。针对挑战，咱们的应答计划别离是：高可用、可观测、标准化和自动化。其中容器监控和k8s版本无损降级的挑战，vivo公众号有具体技术计划的介绍，本文偏重介绍集群高可用和运维自动化两局部。 2.4.2 平台挑战 除了集群稳定性的挑战，平台也将面临各种挑战，因为容器平台和周边生态能力不欠缺，对业务存在较高的适配和迁徙老本。总结起来咱们遇到的挑战次要有4点： 容器IP的变动：k8s晚期把业务都设计成无状态的，其原生实现是每次公布容器的IP都会变动，这对局部依赖固定IP的传统业务不太敌对，业务革新老本较高。周边生态的适配和兼容：包含公布零碎、中间件微服务平台、外部开发框架和流量接入层等用户应用习惯：vivo有比拟成熟的公布平台，用户习惯按机房公布，习惯资源分配和公布离开操作。价值输入：运维研发效率的晋升不好量化，容器老本劣势短期不好掂量。下面这些挑战，推动咱们要进行容器周边生态买通，同时通过加强容器平台产品能力，来适配各种业务场景，升高用户的迁徙老本。 2.5 最佳实际2.5.1 容器集群高可用建设接下来，介绍vivo在容器集群高可用建设中的最佳实际，咱们是从故障预防、故障发现和故障复原，3个维度来构建容器集群可用性保障体系的。 1、在故障预防上，咱们别离从流程工具、容灾能力和基础架构3个方面来进行建设： 流程工具：次要蕴含故障预案和故障演练，以及通过建设运维治理平台，来实现运维标准化、白屏化和自动化。容灾能力：次要是构建业务跨故障域容灾能力，保障集群故障时，服务和业务流量能跨集群调度和疾速一键迁徙等。基础架构：次要是通过屏蔽用户对底层集群的感知，一个机房多套集群，一个业务同时部署在多个集群上，防止单集群故障对业务造成影响。2、在故障发现上，咱们次要是通过，自建的监控大盘、日常集群巡检、外围组件监控、集群外拨测等措施，对故障及时发现和解决，升高对业务影响。 3、在故障复原上，次要是基于后面的故障预案，疾速复原，及时止损，并做好故障的复盘，不断改进咱们的故障预防和发现机制，积淀贵重教训。 另外，集群的可观测性是可用性保障的一个重要依据，咱们通过建设本人的SLO面板，对集群状态实时地进行监控，只有对经营情况一目了然，能力做到稳如泰山，从容应答所有变动。 ...

在大数据时代的明天，数据分析技术未然成为数字经济时代最外围生产力！回顾往昔，能够归结为三个典型阶段： 第一阶段：传统数据仓库时代应用场景：企业外部 BI技术实现：基于传统数据库共享存储架构和专门面向剖析型的无共享 MPP 架构 第二阶段：湖仓并行时代应用场景：企业外部报表与剖析，更大规模的 ETL 数据工程、行为剖析和画像等新型数据利用剖析，百万级内部客户高并发需要技术实现：离线数据湖，在线实时数仓 第三阶段：“云数仓为核心”的古代数据栈时代需要场景：一个零碎复杂度低、性价比高、简略易用且能够应答更多元、宽泛的场景和产业的数据分析平台计划技术实现：云原生化、实时对立的新一代云数仓产品 作为古代数据栈时代的主心骨，数仓在企业数字化转型的这场战斗中无疑背负着极为重要的使命。现在的时代又对数仓提出了怎么的要求？云计算的浪潮下，数仓的三个技术发展趋势愈发清晰： 实时化：千或万级高并发、毫秒级低提早、高吞吐、走向分钟级的数据产出效率成为了数据分析技术的关键词。统一化：湖仓一体、在离线一体、流批一体等智能湖仓的理念减速了平台和接口的对立；计算模型的交融、多模数据类型反对进一步提高存储计算的效力，升高运维门槛。云原生化：数据仓库联合云的软硬件翻新、资源弹性、安全可靠、随需而用等云原生特色，从根本上带给用户极致性价比和极简应用体验。将数字化转型新时代中的需要作为产品的规范，SelectDB 趁势而为，应运而生。基于存算拆散的云原生架构研发，SelectDB Cloud  构建于多云之上，并针对简单、多样的企业级数据分析需要打造五大外围特色劣势：极致性价比 / 交融对立 / 简略易用 / 企业级个性 / 开源凋谢SelectDB Cloud 产品劣势解读>>> 极致性价比 读懂 SelectDB Cloud 的极致性价比    极致性价比背地的“黑科技” 查问引擎的优化：基于 MPP 查问引擎进行优化，反对节点间和节点内并行执行；反对多张大表的分布式 shuffle join；；同时还反对相似 runtime filter 等动静执行技术，通过动静调整执行达到最优的执行效率。通过 colocate join 和 bucket shuffle join 优化可能缩小数据传输，晋升 join 性能。高效的数据处理：采纳了列式内存布局，向量化计算框架。大幅缩小了虚函数调用，进步了 cache 命中率，高效利用了 simd 指令，从而使得算子的性能晋升数十倍。多种存储模式：采纳了列式存储，使得编码、压缩、解决都十分高效；反对多种索引构造来做数据剪枝，减速数据扫描。反对物化视图，无效减速查问时的效率；反对多种存储模型。智能优化策略：采纳了 RBO 和 CBO 联合的智能优化器。行将公布的短门路优化，还可能反对数万QPS 的并发点查。云原生架构：SelectDB Cloud 云原生架构实现了本地磁盘缓存和对象存储的分层分级存储引擎 ——这样不同层级的存储老本带来综合老本大幅降落；同时在云原生架构实现了计算节点的拆散和弹性，得以令计算资源的随需弹性扩缩容。>>> 交融对立 读懂 SelectDB Cloud 的交融对立    交融对立背地的“黑科技” 混合负载：SelectDB Cloud 反对传统 OLAP 场景 （实时报表和 Adhoc 剖析等），也反对批量数据处理（ETL/ELT)。开发者在将大批量的离线 ETL 变成实时、小批量和增量的 ETL后，SelectDB Cloud 可能利用全内存的框架和向量化的引擎来更加高效的解决数据，能够达到几十倍的性能晋升。开发者通过简略、规范的 SQL 语句就能够实现数据加工，SelectDB Cloud 也反对 Java UDF 来实现更加个性化的数据处理逻辑。同时，在云上 SelectDB Cloud 也很便捷的应用独自的 ETL 集群来做隔离。结构化/半结构化反对：SelectDB Cloud 高效原生反对半结构化数据的高效存储和检索剖析，在升高了零碎复杂性的同时显著晋升了老本和性能的收益。SelectDB Cloud 具备灵便高效存储的能力，反对 Array, JSONB, Map 等复合数据类型和动静 schema 表。同时，SelectDB Cloud 具备丰盛索引构造减速检索剖析，也可能实现高效剖析和解决。湖仓一体：SelectDB Cloud 还能对曾经建设的离线数仓和数据湖进行联邦查问，在实现高性能的同时，不须要迁徙历史数据。SelectDB Cloud 反对便捷的元数据买通，免去了手动创立表面的繁琐，同时可能对热元数据主动 cache，并且可能反对手动和主动刷新；同时，SelectDB Cloud 也反对多种表面的联邦查问 (Hive, Iceberg, Hudi 关系型数据库，ES，以及各种反对 HMS 协定的云数仓）。简略易用SelectDB Cloud 具备简略易用的个性，它可能大幅度降低企业技术团队的学习、应用门槛和开发周期，更加高效的开释数据生产力，助力业务倒退和更迭。目前，SelectDB Cloud 是畛域中少有反对 MySQL 连贯协定的数仓。在现在的事务处理畛域，MySQL 曾经被各大公司宽泛采纳，基于此，用户能够应用 MySQL Client、JDBC 和 DBeaver 来连贯应用 SelectDB Cloud，这对于用户来说节俭了很多学习老本，更易于上手，兼容性也更好；另外，SelecDB Cloud 还通过可视化控制台为开发者和管理者提供了许多惯例、高频的性能来反对不同角色对大量的日常治理工作；除此之外，SelectDB Cloud还能够提供丰盛易用的数据导入形式：包含 HTTP Load、Stage Load 和帮忙周边大数据生态工具进行连贯导入的 Connector 插件，这些性能为企业在数据分析全链路过程带来简略易用的体验。 ...

近日，国内企业级云原生解决方案的领军企业灵雀云，与操作系统软件Ubuntu的原厂企业Canonical（以下简称Ubuntu）独特发表达成策略单干。单方将提供操作系统软件Ubuntu与云原生开放平台ACP的深度交融一体化解决方案，为开发者在支流操作系统上搭建一个开箱即用的企业级云原生平台，提供更加多元、简便、高效的抉择。  操作系统作为连贯硬件和数据库、中间件、应用软件的纽带，是构建企业  IT 底层生态环境的重要组成部分。作为国内支流操作系统，Ubuntu反对容器在多云环境横向扩大和超大规模计算的利用场景，始终是开发者及企业利用容器推动翻新的优选平台。基于Ubuntu，开发者能够应用Kubernetes发行版或私有云托管的Kubernetes服务，建设并治理新的Kubernetes集群。  目前，灵雀云云原生开放平台ACP已与Ubuntu实现兼容适配，用户能够在多云及混合云架构下轻松构建一个开箱即用、全面反对微服务架构和DevOps的云原生平台，为开发者及企业在Ubuntu上构建云原生基础设施、利用架构、开发流程、数据服务等方面的能力，提供更加简便、高效的抉择。  灵雀云云原生开放平台ACP，可服务于不同规模的企业、我的项目，它反对治理各种复杂度的基础设施环境、组织构造清晰的部门建制和人员团队，让资源配置更好地适应利用的理论需要，从而改良基础设施的敏捷性、自动化、效率和老本优化，驱动业务翻新增长；ACP也同样实用于独立开发者，它反对宽泛的 DevOps 工具链，反对可视化编排及一键部署。与此同时，ACP一体全栈，开箱即用，疾速搭建的个性，在开发者社区中失去了宽泛好评。  以云原生为代表的新一代技术，是推动数字化翻新倒退的外围驱动力，深入云原生技术与操作系统等 IT 底层环境的交融，是灵雀云与Ubuntu独特的诉求。将来，单方将携手为寰球企业用户、合作伙伴及开发者，提供更加优质、高效、便捷的“操作系统+云原生”一体计划，合力共建更加强健的IT生态体系！ 上一篇：工业互联网新引擎——灵雀云 × 英特尔 5G交融边缘云解决方案下一篇：一学就会的云原生，你信么？

从几个数字开始说IDC 预计到 2024 年，因为采纳了微服务、容器、动静编排和 DevOps 等技术，新增的生产级云原生利用在新利用的占比将从 2020 年的 10% 减少到 60%，其中微服务的 workload 在企业内将超过 80% 。下面的四点是云原生时代所代表的四个核心技术。其中，咱们的开发同学可能对于微服务比拟热衷，从近几年的趋势来看，Java 畛域的微服务框架日趋成熟，和云原生的联合也越来越严密。从 EDAS 中的数据来看，Spring Cloud + Kubernetes 基本上曾经成为了微服务架构状态下的支流配搭。然而另外一个数据让我产生了更多的好奇，就是目前在云原生场景下有过微服务生产教训的开发人员有余 8% 。为什么会是这个样子？我感觉次要起因有两个： 首先，是因为自身微服务的学习曲线比拟平缓，好不容易学会精通一个框架，能够进行生产实践了，可是马上又面临了云原生诸多简单的概念和简单环境搭建的技术挑战，这个两个因素联合在一起对于每一个人充斥的都是对于未知世界的恐怖，这样在一些策略定力不那么强的团队中，最初落地成果就不太好。 针对这一条，我感觉大家只须要跟进咱们团队的一些产品和相干课程就行了，云原生团队有大量的相干课程在阿里云大学上供大家学习，很多产品也提供了不错的工具；同时在各个领域都有很多的数字化转型的教训，其中包含微服务在研发团队中践行落地的教训。感兴趣的搭档能够给咱们留言，咱们能够择期进行深刻的沟通交流。 其次，对于开发人员而言，始终有一个谬误的认知就是云原生利用和一般开发的利用是没有区别的，因为对于开发者而言，还是一样写代码，还是一样公布部署，还是一样排查诊断。然而这里还真的不太一样，哪里不一样呢？Heroku 给咱们总结进去了 12 条因素，在圈内叫做 12 factor apps，既简略了解下来，合乎这个十二条因素的利用，能力叫做云原生利用。 Twelve Factor Apps这个十二条我列在了这里，橙色的局部，和我明天的内容相干。上面我每一条做一下简略的解说： 第一条：Codebase，既一份代码，多处部署。反过来了解就是多个部署都是一份代码，而且 得 是一份代码。那什么时候不是？比方咱们间接上生产环境中调整然而忘了同步回来的时候，也就是说，这一条是束缚咱们的研发流程，保障代码在各个环境中的一致性。 第二条：是显示申明依赖关系，这一条很好了解，写 Java 的同学都会应用 ant、maven、gradle 这样的工具对于一些依赖进行显示申明。然而咱们往往容易疏忽两点，第一点，是依赖一个 snapshot 版本，最初因为短少无效的跟踪而导致线上故障。第二点是一个隐含的依赖，既代码运行时环境的依赖系统软件、执行引擎等应都当是做利用的一部分。 第三条：Config，惯例了解是代码配置拆散。这里严格意义上，是讲的是整个运行环境（镜像）与配置要做隔离，什么意思呢？这里的外围是所依赖配置，是否能在运行启动的过程中，通过惯例的运维伎俩能进行灵便替换，这些运维伎俩包含：比方更改环境变量，更改启动参数，通过分布式配置服务等。 第四条：Backing Services，所有后端服务，其实包含所有产生网络调用的情景，咱们都须要同一视角去看待。当作附加资源有两种意思，第一是资源该当准的资源拜访的接口与形式，比方在 Java 中的 URI 接口。还有一种了解就是既然是资源，就须要思考他的可用性，既然所有后端服务都是资源，那么咱们也要厚此薄彼的去治理资源的可用性。 第五条：Build,Release,Run 之所以要严格离开，这是三个畛域咱们关注的能力也会不一样。首先 Build 更注重实效；而 Release 要重视策略；Run 阶段更重视流量治理，要尽可能的做到流量无损耗。 第六条：Stateless，单纯过程维度的无状态次要是过程启动过程中对于数据的依赖。无状态的目标，是为了更好的做疾速伸缩甚至主动的弹性伸缩，Stateless + 启动无需干涉是弹性的要害一步。 第七条：Port Binding，是指所有对外裸露的服务都通过端口裸露，这里是与之相同的是有一些利用通过 unix socket 或者 IPC 之类的拜访形式会极大减少大规模服务运维场景下的复杂度。 ...

开始阅读文章前，请角色切换：构想你作为一位中小型IT公司CTO，面对云原生技术决策，你须要答复两个问题： 为什么须要上云？ 上云有何弊病？ 作为一家公司的技术决策者，必须了解上云的利与弊，并联合公司各阶段倒退指标给出最适宜的技术计划。 云原生-概述 （一） 云原生-定义 云原生的定义，业界也是“百家争鸣”各持观点，从技术视角了解云原生会绝对清晰。云原生的关键技术包含： • 微服务架构：服务与服务之间通过高内聚低耦合的形式交互。 • 容器：作为微服务的最佳载体，提供了一个自蕴含的打包形式。 • 容器编排：解决了微服务在生产环境的部署问题。 • 服务网络：作为基础设施，解决了服务之间的通信。 • 不可变根底：设施晋升公布效率，不便疾速扩大。 • 申明式API：让零碎更加强壮 命令式API：能够间接收回让服务器执行的命令，例如：“运行容器”、”进行容器”等。 申明式API：能够申明冀望的状态，零碎将一直地调整理论状态，直到与冀望状态保持一致。 • DevOps：缩短研发周期，减少部署频率，更平安中央便： Culture ：达成共识 Automation：基础设施自动化 Measurement：可度量 Sharing：你中有我，我中有你 【私人观点】 云原生的定义：利用因云而生，即云原生。 利用原生被设计为在云上以最佳形式运行，充分发挥云的劣势，是上云的最短门路。 （二）云原生-技术生态 （三） 云原生-关键技术云原生关键技术包含：微服务，容器，容器编排，服务网络，不可变根底，申明式API。 （1）微服务 微服务是一种用于构建利用的架构计划。 将一个简单的利用拆分成多个独立自治的服务，服务与服务间通过“高内聚低耦合”的模式交互。 微服务典型架构包含： • 服务重构：单体革新成合乎业务的微服务架构。 • 服务注册与发现：微服务模块间的服务生命周期治理。 • 服务网关：身份认证、路由服务、限流防刷、日志统计。 • 服务通信：通信技术计划如，RPC vs REST vs 异步音讯。 • 可靠性：服务优雅降级，容灾，熔断，多正本。 （2）容器 容器是一种打包利用的形式，能够打包利用中的所有软件和软件所依赖的环境，并可实现跨平台部署。 容器关键技术：namespac视图隔离，cgroups资源隔离 ，Union File System联结文件系统。 ...

云原生社区长沙站成立于 2021 年 6 月，社区致力于推广云原生技术，构建开发者生态，在社区成立之后举办过 2 次线下会议和头脑风暴，欢送宽广云原生技术爱好者退出，云原生社区长沙站欢迎您（长沙同学能够增加微信 zb016720，申请入群）。 期待、筹备好久之后，云原生社区 Meetup 长沙站终于要开始了。 流动信息•流动日期：12 月 3 日 •流动工夫：14:00 - 17:00 •流动地点：长沙市岳麓区尖山路 39 号中电软件园总部大楼 •流动规模：50 - 80 人，线下 •主办方：云原生社区 •承办方：云原生社区长沙站 •场地 & 茶歇资助：中电软件园、极狐(GitLab) •单干社区：openKylin，腾源会 议题 报名扫描下方二维码开始报名吧！ 流动日程13:30 - 13:50 签到入场 13:50 - 14:00 主持人收场 Topic 114:00 - 14:40：如何在保障平安的前提下晋升研发效率？ 讲师：马景贺 集体介绍： 极狐(GitLab)DevOps 技术布道师，LFAPAC 开源布道师，CDF ambassador。关注在云原生和 DevSecOps 畛域。 议题纲要： 效率、品质、平安合规是软件研发过程中至关重要的三个方面，在软件研发过程中同时实现三方面是极具挑战性的，不仅与团队人员的技能无关，更重要的是与团队的研发流程、团队人员的思维意识、团队文化等无关。流程的凌乱、意识的忽有忽无让晋升效率、保障品质、保障平安合规成为一种流于形式、难以落地的口号。极狐GitLab workflow 通过将我的项目需要治理、分支开发、Code Review、Approve Rule、CI/CD、Security 等“串”在一起，造成了一个可能标准化、规范化研发流程的 workflow，通过配置、流程来为意识兜底，从而达到在软件研发过程中晋升效率、保障品质、保障平安合规成为可能。 听众收益： 1.极狐GitLab workflow 是如何标准研发流程的 2.Code Review + Approve Rule 如何晋升代码品质 ...

近日，国内最具权威性的信创行业赛事之一2022信创“大比武”总决赛圆满落幕，灵雀云ACP“一云多芯”信创云解决方案荣获通信行业赛道三等奖。 2022信创“大比武”流动是由北京航空航天大学、北京理工大学、中电标协信创工委会整体主办，中国互联网基金会反对的行业大赛，是国内目前惟一具备大覆盖面、强权威性的信创行业赛事。流动共分为七个赛道，其中“通信业务经营技术赛道”由中国联通团体、中国软件评测核心主办，联通数字科技有限公司承办，吸引了近百家信息技术厂商参赛。 通信赛道旨在聚焦通信畛域数字化转型理论需要，为进一步推动通信业务零碎转型降级提供能源。赛事邀请多名信创领域专家参加评审，通过两轮强烈的比拼和角逐，麒麟软件、360数字平安团体、飞腾信息、优炫软件、浪潮软件、灵雀云等25支团队最终怀才不遇。中国联通数字化部副总经理刘洪波缺席流动并致辞，联通数字科技有限公司高级副总裁魏春城代表通信赛道为局部获奖团队颁奖。  本次获奖的灵雀云ACP“一云多芯”信创云解决方案，以国产化操作系统为支点，具备最优化的零碎运行环境，承载灵雀云全栈云原生开放平台，反对飞腾、鲲鹏、海光、兆芯、Intel等多种国内外软硬件环境，满足企业多样化的数字化转型理论需要。 针对企业级要害业务具备主机系统可靠性、安全性、高性能和可扩展性，技术架构更贴合企业业务利用，满足企业级利用逐渐向容器化、微服务化过渡的宽泛需要，反对企业建设一个笼罩内外部各环节和组织构造的公有云平台。 计划可服务于不同规模的企业，反对治理各种复杂度的基础设施环境、组织构造清晰的部门建制和人员团队。让资源配置更好地适应利用的理论需要，从而改良基础设施的敏捷性、自动化、效率和老本优化，驱动业务翻新增长，为国产化利用的技术架构提供了牢靠保障。 在信创生态畛域，灵雀云已实现与鲲鹏、麒麟、飞腾、UOS等支流国产芯片、操作系统、服务器的兼容性认证，独特打造平安可信的云原生环境，继续晋升国产化建设实力，高效满足政企用户需要，着力帮忙国有企业建设安全可靠、自主可信的信创云原生平台，减速买通数字化转型的“最初一公里”。 作为三大运营商最信赖的云原生搭档之一，灵雀云保持以技术创新为倒退引擎，继续加大信创畛域投入，贴合客户业务场景，构建自主可信的翻新倒退格局。将来，灵雀云也将持续携手信创生态合作伙伴，一直打磨产品，共建信创环境，为我国数字经济倒退筑就松软牢靠的云原生底座！ 上一篇：灵雀云ACP 斩获“2022金边奖-最佳云原生边缘云平台”下一篇：一学就会的云原生，你信么

随着数据量和计算能力的爆发式增长，云计算技术的迅猛发展，云原生时代应运而生。私有云带来了能够按需申请 / 开释的有限的计算资源、有限的存储池和高价的对象存储，让云原生数据库 PieCloudDB 解脱 PC 架构的限度，完满解决传统数据库的缺点，实现了基于云计算平台的元数据层 - 计算层 - 存储层三层拆散架构。PieCloudDB 的弹性伸缩、降本增效、即开即用等泛滥劣势，为用户带来更高的性价比和更便捷的应用体验。 在享受 PieCloudDB 所带来便捷的同时，常有人对安全性产生疑难：在云环境下，零碎所面临的危险远多于公有环境。作为一款云原生数据库，PieCloudDB 是如何保障其数据库安全呢？  在介绍 PieCloudDB 的安全性之前，咱们先来探讨一下传统数据库的运行档次。传统数据库的运行档次次要分为三个档次： PieCloudDB 作为一款云原生数据库，以云计算架构为设计根底，全面解脱 PC 架构解放，实现存算拆散。存储侧反对规范对象存储，大大降低了灾备的老本。PieCloudDB 通过智能可视化平台，简化了传统 DBA 的工作量。同时，基于云化个性，PieCloudDB 也简化了数据库在基础架构层的运维工作，并且将平台运维拆散至云平台零碎，将用户从运维齐全解放了进去，运行档次也简化为用户层和基础架构层两个档次。在用户层，PieCloudDB 高度兼容 SQL:2016 规范和规范数据库接口，并通过智能可视化规范平台升高了操作门槛，为用户的权限治理、用户治理、集群治理提供了可视化的能力，保障数据安全。PieCloudDB 为用户提供了智能可视化规范平台。通过可视化的操作，PieCloudDB 为用户在权限治理、用户治理和集群治理操作上升高了门槛，让数据库应用体验上了一个台阶。PieCloudDB 基于 RBAC（Role-Based Access Control，基于角色的访问控制）模型设计权限，将用户通过角色与权限进行关联。在这种模型中，用户与角色之间，角色与权限之间，个别是多对多的关系。PieCloudDB 对于权限治理的指标是实现可见即可管。PieCloudDB 提供了租户下的角色治理模块，反对创立角色，建设基于零碎角色的根本角色架构，对不同的角色实现角色的继承、用户的关联、权限的赋予等操作；通过可视化操作和图表构造帮忙用户了解以后零碎角色关系。 PieCloudDB 实现了租户下的用户治理性能，反对创立用户、查找用户、批改用户信息、重置明码、赋予用户角色、删除用户等操作；可视化的治理界面让用户治理变得更加便捷。 PieCloudDB 为用户提供了集群操作治理和集群精细化治理模块，反对将创删集群等操作调配给不同角色来实现集群权限治理，领有受权的用户能够按需对集群进行扩容或缩容、启停或删除等操作； 同时，因为 PieCloudDB 是多集群架构，在不久的未来将实现集群精细化治理，使用户能够依照每个集群为最小对象进行角色受权治理。 PieCloudDB 高度兼容 SQL:2016 规范，齐全反对 SQL:1992 规范、大部分的 SQL:1999 和局部 SQL:2003 规范（次要反对其中的 OLAP 个性），反对包含窗函数、汇总、数据立方体和各种其余表白性能。此外，PieCloudDB 齐全反对和认证规范数据库接口 (PostgreSQL、SQL、ODBC、JDBC 等)。 对 SQL 的全面反对使得 PieCloudDB 能够无缝集成业内常见的提取 / 转换 / 加载（ETL）和 BI（商业智能）工具。企业只需安顿大量的集成工作，就能够应用现有的应用规范 SQL 构造和接口的剖析工具让利用在 PieCloudDB 上运行。从而防止了企业受制于供应商，帮忙企业在升高业务危险的同时推动翻新。 ...

一学就会的云原生你信吗？ 风很大的K8s到底好在哪儿？课程名称：《容器、K8s根底》课程亮点：数字化转型、降本增效入门经典课程！容器、K8s根底课程一步到位，从零开始解说Docker、Kubernetes的应用和利用实际，打造更懂容器、更会数字化转型的IT团队！适用人群：企业IT架构师、开发、运维人员 K8s怎么用？有官网认证培训吗？课程名称：《CKA精讲》课程亮点：CNCF官网受权CKA考试培训，帮忙所在企业迅速晋升K8s团队技术能力，申请认证 Kubernetes 服务提供商（KCSP）的敲门砖。适用人群：企业IT架构师、开发、运维人员 如何2小时疾速入门云原生？课程名称：《企业级云原生平台介绍》课程亮点：帮忙您企业的IT团队理解采纳基于容器的云原生平台后劲，带您疾速踏上企业的数字化转型之路。利用灵雀云企业级云原生平台（简称：ACP）打造的云原生架构能够进步利用的可靠性和可扩展性，升高开发人员老本，并能促成继续集成和继续部署。适用人群：企业级云原生平台使用者、开发、运维人员 开发、运维、业务都说好的云原生平台长什么样？课程名称：《企业级云原生平台应用精讲》课程亮点：一站式培训教学，助力企业IT团队造就装置、配置和治理灵雀云企业级云原生平台所需的技能，确保疾速公布容器化利用。适用人群：企业级云原生平台使用者、开发、运维人员 只此一家的官网认证云原生平台运维培训在哪里？课程名称：《企业级云原生平台运维与治理》课程亮点：采纳企业级云原生平台，实现疾速利用开发和部署，及利用的跨云治理，进而简化云原生利用的扩大、治理和保护；从培训课程到考前辅导全流程笼罩，学员通过考试还可取得“ACP认证工程师（运维）”官网认证证书。适用人群：企业级云原生平台使用者、开发、运维人员 七嘴八舌的利用现代化，外围方法论不过如此？课程名称：《利用现代化概览》课程亮点：学习容器/K8s、DevOps、微服务等云原生核心技术及实际方法论，减速利用现代化，将产品利用更快地推向市场！适用人群：企业IT架构师、利用开发、运维人员 想做容器化却无从下手？课程名称：《利用容器化革新》课程亮点：培训课程笼罩企业IT利用容器化革新的全流程、全阶段。资深云原生行业专家率领开发人员学习如何在云原生架构下设计、构建、部署容器化利用。适用人群：参加企业级云原生架构革新的利用开发人员 开发运维流程繁琐、周期长？跟不上业务倒退？课程名称：《DevOps方法论与最佳实际》课程亮点：DevOps治理施行高级进阶课程助力企业实现麻利开发、疾速迭代！资深DevOps专家教您如何落地DevOps，买通企业业务利用全流程，从实践根底到落地实训全链路领导！适用人群：参加企业级DevOps治理的开发、运维及相干人员 传统架构无奈满足业务需要？大行其道的微服务到底要不要上？怎么上？课程名称：《微服务治理与开发》课程亮点：企业级微服务治理与开发专项技能疾速晋升！微服务利用概念、常见微服务架构、微服务开发与治理，以及如何与Kubernetes容器等现代化云原生技术联合应用，一门搞定！适用人群：参加企业级微服务架构革新的开发、运维及相干人员 立刻开启云原生世界的大门！

过来数年间，在企业数字化转型的大趋势下，云原生，凭借其麻利、弹性、平滑的特色，不仅帮忙大量企业实现降本增效，也大幅晋升了开发过程中的生产力，成为当下最支流的技术倒退方向之一。 不过，对于开发者而言，如何借助“真正的云原生”晋升效率、升高开销，充沛享受云原生的技术红利，是更值得关注的议题。 云原生，曾经成为大厂的“技术底色”当初越来越多利用采纳云原生技术进行构建。有数据统计，近年来云原生相干的利用增长超过了 200%，CNCF 所评估的项目数甚至达到了 372% 的增长。咨询机构 Gartner 也预测，到 2025 年云原生平台将成为 95% 以上的新数字化打算的根底，而去年这个比例还不到 40%，显然还具备十分大的增长后劲。 其实，云原生早已是大厂实现技术迭代的要害抓手。 在 10 月 29 日举办的 Techo Day（腾讯技术开放日），腾讯云副总裁刘颖走漏，“早在2015 年容器和K8S呈现时，腾讯外部就曾经将这些技术引入理论业务，通过晚期一系列外部业务试点，腾讯在云原生技术上的积攒逐步成熟，之后咱们将云原生技术放到腾讯云上对外部客户输入，同时进一步在腾讯自研业务中推动云原生技术升级换代。” 据理解，往年腾讯的自研业务已全面上云，上云规模冲破 5000 万核，这也是业界最大规模的一次云原生实际，视频号、腾讯会议之类的大型利用都采纳了云原生来作为其技术底座，撑持起业务的爆发式增长。 联合内外部教训，腾讯已积淀出一套残缺的云原生技术和产品体系，涵盖软件研发流程、计算资源、架构框架、数据存储和解决、平安等五个畛域的多个场景。 除此之外，腾讯的各项动作也意味着，其在继续减轻对云原生的布局，踊跃裁减云原生产品体系，加大对云原生技术的研发投入。 大厂对云原生的押注，也牵引着行业的注意力，无论是为了晋升开发效率或学习开发技能，越来越多的开发者都在接触、拥抱云原生。据理解，腾讯云原生产品服务的开发者总数曾经超过300万。 云原生疾速倒退的背地，不仅仅是量的变动，同样引发了业内对架构计划、生产方式、思维模式、商业模式的思考。 对开发者而言，云原生的价值是什么云原生对企业而言，意味着降本增效，以及更好地反对业务倒退，那对法开发者而言，云原生的价值又如何评判？ 在腾讯云副总裁黄俊洪看来，“只有充沛享受到云计算红利，才是真正的云原生。云原生的倒退，实质上解放了开发者的生产力，让代码的开发工作有了质的晋升，开发者能更加聚焦到有创造力的业务逻辑和业务场景的了解上。” 过来企业“上云”只是单纯把常见的底层资源如计算、存储、网络堆砌到云上，短少对开发过程、开发架构、开发框架选型以及利用如何疾速交付的关注。对开发者而言，这个阶段也只是通过根底设置来晋升资源层面的利用效率。 随着云计算基础设施日益完善，“上云”曾经不再是单纯的“上虚拟机”。云原生作为“上云”的2.0阶段，外围是将应用程序的每个局部都进行打包、动静编排，每个局部都能被被动调度和治理。 通过将基础设施与业务平台交融，这些能力得以“排列组合”到一起，为业务利用提供规范的运行、监控、治理平台。这让开发者能把关注点从资源，转移到开发自身。 比方，微服务把应用程序结构成一组涣散耦合的服务进行开发部署，大大提高业务的敏捷性；通过 DevOps，进行继续集成交付以实现残缺的自动化和上云协同。 通过云原生技术来构建利用，开发者不再须要消耗大量工夫去思考底层技术实现，通过一些好用的云原生工具，就能疾速调用和治理底层资源，所有算力可能主动启动、伸缩，疾速响应业务，无效晋升了资源利用率，升高开发成本。得益于此，开发者能够有更多精力投入对业务的思考。 除此之外，云原生也带来了开发环境的扭转。现在各个云服务商都在推出好用的云端开发工具，例如腾讯云的 Cloud Studio，帮忙开发者解脱本地开发物理环境的解放，能够随时随地在云端开发、合作、公布利用。同时，其交融了腾讯云的底层云资源和在线开发环境，开发者能够享受更便捷、高效的开发过程。 云原生工具越来越丰盛易用对开发者而言，须要关注的不仅是行业趋势，也须要及时学习和理解新的云原生产品，放弃与时俱进。 近两年，微软、谷歌、AWS、腾讯等云服务商，都一直加大在微服务、容器化、Serverless、分布式云等畛域的投入，为企业和开发者提供各种高效、稳固的云原生产品，这些产品的性能和设计，也越来越丰盛易用。 此次 Techo Day，腾讯云重磅公布了三款全新的云原生产品。 •TSE 云原生网关 KONG，作为高性能、高可用的开源托管网关，能够集流量网关、平安网关、微服务网关为一体，无效缩小用户自建网关的开发和运维老本。 •TSE Polarismesh（北极星），是腾讯开源的服务发现、配置核心和治理核心，能解决分布式或者微服务架构中的服务可见、故障容错、流量管制和平安问题。 •TKE Housekeeper 原生节点，是专为云原生设计的加强节点，通过云原生申明式的形式治理和运维节点，解决 Serverful 模式下节点运维艰难的问题。同时通过 request 举荐、节点缩放、调度优化、节点水位管制等组合能力，解决资源利用率低的问题。 这些产品在推出前，都通过了海量外部业务的验证。例如，HouseKeeper 基于原生节点的老本优化能力，帮忙腾讯外部某大型业务实现了 2 个月资源申请量降落 25%。 腾讯云副总裁刘颖示意，将来，腾讯云还会继续投入云原生更前沿的利用，“例如，如何将云原生技术与具体开发场景交融演进，进一步晋升特定场景的开发效率。” 技术的倒退离不开生态的凋敝，离不开海量用户的实际。胜利的实际背地，正是一方面凭借本身的业务教训为开发者提供工具产品，另一方面背靠宏大的海量开发者，一直收集实在的需要与反馈，从而造成技术产品生态的正循环。 结语作为技术倒退的趋势，云原生势必会从一项前沿技术变得愈发支流，甚至成为开发畛域的通用范式。但真的到了那一天，云原生和当初相比会不会有很大的不同？云原生的将来是什么？ 咱们回顾最后的云原生技术，从微服务架构大规模的利用开始，到明天进入一个绝对成熟和大规模利用落地的阶段。将来的方向，是更高效的资源管理与调度？还是更麻利的利用交互和治理？亦或者是更欠缺的平安可信和合规？ 对于开发者、企业、云厂商必定有不同的答案，但就像布莱恩•阿瑟在《技术的实质》一书中所说 —— “技术的实质就是对天然的编程，它是一种对景象的捕获，并驾驭这些景象为人类服务。” ...

2022 长沙 · 中国 1024 程序员节已于 10 月 23 - 25 日在长沙、北京等多地圆满举办。本次程序员节以“算力新时代，开源创将来”为流动主题，开设十余场业余主题论坛，笼罩多个技术畛域。龙蜥社区云原生 SIG Owner 王强在1024程序员节北京峰会分享《根底软件云原生挑战》演讲，以下是本次演讲内容：云原生的定义比拟多，有 CNCF 的，也有各大云厂商的一些定义，狭义的云原生是应运而生的零碎架构，生在云上，长在云上，可能充沛地利用云计算的基础设施。cncf 外面的定义更多是关注在技术和架构层面，通过容器、微服务、 不可变基础设施、申明式 API，基于云，实现古代利用架构的构建。 通过这些年的倒退，能够看到筹备或者曾经在生产环境应用容器技术的用户数曾经达到受访者的 93%，这是一个相当高的比例。同时 2021 年 CNCF 也公布年度调查报告，发表逾越鸿沟，成为容器编排的事实标准。能够看到云原生的趋势曾经势不可挡。 那么云原生给咱们带来了哪些变动，对于底层开发同学，这些变动外面蕴含着哪些机会？联合上面的图咱们来看看。 传统状态外面，用户是须要残缺负责软硬件技术栈，不单须要懂你的程序，你的程序执行的软件环境，还须要懂你机器的硬件环境。这种时候真要做一个利用挑战是比拟大的，须要找 OS，还须要管运行利用的物理机器部署到哪里，网络怎么办等等。 到了虚拟化或者 IAAS 场景外面，咱们只须要负责程序和软件原型环境，硬件相干的就交给 IAAS 提供方负责。这外面之前物理环境、物理网络这些就不须要再关怀，只须要关注好本人的利用和根底OS 环境。然而 OS 相干人才是很稀缺的，真正须要解决底层问题，或者想充分发挥底层硬件的性能，这块对用户来说门槛很高。IAAS 相干技术曾经倒退了十多年，整体上也还有不少挑战，不过对下层曾经绝对比拟成熟。 到云原生场景，通过标准化利用运行环境和利用编排零碎，用户就只须要关注业务逻辑，这样可能大大节俭底层相干开销，晋升翻新速度。然而用户的简略，意味着平台层的挑战就更大，须要将利用或者函数执行的 runtime、OS、kernel都进行笼罩，当然挑战和时机并存，也正因为这些挑战，同时也给了根底软件同学更多的机会。 用户界面上移，带给咱们哪些挑战和机会？咱们能够先整体看看云原生零碎的架构。最上层是云原生利用，其中容器场景咱们有一层是利用运行环境——容器镜像，函数场景也还好蕴含语言 runtime。第二层右边是云原生管控，负责利用定义、业务编排、服务框架。左边是咱们外围关注的云原生节点零碎。外面能够分为云原生节点管控、节点平安、节点运维、云原生运行时，云原生存储，云原生网络，以及底层撑持容器运行的容器优化 OS。最上面的是撑持整体云原生的基础设施服务。接下来咱们来看下各个子模块外面的一些具体挑战。 首先来看下最底层的云原生容器 OS。传统的 OS，因为须要思考简单的利用运行环境，须要内置大量的服务和驱动，整体 OS 存在体积臃肿的问题。同时因为OS 用户能够间接批改，没有适合的治理，很容易呈现节点 OS 版本零散，进而集群的 OS 环境状态不统一，问题定位和降级艰难。另外传统操作系统外面蕴含有大量容器场景不须要的包和零碎服务，容易给云原生带来更大的攻击面。另外云原生场景，依据业务流量，动静的对节点进行扩缩容是常态，能够无效升高业务老本。然而动静扩缩容场景，传统 OS 并没有蕴含云原生相干组件，导致 OS 扩容后须要一一下载包，并启动服务，高并发状况下载和启动服务都可能带来稳定性危险，同时也因为这些耗时操作，也会导致节点扩容耗时高，进而影响用户应用。 针对这样系列挑战，社区和云厂商纷纷推出了容器优化 OS，比方阿里云的LifseaOS、AWS 的 BottlerocketOS；红帽的 CoreOS，也足见相干挑战在云原生场景下的共识。 接下来咱们再来看看云原生运行时的挑战。 传统 Linux 原生容器间接跑在节点下面，不同业务和租户的容器通过节点进行隔离，因为共享内核且无无效平安隔离，存在较多的平安危险挑战。同时这种隔离存在资源碎片问题，也无奈无效的利用不同容器的特色实现整体利用率的晋升。针对这些问题，云原生外面又涌现出了运行时。平安容器是比拟早呈现的，通过联合虚拟化技术和容器技术，无效的防止了容器逃逸带来的危险，保障了节点的平安。然而引入的虚拟化层，又同时带来了比拟大的开销，这也是很多人不敢应用平安容器的一个放心。不过有问题其实也就意味着时机，这些年间断呈现了gvisor、firecracker、rund 等相干技术，外围是用来解决平安容器的资源开销挑战问题，能够说通过虚拟化技术和容器联合，开拓了一个新的方向，带来了诸多的机会，通过这些年的倒退也获得了不错的成绩。 ...

近年来，数字化转型成为各行业倒退前行的必要前提。对于金融行业而言，面对于来自政策、新科技等因素的一直冲击，以银行为代表的金融机构在数字化转型浪潮下纷纷按下减速键。 22 年初，金融管理部门陆续公布《金融科技倒退布局（2022~2025）》、《对于银行业保险业数字化转型的领导意见》等重要指导性文件。数字化转型方针与行业新规的相继出台为金融行业数字化转型指明了倒退方向与重点。局部早已开启数字化建设的金融企业，在转型实际的过程中，联合政策领导，施展本身劣势，利用金融科技的翻新引擎，踏上从多点冲破走向深刻倒退的数字化转型之路。 云原生构架能够高效赋能金融企业放慢业务交付、升高经营老本，使金融业务能更从容地接入翻新技术、晋升渠道的宽泛触达能力。因而，云原生技术失去了行业的高度重视，并成为推动金融业数字化转型的重要利器。 9 月 15 日，北京神州数码云科信息技术有限公司副总裁吴静涛学生，受邀参加由《中国金融电脑》杂志社与中国工商银行金融科技研究院联结策动的 2022 年度金融科技翻新引擎技术论坛系列流动。与中国工商银行软件开发核心、交通银行软件开发核心、广发银行研发核心的领导齐聚线上论坛，分享各自云原生技术实际成绩，探讨技术倒退新趋势、新思路，打造更好的金融科技共享生态。 在本次线上论坛中，吴静涛围绕云原生这一热点话题，联合团队多年来的钻研和实际，就数智化时代下业务可持续性和利用可持续性发表了本人的认识。 任何的技术，都存在被颠覆重构的可能性在技术倒退的过程中，为适应市场的走向，随同政策、文化、科技等因素的引领，原有技术被一直的颠覆和重构。以负载平衡为例，随同国内云原生技术热度逐步晋升、信息技术利用翻新在金融场景的减速遍及。如何颠覆负载平衡，重构更合乎逻辑的 IT 构架使其贴合客户的需要，成为新的课题。 可持续性架构，可观测性能力在数智化时代, 业务可持续性很大水平上和利用可持续性相关联。将传统架构和云原生架构对立, 实现兼容和协同, 是金融科技厂商提供的最佳可持续性服务。 作为金融机构数字化转型的长期搭档，为了实现负载平衡的技术冲破，神州云科翻新地提出了以晋升可持续性、可观测性和 AIOps 自动化能力为外围的倒退构想，其外围价值笼罩了打造韧性 IT、晋升数据中心利用率以及强化部门间协同等多个方面。其中，韧性 IT 是指帮忙企业在云原生、自主可控环境下构建 MAA(Maximum Available Architect) 平台，帮忙客户平滑过渡，同时实现多云、多活架构与服务的可持续性；晋升数据中心利用率是指通过组建定向开源协会等动作，助力企业疾速过渡到云原生技术架构与生态体系当中，晋升 DC 利用率；强化部门间协同则是指通过打造无侵入式数据采集能力，帮忙企业构建可观测性平台，在大幅升高故障率的根底上，无效晋升 AIOps 自动化能力。 基于对行业的充沛了解，让云科透明湖负载平衡产品对将来的布局有了清晰认知。咱们在负载平衡颠覆重构的实际中，着力解决利用交付畛域国产化问题，打造高性能、平安可控、兼顾高效能和拓展性设计的卓越产品。帮忙客户最低危险实现换代，晋升可持续性能力。 云原生的挑战与将来随着数字经济的倒退，我国金融科技蓬勃发展，继续推动数字化转型。银行的技术架构体系，也逐渐向着更加凋谢、稳敏双态的趋势演进。更多的将理论场景链接价值网络，通过以客户为核心去赋能业务倒退。 近年来，咱们看到金融行业新一代围绕云计算，大数据与人工智能的基础设施日渐夯实。基于容器、微服务等技术的云原生技术架构倒退进入轨道。 本次线上论坛，与会嘉宾们围绕云原生监控难点、多云环境、发展趋势等问题开展了深刻交换。 “为确保云环境稳固，云环境可观测、监测能力是十分重要的，对此您怎么看？”吴静涛：“可观测性在目前市场上有两个支流模式。第一是以互联网厂商阿里等为主导的 DevOps 模式。早在 2016 年就开始了，开发团队本人负责在运行环境通过利用打点 log 的形式实现数据采集和利用的可观测性。第二是以国内外 APM 厂商为主导的探针模式。通过在代码运行环境中，用字节码注入的形式实现数据采集和可观测性。不过，这两种模式在金融零碎的理论运行中都存在肯定的阻碍。利用打点 log 在生产核心的应用会造成性能降落、运维简单、与开发核心实时数据交互艰难的问题。而 APM 模式也会带来平安危险、性能和可靠性降落等问题。 在 2019 年我主导的一个我的项目中，传统数据中心利用负载平衡产品和云原生环境，通过 API Gateway 的策略控制点来实现数据采集，实现利用可观测性。其长处在于利用现有架构节点，无探针和打点 log 的存在，不影响任何利用的运行平安、性能和可靠性。毛病是颗粒段在应用服务 /API 服务的级别，无奈达到每行代码的细颗粒度。目前这种形式曾经在多家银行利用实际，并解析了银行 90% 以上的利用协定。思考到代码效率是开发核心和测试中心的工作，生产核心采纳无探针的大颗粒度利用可观测性是最佳门路。” 银行数据中心较为简单，如波及多云治理、利用 COTS 组件来构建公有云零碎以及对不同厂商云产品通常进行了肯定水平的垂直整合，从云运维治理上角度也提出了很多挑战，如对资源调度带来很多不便和隔膜，可能影响云服务出现整体性等，请问您如何看到这个问题？吴静涛：数据中心的双活和多云多活都是在利用层面实现。而云原生更多是利用开源和商业组件来实现。因而，对云运维治理提出了很大挑战: 云平台能够负责本人的平安，外部调度与容灾。而无奈实现利用的平安、API 平安与跨区跨域容灾；云平台能够负责 Node/Pod 的治理。但金融企业须要的是利用的生命周期治理，只能本人在云平台根底上投入本人的研发力量；云平台的开源组件，一旦产生停服 / 断供的情况，代码更新进行、技术服务进行，就会呈现新的安全漏洞无奈疾速发现与修复。所以，须要有自主可控的企业提供新的代码树与开源及其周边代码，提供兜底服务。发问：咱们晓得，只有基于云环境上产品研发、部署及经营能力输入优质金融服务，能力施展云原生的价值作用。请您从整体产品研发视角给出一个技术倡议，如何能力更好地施展云原生技术架构作用？吴静涛：“目前，在金融企业的 B/S 传统数据中同时面临双重挑战，即自主可控的挑战和云原生的演进。在客户最关怀的利用可持续性方面, 始终有两个流派：一是双活数据中心 / 多云多活为架构。另一个是 Design for fail，serverless 为架构。 ...

作者：云原生峰会小组 明天，企业应用构建仍然面临很大挑战， 资源如何按需应用，实现降本增效？ 如何在简单零碎架构下， 充沛保障业务稳固和连续性？ 如何做到利用的麻利和业务的智能化？ 如何保障系统的可信和平安？ 企业亟需充沛开掘云计算的技术红利， 助力业务倒退， 发明更多的商业价值。 云原生能够激活利用构建范式， 以解决企业在新期间遇到的挑战。 为探寻企业数字化转型的 将来方向及技术重点 深度解密云原生技术新动向 11 月 5 日 杭州云栖小镇-云原生峰会 阿里云将联手识货、传音、禾连衰弱、新东方、心动网络等实战企业技术负责人 向你收回邀请 11 月 5 日，杭州云栖小镇 B 馆，咱们不见不散！ 扫码或者点击此处，即可报名参会。

10 月 24 日，2022 年拓数派产品发布会在上海胜利举办。拓数派创始人兼 CEO 冯雷、拓数派 COO 陆公瑜、拓数派 CTO 郭罡、东吴证券投行联席总经理席平健等领导及业内专家缺席流动，作为拓数派本年度最受关注的产品发布会，大会吸引了泛滥来自行业及机构的嘉宾加入会议。 拓数派创始人兼 CEO 冯雷在收场演讲中向与会嘉宾分享拓数派的倒退策略与产品理念。他示意，云计算 1.0 时代，曾经造就了一批 IaaS 巨头，云计算的 2.0 浪潮，正在世界范畴内造就一批云原生小伟人，在这个浪潮中，拓数派秉承 “最终实现大数据愿景” 的产品理念，围绕「数据」、「发现」与「计算」三个方面，趁势而为打造了云原生 eMPP 数据库 PieCloudDB，作为寰球为数不多的存算拆散云原生架构剖析型数据库之一，PieCloudDB 冲破了 PC 时代计算平台的限度，从新打造云上的数据库内核，助力企业开释数据价值最大化，打造高质量倒退新劣势，并在新基建中承当牢靠和可控的云数据库底座。 冯雷提到， PieCloudDB 发明的全新 eMPP 分布式技术，让数据能够在云中有限的增长，云上数据既是隔离也是连通。从平安的角度是隔离，同时具备数据共享的能力。计算资源也可在云上弹性调配，有查问计算工作的时候按需启动，依照应用工夫和规模计算成本，而不是购买大量服务器静置为不确定的应用额定领取老本，这样使得计算模型在云上会以更低成本提供指数级的存储和计算资源，帮忙甲方的业务模型发现新洞察或者进步精准度，从而建设竞争壁垒。 同时，冯雷也预报了 PieCloudDB “云上云” 版本将会在明年上半年重磅公布。 演讲最初，冯雷示意，随着数据量和计算能力的爆发式增长，今后会有越来越多的企业将利用向云上迁徙，云原生数据库将会成为数据云时代的重要策略抓手，云原生架构也会变得越来越受关注。将来，拓数派将继续深耕云原生数据库产品研发，致力于使用突破性翻新实践、独创的云原生数据库旗舰产品以及之上的算法和数学模型，建设下一代云原生数据平台的前沿规范，为数据库行业全面走向云时代火上浇油。大势观澜，让咱们趁势而为，独特发明云原生数据库和云上数据计算的有限可能！在产品公布环节，拓数派 CTO 郭罡和核心技术合伙人展现了 PieCloudDB 的核心技术劣势，并分享了社区版与企业版的产品个性。郭罡指出，传统分布式数据库系统大多是 MPP（大规模并行计算）架构。MPP 架构的数据库以 PC 服务器为单位，通过组群形式来扩大存储和计算。随着数据量的一直攀升，企业对数据库的要求也越来越高，在应用过程中，传统数据库解决方案也面临着诸多的瓶颈，如无奈跨集群拜访数据，无奈启动更多算力实现冷数据的实时计算，无奈并发运行多个高维度加强 BI 计算等。 PieCloudDB 齐全基于云计算架构的弹性并行计算，解决基于 PC 的传统 MPP 的缺点。在 PieCloudDB，存储和计算各自作为两个独立变量，各自在云里弹性伸缩，同时能够实现霎时扩缩容。 并且产品容许用户对于云中数据同时开启多个集群进行数据计算，能够继续将所有数据在云中存储，为已有的利用和将来的利用真正实现数据共享。在产品公布环节，郭罡还着重分享了 PieCloudDB 的几个关键技术劣势：PieCloudDB 使用元数据 - 计算 - 数据拆散的三层架构，实现了云上存储资源与计算资源的独立治理。云上计算资源亦可弹性调配，有查问计算工作的时候按需启动，依照应用工夫和规模计算成本。在云上，PieCloudDB 利用 eMPP（elastic MPP）架构，实现多集群并发执行工作。企业可灵便进行扩缩容，随着负载的变动实现高效的伸缩，轻松应答 PB 级海量数据。PieCloudDB 可依据客户需要在任何 IaaS 上运行，也能够通过自带的 K8s 间接在裸硬件装置。借助这种 “不受限于基础架构” 的跨云部署，企业能够买通的多云的数据管道，解锁对特定 IaaS 云的依赖并取得云资源议价权。PieCloudDB 采纳全新的存储缓存架构设计。在计算层，各个计算节点针对元数据和用户数据都设计了多层缓存构造，防止网络提早和数据挪动，进步计算效率，缩小零碎响应工夫，保障用户的实时性需要。PieCloudDB 提供企业级通明数据加密。采纳实时加密，高强度算法，多级密钥等技术爱护数据安全。PieCloudDB 还反对包含数据库、表级别受权治理等欠缺的平安及权限治理，帮忙企业零碎的治理表级别的权限。 ...

随着 Kubernetes 的倒退和改良，新的平安威逼和危险也逐步向 K8s 转移，因而 K8s 安全性变得越来越重要，而爱护 K8s 集群已成为 DevOps 团队不容忽视的重要工作。K8s 有多种实现类型（本地、云治理、混合等）、泛滥开源反对工具和各种配置设置，且爱护运行容器工作负载的任何平安敏感架构的需要也在增长。 依据 CNCF 的 K8s 平安审计考察，攻击者能够通过利用各种 K8s 破绽和几种标准配置进行非法行为。明天，咱们将探讨一些施行保障 K8s 平安的最佳实际。 K8s 和 K8s 集群K8s 是一个用于治理容器（容器化应用程序）的零碎，容器则能够了解为是一个轻量级的虚拟机。要创立应用程序，就须要先创立一些容器并应用 K8s 来治理这些容器。这的确是一个宏大且疾速扩大的生态系统，并且 K8s 的设施、反对和工具绝对比拟容易取得。K8s 能够立刻生成和扩大容器，并跨所有容器治理存储。 K8s 集群是蕴含所有 K8s 组件的K8s 零碎。集群能够在物理机（如 PC 或笔记本电脑）或虚拟机上运行。如果你有一台机器运行残缺的 K8s 零碎，则该机器托管您的 K8s 集群；假如你有两台机器运行 K8s，这两台机器都会组织你的 K8s 集群。集群能够在物理机和虚拟机的任意组合上运行。 7步爱护 K8s 集群平安接下来咱们一起看看企业应该施行哪些平安最佳实际来确保其 K8s 集群的安全性。 1. 将 K8s 降级到最新版本最根本且常常被忽视的平安最佳实际是将 K8s 生态系统放弃最新状态。企业将受害于新的平安性能和谬误跟踪更新以及变体版本。此外，在启动到生产集群之前，请在测试环境中应用最新的残缺版本。 2. 验证 Kubernetes API 服务器Kubernetes API 服务器，也被称为 Kube-API 服务器，是 K8s 集群的外围。K8s API 是 K8s 集群的次要拜访点。管理员或服务帐户能够通过命令行实用程序 kubectl、REST API 调用或其余客户端 SDK 拜访 API。服务器提供拜访并保障集群是可操作的。所有在集群外部调用的 API 尝试都应该应用加密的传输层安全性。倡议采纳完全符合访问控制规定的 API 服务器的 API 身份验证办法。 ...

多租户可视化 K8s 治理平台 KubeCube近日迎来了新版本的公布，新版本减少了 K8s 版本转化、HNC GA 版本适配、审计信息国际化、warden 被动上报模式，为集群和我的项目设置 Ingress 域名后缀等个性，也修复了若干已知问题，详见 ChangeLog。 该版本中最次要的个性是 Version-Conversion 能力的反对，使得接入 KubeCube 的用户无需感知被 KubeCube 接管的 K8s 集群版本，能够应用指定版本的 K8s API 来操作 K8s 资源，KubeCube 会做自适应转化；同时 KubeCube 也将这个能力包装成 SDK 供内部应用。 为什么须要多 K8s 版本转化？在理论的生产场景中，用户的 K8s 集群往往固置于某一稳固版本，并随着工夫的推移，在该 K8s 集群中积淀了大量的业务、工具、计划等，同时 K8s 社区又会一直的推出更高的版本，此时降级 K8s 版本往往须要比拟高的代价。 K8s 的版本升级，并不总是保障 API 的完满兼容，绝大多数的 API 会经验从 Development level --> Alpha level --> Beta level --> Stable level 的倒退阶段，现实状况下，用户应该应用 Stable level 的 API 用于生产环境，然而事实中，用户所应用的某一资源的 API 很可能处于 Stable level 以下的阶段，比方 extensions/v1beta1 的 Deployment 和 apps/v1 的 Deployment。详见 K8S API 变动布局。 ...

download：云原生利用架构设计与开发实战网潘货区数据库什么时候分表？ 子数据库和子表要解决的是现有海量数据拜访的性能瓶颈，以及一直减少的数据量的架构前瞻。数据库划分和表划分的要害指标是否是数据量。咱们以fire100.top网站的资源表t_resource为例。零碎运行初期，每天只上传几十个资源。此时应用单数据库单表的形式足以撑持零碎的存储，数据量小简直没有任何数据库性能瓶颈。然而有一天，一个神秘的流量进来了，零碎产生的资源数据量忽然减少到10万甚至上百万。此时资源表数据量达到数千万，查问响应变得迟缓，数据库的性能瓶颈逐步浮现。以MySQL数据库为例，单个表的数据量达到亿级。当通过增加索引和SQL调优等传统优化策略取得的性能晋升依然很小时，能够思考划分数据库和表。既然MySQL在存储海量数据时会呈现性能瓶颈，是否能够思考用其余计划代替？比方高性能非关系数据库MongoDB？能够，但这取决于存储的数据类型！目前互联网上大多数公司的外围数据简直都存储在关系数据库(MySQL、Oracle等。)，因为它们领有堪比NoSQL的稳定性和可靠性，产品的成熟生态系统，以及其余存储工具不具备的外围交易个性。不过还是能够思考用MongoDB来评论和赞美这些非核心数据。如何划分数据库和表 子数据库和子表的外围是将数据分片并绝对平均地路由到不同的数据库和表中，分片后疾速定位数据并整合搜寻后果。 图书馆和桌子能够从垂直(纵向)和程度(横向)两个纬度来划分。咱们以经典的订单业务为例，看看如何拆分。 垂直决裂1.垂直存储一般来说，垂直数据库是依照业务和性能的维度划分的，不同的业务数据放在不同的数据库中，外围概念库是专用的。依据业务类型，将数据拆分到多个数据库中，订单、领取、会员、积分等表放在相应的订单数据库、领取数据库、会员数据库、积分数据库中。不同服务禁止跨数据库直连，获取的对方业务数据全副通过API接口交互，这也是微服务拆分的重要依据。 垂直的数据库划分很大水平上取决于业务的划分，然而有时候业务之间的划分并不是那么清晰，比方电商中订单数据的拆分，其余很多业务都是依赖订单数据的，有时候界线划分的并不好。垂直子数据库将一个数据库的压力扩散到多个数据库，进步了局部数据库的性能。然而没有解决单个表数据量大带来的性能问题，须要前面的子表来解决。2.垂直子表对业务中字段较多的大表进行竖表拆分。个别将宽业务表中的独立字段或不常用字段拆分成独自的数据表，这是一种将大表拆分成小表的模式。例如，一个t_order表有几十个字段，其中订单金额的相干字段是常常计算的。为了不影响订单表t_order的性能，能够将order amount的相干字段离开，保护一个独自的t_order_price_expansion表，使每个表只存储原表的一部分字段，这些字段由订单号order_no关联，而后将拆分后的表路由到不同的库。 数据库是以行为为单位将数据加载到内存中的，所以拆分后的外围表大部分是拜访频率高的字段，字段的长度也较短，这样能够将更多的数据加载到内存中，缩小磁盘IO，进步索引查问的命中率，进一步提高数据库性能。程度决裂数据库和表垂直拆散后，依然会存在单个数据库和表中数据过多的问题。当咱们的利用无奈进行细粒度的垂直划分时，单个数据库读写和存储的性能依然存在瓶颈。这时候就须要配合数据库和表的横向拆散。1、图书馆的程度横向数据库拆分是将同一个表依照肯定的规定拆分成不同的数据库，每个数据库能够位于不同的服务器上，从而实现横向扩大，是进步数据库性能的罕用办法。 例如，db_orde_1和db_order_2的数据库中有雷同的t_order表。当咱们拜访一个订单时，咱们能够通过对订单的订单号取模来指定该订单应该在哪个数据库中操作:订单号mod 2(数据库实例的数量)。这种计划往往能够解决单库存和性能瓶颈的问题，然而因为同一个表散布在不同的数据库中，数据拜访须要额定的路由工作，因而零碎的复杂度也有所提高。2.程度表在同一个数据库中，一个数据量很大的表依照肯定的规定被分成若干个构造雷同的表，每个表只存储原表的一部分数据。例如，一个t_order订单表有900万个数据，t_order_1、t_order_2和t_order_3三个表被程度拆分。每个表有300万个数据，以此类推。 程度表尽管拆分了表，然而子表都在同一个数据库实例中，只是解决了单个表数据过多的问题，并没有把拆分的表扩散到不同的机器上，依然在抢夺CPU、内存、网络IO等。同一个物理机器。为了进一步提高性能，须要将拆分后的表扩散到不同的数据库中，以达到分布式的成果。 存在哪个数据库的表。在将来，会有一个问题。一个表将呈现在多个数据库中。到底应该寄存在哪个数据库的哪个表呢？咱们在下面曾经屡次提到某些规定。实际上，这个规定是一个路由算法，它决定了一个数据应该存储在哪个数据库的哪个表中。常见的有取模算法、范畴限度算法、范畴+取模算法和预约义算法。1.模块化算法关键字段模块化(从散列后果中取余数hash(XXX) mod N)，其中N是数据库实例或子表的数量)是最常见的路由办法。以t_order表为例，先将数据库从0到N-1编号，而后对t_order表中的order number字段取模hash (order_no) mod n失去余数I，I=0存储第一个库，i=1存储第二个库，i=2存储第三个库，以此类推。 雷同程序的数据将落在雷同的数据库和表中。查问时应用同样的规定，以t_order订单号作为查问条件，能够疾速定位数据。劣势实现简略，数据分布绝对平均，申请不容易命中一个数据库。劣势模块化算法对集群的扩大反对不是很敌对。集群中有n个数据库real hash (user _ id) mod n。当某台机器停机时，本应达到数据库的申请不能被解决，而后被抛弃的实例将被踢出集群。此时，机器号缩小算法扭转hash(user_id) mod N-1，雷同的用户数据落在不同的数据库中。本机复原后，以user_id为条件的用户数据查问会少一些。2.范畴限度算法范畴限度算法由一些范畴字段宰割，如工夫或ID区域。用户表t_user分为三个表:t_user_1、t_user_2和t_user_3。而后将user_id范畴从1到1000 W的用户数据放入t_user_1，1000到2000 W放入t_user_2，2000到3000 W放入t，日期范畴也是如此。劣势单表数据量可控。横向扩大很简略，减少节点即可，不须要迁徙其余碎片化数据。劣势因为间断切片可能存在数据热点，比方按工夫域切片时，如果某段时间(如双11)订单急剧减少，存储11月数据的表可能会频繁读写，而存储在其余切片表中的历史数据很少被查问，导致数据歪斜，数据库压力散布不平均。 3.范畴+模数算法为了防止热数据的问题，咱们能够优化下限算法。这次咱们先通过range算法定义每个数据库的用户表t_user只存储1000w的数据，第一个db_order_1库存的userId从1到1000 W，第二个数据库是10002000w，第三个数据库是20003000w，以此类推。 在每个数据库中，用户表t_user被拆分成t_user_1、t_user_2、t_user_3等。，userd模路由到相应的表。无效防止了数据分布不平均的问题，数据库的横向扩大也很简略。间接增加实例不须要迁徙历史数据。4.地理位置碎片化地理位置碎片化其实是一个更大的范畴，是以城市或者区域来划分的。比方华东和华北的数据放在不同的碎片化数据库和表中。5.预约义算法预约义算法是事后明确晓得子数据库和子表的数量，它能够间接将某一类数据路由到指定的数据库或表，甚至在查问的时候。子数据库和子表的问题不难发现，与拆分前的单数据库、单表相比，当初零碎的数据存储架构曾经变得非常复杂。看几个有代表性的问题，比方:分页、排序和跨节点联结查问分页、排序、联查，这些开发中频繁应用的看似一般的操作，在数据库和表划分后却是令人头疼的事件。查问扩散在不同库中的表的数据，而后将所有后果汇总合并提供给用户。例如，咱们须要查问11月和12月的订单数据。如果两个月的数据扩散在不同的数据库实例中，咱们须要查问两个数据库相干的数据。合并、排序和分页数据的过程很简单。

文/龙蜥社区云原生 SIG 前言局部秘密容器是 Cloud Native Computing Foundation（CNCF）下的一个新的 Sandbox 我的项目。秘密容器我的项目基于 CPU 可信执行环境（TEE）技术，并与云原生容器以及 Kubernetes 技术联合，构建出新的软件架构，其设计目标是为运行在不受用户管制的云计算基础设施上的敏感数据和利用提供平安可信的计算环境。秘密容器我的项目的指标是标准化秘密计算在容器技术层面的实现形式，屏蔽多种 CPU TEE 的底层实现细节，在应用体感上放弃与应用一般容器进行开发和部署的一致性。阿里云还将秘密解决方案推广到龙蜥社区， 并基于龙蜥社区构建开箱即用的秘密容器解决方案。 CPU TEE（如 AMD SEV、Intel SGX 和 Intel TDX）可能提供处理器微架构级内存访问控制与隔离机制，在内存级提供加密和完整性爱护，减少新的指令集与处理器运行模式，禁止不可信设施通过 DMA 拜访加密内存，目标是避免在计算过程中泄露或篡改敏感数据和代码。CPU TEE 建设了一种新的威逼模型，用户敏感数据和利用的安全性无需由云服务提供商及其基础设施管理员来保障，而仅依赖于硬件级别的TEE 爱护技术。秘密容器我的项目的指标是在容器级别标准化秘密计算，并简化其在 Kubernetes 的应用。这是为了让 Kubernetes 用户可能应用相熟的工作流和工具部署秘密容器工作负载，而无需深刻理解底层秘密计算技术。秘密容器将反对多种环境，包含公共云、本地和边缘计算。 目前秘密容器我的项目的外围参与者包含阿里云、AMD、ARM、IBM、Intel、Microsoft、Red Hat、Rivos 等在内的软件和硬件公司。阿里云作为该我的项目核心技术的次要贡献者，在秘密容器社区不久前公布的 0.1.0 release 中，阿里云在该我的项目以及相干依赖我的项目的奉献比例约占 20%，位居社区第二，仅次于 Intel。该我的项目 9 个外围子项目中有 5 个由阿里云的 Maintainer 负责，我的项目的技术领导委员会 10 名成员中，阿里云占有 2 个席位。 技术架构秘密容器有两种典型架构： Pod 级秘密容器：该架构基于 Kata Containers 我的项目，最大区别是将基于一般虚拟化技术实现的轻量级 Sandbox Pod替换为基于秘密计算技术实现的轻量级 TEE Pod，目标是将特定租户的整个 Pod 以及其中的容器运行在受 CPU TEE 爱护的执行环境中。除此之外，TEE Pod 外部还额定集成了 image-rs 和 attestation-agent 等组件，它们负责实现容器镜像的拉取、受权、验签、解密、近程证实以及机密注入等平安个性。Pod 级秘密容器反对 AMD SEV 以及 Intel TDX 秘密虚拟机。过程级秘密容器：该架构基于阿里云、Intel 与蚂蚁单干的 CNCF 我的项目 Inclavare Containers。租户的容器运行在反对 Intel SGX Enclave 的CPU TEE中。该架构的特别之处在于 Pod 由容器工作负载运行在 LibOS（目前反对蚂蚁 Occlum，未来会反对Intel Gramine）之上，并由 enclave-agent 对容器的生命周期进行治理。除此之外的外围组件 image-rs 和 attestation-agent 组件均与 Pod 级秘密容器架构雷同。秘密容器的根本运行过程为： ...

近日，国内企业级云原生解决方案的领军企业灵雀云，携全栈云原生开放平台ACP（Alauda Container Platform)正式登陆VMware云市场。VMware云市场(Cloud Marketplace)由VMware寰球经营，提供在多云环境内发现和部署教训证的第三方和开源解决方案。灵雀云ACP提供基于云原生技术的全栈公有云平台和服务，将为VMware的企业用户在云原生基础设施、利用架构、开发流程、数据服务等方面提供更加丰盛多元的抉择。在企业数字化转型的过程中，业务零碎上云及利用现代化革新已成为企业的必然选择。从传统IT架构零碎迁徙至基于云计算的微服务架构和云原生利用体系，将实现企业业务能力、数据能力和技术能力的平台赋能和能力复用，是企业数字化转型的必由之路，也是灵雀云与VMware两家深耕云原生基础设施畛域的企业始终以来的共识。灵雀云全栈云原生开放平台ACP，针对企业级要害业务具备主机系统可靠性、安全性、高性能和可扩展性，技术架构更贴合企业业务利用，满足企业级利用逐渐向容器化、微服务化过渡的宽泛需要，反对企业建设一个笼罩内外部各环节和组织构造的公有云平台。灵雀云ACP有以下劣势：· 以利用为核心：笼罩利用全生命周期治理，可视化利用编排，一键式利用部署，版本治理，无缝降级，反对利用和服务秒级弹性伸缩；· 全栈开箱即用：一体全栈，各服务模块作为平台组件，开箱即用，疾速搭建；· 全面反对微服务架构和DevOps：反对 SpringCloud、ServiceMesh 服务治理架构，反对宽泛的 DevOps 工具链；· 数据及中间件企业级反对：针对罕用数据组件，如 MySQL、Redis、RabbitMQ、kafka等提供企业级反对和服务。灵雀云ACP可服务于不同规模的企业，反对治理各种复杂度的基础设施环境、组织构造清晰的部门建制和人员团队。让资源配置更好地适应利用的理论需要，从而改良基础设施的敏捷性、自动化、效率和老本优化，驱动业务翻新增长。将来，灵雀云将携手VMware，为寰球企业用户及合作伙伴，提供更加优质、便捷的云原生技术和服务，为企业IT的开发、测试、部署、运维、治理等能力提供数字化转型外围撑持。上一篇：数字化转型新抓手——《企业应用现代化行动指南》下一篇：企业高管IT策略指南——为何抉择容器与Kubernetes

作者：李涛（吕风） Koordinator [ 1] 继上次 [v0.6版本 [ 2] ](https://mp.weixin.qq.com/s?__...)公布后，通过 Koordinator 社区的致力，咱们迎来了具备重大意义的 v0.7 版本。在这个版本中着重建设了机器学习、大数据场景须要的任务调度能力，例如 Coscheduling、ElasticQuota 和精细化的 GPU 共享调度能力。并在调度问题诊断剖析方面失去了加强，重调度器也极大的晋升了安全性，升高了重调度的危险。 版本性能个性解读任务调度Enhanced Coscheduling  Gang scheduling 是在并发零碎中将多个相关联的过程调度到不同处理器上同时运行的策略，其最次要的准则是保障所有相关联的过程可能同时启动，避免局部过程的异样，导致整个关联过程组的阻塞。例如当提交一个 Job 时会产生多个工作，这些工作冀望要么全副调度胜利，要么全副失败。这种需要称为 All-or-Nothing，对应的实现被称作 Gang Scheduling(or Coscheduling) 。 Koordinator 在启动之初，冀望反对 Kubernetes 多种工作负载的混部调度，进步工作负载的运行时效率和可靠性，其中就包含了机器学习和大数据畛域中宽泛存在的具备 All-or-Nothing 需要的作业负载。为了解决 All-or-Nothing 调度需要，Koordinator v0.7.0 基于社区已有的 Coscheduling 实现了 Enhanced Coscheduling。 Enhanced Coscheduling 秉承着 Koordiantor 兼容社区的准则，齐全兼容社区 scheduler-plugins/Coscheduling 和依赖的 PodGroup CRD。曾经应用 PodGroup 的用户能够无缝降级到 Koordinator。 除此之外，Enhanced Coscheduling 还实现了如下加强能力： 1. 反对 Strict 和 NonStrict 两种模式scheduler-plugins/Coscheduling 在调度失败时会 Reject 所有调配到资源但处于 Wait 状态的 Pod。这种模式咱们定义为 Strict 模式，也是默认模式。但这种模式对于体量较大的 Job 并不是很敌对，有可能会导致这种大体量的 Job 拿不到资源。为了解决这个问题，咱们容许调度失败时不立刻 Reject，并通过重试调度尝试拿到资源满足 MinMember。这种模式咱们称为 NonStrict。尽管这种模式对于体量大的 Job 敌对，能够让这种 Job 更快的调度实现，但同时也减少了资源死锁的危险。后续 Koordinator 会提供 NonStrict 模式下解决死锁的计划实现。 ...

作者：草谷 前言MSE 提供了托管版的 ZooKeeper，蕴含比开源 ZooKeeper 更弱小更稳固的性能，能帮忙您免去运维 ZooKeeper 集群的懊恼，当咱们须要从自建 ZooKeeper 迁徙到 MSE ZooKeeper 下面时，往往依赖旧集群的数据，MSE 提供了多种数据迁徙的计划，其中支流的计划能够通过 MSE Sync 进行实时同步，这样可能达到平滑不停机的目标，本文将介绍另外一种数据迁徙的形式，次要针对业务反对停机的场景，进行一个补充，操作相比更加简略疾速。 实现原理 在对 ZooKeeper 进行了若干次事务操作之后，ZooKeeper 会将内存数据全量写入到本地磁盘中，生成一个 snapshot 结尾的快照文件，这个快照文件就蕴含了该集群的全量数据。同时 ZooKeeper 在节点启动的时候，会首先加载该快照文件进行一次数据初始化。 基于此原理，咱们能够将任意要迁徙集群的快照文件，放到指标集群的快照门路中，而后重启指标集群就能够将迁徙集群的数据加载到本人的内存中了，这样就实现了一次全量数据的迁徙。 数据导入实际 步骤一：获取快照文件“反对开源 ZooKeeper 3.4.x～3.8.x 的数据迁徙导入到 MSE ZooKeeper” 咱们先找到自建 ZooKeeper 的 Snap 缓存文件： 文件名为 “snapshot.xxx”格局的：是 ZooKeeper 某个时刻的全量数据，ZooKeeper 会定时写到磁盘中的。 文件门路snapshot.xxx 文件的存储门路：会配置在 ZooKeeper 的 zoo.cfg（zoo.cfg 默认放在 zookeeper 目录的 conf 文件夹下）配置文件中，dataDir 项，例如： dataDir=/home/admin/zookeeper/zkData获取文件snapshot.xxx 个别在目录中会存在多个，拿最近工夫生成那个即可： 步骤二 ：筹备 MSE 集群以下表格供参考，购买还须要参考 QPS/TPS 等维度的束缚，例如读写数据较小，QPS/TPS 相应也能进步，具体以业务场景为准： 步骤三：上传快照文件从注册配置核心列表页点击你购买的实例，进入 ZooKeeper 的根底信息页： 从“节点治理”进入治理页面： ...

作者：王彬|杏祉尧|黄枫 我的项目背景贵州酒店团体有限公司于 2019 年 2 月 28 日注册成立，是经贵州省人民政府批准并受权省国资委履行出资人职责的省管大一型企业，全资及控股子企业 23 家，自营及委管酒店（我的项目）80 余家，客房近 1.3 万间。 酒店团体组建以来，构建了以酒店经营与治理为外围业务，以游览商品、教育培训、会议会展、电商科技、黔菜餐饮为支柱业务的“1+N”主营业务架构，正逐渐培养打造系列酒店、特色餐饮、教育培训等游览产业化服务品牌体系。 在 2020 年，成立了贵州乐旅网络科技有限公司专门负责酒店团体信息化建设，贵州乐旅网络科技有限公司肩负着建设酒店团体现代化信息系统的使命，初期在三四个人的疾速迭代下，疾速构建起了撑持全团体内外部业务的信息系统。随着公司的倒退和市场需求的迅速变动，乐旅网络科技也一直壮大，从最后的三四个人倒退到了十几人，零碎模块越来越多，同时各种问题也开始浮现。 现状问题&剖析酒店团体的信息系统最后部署在阿里云 ECS 上。零碎依照微服务的架构拆分成多个组件，基于 ASP.NET Core 框架开发。在开发运维过程中遇到一系列问题： 组件短少扩展性：团体的业务有显著的峰谷个性，平台会定期上线一些流动，如土特产秒杀，酒店房间优惠，通过这些流动，用户能够获取抢购贵州名牌白酒的资格等。在流动期间访问量微小，峰值最高能达到几十万 qps，是平时的几十倍。同时信息系统仍旧连续第一代架构，扩展性不好，没法做到很好的弹性伸缩，对于越来越大的流量，零碎稳定性问题愈发凸显。 多环境建设不欠缺：线下测试环境与线上生产环境隔离，线下测试中并不能齐全笼罩线上生产环境的场景，在上线时会呈现须要上线的组件在线上实在环境中呈现预期之外的异样，须要疾速复原，这就须要有很好的版本治理，这一块也是缺失的。 团队协同效率低：整个零碎有多个模块，扩散在不同团队，ECS 机器也都是独立保护，发版过程须要上下游链路一起协同，依照依赖关系程序公布，耗费工夫长，协同难度大。 监控零碎不欠缺：运行状态没有对立的观测平台，遇到问题也只能子系统别离排查，且短少问题排查帮助工具。 技术选型&比照为了更好的对应零碎倒退的须要，乐旅网络科技决定同阿里云达成策略单干，基于阿里云打造信息平台 2.0。 在新架构的设计上，针对以后遇到的痛点问题，项目组在技术选型时定下了以下几个指标： 自动化运维，团队需要多，开发工作重，专门负责运维的同学并不多，心愿 2.0 零碎能够借助体系化的运维平台，晋升运维效率，大幅加重运维压力。自动弹缩，团队的业务流动较多，流动到来时有不可预知的流量波峰，之前通过预估扩容的形式存在预估不准和扩大艰难的问题，2.0 零碎心愿能够更加简略的扩缩零碎，最好可能通过自动化的形式防止反复的部署和下线操作。版本治理，测试环境并不能齐全模仿线上生产环境，新上线的组件上线后可能会呈现问题，心愿可能有版本治理的工具，当遇到问题时，能够很不便的切换到指定版本，实现代码资产的可选治理。团队协同，目前团队合作次要靠人为线下沟通，不同团队的组件都由本人保护，ECS 机器彼此也都权限隔离，2.0 版本心愿能够应用对立的零碎管理权限，实现不同团队，不同角色都能够应用同一套权限体系，简化团队之间协同的工作。监控平台，目前的零碎短少监控，于实时运行状态监控简直没有，目前只有基于机器运行指标的监控。各组件依照开发人员设计自行打日志，当呈现问题时，排查问题链路简短，且没法做到对立的链路追踪。因为零碎短少量化指标，对系统的把控性偏低，没法做到异样预警，也没法很好的做针对性的继续优化。2.0 零碎心愿在这方面有所改观，能多维度的对系统进行监控，加强对系统的控制力。为此，项目组在阿里云上进行了第一轮全面筛选，很快选型指标放大到了自建 K8s 和 SAE，并对这两种技术进行了一系列的比对，次要比对指标如下： 比照这两种技术后，思考到自建 K8s 自身的复杂性，对技术栈的深度，技术的继续投入和业务的收益，项目组进行了多方面掂量，最终抉择了 SAE。 SAE 这款产品在免运维，自动弹缩，可观测等方面都深度合乎酒店团体以后我的项目的需要，项目组在最后选型时就对以下几个性能十分感兴趣： 免运维：SAE 可能免运维底层基础设施，例如 IaaS、K8s、微服务组件和 APM 组件等，无需自建 ZooKeeper、Eureka、Consul 和 Skywalking 等，极大升高开发运维老本。提供商业化稳定性兜底。 自动弹缩：SAE 提供了精准容量+弹性+限流降级一整套高可用产品化解决方案。通过该计划，SAE 可能帮忙利用轻松应答流量顶峰，在保障业务 SLA 的同时也节俭了资源老本。 体系化监控：SAE 无缝集成的 ARMS 产品，具备白屏化利用监控和诊断能力，可用定位到慢 SQL、慢办法、办法的调用堆栈、对于线上问题的剖析、排查、预警和解决，提供强有力反对，节俭大量的排查工夫。所以，最终项目组毫无疑问的抉择了 SAE。 我的项目开发过程&成果在项目组确定选型之后，项目组很快开始着手迁徙零碎到 SAE，迁徙的过程比原打算的更加顺利，因为一开始设计团体的零碎时便是基于微服务理念的，所以 ECS 上的组件迁徙到 SAE 可能做到很顺滑，代码层面没有大的改变，迁徙过程见下图： ...

▼立刻下载▼保姆级教程：一看就懂的《企业应用现代化行动指南》（附下载）ebook下载 | 《企业高管IT策略指南——搭建微服务架构》ebook下载 | 灵雀云公布《 企业高管IT策略指南——为何抉择容器与Kubernetes》IT架构师必读的DevOps落地行动指南超实用转型攻略！《2022央国企云原生落地实用指南》重磅公布（附下载链接）超硬核攻略！《2022金融云原生落地实用指南》重磅公布（附下载地址）

在数字化浪潮下，利用现代化曾经成为企业数字化翻新的基石。 云原生利用正在爆发性增长。国内权威出名剖析机构Gartner预测到2025年，云原生平台将成为95%以上新数字倡导的根底，而在2021年这一比例只有不到 40%。IDC预测，到2025年，数字经济将催生出超过5亿个新利用/服务，90% 的应用程序将是云原生应用程序。 在此背景下，灵雀云联结云原生技术实际联盟（CNBPA）独特推出了《企业应用现代化行动指南》，为企业应用现代化提供零碎残缺、切实可行的转型参考和领导，帮忙企业在强烈的数字化竞争中破局而出。 >您能够从中理解：· 利用现代化所需基本概念及关键技术· 企业应用上云支流门路都有哪些· 什么利用适宜进行容器化革新· 利用上云有无可参考的判断规范· DevOps能为您的企业提供何种收益· DevOps落地常见误区都有什么· 常见微服务架构如何选型· 出名头部企业应用现代化先锋实际  ......扫描上方二维码，立刻获取完整版电子书。

9月16日，在2022中国数据中心市场年会“降本增效分论坛”上，《云原生FinOps能力成熟度模型》规范正式启动，作为FinOps产业规范工作组首批发动成员和云原生技术畛域的惟一代表企业，灵雀云缺席并参加授牌。 随着云计算的深刻，企业上云资源配置不合理、异构资源难治理、计费形式不灵便等问题逐步浮出水面。据Gartner 公司的考察，45 %向云计算架构进行“晋升和转移”的企业示意呈现了更高的老本，甚至在第一年超支70 %，因而晋升资源利用率，实现降本增效，已成为以后企业关注的重点，无关FinOps（Financial Operations）的探讨也始终热度不减。 FinOps 产业规范工作组是在中国产业互联网倒退联盟领导下，由多家企事业单位联结发动成立的组织，致力于通过钻研和制订云财务管理相干规范体系，促成企业更加高效正当地洽购和应用云服务，升高企业数字化转型累赘。灵雀云作为云原生技术领军企业成为联盟首批发动成员单位，将云原生“降本增效”的最佳实际带入FinOps规范制订工作中。 始终以来，灵雀云认为“降本增效”是企业应用云原生技术的最大价值之一。 云计算以资源虚拟化为底层根底，以云原生为技术“内核”，向下买通灵便、高效调度、异构资源交融的基础设施资源，构建全域数据高速互联与算力全笼罩的整体架构；向上撑持研发效力晋升，疾速响应业务需要，驱动传统行业技术和业务交融，推动企业数字化倒退。 云原生技术有助于企业IT“降本增效”次要体现在两个方面：1、信息统计追踪实现老本可视：细粒度灵便计量，并继续追踪；发展多维度老本可视化剖析；综合理论业务，正当的布局；2、利用降本技术实现老本优化：容量度量，正确评估利用容量，适合设置资源申请；利用混部，业务利用弹性混部，回收波谷冗余；架构优化，优化软件硬件架构，GPU池化共享等。 随着云原生技术与业务利用更加深度交融，能够帮忙企业实现更加灵便的弹性资源供应、智能的自动化流量调控。另外，容器、微服务、服务网格、无服务器等技术逐步成熟，使得基础设施资源也正在以更加灵便的形式与业务利用联合，最终实现经营降本增效。 将来，灵雀云将充分发挥本身产品技术劣势，与FinOps产业规范工作组一起积极开展《云原生FinOps能力成熟度模型》等规范制订、报告公布、技术研究、测评认证、市场流动等工作，推动云原生技术和其最佳实际融入企业业务和文化，进步组织理解云老本、衡量老本的能力；推动云原生FinOps落地，优化企业上云老本，实现企业上云的降本增效。 上一篇：2022企业云原生落地实用指南下一篇：揭秘5名运维如何轻松治理数亿级流量零碎

前不久，2022年中国航空数字化转型高峰论坛在上海顺利举办，灵雀云首席解决方案专家杜东明受邀进行了《云原生赋能航空企业数字化转型》的主题分享，和来自东方航空、北方航空、厦门航空、东海航空、长龙航空等航司的企业代表和数十位资深行业专家，独特探讨航空数字化转型的高质量倒退新门路，为智慧民航建设赋能。 云原生赋能航空数字化转型推动航空数字化转型，是我国民航强国策略中的重要内容。在现在的数字化时代，航空业面临着更为严厉的敏态业务挑战，企业继续翻新、疾速迭代的IT能力至关重要。然而数字化转型是一个宏大简单的过程，如何疾速实现数字化转型曾经成为以后航空企业亟待解决的难题。 作为企业数字化转型中值得信赖的云原生合作伙伴，灵雀云始终致力于帮忙企业实现利用现代化、减速数字化转型，提供蕴含技术、产品、解决方案、培训、征询等残缺的一站式服务，通过基于容器/Kubernetes技术、以DevOps为理念、面向微服务利用的全栈云原生开放平台Alauda Container Platform，帮忙企业疾速构建云原生利用，实现基础设施云化、利用架构现代化和开发流程麻利化，为企业数字化转型弯道超车提供切实牢靠、开箱即用的解决门路。 灵雀云减速某大型国有航司业务翻新 在实际方面，以某大型国有航空公司为例，该航司利用云原生技术重塑了整个软件的全生命周期，从架构设计到开发，再到构建、交付和运维等所有环节都疾速实现了数字化转型。 · 架构侧该航司通过引入灵雀云全栈云原生开放平台ACP，疾速实现了传统架构的云原生化革新，向更麻利的利用架构进阶；· 开发侧云原生技术的深刻利用使得该航司在短时间内实现了业务麻利开发，即在不影响业务利用可用性、稳定性、安全性的前提下晋升业务翻新和业务试错能力；· 交付侧顺利完成了APP机票预订、航班动静、值机办理、行程核心、用户核心等一系列外围用户服务性能的迁徙，让新兴的业务利用更快地推向市场；· 运维侧疾速实现了APP分钟级的业务利用公布，运维人员无需再操心简单的技术细节，仅需个位数的运维人员即可轻松治理亿级业务零碎。 立刻定制独家航空云原生解决方案点击此处，与灵雀云资深工程师独特探寻航空业云原生最佳实际。 上一篇：案例成果展 | 一朵“航空云”为国航APP外围业务保驾护航下一篇：智能制作的下一站：云原生+边缘计算双轮驱动

为了适应万物互联，数据上云这个，趋势并满足云原生应用程序的存储需要，云原生数据库提供了云中所需的所有个性。 在本文的最初，您应该了解云原生数据库的确切含意、它与容器，云原生，的关系以及它与传统数据库的区别。 云原生数据库和云原生云原生数据库与传统数据库的区别高级可扩展性弹性伸缩动静容灾自动化运维可拜访性降低成本云原生数据库是一种旨在充分利用云技术和分布式系统的数据库。 只管许多数据库能够在云中运行，但云就绪和云原生之间存在差别。 “云原生”形容了服务、软件、API 或数据库，其架构和构建是为了在云上运行和部署，同时受害于云原生零碎提供的性能。 云原生数据库能够在云原生技术上运行（比方 Kubernetes，各类私有云），以提供灵便、可扩大的数据存储和查问解决方案。 云原生数据库和“云原生”在议论云原生时，咱们必须提到容器，因为这是云原生利用程序运行的中央。然而，容器是应用 Docker 和 Kubernetes 等技术构建和部署到云中的。因而，要思考数据库云原生，它须要在容器中运行，同时，它应该可能存储数据并确保状态。 在云中长久化和挪动数据是一个次要问题，因为 Kubernetes 最后是为无状态工作负载设计的。因为数据库须要长久化数据，最近的改良为 Kubernetes 引入了有状态集和长久卷，使得在 Kubernete 上运行有状态工作负载变得容易。 云原生数据库利用这些改良将数据库带入云，以享受 Kubernetes 的所有益处，包含弹性和弹性。 云原生数据库与传统数据库的区别随着微服务和容器化应用程序的日益采纳，须要一个与应用程序相似的数据库来充分利用其劣势。 像 MySQL 和 MongoDB 这样的传统数据库在许多方面都受到限制，包含可伸缩性、安全性和可拜访性。只管它们能够与星散成，但在云中应用这些数据库限度了应用程序享受云技术益处的能力。 以下是云原生数据库的一些无益个性，这些个性使它们区别于传统数据库。 高级可扩展性云原生数据库最重要的个性可能是它可能随工作负载扩大。云原生数据库必须可能减少其容量，以动静适应工作负载的减少。这容许组织运行其应用程序，而无需放心存储限度。 弹性伸缩扩充规模与放大规模同样重要。云原生数据库必须可能在工作负载缩小时放大或缩小其容量，以确保您只领取所需的资源，这是云的益处之一。 动静灾备云原生数据库必须可能在不失落任何数据的状况下禁受住系统故障。当零碎某一部分呈现故障时，云原生数据库能够将数据挪动到新的 pod 并主动修复。 运维自动化云原生数据库容许咱们将部署和治理云原生数据库的过程进行编码，以实现自动化。甚至，能够集成人工智能 AI 的能力，来简化运维。云原生数据库因为其自动化和可扩展性等特点，使其易于治理和更新数据库。 可拜访性与传统数据库（只能通过部署零碎拜访的云原生数据库）不同，云原生数据库应用分布式数据库技术，使其易于拜访。 降低成本云的一个次要特色是只为您应用的资源付费的能力。加上弹性，云原生数据库容许您按需付费，只为您须要的资源付费。 我当初以亚马逊云科技的典型云原生数据库举例： Amazon Aurora Amazon Aurora 是一个与 MySQL 和 PostgreSQL 兼容的关系数据库，它为云计算而构建，将传统企业数据库的性能和可用性与开源数据库的简略性和老本效益联合在一起。 Amazon Aurora 齐全由 Amazon 关系数据库服务（RDS）治理，该服务主动执行耗时的治理工作，如硬件配置、数据库设置、修补和备份。 Amazon Aurora 领有一个分布式、容错、自我修复的存储系统，每个数据库实例可主动扩大到128TB。它通过多达15个低提早读取正本、工夫点复原、到 Amazon S3 的间断备份以及跨三个可用性区域（AZ）的复制，提供了高性能和高可用性。 同时，Aurora 有一项极具特色的性能：Aurora Serverless ，即按需主动扩大配置。 Aurora Serverless v2 在几分之一秒内将数据库工作负载扩大到数十万个事务。它以细粒度的增量调整容量，为应用程序的需要提供适量的数据库资源。您无需治理数据库容量，只需为应用程序耗费的资源付费。 ...

Amazon 在2007年公布的 Dynamo 论文被认为是 NoSQL 数据库的开篇之作，并在之后的十几年间对 NoSQL 的倒退产生了至关重要的影响。在2012年，源自 Amazon Dynamo 论文的 DynamoDB 正式上线，开始向 AWS 的客户提供了一项兼备极致性能与扩展性的云原生数据库服务。在刚刚完结的云原生数据库十周年在线大会上，咱们一起回顾了 DynamoDB 在十年间的倒退，Amazon DynamoDB 在游戏、广告、可穿戴设施、智能家居和互联网软件等行业中帮忙少量客户实现了向寰球互联网扩大的指标。 DynamoDB 作为云原生的无服务架构数据库服务，不仅为用户提供了极致的弹性、可用性和性能，还提供了全局表、事务反对和本地部署测试等个性，帮忙用户满足在更高要求场景下的需要。 Amazon DynamoDB 是一个键/值和文档数据库，能够在任何规模的环境中提供个位数的毫秒级性能。它是一个齐全托管、多区域、多活的长久数据库，具备实用于 Internet 规模应用程序的内置安全性、备份和复原以及内存缓存。DynamoDB 每天可解决超过 10 万亿个申请，并可反对每秒超过 2000 万个申请的峰值。 许多寰球倒退最快的企业，如 Lyft、Airbnb 和 Redfin，以及 Samsung、Toyota 和 Capital One 等企业，都依附 DynamoDB 的规模和性能来反对其要害工作工作负载。数十万 AWS 客户抉择 DynamoDB 作为键值和文档数据库，用于其挪动、Web、游戏、广告技术、物联网以及其余须要任何规模下的低提早数据拜访的应用程序。为您的应用程序创立一个新表，其余的交给 DynamoDB。 任意规模下的极致性能DynamoDB 通过在任意规模环境中提供统一的个位数毫秒响应工夫，反对世界上一些最大规模的应用程序。您能够构建吞吐量和存储空间简直有限的应用程序。DynamoDB 全局表可跨多个 AWS 区域复制您的数据，使您可能疾速在本地拜访全局散布的应用程序的数据。对于须要以微秒级提早执行更快拜访的应用案例，DynamoDB Accelerator (DAX) 提供了齐全托管的内存缓存。 无需治理服务器DynamoDB 是无服务器服务，无需预配置、修补或治理服务器，也不须要装置、保护或操作软件。DynamoDB 可主动纵向扩大和缩减表，以针对容量做出调整并放弃性能。因为内置了可用性和容错能力，您无需为这些性能构建应用程序。DynamoDB 提供预配置和按需容量模式，使您可能通过指定每个工作负载的容量或只为您应用的资源付费，从而优化老本。 企业级个性反对DynamoDB 反对 ACID 事务，使您可能大规模构建业务要害型应用程序。DynamoDB 默认加密所有数据，并为您的所有表提供细粒度的身份和访问控制。您能够立刻创立数百 TB 数据的残缺备份，而不会对您的表性能产生影响，并且能够复原到先前的 35 天内的任何工夫点，而无需停机。您还能够将 Amazon DynamoDB 表数据导出到 Amazon S3 中的湖内数仓，以执行任意规模的剖析。DynamoDB 还提供有服务级别协定，从而确保可用性。 ...

编者按：过来的三年对根底软件畛域来说是不平庸的三年，是波涛汹涌的三年。随着国际形势和行业格局的变动，大家肯定充沛感触到了云原生和操作系统这两个话题的热度。那么当云原生和操作系统这两个热点话题相遇的时候，会产生什么故事？本文整顿自 2022 年阿里巴巴开源凋谢周技术演讲，让作者带咱们走进这场技术盛宴。 本次的分享主题围绕三个方面开展： 首先简要介绍一下龙蜥云原生 SIG（Special Interest Group） 的前世今生。咱们为什么要成立云原生 SIG？想解决什么样的问题？它如何解决这些问题？接下来进一步分享如何基于开源社区和组织，从头开始一步一步构建一个云原生操作系统的原型。最初介绍云原生 SIG 的运作机制，并诚挚地邀请大家一起来参加龙蜥云原生 SIG 的建设。 一、龙蜥社区云原生 SIG回头看我在操作系统和云原生两个畛域的一些经验是十分有意义的，因为它能够让我从不同的视角来看这两个畛域的倒退。基于我在操作系统和云原生畛域的职业经验，最近我开始思考云原生和操作系统是什么关系？应该如何推动这两个畛域的独特倒退？所以我协同行业的合作伙伴一起推动成立了龙蜥云原生 SIG，为研发一套龙蜥云原生操作系统做筹备。下面提到了龙蜥云原生操作系统，那么大家可能会好奇，什么是云原生？云原生和操作系统有什么关系？咱们如何能力构建一个云原生操作系统？ 云原生就是充分利用云基础设施来开发软件利用的一种模式，也就是站在伟人的肩膀上，充分利用成熟稳固的云基础设施来开发、公布、运行和保护一个利用，以保障咱们利用的弹性、性能、容器、老本等诸多方面的诉求。 （图/龙蜥云原生零碎架构） 如上图所示，是一个典型的云原生零碎的架构，其蕴含四个局部： 第一个最底下的是云原生的基础设施。它提供诸如虚拟机、服务器等诸多的物理资源，以及告警、日志等诸多的服务。 第二在这之上龙蜥会构建一套云原生管控。云原生管控者次要提供定义云原生利用的机制，以及为云原生应用服务的一些通用框架，比如说 service mesh 等相似的服务框架。当然，云原生管控零碎外面最外围的则是云原生编排零碎，它负责感知底层的资源，调度底层的资源来服务于云原生利用，最初它会把云原生利用调度到一个具体的云原生节点上来执行。 第三个零碎则是云原生节点零碎。它性能看起来很简略，只须要负责高效地执行被调度到本节点的云原生利用，但其实这个工作并不简略。 第四个最上层则是云原生利用。这层负责实现用户的业务逻辑和交付商业服务。 下面提到：简略的节点零碎其实并不简略，它也面临诸多的挑战。为什么？因为从最开始的无状态利用到当初的大数据、AI、数据库等各种庄重利用的云原生化，业务对云原生节点零碎提出了严苛的诉求。比方如何保障咱们节点的资源利用率？如何保障云原生利用的 QoS？如何隔离多个利用之间的故障？以及保障各个利用的数据安全？ 这些挑战都是云原生节点零碎须要去面对和解决的问题。 下面提到云原生节点零碎面临诸多的技术挑战，可能大家也意识到了这些挑战恰好是操作系统所善于的畛域，因而咱们自然而然地就诞生了一个这样的想法，那就是须要为云原生节点零碎打造一套不便、易用、欠缺的云原生操作系统。那么如何来打造这个零碎？ 基于以上思考，咱们成立了龙蜥云原生 SIG。龙蜥云原生 SIG 有三个外围的定位，就是桥梁、组件以及零碎。 首先，龙蜥云原生 SIG 是一个桥梁，或者说是大家坐在一起聊天的中央，让咱们一起来交换用户的需要、业务所面临的挑战，以及咱们会邀请上游技术社区的外围开发人员来参加这个过程，看看上游社区能为咱们的利用、业务提供什么样的帮忙，提供什么样的解决方案。 另外一个方面，云原生 SIG 也会负责拉通龙蜥社区外部的其余相干的技术 SIG。比方会协同秘密容器 SIG、高性能存储 SIG、容器网络 SIG 以及容器 OS SIG，大家独特来打造一套易用的云原生操作系统。 当然，云原生 SIG 的具体交付件则是稳固好用的云原生组件和零碎。 二、从零开始构建云原生 OS接下来我会和大家一起基于开源社区和开源组件，从头开始构建一个云原生操作系统的原型。 第一步，咱们须要因地制宜，为云原生利用构建一个容器优化的 OS。当然，为了不便大家，也能够利用现有的操作系统来反对云原生的利用，然而咱们会面临诸如操作系统体积特地宏大，装置运维特地耗时等问题。随着这个零碎的运行越来越长，整个零碎当中的操作系统的版本越来越零散，版本越来越多，咱们还会面临系统维护艰难的问题。更重要的是，因为传统的操作系统外面内置的软件比拟多，从而也导致了比拟大的平安危险敞口。随着云原生利用的遍及以及利用占比的日益晋升，咱们值得为云原生利用打造一套专用的操作系统。 基于这样的考量，云原生 SIG 利用平安的 rust 语言从头开发了一套全新的为容器优化的操作系统，咱们称之为 Lifsea OS。Lifsea OS 会内置很多云原生所须要的组件，从而免去用户本人抉择装置、配置各个云原生组件的懊恼。同时这些组件都会以只读的形式装置应用，从而防止了在运行过程当中被恶意软件篡改的危险。 另外为了简化大家运维大规模集群的懊恼，Lifsea OS 提供了基于 API 的运维管控的接口，也就是说也能够以编程的形式来运维整个零碎中的节点。当然，这样一个零碎看起来是深度定制化的，然而龙蜥也提供了十分弱小的定制化能力。比如说用户能够依据本人的业务需要往 Lifsea OS 零碎当中增加必要的组件，批改相应的配置，从而让咱们这个操作系统可能真正的适应各个用户场景的需要。 ...

数字化转型是 IT 界最热的话题。不过，与以往一窝蜂、谋求形式化的数字化不同，在疫情和日益减少的内部压力下，如何利用数字技术进行业务翻新，如何在数字化转型的浪潮中大浪淘沙，生存下来并翻新倒退已成为当下企业最关注的问题。另一边，数据的增长，竞争环境的变动，企业都寄希望于数字化去做利用的翻新、业务效率的晋升，并开掘数据中更多潜在的商业价值。 如何生存？——抉择云原生数据库赋能业务，升高 IT 老本 对于企业来说，灵便的 IT 云资源之上，云原生更进一步用于构建和运行可弹性扩大的企业应用，这将极大扩大企业应用负载的丰富性，让利用施展极致的后劲，同时最优的 IT 老本，应答疾速变动的市场。 抉择云原生数据库构建企业数据架构，是升高用云老本，保障企业生存与继续倒退的要务。云原生数据系统架构的实例很多，咱们以云巨头亚马逊云科技为例。 如何倒退——以先进技术的翻新求倒退 IT 技术本身的倒退，是一场由技术引领的效率颠覆翻新。早在互联网公司疾速走向市场的年代，互联网典型特色包含在线用户数量呈爆炸式增长、数据模式不固定，谋求疾速交付和轻运维等。而传统关系型数据库将所有数据存储在一个盒子中，无奈高效地扩大，这迫使用户须要对其数据库从新分片，而后还须要治理所有的分区和从新分区等，这让用户面临微小的运维挑战和压力。 构建原始 Amazon Dynamo 的初衷正是应答这些挑战。Amazon Dynamo 是 Amazon DynamoDB 的前生，它在过后不是一项服务，而是一个由亚马逊工程师构建的软件系统。然而，Amazon Dynamo 仍有局限性，不能作为内部服务提供给其余非专属客户应用，即受 SQL API 限度。 Amazon DynamoDB 起源于 2007 年亚马逊云科技发表无关 Dynamo 技术细节的论文，以此奠定了首批非关系型数据库（NoSQL）的雏形。最后的 Dynamo 基于一套弱小的分布式系统准则设计，生成了一个可随便扩大和高牢靠的数据库系统。Amazon DynamoDB 也是持续基于这些准则而一直构建倒退起来的。 Amazon Dynamo 通过几个原始组件搭建的一项易于应用的云服务，那就是 Amazon DynamoDB，自 2012 年问世以来，减少了大量翻新性能，不仅波及底层可用性、持久性、安全性和规模等个性，还包含易用性等。客户不再须要配置集群，只需创立一个表存储数据，即可轻松实现无缝缩放。管理员不用执行任何操作，甚至无需装置单个库来操作数据库，这让用户以前所未有的形式拥抱云，取得云上的弹性和可扩展性。所以自 12 年公布之初，Amazon Dynamo 就具备了云原生数据库的因素，现已成为泛滥企业外围业务的根底。 具体来说，Amazon DynamoDB 是一个键-值和文档数据库，这使 AmazonDynamoDB 可能领有灵便的架构，可利用程度扩大反对简直任何大小的表。其中性能实现由 Amazon DynamoDB Accelerator 实现微秒级提早。另外 Amazon DynamoDB 是无服务器服务，无需预配置、修补或治理服务器，也不须要装置、保护或操作软件，可主动扩大和缩减表，以针对容量做出调整并放弃性能。因为内置了可用性和容错能力，用户无需为这些性能构建应用程序。Amazon DynamoDB 提供预配置和按需容量模式，使用户可能通过指定每个工作负载的容量或只为您应用的资源付费，从而优化老本。 ...

咱们许多客户都示意不心愿与商用数据库供应商单干，从而防止低廉的老本开销以及繁琐的许可条款。然而，从新式商用数据库迁徙进去可能须要消耗大量工夫和资源。迁徙数据库时，可应用 AWS Schema Conversation Tool 和 AWS Database Migration Service 主动迁徙数据库模式和数据。然而，迁徙应用程序自身须要实现更多的工作量，包含重写与数据库交互的利用程序代码。主动性足够，但老本和危险往往是限制性因素。 现在，Babelfish for Aurora PostgreSQL 问世。有了 Babelfish，Amazon Aurora PostgreSQL 兼容版将可能了解 SQL Server 线路协定。这一工具让您以更低的老本、更快的速度将 SQL Server 应用程序迁徙到 PostgreSQL，迁徙相干危险也更小。 在传统迁徙所需的一部分工夫内就可迁徙完应用程序。您将持续应用应用程序目前所用的现有查问和驱动程序。只需将应用程序指向已激活 Babelfish 的Amazon Aurora PostgreSQL 数据库即可。应用 Babelfish，Amazon Aurora PostgreSQL 将能了解 SQL Server 线路协定表格数据流 (TDS)，并使 PostgreSQL 可能了解 SQL Server 应用的罕用 T-SQL 命令。对 T-SQL 的反对包含 SQL 方言、动态游标、数据类型、触发器、存储过程和函数等元素。Babelfish 显著缩小了应用程序所需的更改次数，从而升高了与数据库迁徙我的项目相干的危险。采纳 Babelfish 可节俭应用 SQL Server 时的许可老本。Amazon Aurora 能够实现商用数据库的安全性、可用性和可靠性，而老本只有商用数据库的十分之一。 尽管 SQL Server 曾经倒退了 30 多年，但咱们预计它短期内也不会反对所有性能。然而，咱们将专一于最常见的 T-SQL 命令并返回正确的响应或谬误音讯。例如，在 SQL Server（精度为四位小数）和 PostgreSQL（精度为两位小数）中，MONEY 数据类型具备不同的特色。这种轻微的差异可能会导致四舍五入的谬误，并对财务报告等上游流程产生重大影响。在这种状况以及许多其余状况下，Babelfish 将确保保留 SQL Server 数据类型的语义和 T-SQL 性能：咱们创立了一个其行为合乎 SQL Server 应用程序要求的 MONEY 数据类型。通过 Babelfish 连贯创立具备此数据类型的表时，将取得合乎 SQL Server 应用程序要求的此兼容数据类型和行为。 ...

在迁徙 Microsoft Azure SQL 数据库时，通常须要应用数据库工具从 Azure SQL 数据库中提取数据，针对指标数据库进行必要的架构更改，而后将数据导入指标数据库。这个别会波及到手动步骤，并且源应用程序须要停机较长的工夫。如果有一种办法能够疾速平安地从 Azure SQL 迁徙到 Amazon Aurora MySQL 兼容版，同时最大限度地缩小应用程序停机工夫和用户干涉工作，那会怎么样？本博文介绍了如何疾速、平安地主动从 Microsoft Azure SQL 数据库迁徙到 Amazon Aurora MySQL 兼容版，并最大限度地缩小依赖 Microsoft Azure SQL 数据库的应用程序的停机工夫。在下文中，咱们假如您现有一个 Microsoft Azure SQL 数据库，须要将其迁徙到 Amazon Aurora MySQL 兼容版。您将须要对 Azure SQL 数据库的管理员拜访权限，以及连贯信息、用户名和明码。您还须要批改 Azure SQL 数据库防火墙，以容许来自 AWS Database Migration Service（AWS DMS）和托管 AWS Schema Conversion Tool（AWS SCT）的 Amazon Elastic Compute Cloud（Amazon EC2）实例的拜访。对于指标数据库，咱们将应用 Amazon Aurora MySQL 兼容版。 咱们为 AWS SCT 部署应用 Amazon EC2 Windows 实例。 SCT 能够本地装置在任何 Windows 或罕用的 Linux 平台上。 ...

一、前言Aurora Serverless 是 Amazon Aurora 的按需主动扩大配置。Aurora Serverless v2 在几分之一秒内将数据库工作负载扩大到数十万个事务。它以细粒度的增量调整容量，为应用程序的需要提供适量的数据库资源。您无需治理数据库容量，只需为应用程序耗费的资源付费。早在2018年Amazon Aurora 即提供了 Serverless 选项。 Amazon Aurora 最新提供的 Aurora Serverless V2 版本相比于上一代 V1 版本更上一层楼，重点晋升局部：资源容量采纳原地扩大，使资源容量扩大速度由V1分钟级晋升到秒级，v2 版本可能在容量调整时做到更细粒度, 以0.5 ACU作为扩大单元（V1翻倍扩大），并可能根据多个维度进行容量调整，通过继续的监控和尽可能大的利用缓冲池。Aurora Serverless v2 相比 V1 减少了残缺的 Amazon Aurora 性能，包含多可用区反对、只读正本和寰球数据库等，反对跨 AZ 和跨区域的高可用部署和读取扩大。 Amazon Aurora Serverless v2 非常适合各种应用程序。例如，面对业务快速增长场景与海量多租户场景时，当领有数十万个应用程序的企业，或领有具备成千盈百个数据库的多租户环境的软件即服务 (SaaS) 供应商，能够应用 Amazon Aurora Serverless v2 来治理整个 SaaS 利用中泛滥数据库的容量，同时还实用于业务吞吐量稳定显著的场景，如游戏业务、电商业务、测试环境等，以及无奈预估吞吐量的新业务零碎。对于大部分工夫都处于低谷的业务零碎，Amazon Aurora Serverless v2 能够无效地为客户节省成本。 作为新一代云原生无服务数据库， Aurora Serverless V2 提供了无可比拟弹性伸缩性， 动如脱兔；同时也提供了面向企业级利用的坚不可摧的高可用性，静若磐石。 本博客重点会围绕着 Aurora Serverless V2 的弹性伸缩和高可用个性，开展测试和剖析，进一步向您展现 Aurora Serverless V2 的特点。 二、测试2.1 扩展性测试2.1.1 测试指标Aurora Serverless V2 随负载变动的弹性伸缩能力Aurora Serverless V2 与 V1弹性伸缩能力比拟Aurora Serverless 资源扩大以 ACU 为单位，对于ACU定义： ...