写在前面：博主是一只经过实战开发历练后投身培训事业的“小山猪”，昵称取自动画片《狮子王》中的“彭彭”，总是以乐观、积极的心态对待周边的事物。本人的技术路线从Java全栈工程师一路奔向大数据开发、数据挖掘领域，如今终有小成，愿将昔日所获与大家交流一二，希望对学习路上的你有所助益。同时，博主也想通过此次尝试打造一个完善的技术图书馆，任何与文章技术点有关的异常、错误、注意事项均会在末尾列出，欢迎大家通过各种方式提供素材。

• 对于文章中出现的任何错误请大家批评指出，一定及时修改。
• 有任何想要讨论和学习的问题可联系我：zhuyc@vip.163.com。
• 发布文章的风格因专栏而异，均自成体系，不足之处请大家指正。

为何数据库也云原生了？

本文关键字：云原生、数据库、大数据、分布式、AWS

文章目录

• 为何数据库也云原生了？
• • 一、理解云原生
  • • 1. 云的概念与发展
    • 2. 云市场与云原生
  • 二、数据库的角色
  • • 1. 数据库的长期角色
    • 2. 数据库新时代职能
  • 三、数据库发展趋势
  • • 1. 分布式
    • 2. 云原生
  • 四、山猪乱弹

一、理解云原生

最近云原生的概念出现的频率又高了起来，其实究其原因还是整个云生态又向上迈了一步，毕竟云的概念已经持续了好多年。云原生也不能说是一个新词，只是和单独的一个云字还是有所区别的，当前又被赋予了更多的含意。

1. 云的概念与发展

笔者最开始接触云可以追溯到8年前，那个时候百度网盘还叫百度云，云市场上见的最多的也是云服务器，甚至连云计算和云服务也没有开始崭露头角，应用的开发模式主要还是可以被清晰的划分为：本地开发 -> 测试部署 -> 生产发布。回顾这么多年的发展历程，依然可以总结为：以需求为导向。

• 企业有需求：降低成本，提高效率
• 开发者有需求（隐式的但源自内心）：减少工作量，高效协作
• 客户有需求：快速应对需求变化，产品迭代稳定且快速

这一切的需求催化了方方面面的发展，包括各技术框架、开发模式、中间件、大数据等等，自然也包括云。单就云本身的概念其实比较好理解，最直白的说就是不在本地，可以购买或租用云端的服务器、存储空间、功能服务，通过接口调用或者远程连接就能够使用相应的服务和资源。但是当提供的服务逐渐变多之后，可以做的事情却发生了质的变化。

2. 云市场与云原生

• 云市场

现在我们再去云市场上去逛逛，可谓是五彩缤纷：云服务器、云计算、云存储、云数据库、音视频处理以及各种功能性服务。但是使用这些云市场提供的服务就是云原生了吗？当然不是，如果只是在应用开发时引入了一些云服务SDK，那也无非只是解决了项目开发上的一些功能性需求。
再比如项目发布时，如果自己直接租用服务器，并搭建数据库环境，那数据库的所有维护，包括分库分表的设计都需要由开发者考虑并实施，并且编写的代码与数据库的设计方案也是强耦合的，必须进行周到的考虑，否则后期一旦遇到数据迁移或扩容的问题，很可能会十分头疼。

• 云原生

也就是说云原生不仅仅指的是云资源的使用，更重要的是如何使用和整合，在项目开发时，是否结合了云环境的特点，这样才能充分发挥云的优势。那么质的变化是什么呢？由于容器、自动化、微服务等技术的成熟，使得云服务不再是简单的云端调用，而且还能够应对不停机更新，高可用，分布式，扩容等需求。后文将从数据库的角度出发，继续解读。

二、数据库的角色

数据库是我们再熟悉不过的一个关键角色，我们简单的回顾一下数据库的发展历程，只讨论关系型数据库。

1. 数据库的长期角色

数据库一直以来的角色就是数据的存储与查询，与之相关的事务管理以及存储过程等功能也是为了保证数据库能够更好的满足数据读取的需求。对于关系型数据库来说，关系模型可以较好的刻画业务场景的关联关系，并且结合范式及数据库设计方案可以使得数据以合理的方式存储，并且可以较为方便的读取。

2. 数据库新时代职能

在一段时间里，数据库可以满足各类业务场景的项目需要。但是随着时代的发展，数据库面临很多需要解决的问题。

• 进入互联网时代，活跃的用户逐渐增多，存储压力不断增加
• 大数据时代到来，数据的价值发生变化，数据库变为关键数据源
• 历史数据不断累积，需要考虑数据库性能与扩容问题

以上出现的问题看似平常，其实并没有表面这么简单，虽然都能够解决，但是如果使用非云的方式处理，依然是繁琐的。

