大型电商架构及演化历程.pptVIP

大型电商架构及演化历程 盈天讯 张宇 自我介绍 亿玛科技架构师 中宏互联技术总监 凡客诚品首席架构师 IBM GBS 资深电子商务顾问 苏宁易购项目，技术管理委员会核心成员 曾参与上品折扣、广之旅、李锦记、中国银行企业网银、平安保险等项目 目前：盈天讯首席架构师 Agenda 小且快（资金为重） 大而全（功能为重） 大且快（量级为重） 大且敏（终极追求） 技术趋势 小且快（资金为重） 两个层面的“快” 架构选型：ASP.NET、RoR等 他们都选了什么？ 架构特点 部署架构 两个层面的“快” 电商的灵魂是“快” 开发速度快 运行速度快 小而快时候，更多的指的是开发速度快 框架选型 ASP.NET RoR Grails PHP Django 他们都选了什么？ 架构选型 为什么大多数人选择了ASP.NET？ 人员成本 服务器成本 人力资源充沛 有几个人熟悉其他RAD？ 维护成本低 成长空间：容易晋身为企业级架构 为什么大多数人选择了自主研发？ 需要商业模式创新 创业者期望“颠覆” “小而美”的时候，维护成本高 架构特点 轻量，直观，容易理解，架构代价（overhead）小 耦合度高 基本不存在分层 能做到静态分层已经很不错了 有些团队喜欢把所有查询都写在存储过程中 Data Driven 以数据（库）为中心的设计 全局数据共享，极少考虑封装性 CRUD四轮马车的代码 没有，也不太可能测试（单元，集成） 部署架构 基本上是单点 甚至是租用主机 现在可以选择云 大而全（功能为重） 野蛮生长 企业级需求 问题 架构演进 架构特征 部署架构 野蛮生长 截止到2010年3月份，凡客诚品技术部接到的需求已经排期排到了2013年 技术团队从2-5个人突然增长到300+，后来增长到1000+ 苏宁易购也同样经历了开发人员从几十一下子到几百再一下子到上千的阶段 网站后台从几个模块增加到上百个模块 从单一网站系统演变为众多业务系统（客服系统、联盟系统、搜索系统、供应商系统、物流仓储系统……） 每个系统都有少则几十多则上百的模块 企业级需求 企业级复杂度 工作流（审核、审批） 专业的财务需求 多系统统一认证（SSO、LDAP）、权限 作业（JOB、Cron）系统、队列、批处理 各种客户端接入（C/S、B/S） 凡客管理平台，ERP，CRM，WMS，客服系统都是C/S架构 问题 来不及设计 系统关键环节越来越复杂，越来越难维护 “订单转有效”是一个凡客内部著名的存储过程，历经4名程序员，最终达到3000+行SQL，并成功达到无人能懂，无人敢改的地步 所有功能交织在一起，牵一发而动全身 代码改动影响面大，回归测试范围大 长事务、大事务 架构演进——分层架构 面对越来越复杂的业务系统，首要的问题是耦合过重 最基本的是分层架构 分层架构——我们得到了什么？ 人们常说，分层架构主要的好处是可以替换某一层的具体实现，比如我可以把UI层从Struts换成Spring VMC，可以把Data Access层从Hibernate换成iBatis，但多少项目换过？ 更清晰的代码 噪音的减小 更有意义的命名 复用 可维护性 存储过程中的业务逻辑全部收回逻辑层 架构演进——划分模块 分层架构使得各层之间的依赖关系变得明晰 重构、重写部分代码 拆分依赖中枢 下单 促销 划分业务模块 使用单元测试保证重构是安全的 Refactoring To Patterns 架构演进——AOP SSO，权限等代码 事务代码 日志代码 严重干扰了业务代码的清晰度 增加了出错几率 架构特征 分层清晰，层次之间依赖关系清晰 面向接口的设计 采用Spring等DI框架 各小组负责自己的业务模块 AOP等架构组件使基础服务自动化 数据库集成 主系统和各个边缘系统通过共享数据库进行数据交换 数据库表混用现象突出 用户、订单表中的字段可能多达100多个，被十几个系统分别使用 数据库锁现象严重 各个系统争用数据库锁 某些数据库产品因此容易发生死锁现象 部署架构 负载均衡优于HA（热备） 可以随时扩展新的运算能力 大且快（量级为重） 挑战 架构演进 CQRS 缓存 切分 横纵切分 前后端切分 异步与最终一致 Reporting Database 架构演进——CQRS 电商的特点是，80%的请求是只读的 CQRS = Command Query Responsibility Separation 不仅仅是你认为的读写分离 从UI，到Action，到Service，一直到数据库，贯穿始终的读写分离 Cache-Control 命名规范：GetXXX，QueryXXX 读写分离的事务控制（电商容许很大范围的数据不一致现象） 只读数据库 架构演进——CQRS 架构演进——各级缓存 浏览器缓存 CDN 前端HTTP缓存