RDS PostgreSQL产品架构演进
RDS PostgreSQL总体上来说，经历过三代架构。
第一代架构：
第一代架构是传统的物理机模式，左边呢是一台主节点的物理机，右边是一台standby物理机，它们主从之间通过Streaming流复制来做，然后最上面是有SLB，SLB是当主节点OK的情况下把SLB的流量切到主节点，如果当主节点异常的情况下，则把SLB切到备节点，这就是HA。
但是纯物理模式有几个缺点：
v 第一个缺点是，如果备节点，物理机当机的情况下，数据拷贝的时间是异常漫长的。
v 第二个缺点是，弹性能力比较差。
例如：要对这个机器的实例进行变配的时候，比如说4C4G变成了8C16G，这时候就要做一个变配，如果物理机有资源的情况下就可以完成变配，但若本地物理机没有资源的情况下，就需要一个跨机迁移，进行腾挪，而腾挪的时间非常漫长。
第二代架构：
第二代产品的特点是沉积分离，如左半边这张图，首先有个master节点在中间，master节点会通过streaming的复制方式，把数据传给两边的计算节点，一个是standby节点，一个是readonly，每个节点下面都挂着分布式存储，保证数据的一致性，独立性。
上面有个SLB，SLB连接主节点，还有个SLB RO节点，这个主要连着只读节点，这样有几个好处。
首先是底层分布式存储，分布式存储会带来很多运维上的提升，比如说数据的搬迁，数据的克隆，都可以很快的完成。
其次就是计算节点，计算节点由于是ServerList，所以在迁移的过程中不需要搬数据；第二是能够快速的弹升动作。
右图可以看到是SLB挂了一个master节点，然后下面是分布式存储，这个架构就是RDS PostgreSQL基础版，首先一个计算节点下面挂着一个分布式存储，上面是SLB，分布式存储有个最大的特点：保证数据的可靠性。
当主节点挂掉的情况下，只要重新找一个计算节点，把数据库和盘关联起来，把盘挂上去，就完成了，所以说基础版虽然在HA能力会变弱，但是其数据的可靠性还是很强的。
第三代架构（My Base）
My Base 在2019年在My SQL产品上进行了孵化，今年三月份My Base在PG产品上进行了孵化。
大家可以看到一个特点，原来一个计算节点只能挂一个数据库节点，现在一个计算节点可以挂多个数据库节点。
那么，它有什么好处呢？
首先，左边的这个计算节点，master standby，master readonly；右边节点就是：standby master，standby readonly。
就是说现在用户可以自定义左边的计算节点挂多少个master，右边的可以挂多少个matser，这样的话就把资源调拨的能力下沉给用户，用户可以自己调度解决，这是第一点；第二点，用户可以根据业务的压力进行动态的调配。
但是数据库是一个IO密集型的计算，所以如果一块数据盘大家都是这个计算节点会不会有性能的问题？
会，但是可以优化，避免的。
Ø 首先，每个数据库节点都挂了分布式存储，每个分布式存储都是独立的，这样就保证IO之间是隔离的，不会互相影响。这是MyBase产品一大亮点，就是用户成本会更低、更经济，同时具备自主的调度能力。
Ø 其次，MyBase还有个特点就是用户可以自己登陆到计算节点，看到数据库的状态、信息等等，甚至可以自己去写一些小脚本去监控数据库，这样是加大了用户对数据库的把控力。
RDS PostgreSQL产品迭代回顾
目前经历了三代产品：
Ø 第一代是纯物理机模式；
Ø 第二代是存记分离模式（我们更倾向强调快弹能力，快速的响应能力）；
Ø 第三代提供的是用户的自主可控能力（比如说自主调配，自主查看数据库）。
RDS产品的安全体系
l 第一大块：运维合规
运维合规，首先是白屏化运维，授权审计，这一块主要针对阿里云的后台工作人员来做的，用来保证每个实例操作是用户授权的，并且有审计；
其次是SQL审计，这个是开放的功能，是保证PG里面的每一条SQL都是用户已经执行过的；
另一个是内核支持，内核会更多的做一些加密、支持等等；
l 第二大块：容灾容错
1. 异地容灾：异地容灾指的是异地有可用的PG或者IDS数据库，并且随时随地可以被激活当主库来用，这就叫异地容灾；
2. 异地灾备：异地备份，当异地发生情况的时候，可在异地灾备中把这个数据库从备份机里面拉出来进行一个复活；
3. AZ级容灾：AZ级容灾就是在购买RDS时，会选择可用区，这就是AZ级容灾。AZ级容灾更多的是在可用区相当于IDC级别容灾，就是当IDC单点发生故障的时候，我们可以进行容灾操作。
l 第三大块：基础备份
基础的备份我们有RPO和RTO的保障。还有recycle，就是我们所谓的回收站，很多人在RDS官网购买了数据库之后随时间推移可能忘了，忘记续费了，这时候他的回收站就可以使用，比如说超过一个月以后，这个实例就被释放掉，但是不会真的实施释放动作，而会放在回收站里。
l 第四大块：存储安全
存储安全分为几大块，首先是KMS，这是密钥服务；然后TDE，透明数据加密；还有SGX，是我们的硬件加密，都是存储级别的加密。
l 第五大块：链路安全
链路安全更多的是网络链路上的东西，比如说VPC，VPC是相互隔离的，还有一个是白名单，还有一个是防暴力破解，SSL加密等等。
l 第六大块：账号安全
其次是账号加密和账号的安全，账号的安全分为：DB账户授权、RAM授权和安全密码字典。
DB账户授权：普通账户权限管理。
RAM授权：是控制台的实力权限，因为阿里云提出的是一个主账号下面N多个子账号。
安全密码字典：很多客户可能对数据库设了一个很简单的密码，我们会将弱密码阻绝掉，账户也会拦截掉。
基于安全体系建设我们获得了一些认证，PCI-DSS、SOC、MTCST3、等保四级等等一系列安全认证。
说完RDS整体安全体系建设概览之后，再给大家再讲一下具体是怎么做的。
RDS安全体系介绍-数据面-网络控制
首先这个数据面的网络控制，首先左右两边有两个VPC，一个VPC是应用的VPC，就是你的APP；还有一块就是数据库的VPC，master和standby是通过Streaming复制的，在APP访问数据库中间我们会经过N层过滤，首先第一个是SSL+证书的安全认证，经过之后到SLB，SLB又会做黑白名单控制，大家可以在阿里云官网设置，哪些白名单能访问，哪些黑名单能访问，都会在这里面去做。然后做白名单控制，控制完之后，才能真正访问到数据库。
下面还有两个蓝色部分：一个是DMS，一个是云盾。
这两个主要作用是什么？
DMS主要解决的问题是客户应用可以访问数据库，但是客户的运维人员和管理人员该怎么访问数据库？
DMS解决了这个问题，DMS不但解决了这个问题，还可以做很多的数据库的限制，比如说这个人只能访问这个库这个表，比如说这个列要加密这个列不用加密等等，这些都是DMS做的。
还有一块是云盾，RDS现在是有开公网的，那开公网以后客户的访问就相当于暴露在互联网，有被劫持的风险等等，而云盾都是来做这个事情，就说在安全上、在网络规划上，云盾和DMS做了数据的加持安全工作。
RDS安全体系介绍-数据面-数据控制
安全体系数据面、数据控制这一块，主要分为几大块，首先用户会把密码放在KMS服务里面，KMS把这个密码加密以后传给了RDS管控体系，RDS管控其实根本不知道他的原始密码是多少，然后RDS管控把KMS的秘钥传给了RDS数据库，然后数据库再根据数据读取的情况进行了加密，有两种形式，一种是TDE加密，就是分布式存储，更常用的是TDE加密；还有一种方案是硬件加密，SGX加密。
TDE加密和SGX加密之间的区别是什么？
首先TDE加密更多的是数据存储加密，比如说你拿到这个数据文件你再去读的时候是完全读不出来的，因为是加密的；SGX加密更多做的是数据库读和写的加密，首先写的时候就要加密，然后读出来的时候也是加密的，当你没有秘钥的情况下，每次读出来的数据都是不一样的，这就是SGX加密。
RDS安全体系介绍-数据面-监控&审计
监控和审计，首先监控目前有十多项监控指标，最长存储30天，最小粒度为五秒，这些是数据库OS层面以及数据库本身，这些在监控指标后台可以看到。
审计，主要包括PG数据库日志审计，并且支持SQL审计，就是保证每一条SQL都是有记录的；还有一个是支持慢SQL审计，用户可以指定慢SQL时间，比如说超过多少需要记录；还有支持HA日志，比如说数据库为什么进行安全切换了等等，都是可以知道的，都是用户可以通过界面看到的，就是说我们的监控审计都是用户通过控制台可以自主的完成和发现的。
RDS安全体系介绍-实例可用性-HA
安全可用性离不开HA，实例可用性我们的目标是99.995%，四个九一个五。
HA有几个优势，一个是HA自身。
首先要有灵活的策略配置。灵活的安全配置就是客户可以自己在控制台设置HA策略（比如说检查心跳，心跳超过十秒而且连续三次超过十秒失败，那么我可以发射HA），这是第一点；第二个是链路的探测能力，很多时候，数据库本身是好的，但是应用访问不了数据库，这多半是链路上出了问题，这是一种情况；还有一种情况是数据库线程池打满，导致外部连接不了数据库，这种情况都属于数据库链路探测；所以说我们的HA是站在用户的角度去检查数据库是不是OK，这就是链路探测能力。
另外是基于RT的检测，首先第一点，数据库好不好、数据库运行的健不健康，其实我们不只是要保证数据库是活着，而是数据库的RT是多少？
比如说，有个客户每天0点-3点都要跑DW任务，这个时候他的rt一定很高，平时可能一个SQL只要0.1秒，如果跑DW可能要4-5秒，这个时候HA认为他这个数据是好还是不好？是要切还是不切？这都是个问题，所以我们引入了AI的预测，AI的预测主要是用来准确的知道这个数据库每天0-3点都是在跑数仓任务，那么这个时候就不会去做任何的切换动作，因为他是符合预期的。
再说数据的一致性，数据的一致性是HA的根本，我们在HA切之前，会做大量的数据库一致性的校验，保证每一条数据都是从主库传到备库。
关于HA的管控，大家可以看到很多软件，那些HA都是不具备集群能力的，都是单点，但是我们的HA是cluster，保证他的可灰度、可验证的，这是集群。
还有一个机房熔断能力，极端情况下，ZONE 1和ZONE 2断网，这时候我的HA是切好呢还是不切好？
切了之后，比如说主库是在ZONE 1，如果把ZONE 2的备库激活了好不好？好。
从可运营的角度最好，但是这里还有个问题，我的应用在不断的写熔一，他不知道ZONE 2已经成为一个新的主库了，这时候是会出现双写的情况。所以我们有了一个zonemonitor的东西，主要解决的是机房级孤岛和机房级容灾的时候zonemonitor可以连接两边的HA cluster，然后做相应的action。
还有一个是异地的fail over能力，异地的fail over能力更多的是解决rejoin级别数据库的可用性问题。
RDS安全体系介绍-数据一致性
数据的一致性，一个是数据库内核默认RPO小于0，我们要做到RPO小于等于0。
首先wal level是replica级别，还有synchronous commit这个我们也做了相应的配置，希望默认是Remote_write，只有异常情况下Local 模式。
今天着重讲的是备份的agent，首先在DB里面不断地get logs，然后不断得到日志，仅仅是得到日志的信息而不是把日志拿过来，然后我们再把日志的信息放到Local jobs里面，放到里面以后会去做Uploader任务的拆解与拆分，这更多的相当于是做一个并发，做一个偏移量，然后进行OSS上传，这就是备份。备份完以后，会检查状态，最后把PG的.wal文件改成.dump文件。
我们增量的备份要求RPO小于10，这是我们一直在努力追求的方向！
RDS安全体系介绍-数据安全性-备份
数据安全性里面的备份包含了大量东西，主要分为几块：全量备份、增量备份、安全性。
全量备份，我们具备分钟级的备份和恢复能力，由于我们底层使用的是分布式存储，依赖存储的备份能力，我们可以做到分钟级的备份和恢复，这第一点；
第二点是现在还支持永久备份，比如这个客户实例不需要了，但他需要一个备份，那我们有永久备份的能力；
还有就是库表级备份，库表级备份目前只有MySQL上面，PG上面没有，库表级备份做的更多的事情是，客户想要看11月5 号这个库这个表当时是什么样子，我们现在是支持的；
还有一个是增量备份，就是秒级的增量备份；
最后是安全性，很多人问如果数据库备份了，放在备份集上，是不是任何一个人把备份拿走了就可以了，他就可以恢复出数据库，这是不可以的，备份加密我们做了KMS和TDE的；还有就是异地容灾的备份和备份的有效性验证，备份对有效性验证我们是不断的有定时程序不断地去抽取备份，去做备份有效性验证。
RDS体系VS用户自建
RDS体系和用户自建，他们两个区别在哪里？
首先网络上面RDS数据支持SLB/NGLB多种模式和VPC模式，而用户自建一般都使用DNs的方式。
还有一种是硬件，我们有专业的硬件团队，每年都会迭代一款硬件，而用户基本上不会去做硬件的更新；OS我们也有专业的OS团队，专业的内核团队去做发布、迭代等等。
数据库我们也有专业的团队做疑难诊断、发布等等，管控我们有运维，备份，告警，HA等等，我们都有明确的SLA；而且我们的服务也是7*24专家服务，而用户自建完全是靠DBA，这是RDS体系和用户自建体系的区别。
全量备份，我们具备分钟级的备份和恢复能力，由于我们底层使用的是分布式存储，依赖存储的备份能力，我们可以做到分钟级的备份和恢复，这第一点；
第二点是现在还支持永久备份，比如这个客户实例不需要了，但他需要一个备份，那我们有永久备份的能力；
还有就是库表级备份，库表级备份目前只有MySQL上面，PG上面没有，库表级备份做的更多的事情是，客户想要看11月5 号这个库这个表当时是什么样子，我们现在是支持的；
还有一个是增量备份，就是秒级的增量备份；
最后是安全性，很多人问如果数据库备份了，放在备份集上，是不是任何一个人把备份拿走了就可以了，他就可以恢复出数据库，这是不可以的，备份加密我们做了KMS和TDE的；还有就是异地容灾的备份和备份的有效性验证，备份对有效性验证我们是不断的有定时程序不断地去抽取备份，去做备份有效性验证。
RDS体系VS用户自建
RDS体系和用户自建，他们两个区别在哪里？
首先网络上面RDS数据支持SLB/NGLB多种模式和VPC模式，而用户自建一般都使用DNs的方式。
还有一种是硬件，我们有专业的硬件团队，每年都会迭代一款硬件，而用户基本上不会去做硬件的更新；OS我们也有专业的OS团队，专业的内核团队去做发布、迭代等等。
数据库我们也有专业的团队做疑难诊断、发布等等，管控我们有运维，备份，告警，HA等等，我们都有明确的SLA；而且我们的服务也是7*24专家服务，而用户自建完全是靠DBA，这是RDS体系和用户自建体系的区别。
客户案例介绍
举例子，这是我们某个银行客户，他最后选择了阿里云的RDS PG产品，因为这是他对比了其他云厂商的结果。首先阿里云PG版本丰富度会高很多，我们支持PG9/PG10/PG11/PG12四个大版本，而且我们Region开放区有22个，与国内云厂商相比是领先的。
还有一个是安全加密，我们有SSL/KMS/TDE/SGX加密等等多种加密手段；还有一个存储形态，我们现在在阿里云官网可以买到本地盘和云盘两种形式，我们云盘最大支持32tb，可以满足很多的业务需求，还有功能丰富度，像刚刚说的监控报警等等功能会比较丰富，所以说这位客户在横向对比自建和其他云厂商以后，最后选择了阿里云和阿里SPG。
RDS PostgreSQL未来展望
未来主要通过安全，稳定，经济，智能这四个大的方向来走。
安全前面已经介绍了，稳定上我们要达到四个九一个五的目标，安全和稳定是基础。没有安全和稳定的基础，功能做的再好，再便宜的东西也没有用，这是第一点；
第二点是要做到便宜，就是要做经济，怎么能把数据库做的更经济，这也是我们最大的目标，比如说我们K8s化，要做资源磁化等等，就是要做提升性价比的事情；
还有智能，智能是未来的方向，目前RDS PG主要做两块，一块是基于AI的数据库智能优化；另外基于AI数据库智能运维优化，综合来说我们着重的方向还是在安全、稳定、经济、智能这四大块。
