必选云原生数据库的原因

Posted 2023-04-11 三掌柜666

 更多玩转云产品，点击进入：https://click.aliyun.com/m/1000370368/

前言

随着云原生的高速发展，打破了企业传统的部署方式，以及开发主线和运维方式。可以说云原生的诞生以及发展，促使了企业的技术变革和进步。作为云原生领域的数据库不仅是非常重要的一环，而且也是打破传统数据库的领域之一。云原生已经深入人心，尤其是在企业进行数字化专项的时候首选云原生，而云原生数据库又是云原生的重中之重的领域，承载着云原生的关键。那么本文就来聊一下关于云原生数据库的相关内容，仅代表个人观点，如有不妥之处，还请各位看官包涵。

众所周知，云原生的出现，打破了传统的部署方式以及数据存储方式，关于数据库相关的变革也是非常大的。而且作为开发人员来说，关于云原生数据库的使用也是必备技能，尤其是市面上比较主流的几款云原生数据库，也要有所了解。在传统数据库架构中，只有高耦合设计模式才能让系统发挥最大效能，但是这恰恰束缚了数据库的可扩展性。但是云原生数据库可以通过解耦实现资源共享，实现上云之后的共享和整合，可以很好、快速的扩容，极大方便企业的业务动态性。

一、常用云原生数据库

由于笔者也是一位有着多年经验的一线开发人员，关于云原生数据库的使用也是颇有心得。在实际开发中接触到的云原生数据库有好几个，比如阿里云PolarDB、亚马逊云科技的Aurora、CockroachDB、腾讯云的KeeWiDB等。

接下来通过笔者自己使用的角度出发来分享一下上面几个数据库的使用心得，PolarDB是阿里云自主研发的关系型云原生数据库，既拥有分布式设计的低成本优势，又有集中式的易用性；Aurora是亚马逊云科技的关系型数据库，既有可伸缩性，又有可用性；CockroachDB是一个既有可伸缩性，又有分布式的数据库；腾讯云的KeeWiDB既高速低延时，又软硬件结合的NoSQL数据库。

其实阿里云是全球早期的提供云原生数据库的厂商之一，云托管数据库RDS服务是阿里云核心的服务之一，再加上云原生关系型数据库PolarDB以及PolarDB-X分布式版本，比如云原生数据库 PolarDB mysql版会100%兼容 MySQL，具有多主多写、多活容灾、HTAP特性，交易性能最高可达开源数据库的6倍，分析性能最高可达开源数据库的400倍，TCO 低于自建数据库50%，让云原生数据库变得更加智能、更加安全、更加简单，具体详情进服务链接了解：云原生数据库PolarDB MySQL版_关系型数据库_MySQL上云_数据库-阿里云。

二、云原生数据库的优势

从笔者多年的开发经验来讲，云原生数据库相比传统数据库的优势有很多，比如云原生数据库的可伸缩性能，可以根据实际情况来进行自动调整，分配资源，具备良好的可伸缩性；再如云原生数据库的机动灵活性，在实际使用中，可以根据实际需要来进行自由配置，支持多个数据模型以及部署框架，具有很强的可扩展能力；又如云原生数据库的容错机制，可以在实际应用中遇到故障和险情的时候，云原生数据库可以通过故障转移以及自动恢复等容错机制，保证程序正常运转，实现极高可用性的特点。

三、云原生数据库serverless能力

作为开发人员，关于云原生数据库serverless能力的含义其实并不陌生，其实云原生数据库serverless指的是数据库服务在设置预算和基础设施的情况下，根据按需自动伸缩和实际使用来收费的能力。众所周知，传统数据库中，需要首先进行预设资源，且随时保证预设资源可用，这就造成资源的浪费，但是云原生数据库serverless能力就是可以根据实际情况，以及应用的访问和使用量进行自动调整资源配置，并且根据实际使用量进行计费，动态的调整可以让用户只支付实际使用的资源费用，从根本上解决了资源浪费的情况。

上面提到，云原生数据库serverless能力还可以给用户提供容错能力，可以通过故障转移以及自动恢复等容错机制，保证程序正常运转，实现极高可用性的特点。其实，云原生数据库serverless是整合了云原生数据库和serverless的优势，自动分配资源，实现动态伸缩计费，让业务负载均衡，不用预留资源空间，极大提高资源利用率和成本。

云原生数据库serverless能力可以帮助企业以及使用者进行降本增效，首先通过动态根据使用情况的动态伸缩计费模式，可以降低企业资源成本；通过自动备份和故障回复等操作，减少企业运维人员的工作量，提供工作效率；还可以通过应用程序的扩展，结合实际情况，提高企业的业务实现灵活性。

四、云原生数据库功能发挥最大化

结合实际的使用经验来谈云原生数据库的功能特点，这里分享一个笔者公司在进行处理和请求海量数据的时候，如何保证平台稳定性，具体公司业务不再过多描述，就说在某一次年中大促的时候，公司的订单剧增，以及限时秒杀时候有大量支付请求的时候，借助云原生数据库通过动态的负载均衡和伸缩等帮助销售平台不宕机，保证了稳定性。还有一次，是做一个公司的版本迭代需求，由于涉及到新业务的拓展，版本迭代比较频繁，之前的每月一次迭代成了每周迭代，尤其是在部署的时候，通过云原生数据库很好地进行应用部署，而且是在快速部署的，非常的方便。比如阿里云的云原生多模数据库 Lindorm，它提供了宽表、时序、文件、搜索等多种数据模型，支持毫秒级在线数据处理、海量数据低成本存储和分析，使用统一SQL融合多模数据的实时查询、检索和分析，流库一体、内置流计算引擎满足实时计算需求，具体详情进服务链接了解：云原生多模数据库Lindorm_多模数据库_工业物联网_数据库-阿里云。

