面向互联网应用的技术架构探讨

1、面向互联网应用的技术架构探讨提纲互联网应用的架构目标互联网应用的架构实践互联网架构解决方案Web架构不等于互联网架构架构的变化：从交易型向交互型转换应用服务器DB服务器存储网络数仓和BI业务请求业务交易业务分析交易型 IT客户要求客户服务业务分析传统IT交互型 IT互联网化手机运营商IM运营商电子商务零售运营商内容运营商搜素运营商O2O物流运营商客户关系客户关系客户关系客户关系客户关系客户关系客户关系客户聚集点前移客户交互创新渠道脱媒，客户脱管如何识别，牵引和保有客户快速理解互联网应用的字面含义网络联接互动多种销售与营销形态X一切内容网络化、电子化一切系统互通互联互联网应用架构带来新的挑战Sc

2、alability（伸缩性）随业务扩展，更大的流量资源随着负载线性增加Availability（可用性）容忍故障并恢复服务质量无突变Low Latency（低延迟）高速响应简单、可维护Manageability（可管理性）诊断的手段自动化Cost（成本）开发代价与复杂度总体拥有成本 伸缩性-互联网业务有着更明显的波动性在特殊的热点引爆后，流量能够通常达到平时的10倍甚至几十倍以上。互联网业务飞速发展，特别是移动互联网的发展带来信息爆炸。同时，用户相比过去更没有耐心用户期待网站一致性的良好体验:不管网站在高峰期要承受多少访客。IT系统的可伸缩性是关键！高可用性 从未像今天这么重要亚马逊的一次故障

3、：每1分钟平均损失5.1万美元总损失超过900万美元当日股价下跌7.8%* 对于纯的互联网电子商务企业，IT系统对企业收入与客户满意度有着更直接的影响。性能 - 用户体验与转化率的重要因素Amazon: 增加 100ms 延迟将导致收入下降 1%；Google: 400 ms 延迟将导致每用户搜索请求下降 0.59%；Bing: 2 秒的延迟将导致收入降低 4.3%/用户; Shopzilla 将页面载入时间从 7秒缩减到 2秒，转化率提升了 7-12%，页面请求增加 25%Google的互联网4秒法则糟糕体验导致30%的客户选择放弃或从竞争对手购买可管理性 - 容易被忽视的环节更加复杂的IT

4、架构：多模块、多层次技术复杂性端到端不透明缺乏自动化手段同时，服务水平与敏捷性下降更加高昂的运营成本管理维护成本数据中心成本机会成本Page 12伸缩性机器自动管理，而不是人快速适应业务变化可用性与性能持续监控，故障预防快速诊断与恢复性能调优快速适应环境的变化成本减少人工维护可管理性影响着IT的各个方面提纲互联网应用的架构目标互联网应用的架构选择互联网架构解决方案Page 14海量数据？高并发？快速响应？LAMP？NoSQL？x86?安全？CLOUD？分布式？互联网应用架构 你看到了什么?嗯，不管怎样，如果我学习了互联网公司，那我一定能够成功了解互联网公司的背后 eBayPhysical Ma

5、ster DB hostsLogical DB hosts(shards)ApplicationsDAL FrameworkBusiness LogicHint (shard key)F1(Hint)ConfigDAL FrameworkBusiness LogicHint (shard key)F2(Hint)Physical standby DB hostsApp1App2全球最大的基于Oracle的Sharding数据库之一超过5PB数据每日超过50T数据48 Billion SQL/day基于Oracle的分片架构通过前端分发查询请求了解互联网公司 淘宝WebX MVC Framewo

6、rkNotifyTDDLDatabase Sharding（MySQL、Oracle)Tail/RedisTFS、OceanBase、HbaseiSearch、kSearch、vSearchMapReduceCSP、哈勃、CassandraSpring、JBosstaobaoHSF10年的系统迭代式演进较多的开源产品、自研从集中到业务中心化，普遍的分布式随着业务发展逐渐做拆分不同的场景采用合适的方案登录【login】tbsession搜索前端【list】商品详情【detail】商品中心【ic】交易中心【tp】用户中心【uic】店铺中心【sc】稳定平台【csp】监控中心【哈勃】静态内容发布【TM

7、S】后台管理收藏夹【mercury】店铺前端购物车【cart】下单【buy】促销优惠【ump】tairtfsmysqlhbaseoracle前台中心系统后台数据层淘宝如何应对大型促销？基本设计松散而依赖。对依赖管理要求极高应用分级与隔离，Qos保障针对读写不同的设计，Cache技术不同的场景，不同的设计商品/用户/交易：Oracle、MySQL收藏夹/指数：OceanBase，hbase数据仓库：Oracle、Hive监控：Cassandra应对经验可精确度量的系统能力（TPS/QPS/PV），3倍余量常态化的性能优化（应用逻辑、CDN、图片、cache）监控与容灾（持续稳定性平台）数据分析（

