php电商后台技巧_电商系列八若何打造一个小而精的电商系统架构

本文大纲：

1. 小型电商网站的架构

2. 日志与监控系统的办理方案

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

4. 基于共享存储的图片做事器架构

5. 移动M站培植

6. 系统容量预估

7. 缓存系统

一、小型电商网站的架构

刚从传统软件行业进入到电商企业时，以为电商网站没有什么技能含量，也没有什么门槛，都是一些现有的东西堆积木似的堆出来罢了。
然而，真正进入到这个行业之后，才创造并非如此。
有人说过，好的架构，是蜕变出来的，电商网站的架构也是如此。
现在好的电商网站，看似很繁芜，很牛逼，实在也是从很小的架构，也是从没什么技能含量开始的。
以是，架构的蜕变过程，便是在技能团队不断追求极致的过程。

本日就来总结小型电商网站的架构演进。
一套电商系统最初期的架构，每每会采取一个比较范例的LAMP架构，前端加上Apache/PHP，后端是MySQL。
这个算是比较盛行的。
不过，目前还有一套.net的技能架构，可能大家很少提到。
很不幸，我便是在一个.net平台为根本的电商公司。
以是，本日也是要总结.net 平台的电商架构。

1、技能架构

一样平常初期的电商网站，基本就几个业务子系统：网站前台、商家前台、系统管理后台、App、M站等。
业务量也不是很大。
以是，MVC + 缓存 + 数据库基本就搞定了。

但就开拓效率而言，.net MVC 的技能架构不会比LAMP开拓速率慢。
以是，一些企业，为了快速推出自己的电商平台，也会采取.net 架构。

2、根本架构

上图为根本架构层面。
这是一个很大略的根本架构。

3、详细架构

全体系统架构里面，还有一个比较主要的组成部分，那便是监控系统。
例如：流量监控、硬件监控、系统性能监控等， 还有便是对某个页面进行监控，设置页面的个中一块进行监控等。
它是提高全体平台可用性的一个主要手段。
多平台、多个维度的监控，能够确保系统的可用性。
一旦涌现非常，特殊在硬件或者性能方面涌现非常，监控系统也能急速发出警告，这样也好戒备于未然。

总而言之，一个好的系统架构该当从扩展性、安全性、性能和可靠性来考虑。
罗马不是一天建成的，架构适宜就行，可以先行之而后优。
通过渐进蜕变的过程，逐步让系统越来越完善。

二、日志与监控系统的办理方案

监控系统紧张用于做事器集群的资源和性能监控，以及运用非常、性能监控、日志管理等多维度的性能监控剖析。
一个完善的监控系统和日志系统对付一个别系的主要性不必多说。
总之，只有实时理解各系统的状态，才能担保各系统的稳定。

如上图所示，监控平台监控的范围很广，从做事器性能及资源，到运用系统的监控。
每个公司都有特定的平台统一监控的需求及办理方案，但监控平台的任务和浸染基本是同等的。

1、日志

日志是监视程序运行的一种主要的办法，紧张有两个目的：1.bug的及时创造和定位；2.显示程序运行状态。

精确详细的日志记录能够快速的定位问题。
同样，通过查看日志，可以看出程序正在做什么，是不是按预期的设计在实行，以是记录下程序的运行状态是必要的。
这里将日志分为两种：1.非常日志；2.运行日志。

我们紧张是利用log4net，将各个别系的日志，持久化记录到数据库或者文件中，以方便后续的系统非常监控和性能剖析。
如何集成log4net，这里不多说。

日志记录的几个原则：

2、监控

监控系统是一个繁芜的系统平台，目前有很多的开源产品和平台。
不过我们平台小，监控任务和需求少，以是基本都是自己开拓。
紧张有这五个方面：1.系统资源；2.做事器；3.做事；4.运用非常；5.运用性能。

详细的架构图如下：

1）系统资源监控

监控各种网络参数和各做事器干系资源（CPU、内存、磁盘读写、网络、访问要求等），担保做事器系统的安全运营，并供应非常关照机制以让系统管理员快速定位/办理存在的各种问题。
目前比较盛行的该当是Zabbix。

2）做事器监控

做事器的监控，紧张是监控各个做事器、网络节点、网关等网络设备的要求相应是否正常。
通过定时做事，定时去Ping各个网络节点设备，以确认各网络设备是否正常。
如果哪个网络设备涌现非常，则发出提醒。

3）做事监控

做事监控，指的是各个Web做事、图片做事、搜索引擎做事、缓存做事等平台系统的各项做事是否正常运行。
可以通过定时做事，每隔一段韶光，就去要求干系的做事，以确保平台的各项做事正常运行。

4）运用非常监控

