我与亚马逊云的七年之痒

说到亚马逊云科技，我顿时想到了一个成语，一个我很喜欢的成语：七年之痒。 是啊，和数据库、开发打交道都已经七年了，这七年来我从一个身强力壮的小伙伴变成一个苍老的大叔——哪怕经验没有增加多少。接下来，我将结合一下我这7年的浅薄经验，抒发一下我这7年来在数据库和开发领域的感受与拙见。 ## 一年之守 我刚入行那会儿，恰逢中国移动互联网的红海阶段。听当年的 HR 说：只要会 SSM，就可以拉过来写代码，给实习机会。可见，那个时候的扩张确实很疯狂也很肆意——而我，恰好就是被“肆意”扩张到的那个人。 起初我是以实习生的身份来做开发的，实习期间合同是一年。那时候我刚大学出来，B 站还没有现在这般百家争鸣，妥妥的二次元天下。我当时给自己立下的一个 Flag 就是，如果一年内我无法适应写代码、或是说无法爱上写代码这份工作，我便会头也不回的走掉。事实证明，我度过了这一年之守，在这一年我也遇到了我人生中接触最多的一个工具——数据库。 ## 三年之痛 7年前的数据库和现在的数据库完全是两个东西。那时候的数据库都必须是每个公司自己维护，也就是在 Linux 小黑屋上敲命令来安装和维护数据库，没有图形化界面，没有 API 调用工具，全部靠命令，全部靠背。我个人来说，除去每天的开发任务，剩下最多的就是去公司专门存储服务器的机房里维护数据库。那时候的服务器散热也没有现状那么花里胡哨，就是靠最原始的空调散热，想想都冷。  那时候公司为了省钱，还专门没有雇人来管理机房，就让我来兼职管理机房。说是管理机房，其实机房里大大小小的事情我全部包揽了。首先头疼的问题就是服务器、交换机等硬件的采购。众所周知，资本家都不喜欢一分钱一分货，都更青睐于一分钱两分货，现在想想，为啥亚马逊云科技刚出弹性服务器的时候，我就马上做预算让老板转向云服务器，因为实在是太方便了。 其次就是机房的各种软件的安装和维护。因为我们公司没有请专门的运维，那个时候运维这个工作还不是很成熟，没有专门的运维，都是由程序员兼职去做的。那时候公司有一个机房值班表，我一看，好家伙，全部是后台开发程序员。软件安装和各种虚拟化以及后期的维护都是我们来做的，痛！太痛了。我画了一张示意图，大概我一个人一天要去管理和维护那么多太机器。  就这样，我在一份钱两份活的工作中成长了三年，三年之痛，不可谓不痛。 ## 五年之离 终于到了第五年，天下局势也发生了翻天覆地的变化。传统线下数据库的份额逐渐被云数据库所取代，那时候的爸爸还不是马云，是 MySQL。MySQL 由于其开源的特性，性能也不必 Orcal 差多少，于是乎各大中小企业都投向了 MySQL。  我们公司第一款云数据库便是亚马逊云科技的 [Amazon RDS](https://aws.amazon.com/cn/rds/?trk=cndc-detail) 产品，怎么说呢，刚开始公司 CTO 委托我选产品的时候，国内大厂那个基本上都在部署自己的云产品，包括大家树枝的阿里云、腾讯云等，我当时看到了 re:Invent 大会，感觉看到了这行业数据库未来的趋势——上云、[无服务器](https://aws.amazon.com/cn/serverless/?trk=cndc-detail)、按需取，于是看了一眼就决定就选他了。这几年来尝试的产品也越来越多，但 [Amazon RDS](https://aws.amazon.com/cn/rds/?trk=cndc-detail) 不仅仅性能卓越，而且一个服务可以直接连接多种数据库，直接避免了部署多台服务器的出资。  刚好这几年，终端工具也逐渐多了起来，像 XSehll、MobaXterm 等工具，可以直接通过这种工具去连接到云端，我甚至有点怀念我以前在小黑空调房里调试数据库的日子了。 ## 七年之痒 到了如今，数据库又朝着另一个方向去了，而且中国方向似乎是大局，那就是云原生。云原生对比原来的云计算的数据库的优势更明显，第一个优势是可以**无感升降配置**，做过部署的同学应该都知道，服务器也和旅游一样，有淡季和旺季之分，在旺季的时候就希望高点配置，到了淡季的时候，又希望低点配置，淡季和旺季的交替和切换往往不是那么明确，需要盯着服务器的负载或者是盯着控制台看，云原生数据库可以实现对大规模的集群服务器进行适时调整配置，无需关机或者是停机，而云计算的数据库需要先关机再升级配置，最后再开机这几个步骤，严重影响体验。亚马逊云科技的云原生应用程序不需要任何硬件或软件上的投资，因为它们是在云上进行的，可以灵活的利用云的弹性优势，因此使用起来相对便宜，这对于中小型企业来说简直是福音。这里要顺带分享一下我最近在研究的一款产品：[Amazon DocumentDB](https://aws.amazon.com/cn/documentdb/?trk=cndc-detail)。 我们 MongoDB 是一款文档型数据库，他使用的是 json 格式的数据，与传统的关系型数据库不同。在以前，如果想要支持高并发的请求，通常我需要搭建多台服务器组成一个集群，而 [Amazon DocumentDB](https://aws.amazon.com/cn/documentdb/?trk=cndc-detail) 通过独立扩展计算和存储，支持每秒数以百万计文档的读取请求，就问各位老铁，这个功能6不6。 我们公司的评论是使用 MongoDB 来存储的，按照以前方式的部署，一旦服务器出现了问题，不仅仅会导致评论这个功能出现问题，一不小心还会导致整个系统宕机，而 [Amazon DocumentDB](https://aws.amazon.com/cn/documentdb/?trk=cndc-detail) 的一个功能给了我很大帮助，那就是自动化硬件预置、修补，我至此就再也没有担心过稳定性的问题了，而且他还可以通过自动复制、连续备份和严格的网络隔离实现 99.999999999% 的持久性，数据的稳定性保障让我很放心。 从 MongoDB 迁移到 [Amazon DocumentDB](https://aws.amazon.com/cn/documentdb/?trk=cndc-detail) 也很简单，借助另一个服务 Amazon DMS 就可以啦。  ## 十年之约 说来，我步入这行也差不多有十年了，浅谈一下我对数据库未来的趋势的看法（当然还是站在巨人的肩膀上）。最近看了 re:Invent 2020，顺带也总结一下我对于数据库的感想。作为一名从基础的物理机数据库到现在云数据库的亲历者，我感觉这些年的变化可以说是天翻地覆的，以前很多的场景，可以说是如果以后不特意去营造是不会再出现的了，比如说穿着棉袄去冷冻室里面调物理机等。同时，数据库上云作为一种基建设施也实实在在是给我们的生活带来了很大的变化，试想一下，如果单纯靠物理机和物理降温的方式来解决数据巨大的问题，我们的春运抢票和双十一整点抢购的场景，估计只能出现在晋江系的小说里面了。 下一个数据库的趋势国家也注意到了，那就是数据量会逐渐扩。现在国家和各大高校都纷纷注意到了大数据这个板块，无疑是给了我们一个很明确的方向，在【东数西算】这项工程里，也表达了东部沿海城市对于算力的吃紧和西部城市计算大数据的天然优势，在接下来的十年，不知道在互联网行业还会出现什么翻天覆地的变化，我们拭目以待吧。 文章审核：jiajiama