云计算典型架构十讲之通用高可用架构
admin
2023-09-18 08:03:36
0次
- 截止目前我们讲了弹性计算、网络和存储，还有成本优化，其实现实中遇到的很大的一个问题是，单个产品经过培训讲解都知道是干嘛的，但是组合起来就不知所云了，这还不是最关键的，其实想要服务好云计算的用户，必须要结合用户的使用场景、业务需求、自身情况来综合判断，所以在最后一个章节，我们列举了10个最常见的、最有代表性的、最有意义的业务架构，以具体的方案、结合产品来讲解不同的方案解决了什么样的问题、有什么优势、适合哪些客户、架构要点是什么、能做什么样的优化。
- 只有结合真正的需求不断磨练自己的架构思路才能更好的服务用户，在帮用户上云的过程中，利用自己的所学帮助用户做迁移、做优化、节约开销。
- 在这个课程中，我总结了10个最常见的客户场景和解决方案，基本涵盖了架构要点中的方方面面。那这十个分别是通用高可用架构，互联网通用，企业内部应用，迁移上云，面向大型架构的多地多活，混合云，业务全球部署和云原生，其中业务全球部署又分为三个小版本，一共是10大3小。
- 每个场景的解决方案都分为架构设计、架构解析和架构要点，接下来我们一个个看。
- 那首先第一个，就是通用的高可用架构，事实上高可用几乎涉及任何IT系统，小到一个微服务，大到一整个完整的系统都会要求高可用，尤其是在大型的业务系统中，因为不同的服务之间存在互相依赖，因此高可用会被反复提及，每一个小的组件都要求满足高可用，才能确保大的系统不会被拖累。
- 那业界用来维护高可用的开源工具也很多，比如keepalived和HAvip的组合，可以在物理机上组成一套高可用系统。那在云上，首先虚拟IP的漂移是大问题，虚拟环境很难允许用户去做二次的IP漂移，所以对于一些想要DIY高可用调度系统的用户来说可能就不太容易实现了，但是云上环境里，云厂商一般都提供了PAAS化的负载均衡调度器，在负载均衡的概念里，除了我们熟知的流量分发以外，故障切换、健康检查也是非常重要的功能。
- 图中左边的部分，是一个典型的业务单机部署示意图，在业务量比较小、用户不多的时候，大部分用户还是会选择单台服务器部署，nginx、PHP、MySQL全都在一台机器上，搭配一个公网IP就可以对外提供服务了，在这个阶段，业务上的诉求很简单，就是先运行起来，验证市场的反应和客户的认可度，所以部署方便、快捷、成本低是主要诉求，在云平台上选择一台linux或者Windows操作系统的机器，分别安装需要的软件，部署上业务代码就可以跑起来了，还有更省事儿的办法，大部分云平台都提供服务器环境预装，比如Linux、Nginx、Mysql、PHP环境一键部署，当然也包括Windows平台的。
- 在这个阶段，企业在IT资源上只需要支出几千块甚至几百块，租赁一个月的服务器就能让业务运行起来。
- 随着业务的发展， 用户越来越多，单台服务器的性能可能跟不上，用户可以选择升级这台服务器，但这显然不是最优解，因为不管单台服务器多强力，始终都有一个单点故障的问题。虽然技术发展到今天，服务器本身的宕机已经是一个小概率事件了，但是今天人们使用IT系统的频率和时长也是越来越多的，IT系统对人们的生活的重要性也是越来越大的。所以即使是小概率事件，也要想办法尽可能的避免。
- 其实生活中也有很多这样的例子，大家回想一下我们在高考的时候会拿几支笔？虽然以今天的制造工艺来说，一支圆珠笔突然不下水的概率非常小，但还是有的，我记得我那会儿高考所有人都至少带两支笔，学习好的学生可能带三支，这就是备份的重要性的。
- 当然这个例子可能不太适用于IT系统，但我们这么做的原因都是一样的，害怕当前使用的东西出现意料之外的错误。那和高考多带一支笔不一样的地方在于，IT系统的高可用往往是两个甚至多个一起干活儿，工作中不管是搬砖还是坐办公室，你很少会见到一件事情必须某个人，只能是他完成的，大部分工作都是多个人一起干，至少，某个位置的人没法上班的时候会有替补方案。
- 就拿搬砖来说，一个壮汉一天能搬一千块转，另一个一天能搬两千块，但工资要的多，看起来还可以，是个划算的买卖，但不管他能搬多少，他一定是有个上限的，这就跟单台服务器的纵向升级是一样的，上限是很明显的。而且有单点故障。
- 那我们再看图中右边的部分，引入另一台服务器和原有服务器一起干活儿，注意，这里的两台服务器干的活儿是一样的，跑的都是同一个业务，负载均衡负责把来访问的人分流调度到不同的服务器上去处理，减轻单台的压力，也避免了单点故障，当然，这里面会有一个会话保持的问题，就是用户A在1点访问了业务，是左边的服务器处理的，过了10分钟A又来刷新页面了，那这个时候是不能让右边的服务器处理的，或者说让上次负责A的请求的服务器来继续处理是最好的，那这个就叫会话保持，还有检查后端服务器的健康状态，不能把请求发给已经宕机的服务器，这都是云上的负载均衡的基本功能。
- 图中我们也看出来了，数据库也独立出来了。其实在实践中，我们作为架构师是经常建议客户从单机服务器改造到负载均衡架构的，其实成本并没有明显的增加，比如之前用一台8C 16G的机器，如果业务量没有增长，也可以换成两台4C 8G的机器组成一个高可用集群，成本还是一样的。但是，就这样看似百利无一害的建议，客户采纳的比例也相对很低。
- 原因就是，之前的一台服务器，代码、数据都在一台机器上，不存在同步的问题，现在机器多了，势必要有数据同步问题，比如开发团队更新了网站代码，以前只需要上传一次、部署一次就好了，现在机器多了，就得操作多次，文件、图片之类的数据也有访问设计问题。
- 这个才是实践中很多客户拒绝改造的原因，嫌麻烦，怕出问题。其实这个也是有办法解决的，无非就是引入共享文件系统，让两台服务器都去访问一份存储，就不存在同步问题，或者自己用sync做同步，另外有些云厂商也会提供一些自动化运维工具，比如阿里云的云助手、资源编排都可以做到批量运维。
- 其实所有有状态的数据都会涉及一个同步问题，当然这里面也包括数据库，一般中小型业务只需要一种关系型数据库就可以了，不管是MySQL也好、sqlserver也好，基本就能满足中小企业的需求，大的互联网项目一般会用到多种数据库引擎，这个我们后面再说。
- 那业务逻辑服务器现在做到了分开部署，高可用，数据库自然也要高可用，否则逻辑服的高可用就白做了，推荐用户用托管的云数据库服务，好处就不赘述了，我们在云数据库的章节已经讲的很细致。
- 这里唯一需要注意的是，和业务逻辑服务器不一样的地方就是，数据库的高可用是一主一备的，不是两台同时工作，只有主节点宕机的时候备节点才会升级成主节点。也就是典型的share everything 架构。实践中经常有用户说这也太浪费资源了，自建数据库的话可以一主一备，备节点还能做成只读节点，提高资源利用率，其实云数据库也可以，像阿里云的polarDB，采用了计算与存储分离的思想，属于share disk架构，可以两个节点都同时利用起来。 这两种都是可选的。
- 此外， 在右边的架构图中，我们可以看到，在同一个VPC内部，服务器和数据库分别位于两个不同的可用区，这样做是为了避免可用区级的故障，比如机房级断电，两个机房同时故障的概率就极小了。图中的负载均衡其实也是具备高可用的，只是云厂商已经帮用户做好了，用户不需要关心。
- 接下来我们看下单机部署和高可用架构的对比。
- 在运维难度上，单机部署运维起来工作量是相对比较少的，就一台机器，上去分别打开各个软件去维护就好了，那高可用架构这边因为机器多了，在业务逻辑服务器上的运维是相对复杂的。
- 在可用性上，单机部署具有单点故障风险，一旦宕机业务直接从互联网上消失，那负载均衡架构下多台服务器同时宕机的概率相对较小，尤其是在多可用区部署时，可用性更高。
- 在可靠性上，这里主要指数据，单机服务器相当于纯DIY，数据都要依赖用户自己备份，高可用架构下，云数据库帮用户节省了很多的数据治理工作，不用担心数据丢失、误删除，数据可靠性更高。
- 在弹性能力上，单机部署的话，很显然，只能对这台服务器做升级扩容，增加CPU、内存、磁盘的数量，最关键的是，纵向升级是有上限的，单台服务器最大也就上百个核心五六百G内存，而且纵向升级，收益不是线性的，这个我们前面也讲过了，到达了某个临界点以后，再升级也没什么提升。性价比不高，也依然避免不了单点故障。 在负载均衡主导的高可用架构下，业务逻辑服务器既可以对单台做纵向升级，也可以往集群里面添加新的服务器，变成三台、五台甚至更多，每一台也都能纵向升级，弹性无疑是远远好于单机部署的。
- 那在成本上，明显单机部署占优势，但是就IT系统来说，无论是互联网业务，还是公司内部系统，保障业务稳定运行都是重中之重，因为一旦系统崩溃，带来的损失根本不是一两台服务器的租赁费那么简单，所以对单机服务器的高可用改造是非常划算的。
- 最后，我们来复习一下本节高可用架构的要点：
- 首先是在高可用架构下，为了确保整体的可用性，每一个环节都得具备高可用，否则一个组件出了问题就可能前功尽弃。
- 第二个是要确保服务器是无状态的，否则会带来运维负担，比如多个服务器之间的数据同步问题，那用NFS来做集中的文件存储、用专门的服务器来做数据库都是不错的办法。
- 在高可用架构下服务器、负载均衡、数据库服务器都不止一台，如果对延迟没有极致苛刻的要求，最好保证多台机器位于不同的可用区，这样可以最大限度的保证容灾能力。
- 第四个是在使用厂商托管的服务之前，要提前调查好各项功能的兼容性和需求是不是匹配，比如负载均衡的7层调度、权限管理很多厂商是不支持的。
- 第五个是要去掉一些不必要的资源来压缩成本，比如每台服务器上的冗余磁盘，在数据集中存储时，这些磁盘是没什么用的，可以尽可能缩减，还有后端业务服务器的带宽。
- 第六个，是很多用户经常会忽略的，我们在实践中也会经常遇到，因为架构调整、升级带来的IP麻烦，绝大部分用户不会一上来就用高可用架构或是自建负载均衡，后期扩展的时候往往域名的解析IP会变，所以在一开始的时候就要选择弹性IP，把IP地址和计算资源分离开，分别作为独立的资源，这样以后不管是机器换代还是上负载均衡，IP都不用变。
- 这一点有些厂商是不支持的，用户还是要提前看好的。
- 最后，即便是简单的高可用架构，也需要一套监控系统，一般云厂商都会提供监控工具，比较重要的监控项有后端服务器的状态、网络带宽的水位、通信延时、丢包率等，一旦发现异常运维人员可以第一时间接到通知，作出应对。
- 好，以上就是架构的第一节的全部内容。
- 完整系列精讲包含【云产品系列】精讲：涵盖计算、存储、网络、数据库 【成本优化系列】和云上十大典型架构。