云计算典型架构十讲之通用高可用架构

截止目前他们讲了弹性计算、网络和存储，还有成本强化，只不过现实中遇到的很大的两个难题是，单个商品经过训练传授都知道是干什么的，但是女团出来就不合逻辑了，这还不是最关键的，只不过想服务项目好云计算的使用者，必须要紧密结合使用者的使用情景、销售业务市场需求、自身情况来综合判断，因此在最后两个段落，他们列举了10个最常用的、最有代表性的、最有意义的销售业务构架，以具体的计划、紧密结合商品来传授相同的计划解决了怎样的难题、有什么优势、适合哪些顾客、构架关键点是什么、能做怎样的强化。

只有紧密结合真正的市场需求不断磨炼自己的构架思路就可以更好的服务项目使用者，在帮使用者穗序的过程中，利用自己的学以致用帮助使用者做北迁、做强化、节约开支。

在那个课程中，我总结了10个最常用的顾客情景和软件系统，基本涵盖了构架关键点中的各个方面。那这十个依次是通用型高需用构架，互联网通用型，企业内部应用，北迁穗序，面向小型构架的多地多活，混合云，销售业务亚洲地区布署和云原生植物，其中销售业务亚洲地区部署又分成三个小版本，一共是10大3小。

每个情景的软件系统都分成构架设计、构架解析和构架关键点，接下来他们两个个看。

那具体来说第两个，就是通用型的高需用构架，事实上高需用几乎涉及任何IT控制系统，小到两个微服务项目，大到一整个完整的控制系统单厢明确要求高需用，尤其是在小型的销售业务控制系统中，因为相同的服务项目之间存在互相依赖，因此高需用会被反复提及，每两个小的模块都明确要求满足高需用，就可以确保大的控制系统不会被拖累。

那业界用来维护高需用的开源工具也很多，比如说keepalived和HAvip的女团，能在物理机内组成一套高需用控制系统。那在云上，具体来说虚拟IP的飘移是大难题，虚拟自然环境很难允许使用者去做二次的IP飘移，因此对于一些想DIY高需用调度控制系统的使用者来说可能就不太容易实现了，但是云上自然环境里，云厂商一般都提供更多了PAAS化的阻抗平衡运维器，在阻抗平衡的概念里，除了他们津津乐道的流量递送以外，故障切换、体检也是非常重要的功能。

图中左边的部分，是两个众所周知的销售业务FPS布署左图，在销售业务规模比较小、使用者不多的时候，绝大部分使用者还是会优先选择DF93伺服器布署，nginx、PHP、MySQL全都在两台电脑上，搭配两个奥梅利IP就能对外提供更多服务项目了，在那个期，销售业务上的政治理念很简单，就是先运转出来，验证市场的反应和顾客的认知度，因此布署方便、快捷、效率高是主要政治理念，在云网络平台上优先选择两台linux或者Windows操作控制系统的电脑，依次安装须要的软件，布署上销售业务代码就能跑出来了，还有更省事儿的办法，绝大部分云网络平台都提供更多伺服器自然环境预载，比如说Linux、Nginx、Mysql、PHP自然环境全屏布署，当然也包括Windows网络平台的。

在那个期，企业在IT资源上只须要支出两块钱甚至几千元，租赁两个月的伺服器就能让销售业务运转出来。

随着销售业务的发展， 使用者越来越多，DF93伺服器的性能可能太慢，使用者能优先选择升级这台伺服器，但这显然不是最优解，因为不管DF93伺服器多强力，始终都有一个单点故障的难题。虽然技术发展到今天，伺服器本身的宕机已经是两个小概率事件了，但是今天人们使用IT控制系统的频率和时长也是越来越多的，IT控制系统对人们的生活的重要性也是越来越大的。因此即使是小概率事件，也要想办法尽可能的避免。

