如何打造一个小而精的电商网站架构？

本文大纲：

1. 小型电商网站的架构

2. 日志与监控系统的解决方案

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

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

5. 移动M站建设

6. 系统容量预估

7. 缓存系统

 

   

1、小型电商网站的架构

  

 

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

 

今天就来总结小型电商网站的架构演进。一套电商系统最初期的架构，每每会采用一个比较典型的LAMP架构，前端加上Apache/PHP，后端是MySQL。这个算是比较流行的。不过，目前还有一套.net的技术架构，可能你们不多提到。很不幸，我就是在一个.net平台为基础的电商公司。因此，今天也是要总结.net 平台的电商架构。

 

1技术架构

 

 

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

 

单就开发效率而言，.net MVC 的技术架构不会比LAMP开发速度慢。因此，一些企业，为了快速推出本身的电商平台，也会采用.net 架构。

 

2基础架构

 

 

上图为基础架构层面。这是一个很简单的基础架构。

 

• 前端网站和M站，考虑到访问量和系统的可用性，基本会采用分布式部署。经过代理服务器进行请求分发。

• 其它的业务子系统，像商家前台和管理系统，基本上都是单机或是主从部署。

• 各个DB ，Redis 服务和文件和图片服务，搜索引擎Solr服务等，采用主从部署。

 

3详细架构

 

 

整个系统架构里面，还有一个比较重要的组成部分，那就是监控系统。例如：流量监控、硬件监控、系统性能监控等， 还有就是对某个页面进行监控，设置页面的其中一块进行监控等。它是提升整个平台可用性的一个重要手段。多平台、多个维度的监控，可以确保系统的可用性。一旦出现异常，特别在硬件或者性能方面出现异常，监控系统也能马上发出警告，这样也好防范于未然。

 

总而言之，一个好的系统架构应该从扩展性、安全性、性能和可靠性来考虑。罗马不是一天建成的，架构适合就行，能够先行之然后优。经过渐进演化的过程，逐步让系统愈来愈完善。

 

   

2、日志与监控系统的解决方案

  

 

监控系统主要用于服务器集群的资源和性能监控，以及应用异常、性能监控、日志管理等多维度的性能监控分析。一个完善的监控系统和日志系统对于一个系统的重要性没必要多说。总之，只有实时了解各系统的状态，才能保证各系统的稳定。

 

 

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

 

1日志

 

日志是监视程序运行的一种重要的方式，主要有两个目的：1.bug的及时发现和定位；2.显示程序运行状态。

 

正确详细的日志记录可以快速的定位问题。一样，经过查看日志，能够看出程序正在作什么，是否是按预期的设计在执行，因此记录下程序的运行状态是必要的。这里将日志分为两种：1.异常日志；2.运行日志。

 

咱们主要是使用log4net，将各个系统的日志，持久化记录到数据库或者文件中，以方便后续的系统异常监控和性能分析。如何集成log4net，这里很少说。

 

日志记录的几个原则：

• 日志级别必定要区分清楚，哪些属于error、warning、info等。

• 记录错误的位置。若是是分层系统，必定要在某个层统一处理，例如咱们的MVC架构，都是在各个Action中Catch异常并处理，而业务层和数据库层这些地方的异常，都是Catch到异常后，往上一层抛。

• 日志信息清晰准确有意义，日志尽可能详细点，以方便处理。应该记录相关系统、模块、时间、操做人、堆栈信息等。方便后续处理。

 

2监控

 

监控系统是一个复杂的系统平台，目前有不少的开源产品和平台。不过咱们平台小，监控任务和需求少，因此基本都是本身开发。主要有这五个方面：1.系统资源；2.服务器；3.服务；4.应用异常；5.应用性能。

 

具体的架构图以下：

 

 

1）系统资源监控

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

 

2）服务器监控

服务器的监控，主要是监控各个服务器、网络节点、网关等网络设备的请求响应是否正常。经过定时服务，定时去Ping各个网络节点设备，以确认各网络设备是否正常。若是哪一个网络设备出现异常，则发出消息提醒。

 

3）服务监控

服务监控，指的是各个Web服务、图片服务、搜索引擎服务、缓存服务等平台系统的各项服务是否正常运行。能够经过定时服务，每隔一段时间，就去请求相关的服务，以确保平台的各项服务正常运行。

 

4）应用异常监控

目前咱们平台全部系统的异常记录，都记录在数据库中。经过定时服务，统计分析一段时间以内的异常记录。若是发现有相关重要的模块的系统异常，好比支付、下单模块频繁发生异常，则当即通知相关人员处理，确保服务正常运行。

 

 5）应用性能监控

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

 

   

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

  

 