目前我们平台所有系统的非常记录，都记录在数据库中。
通过定时做事，统计剖析一段韶光之内的非常记录。
如果创造有干系主要的模块的系统非常，比如支付、下单模块频繁发生非常，则立即关照干系职员处理，确保做事正常运行。

5）运用性能监控

在API接口和各运用的干系位置进行拦截和记录下程序性能（SQL性能，或是 程序实行效率）。
干系主要模块供应性能预警，提前创造问题。
同时统计干系监控信息并显示给开拓的职员，以方便后续的性能剖析。

三、构建数据库的主从架构

发展到大型成熟的公司之后，主从架构可能就有点后进了，取而代之的是更加繁芜的数据库集群。
但作为一个小型电商公司，数据库的主从架构该当是最根本的。
任何大型的系统架构，都是不断演进的。
主从架构便是数据库架构中最根本的架构。
以是研究完主从架构，也就能看懂更加繁芜的架构了。

首先为什么要读写分离？

对付一个小型网站，可能单一数据库做事器就能知足需求。
但在一些大型的网站或者运用中，单一的数据库做事器可能难以支撑大的访问压力，升级做事器性能本钱又太高，以是必须要横向扩展。
还有便是，单库的话，读、写都是操作一个数据库。
数据多了之后，对数据库的读、写性能就会有很大影响。
同时对付数据安全性和系统的稳定性也是寻衅。

数据库的读写分离的好处？

读写分离的基本事理便是让主数据库处理事务性增、改、删操作（Insert、Update、Delete）操作，而从数据库处理Select查询操作。
数据库复制被用来把事务性操作导致的变更同步到其它从数据库。

以SQL为例，紧张卖力写数据、读数据。
读库仅卖力读数据。
每次有写库操作，同步更新到读库。
写库就一个，读库可以有多个，采取日志同步的办法实现紧张和多个读库的数据同步。

1、SQL Server 读写分离的配置

SQL Server供应了三种技能，可以用于主从架构之间的数据同步的实现：日志传送、事务复制和SQL 2012 中新增的功能Always On 技能。
各自利害，详细的大家自己去百度吧，这里供应网上的朋友的配置办法，仅供参考。

2、C# 数据库读写操作

C#的要求数据库操作，但数据库和主从架构的数据库还是不一样的。
主从架构的数据库，为了担保数据同等性，一样平常主库可读可写，从库只卖力读，不卖力写入。
以是，实际C#在要求数据库时，要进行差异对待。

最大略的便是：配置两个数据库连接，然后在各个数据库调用的位置，区分读写要求相应的数据库做事器，如下图：　

第二种办理方案便是判断SQL语句是写语句（Insert 、Update、Create、 Alter）还是读语句（Select）。

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

（PS：此Demo为本人总结，跟实际生产中的DLL 不太相同，但事理是一样的，大家总结封装吧）

同时，增加干系的数据库配置

四、基于共享存储的图片做事器架构

在当前这个互联网的时期，不管何种网站，对图片的需求量越来越大。
尤其是电商网站，险些都会面临到海量图片资源的存储、访问等干系技能问题。
在对图片做事器的架构、扩展、升级的过程中，肯定也会碰到各种各样的问题与需求。
当然这并不代表，你就必须得弄一个特殊NB的图片做事架构，只要大略、高效、稳定就行。
这部分我们来总结一个特殊大略、高效的图片做事架构：通过共享存储的办法来实现图片做事架构。

然而，也有一些人问我，现在大型网站的图片做事器的架构已经完备不是这样了，别人家的图片系统比你这个牛逼多了，为啥不直接写那个呢？

事实是：第一，大型牛逼的系统我也不会；第二， 再牛逼的系统也是从小的架构蜕变过去的，没有一步到位的。
这里先容图片做事器架构虽然比较大略，但也是经由了单机时期的蜕变了，基本上可以知足中小型分布式网站的需求。
这种架构的搭建和学习本钱都极低，符合目前“短平快”的开拓模式。

通过共享目录的办法实现共享存储 ，在共享目录文件做事器上配置独立域名，这样可以将图片做事器和运用做事器进行分离，来实现独立图片做事器。

优点：

1. 将图片做事和运用做事分离，缓解运用做事器的I/O负载。

2. 通过共享目录的办法来进行读写操作，可以避免多做事器之间同步干系的问题。

3. 相对来讲很灵巧，也支持扩容/扩展。
支持配置成独立图片做事器和域名访问，方便日后的扩展和优化。

4. 相对付更加繁芜的分布式的NFS系统，这种办法是性价比高，符合目前互联网的“短平快”的开拓模式。

缺陷 ：

1. 共享目录配置有些繁琐。

2. 会造成一定的（读写和安全）性能丢失。

3. 如果图片做事器涌现问题，那所有的运用都会受到影响。
同时也对存储做事器的性能哀求特殊高。