只不过生活中也有很多这样的例子，大家回想一下他们在高考的时候会拿几支笔？虽然以今天的制造工艺来说，一支圆珠笔突然不下水的概率非常小，但还是有的，我记得我那会儿高考所有人都至少带两支笔，学习好的学生可能带三支，这就是备份的重要性的。

当然那个例子可能不太适用于IT控制系统，但他们这么做的原因都是一样的，害怕当前使用的东西出现意料之外的错误。那和高考多带一支笔不一样的地方在于，IT控制系统的高需用往往是两个甚至多个一起干活儿，工作中不管是搬砖还是坐办公室，你很少会见到一件事情必须某个人，只能是他完成的，绝大部分工作都是多个人一起干，至少，某个位置的人没法上班的时候会有替补计划。

就拿搬砖来说，两个壮汉一天能搬一千块转，另两个一天能搬两千块，但工资要的多，看出来还能，是个划算的买卖，但不管他能搬多少，他一定是有个上限的，这就跟DF93伺服器的纵向升级是一样的，上限是很明显的。而且有单点故障。

那他们再看图中右边的部分，引入另两台伺服器和原有伺服器一起干活儿，注意，这里的两台伺服器干的活儿是一样的，跑的都是同两个销售业务，阻抗平衡负责把来访问的人分流运维到相同的伺服器上去处理，减轻DF93的压力，也避免了单点故障，当然，这里面会有两个会话保持的难题，就是使用者A在1点访问了销售业务，是左边的伺服器处理的，过了10分钟A又来刷新页面了，那那个时候是不能让右边的伺服器处理的，或者说让上次负责A的请求的伺服器来继续处理是最好的，那那个就叫会话保持，还有检查后端伺服器的健康状态，不能把请求发给已经宕机的伺服器，这都是云上的阻抗平衡的基本功能。

图中他们也看出来了，数据库也独立出来了。只不过在实践中，他们作为构架师是经常建议顾客从FPS伺服器改造到阻抗平衡构架的，只不过成本并没有明显的增加，比如说之前用两台8C 16G的电脑，如果销售业务规模没有增长，也能换成两台4C 8G的电脑组成两个高需用集群，成本还是一样的。但是，就这样看似百利无一害的建议，顾客采纳的比例也相对很低。

原因就是，之前的两台伺服器，代码、数据都在两台电脑上，不存在同步的难题，现在电脑多了，势必要有数据同步难题，比如说开发团队更新了网站代码，以前只需要上传一次、布署一次就好了，现在电脑多了，就得操作多次，文件、图片之类的数据也有访问设计难题。

那个才是实践中很多顾客拒绝改造的原因，嫌麻烦，怕出难题。只不过那个也是有办法解决的，无非就是引入共享文件控制系统，让两台伺服器都去访问一份存储，就不存在同步难题，或者自己用sync做同步，另外有些云厂商也会提供更多一些自动化运维工具，比如说阿里云的云助手、资源编排都能做到批量运维。只不过所有有状态的数据单厢涉及两个同步难题，当然这里面也包括数据库，一般中小型销售业务只须要一种关系型数据库就能了，不管是MySQL也好、sqlserver也好，基本就能满足中小企业的市场需求，大的互联网项目一般会用到多种数据库引擎，那个他们后面再说。

那销售业务逻辑伺服器现在做到了分开布署，高需用，数据库自然也要高需用，否则逻辑服的高需用就白做了，推荐使用者用托管的云数据库服务项目，好处就不赘述了，他们在云数据库的段落已经讲的很细致。

这里唯一须要注意的是，和销售业务逻辑伺服器不一样的地方就是，数据库的高需用是一主一备的，不是两台同时工作，只有主节点宕机的时候备节点才会升级成主节点。也就是众所周知的share everything 构架。实践中经常有使用者说这也太浪费资源了，自建数据库的话能一主一备，备节点还能做成只读节点，提高资源利用率，只不过云数据库也能，像阿里云的polarDB，采用了计算与存储分离的思想，属于share disk构架，能两个节点都同时利用出来。 这两种都是可选的。