8、了解热点，发现隐患）降级与开关流控43.8亿，单日最高成交金额一分钟内，涌入买家270万一小时内，成交4.75亿，成交278万笔订单互联网架构设计的一般原则（From eBay）尽可能的拆分Partition Everything 容忍非一致性Embrace Inconsistency 尽可能的容错Remember，Everything Failes 尽可能异步与缓存 Async&Cache Everything 尽可能的自动化Automate Everything 更好的独立扩展与伸缩隔离错误低端的硬件更低的延迟更好的可用性更少的资源更容易的伸缩更快的环境调整更低的运维代价更好的可管理性更好

9、的可用性更好的分区能力最大可用性Page 19架构决策的关键考量架构控制力成本技术适用性应用与数据特点关键诉求了解背后的代价采购成本运维成本机会成本IT模式的差异技术能力12306、电信企业和淘宝的对比对比淘宝，12306的复杂性是多维对单维的区别金融企业 VS 其他互联网公司维度Web2.0网站电商（京东、淘宝等）金融企业业务模式提供服务，后向盈利线上商务，产品销售发展业务与用户，前向收费产品搜索、社交、门户.通用产品金融及周边产品优势免费服务、海量用户规模、快速开发、营销品类丰富与互补、运营经验、快速市场反应、营销品牌、资金、存量客户、线下渠道、售后IT模式自建模式自建模式SI建设IT控制

10、力极强强较弱流程复杂度灵活、轻量、追求快速创新灵活、轻量、追求快速创新较复杂，更追求标准与稳定服务质量要求一般，“免费的午餐”，弱一致性业务一般，平台类，售后服务不明显极高，直接面向客户收费，客户对银行服务的认识惯性性能要求较高高高扩展性要求极高，海量用户规模高，经历爆炸式增长较高IT架构的选择不是黑与白的问题，没有最好的方案，只有最合适的方案。互联网架构的普遍实践基于x86设施构建C100K,提高集群能力采用服务化的架构SOA、服务拆分缓存，消除瓶颈“木桶”理论异构数据源整合离线、实时、流式持续运维防患于未然解决海量并发PV访问压力 解决建设、管控、扩展性提高系统响应能力实现业务实时能力实现

11、运维敏捷能力互联网应用架构的普遍实践基于x86设施构建C100K问题，提高集群能力采用服务化的架构SOA，服务拆分缓存，消除瓶颈“木桶”理论异构数据源整合离线、实时、流式持续运维防患于未然如何选择性的参考并吸收？x86与RISC小机Page 24将Xeon与IBM Power系列CPU进行比较，包括标准测试指标spec_int_rate 2006、spec_fp_rate 2006，X86的性能有了长足的进步需要注意的是，服务器性能需要按照应用负载来看，有的应用需要高主频，有的需要大内存，有的需要高IO能力，不同的应用负载，X86与小型机有不同的表现。25X86服务器市场：全球x86服务器市场

12、增长速度超过UNIX服务器，占据主流UNIX服务器在关键应用领域仍然保持强势，但部分市场会被蚕食从UNIX向x86迁移，从x86向UNIX迁移面临不同的需求UNIX服务器在电信、金融等行业保持强势，但在部分应用被逐步替换X86与UNIX将形成有效互补而非替换，并各自发展X86发展驱动力：x86服务器技术的成熟分布式技术的发展云计算、新一代数据中心的发展成本的综合考虑基于x86的基础设施 发展与趋势26传统x86平台在面向关键应用的主要挑战大规模集群的性能保障，特别是集群的水平扩展能力如何保障集成的复杂度增加，特别是对系统平衡性要求较高的平台与应用，否则性能难以保障且难以预测；依赖于上层平台与应

13、用升级，以弥补单个节点的性能与可靠性的不足，如分布式并行、集群能力、尽可能无状态化等对于大规模的x86集群，运维管理的复杂度会增大，从而带来Capex增大，进而影响到整体TCO27X86单机能力 C100K问题性能必知数字引入大内存和内存计算引入高速IO设备引入高速网络设备X86架构的扩展能力多核架构下支撑高并发海量业务的性能问题，主要是CPU、内存和IO之间的速度越来越不平衡，CPU更多的是在等待Device DriverHardwareOS RDMAOS IRQKernelHot SpaceInfiniband/10GJVMBuffer Zero CopySpin LockQueue De

