长沙网站开发公,深圳营销策划公司十强,微商运营推广,品牌商品怎么做防伪网站大型网站架构是一个系列文档#xff0c;欢迎大家关注。本次分享主题#xff1a;电商网站架构案例。从电商网站的需求#xff0c;到单机架构#xff0c;逐步演变为常用的#xff0c;可供参考的分布式架构的原型。除具备功能需求外#xff0c;还具备一定的高性能#xff0… 大型网站架构是一个系列文档欢迎大家关注。本次分享主题电商网站架构案例。从电商网站的需求到单机架构逐步演变为常用的可供参考的分布式架构的原型。除具备功能需求外还具备一定的高性能高可用可伸缩可扩展等非功能质量需求架构目标。 根据实际需要进行改造扩展支持千万PV是没问题的。 本次分享大纲
电商案例的原因电商网站需求网站初级架构系统容量估算网站架构分析网站架构优化架构总结 电商网站案例一共有三篇本篇主要说明网站的需求网站初始架构系统容量估算方法。 一、电商案例的原因 分布式大型网站目前看主要有几类1.大型门户比如网易新浪等2.SNS网站比如校内开心网等3.电商网站比如阿里巴巴京东商城国美在线汽车之家等。大型门户一般是新闻类信息可以使用CDN静态化等方式优化开心网等交互性比较多可能会引入更多的NOSQL分布式缓存使用高性能的通信框架等。电商网站具备以上两类的特点比如产品详情可以采用CDN静态化交互性高的需要采用NOSQL等技术。因此我们采用电商网站作为案例进行分析。 二、电商网站需求 客户需求
建立一个全品类的电子商务网站B2C用户可以在线购买商品可以在线支付也可以货到付款用户购买时可以在线与客服沟通用户收到商品后可以给商品打分评价目前有成熟的进销存系统需要与网站对接希望能够支持3~5年业务的发展预计3~5年用户数达到1000万定期举办双11双12,三八男人节等活动其他的功能参考京东或国美在线等网站。 客户就是客户不会告诉你具体要什么只会告诉你他想要什么我们很多时候要引导挖掘客户的需求。好在提供了明确的参考网站。因此下一步要进行大量的分析结合行业以及参考网站给客户提供方案。 其他的略~~~~~ 需求功能矩阵 需求管理传统的做法会使用用例图或模块图需求列表进行需求的描述。这样做常常忽视掉一个很重要的需求非功能需求因此推荐大家使用需求功能矩阵进行需求描述。 本电商网站的需求矩阵如下 网站需求 功能需求 非功能需求 全品类的电子商务网站 分类管理商品管理 方便进行多品类管理灵活性网站访问速度要快高性能 图片存储的要求海量小图片用户可以在线购买商品会员管理购物车结算功能良好购物体验可用性性能在线支付或货到付款多种在线支付方式支付过程要安全数据加密安全性多种支付接口灵活切换灵活性扩展性可以在线与客服沟通在线客服功能可靠性即时通讯商品打分评价商品评论 目前有成熟的进销存系统对接进销存属于约束条件对接时要考虑数据一致性鲁棒性支持3~5年业务的发展 属于约束条件伸缩性可扩展性3~5年用户数达到1000万 约束条件举办双11双12,三八男人节等活动活动管理秒杀突增访问流量可伸缩实时性要求高性能参考京东或国美在线 参考条件 以上是对电商网站需求的简单举例目的是说明1需求分析的时候要全面大型分布式系统重点考虑非功能需求2描述一个简单的电商需求场景使大家对下一步的分析设计有个依据。 三、网站初级架构 一般网站刚开始的做法是三台服务器一台部署应用一台部署数据库一台部署NFS文件系统。 这是前几年比较传统的做法之前见到一个网站10万多会员垂直服装设计门户N多图片。使用了一台服务器部署了应用数据库以及图片存储。出现了很多性能问题。 如下图 但是目前主流的网站架构已经发生了翻天覆地的变化。一般都会采用集群的方式进行高可用设计。至少是下面这个样子。 1 使用集群对应用服务器进行冗余实现高可用负载均衡设备可与应用一块部署 使用数据库主备模式实现数据备份和高可用 四、系统容量预估 预估步骤
注册用户数-日均UV量-每日的PV量-每天的并发量峰值预估平常量的2~3倍根据并发量并发事务数存储容量计算系统容量。 客户需求3~5年用户数达到1000万注册用户 每秒并发数预估
每天的UV为200万二八原则每日每天点击浏览30次PV量200*306000万集中访问量24*0.24.8小时会有6000万*0.84800万二八原则每分并发量4.8*60288分钟每分钟访问4800/28816.7万约等于每秒并发量16.7万/602780约等于假设高峰期为平常值的三倍则每秒的并发数可以达到8340次。1毫秒1.3次访问 没好好学数学后悔了吧不知道以上算是否有错误呵呵~~ 服务器预估以tomcat服务器举例
按一台web服务器支持每秒300个并发计算。平常需要10台服务器约等于[tomcat默认配置是150]高峰期需要30台服务器 容量预估70/90原则 系统CPU一般维持在70%左右的水平高峰期达到90%的水平是不浪费资源并比较稳定的。内存IO类似。 以上预估仅供参考因为服务器配置业务逻辑复杂度等都有影响。在此CPU硬盘网络等不再进行评估。 五、网站架构分析 根据以上预估有几个问题 需要部署大量的服务器高峰期计算可能要部署30台Web服务器。并且这三十台服务器只有秒杀活动时才会用到存在大量的浪费。所有的应用部署在同一台服务器应用之间耦合严重。需要进行垂直切分和水平切分。大量应用存在冗余代码服务器SESSION同步耗费大量内存和网络带宽数据需要频繁访问数据库数据库访问压力巨大。 大型网站一般需要做以下架构优化优化是架构设计时就要考虑的一般从架构/代码级别解决调优主要是简单参数的调整比如JVM调优如果调优涉及大量代码改造就不是调优了属于重构 业务拆分应用集群部署分布式部署集群部署和负载均衡多级缓存单点登录分布式Session数据库集群读写分离分库分表服务化消息队列其他技术 六、网站架构优化 6.1业务拆分 根据业务属性进行垂直切分划分为产品子系统购物子系统支付子系统评论子系统客服子系统接口子系统对接如进销存短信等外部系统。 根据业务子系统进行等级定义可分为核心系统和非核心系统。核心系统产品子系统购物子系统支付子系统非核心评论子系统客服子系统接口子系统。 业务拆分作用提升为子系统可由专门的团队和部门负责专业的人做专业的事解决模块之间耦合以及扩展性问题每个子系统单独部署避免集中部署导致一个应用挂了全部应用不可用的问题。 等级定义作用用于流量突发时对关键应用进行保护实现优雅降级保护关键应用不受到影响。 拆分后的架构图 参考部署方案2 如上图每个应用单独部署核心系统和非核心系统组合部署 6.2应用集群部署分布式集群负载均衡 分布式部署将业务拆分后的应用单独部署应用直接通过RPC进行远程通信 集群部署电商网站的高可用要求每个应用至少部署两台服务器进行集群部署 负载均衡是高可用系统必须的一般应用通过负载均衡实现高可用分布式服务通过内置的负载均衡实现高可用关系型数据库通过主备方式实现高可用。 集群部署后架构图 6.3 多级缓存 缓存按照存放的位置一般可分为两类本地缓存和分布式缓存。本案例采用二级缓存的方式进行缓存的设计。一级缓存为本地缓存二级缓存为分布式缓存。还有页面缓存片段缓存等那是更细粒度的划分 一级缓存缓存数据字典和常用热点数据等基本不可变/有规则变化的信息二级缓存缓存需要的所有缓存。当一级缓存过期或不可用时访问二级缓存的数据。如果二级缓存也没有则访问数据库。 缓存的比例一般1:4即可考虑使用缓存。理论上是1:2即可。 根据业务特性可使用以下缓存过期策略 缓存自动过期缓存触发过期 6.4单点登录分布式Session 系统分割为多个子系统独立部署后不可避免的会遇到会话管理的问题。一般可采用Session同步Cookies分布式Session方式。电商网站一般采用分布式Session实现。 再进一步可以根据分布式Session建立完善的单点登录或账户管理系统。 流程说明 用户第一次登录时将会话信息用户Id和用户信息比如以用户Id为Key写入分布式Session用户再次登录时获取分布式Session是否有会话信息如果没有则调到登录页一般采用Cache中间件实现建议使用Redis因此它有持久化功能方便分布式Session宕机后可以从持久化存储中加载会话信息存入会话时可以设置会话保持的时间比如15分钟超过后自动超时 结合Cache中间件实现的分布式Session可以很好的模拟Session会话。 6.5数据库集群读写分离分库分表 大型网站需要存储海量的数据为达到海量数据存储高可用高性能一般采用冗余的方式进行系统设计。一般有两种方式读写分离和分库分表。 读写分离一般解决读比例远大于写比例的场景可采用一主一备一主多备或多主多备方式。 本案例在业务拆分的基础上结合分库分表和读写分离。如下图 业务拆分后每个子系统需要单独的库如果单独的库太大可以根据业务特性进行再次分库比如商品分类库产品库分库后如果表中有数据量很大的则进行分表一般可以按照Id时间等进行分表高级的用法是一致性Hash在分库分表的基础上进行读写分离 相关中间件可参考Cobar阿里目前已不在维护TDDL阿里Atlas奇虎360MyCat在Cobar基础上国内很多牛人号称国内第一开源项目。 分库分表后序列的问题JOIN事务的问题会在分库分表主题分享中介绍。 6.6服务化 将多个子系统公用的功能/模块进行抽取作为公用服务使用。比如本案例的会员子系统就可以抽取为公用的服务。 6.7消息队列 消息队列可以解决子系统/模块之间的耦合实现异步高可用高性能的系统。是分布式系统的标准配置。本案例中消息队列主要应用在购物配送环节。 用户下单后写入消息队列后直接返回客户端库存子系统读取消息队列信息完成减库存配送子系统读取消息队列信息进行配送 目前使用较多的MQ有Active MQ,Rabbit MQ,Zero MQMS MQ等需要根据具体的业务场景进行选择。建议可以研究下Rabbit MQ。 6.8其他架构技术 除了以上介绍的业务拆分应用集群多级缓存单点登录数据库集群服务化消息队列外。还有CDN反向代理分布式文件系统大数据处理等系统。 此处不详细介绍大家可以问度娘/Google有机会的话也可以分享给大家。 七、架构总结 以上是本次分享的架构总结其中细节可参考前面分享的内容。其中还有很多可以优化和细化的地方因为是案例分享主要针对重要部分做了介绍工作中需要大家根据具体的业务场景进行架构设计。 以上是电商网站架构案例的分享一共有三篇从电商网站的需求到单机架构逐步演变为常用的可供参考的分布式架构的原型。除具备功能需求外还具备一定的高性能高可用可伸缩可扩展等非功能质量需求架构目标。 2.网站技术架构示例 最近我在阅读 2 本关于大型网站架构的书《大型网站技术架构——核心原理与案例分析》李智慧、《大型网站系统与 Java 中间件实践》曾宪杰。 我期望从这些书中学习到大型网站是如何做架构的这个过程会遇到什么问题。当看完这 2 本书后我总结出两个大问题 1. 网站技术架构为什么会演进换个说法就是为什么网站会变大 2. 演进的过程会遇到什么问题或者说为了演进会遇到什么问题 网站技术架构为什么会演进 我个人总结出来我们的技术架构演进的两种驱动力驱动着我们为什么演进网站的技术架构 1. 内在驱动力我们期望把当前的业务做得更好开发更多新业务 2. 外在驱动力用户量的上升、用户种类的多样化 这两种驱动力不是独立的更多时候是并行的。我想淘宝就是两种驱动力并行驱动的结果。 演进的原因很简单。但是在什么时机我们就应该演进网站的技术架构了以及如何演进面对这些问题说实话我没有任何经验再说现实中每家企业当时都面临的问题都不一样所以我很难从经验中总结出什么是演进的时机。 但是我可以从另一个角度切入这个问题研究网站内外结构找到这些结构可能出现的问题点知道或者预见到问题点了你当然就知道应该怎么演进了。类似于你了解了 PC 机的结构你也就知道什么时候要加内存了什么时候要加硬盘了。 那么我们先看看网站的外部结构 外部结构中我们可以看由以下几个部分构成 U代表用户群。当用户群变了我们的网站如何演进用户群的分析我目前能知道的维度有数量种类地理位置区域。 N代表网络环境。网络环境在每个地区都不同。你可以想像我们为什么需要 CDN。当我们期望每个区域的用户都能得到好的体验我们的网站如何演进 S代表安全。就是我们要安全到什么程度这与网站当前所处阶段及你网站的性质有关。 C代表我们的网站。属于内部结构 网站的内部结构 内部结构的组成 A应用服务。 D数据服务 总结下来就是我们在考虑网站是否应该演进了或者如何演进时这些组成部分为我们提供了考虑问题的基准。 那么我们为什么不一开始就把网站设计成“大型”的。李智慧在后记里写到“不要企图去设计一个大型网站”“原因是互联网发展运行有其自己的规律短暂的互联网历史已经一再证明这种企图行不通”。还说了“大型网站不是设计出来的而是逐步演化出来的”。对于最后这句话我需要提醒下“不是设计出来的”并不代表“随意设计”。 对于“大型网站的设计”我个人的看法是现在我们的有“云”了计算是可以买的只要我们的设计能适应“云”我是不是就可以一开始就设计大型网站了 演进的过程会遇到什么问题 - 最初 从一个小网站说起。一台服务器也就足够了。 - 数据服务与应用服务分离 越来越多的用户代表着越来越多的数据一台服务器已经满足不了。我们将数据服务和应用服务分离给应用服务器配置更好的 CPU内存。而给数据服务器配置更好更大的硬盘。 - 使用缓存 因为 80% 的业务访问都集中在 20% 的数据上如果我们能将这部分数据缓存下来性能一下子就上来了。而缓存又分为两种本地缓存和远程分布式缓存。具体使用哪种还是两种都用我目前不知道。 这里有一个问题书没有提到应该缓存哪些数据应该有一些原则的吧。 - 使用服务器集群 当这台服务器的处理能力达到上限时它就会成为瓶颈。虽然你是可以通过购买更强大的硬件但总会有上限。这时我们就需要服务器的集群。这时就必须加个新东西负载均衡调度服务器。 但是使用服务器集群时需要考虑一个问题Session 的管理问题。Session 的管理有以下几种方式 Session Sticky打个比方就是如果我们每次吃饭都要保证我们用的是自己的碗筷而只要我们在一家饭店里存着我们的碗筷只要我们每次去这家饭店吃饭就好了。 这种方式的问题 1. 一台服务器重启上面的 session 都没了 2. 负载均衡器成了有状态的机器要实现容灾会有麻烦 Session 复制就像我们在所有的饭店里都存一份自己的碗筷。不适合做大规模集群适合机器不多的情况 这种方案的问题 1. 应用服务器间带宽问题 2. 大量用户在线时占用内存过多 基于 Cookie类似于每次吃饭都把自己的碗筷带上 这种方案的问题 1. Cookie 的长度限制 2. 安全性 3. 数据中心外部带宽的消耗 4. 性能影响服务器处理每次的请求的内容又多了 Session 服务器同样可以是集群的。这种方式适用于 session 数量及 web 服务器数量大的情况 这种方案需要考虑的是 1. 保证 session 服务器的可用性 2. 我们在写应用时需要做调整我目前不知道应用服务器能否将这部分逻辑透明化 - 数据库读写分离 数据库的一部分读未缓存、缓存过期及所有的写操作都还需要经过数据库。当用户量达到一定量数据库将会成为瓶颈。这边我们使用数据库提供的热备功能将所有的读操作引入 slave 服务器。注意读写分离解决的是读压力大的问题。 因为数据库的读写分离了所以我们的应用程序也得做相应的变化。我们实现一个数据访问模块使上层写代码的人不知道读写分离的存在。这里我很想知道如果我使用 ORM 模型时如何实现读写的分离 数据库读写分离会遇到如下问题 数据复制问题 考虑时延、数据库的支持、复制条件支持。不要忘了分机房后这个更是问题。应用对于数据源的路由问题 - 使用反向代理和 CDN 加速网站响应 使用 CDN 可以很好的解决不同的地区的访问速度问题反向代理则在服务器机房中缓存用户资源 - 使用分布式文件系统 - 数据库专库专用数据垂直拆分。 这样可以解决部分数据写的问题 垂直拆分数据库时会遇到的问题 跨业务的事务应用的配置项多了 关于事务的问题有两种办法 使用分布式事务去掉事务或不追求强事务 - 某个业务的数据表的数据量或者更新量达到了单个数据库的瓶颈数据水平拆分 将同一个表的数据拆分到两个数据库中 数据水平拆分会遇到的问题 SQL 的路由问题需要知道某个 User 在哪个数据库上。主键的策略会有不同。查询时的性能问题如分页问题 使用搜索引擎解决数据查询问题部分场景可使用 NoSQL 提高性能开发数据统一访问模块解决上层应用开发的数据源问题 - 业务拆分及应用拆分 网站的业务日益复杂建立一个独立的大型应用来完成这所有的业务变得不实际。从管理角度来也不方便管理。然而业务的拆分很难找到一种通用的模式这是一个企业管理问题和技术问题的混合问题。同时和每个企业的具体情况有关。 但是从这两本书来看最终架构都走向服务化也就是 SOA。而如何实现 SOA是另一个很大的话题不是本篇文章的范畴。 我从程立 08 年的演讲中截个图来说明 SOA 后的架构大概是怎样的 - 非功能性问题 – 安全性问题、监控问题 – 发布问题新的架构意味着新的发布方式 – 分机房 – 这两本书都没有说分机房的问题。我没有经验可是也可以猜到如果要分机房了所有上面的问题都可能要重新考虑。 – 组织架构的变化 我们的技术架构的变化势必会引起我们的组织架构的变化反之亦然。 这部分看似不应该由我们来管但是我觉得我们技术人员也要参与一部分的组织架构的设计。举个例子组织架构的设计会涉及绩效而绩效有时很像一个国家的法律。如果一个国家的法律不健全会发生什么你懂的。 同时我们还必须考虑人员对新架构的学习成本。 这部分我目前在看相关的书籍还没有一个系统的认识。 总结 - 关于演进的顺序 在现实中技术架构的演进不一定就是按文章从头到尾这样列下来的所以要视具体情况来下决定。 - 关于传统演进与现代有“云”环境下的演进 很可惜只有李智慧谈到云而且只点了一下——“现在越来越多人的网站从建立之初就是搭建在大型网站提供的云计算服务基础之上所需的一切资源计算、存储、网络都可以按需购买线性伸缩不需要自己一点一点地拼凑各种资源综合使用各种技术方案逐步去完善自己的网站架构”。 因为我用“云”的时间也不长还不能总结出有云架构与传统的无云架构在演进的时候有什么不同。 说回传统的架构演进我自己总结和思考的结果是 在对网站进行架构调整时可以从两大的维度考虑数据服务和应用服务。而这个调整的过程中需要分清当前哪个点是瓶颈需要知道哪个点优化的优先级最高。同时最重要的一点我们虽然作为技术人员也应该去学习业务知识这样我们在考虑问题时分清哪些是业务问题哪些是技术问题分清后才能对症下药。你要知道有些问题用技术手段并不比用业务手段更有效。12306 的分时卖票就是一个典型例子。
