同城异地灾备，主要是用来进行备份容灾的，从而当一个数据中心挂了，另外一个数据中心经过切换之后，能让服务迅速的恢复。
随着医疗、大型企业行业上云步伐的加快，上云后的业务系统安全性如何保障成为客户关注的重点。对于医疗、大型企业客户，往往建有自己的数据中心，如何保障极端情况下业务系统的稳定运行？双活、灾备，能帮到我们！
内容来源：2017 年 12 月 21 日，驻云科技资深架构师翟永东在“云时代企业架构的搭建”进行《云上架构如何实现高性能和高可用》演讲分享。IT 大咖说（微信id：itdakashuo）作为独家视频合作方，经主办方和讲者审阅授权发布。 阅读字数：2851 | 8分钟阅读 摘要 云上架构需要关注多方面的因素，本次主要讲的是高可用和高性能，从这两方面展开深度的解析如何搭建完善的云上架构。 嘉宾演讲视频及PPT回顾：http://suo.im/4sKQd8 云上架构概述 云上搭建架构不单单需要考虑到性能和可用性
看文章可以知道这次故障，主要是因为SLB层面故障引起的，最终是通过多活进行服务的恢复。
GTM（Global Traffic Manager的简写）即全局流量管理，基于网宿智能DNS、分布式监控体系，实现实时故障切换及全球负载均衡，保障应用服务的持续高可用性。GTM基于资源的健康状况及流量负载做智能调度决策，为用户提供最佳访问IP。网宿GTM，提供更可靠、稳定和安全的流量调度服务，助您轻松构建混合云应用。
1.1 用户消费的数据远大于生产的数据（热卖商品、热点新闻、热点评论、明星直播）。
客户为金融企业对SLA要求及数据安全性很高，有限于考虑到业务的高可用性，采用混合云部署，业务流量入口为阿里金融云，前端可以添加安全设备WAF/CDN/高防IP等，之后Cname到统一入口SLB负载均衡上，后端采用虚拟服务器组，组内ECS部署在同Region的不同Zone，保障跨Zone的靠可用性，考虑到数据的安全性将数据持续化在IDC侧，阿里云与IDC通过云上部署深信服设备与IDC侧Cisco设备通过Ipsec ×××互联（考虑到稳定性目前已经实施专线互通），后端APP-Server与DB-Server部署在IDC，可参考下图：
集群模式：一般指的是通过负载均衡的组件将两台或两台以上搭建成一个集群方式，通过轮训或权重方式进行分配到具体的机器;
Nacos集群的搭建时要注意：1.xx 版本和 2.xx 版本有区别。从2.0开始Nacos使用了 gRPC ，需要开放额外的端口。我就遇到了 各个 Nacos 节点无法互相复制，注册的服务不一致的情况。
HAProxy反代了K8S Master服务器，提供了K8S Master API的高可用和负载均衡能力。
LVS 、HAProxy 被规划为基础层，主要提供了一个高可用的7层负载均衡器。 由LVS keepalived 提供一个高可用的VIP（虚拟IP）。 这个VIP DR模式转发到后端的HAProxy服务器。 HAProxy反代了K8S Master服务器，提供了K8S Master API的高可用和负载均衡能力。
上面的架构图并没有具体说明SLB是什么，实际上上面的架构图翻译成下面这种看起来是不是很熟悉。
自从09年阿里开启了双十一活动，近几年各大电商平台的促销活动如火如荼。电商大促期间剧增的流量，对电商平台相关的软件系统也带来了更严峻的挑战。
当发现目标站点存在CDN防护的时候，我们会尝试通过查找站点的真实IP，从而绕过CDN防护。
上一篇《分布式系统关注点——初识「高可用」》我们对「高可用」有了一个初步认识，其中认为「负载均衡」是「高可用」的核心工作。那么，本篇将通过图文并茂的方式，来描述出每一种负载均衡策略的完整样貌。
我们都对高可用有一个基本的认识，其中负载均衡是高可用的核心工作。本文将通过如下几个方面，让你妥妥的吃透“”负载均衡”。
title: "2020-07-22-腾讯云-slb-kubeadm高可用集群搭建"
本文根据吉翔老师在〖deeplus直播：甩掉技术债包袱，B站的SRE体系建设与转型实践〗线上分享演讲内容整理而成。
Nacos单击模式仅仅适用于测试和单击使用，生产环境大多使用集群模式以确保高可用。如果有多数据中心场景，那么Nacos还支持多集群模式。 nacos集群架构图如下：
1、用户消费的数据远大于生产的数据（热卖商品、热点新闻、热点评论、明星直播）。 在日常工作生活中一些突发的的事件，例如：双十一期间某些热门商品的降价促销，当这其中的某一件商品被数万次点击浏览或者购买时，会形成一个较大的需求量，这种情况下就会造成热点问题。
在日常工作生活中一些突发的的事件，例如：双十一期间某些热门商品的降价促销，当这其中的某一件商品被数万次点击浏览或者购买时，会形成一个较大的需求量，这种情况下就会造成热点问题。
当时环境：两台主机，系统RHEL 6.5，分别部署OMS和OMR： OMS，也就是OEMCC的服务端 IP：192.168.1.88 内存：12G+ 硬盘：100G+ OMR，也就是OEM底层的资料库 IP：192.168.1.89 内存：8G+ 硬盘：100G+
共享后端存储是一种比较标准的方案，将多个Harbor实例共享同一个后端存储，任何一个实例持久化到存储的镜像，都可被其他实例中读取。通过前置LB组件，如Keepalived，可以分流到不同的实例中去处理，从而实现负载均衡，也避免了单点故障，其架构图如下：
来源 | 经授权转载自 哔哩哔哩技术 公众号 至暗时刻 2021 年 7 月 13 日 22:52，SRE 收到大量服务和域名的接入层不可用报警，客服侧开始收到大量用户反馈 B 站无法使用，同时内部同学也反馈 B 站无法打开，甚至 APP 首页也无法打开。基于报警内容，SRE 第一时间怀疑机房、网络、四层 LB、七层 SLB 等基础设施出现问题，紧急发起语音会议，拉各团队相关人员开始紧急处理（为了方便理解，下述事故处理过程做了部分简化）。 初因定位 22:55 远程在家的相关同学登陆 VPN 后，
鱼羊 丰色 发自 凹非寺 量子位 | 公众号 QbitAI 一个小小字符“0”，竟引得B站全面崩溃。 不知你是否还记得那一夜，B站“大楼停电”、“服务器爆炸”、“程序员删库跑路”的彻夜狂欢。（手动狗头） 时隔一年，背后“真凶”现在终于被阿B披露出来—— 没想到吧，就是这么简单几行代码，直接干趴B站两三个小时，搞得B站程序员彻夜无眠头发狂掉。 你可能会问，这不就是个普普通通用来求最大公约数的函数吗，怎么就有如此大的威力？ 背后一桩桩一件件，归根结底其实就一句话：0，它真的不兴除啊。 具体详情，咱们还是一
LVS在基本的生产环境中,都会同时运行在二台硬件相近的服务器上：LVS Router（主 LVS ），一个作为备份LVS（备份 LVS ）。 主 LVS 服务器在网站的前端起二个作用：
在日常工作生活中一些突发的的事件，例如：双十一期间某些热门商品的降价促销，当这其中的某一件商品被数万次点击浏览或者购买时，会形成一个较大的需求量，这种情况下就会造成热点问题。同理，被大量刊发、浏览的热点新闻、热点评论、明星直播等，这些典型的读多写少的场景也会产生热点问题。
LB,SLB,ALB，GSLB,CDN，傻傻分不清楚，听风看雨。。。毒鸡汤看多了，我快掩饰不住我的悲伤了。。。
近日来，和很多来自传统行业、国企、政府的客户在沟通技术细节时，发现云原生所代表的技术已经逐渐成为大家的共识，从一个虚无缥缈的概念渐渐变成这些客户的下一个技术战略。自然，应用架构就会提到微服务，以及其中最重要的分布式协作的模式——服务发现。模式（pattern）是指在特定上下文中的解决方案，很适合描述服务发现这个过程。不过相对于 2016 年，现在我们最少有十多种的方式能实现服务发现，这的确是个好时机来进行回顾和展望，最终帮助我们进行技术选型与确定演进方向。
昨晚10：30左右，B站的部分服务器机房发生故障造成无法访问。个人猜测11点多左右应该系统应该已经恢复了，但是因为视频行业强依赖CDN 云厂商 DNS 运营商 用户本身等原因拖到12点左右恢复80-90%吧，整体业务大概2点多，以上时间均为用户感知和猜测。自己本着做过全球化 多数据中心 多节点的视频业务出发，想讲讲明天这个国民APP反应速度及技术处理的难点。
本文只介绍选型分析、部署架构图、部署架构设计说明、部署节点规划、上云总成本分析等内容，具体的安装部署暂不涉及。
疫情初期某地政府决定发放一批免费口罩面向该市市民，该市市民均可免费预约领取，预约时间为早上9点-12点，因此该场景为限时抢购类型场景，会面临非常大的定时超大流量超大并发问题，在该项目的落地过程中，涉及的架构演变，做了一些记录和思考。
自建 Redis 系统是得物 DBA 团队自研高性能分布式 KV 缓存系统，目前管理的 ECS 内存总容量超过数十TB，数百多个 Redis 缓存集群实例，数万多个 Redis 数据节点，其中内存规格超过 1T 的大容量集群多个。
请看我之前写的 Prometheus简介,原理和安装 https://www.cnblogs.com/you-men/p/12839535.html
纵观运维的各项技能，了解各种各样的中间件，tomcat，redis，mongo，nginx等等等，但是又有什么意思？
灾备，又称灾难恢复(disaster recovery)。指的是， 发生灾难时恢复业务的能力。这就意味着已经发生了灾难，进行补救。它的流程是，前期准备，发现灾难，应对灾难。 大多数系统的自动灾备依赖外部系统实现，一些关键模块则使用分布式共识算法实现内部灾备。
Nacos 支持两种部署模式：单机模式和集群模式。在实践中，我们往往习惯用单机模式快速构建一个 Nacos 开发/测试环境，而在生产中，出于高可用的考虑，一定需要使用 Nacos 集群部署模式。我的上一篇文章《一文详解 Nacos 高可用特性》提到了 Nacos 为高可用做了非常多的特性支持，而这些高可用特性大多数都依赖于集群部署模式。这篇模式文章便是给大家介绍一下，在实践中可以被采用的几种集群部署模式，无论你是希望自行搭建 Nacos，还是希望对 MSE 商业版 Nacos 有一个更加深刻的理解，我都很乐意跟你分享下面的内容。
一个网站要保持高可用，绝对要避免单点故障，即只有一台服务器提供web服务，当这台服务器宕机时，流量进不来，意味着白花花的钱就丢了。
最近有个集团级的云项目处于实施过程中，客户对数据备份、应用双活视为同一个事物，要求我方将原秒级数据备份升级为秒级应用双活。实际问题，备份与双活是不同的两个概念。以下我们用图文方式简述双活与数据备份的区别。
反向代理，是把一些静态资源存储在服务器上，当用户有请求的时候，就直接返回反向代理服务器上的资源给用户，而如果反向代理服务器上没有的资源，就转发给后面的负载均衡服务器，负载均衡服务器再将请求分发给后端的web服务器。 区别就是：反向代理服务器是需要存储资源的，让用户更快速的接收到资源 负载均衡就是，为了保证后端web服务器的高可用，高并发，是不需要要存储资源，只需要转发用户的请求。 一、SLB产生背景: SLB(服务器负载均衡)：在多个提供相同服务的服务器的情况下，负载均衡设备存在虚拟服
随着苏宁线下线上业务以及全产业、全业态规模式快速增长，特别是每年苏宁 818 大促、双 11 等大促节点，销售订单基本都呈现倍数级增长态势，需要进行大量资源扩容，单个数据中心的容量有限，已经无法支撑苏宁业务的快速发展。同时，单数据中心在高可用上存在不足，一旦数据中心发生故障，会导致业务受损，用户访问中断，带来严重的影响。针对以上问题，苏宁规划建设多数据中心解决方案迫在眉睫。
背景：在使用mongodb的时候，发现复制集集群的时候，大量的写入操作会造成集群的主进行切换，从而导致程序报错。
1. **服务发现**：Nacos 作为一个服务注册中心，允许服务提供者在启动时将自身服务信息注册到 Nacos Server，服务消费者则可以通过 Nacos 获取服务列表，进而找到所需的服务提供方进行调用，实现了服务间的自动发现与绑定。
KubeSphere 使用一段时间之后，由于工作负载不断增加，您可能需要水平扩展集群。自 KubeSphere v3.0.0 起，您可以使用全新的安装程序 KubeKey 将新节点添加到集群。从根本上说，该操作是基于 Kubelet 的注册机制。换言之，新节点将自动加入现有的 Kubernetes 集群。KubeSphere 支持混合环境，这意味着新添加的主机操作系统可以是 CentOS 或者 Ubuntu。若要水平扩展多节点集群，操作步骤基本相同。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
