前面写过一些电商网站相关的文章，这几天有时间，就把之前写得网站架构相关的文章，总结整理一下。把以前的一些内容就连贯起来，这样也能系统的知道，一个最小的电商平台是怎么一步步搭建起来的。对以前的文章感兴趣的朋友可以看这个，
本文大纲：
1.小型电商网站的架构
2.日志与监控系统的解决方案
3.构建数据库的主从架构
4.基于共享存储的图片服务器架构
5.移动M站建设
6.系统容量预估
7.缓存系统
一、小型电商网站的架构
刚从传统软件行业进入到电商企业时，觉得电商网站没有什么技术含量，也没有什么门槛，都是一些现有的东西堆积木似的堆出来罢了。然而，真正进入到这个行业之后，才发现并非如此。有人说过，好的架构，是演化出来的，电商网站的架构也是如此。现在好的电商网站，看似很复杂，很牛逼，其实也是从很小的架构，也是从没什么技术含量开始的。所以，架构的演化过程，就是在技术团队不断追求极致的过程。
今天就来总结小型电商网站的架构演进。一套电商系统最初期的架构，往往会采用一个比较典型的LAMP架构，前端加上Apache/PHP，后端是MySQL。这个算是比较流行的。不过，目前还有一套.net的技术架构，可能大家很少提到。很不幸，我就是在一个.net平台为基础的电商公司。所以，今天也是要总结.net平台的电商架构。
1技术架构
一般初期的电商网站，基本就几个业务子系统：网站前台、商家前台、系统管理后台、App、M站等。业务量也不是很大。所以，MVC+缓存+数据库基本就搞定了。
单就开发效率而言，.netMVC的技术架构不会比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为例，主库负责写数据、读数据。读库仅负责读数据。每次有写库操作，同步更新到读库。写库就一个，读库可以有多个，采用日志同步的方式实现主库和多个读库的数据同步。
1SQL Server 读写分离的配置
SQL Server提供了三种技术，可以用于主从架构之间的数据同步的实现：日志传送、事务复制和SQL 2012 中新增的功能Always On 技术。各自优劣，具体的大家自己去百度吧，这里提供网上的朋友的配置方式，仅供参考。
（图源：网络）
2C# 数据库读写操作
C#的请求数据库操作，单数据库和主从架构的数据库还是不一样的。主从架构的数据库，为了保证数据一致性，一般主库可读可写，从库只负责读，不负责写入。所以，实际C#在请求数据库时，要进行区别对待。
最简单的就是：配置两个数据库连接，然后在各个数据库调用的位置，区分读写请求相应的数据库服务器，如下图：
第二种解决方案就是判断SQL语句是写语句（Insert 、Update、Create、 Alter）还是读语句（Select）。
Demo下载：
（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 的方式访问：
五、移动M站建设
最近在一直在搞M站，也就是移动Web站点。由于是第一次，也遇到了很多问题，所以把最近了解到的东西总结一番。聊一聊什么是移动M站，以及它有什么作用和优势。
有人会问，M站和APP有什么不同？
APP直接在用户的移动设备上，曝光率相对较高。 而M站需打开浏览器，输入地址才能访问，所以曝光率相对较低。
M站的推广的渠道相比移动APP，渠道较多，方便追踪用户来源、流量入口等，方便以后的活动推广和数据分析。
M站用户无需安装，输入URL即可访问，而APP需要下载安装。
M站能够快速地通过数据分析，能快速得到用户的反馈，从而更容易根据统计数据分析和用户的需求来调整产品。
APP对用户更具粘性及用户体验也更好。
本文来自投稿，不代表重蔚自留地立场，如若转载，请注明出处https://www.cwhello.com/169681.html
如有侵犯您的合法权益请发邮件951076433@qq.com联系删除
