博客分类：
1 前端优化必要性
随着互联网的发展，前端优化越来越被人们重视，在一个大型的大型电子商务网站技术架构中，前端架构一定是一项必不可少的工作，国内几个大型的互联网公司也有非常强大的前端技术人员。在业界享有名气淘宝UED团队就有好几十人。在浏览器访问一个网站时，有10%-20%的时间是花在下载HTML上面，有80%-90%时间是花在下载页面中所有组件上面。如果我们可以把后端时间缩短一半，整体响应时间只能减少5%-10%。然而我们关注前端，同样是其响应时间缩短一半，那整体性能能减少40%-45%。
看些研究数据：
Amazon 慢 0.1 s -& 1% 用户放弃交易
Google 慢 0.4s -&
0.6% 放弃搜索
Yahoo! 慢 0.4s -&
减少 5%-9% 的流量
Bing 慢 2s -&
收入下降 4.3 %
2 前端优化最佳实践
在前端发展了那么长时间，其优化经验也有很多值得借鉴，下面作简单介绍。
2.1 14条优化军规
尽可能的减少HTTP请求数
添加Expires头(或者 Cache-control)
把CSS样式放在页面的上方。
将脚本放在底部(包括内联的)
避免在CSS中使用Expressions
将javascript和css独立成外部文件
减少DNS查询
压缩JavaScript和CSS文件 (包括内联的)
移除重复的脚本
配置 ETags
缓存Ajax请求
以上内容在网上都有介绍，在此不作多说，有兴趣的同学可以google一把。
2.2 拆分初始化负载
Ajax和动态HTML的日益普及网页上面的js和css也变得非常庞大，web程序也变得像桌面程序一样，很大一部分代码不会在启动时候使用，而是采取插件式架构，允许动态加载模块。
在一个大型结构复杂的网页上面，为了不影响用户体验，可以把js分为两部分，一部分是渲染页面必须的，剩下是一部分。这样也在一定程度上面提高用户体验，给用户第一时间看到完整的页面。再寻找哪些js可以被拆分，可以通过一些辅助工具来判断，firebug就是一个非常好的工具，可以通过查看哪些函数onload之前未被使用。通过判断可以把其中一部分拆分出来，但是有些不开始拆分，例如页面的错误处理和业务判断等js是不能拆分的，如果要拆分合理必将是一项严谨的工作。
2.3 无阻塞加载脚本
Js有两种方式被包含在页面中，一种是行内脚本，一种是外部脚本。对外面脚本浏览器在下载js或者执行脚本的同时不会下载其他内容，有时候这种情况是必要，但是却会影响页面其他展示，理想情况是不堵塞其他内容下载的方式来加载js。目前也有对应的技术，用得比较多的是XHR Eval，xhr注入，script ifram，script dom element，script defer document.write script Tag。具体使用情况要根据环境来定。
由于使用外部脚本，有人可能会想到把全部使用内部脚本，这种做法不可取，这样会增加页面大小，而且浏览器不会缓存js，少数内部脚本是可取的。但是大多情况下使用外部脚本，这样无论在团队开发，还是版本控制还会带来很大好处。
2.4 使用现成组件
现成开源的js组件很多，可以根据熟悉程度和业务应用性使用，jquery，yui，ext，dojo。如果自行开发，除非有强大团队，要不维护成本太高，而且功能不完善。
惊艳，野性， 代码风格类Ruby，新手不易上手，文档缺乏
乖巧 灵活 易用
强大，复杂，笨重
它的设计初衷就是：不光只运行在浏览器的脚本环境中，甚至像pdf/rhino这些也拥有
脚本环境的地方也能使用
温顺，矫健，文档齐全，编码语法相对传统，封装的形式比较接近于Java
野生，炫，侵入太强，适用于精英团队
2.5 针对Content优化
组件延迟加载
不可见的组件: 非当前的Tab，隐藏的图片
附加组件：动画,拖动
预加载组件
无条件的预加载(Google 首页的例子）
有条件的预加载（淘宝首页搜索提示功能的例子）
减少DOM元素个数
元素越多，下载的数据越多，JS操作DOM速度越慢
尽量少使用 iframe
公共文件的重复加载
浏览器的消耗
2.6 图片优化
尝试使用PNG，png拥有gif所有功能，还支持alpha透明，文件比较小，所以尽可能使用png格式图片。
删除图片的元数据，例如photoshop的元数据，这样在一定程度上能减少图片大小而不影响图片质量。
CSS sprites
可以把网站常用的小图片集合在一张图片中，通过Css定位到小图上面，从而减少http请求。
不要在HTML中缩放图片
width="100" height="100" src=“cat.jpg" /&
怎么样才算足够快
用户直接操作ui中对象的感觉极限。例如，用户直接选择表格的一列到该列高亮显示，或者反馈被选择的时间间隔。
用户随意在计算机指令空间操作而无需过度等等时间的感觉极限。0.2-1.0的时间延迟会被用户注意到，会让用感觉到计算机正在对指令进行处理中。等待的时间过长，会让用户失去流畅的体验。
用户专注于任务的极限，超过10秒的任何操作都要有一个进度指示器，以及有一个让用户中断操作，而且有清晰的标示方法。假设用户超过10秒后返回界面，他们将要重新适应。在实际工作中有些操作超过10秒是可以接受的，比如撤换操作任务。
换句话说js在执行如果超过0.1秒，会让人感觉到不平滑。如果超过1秒会让人感觉应用程序缓慢；超过10秒那么用户会非常沮丧。这些就是用于足够快的标准。
16 顶15 踩
浏览: 198436 次
来自: 深圳
lirig 写道davos 写道其实我想知道的是我们的应用程序 ...
楼主写的不错，值得学习。我有个问题请教一 ...
zyz251314 写道soleghost 写道垂直分库--& ...
soleghost 写道垂直分库--&水平分库--&gt ...
写的很好，受益匪浅那，我正准备做个电商网站，正在做全面考 ...如何一步一步用DDD设计一个电商网站（二）—— 项目架构
来源：博客园


一、前言
上一篇我们讲了DDD的核心概念（），并且设计了我们的上下文映射图，那么接下来就准备开始立项了，本篇文章的部分知识点可能对一部分人来说比较基础，可以选择性的阅读。
在这之前我们平常用的最多的应该就是3层架构了，这里也不展开描述了，大家都是在3层的陪伴下一路走来的~
DDD所使用的传统分层架构是松散分层，也就是上层可以访问任意层级的下层，而不是仅限于当前层的下一层，这是有别于3层架构的。如下面2张图的区别图：
　　　　　　
　　　　　　　　　　　　　　　　　　　　【图1】
　　
　　　　　　　　　　　　　　　　　　　　【图2】
Application：这层的职责是对接收到的数据做一些非业务性验证，事务的控制，最重要的是协调多个聚合之间的操作。这里应该可以清晰的表达出整个操作所做的事情，并且与通用语言是一致的。
Domain：这一层是DDD设计的核心，这里不但需要精确合理的表达出通用语言的每一个细节，另外如何把对象合理的定义为聚合、实体、值对象也是重中之重。这里不但关系着整个项目的复杂度，也是战术建模的体现，任何的一行代码都是对业务的准确定义，应该是恰到好处。一个清晰简洁的战术建模才可以应对后续的快速变化。
Infrastructure：这里是辅助性的一层，也是整个项目的基础。好比这里存放着一砖一瓦，最终建造什么模样的高楼在于用它的地方。主要包括，仓储的实现（我们存放数据的地方）、一些通用的支撑性类库。
 

二、六边形架构
在[Vaughn Vernon]《实现领域驱动设计》一书中多次提到对DDD主张六边形架构的概念，六边形架构对于保证限界上下文内的领域概念的清晰性有着重要的作用，那么什么是六边形架构，如下图3（摘自[Vaughn Vernon]《实现领域驱动设计》一书）。
　　
　　　　　　　　　　　　　　　　　　　　　　【图3】

在当今越来越提倡开放合作的大环境下，引用的多样化的Service，和在自身系统达到一定规模之后的分布式治理，越来越需要通过协作进行工作，那么如何提升协作的效率变得越来越重要。提高各个应用程序的自治性，是一种有效提升协作能力的手段。从上图中看出为了保证领域模型所在的应用程序的干净简洁和自治性，各种适配器作为"防腐层（在上篇中有提到）"在整个程序的最外层保护着当前的“界限上下文（在上篇中有提到）”不受外部入侵。
所以在我们的整个设计中需要注意对涉及到外部系统交互的地方的抽象，通过面向接口、依赖注入等方式做到外部的变化对自身系统的影响最小化。
 

三、终于开始建项目了
按照之前的这些描述，我们终于初步建立了我们的解决方案。如下图4：
　　
　　　　　　　　　　　　　　　　【图4】

这里把每个项目的职责大致说一下。
Mall：负责我们的电商网站的界面处理和用户的数据录入
Mall.Application：按模块分别定义不同的ApplicationService来讲述每一个操作下的“故事”。
Mall.Application.DomainEventSubscribers：所有的领域事件订阅者。
Mall.Domain：这里存放着战术建模的结晶，Entity、Aggregate、ValueObject。（下面会具体讲述下）
Mall.Domain.Events：所有的领域事件，这层也可以合并到Domain中，给它新建一个文件夹。
Mall.Domain.IRepositories：所有的仓储（资源库）接口。类似于三层中的IDAL。
Mall.DomainService：领域服务，存放着那些不适合放在聚合/值对象上的无状态的操作方法，用于实现特定某个领域的任务。
Mall.Infrastructure：存放着一些通用类库
Mall.Infrastructure.Repositories：所有仓储（资源库）的实现。
Mall.Infrastructure.Translators：翻译层，也就是与外部系统沟通的桥梁，主要的职责就是做好“反腐层”的重任。
 

四、DDD中的3个臭皮匠
这里的3个臭皮匠其实就是：Entity、ValueObject、Aggregate。我们要提炼出业务中的精华，合理的抽象为这3个概念，并且这种抽象是需随着领域里的概念变化而变化的。这3者的结合运用会让我们的项目活起来，这是DDD的核心。这里再把这3个概念重新梳理一下。
Entity（实体）： 每个实体是唯一的，并且可以相当长的一段时间内持续地变化。我们可以对实体做多次修改，故一个实体对象可能和它先前的状态大不相同。但是，由于它们拥有相同的身份标识，他们依然是同一个实体。
ValueObject（值对象）：值对象用于度量和描述事物，当你只关心某个对象的属性时，该对象便可作为一个值对象。实体与值对象的区别在于唯一的身份标识和可变性。
Aggregate（聚合）：聚合类是实体的升级，是由一组与生俱来就密切相关实体和值对象组合而成的，这整个组合的最上层实体就是聚合。
 

五、CQRS（Command Query Responsibility Segregation）
说到DDD必然要提一下CQRS，我认为CQRS和DDD的关系就像咖啡和牛奶，给大型系统的构建提供了一剂良药，它生于读写分离，具有高吞吐量、高伸缩性等特点，值得我们为之付出一些代价。但是CQRS的使用会使整个数据持久化和查询的链路拉长，并且工作量也会比简单的读写一体化大的多，所以需要对项目做出合理的考量来决定是否使用。
当我们需要把某个复杂的聚合修改之后写入到数据库的时候，要保证N张表的数据被同时修改成功，整个事务的周期必然会加长。而且当我们需要显示来自不同聚合类型与实例的数据时，我们的SQL必然包含N多的join。领域越复杂这种情况越发常见。
CQRS需要和事件源结合使用，对数据的修改操作只是往事件源里增加一条修改后的结果记录（类似于我们的源码控制软件的log），并不会直接把修改后的对象持久化到数据库。这样能够大大提高数据修改的速度，并且对于查询操作的实现方式就比较多样化了。大致列举了以下4种方式：
1.还是使用单个数据库，每次领域对象的获取都需要根据事件源中的事件集合做重建，得到当前的最新的数据返回。这只是编码设计上的读写分离
2.拆分为读库和写库，实现方式同1
3.拆分为读库和写库，并且针对读库做专门的查询数据冗余，异步的通过事件源来修改查询数据，可以结合merge commit。
4.在3的基础上做读库的负载均衡
这4种方式复杂度各不相同，可以结合实际项目的复杂度择优选择，其中最关键的一条便是是否存在大量的列表类数据展示，如果是那么1和2便就不适合了。在以上的方式之外可以结合其他的数据存储一起使用，如缓存，NoSql，然而这只需要订阅所有的命令事件即可实现。
 

六、结语
本篇主要介绍了项目的分层架构、每层的职责和里面存放什么样子的类。限于非我们这个系列的核心主题，所以都没有发散出去做更加具体形象的描述，希望大家可以边结合[Vaughn Vernon]《实现领域驱动设计》一书的阅读跟着我做实际的编码来加深对DDD的理解。跳出根深蒂固的三层思想是痛苦的，但是我认为只要坚持下去，DDD会让你看见一片世外桃源，到那时会觉得我们的付出都是值得的。并且DDD思想的运用可大可小，小到类的设计，大到复杂项目之间的构架，都会给你提供帮助。
 
作者：出处：
免责声明：本站部分内容、图片、文字、视频等来自于互联网，仅供大家学习与交流。相关内容如涉嫌侵犯您的知识产权或其他合法权益，请向本站发送有效通知，我们会及时处理。反馈邮箱&&&&。
学生服务号
在线咨询，奖学金返现，名师点评，等你来互动大型电商网站架构演进之路（一） - 简书
大型电商网站架构演进之路（一）
现在电商网站越来越多，除了阿里、京东、唯品会、聚美优品这种耳熟能详的巨头还有很多垂直领域的，比如找钢网、酒仙网、本来生活、Roseonly等，这些网站的主流功能基本类似，无非是完成整个交易流程，但是由于面向的用户量级不一样，所处的发展阶段不一样，背后的实现方式也是有很大的差别，下面来给大家聊聊大型电商的架构演变之路。大型电商网站，已经不只是WEB
早些年提起电商网站，人们会说不就是一个web网站吗，跟BBS基本类似，网上还有很多开源的版本，最出名的应该就是EShop和Shopex了，十几兆的源码拿过来，分分钟就自己可以搭建一个电商网站。但是我想说现在的大型电商网站已经不止是 HTML、Apache、IIS、Lighttpd、JAVA、C/C++、PHP、MySQL、Mssql、Oracle。。。还有跨进程通信、数据缓存、磁盘ＩＯ优化、大容量存储、分布式计算、负载均衡、网络安排、IDC建设。。。架构演变之一：物理分离webserver与数据库
上文提到最简单的电商网站一台机器就可以搞定，类似ecshop，webserver与数据库放在一台机器上一样可以搭起个电商网站，从外观看还是挺像模像样的，笔者曾用ecshop给朋友搭建过电商网站，效果如下从外观看绝对想不到这是一台机器搭建起来的.
上面的这个网站尽管样式很漂亮、该有的功能也都有了，但是实践中你会发现，自己玩玩还行，真的投入生产恐怕噩梦就来了，随便搞个活动，当同时有几十人或者上百人来下单的时候，你就会发现有人开始抱怨网站打开不，或者响应很慢了。这个时候你能做的就是重启机器，然后起来后没几分钟网站再挂掉，然后你再重启机器。。。
因为一台机器的CPU、内存、硬盘IO读取都是有上限的，而且很容易就达到这种上限，当CPU或者内存或者硬盘任何一个达到上限的时候就是用户崩溃你要重启机器的时候了，那面对这种情况应该如何优化呢？下面来介绍演变的第一步，webserver与数据库分离，既然一台机器有瓶颈那我们就想办法部署在多台机器上，最常用的方法就是把webserver与数据库进行分离，分别部署在不同的机器上，进行物理的分离。通常将webserver部署在一台机器，数据库部署在另外一台机器上，这种演进方式比最初的单台机器扩展性稍微好些，性能至少可以翻一倍。架构演变之二：增加页面缓存
按照上面的方法将webserver与数据库分离后，你的网站性能会提升些，但还不足以让你高枕无忧，用户稍微再多一点，估计PV在万级的时候，你将面临的挑战是数据库压力大，连接数多，响应比较慢。这个时候可以优化的方案是增加页面缓存，因为电商上有些页面相对比较静态，例如一些活动页，这些页面如果也请求到webserver，再到底层数据库就是比较浪费资源了，这种页面是可以进行缓存起来的，不需要耗费后面网站的资源，前端页面缓存的方式有很多，比较常用的是squid反向代理。
squid反向代理的好处是可以降低web服务器的负载，加速客户端浏览。代理可以缓存一些web的页面，降低web服务器的访问量，所以可以降低web服务器的负载, web服务器同时处理的请求数少了，响应时间自然就快了；同时代理也缓存了一些页面，可以直接返给客户端。架构演变之三：页面片段缓存，小数据量异步请求
有了squid的反向代理，性能可以有一定幅度的提升，但是电商的纯静态页面还是比较少的，单纯通过squid缓存技术并不能解决问题，电商中请求量最大的是活动页和商详，这两个地方都不是纯静态页面，商品的价格、促销、库存都要实时或者准实时展示，如果整个页面缓存下来会存在用户看到的价格跟实际的价格不一致，针对这种情况，我们需要把一个页面再分解下，例如商详，主图、文描这种都是基本固定的，价格、促销、库存是实时在变化的，所有比较好的方案是将主图、文描这种基本不变化的缓存下来，价格、促销、库存通过ajax异步读取。架构演变之四：数据缓存
页面缓存，异步读取后，网站下一步遇到的瓶颈会是在哪里呢？DB、DB还是DB，每一次的异步请求，基本都要把请求打到DB这一层，商品的最新价格要从DB读取，商品的最新库存数量要从DB读取，这时候DB的读取速度就是整个网站的瓶颈所在，那么如何解决这个问题呢？ 缓存、缓存、还是缓存。将不是经常变动的数据进行缓存，常用的缓存方式redis或者memcache都可以，如何使用缓存，看似简单其实有很多学问在里面，这里只提几个关键的点，大家可以自己思考下，使用缓存的时候需要考虑的因素有：什么样的数据适合缓存？是不是DB所有的数据都有必要缓存？如何保持缓存与DB的数据一致性？采用本机缓存还是网络缓存？本机缓存又分进程级缓存还是共享内存？如何提高缓存的命中率？缓存需不需要持久化？缓存的淘汰机制怎样选择？关于缓存的使用后面找时间单独开篇介绍下。增加了数据缓存后，这种方式性能可以有比较大的提升，支持个几十万至百万左右的PV应该是不成问题的。目前市面上的中小型的电商网站应该大部分采用这种架构，这种架构基本已经可以支持中小型电商的性能要求。下一篇将介绍国内中大型电商网站的架构，类似唯品会、聚美优品，京东、淘宝，敬请期待。
主要介绍电商相关产品、技术文章，欢迎跟有兴趣的朋友多多交流本文大纲：
1.&小型电商网站的架构
2.&日志与监控系统的解决方案
3.&构建数据库的主从架构
4.&基于共享存储的图片服务器架构
5.&移动M站建设
6.&系统容量预估
7.&缓存系统
一、小型电商网站的架构
刚从传统软件行业进入到电商企业时，觉得电商网站没有什么技术含量，也没有什么门槛，都是一些现有的东西堆积木似的堆出来罢了。然而，真正进入到这个行业之后，才发现并非如此。有人说过，好的架构，是演化出来的，电商网站的架构也是如此。现在好的电商网站，看似很复杂，很牛逼，其实也是从很小的架构，也是从没什么技术含量开始的。所以，架构的演化过程，就是在技术团队不断追求极致的过程。
今天就来总结小型电商网站的架构演进。一套电商系统最初期的架构，往往会采用一个比较典型的LAMP架构，前端加上Apache/PHP，后端是MySQL。这个算是比较流行的。不过，目前还有一套.net的技术架构，可能大家很少提到。很不幸，我就是在一个.net平台为基础的电商公司。所以，今天也是要总结.net&平台的电商架构。
一般初期的电商网站，基本就几个业务子系统：网站前台、商家前台、系统管理后台、App、M站等。业务量也不是很大。所以，MVC&+&缓存&+&数据库基本就搞定了。
单就开发效率而言，.net&MVC&的技术架构不会比LAMP开发速度慢。所以，一些企业，为了快速推出自己的电商平台，也会采用.net&架构。
上图为基础架构层面。这是一个很简单的基础架构。
前端网站和M站，考虑到访问量和系统的可用性，基本会采用分布式部署。通过代理服务器进行请求分发。
其它的业务子系统，像商家前台和管理系统，基本上都是单机或是主从部署。
各个DB&，Redis&服务和文件和图片服务，搜索引擎Solr服务等，采用主从部署。
整个系统架构里面，还有一个比较重要的组成部分，那就是监控系统。例如：流量监控、硬件监控、系统性能监控等， 还有就是对某个页面进行监控，设置页面的其中一块进行监控等。它是提高整个平台可用性的一个重要手段。多平台、多个维度的监控，能够确保系统的可用性。一旦出现异常，特别在硬件或者性能方面出现异常，监控系统也能立刻发出警告，这样也好防范于未然。
总而言之，一个好的系统架构应该从扩展性、安全性、性能和可靠性来考虑。罗马不是一天建成的，架构适合就行，可以先行之而后优。通过渐进演化的过程，逐步让系统越来越完善。
二、日志与监控系统的解决方案
监控系统主要用于服务器集群的资源和性能监控，以及应用异常、性能监控、日志管理等多维度的性能监控分析。一个完善的监控系统和日志系统对于一个系统的重要性不必多说。总之，只有实时了解各系统的状态，才能保证各系统的稳定。
如上图所示，监控平台监控的范围很广，从服务器性能及资源，到应用系统的监控。每个公司都有特定的平台统一监控的需求及解决方案，但监控平台的任务和作用基本是一致的。
日志是监视程序运行的一种重要的方式，主要有两个目的：1.bug的及时发现和定位；2.显示程序运行状态。
正确详细的日志记录能够快速的定位问题。同样，通过查看日志，可以看出程序正在做什么，是不是按预期的设计在执行，所以记录下程序的运行状态是必要的。这里将日志分为两种：1.异常日志；2.运行日志。
我们主要是使用log4net，将各个系统的日志，持久化记录到数据库或者文件中，以方便后续的系统异常监控和性能分析。如何集成log4net，这里不多说。
日志记录的几个原则：
日志级别一定要区分清楚，哪些属于error、warning、info等。
记录错误的位置。如果是分层系统，一定要在某个层统一处理，例如我们的MVC架构，都是在各个Action中Catch异常并处理，而业务层和数据库层这些地方的异常，都是Catch到异常后，往上一层抛。
日志信息清晰准确有意义，日志尽量详细点，以方便处理。应该记录相关系统、模块、时间、操作人、堆栈信息等。方便后续处理。
监控系统是一个复杂的系统平台，目前有很多的开源产品和平台。不过我们平台小，监控任务和需求少，所以基本都是自己开发。主要有这五个方面：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 技术。各自优劣，具体的大家自己去百度吧，这里提供网上的朋友的配置方式，仅供参考。
日志传送：SQL Server 2008 R2 主从数据库同步
（链接：）
事务复制：SQL Server 复制：事务发布
（链接：）
（图源：网络）
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站点（）将该共享目录通过Web站点发布出去。这样其它的应用就能访问到相关图片。
所以，各应用将文件上传到共享目录
&&&&//保存原图//完整的地址：\\192.168.1.200\lib\\10\IMG\4ugvvt6m9gdu.jpgrelativePath = relativeDir + fileName + imageE
&&&&&&&var absolutePath = ConfigHelper.SharePath + relativeP
&&&&&&&fileData.SaveAs(absolutePath); &&&&&&&&&&&&
上传成功后，可直接通过web 的方式访问：
/lib//10/IMG/4ugvvt6m9gdu.jpg
五、移动M站建设
最近在一直在搞M站，也就是移动Web站点。由于是第一次，也遇到了很多问题，所以把最近了解到的东西总结一番。聊一聊什么是移动M站，以及它有什么作用和优势。
有人会问，M站和APP有什么不同？
APP直接在用户的移动设备上，曝光率相对较高。 而M站需打开浏览器，输入地址才能访问，所以曝光率相对较低。
M站的推广的渠道相比移动APP，渠道较多，方便追踪用户来源、流量入口等，方便以后的活动推广和数据分析。
M站用户无需安装，输入URL即可访问，而APP需要下载安装。
M站能够快速地通过数据分析，能快速得到用户的反馈，从而更容易根据统计数据分析和用户的需求来调整产品。
APP对用户更具粘性及用户体验也更好。
M站对于营销推广活动非常方便，转发分享方便快捷。
M站更新迭代产品速度和响应产品调整非常快，随时发布，而APP需要审核时间。
M站跨平台，无需开发安卓和iOS版，只需有浏览器即可。&&&&&
所以， 我觉得，M站和客户端是相辅相成的。M站的及时性和快捷性，是APP无法比拟的。而APP的用户体验，则是M站无法做到的。目前来说两者是不可能被对方完全替代的，在互联网营销大行其道的今天，M站也越来越重要。营销活动大多以H5页面的形式展示和传播。通过M站的营销和推广，从而又促进APP的使用和推广。
目前，移动M站有倾向APP的趋势。M站会越来越像个APP，使得M站也越来越重要。而且，很多APP的展示效果，在原生代码无法实现的时候，嵌套移动H5页面也是一个很好的选择。
下面介绍几个移动M站建设的要点：
51Degrees号称是目前最快、最准确的设备检测的解决方案。它是一个免费开源的.NET移动应用开发组件，可以用来检测移动设备和浏览器。甚至可以获取屏幕尺寸、输入法、加上制造商和型号信息等。从而可以选择性地被定向到为移动设备而设计的内容。由于拥有精确的移动设备的数据，所以几乎支持所有的智能手机，平板电脑等移动设备。
其实说白了，51Degree的作用就是识别客户端的设备。PC浏览器访问，就跳转到PC站，手机浏览器访问就跳转到M站。从而达到更好的用户体验。
如何将51Degree加入到现有网站？
移动Web和传统的Web其实并没有本质的区别。说白了还是一个Web站点，使用的技术都是Html+CSS+JS。不同的是，只不过目前在Html5的大趋势下，将Html5加入到了移动M站，使得M站更像个轻APP。
3Bootstrap
Bootstrap就不多说了，网上有很多Bootstrap的资料。它最大的优势应该就是非常流行，非常容易上手。如果缺少专业的设计或美工，那么Bootstrap是一个比较好的选择。他的用法极其简单，几乎没什么学习成本，绝对是快速开发的利器。
官网：Github：
移动M站的URL要尽量和PC相同，这是可以避免同一URL在PC站可以显示，但是在手机上打开却是404；
M站写单独的TDK。
六、系统容量预估
电商公司的朋友，这样的场景是否似曾相识：
运营和产品神秘兮兮的跑过来问：我们晚上要做搞个促销，服务器能抗得住么？如果扛不住，需要加多少台机器？
于是，技术一脸懵逼。
其实这些都是系统容量预估的问题，容量预估是架构师必备的技能之一。所谓，容量预估其实说白了就是系统在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。一般来说，生产系统不会跑满到极限的，这样容易影响服务器的寿命和性能，单机线上允许跑到QPS=960。
扩展说一句，通过压力测试，已经知道Web层是瓶颈，则可针对Web相关的方面做一些调整优化，以提高Web服务器的单机QPS 。
还有压力测试工作中，一般是以具体业务的角度进行压力测试，关心的是某个具体业务的并发量和QPS。
5）回答最开始那两个问题　
需要的机器=峰值QPS/单机极限QPS
好了，上述已经得到了峰值QPS是5000，单机极限QPS是1000，线上部署了3台服务器：
服务器能抗住么？ -& 峰值5000，单机1000，线上3台，扛不住
如果扛不住，需要加多少台机器？ -& 需要额外2台，提前预留1台更好，给3台保险
需要注意的是，以上都是计算单个服务器或是单个集群的容量。实际生产环境是由Web、消息队列、缓存、数据库等等一系列组成的复杂集群。在分布式系统中，任何节点出现瓶颈，都有可能导致雪崩效应，最后导致整个集群垮掉&（“雪崩效应”指的是系统中一个小问题会逐渐扩大，最后造成整个集群宕机）。
所以，要了解规划整个平台的容量，就必须计算出每一个节点的容量。找出任何可能出现的瓶颈所在。
七、缓存系统
对于一个电商系统，缓存是重要组成部分，而提升系统性能的主要方式之一也是缓存。它可以挡掉大部分的数据库访问的冲击，如果没有它，系统很可能会因为数据库不可用导致整个系统崩溃。
但缓存带来了另外一些棘手的问题： 数据的一致性和实时性。例如，数据库中的数据状态已经改变，但在页面上看到的仍然是缓存的旧值，直到缓冲时间失效之后，才能重新更新缓存。这个问题怎么解决？
还有就是缓存数据如果没有失效的话，是会一直保持在内存中的，对服务器的内存也是负担，那么，什么数据可以放缓存，什么数据不可以，这是系统设计之初必须考虑的问题。
什么数据可以放缓存？
不需要实时更新但是又极其消耗数据库的数据。比如网站首页的商品销售的排行榜，热搜商品等等，这些数据基本上都是一天统计一次，用户不会关注其是否是实时的。
需要实时更新，但是数据更新的频率不高的数据。
每次获取这些数据都经过复杂的处理逻辑，比如生成报表。
什么数据不应该使用缓存？
实际上，在电商系统中，大部分数据都是可以缓存的，不能使用缓存的数据很少。这类数据包括涉及到钱、密钥、业务关键性核心数据等。总之，如果你发现，系统里面的大部分数据都不能使用缓存，这说明架构本身出了问题。
如何解决一致性和实时性的问题？
保证一致性和实时性的办法就是：一旦数据库更新了，就必须把原来的缓存更新。
说一说我们的缓存方案：我们目前的缓存系统：Redis（主从）+ RabbitMQ + 缓存清理服务组成，具体如下图：
缓存清理作业订阅RabbitMQ消息队列，一有数据更新进入队列，就将数据重新更新到Redis缓存服务器。
当然，有些朋友的方案，是数据库更新完成之后，立马去更新相关缓存数据。这样就不需要MQ和缓存清理作业。不过，这同时也增加了系统的耦合性。具体得看自己的业务场景和平台大小。
原文地址：&&
阅读(...) 评论()