4. 图片上传操作，还是得经由Web做事器，这对Web做事器还是有巨大的压力。

架构非常大略，基本架构如下图所示：

在存储做事器上建立一个共享目录（详细办法，我就不去重复了，自己百度吧，把稳共享目录的文件安全）。

各个运用直接通过共享目录（\\192.168.1.200），将图片上传到存储做事器上。

建立一个Web站点（i1.abc.com）将该共享目录通过Web站点发布出去。
这样其它的运用就能访问到干系图片。

以是，各运用将文件上传到共享目录

//保存原图　　　　//完全的地址：\\192.168.1.200\lib\2016\03\04\10\IMG\4ugvvt6m9gdu.jpg　　　　relativePath = relativeDir + fileName + imageExtension;var absolutePath = ConfigHelper.SharePath + relativePath;fileData.SaveAs(absolutePath);

上传成功后，可直接通过web 的办法访问：

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

五、移动M站培植

最近在一贯在搞M站，也便是移动Web站点。
由于是第一次，也碰着了很多问题，以是把最近理解到的东西总结一番。
聊一聊什么是移动M站，以及它有什么浸染和上风。

有人会问，M站和APP有什么不同？

以是， 我以为，M站和客户端是相辅相成的。
M站的及时性和快捷性，是APP无法比拟的。
而APP的用户体验，则是M站无法做到的。
目前来说两者是不可能被对方完备替代的，在互联网营销大行其道的本日，M站也越来越主要。
营销活动大多以H5页面的形式展示和传播。
通过M站的营销和推广，从而又促进APP的利用和推广。

目前，移动M站有方向APP的趋势。
M站会越来越像个APP，使得M站也越来越主要。
而且，很多APP的展示效果，在原生代码无法实现的时候，嵌套移动H5页面也是一个很好的选择。

下面先容几个移动M站培植的要点：

1、51Degree

51Degrees号称是目前最快、最准确的设备检测的办理方案。
它是一个免费开源的.NET移动运用开拓组件，可以用来检测移动设备和浏览器。
乃至可以获取屏幕尺寸、输入法、加上制造商和型号信息等。
从而可以选择性地被定向到为移动设备而设计的内容。
由于拥有精确的移动设备的数据，以是险些支持所有的智好手机，平板电脑等移动设备。

实在说白了，51Degree的浸染便是识别客户真个设备。
PC浏览器访问，就跳转到PC站，手机浏览器访问就跳转到M站。
从而达到更好的用户体验。

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

2、架构

移动Web和传统的Web实在并没有实质的差异。
说白了还是一个Web站点，利用的技能都是Html+CSS+JS。
不同的是，只不过目前在Html5的大趋势下，将Html5加入到了移动M站，使得M站更像个轻APP。

3、Bootstrap

Bootstrap就不多说了，网上有很多Bootstrap的资料。
它最大的上风该当就是非常盛行，非常随意马虎上手。
如果短缺专业的设计或美工，那么Bootstrap是一个比较好的选择。
它的用法极其大略，险些没什么学习本钱，绝对是快速开拓的利器。

官网：http://getbootstrap.com/Github：https://github.com/twbs/bootstrap/

4、几点建议

六、系统容量预估

电商公司的朋友，这样的场景是否似曾相识：

运营和产品神秘兮兮的跑过来问：我们晚上要做搞个匆匆销，做事器能抗得住么？如果扛不住，须要加多少台机器？

于是，技能一脸懵逼。

实在这些都是系统容量预估的问题，容量预估是架构师必备的技能之一。
所谓，容量预估实在说白了便是系统在Down掉之前，所能承受的最大流量。
这个是技能职员对付系统性能理解的主要指标。
常见的容量评估包括流量、并发量、带宽、CPU、内存 、磁盘等一系列内容。
这部分来聊一聊容量预估的问题。

1、几个主要参数

很多人常常会把并发数和QPS给稠浊了。
实在只要理解了上面三个要素的意义之后，就能推算出它们之间的关系：QPS = 并发量 / 均匀相应韶光。

2、容量评估的步骤与方法

1）预估总访问量

如何知道总访问量？对付一个运营活动的访问量评估，或者一个别系上线后PV的评估，有什么好方法？

最大略的办法便是：讯问业务方，讯问运营同学，讯问产品同学，看产品和运营对这次活动的流量预估。

不过，业务方对付流量的预估，该当就PV和用户访问数这两个指标。
技能职员须要根据这两个数据，打算其他干系指标，比如QPS等。

2）预估均匀QPS

比如：活动落地页1小时内的总访问量是30w PV，该落地页的衍生连接数为30，那么落地页的均匀QPS=(30w30)/(6060)=2500。

3）预估峰值QPS

系统容量方案时，不能只考虑均匀QPS，还要考虑高峰的QPS，那么如何评估峰值QPS呢？

