有哪些可以做策划方案的网站,专业做生鲜的网站,合肥建设网站哪家好,美丽乡村网站建设模板为什么80%的码农都做不了架构师#xff1f; #0 系列目录# 大型分布式网站架构大型分布式网站架构技术总结大型网站架构系列#xff1a;电商网站架构案例#1 电商案例原因# 分布式大型网站#xff0c;目前看主要有几类1.大型门户#xff0c;比如网易#xff… 为什么80%的码农都做不了架构师 #0 系列目录# 大型分布式网站架构大型分布式网站架构技术总结大型网站架构系列电商网站架构案例#1 电商案例原因# 分布式大型网站目前看主要有几类1.大型门户比如网易新浪等2.SNS网站比如校内开心网等3.电商网站比如阿里巴巴京东商城国美在线汽车之家等。大型门户一般是新闻类信息可以使用CDN静态化等方式优化开心网等交互性比较多可能会引入更多的NOSQL分布式缓存使用高性能的通信框架等。电商网站具备以上两类的特点比如产品详情可以采用CDN静态化交互性高的需要采用NOSQL等技术。因此我们采用电商网站作为案例进行分析。 #2 电商网站需求# 客户需求 建立一个全品类的电子商务网站B2C用户可以在线购买商品可以在线支付也可以货到付款 用户购买时可以在线与客服沟通 用户收到商品后可以给商品打分评价 目前有成熟的进销存系统需要与网站对接 希望能够支持3~5年业务的发展 预计3~5年用户数达到1000万 定期举办双11双12,三八男人节等活动 其他的功能参考京东或国美在线等网站。 客户就是客户不会告诉你具体要什么只会告诉你他想要什么我们很多时候要引导挖掘客户的需求。好在提供了明确的参考网站。因此下一步要进行大量的分析结合行业以及参考网站给客户提供方案。 需求管理传统的做法会使用用例图或模块图需求列表进行需求的描述。这样做常常忽视掉一个很重要的需求非功能需求因此推荐大家使用需求功能矩阵进行需求描述。 本电商网站的需求矩阵如下 以上是对电商网站需求的简单举例目的是说明1需求分析的时候要全面大型分布式系统重点考虑非功能需求2描述一个简单的电商需求场景使大家对下一步的分析设计有个依据。 #3 网站初级架构# 一般网站刚开始的做法是三台服务器一台部署应用一台部署数据库一台部署NFS文件系统。这是前几年比较传统的做法之前见到一个网站10万多会员垂直服装设计门户N多图片。使用了一台服务器部署了应用数据库以及图片存储。出现了很多性能问题。如下图 但是目前主流的网站架构已经发生了翻天覆地的变化。一般都会采用集群的方式进行高可用设计。至少是下面这个样子。 1使用集群对应用服务器进行冗余实现高可用负载均衡设备可与应用一块部署 2使用数据库主备模式实现数据备份和高可用 #4 系统容量预估# 预估步骤 注册用户数-日均UV量-每日的PV量-每天的并发量 峰值预估平常量的2~3倍 根据并发量并发事务数存储容量计算系统容量 客户需求3~5年用户数达到1000万注册用户 每秒并发数预估 每天的UV为200万二八原则 每日每天点击浏览30次 PV量200*306000万 集中访问量240.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硬盘网络等不再进行评估。 #5 网站架构分析# 根据以上预估有几个问题 需要部署大量的服务器高峰期计算可能要部署30台Web服务器。并且这三十台服务器只有秒杀活动时才会用到存在大量的浪费。 所有的应用部署在同一台服务器应用之间耦合严重。需要进行垂直切分和水平切分。 大量应用存在冗余代码。 服务器SESSION同步耗费大量内存和网络带宽。 数据需要频繁访问数据库数据库访问压力巨大。 大型网站一般需要做以下架构优化优化是架构设计时就要考虑的一般从架构/代码级别解决调优主要是简单参数的调整比如JVM调优如果调优涉及大量代码改造就不是调优了属于重构 业务拆分 应用集群部署分布式部署集群部署和负载均衡 多级缓存 单点登录分布式Session 数据库集群读写分离分库分表 服务化 消息队列 其他技术 #6 网站架构优化# ##6.1 业务拆分## 根据业务属性进行垂直切分划分为产品子系统购物子系统支付子系统评论子系统客服子系统接口子系统对接如进销存短信等外部系统。 根据业务子系统进行等级定义可分为核心系统和非核心系统。核心系统产品子系统购物子系统支付子系统非核心评论子系统客服子系统接口子系统。 业务拆分作用提升为子系统可由专门的团队和部门负责专业的人做专业的事解决模块之间耦合以及扩展性问题每个子系统单独部署避免集中部署导致一个应用挂了全部应用不可用的问题。 等级定义作用用于流量突发时对关键应用进行保护实现优雅降级保护关键应用不受到影响。 拆分后的架构图 参考部署方案2 1如上图每个应用单独部署 2核心系统和非核心系统组合部署 ##6.2 应用集群部署分布式集群负载均衡## 分布式部署将业务拆分后的应用单独部署应用直接通过RPC进行远程通信 集群部署电商网站的高可用要求每个应用至少部署两台服务器进行集群部署 负载均衡是高可用系统必须的一般应用通过负载均衡实现高可用分布式服务通过内置的负载均衡实现高可用关系型数据库通过主备方式实现高可用。 集群部署后架构图 ##6.3 多级缓存## 缓存按照存放的位置一般可分为两类本地缓存和分布式缓存。本案例采用二级缓存的方式进行缓存的设计。一级缓存为本地缓存二级缓存为分布式缓存。还有页面缓存片段缓存等那是更细粒度的划分 一级缓存缓存数据字典和常用热点数据等基本不可变/有规则变化的信息二级缓存缓存需要的所有缓存。当一级缓存过期或不可用时访问二级缓存的数据。如果二级缓存也没有则访问数据库。 缓存的比例一般1:4即可考虑使用缓存。理论上是1:2即可。 根据业务特性可使用以下缓存过期策略 1缓存自动过期 2缓存触发过期 ##6.4 单点登录分布式Session## 系统分割为多个子系统独立部署后不可避免的会遇到会话管理的问题。一般可采用Session同步Cookies分布式Session方式。电商网站一般采用分布式Session实现。 再进一步可以根据分布式Session建立完善的单点登录或账户管理系统。 流程说明 1用户第一次登录时将会话信息用户Id和用户信息比如以用户Id为Key写入分布式Session 2用户再次登录时获取分布式Session是否有会话信息如果没有则调到登录页 3一般采用Cache中间件实现建议使用Redis因此它有持久化功能方便分布式Session宕机后可以从持久化存储中加载会话信息 4存入会话时可以设置会话保持的时间比如15分钟超过后自动超时 结合Cache中间件实现的分布式Session可以很好的模拟Session会话。 ##6.5 数据库集群读写分离分库分表## 大型网站需要存储海量的数据为达到海量数据存储高可用高性能一般采用冗余的方式进行系统设计。一般有两种方式读写分离和分库分表。 读写分离一般解决读比例远大于写比例的场景可采用一主一备一主多备或多主多备方式。 本案例在业务拆分的基础上结合分库分表和读写分离。如下图 1业务拆分后每个子系统需要单独的库 2如果单独的库太大可以根据业务特性进行再次分库比如商品分类库产品库 3分库后如果表中有数据量很大的则进行分表一般可以按照Id时间等进行分表高级的用法是一致性Hash 4在分库分表的基础上进行读写分离 相关中间件可参考Cobar阿里目前已不在维护TDDL阿里Atlas奇虎360MyCat在Cobar基础上国内很多牛人号称国内第一开源项目。 分库分表后序列的问题JOIN事务的问题会在分库分表主题分享中介绍。 ##6.6 服务化## 将多个子系统公用的功能/模块进行抽取作为公用服务使用。比如本案例的会员子系统就可以抽取为公用的服务。 ##6.7 消息队列## 消息队列可以解决子系统/模块之间的耦合实现异步高可用高性能的系统。是分布式系统的标准配置。本案例中消息队列主要应用在购物配送环节。 1用户下单后写入消息队列后直接返回客户端 2库存子系统读取消息队列信息完成减库存 3配送子系统读取消息队列信息进行配送 目前使用较多的MQ有Active MQ,Rabbit MQ,Zero MQMS MQ等需要根据具体的业务场景进行选择。建议可以研究下Rabbit MQ。 ##6.8 其他架构技术## 除了以上介绍的业务拆分应用集群多级缓存单点登录数据库集群服务化消息队列外。还有CDN反向代理分布式文件系统大数据处理等系统。 此处不详细介绍大家可以问度娘/Google有机会的话也可以分享给大家。 #7 架构总结# 转载于:https://my.oschina.net/xianggao/blog/637807