14、vice DriverOS RDMAOS IRQJVMBuffer Zero CopySpin LockQueue 互联网公司定制白牌服务器定制硬件，增加Flash设备，增加多网卡bonding，增大Cache定制操作系统，设置大LargePage，解决软中断性能瓶颈，解决网络拥塞定制JVM虚拟机，改善GC策略互联网架构的普遍实践基于x86设施构建更开放、更兼容采用服务化的架构SOA，服务拆分缓存，消除瓶颈“木桶”理论异构数据源整合离线、实时、流式持续运维防患于未然服务提供者SOA 管理基础框架SOA管理SOA安全SOA治理企业服务总线（数据）共享的业务服务服务化为互联网IT系统应用架构实现提

15、供参考业务服务展现服务页面组件用户交互支持业务流程多终端适配原子服务服务组装服务合理化自定义业务逻辑共享的业务流程业务流程合理化系统/人为中心的流程服务消费者应用接入模式（Portal、Web & Mobile Apps、Mashups、Workflow、Business Process）客户接入渠道（Web、Mobile、IVR）系统消费者（Client & Partner Dev、Event Process）共享的数据服务CRUD封装数据聚合数据同步服务接入数据服务数据接入应用资产接入接入服务企业服务总线淘宝是这么做服务化的互联网服务化架构设计 SOA+SNA设计要点：垂直拆分，拆分技术能

16、力拆分分布式缓存服务拆分异步消息机制拆分静态资源服务拆分基础服务ServerServerServerServer服务拆分设计要点：水平拆分，引入SOA，解除资源依赖应用可灵活任意拆分，拆分以后才能前端资源分层分离，后端SOA分离采用域名机制，配合动态DNS应用所依赖资源，如数据库，每个Server都配置全量，如服务，可采用SOA总线实现服务路由Share Nothing = 通过水平与垂直拆分，实现应用的可维护、可扩展，可伸缩Server服务器域名数据库资源服务资源应用介质通过服务化实现拆分34利用SOA化思路，优化服务规约，更动态实现业务需求利用SOA化思路，更容易隔离、优化核心瓶颈点利用S

17、OA化思路，实现业务编排，有利于后续业务需求扩展利用SOA化思路，实现业务编排，有利于后续业务拆分接入服务通用业务服务编排新业务业务扩容接入服务新服务扩容实例化新服务扩展shading数据路由服务通过服务化实现资源隔离缴费优先级和流程控制路由及负载均衡队列控制服务节点组执行队列管理能力开户资源管理并发性高并发性中并发性低节点5节点2节点3节点4节点1队列执行缴费开户资源管理应用需求资源状态资源池管理能力应用执行状态多资源及资源池能力资源动态调配能力异步消息服务用户浏览订单处理支付处理清算处理通信前置资金记账收费处理营销处理客户信息互联网用户安全核查订单处理秒杀、抢购订单受理用户登陆校验防Abo

18、t订单认证下单有效订单消息互联网架构的普遍实践基于x86设施构建更开放、更兼容采用服务化的架构SOA，服务拆分缓存，消除瓶颈“木桶”理论异构数据源整合离线、实时、流式持续运维防患于未然消除瓶颈 端到端性能的关键订单网络Web 服务器CDN数据库认证支付网络优化应用层优化数据库优化前端PV优化Web前端深度优化借助第三方分流采用CDN分布式/并行架构多级缓存优化考虑软硬集成优化读写分离、冷热分离数据库设计优化消除瓶颈，平衡设计Web前端优化WEB展现优化添加Expires头(或者Cache-control) 将javascript和css独立成外部文件压缩JavaScript和CSS文件(包括内

19、联的)避免跳转、移除重复的脚本配置Etags、缓存Ajax请求拆分初始化负载无阻塞加载脚本内容加速页面组件加载优化（延迟加载、预加载）静态页面&图片缓存优化（Nginx）借助合作方实现分流借助开放平台展开合作分流、异步多级缓存，消除瓶颈接入/负载均衡DB instanceDB instanceDB instanceWeb/appWeb/appWeb/app应用层数据Cache：降低对数据库请求压力数据库Cache：降低存储访问压力(存储Cache：降低物理磁盘访问压力（Flash/SSD) 图片/媒体Cache：降低Web访问压力数据库平衡设计：集群内部互联性能CPU能力内存大小存储IO能力（

20、带宽/IOPS）消除接入网络瓶颈Web/app平衡设计：海量并发IO吞吐能力集群内部互联性能CPU能力/内存应用服务互联性能数据库通信带宽/延迟 消除层间瓶颈，尽可能的缓存消除层内瓶颈，尽可能的均衡如何消除瓶颈？客户端缓存（浏览器/cookie)多级缓存，消除瓶颈（2）接入/负载均衡DB instanceDB instanceDB instanceWeb/appWeb/appWeb/app应用层数据Cache：降低对数据库请求压力数据库Cache：降低存储访问压力(存储Cache：降低物理磁盘访问压力（Flash/SSD) 图片/媒体Cache：降低Web访问压力客户端缓存（浏览器/cooki

