Open AlexiaChen opened 4 years ago
异地就是指地理位置的不同，多活就是不同的地理位置上的系统都能够提供业务服务，这里的活是Active的意思。
这种方案真是要真正的大型互联网公司才有这种架构了，抗自然灾害能力比较强。
现在城市都有区嘛，昆明有五华，盘龙等。一般各个区的网络或者电路都是松耦合的。所以会在各个区部署多个机房，距离一般都是几十公里，通过搭建高速网络，能够实现和同机房的网络传输速度。如果该城市遭遇地震，水灾，一般就废了。
业务部署在不同的城市的多个机房，距离最好远离些，因为能有效面对极端灾难事件。但是这样的架构复杂，而且网络传输速度会降低，因为现实世界都是各种路由和中转，不可控因素增加。比如广州到北京的正常情况下RTT大约是50ms，如果有网络抖动，RTT可能飙升到500ms甚至1s，如果还有线路丢包，那延迟可能就是几秒几十秒了。
既然物理世界决定了延迟不低，那么在这个时间窗口内数据不一致，还要能正常提供服务，这样就比较矛盾：数据不一致业务肯定不会正常，但是跨城异地肯定会导致数据不一致。
如何解决？重点还是在“数据”类型上，根据数据的业务特性来做不同的架构。如果是金融行业一些强一致需求，比如，银行存款余额，支付宝余额等，这类数据实际上是无法做到跨城异地多活的。所以对于余额这类数据，最多只能采用同城异区这种架构。
而对数据一致性要求不高，数据变更不频繁，甚至数据丢失影响也不大的业务，跨城异地多活就能用上了。比如，用户登录，新闻网站，微博，百度贴吧等等。
业务部署在不同国家的多个机房。哈，这个距离一般更远了，网络延时更大，延时平均在几秒，对于用户感觉特别明显，很显然，这样的架构就连微博，贴吧都不适用了。一般用在为不同地区的用户提供服务，比如：微软的Bing搜索有国内版和国际版，亚马逊有美亚，日亚。还有一个场景就是，为只读类业务做多活，比如Google的搜索业务，爬虫爬到的那些网页索引，不需要实时，搜索结果基本相同，访问哪里都差不多。
前提不要犯一个错误：保证所有业务“异地多活”。这种显然是最终要完蛋的，有些业务特性做异地多活可能无解。
所以要优先实现核心业务的异地多活架构。
前提不要犯一个错误：所有数据实时同步。也是扯淡的。你应该考虑尽量减少数据同步，只同步核心业务相关的数据，保证最终一致性。
基本上主流的存储系统都有同步功能，MySQL主从复制，Redis的Cluster功能，Elastic Search的集群功能。这些系统的同步功能已经非常强大了，能够拿来直接用，但是也限制了一些人的想象力：只使用存储系统的同步功能
绝大部分场景下，存储系统自带的同步功能足够了，但是一些极端场景，难以满足业务需求。解决方案就是手脚并用，多种方案一起上。比如，用消息队列方式，二次读取，回源读取等。
前提不要犯一个错误：保证业务100%可用。这是不现实的。事实上也绝对不可能保证100%可用。做到百分之99%就可以了，其他的可以用变相手段搞定，比如，挂公告，事后对用户进行补偿。
异地多活架构主要是应对系统故障，发生概率比较小，还有另一种故障影响没系统级那么大，但是发生的概率较高，这就是接口级故障。
接口故障表现就是系统没有宕机，网络没有中断，但是业务表现出问题了。比如，业务响应慢，大量访问超时，大量访问出现异常，无法连接数据库等等。
引起这种原因，要不是系统负载过大，要不就是程序bug。但是解决接口故障的核心思想也是：优先保证核心业务，优先保证绝大部分用户。
某些业务或接口的功能降低，只提供部分功能，也可以完全停掉所有功能。核心思想是弃车保帅，优先保证核心业务。
和降级这个概念比较容易混淆，降级的目的是应对系统自身的故障，熔断的目的是应对依赖的外部系统的故障情况。比如A服务依赖并调用B服务和C服务，但是B服务响应慢，间接导致A服务响应慢，这时候就需要熔断机制，即A服务不再请求B服务这个接口，或者请求B服务就立刻返回错误，避免拖慢整个A服务。A服务中依赖C服务的业务不会受到影响。
现今的微服务框架一般都用这种功能，比如Spring Cloud。
一般是为了对抗用户访问压力，限制流量。到一定流量阈值就丢弃请求。算法有很多，什么令牌桶什么的。不过多描述。
限流分两种：
基于请求限流：某个指标上限，比如当前登录用户量等。缺点是，不好量化，不同机器各种指标的阈值上限不同
基于资源的限流： 连接数，线程数，文件句柄，CPU或内存占用率。这种方案能够更加有效的反映当前系统的压力
异地多活
异地就是指地理位置的不同，多活就是不同的地理位置上的系统都能够提供业务服务，这里的活是Active的意思。
这种方案真是要真正的大型互联网公司才有这种架构了，抗自然灾害能力比较强。
异地多活架构
同城异区
现在城市都有区嘛，昆明有五华，盘龙等。一般各个区的网络或者电路都是松耦合的。所以会在各个区部署多个机房，距离一般都是几十公里，通过搭建高速网络，能够实现和同机房的网络传输速度。如果该城市遭遇地震，水灾，一般就废了。
跨城异地
业务部署在不同的城市的多个机房，距离最好远离些，因为能有效面对极端灾难事件。但是这样的架构复杂，而且网络传输速度会降低，因为现实世界都是各种路由和中转，不可控因素增加。比如广州到北京的正常情况下RTT大约是50ms，如果有网络抖动，RTT可能飙升到500ms甚至1s，如果还有线路丢包，那延迟可能就是几秒几十秒了。
既然物理世界决定了延迟不低，那么在这个时间窗口内数据不一致，还要能正常提供服务，这样就比较矛盾：数据不一致业务肯定不会正常，但是跨城异地肯定会导致数据不一致。
如何解决？重点还是在“数据”类型上，根据数据的业务特性来做不同的架构。如果是金融行业一些强一致需求，比如，银行存款余额，支付宝余额等，这类数据实际上是无法做到跨城异地多活的。所以对于余额这类数据，最多只能采用同城异区这种架构。
而对数据一致性要求不高，数据变更不频繁，甚至数据丢失影响也不大的业务，跨城异地多活就能用上了。比如，用户登录，新闻网站，微博，百度贴吧等等。
跨国异地
业务部署在不同国家的多个机房。哈，这个距离一般更远了，网络延时更大，延时平均在几秒，对于用户感觉特别明显，很显然，这样的架构就连微博，贴吧都不适用了。一般用在为不同地区的用户提供服务，比如：微软的Bing搜索有国内版和国际版，亚马逊有美亚，日亚。还有一个场景就是，为只读类业务做多活，比如Google的搜索业务，爬虫爬到的那些网页索引，不需要实时，搜索结果基本相同，访问哪里都差不多。
异地多活设计技巧
1. 保证核心业务异地多活
前提不要犯一个错误：保证所有业务“异地多活”。这种显然是最终要完蛋的，有些业务特性做异地多活可能无解。
所以要优先实现核心业务的异地多活架构。
2. 核心数据最终一致性
前提不要犯一个错误：所有数据实时同步。也是扯淡的。你应该考虑尽量减少数据同步，只同步核心业务相关的数据，保证最终一致性。
3. 采用多种手段同步数据
基本上主流的存储系统都有同步功能，MySQL主从复制，Redis的Cluster功能，Elastic Search的集群功能。这些系统的同步功能已经非常强大了，能够拿来直接用，但是也限制了一些人的想象力：只使用存储系统的同步功能
绝大部分场景下，存储系统自带的同步功能足够了，但是一些极端场景，难以满足业务需求。解决方案就是手脚并用，多种方案一起上。比如，用消息队列方式，二次读取，回源读取等。
4. 只保证绝大部分用户的异地多活
前提不要犯一个错误：保证业务100%可用。这是不现实的。事实上也绝对不可能保证100%可用。做到百分之99%就可以了，其他的可以用变相手段搞定，比如，挂公告，事后对用户进行补偿。
接口级的故障应对方案
异地多活架构主要是应对系统故障，发生概率比较小，还有另一种故障影响没系统级那么大，但是发生的概率较高，这就是接口级故障。
接口故障表现就是系统没有宕机，网络没有中断，但是业务表现出问题了。比如，业务响应慢，大量访问超时，大量访问出现异常，无法连接数据库等等。
引起这种原因，要不是系统负载过大，要不就是程序bug。但是解决接口故障的核心思想也是：优先保证核心业务，优先保证绝大部分用户。
降级
某些业务或接口的功能降低，只提供部分功能，也可以完全停掉所有功能。核心思想是弃车保帅，优先保证核心业务。
熔断
和降级这个概念比较容易混淆，降级的目的是应对系统自身的故障，熔断的目的是应对依赖的外部系统的故障情况。比如A服务依赖并调用B服务和C服务，但是B服务响应慢，间接导致A服务响应慢，这时候就需要熔断机制，即A服务不再请求B服务这个接口，或者请求B服务就立刻返回错误，避免拖慢整个A服务。A服务中依赖C服务的业务不会受到影响。
现今的微服务框架一般都用这种功能，比如Spring Cloud。
限流
一般是为了对抗用户访问压力，限制流量。到一定流量阈值就丢弃请求。算法有很多，什么令牌桶什么的。不过多描述。
限流分两种：
基于请求限流：某个指标上限，比如当前登录用户量等。缺点是，不好量化，不同机器各种指标的阈值上限不同
基于资源的限流： 连接数，线程数，文件句柄，CPU或内存占用率。这种方案能够更加有效的反映当前系统的压力