电子商务总结（八）如何构建一个小而精密的电子商务网站架构

我过去曾写过一些电子商务网站的相关文章。如果我有这些日子的时间，我将总结与网站架构相关的文章。之前的一些内容将是连贯的，以便我们可以系统地了解如何逐步建立小型电子商务在线商城系统。

本文概述：

1.小型网上商城系统网站的架构

2.记录和监控系统解决方案

3.构建数据库的主从架构

4.基于共享存储的图像服务器架构

5.移动M站建设

6.系统容量估算

7.缓存系统

一，小型电子商务网站的结构

当我第一次从传统软件行业进入电子商务业务时，我觉得电子商务网站上没有技术内容，也没有门槛。一些现有的东西堆积如木桩。然而，在实际进入该行业后，发现情况并非如此。据说，随着电子商务网站的架构，良好的架构也在不断发展。如今，一个好的电子商务网站似乎非常复杂，非常强大。事实上，它从一个小结构开始，从没有技术内容开始。因此，架构的演变是在技术团队中不断追求终极的过程。

今天，我们将总结小型电子商务网站架构的演变。电子商务系统的初始架构倾向于采用典型的LAMP架构，前端有Apache/PHP，后端有MySQL。这很受欢迎。但是，目前有一套很少提及的.net技术架构。不幸的是，我是一家基于.net平台的电子商务公司。因此，今天也要总结一下.net平台的电子商务结构。

1技术架构

一般来说，最初的电子商务网站基本上有几个业务子系统：网站前台，商家前台，系统管理后台，App，M台等。业务量不是很大。因此，MVC +缓存+数据库基本上是固定的。

仅就开发效率而言，.netMVC的技术架构不会慢于LAMP开发。因此，一些企业为了快速推出自己的电子商务平台，也将采用.net架构。

2基础设施

上图显示了基础架构级别。这是一个非常简单的基础设施

1.考虑到访问量和系统可用性，前端网站和M站基本上采用分布式部署。通过代理服务器请求分发。

2.其他业务子系统，例如商业前端和管理系统，基本上是独立或主从部署。

3，每个DB，Redis服务和文件和图片服务，搜索引擎Solr服务等，使用主从部署。

3详细的架构

整个系统架构中一个更重要的组件是监控系统。例如：流量监控，硬件监控，系统性能监控等，有监控某个页面，设置其中一个页面进行监控。它是提高整个平台可用性的重要手段。多平台，多维监控确保系统可用性。一旦出现异常，特别是如果硬件或性能出现异常，监控系统可立即发出警告，这也是一种预防措施。

总之，应考虑良好的系统架构，以实现可扩展性，安全性，性能和可靠性。罗马不是一天建成的，建筑是正确的，它可以先做。通过逐步演变的过程，系统逐步完善。

二，日志和监控系统的解决方案

监控系统主要用于服务器集群的资源和性能监控，以及应用异常，性能监控和日志管理的多维性能监控和分析。完整的监控系统和日志系统不用说系统的重要性。简而言之，只有实时了解每个系统的状态才能确保每个系统的稳定性。

如上图所示，监控平台监控范围广泛，从服务器性能和资源到应用系统监控。每个公司都有一个特定的平台来监控需求和解决方案，但监控平台的任务和功能基本相同。

1 log

记录是监视程序操作的重要方法。主要有两个目的：

1.及时发现和定位错误;

2.显示程序的运行状态。

正确和详细的日志记录可以快速找到问题。同样，通过查看日志，您可以看到程序正在执行的操作以及它是否按预期执行，因此需要记录程序的运行状态。

这里有两种类型的日志：

1.异常日志;

2.运行日志。

我们主要使用log4net将每个系统的日志记录到数据库或文件中，以便进行后续系统异常监控和性能分析。如何整合log4net，这里不多说。

记录的几个原则：

必须清楚地区分日志级别，即错误，警告，信息等。

记录错误的位置。如果是分层系统，则必须在某一层均匀处理。例如，我们的MVC架构是一个Catch异常，并在每个Action中处理。业务层和数据库层中的异常是Catch to exception。扔到一个新的水平。

日志信息清晰准确，日志尽可能详细，便于处理。应记录相关的系统，模块，时间，操作员，堆栈信息等。方便后续处理。