• 活跃用户增加，意味着数据交互频率增加，这不仅仅是数据存储量变大，数据库的并发性能同样在经受考验。
• 由于有了数据分析的需求，需要将数据抽取到大数据环境，如何处理才能够不影响到核心业务功能的运作。
• 针对数据库的分库分表方案与业务逻辑深度绑定，当业务逻辑发生变化或考虑步骤，历史遗留数据如何处理。
• 当项目运转周期足够长，是否需要做冷热数据的区分来进行优化。

可以看出，对于企业级应用来说，数据库需要承担的角色不仅仅是数据存储和查询这么简单了。还需要应对高并发，存储扩容，数据同步，数据安全等诸多方面的要求。

三、数据库发展趋势

笔者之前写过一篇文章：跨过2019 - 如何立一个新的Flag?且看行业解读，其中阐述了技术重心的偏移。

数据上云是必然的，因为存在数据分析的需求，此外云数据库可以很好的解决目前数据库面临的一些问题。这里我们已经可以看出数据库未来的发展趋势至少会包含分布式与云原生这两大方向，这也许意味着我们以后在学习数据库时要掌握更多的内容，但这绝非坏事，只有紧握时代的脉搏，才更容易被市场所需要。

1. 分布式

在个人学习阶段，我们所安装的主流数据库：MySQL、Oracle、SqlServer等都是以单线程，单实例的模式在工作。在企业场景中，这些数据库都提供了数据库集群的解决方案。
为何分布式的模式如此重要呢？其实最粗暴的办法就是增加硬件配置，使得软件能够更高效的运行，其实想来也不难理解，就算面临再大的数据量，只要CPU与内存足够强大，那也可以在较短的时间内得到结果。但是这是在垂直方向上使用硬件进行优化，当达到一定程度时，付出与预期回报已然不成正比，甚至完全达到瓶颈，毕竟硬件性能也是有上限的。
而分布式则是在水平方向上使用软件解决方案进行优化，在多个机器上同时运行多个实例，可以将任务进行分散，也就是分而治之的思想。在实施的过程中，可以完全由人为的方式进行监控和管理，但是由于是分布式，本身就有了一定的高可用性，即使挂了几个节点整个数据库服务依然顶得住。但是采用这种方式依然需要人为干预，无法做到自动化。

2. 云原生

由于云原生本身就使用到了容器技术，所以天生和分布式就能够很好的融和在一起，当然，这也需要开发者对项目进行了云的设计。以Amazon RDS for MySQL为例，我们一起来看一看云原生数据库能做到哪些事：

使用云原生数据库只需要进行简单的配置，比如初始的数据库性能以及扩展时的资源分配。也就是说只需要对数据吞吐量做简单的预估，而且随着项目的运行会有越来越多的监控数据，进而决定为云数据库资源投入多少钱能够达到一个平衡。目前已经有很多云数据库产品可以稳定使用了，包括关系型与非关系型，并且很多中间件（消息队列等）也在逐步加入，最终一定会越来越丰富。比较市面上的云市场，使用AWS云数据库还有诸多优势：

• 更为丰富的数据库品类

虽然关系型数据库使用通用的SQL标准，但是不同数据库软件之间依然存在着内置函数、数据类型、数据库对象等诸多方面的差别。丰富的云数据库类型可以使得数据上云时的选择更为从容，同时对于NoSQL数据库以及也提供了支持。

• 精确成本控制

数据库实例同样采用实际用量付费的方式，每小时根据存储、IO以及使用的数据库相关服务进行计费。当对数据库的配置进行修改后（扩容或销毁），也会按相应比例计费。

• 易于管理和监控

使用云数据库，可以将开发者的精力投入到业务逻辑开发上，对于数据库的管理使用配置的方式即可。同时，Amazon CloudWatch功能可以记录完整的运行日志，并可以根据设置的指标发出警报。

• 数据随时备份与回档

相比于传统数据库自主部署与备份，云数据库不需要担心数据备份的空间管理问题。传统的数据库部署是基于云服务器的，运维人员需要保证云服务器的资源能够满足数据库所需，但这其实是一项重复且额外的工作，因为我们的目的是管理数据。云数据库本身提供了一整套的完整服务，将数据管理的必备操作完全抽离和封装，管理者只需要在管理面板上就可以完成相关操作。

四、山猪乱弹

云原生是一个正在发生的趋势，它所带来的并不是技术栈的变动，而是开发模式的革新。做为开发者，我们至少应对此保持关注，理解相关的概念，进而发现自己在哪方面又有了生长空间！说的再多，忙里偷闲，不如自己动手试试（免费福利）：

• 数据库免费试用链接及上手教程
• 云原生数据库在线大会
• 亚马逊100余种产品免费套餐 - 首年免费

扫描下方二维码，加入官方粉丝微信群，可以与我直接交流，还有更多福利哦~