分布式应用架构核心要素的设计方法探讨试卷.pptx

分布式应用架构核心要素的设计方法探讨 1 互联网应用/企业应用那些事 2 分布式为弹性应用解困 分布式平台的核心要素设计剖析 3 4 （大型）互联网应用 VS 企业应用 • 商业模式衍生出技术色彩 • 高用户量目标 • 不固定、不可控 • 快速迭代的冲击 • 活难干、没预算 • 商业模式推动技术变革 • capacity planning • enterprise-scale, carrier-scale • 不好的用户体验 • 限定的使用模式 企业应用 （大型）互联网应用 2008奥运首次订票 12306 “互联网思维”2B应用 SaaS 避免盖棺定论 问题一直都在 托翁法则 “舍得” 建设性改良 0~1 VS 1~100 颠覆 逆袭 弹性架构 • 完善、灵巧 • 单体高效 • 值得尊敬的兼容性 • 提前布局 弹性应用 资金的弹性 VS 规模的弹性 弹性的CTO 功能迭代 弹性可伸缩 VS 弹性可拥挤 弹性的开发人员 架构迭代 弹性应用的范畴 应用 前端 链路 后端 数据库 后端 负载均衡 运行容器 数据交换 数据存储 分布式平台内部实现 需求 原理 设计思想 具体实现 深入了解现有平台 评估自研、改造 1 互联网应用/企业应用那些事 2 分布式为弹性应用解困 分布式平台的核心要素设计剖析 3 4 弹性应用面临的困境 OLTP（1+1=?） 会话型应用（++i） 并行/分布式计算、大数据 困境中的答案 分布式 计算 分布式 存储 •提升计算节点个数 •同一类任务由超过一 个CPU完成 •摩尔定律“回归” 通过scale out解脱单一计算节 点上无法从硬件无限突破的两 大性能瓶颈：CPU和磁盘 •提升存储节点个数 •维持单位存储管理成本 高 可 用 高 可 靠 高 性 能 弹 性 可 伸 缩 框架 应用 决定如何“分”和“治” 平台 分布式应用 开发态 • 编程范式和API支撑 • 最少的知识投资 • 通用、底层、简单、轻量 • 杜绝“分布式”设计框架 • • • 运行态 强大的运行容器，应用透明 多线程/进程/机器透明并发 必杀技：强大的RASP 理想的分布式平台该做什么？ “最高深的技术是那些令人无法察觉的技术，这些技术不停地把他们自己 编织进日常生活，直到你无从发现为止” ——Mark Weiser 分布式平台设计的核心方法论 无银弹 有秘诀 • 功能和RASP的N • 加法变乘法 “舍得” • • • • • • • • 九六四 功能与方案的“舍得” 主动的“舍” 时间/空间上的“舍” 不同应用不同取舍 收放自如的“舍” 不光是智商的问题 “改变世界”的发明？ 1 互联网应用/企业应用那些事 2 分布式为弹性应用解困 分布式平台的核心要素设计剖析 3 4 开发态（框架）的核心要素 数据协议 可插拔、可扩展、 业务透明 持久化 便捷的 编程模型 会话 丰富的数据类型 内存管理 服务实例间通信 工具包 编程范式 RPC 对话 EDA Map-Reduce 批处理、并行计算 多语言 互操作 通讯协议 计算资源间统一 可插拔、可扩展、 业务透明 操作系统 透明 便捷的编程模型 应用服务 Callback那些事 开发工作量 出错几率 运行时灵活度 RASP 最小程度的新语义引入 配置驱动 一种框架解决多种业务 框架初始化 应用初始化 框架主循环 应用 框架 请求服务 路由 负载均衡 数据协议 通讯协议 处理响应 框架 编 程 模 型 Map-Reduce Buzzword 分布式编程框架完全入侵应用 逆向思维，本末倒置 合适时机出现的伟大的“廉价”创新 不等于分布式，不是银弹 简单粗暴的“分而治之” 适合批处理 典型的分布式编程模型 请求式分布式应用 平台和应用有条件隔离 • HTTP Session • 容器+运行时 VS 统一容器 请求成本高、并发弱 必备负载均衡 请求间同步需第三方支持 适合OLTP 服务型分布式计算框架——分布式遇上SOA 服务 便捷开发 重要而简单的异步 顺向思维，业务导向 框架最小程度入侵 开发态运行态隔离 专注业务 内外统一，便捷发布 灵活的应用架构 高效的运行效率 个性化的分布式模型 自上而下、自内而外的全SOA 简单、灵活、高效、个性化的