2监测

监控系统是一个复杂的系统平台，有许多开源产品和平台。但是，我们的平台很小，监控任务和需求都很小，所以基本上我们自己开发。

主要有五个方面：

1.系统资源;

2.服务器;

3.服务;

4.申请例外;

5.应用程序性能。

具体架构如下：

1）系统资源监控

监控各种网络参数和服务器相关资源（CPU，内存，磁盘读/写，网络，访问请求等），确保服务器系统的安全运行，并提供异常通知机制，使系统管理员能够快速定位/解决现有的问题。目前流行应该是Zabbix。

2）服务器监控

监控服务器主要是监控每个网络设备（如服务器，网络节点或网关）的请求响应是否正常。通过定时服务，定期ping每个网络节点设备，确认每个网络设备是否正常。如果任何网络设备异常，则会发出消息警报。

3）服务监控

服务监控是指平台系统的服务，如Web服务，图像服务，搜索引擎服务和缓存服务是否正常运行。通过定时服务，每次都可以请求相关服务，以确保平台的服务正常运行。

4）应用异常监控

我们平台上所有系统的异常记录目前都记录在数据库中。通过定时服务，对一段时间内的异常记录进行统计分析。如果发现存在与重要模块相关的系统异常，如支付和订单模块频繁异常，请立即通知相关人员确保服务正常运行。

5）应用程序性能监控

在API接口和每个应用程序的相关位置拦截并记录程序性能（SQL性能或程序执行效率）。相关的重要模块提供性能警告并提前发现问题。同时，统计显示相关监测信息并显示给开发人员，以便于后续的性能分析。

第三，构建数据库的主从架构

在大型和成熟公司发展之后，主从架构可能有点过时，取而代之的是更复杂的数据库集群。但作为一家小型电子商务公司，数据库的主从架构应该是最基本的。任何大型系统架构都在不断发展。主从架构是数据库架构中最基本的架构。因此，在研究了主从架构之后，您还可以了解更复杂的架构。

首先，为什么要读写分离？

对于小型网站，单个数据库服务器可能就足够了。但是，在某些大型网站或应用程序中，单个数据库服务器可能难以支持较大的访问压力，并且升级服务器性能成本太高，因此必须水平扩展。还有一个库，读写操作数据库。数据过多后，数据库的读写性能会产生很大的影响。这也是数据安全性和系统稳定性的挑战。

数据库读写分离的好处是什么？

1.将读取操作和写入操作分离到不同的数据库中，以避免主服务器上的性能瓶颈;

2.当主服务器执行写操作时，不会影响查询应用服务器的查询性能，减少阻塞，提高并发性;

3.数据具有多个灾难恢复副本以提高数据安全性。同时，当主服务器发生故障时，它可以立即切换到其他服务器以提高系统可用性。

读写分离的基本原则是让主数据库处理事务添加，更改，删除操作（插入，更新，删除）操作，并处理来自数据库的Select查询操作。数据库复制用于将事务操作引起的更改同步到其他辅助数据库。

以SQL为例，主库负责编写数据和读取数据。读库仅负责读取数据。每次进行写操作时，更新都会同步到读库。写一个库，可以有多个读库，主库和多个读库的数据同步是通过日志同步实现的。

1SQL Server读写单独的配置

SQL Server提供了三种可用于主从体系结构之间数据同步的技术：日志传送，事务复制和SQL 2012中的新功能Always On技术。每种技术都有自己的优点和缺点。具体来说，每个人都去百度。这里，提供在线朋友配置方法仅供参考。

日志传送：SQL Server 2008 R2主从数据库同步

事务复制：SQL Server复制：事务发布

（来源：网络）

2C＃数据库读写操作

C＃请求数据库操作，单个数据库和主从架构数据库仍然不同。主从架构数据库，为了保证数据的一致性，一般主库是可读写的，从库只负责读取，不负责编写。因此，在请求数据库时应该区别对待实际的C＃。

最简单的方法是配置两个数据库连接，然后在每个数据库调用的位置，区分相应的数据库服务器以进行读写请求，如下所示：

第二种解决方案是确定SQL语句是写语句（Insert，Update，Create，Alter）还是read语句（Select）。

