Archive for November, 2015

作者:AngryFox 分类: Uncategorized November 16th, 2015 暂无评论

介绍
iOS9引入了新特性App Transport Security (ATS)。
新特性要求App内访问的网络必须使用HTTPS协议。
但是现在很多项目使用的是HTTP协议,现在也不能马上改成HTTPS协议传输。
那么如何设置才能在iOS9中使用Http请求呢

解决办法:
在Info.plist中add Row添加NSAppTransportSecurity类型Dictionary。
在NSAppTransportSecurity下添加NSAllowsArbitraryLoads类型Boolean,值设为YES

作者:AngryFox 分类: Uncategorized November 11th, 2015 暂无评论

1. 爬虫系统;2. 离线信息处理系统;3. 索引系统;4. 搜索服务系;5.反馈和排序系统。
新增一个促销类型可能牵动从单品展示、搜索、推荐、购物车、交易、订单、退换货、库存、价格、促销自身等一系列产品线的变更。因此,促销系统的重构势在必行,数据模型与运营的贴合度决定的扩展性、灵活性,系统解耦和更强大的数据处理能力,是核心改进点。
系统模块有效切分
服务化解耦,集中服务治理
增加异步访问
多阶段缓存,降低后端压力
优化数据库访问
加强系统监控
“三大战役”,即换底计划、多中心交易计划、京东大脑计划。
研发端根据移动端网络特点进行接入网络优化、持续精简内容、加载策略优化等,通过移动组件化建设、无线登录、push触达、开放化平台能力建设、无线监控测试平台、远程插件下发等数十项优化保障双11的进行。
各个团队的线上系统都有成熟的路由降级切换开关。

PyPy 4.0 支持SIMD矢量、预热时间的改进、以及对Numpy的改进。
强依赖-> Service化->业务解耦->读写分离->异步->水平/垂直拆分->服务逻辑分组等。
下单接口业务性强 如何定义日志系统,让以后的监控和问题定位更简单更快捷。事实证明这个决定是对的,直到现在1号店的大部分订单相关的监控、预警、问题排查定位等完全依赖这个日志。一是进数据库、持久化有序化,二是分类化、层次化、错误code唯一
1号店采用的什么RPC框架,是Hessian
如何把控系统的质量?对应的检查单和组织会议对其检查。
屏蔽非关键业务的入口、关闭影响性能非关键业务功能、页面静态化、开启验证码策略延缓系统压力、延长缓存的时间牺牲实时性、放弃后端的补偿机制以减少调用链时间等。在多大压力的情况下开启什么的降级策略,需要再定义和演练。在实践过程中,我们定义了不同级别的降级策略、每个级别对应不同的流量压力。

作者:AngryFox 分类: Uncategorized November 10th, 2015 暂无评论

QQ空间团队采用的解决方案是基于Android Dex分包策略,把有问题的类打包到一个dex,然后把该dex插入到Elements的最前面。
如果CDN调度模型不当,会导致这些设备上的流量抖动非常厉害,对云平台也是非常不利的

可扩展性
性能可扩展:性能无法完全实现线性扩展,但要尽量使用具有并发性和异步性的组件。具备完成通知功能的工作队列要优于同步连接到数据库。
可用性可扩展:CAP理论表明,分布式系统无法同时提供一致性、可用性和分区容错性保证。许多大规模Web应用程序都为了可用性和分区容错性而牺牲了强一致性,而后者则有赖于最终一致性来保证。
维护可扩展:软件和服务器都需要维护。在使用平台&工具监控和更新应用程序时,要尽可能地自动化。
成本可扩展:总拥有成本包括开发、维护和运营支出。在设计一个系统时,要在重用现有组件和完全新开发组件之间进行权衡。现有组件很少能完全满足需求,但修改现有组件的成本还是可能低于开发一个完全不同的方案。另外,使用符合行业标准的技术使组织更容易聘到专家,而发布独有的开源方案则可能帮助组织从社区中挖掘人才。

避免单点故障:任何东西都要有两个。这增加了成本和复杂度,但却能在可用性和负载性能上获益。而且,这有助于设计者采用一种分布式优先的思维。
横向扩展,而不是纵向扩展:升级服务器(纵向)的成本是指数增长的,而增加另一台商用服务器(横向)的成本是线性增长的。
尽量减少应用程序核心所需要完成的工作。
API优先:将应用程序视为一个提供API的服务,而且,不假定服务的客户端类型(手机应用、Web站点、桌面应用程序)。
总是缓存。
提供尽可能新的数据:用户可能不需要立即看到最新的数据,最终一致性可以带来更高的可用性。
设计时要考虑维护和自动化:不要低估应用程序维护所需要的时间和工作量。软件首次公开发布是一个值得称赞的里程碑,但也标志着真正的工作要开始了。
宁异步,不同步。
努力实现无状态:状态信息要保存在尽可能少的地方,而且要保存在专门设计的组件中。
为故障做好准备:将故障对终端用户的影响最小化。