发展到大型成熟的公司以后，主从架构可能就有点落伍了，取而代之的是更加复杂的数据库集群。但做为一个小型电商公司，数据库的主从架构应该是最基础的。任何大型的系统架构，都是不断演进的。主从架构即是数据库架构中最基础的架构。因此研究完主从架构，也就能看懂更加复杂的架构了。

 

首先为何要读写分离？

 

对于一个小型网站，可能单台数据库服务器就能知足需求。但在一些大型的网站或者应用中，单台的数据库服务器可能难以支撑大的访问压力，升级服务器性能成本又过高，因此必需要横向扩展。还有就是，单库的话，读、写都是操做一个数据库。数据多了以后，对数据库的读、写性能就会有很大影响。同时对于数据安全性和系统的稳定性也是挑战。

 

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

 

• 将读操做和写操做分离到不一样的数据库上，避免主服务器出现性能瓶颈；

• 主服务器进行写操做时，不影响查询应用服务器的查询性能，下降阻塞，提升并发；

• 数据拥有多个容灾副本，提升数据安全性，同时当主服务器故障时，可当即切换到其余服务器，提升系统可用性。

 

 

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

 

以SQL为例，主库负责写数据、读数据。读库仅负责读数据。每次有写库操做，同步更新到读库。写库就一个，读库能够有多个，采用日志同步的方式实现主库和多个读库的数据同步。

 

1SQL Server 读写分离的配置

 

SQL Server提供了三种技术，能够用于主从架构之间的数据同步的实现：日志传送、事务复制和SQL 2012 中新增的功能Always On 技术。各自优劣，具体的你们本身去百度吧，这里提供网上的朋友的配置方式，仅供参考。

 

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

  （连接：http://www.it165.net/database/html/201306/4088.html）

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

  （连接：http://www.cnblogs.com/gaizai/p/3305879.html）

 

 

（图源：网络）

 

2C# 数据库读写操做

 

C#的请求数据库操做，单数据库和主从架构的数据库仍是不同的。主从架构的数据库，为了保证数据一致性，通常主库可读可写，从库只负责读，不负责写入。因此，实际C#在请求数据库时，要进行区别对待。

 

最简单的就是：配置两个数据库链接，而后在各个数据库调用的位置，区分读写请求相应的数据库服务器，以下图：　

　　

 

第二种解决方案就是判断SQL语句是写语句（Insert 、Update、Create、 Alter）仍是读语句（Select）。

 

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

 

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

  

 

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

 

 

   

4、基于共享存储的图片服务器架构

  

 

在当前这个互联网的时代，无论何种网站，对图片的需求量愈来愈大。尤为是电商网站，几乎都会面临到海量图片资源的存储、访问等相关技术问题。在对图片服务器的架构、扩展、升级的过程当中，确定也会碰到各类各样的问题与需求。固然这并不表明，你就必须得弄一个特别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

 

   

5、移动M站建设

  

 

最近在一直在搞M站，也就是移动Web站点。因为是第一次，也遇到了不少问题，因此把最近了解到的东西总结一番。聊一聊什么是移动M站，以及它有什么做用和优点。

 

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

 

1. APP直接在用户的移动设备上，曝光率相对较高。 而M站需打开浏览器，输入地址才能访问，因此曝光率相对较低。

2. M站的推广的渠道相比移动APP，渠道较多，方便追踪用户来源、流量入口等，方便之后的活动推广和数据分析。

3. M站用户无需安装，输入URL便可访问，而APP须要下载安装。

4. M站可以快速地经过数据分析，能快速获得用户的反馈，从而更容易根据统计数据分析和用户的需求来调整产品。

5. APP对用户更具粘性及用户体验也更好。

6. M站对于营销推广活动很是方便，转发分享方便快捷。

7. M站更新迭代产品速度和响应产品调整很是快，随时发布，而APP须要审核时间。

8. M站跨平台，无需开发安卓和iOS版，只需有浏览器便可。     

 

因此， 我以为，M站和客户端是相辅相成的。M站的及时性和快捷性，是APP没法比拟的。而APP的用户体验，则是M站没法作到的。目前来讲二者是不可能被对方彻底替代的，在互联网营销大行其道的今天，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？title=Enhance%20existing%20web%20site

 

2架构

 

移动Web和传统的Web其实并无本质的区别。说白了仍是一个Web站点，使用的技术都是Html+CSS+JS。不一样的是，只不过目前在Html5的大趋势下，将Html5加入到了移动M站，使得M站更像个轻APP。

 

 

3Bootstrap

 

