电商资讯 2018-11-11 18:36:37
大型网站架构是一系列文件，欢迎大家关注。此共享主题：电子商务网站架构案例。从电子商务网站的需求到独立的体系结构，它逐渐演变为可用于参考的分布式体系结构的原型。除功能要求外，它还具有某些非功能性质量要求（体系结构目标），如高性能，高可用性，可伸缩性和可伸缩性。
根据实际需要，在线商城系统网站由1000万PV进行转换，扩展和支持。那没问题。
这个分享大纲1.电子商务案件的原因;
2.电子商务网站要求;
3.网站的主要结构;
4;系统容量估算;
5.网站架构分析;
6.网站架构优化;
7.架构摘要;
电子商务网站上有三篇文章。本文主要介绍了网站的需求，网站的初始结构以及系统容量的估算方法。
一，电子商务案例的原因分布式大型网站，目前主要有几种类型1.大型门户网站，如网易，新浪等; 2.SNS网站，如校园，开心等; 3.电子商务网站：如阿里巴巴，京东商城，国美在线，汽车之家等。大型门户网站一般都是新闻类信息，可以使用CDN，静态等优化，并且有更多的互动，如开心网。它可能会引入更多的NOSQL，分布式缓存，并使用高性能的通信框架。电子商务网站具有以上两个特征。例如，产品详细信息可以是CDN，静态和高度交互。因此，我们以电子商务网站为案例进行分析。
其次，电子商务网站需要 客户需求：1.建立全类电子商务网站（B2C），用户可以在线购买商品，可以在线支付，或货到付款;
2.用户购买时可以在线与客服沟通;
3.收到产品后，用户可以对产品进行评分并进行评估;
4.有一个成熟的发票系统;它需要连接到网站;
5，我希望能够支持3〜5年的业务发展;
6.据估计，3〜5年内用户数将达到1000万;
7.定期举行双11，双12,38个男子节和其他活动;
8.其他功能是指京东或国美在线等网站。
客户是客户，不会告诉你具体是什么，只会告诉你他想要什么，我们经常要引导和探索客户的需求。幸运的是，提供了一个清晰的参考网站。因此，下一步是进行大量分析，结合行业和参考站点为客户提供解决方案。
其他咯~~~~~
需求函数矩阵传统的需求管理方法使用用例图或模块图（需求列表）来描述需求。这通常忽略了一个非常重要的要求（非功能性要求），因此建议您使用需求函数矩阵来描述要求。
该电子商务网站的需求矩阵如下：
各类电子商务网站分类管理，商品管理方便多类管理（灵活性）网站访问速度（高性能）
图像存储要求（海量小图片）用户可以购买产品会员管理，购物车，结算功能，良好的购物体验（可用性，性能），在线支付或货到付款，多种在线支付方式，支付流程，安全性，数据加密（安全性行为）多个支付接口的灵活切换（灵活性，可扩展性）可以在线与客户服务进行通信。在线客服功能可靠性：即时通讯产品评级评估商品评论。目前，当约束停靠时，存在成熟的发票系统对接发票。为了考虑数据的一致性，鲁棒性支持3到5年，业务的发展受到约束可扩展性，可扩展性3到5年，用户数达到1000万约束，持有双11，双12,38个男人的日子等活动活动管理，秒杀突然增加访问流量（可扩展）实时要求（高性能）参考京东或国美在线参考条件。
以上是电子商务网站要求的一个简单例子，目的是为了说明
（1）当需要进行需求分析时，综合的大规模分布式系统关注非功能性需求;
（2）描述一个简单的电子商务需求场景，以便每个人都有下一个分析设计的基础。
第三，网站的主要架构一般网站，最初的做法是三个服务器，一个部署应用程序，一个部署数据库和一个部署NFS文件系统。
这是前几年相对传统的方法。我看过一个网站的超过100,000名成员，垂直高仿服装设计门户，以及N多张图片。使用单个服务器部署了应用程序，数据库和映像存储。存在许多性能问题。
如下图所示：
但是，目前主流的网站架构发生了翻天覆地的变化。通常，集群用于高可用性设计。至少以下。
（1）使用集群实现高可用性的应用服务器的冗余; （负载均衡设备可以与应用程序一起部署）
（2）使用数据库主备模式实现数据备份和高可用性;
四是系统容量估算 预计步骤：1.注册用户数量 - 每日平均紫外线量 - 每日光伏量 - 每日并发度;
2.峰值估计：平坦常数的2~3倍;
3.根据并发数量（并发数，事务数）和存储容量计算系统容量。
4，客户需求：3到5年的用户注册用户达到1000万;
每秒并发估计：1.每日紫外线是200万（第28条原则）;
2.每天点击并浏览30次;
3.光伏数量：200 * 30=6000万;
4，集中访问：24 * 0.2=4.8小时将有60万* 0.8=48万（二八原则）;
5，每分钟并发量：4.8 * 60=288分钟，访问4800/288=每分钟167,000（大约相等）;
6，每秒并发数量：16.7万/60=2780（大约相等）;
7.假设：如果峰值周期是正常值的三倍，则每秒的并发次数可以达到8340次。
8,1毫秒=1.3次访问;
没学过数学而后悔呢？ ！ （我不知道上面是否有任何错误，呵呵~~）
服务器估计:(例如使用tomcat服务器）1.按Web服务器以支持每秒300个并发计算。通常需要10台服务器（大约相等）; [tomcat默认配置为150];
2.高峰期：需要30台服务器;
容量估算：70/90原则系统CPU通常保持在约70％的水平，并且高峰期达到90％。这不是浪费资源而且相对稳定。内存，IO类似。
以上估计仅供参考，因为服务器配置，业务逻辑复杂性等具有影响。在这种情况下，不再评估CPU，硬盘，网络等。
五，网站架构分析 根据上述估计，有几个问题：1.需要部署大量服务器。在高峰时段，可以部署30个Web服务器。而这些30台服务器，只有尖峰，将在活动中使用，存在很多浪费。
2.所有应用程序都部署在同一台服务器上，应用程序之间的耦合非常严重。需要垂直和水平切割。
3.大量应用程序中存在冗余代码。
4，服务器SESSION同步消耗大量内存和网络带宽。
5，数据需要频繁访问数据库，数据库访问压力巨大。
大型网站通常需要进行以下架构优化（优化是架构设计，必须考虑，一般来自架构/代码级别，调优主要是调整简单参数，如JVM调优;如果调优涉及很多代码转换，它不是调整，它是重构）：
1.业务分裂;
2.应用程序集群部署（分布式部署，集群部署和负载平衡）;
3.多级缓存;
4.单点登录（分布式会话）;
5，数据库集群（读写分离，子库表）;
6，服务;
7，消息队列;
8.其他技术;
六，网站架构优化 6.1业务拆分1.根据业务属性垂直拆分，分为产品子系统，购物子系统，支付子系统，评论子系统，客户服务子系统，接口子系统（对接，如开发票，短信等外部系统）。
2，根据业务子系统级别定义，可分为核心系统和非核心系统。核心系统：产品子系统，购物子系统，支付子系统;非核心：评论子系统，客户服务子系统，接口子系统。
3，业务拆分角色：升级为子系统，可以负责专业的团队和部门，专业人员做专业的事情，解决模块之间的耦合和可扩展性问题;每个子系统都是单独部署的，避免了集中部署导致应用程序挂起所有应用程序都不可用的问题。
4，级别定义角色：用于流量突发，保护关键应用，实现优雅降级;保护关键应用程序免受影响。
拆分架构图：
参考部署计划2
1.如上所示，每个应用程序单独部署;
2.核心系统和非核心系统的联合部署
6.2应用程序集群部署（分布式，集群，负载平衡）1.分布式部署：分离服务后的应用程序单独部署，应用程序直接通过RPC进行通信;
2，集群部署：电子商务网站的高可用性要求，每个应用程序至少部署两台服务器进行集群部署;
3.负载平衡：高可用性系统是必需的。通常，通过负载平衡实现高可用性。通过内置负载平衡高度可用分布式服务。关系数据库通过活动/备用模式高度可用。
部署后架构图：
如图1所示，根据存储位置，缓存可以分为两种类型的本地缓存和分布式缓存。这种情况使用二级缓存来设计缓存。 1级缓存是本地缓存，2级缓存是分布式缓存。 （有页面缓存，片段缓存等，它们是更细粒度的分区）。
2. 1级缓存，缓存数据字典，以及通常不可变/状态变化的信息，如热点数据，二级缓存所需的所有缓存。 L1高速缓存过期或不可用时访问L2高速缓存的数据。如果辅助缓存不可用，请访问数据库。
3，缓存的比例，一般为1: 4，可以考虑使用缓存。 （理论上，它是1: 2）。
1.可以使用以下缓存过期策略，具体取决于业务特征：
2，缓存自动过期;
3.缓存触发器到期;
6.4单点登录（分布式会话）1.系统分为多个子系统。独立部署后，不可避免会遇到会话管理问题。通常可以使用会话同步，cookie和分布式会话方法。电子商务网站通常使用分布式会话实现。
2.此外，基于分布式会话，可以建立完整的单点登录或帐户管理系统。
流程描述
1.当用户第一次登录时，会话信息（用户ID和用户信息），例如用户ID被用作密钥，被写入分布式会话;
2.当用户再次登录时，获取分布式会话，是否有会话信息，如果没有，则转移到登录页面;
3，一般使用Cache中间件实现，建议使用Redis，因此它具有持久化功能，方便分布式会话可以从持久存储中加载会话信息;
4，存放会话时，可以设置会话的持续时间，如15分钟，超过后自动超时;
5，结合Cache中间件，分布式会话，可以非常好地模拟Session会话。
6.5数据库集群（读写分离，子数据库子表）1.大型网站需要存储大量数据。为了实现海量数据存储，通常以冗余方式设计高可用性和高性能。通常有两种读取和写入分离和子分割的方法。
2，读写分离：一般解决读取比例远大于写入比例的情况，可以使用一个主设备和一个备用设备，一个主设备多个备用设备或多个主设备多个待机模式。
这个案例基于业务拆分，结合子库表和读写分离。如下图所示：
1.业务拆分后：每个子系统都需要一个单独的库;
2.如果单个库太大，可以根据业务特征将子库作为子库，如产品分类库和产品库;
3，在子库之后，如果表中有大量数据，那么子表，一般可以根据Id，时间等进行划分; （高级用法是一致的哈希）
4.在子库和子表的基础上，分开阅读和写作;
相关的中间件可以参考Cobar（阿里，目前不在维护），TDDL（阿里），阿特拉斯（Qihu 360），MyCat（基于Cobar，很多国内牛，被称为中国第一个开源项目）。
子数据库子表，JOIN，事务问题后的序列问题将在子库主题共享中引入。
6.6服务化提取多个子系统共用的功能/模块并将其用作公共服务。例如，可以将此案例的成员子系统提取为公共服务。
1，消息队列可以解决子系统/模块之间的耦合，实现异步，高可用，高性能的系统。它是分布式系统的标准配置。在这种情况下，消息队列主要用于购物和分发。
2.用户下订单后，写入消息队列并直接返回客户端;
3.库存子系统：读取消息队列信息并完成库存减少;
4.分发子系统：读取分发的消息队列信息;
当前使用的MQ包括Active MQ，Rabbit MQ，Zero MQ，MS MQ等，需要根据具体的业务场景进行选择。建议研究Rabbit MQ。
6.8其他架构（技术）除了上面描述的业务拆分，应用程序集群，多级缓存，单点登录，数据库集群，服务和消息队列。还有CDN，反向代理，分布式文件系统，大数据处理和其他系统。我不会在这里详细介绍它。您可以询问是否有机会与Google分享。如果有机会，您可以与所有人分享。
七，结构总结
有关详细信息，请参阅之前的分享。仍有许多地方可以进行优化和改进。因为是案例共享，所以主要介绍重要的部分。在工作中，您需要根据特定的业务场景设计架构。
以上是共享电子商务网站架构的三篇文章。从电子商务网站的要求到独立架构，它逐渐演变为分布式架构的常用原型。除功能要求外，它还具有某些非功能性质量要求（体系结构目标），如高性能，高可用性，可伸缩性和可伸缩性。
2.网站技术架构示例我最近阅读了2本关于大型网站架构的书籍：《大型网站技术架构——核心原理和案例研究》李志辉，《大型网站系统和Java中间件实践》曾宪杰。
我希望从这些书中学习大型网站的结构，以及在此过程中将遇到的问题。在阅读了这两本书之后，我总结了两个大问题：
1.为什么网站技术架构会发展？换句话说，为什么网站变得更大？
2.演变过程会遇到什么问题？或者你为了进化会遇到什么问题？
为什么网站技术架构会发展？
我个人总结了我们技术架构演变的两个驱动因素，推动了我们为什么要进化网站的技术架构：
1.内部驱动力：我们希望做得更好，开发更多新业务
2.外部驱动力：增加用户数量和用户种类
这两种驱动力不是独立的，而是更常见的并行。我认为淘宝是两个驱动力并联驱动器的结果。
进化的原因很简单。但是，我们应该在什么时候改进网站的技术架构以及如何发展？面对这些问题，说实话，我没有任何经验。此外，实际上，每个企业当时都有不同的问题。因此，我很难总结从经验中演变的时机。
但我可以从另一个角度来研究这个问题：研究网站的内部和外部结构，发现这些结构可能存在的问题，了解或预测问题，当然你知道如何进化。与您了解PC结构的方式类似，您知道何时添加内存以及何时添加硬盘。
那么让我们来看看网站的外部结构：
在外部结构中，我们可以看看以下部分：
U：代表用户组。随着用户群的变化，我们的网站是如何发展的？用户组的分析，我目前可以知道的维度是：数量，类型，地理位置（区域）。
N：代表网络环境。每个地区的网络环境都不同。你可以想象我们为什么需要CDN。当我们希望每个地区的用户都能获得良好的体验时，我们如何改进我们的网站？
S：代表安全。我们有多安全吗？这与网站的当前阶段和您网站的性质有关。
C：代表我们的网站。属于内部结构
网站的内部结构：
内部结构的构成：
答：应用服务。
D：数据服务
总而言之，当我们考虑网站是否应该发展或演变时，这些组件为我们提供了考虑问题的基线。
那么为什么我们不首先将网站设计为“大”。李志辉在后记中写道：“不要试图设计一个大型网站。” “原因在于互联网的发展有其自己的规则。互联网的短暂历史一再证明这种尝试是不可行的。”还说：“大型网站不是设计的，而是逐渐发展起来的。”对于最后一句，我需要提醒您“未设计”并不意味着“自由设计”。
对于“大型网站的设计”，我个人认为现在我们有“云”，可以买到计算。只要我们的设计能够适应“云”，我可以从一开始就设计一个大型网站吗？ ？
在进化过程中会遇到什么问题。
- 初始
从一个小网站开始。服务器就足够了。
- 从应用服务中分离数据服务
越来越多的用户代表越来越多的数据，而一台服务器无法满足它。我们将数据服务与应用程序服务分开，并为应用程序服务器配置更好的CPU和内存。并使用更好更大的硬盘驱动器配置数据服务器。
- 使用缓存
由于80％的业务访问集中在20％的数据上，如果我们可以缓存这部分数据，性能就会提升。有两种类型的缓存：本地缓存和远程分布式缓存。哪一个使用？仍然使用两者，我现在不知道。
这里有一个问题，本书没有提到：应该缓存哪些数据？应该有一些原则。
- 使用服务器群集
当服务器的处理能力达到上限时，它就成了瓶颈。虽然你可以购买更强大的硬件，但总有一个限制。此时，我们需要一组服务器。此时，您必须添加一些新内容：负载平衡调度服务器。
但是，在使用服务器群集时，需要考虑一个问题：会话的管理。有几种方法可以管理Session：
会议粘贴：例如，如果我们每次必须确保我们使用自己的餐具，只要我们在餐厅吃菜，只要我们每次去这家餐厅，就好了。 。
这样的问题：
1.服务器重新启动，上述会话消失。
2.负载均衡器成为有状态机，实现灾难恢复很麻烦。
会议副本：就像我们在所有餐厅都有一张筷子桌一样。不适合大规模集群，适用于少数机器
这个解决方案的问题是：
1.应用服务器带宽问题
2.当大量用户在线时，他们使用太多内存
基于饼干：类似于每顿饭自带菜肴
这个解决方案的问题是：
1. Cookie长度限制
2.安全性
3.数据中心外部带宽消耗
4.性能影响，服务器处理每个请求的更多请求
会话服务器：它也可以是群集的。此方法适用于会话数和Web服务器数
需要考虑该计划：
1.确保会话服务器的可用性
2.我们需要在编写应用程序时进行调整。我不知道应用程序服务器是否可以使这部分逻辑透明。
- 数据库读写分离
部分数据库读取（未缓存，缓存已过期），所有写入操作也需要通过数据库。当用户数量达到一定数量时，数据库将成为瓶颈。在这里，我们使用数据库提供的热备用功能将所有读取操作带到从属服务器。注意：读写之间的分离解决了读取压力大的问题。
由于数据库是读写的，因此必须相应地更改我们的应用程序。我们实现了一个数据访问模块，以便在上层编写代码的人不知道是否存在读写分离。在这里，如果我使用ORM模型，我想知道如何实现读写分离？
数据库读写分离将遇到以下问题：
数据复制问题：考虑延迟，数据库支持和复制条件支持。不要忘记，在扩展室之后，这更是一个问题。 将路由问题应用于数据源
- 使用反向代理和CDN加速网站响应
使用CDN可以解决不同区域的访问速度问题，反向代理缓存服务器机房中的用户资源：
- 使用分布式文件系统
- 数据库特殊：垂直分割数据。
这可以解决一些数据写入问题
垂直拆分数据库时遇到的问题：
1.跨业务交易;
2.应用程序中有更多配置项
有两种方法可以解决这个问题：
1.使用分布式交易;
2，删除交易或不追求强势交易
- 业务数据表的数据量或更新量达到单个数据库的瓶颈：数据级别拆分
将同一个表中的数据拆分为两个数据库
数据级别拆分的问题：
1，SQL路由问题，您需要知道用户所在的数据库。
2.主键的策略将有所不同。
3，查询时的性能问题，如分页问题。
4.使用搜索引擎：解决数据查询问题。
5.某些方案可以提高NoSQL的性能。
6.开发数据统一访问模块：解决上层应用程序开发的数据源问题。
- 业务拆分和应用程序拆分
网站的业务变得越来越复杂，构建一个大型独立应用程序来完成所有这些业务是不切实际的。从管理角度来看，管理起来并不容易。但是，业务的分裂很难找到一个共同的模型，这是企业管理问题和技术问题的混合体。同时，它与每家公司的具体情况有关。
但是从这两本书中，最终的架构正朝着服务方向发展，即SOA。如何实现SOA是另一个重要主题，而不是本文的范围。
我从Cheng Li的2008演讲中拍摄了一张照片，以说明SOA背后的架构是什么：
- 非功能性问题
- 安全问题，监控问题
- 发布问题：新架构意味着新的发布方法
- 扩展室
- 这两本书没有说延伸室的问题。我没有经验，但我也可以猜测，如果你想离开房间，可能需要重新考虑上述所有问题。
- 组织结构的变化
我们的技术架构的变化必将导致我们的组织结构发生变化，反之亦然。
这部分似乎并不在我们的控制之下，但我认为我们的技术人员也应该参与一些组织结构的设计。例如，组织结构的设计涉及绩效，绩效有时类似于一个国家的法律。如果一个国家的法律不健全会怎样？你懂。
与此同时，我们还必须考虑学习新架构的成本。
我目前正在阅读这部分的相关书籍，我仍然没有系统的理解。
摘要：- 关于进化的顺序
实际上，技术架构的演变并不一定列在文章的开头到结尾，因此需要根据具体情况来决定。
- 关于“云”环境中的传统进化和现代演化
不幸的是，只有李志辉谈到云，只点击了——。 “现在越来越多的人的网站建立在大型网站提供的云计算服务的基础上。所有资源都需要：计算，存储和网络可以按需购买线性扩展。你不需要拼凑各种资源一个一，并全面使用各种技术解决方案，逐步完善自己的网站架构。“
因为我长时间不使用“云”，所以我无法总结云架构和传统无云架构之间的区别。
回到传统的建筑发展，我自己的总结和思考的结果是：
在对网站进行体系结构调整时，可以考虑两个主要方面：数据服务和应用程序服务。在这种调整的过程中，有必要区分哪个点当前是瓶颈，并且有必要知道哪个点具有最高优先级。同时，最重要的一点是：虽然我们作为技术人员，但我们也应该学习业务知识，这样我们就可以在考虑问题时区分业务问题和技术问题。你需要知道一些问题并不比技术方法更有效。
随商信息技术（上海）有限公司 b2b2c多用户商城系统是基于PHP技术的企业级电子商务平台系统，系统支持平台自营、招商加盟和多商家入驻、集成微信商城、移动端APP商城、微信小程序于一体。公司主营业务包含商城系统定制开发、新零售系统解决方案、电商平台系统定制开发、商城网站建设服务等等，随商为大、中、小企业提供一个安全、高效、强大的电子商务解决方案，协助企业快速构建、部署和管理其电子商务平台，拓展企业销售渠道，致力于推动PHP技术和电子商务行业的发展而不断努力。