演示下载：http://files.cnblogs.com/files/zhangweizhong/Weiz.DB.rar

（PS：这个演示是我自己的总结，与实际生产DLL不一样，但原理是一样的，我们总结一下包）

同时，增加相关的数据库配置。

第四，基于共享存储映像服务器架构

在当今互联网时代，无论什么样的网站，对图片的需求都在增长。特别是，电子商务网站几乎总是面临与大量图像资源的存储和访问相关的技术问题。在图像服务器的体系结构，扩展和升级过程中，肯定存在各种问题和需求。当然，这并不意味着您必须获得特殊的NB图像服务架构，只要它简单，高效和稳定。在这一部分中，我们将总结一种特别简单有效的图像服务架构：图像服务架构通过共享存储实现。

但是，有些人问我，大型网站的图像服务器的架构根本不是这样的。其他人家的图像系统比你强大得多。你为什么不直接写这个？

事实是：首先，我不会有一个大规模的系统;其次，进化系统也是从一个小结构发展而来，没有一步到位。虽然这里介绍的图像服务器架构相对简单，但它已经发展到独立时代，基本上满足了中小型分布式网站的需求。该架构的构建和学习成本极低，符合当前“短而快”的开发模型。

共享存储通过共享目录实现，并且在共享目录文件服务器上配置独立域名，以便可以分离图像服务器和应用程序服务器以实现单独的图像服务器。

优点：

1.将映像服务与应用程序服务分开，以减轻应用程序服务器的I/O负载。

2.通过读写共享目录，可以避免多个服务器之间的同步问题。

3.相对灵活，它还支持扩展/扩展。支持将配置作为单独的映像服务器和域名访问，以便将来进行扩展和优化。

4.与更复杂的分布式NFS系统相比，该方法具有成本效益，符合当前互联网“短而快”的开发模式。

缺点：

1.共享目录配置有点麻烦。

2.会导致某种（识字和安全）性能损失。

3.如果映像服务器出现问题，则所有应用程序都将受到影响。同时，存储服务器的性能要求特别高。

4.图片上传操作，还是要经过网络服务器，这对网络服务器来说仍然是一个巨大的压力。

架构非常简单，基本架构如下所示：

在存储服务器上创建一个共享目录（具体来说，我不会重复它，百度，注意共享目录的文件安全性）。

每个应用程序直接通过共享目录（\\ 192.168.1.200）将映像上载到存储服务器。

创建一个Web站点（i1.abc.com）以通过Web站点发布共享目录。这样，其他应用程序可以访问相关图像。

因此，每个应用程序都将文件上传到共享目录

上传成功后，您可以直接通过网络访问它：

http://i1.abc.com/lib/2016/03/04/10/IMG/4ugvvt6m9gdu.jpg

五，移动M站的建设

最近我一直在研究M站，这是移动网站。由于这是第一次，我也遇到了很多问题，所以我总结了我最近学到的东西。谈论什么是移动M台及其作用和优势。

有人可能会问，M台和APP有什么区别？

APP直接在用户的移动设备上并且具有相对高的曝光率。 M站需要打开浏览器并输入访问它的地址，因此曝光率相对较低。

M站的推广频道比移动APP有更多的频道，便于跟踪用户来源和交通门户等，便于未来的事件推广和数据分析。

M站用户不需要安装，输入要访问的URL，APP需要下载安装。

M站可以快速通过数据分析并快速获得用户的反馈，从而可以更轻松地根据统计分析和用户需求调整产品。

APP对用户更具粘性，用户体验更好。

M站非常便于营销和推广活动，转发和共享方便快捷。

M站更新迭代产品速度和响应产品调整非常快，准备发布，APP需要审核时间。

M站跨平台，无需开发Android和iOS版本，只需一个浏览器。

因此，我觉得M台和客户是互补的。 APP的时效性和速度是APP无法比拟的。 M站无法实现APP的用户体验。目前，两者都不可能被对方完全取代。在今天的互联网营销中，M站变得越来越重要。大多数营销活动以H5页面的形式显示和传播。通过M站的营销和推广，促进了APP的使用和推广。

目前，移动M台有APP倾向。 M台将越来越像APP，使M台越来越重要。而且，很多APP显示效果，嵌套移动H5页面也是不能实现本机代码的不错选择。

