3.Ingress实践 3.1.什么是Ingress? 在ingress之前,我们想要访问k8s集群中的pod服务时,是通过部署一个service,将service的type设置为NodePort或者将设置为LoadBalance,这样可以在物理机上开辟出一个物理端口给到对应的service,service再通过dns解析出具体要路由的Pod服务,从而对Pod服务进行服务转发访问. 但是在生产环境,一般是会有几百上千个pod服务,意味着需要有几百上千个service对象,那么多service对象

在使用codis时候,我们遇到的场景是,公司提供了HA的Proxy(例如N个),但是不暴露zookeeper(也就是说没有codis后端服务列表). 如果暴露zk的话,可以看这一篇,http://www.cnblogs.com/kangoroo/p/7485760.html 要求在开发客户端api的过程中,自己进行探活&故障摘除&负载均衡. 我这里做了一个简单的实现,提供给大家参考.本实例支持使用在server或者daemon中. 我们的实现叫做pycodis. 1.核心文件CodisPo

本文基于 Golang 开发了一款简单易用的拨测云函数,入口函数与腾讯云 Serverless SDK 绑定.与目前腾讯云中默认的拨测函数不同的是, url-tester-func 支持非 200 响应码作为预期值且通知机制由邮件变更为了 Telegram Bot .使用者借助腾讯云提供的免费 Serverless 调用配额即可搭建一套简单的 HTTP 接口探活服务. 项目地址 MrEasonYang/url-tester-func 使用 首先需要根据腾讯云文档创建 Serverless 函数的

2015年开始的百播大战,熊猫TV是其中比较特别的一员. 说熊猫TV是含着金钥匙出生的公子哥不为过.还未上线,就频频曝光,科技号,微博稿,站上风口浪尖.内测期间更是有不少淘宝店高价倒卖邀请码,光内测时用户注册数量就达几十万,火爆程度可见一斑.笔者作为写下熊猫TV第二行代码的Coder,见证了熊猫TV成立以来的风风雨雨.直播技术坑不少,本文简单揭秘熊猫TV这一年的技术架构演进,分析各个阶段面临的主要问题和应对方案,给大家做直播系统提供一定的参考. 熊猫架构 0.1- 来不及了,老司机快上车 这个阶

一.问题起源 淘宝搜索的博客 http://www.searchtb.com/2011/01/zookeeper-research.html  提到Paxos是zookeeper的灵魂 有一篇文章标题更是以“Zookeeper全解析——Paxos作为灵魂” 作为标题,认为是zookeeper的基础: “ Google的Chubby,Apache的Zookeeper都是基于它的理论来实现的,Paxos还被认为是到目前为止唯一的分布式一致性算法,其它的算法都是Paxos的改进或简化.有个问题要提一下

高可用   高可用(High Availabiltity) 应用提供持续不间断(可用)的服务的能力 系统高可用性的评价通常用可用率表示   造成不可用的原因 硬件故障(各种) 预期中的系统软硬件维护 软件缺陷(应用代码,服务程序都可能存在bug) 攻击,泄露,认为失误...等安全事件 对于系统来说,不可用时间是各关键组件不可用时间的总和.....   提高可用性的主要手段 冗余,Redundancy 关键软硬件通过备用冗余避免故障时长时间的不可用 数据软件,硬件,存储的数据,都需要通过冗余确保故

Codis31搭建 codis 3.1 安装搭建 一.基本信息 1. 服务器基本信息 ip地址 安装服务 172.16.200.71 zk1.codis-dashboard.codis-fe.codis-ha. codis-proxy1.codis_group1_M(6379).codis_group3_S(6380) 172.16.200.72 zk2.codis-proxy2.codis_group2_M(6379).codis_group1_S(6380) 172.16.200.73 zk

引子 前段时间我们的服务由于一台交换机网络出现故障,导致数据库连接不上,但是在数据库的连接超时参数设置不合理,connect timeout设置的过长,导致接口耗时增加.DB连接超时后线程未正常结束,上游请求又持续进来,最终耗光了Java线程,JVM进入持续GC状态,无法恢复,直到手工重启才恢复服务. 于是在服务的保护方面新增了两个措施,第一,调小服务端workThread的最大线程数.第二,在Server端设置Accept后Socket的readTimeout时间,当Socket调用read方

1.安装RabbitMQ 1)下载和安装erlang 下载erlang wget http://www.rabbitmq.com/releases/erlang/erlang-18.1-1.el6.x86_64.rpm 安装erlang,root用户使用rpm安装 rpm -ihv erlang-.el6.x86_64.rpm 2)下载和安装RabbitMQ 下载RabbitMQ wget https://github.com/rabbitmq/rabbitmq-server/releases/

在这一篇中我们实现了不通过zk来编写codis集群proxys的api,http://www.cnblogs.com/kangoroo/p/7481567.html 如果codis集群暴露zk给你的话,那么就方便了,探活和故障摘除与恢复codis集群都给你搞定了,你只需要监听zookeeper中实例的状态就好了. 下面看我的实现. 1.CodisByZKPool.py 这里通过zk读取并初始化pool_shards,简单说一下如何故障摘除和恢复 1)我们监听zk中节点状态改变,当发现某个实例对应

