51Testing软件测试论坛

标题: 老司机教你基于云计算构建高可用应用！ [打印本页]

作者: 学掌门网校 时间: 2018-3-23 10:56
标题: 老司机教你基于云计算构建高可用应用！
业务高可用是我们每个项目的需求，一个经常故障的项目，会让我们觉得不靠谱而选择放弃，从而导致项目的失败。今天，我们来聊一聊，如何让你自己的业务能够更加稳固的运行！
　　本次我们从四个不同的角度，来分析，如何让我们的应用更加稳固，平稳运行。

　　一、程序架构
　　优秀的代码
　　优秀的代码非常重要，即使我们拥有最好的硬件资源和架构，如果我们没有一套健壮的代码，其他资源再好都没有用，所以代码在设计和编写时，应当注意代码的健壮程度。优秀的代码不止开发起来方便，同时维护成本也较低，对于后续的优化来说，健壮的代码会让优化人员更加容易的找到问题的关键。
　　合理的架构
　　一个大型的、负载的单体应用可能会让你的整个开发进度缓慢、部署困难。所以，为了解决这种问题，不妨在开发初期便将应用程序设计为微服务架构的程序，虽然可能会提升程序之间的沟通难度，但却为你的应用提供了后续自由伸缩的可能，帮你解决后期发展起来的伸缩难题。
　　对于已经上线的应用，整体微服务化可能是非常困难的，毕竟你不可能让整个团队重新开发一套系统出来，这样的情况下，不妨把核心的、请求量较高的业务单独拆分出来，作为一个服务，让每一个服务都变成专注与单一的责任和功能的小的区块，更好的对外提供服务。
　　二、资源架构
　　在[url=]云计算[/url]的时代，云计算大行其道，为各行各业提供计算能力的支持，合理的利用云计算所提供的能力，就能帮助我们更加轻松的去做好应用的高可用。
　　一般来说，我们的每一个应用大体上都可以分为四层：入口层、业务层、缓存层、[url=]数据库[/url]层。当我们做好每一层的优化，那么我们的应用本身对于可能出现的问题进行避免。
　　入口层
　　入口层通常的情况下指的是Nginx、Apache等层面的东西，来负责应用的入口。一般情况下，我们会将应用程序定位在某一个IP，那么如果我们这个IP宕机了，就会导致服务的不可用，所以，在入口层我们不妨使用负载均衡，通过对压力的评估和成本的预估以及[url=]技术[/url]实现的难度，我们可以选择自建负载均衡或者使用云服务商提供的负载均衡器，在这样的情况下，当我们入口层后面的业务出现了单点故障时，可以自动借助于负载均衡的健康检查和请求分发的机制，把请求转发分配到可用的节点，保证服务的正常运转。
　　业务层
　　业务层通常是由PHP、Java、[url=]Python[/url]、Go等写的逻辑代码构成的，需要依赖于后台数据库及一些缓存层面的东西。如何实现业务层的高可用呢？最核心的就是，业务层不要有状态,将状态分散到缓存层和数据库。目前大家通常喜欢将以下几种数据放入业务层。
　　第一个是session，即用户登录相关的数据，但好的做法是将session放在数据库里，或者一个比较稳定的缓存系统中。
　　第二个是缓存，在访问数据库时，如果一个查询很慢，就希望将这些结果暂时放到进程里，下次再做查询时就不用再访问数据库了。
　　一个简单的原则就是业务层不要有状态。在业务层没有状态时，一台业务层服务器当掉了之后，Nginx/Apache会自动将所有的请求打到另外一台业务层的服务器上。由于没有状态，两台服务器没有任何差异，所以用户完全感受不到。如果把session放在业务层里面的话，那么面临的问题是，这个用户以前是登录在一台机器上的，这个进程死掉后，用户就会被登出了。
　　缓存层
　　非常简单的架构里是没有缓存这个概念的。但在访问量上来之后，[url=]MySQL[/url]之类的数据库扛不住了，比如在SATA盘里跑MySQL，QPS到达200、300甚至500时，MySQL的性能会大幅下降，这时就可以考虑用缓存层来挡住绝大部分服务请求，提升系统整体的容量。
　　缓存层如果希望实现高可用的架构，最好的方案就是将缓存层分的细一些，采用分布式的缓存或者是云计算服务商提供的云缓存能力，来减轻数据库层的压力。
　　数据库层
　　在数据库层面实现高可用，通常是在软件层面来做。例如，MySQL有主从模式(Master-Slave)，还有主主模式(Master-Master)都能满足需求。MongoDB也有ReplicaSet的概念,基本都能满足大家的需求。
　　三、云计算资源利用
　　上述的内容，主要还是和开发层面有关的，接下来我们来聊聊和运维强相关的内容
　　业务不单点
　　无论我们怎么对服务器的能力进行优化，终归是有个上限的，而且，单点服务器也更容易出现安全的故障问题。即便是云计算，也无法保证业务的永久可运行，即便是国内TOP1的阿里云，也出现过机房光缆被挖断过。所以，不要指望云计算服务商为你提供绝对可用的服务，更何况，在他们自己的服务等级协议里也不是100%。
　　所以，对于我们自己来说，要让自己的应用尽可能的不要单机运行，即使你的应用是单体服务，也可以让他跑在同一个节点的不同可用区（节点故障很少见）、不同节点的多个可用区（异地多活）、甚至，为了保证业务的运行，不要相信一家服务商，你可以同时采购多家的云计算资源（如果预算足够），就算有百分之一的可能，这个服务商挂掉了，你还可以切换到别的服务商去提供服务。
　　合理利用云资源
　　除了云计算最基础的计算能力，我们往往会购买一些附加的业务，比如云数据库、云缓存、云存储等等。
　　通过云存储，我们可以将非结构化的附件数据，存储到云服务商所提供的对象存储服务中，减少本地的文件存储压力，同时为业务服务器减少IO读写压力，更加专注于运算。
　　通过云缓存，我们可以在使用同一个可用区的多台主机时，将状态进行同步。帮助我们的应用同步状态，以免用户登录状态的丢失。
　　通过云数据库，我们可以借助云服务厂商所提供的能力，来拓展我们数据库的多备份、主从分离等等。让我们的业务数据查询请求进行分流，避免单一数据库的读写压力过大而导致业务的崩溃。
　　利用云计算供应商的提供能力，能够为你自己维护减轻压力，把精力放在业务本身。

