【ArchSummit】如何通过AIOps推动可量化的业务价值增长和效率提升?>>> 了解详情
写点什么

你知道吗?传统企业已经在用最新互联网架构了

  • 2018-04-03
  • 本文字数:3462 字

    阅读完需:约 11 分钟

传统企业采用私有云方案来降低运营成本、加速产品创新,听起来貌似不是什么新鲜事儿,不过如果告诉你这些传统银行、电力甚至政府部门已经在用基于 Docker+Kubernetes 的容器 PaaS 来改造他们的业务,你会不会很吃惊?

“现在的 PaaS 已经跟传统 PaaS 完全不一样了;甚至可以说,有了容器 PaaS,很多场景下都不需要 IaaS。”企业私有云提供商博云 CTO 李亚琼博士对此一点都不惊讶。日常工作中他接触了太多对互联网业务需求强烈的传统企业,以一家汽车制造企业、一家能源电力企业为例,采用的都是“物理机 + 容器”的方式来部署私有云,上云的业务既有内部管理系统(OA),也有核心业务系统(支付网关)。可以说这些客户倒逼云计算供应商提供出 Docker+Kubernetes 的容器 PaaS 解决方案。

李亚琼博士的这番话的背景,是 Kubernetes 成为事实标准,在相关领域攻城略地,而基于 Docker+Kubernetes 的集群开始成为私有云的标准解法,不但互联网公司纷纷从 OpenStack 迁移到 Kubernetes,连博云这样的私有云提供商也将 Kubernetes 的 PaaS 作为他们的主打产品。

有关传统 PaaS 与容器 PaaS 的对比,业界有非常多的观点。

PaaS 一度是云计算的宠儿,从这个概念诞生开始,就有人认为它才是云计算的未来:使用 PaaS 就像用水和电一样,无关系统和环境,无需运维。大量的公有云厂商都瞄准了这个方向推出产品,甚至很多公司最开始推出的云计算产品就是 PaaS,最典型的就是新浪云 SAE。

但人们很快发现,传统 PaaS 的局限性太大,受限的运行环境、被阉割的 API,彼时开发 PaaS 上的应用就意味着和这个 PaaS 强绑定,很难迁移。甚至连开发都很有问题,因为你的开发环境和运行环境差别太大。因此 PaaS 逐渐偃旗息鼓,IaaS 作为更务实的选择,成为公有云的宠儿。

但这个情况被 Docker 以及之后的 Kubernetes 所改变了。

李亚琼博士认为,以前的 PaaS 面对的是开发,但其实无法满足开发者个性化的需求;容器 PaaS 关注的是部署和分发,不去干涉应用的运行时,反而给了开发更大的空间。

在传统 PaaS 平台结构中,更多是做一个应用沙盒,封装了应用正常运行所需的运行环境和系统,这类 PaaS 平台就如同一个“黑盒”,应用完全脱离了用户的控制,进入了完全被托管的状态,使得开发人员和运维人员对应用和应用运行时的掌控力变弱;另外传统 PaaS 通常在应用架构选择、支持的环境服务等方面有较强限制,导致此类云平台层次结构运力不足。

随着容器的兴起,传统 PaaS 一方面向更高级的 Serverless 转变,另一方面又分裂出 iPaaS,也就是容器 PaaS,可做应用层的封装调度、部署打包、开发扩容,很多互联网厂商和红帽这样的传统厂商都在转向以容器为核心的 PaaS。

对于客户来说,通过容器 PaaS 可以更加快速的实现业务开发、集成和交付上线;另外它还具有无绑定、可拓展的特点。

当然,用户在选择哪些业务采用容器 PaaS 的时候更多的是考虑业务本身的流量是否具有突然性增长,而和具体的业务领域关系不大。不过,大部分用户上云也是遵循着优先部署对弹性能力要求比较高的业务、其他业务逐步迁移这样一个策略。

在企业私有云建设中,曾经一度进化出了 IaaS+ 云平台的分层结构,但 IaaS 层不具备贴近应用的资源调度策略。基于容器的 iPaaS 在部署和分发上更方便,更多的代码、应用、服务能被复用,而 IaaS 不贴近业务,交付慢。

另外伴随 PaaS 与 DevOps 结合为企业做微服务化改造,真正让企业的系统和应用实现了横向扩展、弹性伸缩。相对而言,IaaS 一般只能做原样迁移,不改造架构,企业上云前遇到的问题在上云后还会遇到。