以下是构建移动M站的一些关键点：

151Degree

51Degrees声称是最快，最准确的设备检测解决方案。它是一个免费的开源.NET移动应用程序开发组件，可用于检测移动设备和浏览器。您甚至可以获得屏幕尺寸，输入方法，制造商和型号信息等。因此，它可以选择性地指向为移动设备设计的内容。凭借准确的移动设备数据，它几乎支持所有移动设备，如智能手机和平板电脑。

事实上，51Degree的作用是识别客户端的设备。访问PC浏览器时，它将跳转到PC站，移动浏览器将跳转到M站。从而实现更好的用户体验。

如何将51Degree添加到现有网站？

http://51degrees.codeplex.com/wikipage？标题=加强％20existing％20web％20site

2架构

移动网络和传统网络之间没有本质区别。说穿了，它仍然是一个网站，使用的技术是Html + CSS + JS。不同之处在于，正好在Html5的大趋势下，Html5被添加到移动M台，使得M台更像是轻型APP。

3Bootstrap

Bootstrap并没有多说，互联网上有很多Bootstrap信息。它的最大优点应该是它非常受欢迎并且非常易于使用。如果缺乏专业设计或艺术，那么Bootstrap是更好的选择。他的用法非常简单，几乎没有学习成本。它绝对是快速发展的工具。

4条建议

1.移动M台的URL应与PC相同。这可以防止在PC站上显示相同的URL，但在手机上打开时它是404;

2. M站写一个单独的TDK。

六，系统容量估算

电子商务公司的朋友，这个场景是否熟悉？：

操作和产品神秘跑过来问：我们晚上要做促销，服务器可以抵制吗？如果你无法帮助，你需要添加多少台机器？

因此，该技术非常棒。

实际上，这些都是系统容量估计的问题。容量估算是架构师必须具备的技能之一。所谓的容量估计实际上是系统在下降之前可以承受的最大流量。这是技术人员理解系统性能的重要指标。常见的容量评估包括流量，并发，带宽，CPU，内存，磁盘等。这部分将讨论容量估算。

1几个重要参数

QPS：每秒处理的请求数。

并发：系统同时处理的请求数。

响应时间：一般取平均响应时间。

许多人经常将并发数量与QPS混淆。实际上，只要你理解了上述三个元素的含义，就可以计算出它们之间的关系：QPS=并发/平均响应时间。

2个步骤和能力评估方法

1）估计总访问次数

我怎么知道总访问次数？有没有什么好方法可以评估运营活动的流量，或者在系统上线后评估PV？

最简单的方法是询问工作组，询问操作同学，询问产品同学，并查看此事件的产品和操作流量估算值。

但是，业务方面的流量估算应基于PV和用户访问计数。技术人员需要根据这两个数据计算其他相关指标，例如QPS。

2）估计的平均QPS

总请求数=总PV *页面派生连接数

平均QPS=总请求/总时间

例如，事件登录页面1小时内的总访问次数为30w PV，登陆页面的派生连接数为30，则登陆页面的平均QPS为（30w * 30）/（60 * 60）=2500。

3）估计的峰值QPS

在规划系统容量时，您不仅可以考虑平均QPS，还可以考虑峰值QPS。如何评估峰值QPS？

这应该基于实际的业务评估，通过一些营销活动的先前PV数据和其他估计。通常，峰值QPS约为平均QPS的3-5倍。如果每日平均QPS为1000，那么峰值QPS估计为5000.

但是，有些企业更难评估商业访问，例如“第二次杀戮业务”，此类暂时没有讨论此类服务的容量评估。

4）估算系统，独立限制QPS

如何估算一个企业，一个服务器单机限制QPS？

此性能指标是服务器最基本的指标之一，因此没有其他方法可以进行压力测试。通过压力测试，计算服务器的独立限制QPS。

在企业上线之前，通常需要进行压力测试（许多创业公司，具有快速业务迭代的系统可能没有这一步，然后是悲剧），将APP作为营销活动（估计每日平均QPS为1000） ）峰值QPS为5000），业务场景可能如下所示：

通过应用推送活动消息;

操作活动H5登陆页面是一个网站;

H5登录页面由缓存缓存和数据库DB中的数据组合而成。

