倾听一线架构师的声音1专题讲座.ppt

* * 总结 [4] * 1.自动化运维 自动部署 灰度发布 2.支持降级，保证主功能运行，附加功能可动态开关 3.定期故障演练 百度流量收集与跨机房的流量回放 京东定期限流测试（流量限制命中在一个节点上） VIP，定期镜像环境停服，观察问题 4.弱依赖，不做过早过量的设计 5.做好当前事情，不谈高大上架构，渐进式演进 6.天下武功，唯快不破 广纳贤才,加入架构 * Thanks! * 倾听一线架构师的声音 * 云架构与大数据 2. 高性能高可用架构设计 3. 高效电商系统构建 4. 总结 * 云架构与大数据 [1] day * 公有云 阿里云、腾讯云、七牛、又拍云 私有云 Euclyptus(EC2开源) 特点: 低成本 可扩展 安全性 灵活性 * Saas(软件即服务) 故名思义:通过买软件就有某项服务,比如你需要CRM、ERP、OA 某银行对连阿里云，提供商城、支付等服务 Paas(平台即服务) Google的App?Engine 微软的Azure Iaas(基础设施即服务) VPS(虚拟vm) 从层级上看，Saas基于Paas，Paas基于Laas，随着服务演进，三个概念已经越来越模糊 云平台分类 * Nice:图片社交创业公司APP，服务端部署在七牛云，是第一个从七牛迁出的用户，迁出原因:七牛提供最好的服务器内存32G，而Nice的MYSQL数据库索引都已经32G了， 无法满足业务增长，而七牛的CEO希望Nice把程序改成水平可扩展的，对Nice来说硬件能解决问题，远比修改程序满足当前业务来的代价小。 如图片、静态资源文 件我们可考虑放在云上 这么强大，我们需要吗? * OLTP(联机事务处理系统) 关系型数据库，记录数据库的CRUD操作，传统的关系型数据的大数据一般是通过分片的方式 Taobao-tddl、Hibernate-shard、Ibatis-sharding、Cobar-client、Shalo-dal Mysql Proxy、Atlas、Amoeba、Cobar、Mycat、MyFox 大数据 * OLAP(联机分析处理系统) 基于Hadoop开发的产品: EMC Greenplum Pivotal GPDB(之前来公司推荐的产品) Teradata(功能性能最好就是太贵$100w/节点，全球市值第一工行买70个节点后，都买不起了) Palo(￥5w/节点，百度计划-2015年将开源) 选择一个我们可以Hold住的产品 或半成品，比什么都重要 (hadoop+mysql+stom/spark) * 高性能高可用架构 设计 [2] day * 陌陌(高可用架构) 同时在线连接数1200w+ 单台服务器正式环境压测100万长连接 每天收发消息量70亿 * 协议 OpenFire(java) Tigase(java) Prosody(lua) Ejabberd(erlang/otp,support sip) Mosquitto(python) Pomelo(node.js) XMPP(基于XML协议的通讯协议) MQTT(基于代理的“发布/订阅”模式的消息传输协议) SIP(会话发起协议，基本上应用视频语音，VOIP) TCP(nio) 产品及框架 * 业务更新不断线 停服就意味的损失，怎么可以不停服更新业务 业务分流: 只有消息为长链接，其他业务走http 弱网络和丢消息问题(只保证单设备收到消息) 优化通信协议（见下一页） 问题及优化 * 连接与逻辑之间弱依赖 HASH取模命中，分担压力 优化消息传输机制 * 优化消息传输机制 修改成 引入版本号，让单条信息回馈，变成批量接收回馈，提升消息传输机制 * 减小故障影响面 1. 业务线程隔离互不影响，任何服务挂掉不 影响聊天 2. 对其他系统的服务都尽量设计成弱依赖(ESB) 3. 支持降级，各个业务的动态开关 4. 定期的故障演练，检验系统优化方案，加快故障修复时间 * 高效电商系统构建 [3] day * 限流分流 过早过度的优化（over-engineer） 预先将Redis扩展到几十个分片，在网络出阻塞的情况下，程序中的连接池一直在超时重建连接，影响整个使用redis集群应用一直连接重建的死循环。 基于IP、用户等有限维度分流 基于业务的分流限流降级 基于业务逻辑的限流--预售秒杀系统(黑名单用户转到性能差的节点去排队) 基于用户行为统计分析—用户信用体系 这个问题让我想起几年的高铁脱轨事件, 中国在高铁时代一上来就时速300公里， 缺少高速的运营经验 自动删单程序功能（自动清理1周前