Bootstrap就很少说了，网上有不少Bootstrap的资料。它最大的优点应该就是很是流行，很是容易上手。若是缺乏专业的设计或美工，那么Bootstrap是一个比较好的选择。他的用法极其简单，几乎没什么学习成本，绝对是快速开发的利器。

 

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

 

4几点建议

 

• 移动M站的URL要尽可能和PC相同，这是能够避免同一URL在PC站能够显示，可是在手机上打开倒是404；

• M站写单独的TDK。

 

   

6、系统容量预估

  

 

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

 

运营和产品神秘兮兮的跑过来问：咱们晚上要作搞个促销，服务器能抗得住么？若是扛不住，须要加多少台机器？

 

因而，技术一脸懵逼。

 

其实这些都是系统容量预估的问题，容量预估是架构师必备的技能之一。所谓，容量预估其实说白了就是系统在Down掉以前，所能承受的最大流量。这个是技术人员对于系统性能了解的重要指标。常见的容量评估包括流量、并发量、带宽、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），业务场景多是这样的：

 

• 经过APP推送一个活动消息；

• 运营活动H5落地页是一个Web站点；

• H5落地页由缓存Cache和数据库DB中的数据拼装而成。

 

经过压力测试发现，Web服务器单机只能抗住1200的QPS，Cache和数据库DB能抗住并发压力（通常来讲，1%的流量到数据库，数据库120 QPS仍是能轻松抗住的，Cache的话QPS能抗住，须要评估Cache的带宽，这里假设Cache不是瓶颈），这样，咱们就获得了Web单机极限的QPS是1200。通常来讲，生产系统不会跑满到极限的，这样容易影响服务器的寿命和性能，单机线上容许跑到QPS1200*0.8=960。

 

扩展说一句，经过压力测试，已经知道Web层是瓶颈，则可针对Web相关的方面作一些调整优化，以提升Web服务器的单机QPS 。

 

还有压力测试工做中，通常是以具体业务的角度进行压力测试，关心的是某个具体业务的并发量和QPS。

 

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

　　　　

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

 

好了，上述已经获得了峰值QPS是5000，单机极限QPS是1000，线上部署了3台服务器：

• 服务器能抗住么？ -> 峰值5000，单机1000，线上3台，扛不住

• 若是扛不住，须要加多少台机器？ -> 须要额外2台，提早预留1台更好，给3台保险

 

3总结

 

须要注意的是，以上都是计算单个服务器或是单个集群的容量。实际生产环境是由Web、消息队列、缓存、数据库等等一系列组成的复杂集群。在分布式系统中，任何节点出现瓶颈，都有可能致使雪崩效应，最后致使整个集群垮掉 （“雪崩效应”指的是系统中一个小问题会逐渐扩大，最后形成整个集群宕机）。

 

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

 

   

7、缓存系统

  

 

对于一个电商系统，缓存是重要组成部分，而提高系统性能的主要方式之一也是缓存。它能够挡掉大部分的数据库访问的冲击，若是没有它，系统极可能会由于数据库不可用致使整个系统崩溃。

 

但缓存带来了另一些棘手的问题： 数据的一致性和实时性。例如，数据库中的数据状态已经改变，但在页面上看到的仍然是缓存的旧值，直到缓冲时间失效以后，才能从新更新缓存。这个问题怎么解决？

 

还有就是缓存数据若是没有失效的话，是会一直保持在内存中的，对服务器的内存也是负担，那么，什么数据能够放缓存，什么数据不能够，这是系统设计之初必须考虑的问题。

 

什么数据能够放缓存？

 

• 不须要实时更新可是又极其消耗数据库的数据。好比网站首页的商品销售的排行榜，热搜商品等等，这些数据基本上都是一天统计一次，用户不会关注其是不是实时的。

• 须要实时更新，可是数据更新的频率不高的数据。

• 每次获取这些数据都通过复杂的处理逻辑，好比生成报表。

 

什么数据不该该使用缓存？

 

实际上，在电商系统中，大部分数据都是能够缓存的，不能使用缓存的数据不多。这类数据包括涉及到钱、密钥、业务关键性核心数据等。总之，若是你发现，系统里面的大部分数据都不能使用缓存，这说明架构自己出了问题。

 

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

 

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

 

说一说咱们的缓存方案：咱们目前的缓存系统：Redis（主从）+ RabbitMQ + 缓存清理服务组成，具体以下图：

 

缓存清理做业订阅RabbitMQ消息队列，一有数据更新进入队列，就将数据从新更新到Redis缓存服务器。

 

固然，有些朋友的方案，是数据库更新完成以后，立马去更新相关缓存数据。这样就不须要MQ和缓存清理做业。不过，这同时也增长了系统的耦合性。具体得看本身的业务场景和平台大小。

原文地址：http://click.aliyun.com/m/21358/