高可用架构常见场景
一、 前言：
“高可用性”（High Availability）通常来描述一个系统经过专门的设计，从而减少停工时间，而保持其服务的高度可用性。所以当我们一说到高可用，我们满脑子都是以负载均衡为主心骨搭建的拓扑图，以他为中心，从单节点拓展为多节点，消灭单点故障。但随着我们业务架构越来越庞大复杂，那么要考虑的就不再只是服务器维度的高可用了。接下来，我来给大家介绍一下不同维度的“高可用”在架构上是如何实现的。
二、 通用高可用
很多人在搭建业务的时候喜欢用一台高性能服务器搭建所有业务所需的应用和环境。比如服务器上搭建Nginx、会员系统、订单系统、自建数据库等等。这类搭建的初衷大概有简单省事、预算不足、初期业务量小感觉够用等因素。
这些困难业主要集中在业务上线初期，都是很现实的问题，不过随之带来的是更加现实的困难。性能瓶颈很快到来，后期调整架构会因越来越大的数据量和停服带来收益减少等等问题。
所以业务初期搭建一个基础高可用框架，日后根据需要逐渐添加功能。
A、后期业务增加后我们再根据需要逐步扩容，例如数据库读写压力大了，我们用Redis、数据库读写分离等手段。这样扩容不用复杂的操作，不用长时间的停服迁移重要的数据信息。
B、再后来业务量进一步扩大，需要短信服务、需要组网、需要安全防护等等，都可以灵活拓展。所以对于服务器层面来说，一开始就搭建一个高可用架构是至关重要的。
三、 进阶高可用：
容灾方面：
通常对于一个普通的APP、门户网站、内部系统等等业务，通用高可用已经足够了。但为了实现客户们日益提高的对体验感的的高要求，工程师们不知踏平了多少坑以后实践出了与之对应的高级高可用架构。这种架构不再针对某一个业务集群做高可用，而是以业务为维度。举个例子当某一个地域的业务不可用时，能有其他地域的备用集群顶上。
客户体验感：
当业务做大到一定程度，客户群体就不仅仅局限于一个市或者一个省，乃至一个国家。这时候，因为客户离业务集群太远，导致通讯质量不佳，延迟、丢包问题层出不穷。以前我们经常用“三秒”来定义一个网站的好坏，但现在主流网站大多均已采用“1.5秒”来打分了。传统的单业务节点越来越难满足了，那就得考虑多节点同时运行承载业务，可通过全局流量来实现。而多节点之间的数据同步可以用阿里云的云企业网来实现。
负载均衡从其应用的地理结构上分为本地负载均衡和全局负载均衡。本地负载均衡是指对同地域的服务器群做负载均衡，全局负载均衡是指对分别部署在不同地域有不同网络结构的服务器群做负载均衡。
• 多线路智能化解析服务
全局流量管理利用DNS智能解析和应用服务的运行状态健康检查，将用户访问定向到最合适的IP地址，使访问用户获得最快捷、最流畅的体验。
• 跨地域容灾
全局流量支持将不同地域的IP地址添加到不同的地址池，并配置健康检查。在访问策略配置中，设置默认地址池为地址池甲，Failover地址池为地址池乙，即可以实现应用服务主备IP容灾切换。
• 不同地域访问加速
使用全局流量管理，可以使不同地域的用户访问不同的IP地址池，实现用户分组管理，分组接入，帮助应用服务提高用户访问体验。
这样我们也就能搭建一个便于客户就近访问的业务集群了，而用CEN组网打通各机房VPC，数据同步方面的工作也能变得更简单。