这个要根据实际的业务评估，通过以往的一些营销活动的PV等数据进行预估。
一样平常情形下，峰值QPS大概是均值QPS的3-5倍，如果日均QPS为1000，于是评估出峰值QPS为5000。

不过，有一些业务会比较难评估业务访问量，例如“秒杀业务”，这类业务的容量评估暂时不在此谈论。

4）预估系统、单机极限QPS

如何预估一个业务，一个做事器单机的极限QPS呢？

这个性能指标是做事器最基本的指标之一，以是除了压力测试没有其他的办法。
通过压力测试，算出做事器的单机极限QPS 。

在一个业务上线前，一样平常都须要进行压力测试（很多创业型公司，业务迭代很快的系统可能没有这一步，那就悲剧了），以APP推送某营销活动为例（估量日均QPS为1000，峰值QPS为5000），业务场景可能是这样的：

通过压力测试创造，Web做事器单机只能抗住1200的QPS，Cache和数据库DB能抗住并发压力（一样平常来说，1%的流量到数据库，数据库120 QPS还是能轻松抗住的，Cache的话QPS能抗住，须要评估Cache的带宽，这里假设Cache不是瓶颈），这样，我们就得到了Web单机极限的QPS是1200。
一样平常来说，生产系统不会跑满到极限的，这样随意马虎影响做事器的寿命和性能，单机线上许可跑到QPS12000.8=960。

扩展说一句，通过压力测试，已经知道Web层是瓶颈，则可针对Web干系的方面做一些调度优化，以提高Web做事器的单机QPS 。

还有压力测试事情中，一样平常因此详细业务的角度进行压力测试，关心的是某个详细业务的并发量和QPS。

5）回答最开始那两个问题：

须要的机器=峰值QPS/单机极限QPS

好了，上述已经得到了峰值QPS是5000，单机极限QPS是1000，线上支配了3台做事器：

3、总结

须要把稳的是，以上都是打算单个做事器或是单个集群的容量。
实际生产环境是由Web、行列步队、缓存、数据库等等一系列组成的繁芜集群。
在分布式系统中，任何节点涌现瓶颈，都有可能导致雪崩效应，末了导致全体集群垮掉 （“雪崩效应”指的是系统中一个小问题会逐渐扩大，末了造玉成部集群宕机）。

以是，要理解方案全体平台的容量，就必须打算出每一个节点的容量。
找出任何可能涌现的瓶颈所在。

七、缓存系统

对付一个电商系统，缓存是主要组成部分，而提升系统性能的紧张办法之一也是缓存。
它可以挡掉大部分的数据库访问的冲击，如果没有它，系统很可能会由于数据库不可用导致全体系统崩溃。

但缓存带来了其余一些棘手的问题： 数据的同等性和实时性。
例如，数据库中的数据状态已经改变，但在页面上看到的仍旧是缓存的旧值，直到缓冲韶光失落效之后，才能重新更新缓存。
这个问题怎么办理？

还有便是缓存数据如果没有失落效的话，是会一贯保持在内存中的，对做事器的内存也是包袱，那么，什么数据可以放缓存，什么数据不可以，这是系统设计之初必须考虑的问题。

什么数据可以放缓存？

什么数据不应该利用缓存？

实际上，在电商系统中，大部分数据都是可以缓存的，不能利用缓存的数据很少。
这类数据包括涉及到钱、密钥、业务关键性核心数据等。
总之，如果你创造，系统里面的大部分数据都不能利用缓存，这解释架构本身出了问题。

如何办理同等性和实时性的问题？

担保同等性和实时性的办法便是：一旦数据库更新了，就必须把原来的缓存更新。

说一说我们的缓存方案：我们目前的缓存系统：Redis（主从）+ RabbitMQ + 缓存清理做事组成，详细如下图：

缓存清理作业订阅RabbitMQ行列步队，一有数据更新进入行列步队，就将数据重新更新到Redis缓存做事器。

当然，有些朋友的方案，是数据库更新完成之后，立马去更新干系缓存数据。
这样就不须要MQ和缓存清理作业。
不过，这同时也增加了系统的耦合性。
详细得看自己的业务场景和平台大小。

以上均为个人履历分享，不敷之处请大伙轻点拍砖，有更好的建议欢迎留言。

推举阅读：

电商系列（八）如何通过QPS、并发数预估做事器容量？

电商系列（七）高可用的缓存系统架构

电商系列（六）以电商系统为例，聊一聊系统容量预估

电商系列（五）聊一聊移动H5手机端培植思路！

电商系列（四）基于共享存储的图片做事器架构！

电商系列（三）如何构建数据库的主从架构！

电商系列（二）聊一聊做事器日志与监控系统的办理方案

电商系列（一）中小型电商系统的根本架构！