通过压力测试，发现Web服务器只能抵抗1200 QPS，而Cache和Database DB可以抵御并发压力（一般来说，1％的流量到数据库，数据库120 QPS仍然可以轻松抵抗，Cache QPS可以抵抗，需要评估Cache的带宽，这里假设Cache不是瓶颈），所以我们得到的Web独立限制的QPS是1200.一般来说，生产系统不会运行到限制，很容易影响服务器的生命和性能。允许独立线路运行到QPS1200 * 0.8=960。

为了扩展，让我们说通过压力测试，我们已经知道Web层是瓶颈，我们可以对Web相关方面进行一些调整和优化，以改善Web服务器的独立QPS。

在压力测试工作中，压力测试通常从特定业务的角度进行，关注的是特定业务的并发性和QPS。

5）在开头回答这两个问题

所需机器=峰值QPS /独立限制QPS

那么，上面已经获得了5000的峰值QPS，1000的独立QPS，以及在线部署的三台服务器：

服务器可以抵抗吗？ - ＆GT;峰值5000，独立1000，在线3，不禁

如果你无法帮助，你需要添加多少台机器？ - ＆GT;需要额外的2套，提前预订1套，并提供3套保险

3摘要

应该注意，以上是计算单个服务器或单个集群的容量。实际的生产环境是一个复杂的集群，由一系列Web，消息队列，高速缓存，数据库等组成。在分布式系统中，节点中的任何瓶颈都可能导致雪崩效应，最终导致整个集群崩溃（“雪崩效应”意味着系统中的小问题将逐渐扩展，最后整个集群将沮丧。）

因此，要了解规划整个平台的能力，必须计算每个节点的容量。找出可能出现的任何瓶颈。

七，缓存系统

对于电子商务系统，缓存是一个重要部分，提高系统性能的主要方法之一是缓存。它可以阻止数据库访问的大部分影响，没有它，系统很可能会崩溃整个系统，因为数据库不可用。

但缓存带来了一些其他棘手的问题：数据一致性和实时性。例如，数据库中的数据状态已更改，但仍在页面上看到缓存的旧值，并且在缓冲时间到期之前无法重新更新缓存。如何解决这个问题呢？

还有缓存数据，如果它没有过期，它将保留在内存中，服务器的内存也是一个负担，那么，什么数据可以缓存，哪些数据是不可能的，这是一个必须考虑的问题在系统设计之初。

可以在缓存中放入哪些数据？

1，不需要实时更新但极其消耗数据库的数据。例如，网站主页上的产品销售清单，热门搜索产品等，这些数据基本上每天计算一次，用户不会注意它是否是实时的。

2，需要实时更新，但数据更新频率不高。

3，每次通过复杂的处理逻辑获取这些数据，例如生成报告。

哪些数据不应该使用缓存？

实际上，在电子商务系统中，大多数数据都是可缓存的，并且很少有数据无法缓存。此类数据包括资金，密钥，业务关键核心数据等。简而言之，如果您发现系统中的大多数数据都无法使用缓存，则表明架构本身存在问题。

如何解决一致性和实时性问题？

确保一致性和实时性的方法是，一旦更新数据库，就必须更新原始缓存。

我们来谈谈我们的缓存方案：我们当前的缓存系统：Redis（主从）+ RabbitMQ +缓存清理服务，如下所示：

缓存清理作业订阅RabbitMQ消息队列，一旦数据更新到队列中，数据就会重新更新到Redis缓存服务器。

当然，一些朋友的计划是在数据库更新完成后立即更新相关的缓存数据。这消除了对MQ和缓存清理作业的需要。然而，这也增加了系统的耦合。具体取决于您的业务场景和平台大小。

随商信息技术（上海）有限公司 b2b2c多用户商城系统是基于PHP技术的企业级电子商务平台系统，系统支持平台自营、招商加盟和多商家入驻、集成微信商城、移动端APP商城、微信小程序于一体。公司主营业务包含商城系统定制开发、新零售系统解决方案、电商平台系统定制开发、商城网站建设服务等等，随商为大、中、小企业提供一个安全、高效、强大的电子商务解决方案，协助企业快速构建、部署和管理其电子商务平台，拓展企业销售渠道，致力于推动PHP技术和电子商务行业的发展而不断努力。