作者 | 耿立超
来源 | CSDN博客

文章图片

“戒备”与“偏见”
几年前 ， 我所在的一家传统行业的头部企业启动了一系列数字化转型项目 ， 在配套的IT基础设施建设上 ， “上云”已是大势所趋 。
在此前数年的工作中 ， 我断断续续地使用着公有云产品 ， 大多数情况下 ， 我们只选择IaaS层级的服务 ， 也就是只使用虚拟实例 ， 对PaaS和云平台特定的Serverless服务敬而远之 。 作为一名架构师 ， 我对公有云的此类产品一直怀有一种“戒备”心理 。
一方面 ， 从技术发展路线上 ， 不管是个人还是团队 ， 我们都希望学习并使用行业主流且平台中立的技术 ， 这些技术大多数都是开源的 ， 有着活跃的社区和良好的周边生态 ， 包括高质量的文档 ， 丰富的技术专著 ， 以及互联网上大量的讨论文章等等；另一方面 ， 从公司角度出发 ， 我们也不希望企业与某一朵云深度绑定 ， 这似乎总让人缺少一种“安全感” 。
此外 ， 对于还没有准备好拥抱云计算的技术人员来说 ， 上云会给他们带来一种危机感：“既然你都已经做的这么好了 ， 那以后还要我做什么呢”？这一感受最初产生于IT的基础设施团队 ， 之后系统架构师也会有些许同感 ， 这也是很多PaaS和Serverless服务“不受欢迎”的原因 。 但对于云厂商而言 ， 由于这类服务的利润率更高 ， 他们会更加热衷于推荐此类服务 ， 这会让本已十分敏感的用户更加警惕 ， 以至产生抗拒心理 。
回到公司的数字化转型项目 ， 在听取了多方意见之后 ， 公司决定仅使用虚拟实例构建应用系统和数据平台 ， 尽可能避免深度介入平台特定服务 ， 甚至连非常基础的对象存储服务也没有采用 。 我们数据团队负责构建大数据平台 ， 在一批虚拟实例上搭建了一个Hadoop/Spark集群后 ， 就开始了长期的数仓建设工作 。
之后 ， 随着数据规模的不断上涨 ， 集群也经历过几次扩容 ， 得益于Hadoop集群管理工具和自动化运维工具的支持 ， 每次扩容倒也不算麻烦 。 当时 ， 我们对基础设施的总体状况是满意的：“你总得维护一堆机器 ， 然后定期扩容 ， 哪个系统不是这样呢？”
“上云”改变了什么？
几年后 ， 机缘巧合 ， 我去了一家业界知名的云计算公司 。 所谓“食君之禄 ， 忠君之事” ， 入职后 ， 我必须广泛而深入地学习这家公司的云产品 ， 这些产品既有基于开源产品封装的“云化”版本 ， 又有深度定制的PaaS和Serverless服务 ， 这些产品都借助云平台的虚拟化能力 ， 将动态伸缩与可维护性做到了极致 。
随着对云平台和云系统架构的深入学习和应用 ， 我开始越来越清晰地认识到 ， 由于过去对云计算固有的偏见 ， 阻碍了自己正确看待云计算对系统架构和开发模式带来的深刻影响 ， 在走访了大量公有云企业用户之后 ， 我真切地感受到了云之所以成功和必将成功的“关键” 。
大多数用户选择上云的初衷是希望减轻在IT基础设施上的负担 ， 避免在机房建设 ， 网络规划和服务器采购上一次性投入大量资金 ， 并且还将继续在后期投入资源去管理和维护 。
随着对云计算的深度应用 ， 很快我们就会发现 ， 上云所影响的并不仅仅是基础设施 ， 上层应用系统的架构在基础设施“服务化”的影响下 ， 也慢慢进化出了一些云上特有的架构模式和最佳实践 ， 这些模式和实践在自建（on-premises）场景下并不适用 ， 或效果不够显著 ， 但是在云上则显示出了强大的威力 。
本文 ， 我想针对数据平台的架构设计 ， 选择最具实质意义与深刻影响的几个方面分享一些个人观点 。