作者:AngryFox 分类: Uncategorized November 9th, 2015 暂无评论

多个pool解决安全性
● node可以是物理机或者虚拟机
● zk⽤以监控node和container(可以多个pool共享⼀套zk,也可以⽤etcd)
● scheduler 调度器,负载container的创建调度
● manager,对master提供管控的http rest接⼝
● registry-proxy 保证⺴络联通性以及cache镜像数据,加速镜像下载
● 在node内起cadvisor监控container

粗糙集理论建立在用等价关系(满足自反,对称,传
递三个性质的关系,比如a和a本身是等价的,即自反,
a和b等价,推出b和a等价,即对称, a和b等价, b和c
等价,推出a和c等价,即传递)对全域(即所有元素
的集合)进行划分(等价的分为一个集合,所有元素
被分为多个集合)的基础上,可以定义一个集合的上
近似和下近似,除数据集外不需要任何先验知识

读写数据的分层校验设计
链路优化
无线端请求合并
域名的收敛
DNS本地cache
SPDY长连
图片本地cache
合理的预加载机制
(知道短板 减少数据大小 数据分级 减少翻译、增加预处理)

方案验证
• 新技术探索
• 压力测试
• 鲁棒性测试
• “小白鼠”平台
• 配额内自助使用
极高的交付效率
极高的资源利用率
月 资源“换手”率 > 50%

集群内负载均衡
– IP Hash
– Round-Robin + 外部全局cache

Master
– 外部watchdog
– 检测Master进程是否存活
– 检测Master的端口是否存活
 Worker
– Master监听woker事件
– 内部watchdog
– 向指定worker建立连接,模拟请求测试是否存活
– 注意有坑:遇到大量建立连接时,可能checkAlive的建连超时,误判为
worker已死
从用户行为发生到线上感知的全链路反馈

作者:AngryFox 分类: Uncategorized November 5th, 2015 暂无评论

运维 工具化 产品化 运营化
不断逼近业务核心价值,并持续运营
直播服务器
SRS

1 架构简洁,功能强大
2 主要支持rtmp协议
3 基于state thread library
4 集群支持
CRTMP
1 C++开发
2 协议支持丰富, rtmp, rtsp 等都支持
3 对集群支持不够好,拉模式需要在配置
文件中设置流ID
nginx-rtmp
1 全异步模型实现,性能优越
2 稳定性需要进一步提升
red5
1 比较有名的开源直播服务,使用java 语言开发
2 性能存在问题
FMS 不开源
1 Adobe 的流媒体服务器
2 功能和性能都不错
3 license 费用昂贵

im云关键技术挑战和技术要点
基于云计算的社交大数据分析工具;
支持过亿数据分析,趋势挖掘;
完美的水平扩展性能;
实时数据分析快速准确;
多租户系统;
全自动的决策支持系统;
提供多种可定制的机器学习算法,方便用户建立模型进行预测预警

移动IM的极致追求
1. 无DNS设计
2. 小包体协议
3. 后台轮询测速
4. 精简认证重连
5. 多媒体消息通道复用
6. 长短连接并用

不丢消息99.99%的稳定性
1. 多段ACK确认
2. 永久化存储
3. 排序队列控制
4. 故障自动迁移
5. 负载均衡、无单点故障

登录快
发送消息快快
1. 低流量协议
2. 压缩机制
3. 高频词编码
4. 智能多包合并
5. 自适应、最小心跳
包技术

高效的编解码协议( protocol buffer等)加自定义上层协议
Redis + Cassandra
Redis 解决版本号的线性自增、数据二级缓存
Cassandra 解决 IM消息存储的线性扩展
方案:
全局关系型数据采用数据分区,任何一个数据只在一个中心更新。
redis 必要数据采用异步双写
服务降级的触发是以后端的门限指标为依据

数据服务化
本地缓存机制
请求过滤机制
全异步处理机制:通过总线和人物状态机架构,异步所有能够并行的请求
负载均衡
Nginx based
心跳检测
round robin
服务调度
容灾调度
过载汇报
异常汇报
风险隔离