单机&集群架构
对于一个高可用系统来说，为了提升系统的稳定性，需要以下常用技术服务拆分、服务冗余、限流降级、高可用架构设计、高可用运维，而本篇主要详细介绍下，高可用架构设计。容灾备份以及同城多活，异地多活架构的设计。
我们知道从最简单的系统来说的话，就是单机系统，然后为了实现高可用，最简单的方式就是使用集群模式，通过冗余服务来实现高可用。
但是这样就需要引入负载均衡、服务健康检查、服务发现，动态路由。
一般来对外的服务，都是使用SLB进行提供一个统一的网络IP+PORT，然后SLB进行实时检查服务的网络端口是否在线，不在线则发出报警机制。然后SLB根据一定的负载均衡算法将用户请求打到将康的服务上。
而对于内部的系统，可能使用的是RPC进行交互，那么需要服务注册到注册中心上，zk或者是consul。上游服务根据服务名从注册中心查询到对应的服务地址和端口号。
这样的模式其实对于大多数的中小型公司就可以，而灾备设计和异地多活主要解决的是地理基本的灾难，比如机房断电，网络不可用，地震、火灾等 会直接导致整个机房所提供的服务不可用。对于大型互联网公司来说的话，一般都会做灾备设计和异地多活设计。
灾备设计
灾备 = 容灾+备份。
备份 ： 将系统所产生的的所有重要数据多备份几份。
容灾 ： 在异地建立两个完全相同的系统。当某个地方的系统突然挂掉，整个应用系统可以切换到另一个，这样系统就可以正常提供服务了。
异地多活
异地多活 描述的是将服务部署在异地并且服务同时对外提供服务。和传统的灾备设计的最主要区别在于“多活”，即所有站点都是同时在对外提供服务的。异地多活是为了应对突发状况比如火灾、地震等自然或者人为灾害。
同城多中心
同城异区其实就是 比如在北京 朝阳和通州部署两套IDC机房，提供同样的服务。这种架构在设计上比较简单，使用告诉的专用网络通道，基本等同于同一个机房。设计复杂度降低，以及对应的设计和资源成本。
可以应对机房级别的灾难，逻辑上同一个机房。
跨城多中心
跨城异地其实就是北京一个IDC机房，上海一个IDC，为了应对城市级别的灾难。
但是无法避免区域性灾难。
跨国多中心
跨国这种一般针对的都是海内外业务都有的互联网公司，比如字节的抖音和TIKTOK。以及为了合规性，一般本国的数据，服务器都需要在本国内，比如在印尼做电商，那么相关机房数据都需要在印尼。
整体对比
)
