我们专注服务于当下互联网基础设施建设与云计算、大数据时代的各种需求!

去域名化加速你的移动APP访问

目前市面上很多移动端加速产品。但是都是基于sdk这种,然后劫持请求回边缘CDN节点。做链路加速,这种产品在一定程度并不能加速你的移动app。
我们的最佳实践是抛弃dns请求,全部使用ip,然后通过高速链路、高质量的BGP节点进行数据获取。在移动端,如果你放一个http://www.sklinux.com/1.jpg的请求,那么移动端会首先请求www.sklinux.com的dns解析。

然而,在移动网络非常复杂的今天,dns劫持是非常正常的事情。再加之dns解析时间太长,体验很慢也在情理之中。
然而市面上也有这种加速解析的方案,比如httpdns。但是httpdns,虽然加快了dns的解析,但是不是真正的走的去域名化道路。
所以,我们抛弃了域名。拥抱回归了ip的直接请求方式。比如:http://ip/1.jpg 那么问题来了,多个业务域名需要单ip路由
我们需要在nginx进行上进行业务区分,然后路由回源。这样就可以了,目前这种方案可以支持http、https。网络连通性效果非常的不错
希望做移动端app的研发、运维人员可以考虑。这种方案的连通性可以提升移动端的用户体验,移动端性能提升90%左右。
效果非常好!在这里分享给大家,共勉!

 

论高可用的“妙”处

论高可用的“妙”处

在互联网行业中高可用,目前看来有三种用法。分别是:
1.业务量的增加后,由于市场的需要必须保障核心业务的稳定性。我在这里把称之为 “正常”模式。
2.业务量根本还没有,而且还是新上项目。但是由于服务的启动导致时间的延长(上分钟不能提供服务),所以要做多节点部署
要用前端的高可用,来解决这种程序不能立马提供服务的问题。这种我在这里称之为“斗比”模式。
3.平台不差钱,流量和业务都没有增加也没有接入前。就考虑了高可用。多节点这种,我在这里称之为“高富帅”模式
正常模式,我在这里不谈论。因为市场决定一切、核心服务的强需求,理所当然的。今天的我的观点主要在斗比模式的高可用。

斗比模式的高可用有几个问题。

由于服务的这种延迟启动,导致必须要借用“高可用”的“斗比”模式来进行解决了。比如下面的流程:

1.由于服务的启动时长,不能及时的提供服务。在部署的时候,需要发布成多节点。
需要在升级的时候,先要在摘掉负载均衡上第一个斗比节点。然后升级,升级启动几分钟的时间内,由于服务本身还未启动。然而tomcat(这里指某个基于tomcat的一些java业务服务)
端口已经启动,显然这个时候不能将节点放入负载均衡。那么将进入几分钟漫长的等待(这个时候千万要祈祷java线程别崩溃)后,验证日志ok后再将节点加入负载均衡。并让
节点服务能在负载均衡生效。
2.在升级第2个斗比节点的时候,如法炮制。

针对这种斗比模式,本人有如下观点:
1.这种模式是坑运维和坑老板
2.这种模式是用运维工具去弥补程序设计的严重缺陷
3.这种模式是给平台化、自动化一杯毒酒
4.这种模式是用高可用、灰度这种“正常”模式来装高逼格,用装高逼格的方法论来掩饰程序设计上的缺陷。

 

技术团队如何有效沟通?请看实例

技术团队如何有效沟通?请看实例

a:@运维b、@运维c,现在我们的qps峰值是多少?
b:请问什么项目的qps的峰值?什么对象的峰值?
a:你们有哪些对象?
b:(b开始不计成本的开始给a罗列项目)xxx项目、xx项目、xxxx项目……
a:那就看xx项目的吧(随机指定1个)
b:你要看xx项目的什么对象的峰值(a去找数据,不计成本帮a找)
a:有哪些对象?(很悠闲的姿态)
b:有xx的、有xxx的、有xxxx的等等等等(罗列对象)
a:那就看xxx的吧(随机指定1个)
b:xxx的qps峰值为xxx(开始翻数据)
a:好的,谢谢!

我们现在统计下a和b的成本

a的成本是
a:@运维b、@运维c,现在我们的qps峰值是多少?
a:你们有哪些对象?
a:那就看xx项目的吧(随机指定1个)
a:有哪些对象?(很悠闲的姿态)
a:那就看xxx的吧(随机指定1个)
a:好的,谢谢!

总共就5句话

b的成本为5个事件。包括列表、筛选、询问最后解答
b:请问什么项目的qps的峰值?什么对象的峰值?
b:(b开始不计成本的开始给a罗列项目)xxx项目、xx项目、xxxx项目……
b:你要看xx项目的什么对象的峰值(a去找数据,不计成本帮a找)
b:有xx的、有xxx的、有xxxx的等等等等(罗列对象)
b:xxx的qps峰值为xxx(开始翻数据)

如何提问?
a为什么不能第一次就讲,我需要xx项目的xx对象的qps峰值?
导致b会去不断询问a,到底需要什么?

 

安全的linux沙盒限制日志用户行为规范

限制用户登录后只能访问某个文件夹比如logs,不能看到核心配置文件

1.创建chroot环境
2.修改sshd文件
3.搬移某个文件夹到chroot文件夹
4.系统层链接回去

a.拷贝chroot所需要的文件到chroot文件夹
b.创建普通用户loguser
c.修改sshd文件

Match User loguser
ChrootDirectory /home/chroot/