21、e)优化现有图片/静态页面Cache能力：如基于NAS存储、Flash/内存的Cache能力引入应用层的分布式缓存技术，Cache数据库热点数据，并保持良好伸缩性优化数据库内存cache的使用：降低分布式节点对共享数据的冲突访问；小数据库的合并；热点表的强制Cache等利用Flash/SSD作为磁盘数据的二级缓存，大力提升数据访问效率，特别是随机数据读写的效率。分布式缓存适用场景分析 数据处理中心缓存缓存缓存应用应用并行数据缓存缓存缓存缓存代理服务器应用1应用3应用处理单元应用2数据信息缓存中心简单数据中心缓存缓存缓存特点最高性能技术原则计算靠近数据核心要求事务一致性应用架构P2P访问例子用户

22、余额、累积量，资源库存，用户在线数据特点最高并发处理技术原则类MR核心要求分布式执行应用架构一致性Hash分区访问例子海量日志、事件数据的并行访问特点最大灵活性技术原则数据接口BBP、OCP核心要求封装基本数据访问操作应用架构代理层封装例子资料、参数、静态数据、会话互联网架构的普遍实践基于x86设施构建更开放、更兼容采用服务化的架构SOA，服务拆分缓存，消除瓶颈“木桶”理论异构数据源整合离线、实时、流式持续运维防患于未然Page 44不展开数据架构的讨论买家库1买家库2买家库3买家库32卖家库1卖家库2卖家库3卖家库16Hbase集群交易数据库Shading数据库Shading数据库商品用户交

23、易垂直拆分 产品查看 等级 品牌和厂商 描述 产品目录位置 网页类型 参考的URL 参考的关键字 地理位置字段访客之前购买的商品访客之前的购买习惯将过去的行为归总查找 点击流 页面访问的秩序页面访问的持续时间访客习性历史数据产品细节会话环境互联网越来越重视数据与业务的结合实时事件中心 新的系统互联方式系统事件中心改变传统服务/消息互联方式事件引擎异构数据组合处理模式 事件处理（识别、过滤、合并、聚合）实时决策引擎外呼Email/MMS客户经理事件响应业务监控/告警欺诈控制精确营销与推广BPEL/BPM流程model客户标签、历史信息等决策依据模式识别/预测模型决策规则（行动选择、场景、客户档案

24、、预测结果、建议行动内容）事件/上下文adapter信令/DPI位置SocialWeb日志adapteradapteradapter事件处理规则SocketJMSDatabaseHttp pub/subWebserviceWebServiceMQ/JMSDatabaseCall CenterWeb/wapMobile多媒体实体厅DW决策结果0规则配置，数据与模型准备adapter获取营销服务建议，交互式营销与智能服务实时流处理配置决策学习现有精确营销的升级：统一的决策引擎更多来源更复杂的事件服务更多的渠道不仅是营销支撑结合实时场景规则与模型预测结合Hadoop/NoSQL流数据处理Stream

25、ing Data Processing非实时数据处理集成Integration 开放，同步调用实时决策服务淘宝这么做互联网架构的普遍实践基于x86设施构建更开放、更兼容采用服务化的架构SOA，服务拆分缓存，消除瓶颈“木桶”理论异构数据源整合离线、实时、流式持续运维防患于未然最大可用性架构设计可靠性核心组件采用成熟软硬件硬件内部冗余本地高可用集群架构数据冗余异地容灾异地数据快速恢复利用灾备分担负荷操作连续可在线操作能力设计WEB/应用/缓存集群数据库集群数据库读写分离数据库集群写为主非即时读/统计报表实时复制网络冗余可在线备份、配置、扩展、滚动补丁非关系型集群集成/复制端到端的业务体验保障51C

26、RM防火墙网络交换机负载均衡门户认证管理Web 服务器路由器资源帐务管理计费第3方平台服务开通平台主机 数据库可深入:最终客户体验可深入: 业务交易上下文可深入:各后台的可用性和性能端到端的， 实时的事务可见性 淘宝这么做 自开发的鹰眼系统52互联网的客户体验保障-流控降级53优雅降级,我们需要知道什么?业务优先级根据业务目标,哪些业务是不重要的每个业务所包含的功能点(包括分支功能点) 根据业务目标,哪些功能点是不重要的每个功能点所关联的外部系统容量某点出现瓶颈的时候,停掉该功能点,能否减少 该点的压力总结 应用技术架构总体视图基础设施（服务器、存储、网络）界面层 分布式缓存基础能力层应用能力层系统治理应用服务WEB服务消息服务服务化平台组件能力层总结 应用技术架构细化视图基础设施