大型电子商务网站架构 逃离我推掉我的手 2022-09-21 13:28 176阅读 0赞 [大型电子商务网站架构之-前端优化][-] * # 1 前端优化必要性 # 随着互联网的发展，前端优化越来越被人们重视，在一个大型的大型电子商务网站技术架构中，前端架构一定是一项必不可少的工作，国内几个大型的互联网公司也有非常强大的前端技术人员。在业界享有名气淘宝UED团队就有好几十人。在浏览器访问一个网站时，有10%-20%的时间是花在下载HTML上面，有80%-90%时间是花在下载页面中所有组件上面。如果我们可以把后端时间缩短一半，整体响应时间只能减少5%-10%。然而我们关注前端，同样是其响应时间缩短一半，那整体性能能减少40%-45%。 **看些研究数据：** l Amazon 慢 0.1 s -> 1% 用户放弃交易 l Google 慢 0.4s -> 0.6% 放弃搜索 l Yahoo! 慢 0.4s -> 减少 5%-9% 的流量 l Bing 慢 2s -> 收入下降 4.3 % # 2 前端优化最佳实践 # 在前端发展了那么长时间，其优化经验也有很多值得借鉴，下面作简单介绍。 ## 2.1 14条优化军规 ## 1. 尽可能的减少HTTP请求数 2. 使用CDN 3. 添加Expires头(或者 Cache-control) 4. Gzip 组件 5. 把CSS样式放在页面的上方。 6. 将脚本放在底部(包括内联的) 7. 避免在CSS中使用Expressions 8. 将javascript和css独立成外部文件 9. 减少DNS查询 10. 压缩JavaScript和CSS文件 (包括内联的) 11. 避免跳转 12. 移除重复的脚本 13. 配置 ETags 14. 缓存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。如果自行开发，除非有强大团队，要不维护成本太高，而且功能不完善。 Prototype 惊艳，野性， 代码风格类Ruby，新手不易上手，文档缺乏 Jquery 乖巧 灵活 易用 Dojo 强大，复杂，笨重 它的设计初衷就是：不光只运行在浏览器的脚本环境中，甚至像pdf/rhino这些也拥有 脚本环境的地方也能使用 Yui 温顺，矫健，文档齐全，编码语法相对传统，封装的形式比较接近于Java Ext Ext: 野生，炫，侵入太强，适用于精英团队 ## 2.5 针对Content优化 ## 1. 组件延迟加载 不可见的组件: 非当前的Tab，隐藏的图片 附加组件：动画,拖动 2. 预加载组件 无条件的预加载(Google 首页的例子） 有条件的预加载（淘宝首页搜索提示功能的例子） 3. 减少DOM元素个数 元素越多，下载的数据越多，JS操作DOM速度越慢 4. 尽量少使用 iframe l 公共文件的重复加载 l 浏览器的消耗 ## 2.6 图片优化 ## l 优化图片 尝试使用PNG，png拥有gif所有功能，还支持alpha透明，文件比较小，所以尽可能使用png格式图片。 删除图片的元数据，例如photoshop的元数据，这样在一定程度上能减少图片大小而不影响图片质量。 l CSS sprites 可以把网站常用的小图片集合在一张图片中，通过Css定位到小图上面，从而减少http请求。 l 不要在HTML中缩放图片 <img width="100" height="100" src=“cat.jpg" /> # 3 怎么样才算足够快 # l 0.1秒 用户直接操作ui中对象的感觉极限。例如，用户直接选择表格的一列到该列高亮显示，或者反馈被选择的时间间隔。 l 1秒 用户随意在计算机指令空间操作而无需过度等等时间的感觉极限。0.2-1.0的时间延迟会被用户注意到，会让用感觉到计算机正在对指令进行处理中。等待的时间过长，会让用户失去流畅的体验。 l 10秒 用户专注于任务的极限，超过10秒的任何操作都要有一个进度指示器，以及有一个让用户中断操作，而且有清晰的标示方法。假设用户超过10秒后返回界面，他们将要重新适应。在实际工作中有些操作超过10秒是可以接受的，比如撤换操作任务。 换句话说js在执行如果超过0.1秒，会让人感觉到不平滑。如果超过1秒会让人感觉应用程序缓慢；超过10秒那么用户会非常沮丧。这些就是用于足够快的标准。 [大型电子商务网站架构之--分布式可扩展数据库架构][--] 近几年分布式成为热门的话题，也成为大型系统必备良药，而在数据库方面应用更加广泛。通过采用普通廉价的设备构建出高可用性和高扩展的集群目的。从而摆脱了大型设备的依赖，一个好的分布式数据库架构可以比较方便达到高可用性有可以达到向外扩展的能力。传统的数据库系统一般是通过高端设备，例如小型机或者高端存储来保证数据库完整性，或者通过增加内存cpu来提高数据库处理能力。这种集中式的的的数据库架构越来越不适合海里数据库处理，而且也得付出高额的费用。分布式的架构也就成了商家探索的技术。 **数据库集群** **oracle集群** Oracle RAC是业界最流行的产品。其架构的最大特点是共享存储架构（Shared-disk），整个RAC集群是建立在一个共享的存储设备之上的，节点之间采用 高速网络互连。在 Oracle RAC 环境中，每个 Oracle 数据块都被赋予一个（且只有一个）“主”Oracle RAC 节点。该 Oracle RAC 节点的全局缓存服务 (GCS) 负责管理对这些数据块集的访问。当其中一个 Oracle 节点需要访问某个 Oracle 数据块时，它必须首先与该数据块协商。然后，该主节点的 GCS 或者指示请求的 Oracle 节点从磁盘中获取该数据块，或者指示该Oracle 数据块的当前持有者将被请求的数据块发送到请求节点。Oracle 尝试跨所有 RAC 节点统一分发该数据块的所有权。在 Oracle RAC 环境中，数据块大致相等的所有节点都将被指定为主节点。（如果 Oracle RAC 节点数是 Oracle 数据块数的约数，则所有 RAC 节点都是具有同样数量的数据块的主节点。） ![439f0e01-54f8-3444-9f17-01dbce952e3f.jpg][] **mysql集群** MySQL cluster和Oracle RAC完全不同，它采用Shared-nothing架构。整个集群由管理节点(ndb\_mgmd)，处理节点(mysqld)和存储节点(ndbd)组 成，不存在一个共享的存储设备。MySQL cluster主要利用了NDB存储引擎来实现，NDB存储引擎是一个内存式存储引擎，要求数据必须全部加载到内存之中。数据被自动分布在集群中的不同存 储节点上，每个存储节点只保存完整数据的一个分片(fragment)。同时，用户可以设置同一份数据保存在多个不同的存储节点上，以保证单点故障不会造成数据丢失。 MySQL cluster的优点在于其是一个分布式的数据库集群，处理节点和存储节点都可以线性增加，整个集群没有单点故障，可用性和扩展性都可以做到很高，更适合 OLTP应用。但是它的问题在于：1.NDB存储引擎必须要求数据全部加载到内存之中，限制比较大，但是目前NDB新版本对此做了改进，允许只在内存中加 载索引数据，数据可以保存在磁盘上。2.目前的MySQL cluster的性能还不理想，因为数据是按照主键hash分布到不同的存储节点上，如果应用不是通过主键去获取数据的话，必须在所有的存储节点上扫描， 返回结果到处理节点上去处理。而且，写操作需要同时写多份数据到不同的存储节点上，对节点间的网络要求很高。 **分布式数据库拆分** **数据库分片** Sharding 不是一个某个特定数据库软件附属的功能，而是在具体技术细节之上的抽象处理，是水平扩展(Scale Out，亦或横向扩展、向外扩展)的解决方案，其主要目的是为突破单节点数据库服务器的 I/O 能力限制，解决数据库扩展性问题。 * 把热度高的数据划分开来，使用配置刚好的硬件，提高访问速度，增强用户体验 * 把不同的用户的数据根据用户的id放到不同的数据库中，不同用户对应的交易数据也跟着到不同的数据库；之后可以把交易完成和正在交易的数据库分开。 * 一个全国经济信息系统，可以按照不同地区把不同数据放到不同数据库中，随着时间增加数据也会越来越大，到时还可以工具年份在重新划分数据库。 * 一个大中型的电子商的电子商务网站一定会遇到数据量巨大的问题，可以根据用户对象或者使用和被使用的数据进行分片。这样避免了在一个库中数据膨胀而带来的瓶颈。 * 在数据库分片时最好分到不同的服务器中，或者不同的存储中，避免磁盘竞争 数据库分片存在比较大问题就是人查询或者统计涉及到跨库就比较麻烦。特别是join时如果涉及到多个节点，将非常困难，应该尽量避免。 ![d77f7645-d217-33b7-8bdf-72a8f9a4405d.jpg][] 数据库水平分片 **读写分离** 读写分离架构利用了数据库的复制技术，将读和写分布在不同的处理节点上，从而达到提高可用性和扩展性的目的。 读写分离简单的说是把对数据库读和写的操作分开对应不同的数据库服务器，这样能有效地减轻数据库压力，也能减轻io压力。主数据库提供写操作，从数据库提供读操作，其实在很多系统中，主要是读的操作。当主数据库进行写操作时，数据要同步到从的数据库，这样才能有效保证数据库完整性。**Quest SharePlex**就是比较牛的同步数据工具，听说比oracle本身的流复制还好，mysql也有自己的同步数据技术。mysql只要是通过二进制日志来复制数据。通过日志在从数据库重复主数据库的操作达到复制数据目的。这个复制比较好的就是通过异步方法，把数据同步到从数据库。 主数据库同步到从数据库后，从数据库一般由多台数据库组成这样才能达到减轻压力的目的。读的操作怎么样分配到从数据库上？应该根据服务器的压力把读的操作分配到服务器，而不是简单的随机分配。mysql提供了MySQL-Proxy实现读写分离操作。不过MySQL-Proxy好像很久不更新了。oracle可以通过F5有效分配读从数据库的压力。 上面说的数据库同步复制，都是在从同一种数据库中，如果我要把oracle的数据同步到mysql中，其实要实现这种方案的理由很简单，mysql免费，oracle太贵。好像**Quest SharePlex**也实现不了改功能吧。好像现在市面还没有这个工具吧。那样应该怎么实现数据同步？其实我们可以考虑自己开发一套同步数据组件，通过消息，实现异步复制数据。其实这个实现起来要考虑很多方面问题，高并发的问题，失败记录等。其实这种方法也可以同步数据到**memcache**中。听说oracle的Stream也能实现，不过没有试过。 ![25f77c41-14fc-3508-8ca9-1b8a07a40e88.jpg][] 上图是ebay读写分离的结构图，通过Share Plex 近乎实时的复制数据到其他数据库节点，再通过F5特定的模块检查数据库状态，并进行负载均衡，IO 成功的做到了分布，读写分离，而且极大的提高了可用性。目前读写分离技术比较多，比较有名的为amoeba，有兴趣的同学可以研究下。 **数据库缓存** 读写分离现在应用非常广泛，特别是时国内外大型网站，都使用的非常多，很多都是自己研发缓存系统，淘宝还开源了Tair系统，有兴趣的可以研究下。比较有名的是memcached使用memcached最好的可能算facebook了。通过memcached分担读的操作，把常用的对象数据存储到memcached中，当有读操作过来时先访问memcached如果memcached没有该数据再从数据库获取，同时把数据放到memcached中，下次访问就可以直接访问memcached了。 ![402a9a0d-3509-3cdc-960f-07ad4fbb6809.jpg][] 有一次在和一个朋友聊天时他们正在着手在线文档系统架构设计，由于文档访问压力非常大，每次请求数据库也非常大，由于大量的的文档数据在服务端和客户端传输，会经常造成网络堵塞。我建议他可以把文档分片，减少一次性大文件传输。再根据文档热度把一些文档保持到缓存中。其实文档也好，数据库也好，很多方法只要根据业务要求也可以达到异曲同工的之效。 [-]: http://liriguang.iteye.com/blog/723870 [--]: http://liriguang.iteye.com/blog/714728 [439f0e01-54f8-3444-9f17-01dbce952e3f.jpg]: /images/20220721/f69e2ae164864f94b53f9f375727d69f.png [d77f7645-d217-33b7-8bdf-72a8f9a4405d.jpg]: /images/20220721/1af62a0eb2304ebcbc295105443951ab.png [25f77c41-14fc-3508-8ca9-1b8a07a40e88.jpg]: /images/20220721/b08a44a6db684fd098411cfba879e3e8.png [402a9a0d-3509-3cdc-960f-07ad4fbb6809.jpg]: /images/20220721/15d152baee9a4987ac80ecee198eeea0.png
还没有评论，来说两句吧...