此外， 在右边的构架图中，他们能看到，在同两个VPC内部，伺服器和数据库依次位于两个相同的需用区，这样做是为了避免需用区级的故障，比如说机房级断电，两个机房同时故障的概率就极小了。图中的阻抗平衡只不过也是具备高需用的，只是云厂商已经帮使用者做好了，使用者不须要关心。

接下来他们看下FPS布署和高需用构架的对比。

在运维难度上，FPS布署运维出来工作量是相对比较少的，就两台电脑，上去依次打开各个软件去维护就好了，那高需用构架这边因为电脑多了，在销售业务逻辑伺服器上的运维是相对复杂的。

在需用性上，FPS布署具有单点故障风险，一旦宕机销售业务直接从互联网上消失，那阻抗平衡构架下多台服务器同时宕机的概率相对较小，尤其是在多需用区布署时，需用性更高。

在可靠性上，这里主要指数据，FPS伺服器相当于纯DIY，数据都要依赖使用者自己备份，高需用构架下，云数据库帮使用者节省了很多的数据治理工作，不用担心数据丢失、误删除，数据可靠性更高。

在弹性能力上，FPS布署的话，很显然，只能对这台伺服器做升级扩容，增加CPU、内存、磁盘的数量，最关键的是，纵向升级是有上限的，DF93伺服器最大也就上百个核心五六百G内存，而且纵向升级，收益不是线性的，那个他们前面也讲过了，到达了某个临界点以后，再升级也没什么提升。性价比不高，也依然避免不了单点故障。 在阻抗平衡主导的高需用构架下，销售业务逻辑伺服器既能对DF93做纵向升级，也能往集群里面添加新的伺服器，变成三台、五台甚至更多，每两台也都能纵向升级，弹性无疑是远远好于FPS布署的。

那在成本上，明显FPS布署占优势，但是就IT控制系统来说，无论是互联网销售业务，还是公司内部系统，保障销售业务稳定运转都是重中之重，因为一旦控制系统崩溃，带来的损失根本不是一两台伺服器的租赁费那么简单，因此对FPS伺服器的高需用改造是非常划算的。

最后，他们来复习一下本节高需用构架的关键点：

具体来说是在高需用架构下，为了确保整体的需用性，每两个环节都得具备高需用，否则两个模块出了难题就可能前功尽弃。

第二个是要确保伺服器是无状态的，否则会带来运维负担，比如说多个伺服器之间的数据同步难题，那用NFS来做集中的文件存储、用专门的伺服器来做数据库都是不错的办法。

在高需用构架下伺服器、阻抗平衡、数据库伺服器都不止两台，如果对延迟没有极致苛刻的明确要求，最好保证多台电脑位于相同的需用区，这样能最大限度的保证容灾能力。

第四个是在使用厂商托管的服务项目之前，要提前调查好各项功能的兼容性和市场需求是不是匹配，比如说阻抗平衡的7层运维、权限管理很多厂商是不支持的。

第五个是要去掉一些不必要的资源来压缩成本，比如说每台伺服器上的冗余磁盘，在数据集中存储时，这些磁盘是没什么用的，能尽可能缩减，还有后端销售业务伺服器的带宽。

第六个，是很多使用者经常会忽略的，他们在实践中也会经常遇到，因为构架调整、升级带来的IP麻烦，绝绝大部分使用者不会一上来就用高需用构架或是自建阻抗平衡，后期扩展的时候往往域名的解析IP会变，因此在一开始的时候就要优先选择弹性IP，把IP地址和计算资源分离开，依次作为独立的资源，这样以后不管是电脑换代还是上阻抗平衡，IP都不用变。

这一点有些厂商是不支持的，使用者还是要提前看好的。

最后，即便是简单的高需用构架，也须要一套监控控制系统，一般云厂商单厢提供更多监控工具，比较重要的监控项有后端伺服器的状态、网络带宽的水位、通信延时、丢包率等，一旦发现异常运维人员能第一时间接到通知，作出应对。