话又说回来了，云原生数据库想要发挥最大作用，还是要结合实际场景来定，一般情况下云原生数据库适合需要快迭代、可扩展的应用，而且在高并发、大数据、多读写等情形下也是云原生数据库擅长的优势所在。其实在降本增效的情况下，使用云原生数据库可以实现动态伸缩计费，实现按需付费的能力，可以很好的削减企业开支，节省运维成本。

最后

通过本文关于云原生数据库的相关内容的介绍，想必读者关于云原生数据库的使用以及特点都有了更深的了解，也再次证明企业和开发者使用云原生数据库处理实际业务和需求的时候的优势明显，想必传统的数据库处理方式，云原生数据库真的可以解决很多问题，而且随着云原生的快速发展，云原生数据库也在不断的完善，这也让越来越多的企业和用户使用云原生数据库，实现了技术的升级。最后，选择云原生数据库真的可以让企业“降本增效”。

更多玩转云产品，点击进入：https://click.aliyun.com/m/1000370368/

k8s的yaml说明

k8s yaml

# yaml格式的pod定义文件完整内容：
apiVersion: v1       #必选，版本号，例如v1
kind: Pod       #必选，Pod
metadata:       #必选，元数据
  name: string       #必选，Pod名称
  namespace: string    #必选，Pod所属的命名空间
  labels:      #自定义标签
    - name: string     #自定义标签名字
  annotations:       #自定义注释列表
    - name: string
spec:         #必选，Pod中容器的详细定义
  containers:      #必选，Pod中容器列表
  - name: string     #必选，容器名称
    image: string    #必选，容器的镜像名称
    imagePullPolicy: [Always | Never | IfNotPresent] #获取镜像的策略 Alawys表示下载镜像 IfnotPresent表示优先使用本地镜像，否则下载镜像，Nerver表示仅使用本地镜像
    command: [string]    #容器的启动命令列表，如不指定，使用打包时使用的启动命令
    args: [string]     #容器的启动命令参数列表
    workingDir: string     #容器的工作目录
    volumeMounts:    #挂载到容器内部的存储卷配置
    - name: string     #引用pod定义的共享存储卷的名称，需用volumes[]部分定义的的卷名
      mountPath: string    #存储卷在容器内mount的绝对路径，应少于512字符
      readOnly: boolean    #是否为只读模式
    ports:       #需要暴露的端口库号列表
    - name: string     #端口号名称
      containerPort: int   #容器需要监听的端口号
      hostPort: int    #容器所在主机需要监听的端口号，默认与Container相同
      protocol: string     #端口协议，支持TCP和UDP，默认TCP
    env:       #容器运行前需设置的环境变量列表
    - name: string     #环境变量名称
      value: string    #环境变量的值
    resources:       #资源限制和请求的设置
      limits:      #资源限制的设置
        cpu: string    #Cpu的限制，单位为core数，将用于docker run --cpu-shares参数
        memory: string     #内存限制，单位可以为Mib/Gib，将用于docker run --memory参数
      requests:      #资源请求的设置
        cpu: string    #Cpu请求，容器启动的初始可用数量
        memory: string     #内存清楚，容器启动的初始可用数量
    livenessProbe:     #对Pod内个容器健康检查的设置，当探测无响应几次后将自动重启该容器，检查方法有exec、httpGet和tcpSocket，对一个容器只需设置其中一种方法即可
      exec:      #对Pod容器内检查方式设置为exec方式
        command: [string]  #exec方式需要制定的命令或脚本
      httpGet:       #对Pod内个容器健康检查方法设置为HttpGet，需要制定Path、port
        path: string
        port: number
        host: string
        scheme: string
        HttpHeaders:
        - name: string
          value: string
      tcpSocket:     #对Pod内个容器健康检查方式设置为tcpSocket方式
         port: number
       initialDelaySeconds: 0  #容器启动完成后首次探测的时间，单位为秒
       timeoutSeconds: 0   #对容器健康检查探测等待响应的超时时间，单位秒，默认1秒
       periodSeconds: 0    #对容器监控检查的定期探测时间设置，单位秒，默认10秒一次
       successThreshold: 0
       failureThreshold: 0
       securityContext:
         privileged:false
    restartPolicy: [Always | Never | OnFailure]#Pod的重启策略，Always表示一旦不管以何种方式终止运行，kubelet都将重启，OnFailure表示只有Pod以非0退出码退出才重启，Nerver表示不再重启该Pod
    nodeSelector: obeject  #设置NodeSelector表示将该Pod调度到包含这个label的node上，以key：value的格式指定
    imagePullSecrets:    #Pull镜像时使用的secret名称，以key：secretkey格式指定
    - name: string
    hostNetwork:false      #是否使用主机网络模式，默认为false，如果设置为true，表示使用宿主机网络
    volumes:       #在该pod上定义共享存储卷列表
    - name: string     #共享存储卷名称 （volumes类型有很多种）
      emptyDir: {}     #类型为emtyDir的存储卷，与Pod同生命周期的一个临时目录。为空值
      hostPath: string     #类型为hostPath的存储卷，表示挂载Pod所在宿主机的目录
        path: string     #Pod所在宿主机的目录，将被用于同期中mount的目录
      secret:      #类型为secret的存储卷，挂载集群与定义的secre对象到容器内部
        scretname: string  
        items:     
        - key: string
          path: string
      configMap:     #类型为configMap的存储卷，挂载预定义的configMap对象到容器内部
        name: string
        items:
        - key: string
          path: string

这些语法适合于rancher平台，因为rancher平台的底层也是k8s为基础的。