亿级别网站开发思路

浏览:1976 发布日期:2016/05/08 分类:技术分享 关键字: 分流,分布式,亿级别,网站开发
亿级别网站开发思路(欢迎大家补充,一个小细节都变得很重要):
1.网站目录采用独立分组策略,将固定的业务模型封装到指定的目录内。如登录模型单独放在 login 目录内(包括了 controller,model,view,conf,common子目录)。这样便于拆分,流量大的时候,将其放到其它服务器上,做专职的登录验证服务器用。其它,如会员中心、客服、商品分类一并处理。前期要做好 thinkphp 框架的路由规划,将 login.test.com 指向 登录服务器,member.test.com 指向会员中心服务器。

2.关系型数据库与 NoSQL 并用,关系型数据库前期做好垂直分割和水平分割的预案。NoSQL 中的数据做年-月分割,这样放 NoSQL 的硬盘,只要每年增加 2 块即可。

3.前端 js、css、html 尽量分离。html 只对数据进行描述,不做样式描述,即不含有 style 标签,所有样式都放在 .css 文件内。不做事件处理,即 html 文件中没 js 代码,所有对事件的处理都放入 .js 文件内。js 最好用 jQuery,因为写起来代码简单,便于理解。对 html 中出现的 data-* 这样的标签,最好用 jQuery 动态生成,即 $('#id').attr('data-type', 'settitle'); 这样描述,尽量减少 html 中的代码量,节省主站带宽、硬盘资源(主站配置一般较高,开支大)。
js 需要调用的数据,php 可以将其数组化,然后再将其 json_encode 成字符串,用 base64 编码一下,避免特殊字符的丢失。最后写入 html 中的隐藏域中。js 调用的
时候将其逆向成数组,再去调用。

然后将 js、css及相关的模板图片放到其它分流服务器上,css 与相关的模板图片必须放到相同服务器上,因为 css 中的 backgroud 属性可能引用模板图片。js 可以放到另外一台服务器上。这样用户浏览器在加载的时候,可以同时访问多台服务器,避免了单台服务器的 IO 瓶颈、带宽瓶颈。但要做备用服务器,避免主分流服务器宕机。

商品图片上传的时候,要做缩略图。原图过大的,可以压缩一下。然后按 年/月/商号 ID/唯一图片名称.jpg 方式规划,即 2016/5/1001/572b01e920336.jpg 这样的。
缩略图放到 SSD 阵列内(特点:价格高,容量小,IO 读写快)。原图放到普通硬盘阵列内(特点:价格低,容量大,IO 读写慢)。当用户浏览网页的时候展示缩略图,当点击放大按钮的时候,再加载原图。这样省很多带宽。每年只要增加 2 硬盘即可。

对于商品描述的内容,也可以在用户第一次访问的时候,生成 json,用 ftp 上传到内容分流服务器上,第二个用户访问的时候,直接给个 json 资源的链接即可。但 title、keyword、description 要写入 html 中,便于 seo 优化。

最后用 php 将 html,压缩生成静态缓存。js、css也要压缩后上传到对应的分流服务器上。

4.后台 多商家的后台分流策略可以模仿前台。只有管理员一人操作的后台,可以考虑宽松些,毕竟资源消耗可以忽略不计。

5.cdn 部署 只需要给主站加个 cdn 就可以了,用户访问主站的首页的时候,里面多数是二级域名,通过二级域名进行分流。然后用户访问不同的分流服务器。对于商品分类,如果某一子类数据过大,可以考虑用三级域名再次分流

6.总结:最后主站的 CMS 进化成了内容、资源的路由器。分站的 CMS 残化后,只包含框架和单一的业务模型。这样做的目的是可以随意整合服务器资源,比如:家用 PC,
ADSL 宽带接入,没有开放 80 端口,可以用其它端口,做图片分流,内容分流用。链接写入 html 或 js 中,反正用户也不会去手工输入资源的调用地址。他们一般只会
输入一级域名。如果你开公司,可以利用公司内部闲置的电脑资源当分流服务器用。程序员写代码又不费多少资源,装个 wamp 做个分流服务器用。也可以随意整合云服务器,甚至整合将来的量子计算机资源^_^。

7.问题:上面涉及的很多技术细节没有展开,可以自行思考(估计思考量巨大,我也一样,费了老劲)。
最佳答案
评论( 相关
后面还有条评论,点击查看>>