开发者学堂课程【企业级互联网分布式系统应用架构学习：高可用架构方案实例】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/369/detail/4395
高可用架构方案实例
内容介绍：
一、高可用架构
二、可用区
三、双可用区
一、高可用架构
1、本课程讲解高可用架构，什么是高可用架构？通过下图来理解从非高可用架构到高可用架构的变化。
通常非高可用架构就是在某一个应用架构设计的过程中，中间有单点故障。比如应用服务器只有一台，或者说数据库只有一台，这个通常称之为非高可用架构。一旦应用服务器出现问题，比如说他异常宕机，或者是发生了虚机的迁移，那整个架构或者整个应用就需要停机。
2、通过上图可以看到，这是一个应用的部署架构图。用户在云上购买了一台虚拟机，这台虚机有一个互联网IP。从应用的视角看，应用是可被访问的，而且在这个虚机上部署了多个软件，比如说财务、办公等等软件，用户也在这台机器上部署了自己的数据库。这个架构从使用上正常情况下是没有问题的，他可以应用，也可以正常的接收互联网来的请求，应用也可以访问数据库。但是问题的核心是这台机器一旦出现故障，客户所有的软件都无法访问，所以这个架构是有致命缺陷的。
3、但是从成本考虑，并不在意宕机导致的不可用时间，那这个架构也没有太大的问题。但如果对应用的高可用要求非常高，比如说一定要72小时服务，那这个架构就不是太合适了。同时，这个架构也会带来运维的风险，比如说数据库的管理员也要登录到这台机器上进行数据库的操作，那多个软件的运维人员也要登录到这台机器上进行应用的部署和应用的运维。一旦有管理员操作失误，可能会对其他应用或者数据库产生影响，所以从高可用的视角去看，是有一个比较大的问题的架构。
4、真正的高可用的架构如下图，
首先，要将应用或者软件进行纵向的拆分，比如说把软件一和软件二等等软件进行独立的部署，那每一个软件应用都要有自己完整的部署架构。通常就包含这样几个部分，负载均衡，下边对应的是应用服务器，或者有的时候还有外部服务器，再往下是数据库属性。这个架构会有很大的好处，就是任何一台应用或者虚机，云服务器停止服务都不会对应用产生影响。而且在运维的过程中可以更好地将运维的角色进行划分，运维软件一的用户只能访问云服务器一和云服务器二，运维软件二的运维人员，只能访问另外软件二的里面的两个服务器。同时，应用的部署人员和数据库的运维人员进行分离，如果这样去进行一个应用设计或者架构部署以后，整个系统的可用性就非常高了，他没有太明显的单点故障。
二、可用区
1、但是在互联网应用架构下，可能还面临一个风险，就是如果把这些服务器放在同一个机房，如果这个机房断电或者是对外的网络因为各种原因，比如说施工挖断光缆这些突发事情以后，整个应用访问可能也会受到影响。所以在这里面公有云的供应商就提出了一个概念，叫做可用区。如果学过阿里云前面的一些课程可能会对可用区有一些了解，在这再进一步做一个说明。
2、所谓的可用区，就是公有云供应商，在设计基础网络设施的时候，用可用区来进行资源的隔离。具体的理解就是，比如说、在北京阿里云会建多个可用区，每个可用区都是单独的一套环境，比如说供电、网络的接入，也就是一个可用区停止服务，其他的可用区还可以对外进行服务，不受到影响。同时，这两个可用区在正常情况下会用高速光纤连接在一起，在使用的过程中，用户可以把他的服务器部署在两个可用区，这两个服务器也感知不到他们处于不同的可用区，因为他们之间的网络延时非常小。
3、真正的高可用架构，实际上把应用设计成多可用区的，这两个有什么差别？单可用区它的高可用架构是刚才讲的方式，
就是互联网用户通过 SLB 接入，所有的应用服务器或云服务器 ECS 在一个可用区，同时 rds 的主备也在一个可用区。额外提一下，阿里云的 rds 会自动在后台做主备的架构，有点类似于只读库的架构。在正常情况下，只有生产数据库被前面的应用访问，同时生产库会把数据同步到在备库中。当然对应用是不可见的，在正常情况下，应用访问的都是生产库，只有出现问题以后，阿里云的rds 会自动的切换到在备库。
4、单可用架构设计中，rds 数据库的生产库和在备库是在同一个可用区的。实际上高可用设计在刚才的章节中已经介绍过了，他的问题在于，一旦这个可用区出现问题，比如说网络被挖断、整个机房断电等，虽然出现的概率很低，但是还是有这样一个可能的。
三、双可用区
1、更高的可用区架构把它称之为双可用区高可用架构，也有一个名词叫做两地三中心，还有一个叫法叫同城灾备。同城灾备就是在一个城市的两个区域有两个机房。通常来讲可用区都是在一个城市的相距几十公里的两个地方建的两个机房，在做这个部署的时候，整个架构就变成了如图的情况。
2、还是负载均衡器 SLB ，但这个负载均衡就具备了跨机房的漂移能力，负载均衡本身会绑定一个 IP 地址，互联网的 IP地址，这个 IP 地址实际上是一个虚拟的 IP，也就是说，当a可用区出现问题以后，负载均衡器附带的 IP 可以漂移到可用去b。这样用户在不更改 DNS 的情况下，即便可用区a出现问题，那负载均衡的 IP 还是同一个，所以可以无缝的切换到可用区 b。
3、在应用部署之后，这个架构也需要额外注意，千万不要把应用的所有的云服务器部署在一个可用区，一定要将应用的云服务器分散部署到 a 和 b 两个可用区，比如说图上看到的1、2、3、4这是四台，
如果在极端情况下，a可用区出现问题，因为b可用区还有两台服务器，或者说还有两台云服务器可以服务，所以整个应用不会出现垮掉的问题，或者是不可访问的问题。
4、再往下一层就是 rds 数据库也需要选用多可用区的 rds。多可用区 rds 刚才也做了一定的介绍，他在生产数据库和在备数据库位于两个可用区，当可用区a出现问题以后，位于可用区b的容灾数据库可以立马生效，然后服务于云服务器三和云服务器四。这样的架构就可以保证在一个可用区出现问题以后，应用可以由b可用区的资源进行接管。毕竟可用区完全不可访问的情况，是一个小概率事件，而且两个可用区都不可访问，是一个更小概率事件，所以同城高可用架构已经可以保证应用非常高级别的可用架构。
5、在这个架构里面再总结一下，互联网用户通过 SLB 接入，然后 ECS 或者云服务器在两个可用区分别购买数量相等的多台。在购买过程中，优选低配置而不是购买少量高配置的模式，这样能够更好的保证安全性。数据库在选择的时候选择多可用数据库，以上是有关于高可用部署的架构。
