"Cloud Native is eating the world", 有人认为这是耸人听闻, 有人认为这是大势所趋. 作为一个近两年最热门的技术趋势, 云原生在吸引了业界广泛关注的同时, 也存在一些问题亟需解决, 一些概念亟需厘清.
云原生到底是什么? 它能做什么? 它能给企业带来什么? 它对开发人员意味着什么? 又带来了哪些新的要求和挑战? 它的实践进行到哪一步了? 3 月 14 日, 腾讯云 TVP 技术闭门会探讨了那些有关云原生你不得不知的秘密.
点击视频, 查看本期 TVP 技术闭门会精彩集锦
云原生: 让云的技术适配企业架构
工业界发展的趋势带来云原生的需求
大咖金语:
"企业架构从 2000 年以前数据量 MB 级别的单机时代下的单体应用架构, 历经数据量 GB 级别的互联网时代的 SOA 架构, 再到数据量 TB 级别的移动互联网时代的分布式云计算架构, 最后到现在数据量高达 PB 级别的产业互联网时代下的分布式应用平台架构. 每个不同阶段的发展, 都对应着不同的企业架构, 服务化的发展, 本质上都是朝着平台化的方向在发展."
-- 陈皓
MegaEase 创始人, 酷壳博主陈皓老师高屋建瓴地解释了云原生产生, 发展的历史背景, 他指出, 企业平台化 (云原生) 架构具备以下几个优势:
小前台大平台: 打造企业中台服务, 快速灵活支撑前端业务;
能力开放体系: 打破竖井, 应用和平台解耦, 支撑企业生态圈建设;
统一管理建设运营: 提升运维效率, 资源利用率, 降低成本.
陈皓老师举了两个实际发生的例子(闭门会敏感内容不能公开), 说明了企业为了高强度的竞争走向云化架构的必要性.
云原生的本质是什么?
"云原生是一个完整的生态, 最底层是基础环境, 底层之上是存储, 计算, 网络, 再上层是服务发现, 远程调用, RPC 及一些类分布式数据库的技术, 在此以外还需要强大的运维能力."
陈皓老师根据 CNCF 官网给出的云原生概念做了拆解, 他提到网上一张 "Cloud Native is eating the world" 的漫画特别有意思:
"Software 是闭源的, 而 Open Source 在互联网时代更能适应市场的发展, Cloud 则是把企业需要的运维, 编译, 上线, 高可用和开源软件的能力集成在一起, 提供一揽子方案, 本质上还是闭源的, 走回了老路. 而 Cloud Native 的趋势将把分布式的技术门槛下压, 让 Cloud 技术主动适配适配企业的架构, 为企业提供自主可控的能力, 这是一个颠覆性的概念."
陈皓老师感慨到, 在他 20 多年的软件开发生涯中, 听说过太多名词和概念, 他认为不管新技术是什么, 本质上基本都是期望给企业以高可用的系统, 自动化的运维. 他指出, 云原生分布式系统的本质就是在玩调度, 从整体监控, 资源和服务的调度, 状态和数据的调度, 以及流量的调度, 甚至包括性能, 稳定性, 运维等层面本质上也还是在做调度.
陈皓老师指出, 云原生的落地形式有以下几种特质:
一定是建平台的;
一定要自动化;
一定要分层开放;
一定是以服务化的形式出现;
一定要高可用, 高性能;
一定是追求 DevOps 理念的.
陈皓老师最后指出, 建立云原生架构还要求工程能力的演进, 这背后还伴随着组织架构, 思维方式的转变, 并不只是单纯使用个云原生的技术便能称得上企业级的云原生架构.
腾讯云容器技术探索和思考
大咖金语:
"财富 100 强企业里, 50% 的企业已经在使用 Kubernetes; 腾讯云 Top 100 客户里, 42% 的企业已经在使用 Kubernetes, 这个数据还在快速增长中. 一旦企业使用了 Kubernetes, 其所管理的资源占企业总计算资源的比例也同样在快速地增长. 这些数据都说明了一个事实, Kubernetes 已经进入了大规模的商用阶段, 它的好处正在被大众所认可."
-- 邹辉
Kubernetes 取得如此大的成功的原因是什么? 腾讯云容器产品中心总经理邹辉指出, Kubernetes 部署方便, 具有可靠性高, 可维护性强的优点, 可以让开发和运维更加 "简单". 他表示, 企业在 Kubernetes 容器化过程中会碰到一些问题, 关键在于如何解决交付流程和工具, 运维规划及工具以及人和理念的问题.
"当企业做容器化或者云原生技术改造的过程中, 可以把一些公共的基础部分能力交给云来做, 最大限度地去复用云上已有的一些基础能力. 同时在 Kubernetes 容器化改造的过程中, 不用完全拘泥于 Kubernetes 已有的能力, Kubernetes 本身支持非常好的扩展能力, 团队可以根据公司内部业务的一些业务实际特点针对 Kubernetes 做出一些扩展, 从而让传统业务架构能够更方便的迁移到 Kubernetes 上, 减少这里的改造和迁移阻力. 其实在腾讯内部业务 Kubernetes 容器化改造过程中, 我们也做了大量的扩展能力, 比如说固定 IP,Pod 原地重启, 灰度发布...... 等的能力, 都是为了让业务更加方便地从传统架构往云原生架构迁移和改造."
Kubernetes 正在 Serverless 化
"目前 Kubernetes 的主流用法, 仍然是每个租户 / 集群采购一批物理机 / 虚拟机加入到 Kubernetes 中, 由公司的运维团队按照不同的方式将资源分给各个业务线使用; 而 Serverless 重点在于资源, Kubernetes Serverless 让用户能够直接使用 Pod / 容器, 不用再去单独购买 Node 节点加入到集群中, 计费方式也是按照 Pod 使用时长来定."
邹辉老师认为未来将有越来越多的企业往这个 Serveless 方向走.
- "腾讯云 Kubernetes Serverless(EKS)服务具有拥抱原生, 无服务器, 安全可靠, 极致的速度, 优化成本, GPU 支持等优势, 目前已开始广泛应用在在线业务场景 + 大数据, AI, 音视频转码等场景中."
- Kubernetes "逐渐基础设施化, 成为水和电"
- "根据腾讯云的数据, 显示出云上越来越多的企业, 正在将他们的大数据 / AI 相关系统跑在 Kubernetes 之上. Kubernetes 正逐渐成为一种基础设施, 成为水和电, 以后会成为一个业务的操作系统."
邹辉表示, 出现这种情况的原因主要有两方面考虑:
一是资源成本. 云上很多客户白天在线业务高峰期, 晚上负载率低, 而其大数据 / AI 的业务则正好相反. 在将其容器化以前, 二者分属两套不同的调度系统, 存在很大的资源浪费. 容器化以后, 可以让 Kubernetes 统一调度资源, 减少成本.
二是运维成本. 对于已经将在线业务 Kubernetes 化的客户而言, 而大数据 / AI 框架 本质上也是一个个的软件服务, 容器化改造后, 同样能够在自动伸缩, 故障检测, 故障替换...... 等一些运维动作上享受 Kubernetes 带来的好处.
- "腾讯云容器团队和大数据团队基于大数据套件 ON TKE/EKS 的实践, 目前已经集成了 Flink,Spark,KV 存储, 分布式 Kafka 等能力, 经过适配和优化过的大数据相关套件将在 5 月份于腾讯云上, 以应用市场或者 PaaS 服务的方式对外输出."
- Kubernetes "逐渐延伸到边缘计算场景"
"据 IDC 数据显示, 到 2020 年将有超过 500 亿的终端和设备联网, 其中超过 50% 的数据需要在网络边缘侧处理, 使用边缘计算之后能给企业带来高达约 1/3 的成本下降. 这些边缘设备情况复杂, 可能分布在多个 site, 如何将这些设备统一管理是企业面临的难题. 包括分布到这些设备商的应用程序如何统一部署升级, 故障处理也是问题. 本质上这其实是一个分布式的资源管理和应用管理问题, 而这些恰好是 Kubernetes 擅长的地方."
邹辉指出, Kubernetes 应用到边缘计算场景还需要做一些增强, 主要有两点:
边缘设备网络复杂, 少有内网专线连接, 有些设备甚至只能单通访问外网, 如果构建 Master 和 node 节点之间的网络通道 是 Kubernetes 需要解决的问题.
网络可能不太稳定, 在弱网络情况下, 设备上的应用需要具备一定的自管控和恢复能力.
邹辉以腾讯云边缘容器 (TKE Edge) 技术的实现方式, 对以上问题提供了解决思路:
云端部署一套 K8S Master, 即可管理多个边缘 site, 且兼容 K8S API 标准用法
边缘设备可以位于云机房, 也可是用户自有设备, 只要能够运行容器所需操作系统即可.
Tunnel 隧道: 构建节点与 Master 的安全加密通道, 同时解决单向通情况下, Master 到节点的流量(例如登陆容器)
Hub-edeg: 代理节点上组件访问 Master 请求, 并缓存 Master 部分信息, 用户节点网络中断情况下, 节点上容器自治问题)
分布式健康检测: 关闭 Master 探活机制, 避免弱网络下, 节点被大面积误剔除; 同一 site 内 节点互相进行健康检查打分, 并上报给 Master 决定是否剔除.
ServiceGroup opreator: 自定义工作负载, 便捷管理多个边缘 site 的相同的服务组.
根据 site 节点拓扑进行负载均衡, 节点上的 kube-proxy 只会保存本 site 机房的 endpoint.
- Kubernetes "逐渐 Service Mesh 网格化"
- "腾讯云观察到, 已经有越来越多的客户在生产环境中使用 Service Mesh(Istio).Istio 通过接管流量, 在不侵入业务代码的情况下, 很好地解决了微服务架构复杂性和运维体系要求的问题."
在邹辉看来, Service Mesh 是一个非常好的设计理念, 真正让一个大的系统处在 "一切尽在掌控" 的状态. 但 Istio 并不是万能的, 企业应用过程中同样会遇到诸如控制面板系统维护成本高, 性能开销大, 协议扩展下发, 监控体系构建以及多平台和异构系统支持的问题. 为此, 他同样以腾讯云 Service Mesh (TKE Mesh)为例, 介绍了解题思路:
性能优化: 针对 Istio 遥测上报模块优化, 内核优化等;
开箱即用: 提供 Istio 控制面独立部署和全托管两种模式;
提供多集群方案;
提供私有协议注册框架.
云原生究竟该如何落地?
云原生是概念还是追风?
两轮分享过后, 参会者对云原生有了一些了解, 却多了更多困惑. 对于云原生究竟是概念还是盲目的追风, 陈皓老师表达了自己的观点:
"我觉得这些都是形式, 叫什么名字不重要, 重要的是能解决什么样的问题. 我觉得问题的本质, 还是看目前的业务形态发展还有技术架构. 技术能不能跟得上是其中一个因素, 今天管你是 Cloud 还是 Cloud Native, 企业的核心诉求都是降本增效加稳定. 这里面会有一些权衡和其他因素的影响, 本质上来说所谓去 IOE 就是因为 IOE 无法自主可控, 企业需要自己接管. 云原生也是类似, 有很多的分布式组件其实会有业务的侵入, 也就一定会有定制化, 越往上做越会有定制化的东西. 我觉得自主可控肯定是每个企业希望拥有的, 不希望把很多东西交到别人的手里, 企业级的云原生架构会是企业追求的目标. 技术和企业级是两码事, 企业级是奔着自主可控的, 不管叫什么, 叫 Cloud Native 或者 Cloud 也好, 能解决这个问题就是好的技术."
云原生会被云厂家绑架吗?
同程艺龙机票事业群 CTO 王晓波给腾讯云容器产品中心总经理邹辉挖了个坑: 现在很多云原生的落地都是在基于云在做, 企业的云原生实现路径会被云厂家所绑架吗? 这是不是又跟陈皓老师提的自主可控形成了一个悖论? 邹辉坦率地分析道:
"目前云厂商在做云原生服务的过程中, 越来越朝开源, 标准化的一些思路演进, 而不是做一个封闭式的技术体系. 现在大家做云原生的技术过程中, 无论是腾讯云还是其他云厂商, 强调的重点都是原生, 一定要原生化, 标准化, 实际上这也是在公有云上的取舍, 在私有云这个地方会更加明显一点, 在近一两年云原生的技术推广以后, 我们发现私有云行业里各个企业采购各家不同的厂商的服务, 提到最多就是要原生, 能够跟其他的服务对接, 能够跟开源的软件, 开源的服务保持标准一样. 这也反过来推进各家云厂商都必须按照云原生的思路去跑去运作."
他同时补充到, 对于云厂商而言, 把云原生的技术放到云上, 更多还是把云原生的服务更好地跟云的基础设施适配起来, 降低用户进一步去适配这些基础设施的成本, 同时也能够有更多的技术力量去给到更多的用户提供更好的服务和支撑, 让客户遇到问题的时候能够资源去解决问题.
CTO 怎么看云原生?
对现在的中小企业, 创业团队而言, 云原生又该怎么落地? 要不要上云? 要不要做自建? AfterShip CTO 洪小军也给出了自己对云原生的看法.
第一, 所有的事情前提还是看业务需要什么. 陈皓老师分享中提到从以前的各个阶段到现在的产业互联网, 这里面很多的业务场景是不一样的. 从我们业务角度来看, 首先看我们的产品是什么样的, 我们在什么样的阶段, 然后更进一步看生态技术, Cloud Native 也好还是什么技术也好, 更多还是这个理念, 包括看技术背后的生态是什么样的.
第二, 我们发现一个现象, 企业想要灵活可控, Cloud Native 本质不一定就是公有云, 邹辉老师也提到:
大咖金语:
"云应该是广义的, 公有云, 私有云, 混合云或者说多个云之间的互相连通, 要做到这样的灵活性, 一定要有一定的标准, 要有一定的相关机制来支持. CTO 还是要更全方位地去整合和应用整个行业的生态技术, 比如说像整个 CNCF 的体系, 这里面有很多的东西我们可以去应用."
-- 洪小军
第三, 我这几年的观察来看, 公有云服务体系也在跟整体生态在更好地衔接, 比如随着 K8s 的不断发展和更多被应用到业务里, 到后面大家也都看到了它已经被基本上所有的云厂商兼容, 我相信未来云原生技术也会得到更多厂商更好的支持. 我相信接下来的行业融合, 会进一步加快云原生的落地, 未来我们也具备较强的可控力, 同时我们也可以更加聚焦好我们的业务.
云原生对开发者意味着什么?
Base 北美的开源爱好者, Tetrate.io Founding Engineer 吴晟老师针对云原生层面的开源也提出了自己的见解.
大咖金语:
"云原生在绝大部分技术上用开源组件是必然选择. 云原生在做的事情就是那些技术人员把自己从原始的框架状态下摘出来, 变成自己构建一套生态体系的状态."
-- 吴晟
所以本质上来说, 很多的技术是相通的, 比如说我们所有的 Service Mesh 上面所做的能力, 以前在原生的内嵌框架上都会做到, Kubernetes 做的这些事情原来在做集成的事情也会做到, 大家为了能够让这套体系更加独立能够更加由, 更专业的人做专业的事, 所以选择了开源. 这是 Service Mesh 等技术给开发人员带来的方便.
但同样, 这对所有使用云原生技术的人也会产生反效应, 对他们的要求越来越高, 因为高度的集成化, 技术的难度直线上升, 以前一个熔断机制可能很简单, 现在集成了太多底层的云原生技术, 对于普通的开发人员理解难度可能在大幅度地提升. 尤其是传统行业, 因为这方面的技术人才缺乏甚至对于技术服务商的缺乏, 对于这个事情的推进可能会有比较大的阻碍.
云原生不是一种技术, 而是理念
圆桌讨论环节抛出诸多灵魂提问的同程艺龙机票事业群 CTO 王晓波, 在最后也表达了自己对云原生的理解.
大咖金语:
"云原生不是一种单一的技术, 其背后是一个生态和理念在支撑, 落地问题的关键并不在于技术, 云原生所集成的技术能力相对而言已经较为成熟, 真正关键的问题仍旧在于开发者自身和技术团队, 是否在组织架构层面适配了云原生的理念, 是否改变了自身对开发, 运维等界限的刻板认知, 是否真正了解云原生能否帮到自己的业务."
-- 王晓波
Cloud Native is eating the world, 这场闭门会结束以后, 想必你对这句话会有更深的认识.
来源: https://www.qcloud.com/developer/article/1602693