　　四、关注服务商提供的公告信息
　　维护和故障是不可避免的，再大的云计算服务供应商，都有可能遇见这样或那样的故障文档，只要我们关注服务商所提供的公告信息，尽可能的去提前准备，那么就可以更换的提供服务。
　　这一方面做的比较好的是AWS和Azure，在每次出现故障后，他们都会提出故障公告，诚恳的说明故障的原因和解决方案，让用户明白故障的问题所在。这一方面，国内阿里云在完善故障通报机制，可以看到同一个故障出来阿里云都是通报最快，算是比较靠谱，其他云厂商，基本上官网不会公开，则大多是能瞒则瞒，能不报就不报，但是问题总归是问题，没有说明反而会让用户更加的疑惑，其他云厂商需要向AWS、Azure以及阿里云学习。
　　在维护方面，AWS、Azure就显得比较坑爹了，他们过往的维护周期比较长，如Xen底层的一个[url=]漏洞[/url]，无法采用热升级，一般就需要分批停机维护胡，用户如果没有准备，就需要关站一天，不过好在往往会提前一周发出维护公告，声明维护的节点，让用户提前做好准备。这一方面，国内遇到的还比较少，印象中如阿里云没有大规模停机维护的事件，一方面是AWS在前可作前车之鉴，另外也有技术上的因素。
　　不过，凡事无绝对。毕竟，云计算也是由一个个机房组成的，不是真正飘在天空中，飘在云上的服务器，我们在使用传统独立服务器可能会遇见的掉电、故障等问题，也会出现在云计算的主机上，只是相对来说，要少了很多，更加的安全。
　　所以，不管是AWS、Azure、还是阿里云或国内其他厂商，都在鼓励用户使用多个节点和可用区来部署业务，单点情况下出现的故障是不可避免的，当你使用多个节点时，出现故障的可能就大大的减小了。比如你可以在同一个可用区使用两台主机来做主备，再另外一个可用区做备份，这种情况下，即使一个可用区出现了问题，整体的服务也不会受影响。
　　最后，我们来总结下：
　　· 健壮的代码为高可用保驾护航
　　· 合理的架构为高并发情况下的伸缩提供可能
　　· 入口层的请求分发
　　· 业务层尽可能不存在状态
　　· 缓存层使用分布式缓存缓解压力
　　· 数据库层使用主备模式进行备份
　　· 合理利用云计算资源
　　· 注意数据的安全与备份
　　· 关注云计算厂商的维护公告

上文内容不用于商业目的，如涉及知识产权问题，请联系博为峰小编，我们立即处理。

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)