当你跑通了前面一个demo,博客地址:http://www.cnblogs.com/kangoroo/p/7299920.html,那么你的分布式异步之旅已经起步了. 性能和稳定性是web服务的核心评价指标.下面我们来说,怎么样部署服务,实现web服务的高并发和高可用. 我们将通过一些工具和部署,提升web服务的性能. 这篇文章我们先讲高并发 部署方式:nginx+gunicorn+wsgi 1.django和python的缺陷分析 django作为一个python实现的web服务器,它的性能其

本文来自我的github pages博客http://galengao.github.io/ 即www.gaohuirong.cn [参考:]http://blog.csdn.net/zhu_tianwei/article/details/44928779 Redis3.0 最大的特点就是有了cluster的能力,使用redis-trib.rb工具可以轻松构建Redis Cluster.Redis Cluster采用无中心结构,每个节点保存数据和整个集群状态,每个节点都和其他所有节点连接.节点之

redis 集群方案主要有两类,一是使用类 codis 的架构,按组划分,实例之间互相独立: 另一套是基于官方的 redis cluster 的方案:下面分别聊聊这两种方案: 类 codis 架构 这套架构的特点: 分片算法:基于 slot hash桶: 分片实例之间相互独立,每组 一个master 实例和多个slave: 路由信息存放到第三方存储组件,如 zookeeper 或etcd 旁路组件探活 使用这套方案的公司: 阿里云: ApsaraCache, RedisLabs.京东.百度等 c

本文由  网易云发布. 数字化转型浪潮之下,采用云计算服务提升业务敏捷性.降低运维成本,成为了传统企业的优选方案.网易云资深解决方案架构师张亮通过某物流企业客户的实际案例,分享了传统业务系统在云上的架构设计如何满足数据高可靠.业务高可用的需求,并总结了传统业务上云的常见问题和解决方案. 物流企业业务系统上云需求 对于物流企业来说,内部沟通.供应链协同对优化供应链效率提升核心竞争力非常重要.作为行业翘楚,该物流企业客户建立了一个企业级移动办公平台,该平台集成了即时通讯(IM).企业内部的ERP.O

影响HTTP性能的常见因素 我们这里讨论HTTP性能是建立在一个最简单模型之上就是单台服务器的HTTP性能,当然对于大规模负载均衡集群也适用毕竟这种集群也是由多个HTTTP服务器的个体所组成.另外我们也排除客户端或者服务器本身负载过高或者HTTP协议实现的软件使用不同的IO模型,另外我们也忽略DNS解析过程和web应用程序开发本身的缺陷. 从TCP/IP模型来看,HTTP下层就是TCP层,所以HTTP的性能很大程度上取决于TCP性能,当然如果是HTTPS的就还要加上TLS/SSL层,不过可以肯定

背景 关于Redis的高可用除了只身的Sentinel和Cluster之外,还有一个用的比较多的是Codis,由于公司的Redis大部分都使用Codis,本文就针对Codis进行相关的安装部署进行说明,来好好的认识Codis. 介绍 Codis 是一个分布式 Redis 解决方案, 对于上层的应用来说, 连接到 Codis Proxy 和连接原生的 Redis Server 没有显著区别 (不支持的命令列表), 上层应用可以像使用单机的 Redis 一样使用, Codis 底层会处理请求的转发,

1. 写作缘起 几年前,我在一家农业物联网公司,负责解决其物联网产品线.我们当时基于.net平台打造了一套实时数据采集系统,可以把数以百万级的传感器传送回来的数据采集入库并根据这些数据进行建模.在搭建这套实时数据采集系统的时候,高并发高可用被首次提出,同时要求系统不会有太大的时延.一旦有时延,也就意味着损失.比如一个有3000头猪的猪舍,假设空气温度达到了比较高的水平,但是采集探头采集的数据上传到服务器管道中,由于被积压了5分钟后才被处理,那么主动预警系统打开风机的时候,也许已经晚了,这五分钟的

一. 线上出现了监控指标抖动,netscaler心跳监测的问题,如下图: 二.工具如下: 原理参考:https://www.dearcodes.com/index.php/archives/17/ Nurse是基于以上原理实现的一个端口探活工具,可以周期性的监控目标端口,在目标端口失活或者存活时候发送消息告知,相关代码请参见: https://github.com/itcomputer12/nurse

本案例转载自李大玉老师分享 Ⅰ.问题背景 探活脚本连续8次探测,判断主库异常,触发切换(判断备机是否有延迟,kill原主,VIP飘到备机,设置新主可写) 切换后,业务还是异常,SQL查询没返回,DB连接数耗完,为了恢复业务,重启新主后业务恢复 两个问题 主库为什么会切换 切换后新主库为什么还是不可用 Ⅱ.问题排查 1.根据系统运行时间.系统日志以及服务器带外日志可排除服务器和数据库OOM 2.从每分钟的线程快照中发现故障时大量线程处于sending data和statistics状态,但前一分钟

SpringBoot Actuator 提供了检查项目内部信息的一整套API,通常在项目启动时可以看到. 1.引入依赖包 <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency> 2.配置application.yml management: a

故障背景:程序日志发现有程序请求数据库有大量的timeout请求故障时间:xxx~xxx 故障排查:排查应用服务器和数据库服务器网络和其它硬件监控没有断点,数据库监控请求数当时时间段几乎为0 故障分析:目前分析可能是由于程序侧没有做探活机制导致的,数据库这边设置的超时时间为3600s,当时连接一直没有请求,所以触发了数据库的超时时间并kill掉进程,所以当应用请求数据库时没有设置探活,不清楚数据库进程目前的状态,导致请求超时规避方法:代码层做一个探活机制来保证进程的可用性