站点隔离

隔离相关

• 线程隔离
• 进程隔离
• 集群隔离
• 机房隔离
• 读写隔离
• 动静隔离
• 爬虫隔离
• 热点隔离
• 资源隔离

隔离是指将系统或者资源区分开、是为了在系统发生故障时、限定传播的范围、或者减少资源竞争或者保证服务间不相互影响

线程隔离

主要是指线程池隔离、在实际使用时、会把请求分类、然后交给不同的线程池处理、当一种业务出现问题时、不会讲故障扩散

进程隔离

一般是随业务发展、从0到1 的过程、不会开始就进行系统拆分、这样会开发出一些大而全的系统、系统中的一个模块或者功能出问题、整个系统就不可用了、
先部署多个实例,通过负载均衡转发 -> 无法避免因某个模块bug比如OOM导致整个系统不可用的风险、
较好的方案是、将系统拆分子系统、实现物理隔离

进程隔离使得某一个子系统的故障不会影响全局 

集群隔离

随着系统的发展、单实例服务无法满足需求、此时需要服务化技术、通过部署多个服务形成服务集群
来提升系统容量、随调用方的增多、当秒杀服务被刷会影响到其它服务的稳定性时、应该考虑为秒杀系统提供单独的服务集群、即为分组服务、这样当某一个分组出问题时、不会营销到其它分组、从而实现了故障隔离

机房隔离

随着对机房可用性的要求、会进行多机房部署、每个机房的服务都会有自己的服务分组、本机房的服务应该只调用本机房服务、不跨机房调用、其中一个机房服务发生任何问题时、可以通过DNS/负载均衡将请求全部切到另一个机房、或者考虑服务能自动重试其它机房的服务、从而提高系统可用性

读写隔离

通过主从模式将读和写集群分开、读服务只从Redis集群获取数据、当主Redis集群出现问题时、从Redis集群还是可用的、从而不影响用户访问、而从Redis服务发生问题时、可用尝试从其他集群的重试

动静隔离

当用户访问如结算页时、若 js/css 等静态资源也在结算系统中、可能会因为访问量太大而导致带宽被打满、出现服务不可用

可以将静态资源和动态资源分离、一般应该将静态资源放在CDN上、

爬虫隔离

曾有统计显示爬虫和正常的流量相比可以达到5：1、甚至更高、而一些系统是因为爬虫访问量太大、导致服务不可用、一种解决办法是限流、另外一种解决办法是将爬虫流量引导到单独集群、保证正常流量不受影响、爬虫流量尽量可用

公司是固定的ip、可用考虑ip+cookie的方式、在用户浏览器访问服务前加入cookie、访问服务时验证该cookie、如果没有或者不正确、就可以考虑分流到固定分组

热点隔离

可以将秒杀或者抢购这类的热点服务做成独立的系统进行部署或者进行服务隔离、从而保证秒杀系统出现问题时不影响主流程

对于读热点、可以使用多级缓存来搞定、对于写热点、可以使用缓存+队列模式削峰来搞定

资源隔离

最常见的、磁盘、CPU、网络等都会存在竞争问题、
eg. 在构建需求响应式亿级商品详情页中、使用JIMDB数据同步时要dump数据、SSD盘容量使用了50%以上、dump到同一块磁盘时遇到了容量不足的问题、通过专门挂载一个SAS盘来专门解决同步问题、还有使用Docker容器时、有的容器写十分频繁、要考虑为不同的容器挂载不同的磁盘

默认CPU的调度策略在一些追求极致性能的场景下可能并不适合、我们希望通过绑定到指定进程上来提升性能、当一台机器启动很多个redis实例的时候、将CPU通过taskset绑定到特定的redis示例上可以提升一些性能、
nginx还提供了worker_process 和 worker_cpu_affinity 来提升处理中断的能力、从而提高整体性能