此外李亚琼博士还补充:“在企业公有云上,也有 PaaS 能力向 IaaS 层渗透的趋势,这就是行业专有云。”我们发现在计世资讯发布的《2016-2017 年中国金融云市场现状与发展趋势研究报告》中显示,一些大型金融企业牵头,在自身搭建金融私有云的同时将冗余的资源提供给特定的、有需求的、受限于资金、技术能力等方面的中小型金融企业,最终形成专供金融行业企业使用的金融专有云模式。

Kubernetes 作为 Google 开源的项目,其面向互联网应用的基因是渗透到整个平台的设计理念里的,这一点与传统企业的业务互联网化需求是非常匹配的。其他的调度框架、更多的特性会聚焦于如何实现资源调度,当然这也很重要;而 Kubernetes 的特性是围绕互联网应用架构去设计开发。

这是它吸引博云这样的 PaaS 厂商投身其中的重要原因。李亚琼博士介绍,博云从 2015 年开始做 PaaS 平台研发,接触 Kubernetes 以后,直观判断这才是未来容器平台的核心和方向,事实也证实了博云的判断是准确的。

无论是 Docker、Kubernetes,还是 DevOps、微服务,李亚琼博士以一个传统客户选择这些互联网架构的上云历程,来诠释个中原因。

“我们在能源行业有个客户,在去年部署容器 PaaS 和 DevOps 平台。其中,集成了禅道(项目和文档管理)、Gitlab(代码管理、Issue 跟踪)、Jinkens(持续集成)、容器平台(持续部署、升级),我们帮客户实现整个 DevOps 工具链的集成和自动化 Pipeline 构建,现在客户从开发到测试环境部署实现了一键式。当然,根据客户的安全管理规范,上生产环境还是要经过内部审批后才能实现部署发布,不过在内部的镜像库、部署文件同步等方面我们也帮客户完成了平台搭建,只要流程审批通过也能实现一键式生成环境发布,效果非常不错。”

选择容器 PaaS 需要对原有的业务重构,这是用户在采用容器 PaaS 时不利的方面,但传统企业只要真正拥抱互联网,就必须去使用与互联网相适应的新技术。而容器 PaaS 在改造传统业务时,可以较好的实现逐步过渡,分期上线,也可以打消传统企业的疑虑。

以博云的 PaaS 平台架构为例:

这个架构中核心是从下向上四个层次:微服务运行时层、服务治理层、服务编排与协同层和场景应用层。其中,微服务运行时层也就是基于 Docker 和 Kubernetes 研发的容器 PaaS 层,聚焦与利用容器构建应用运行环境;服务治理层是围绕微服务间的调用及服务治理构建的平台软件,这一块博云也已经实现了在券商行业的落地实施;服务编排与协同层是正在研究的领域;最后就是客户的业务层,在这一层博云也会通过一些平台级的中间件对客户应用提供支持。

据了解,目前博云的 PaaS 产品 BeyondBOC 1.7 版已经可以支持区块链应用部署和微服务集成,比如支持了京东的商用中间件集成,其四级租户体系满足多场景需求,具备多数据中心管理和应用运维能力。在使用 BeyondBOC 的用户中,有 70% 以上已经使用在生产环境中,既包括很多金融行业用户,也包括新华社和某大型国有石油企业。

从去年以来,云原生理念被越来越多的人所接受,以 Kubernetes 为核心的云原生容器基金会 CNCF 也迎来众多企业的支持。基于容器和 Kubernetes 的 PaaS、微服务、Serverless 等一起构成了云原生应用的基础设施和架构,只要云原生的理念不断普及,容器 PaaS 就会取代过去以虚拟化为核心的 IaaS,成为云计算的主流。

2017 年,Kubernetes 成为容器编排事实标准,对云计算的底层架构有着深远影响。特别是在过去不受重视的 PaaS 层,有了 k8s 加持之后能力大大加强,开始逐渐发威。而在云计算的实际使用中人们发现,SaaS 和 IaaS 都在发展 PaaS 以满足客户快速开发的需求。这也是我们策划本次选题的原因所在,希望探讨 PaaS 的技术演变以及发展趋势。

在此次与博云 CTO 李亚琼博士的沟通中,我们发现他们很多传统企业客户都在选择 Docker、Kubernetes 这样的互联网架构,真的是在全面拥抱互联网。博云也从他们业务经验中,解答了我们有关 PaaS 会取代 IaaS 吗?为什么 PaaS 重新流行?PaaS 会成为云计算主流吗?等诸多疑问。

“所谓云计算,其实是能力即服务,将能力提供出来,PaaS 能更好地抽象并提供能力。”这可能也是博云不希望以任何技术标签来定义自己的原因,他们更加看重的是是否能够根据客户应用需求和场景,具备整合技术的能力。“技术会被迭代、淘汰,而客户需求永远不会过时,客户会教你做出什么样的产品。”

李亚琼,博云 CTO。毕业于中国科学院计算技术研究所,获计算机系统结构工学博士学位。加入博云前,先后在华为、曙光进行云计算相关产品研发。李亚琼博士长期从事计算机体系结构、操作系统、虚拟化和容错计算等方面研究,特别是在虚拟化环境下的资源建模与事件分发技术、资源调度与任务管理技术、安全增强与可信环境构建技术等方向进行了大量技术研究与产品开发工作。先后参与国家高技术研究发展“863”计划项目 5 项、“核高基”重大专项 1 项、国家自然科学基金委项目 1 项、国家发改委支持项目 1 项,涵盖高性能计算机系统、高端容错计算机、安全可信、云计算等基础平台及学科前沿研究方向。

2018-04-03 22:204519
用户头像
张晓楠 InfoQ总编辑

发布了 144 篇内容, 共 94.6 次阅读, 收获喜欢 378 次。

关注

评论

发布
暂无评论
发现更多内容

数字化转型背后的 TiDB(地产行业)

TiDB 社区干货传送门

实践案例

TiDB集群之中控不可用,怎么办?

TiDB 社区干货传送门

管理与运维 故障排查/诊断

高可用测试:KILL TiKV-Server,事务 TPS 掉零现象解读

TiDB 社区干货传送门

陆金所金融核心场景数据库的去 O 之路

TiDB 社区干货传送门

实践案例

TiDB 5.0 VS MySQL 8.0 性能对比测试

TiDB 社区干货传送门

版本测评

MySQL 和 TiDB 互相快速导入全量数据

TiDB 社区干货传送门

迁移

TiDB 在 OPPO 准实时数据仓库中的实践

TiDB 社区干货传送门

实践案例

TiDB 5.0 在TPCH和SSB基准测试下OLAP方面的能力表现

TiDB 社区干货传送门

版本测评

在x86和arm混合部署架构下排查TiKV节点内存占用极高的问题

TiDB 社区干货传送门

性能调优 故障排查/诊断

58 同城 TiDB 4.0 报告

TiDB 社区干货传送门

实践案例 数据库架构选型

使用Zabbix监控TiDB(二)

TiDB 社区干货传送门

监控

tikv下线Pending Offline卡住排查思路

TiDB 社区干货传送门

故障排查/诊断

如何理解TiDB允许广义上的幻读

TiDB 社区干货传送门

TiDB 底层架构

【喜大普奔】zabbix 能监控 tidb 集群了 && tidb 能存储 zabbix 监控数据了

TiDB 社区干货传送门

监控

TiKV 多副本丢失的故障修复演练

TiDB 社区干货传送门

故障排查/诊断

TiDB 5.2 发版 ——“交易+分析”双引擎提速,挑战极限业务场景

TiDB 社区干货传送门

新版本/特性发布

数据库架构升级选型 - TiDB

TiDB 社区干货传送门

数据库架构选型

血泪教训 TiKV多副本丢失unsafe-recover恢复记录

TiDB 社区干货传送门

故障排查/诊断

这么多TiDB负载均衡方案总有一款适合你

TiDB 社区干货传送门

实践案例 管理与运维

PD 三类选主流程梳理

TiDB 社区干货传送门

TiDB 底层架构

PD 客户端源码分析

TiDB 社区干货传送门

安装 & 部署

TiDB 5.0 部分新特性试用

TiDB 社区干货传送门

版本测评 新版本/特性发布 性能测评

【案例】汽车之家 - 一次业务优化解决读写冲突的案例,提升 5 倍性能

TiDB 社区干货传送门

性能调优

Prometheus 中 histogram_quantile 函数相关的若干问题

TiDB 社区干货传送门

监控

悲观事务死锁检测

TiDB 社区干货传送门

TiDB 底层架构

TiDB 海量 region 集群调优实践

TiDB 社区干货传送门

性能调优 管理与运维

TiDB大规模节点下线实践

TiDB 社区干货传送门

性能调优

为TiDB DM添加阿里云RDS/DMS Online DDL支持

TiDB 社区干货传送门

实践案例

浅谈 TiDB 初始化系统库过程

TiDB 社区干货传送门

性能调优 TiDB 底层架构

TiDB 性能优化实践

TiDB 社区干货传送门

性能调优 性能测评

TiUP cluster 用到的三个账户

TiDB 社区干货传送门

安装 & 部署

你知道吗?传统企业已经在用最新互联网架构了_DevOps & 平台工程_张晓楠_InfoQ精选文章