个人网站架构设计(二)

昨天对网站的架构做了一个简要的分析,有些人不太理解,有了 NodeJS 还要 php 干啥?我推荐了几篇文章给这位童鞋看了:

如果是一个很小的网站,是用那么多层来处理请求和响应,确实是冗余的,不过我打算将这个网站设计成一个实时平台,这个平台中包含了很多很多的通信模块,所有后端选用
NodeJS 作为 I/O 处理器,这是可以理解的。php
用于通信,连接消耗大,而且不方便并行处理,效率很低。在网络通信和I/O处理上,NodeJS是很优秀的工具。

1. 小小网站,为啥我要如此看重后端

其实最主要的原因是,我买的主机配置很低。呵呵,是的,昨天很多朋友在留言里都提到了购买云主机/VPS相关的东西。今天我也是花了不少时间在各个群里请教,并且也访问、对比了一些云主机供应商的网站。之前在
V2ex 上看到了不少相关的帖子,今天进去翻,没翻到之前点过赞的贴。过程就不多说了,开始打算买个国外的主机,不用备案~ 后来嫌麻烦,买了个阿里云服务器:

CPU: 1核
内存: 512MB
数据盘: 40G
带宽: 1Mbps

买一年省俩月的钱,总共是七百多。选用的 Ubuntu 12.04,
64位系统。不过呢,我并没有一次性买一年的,先花几十块钱买了一个月,试用,反正以后续费还是原价(不像域名那样坑爹,续费就涨价)。域名我是一次性买的十年的,55/年,这东西不贵,多买几年,省事儿。然后进入阿里云的流程,正在备案中...

回到重点,为啥看重后端,看到上面的配置,相比大家也知道了,搞一个实时通信的网站,每个连接后端都需要内存来处理,而且这个内存在链接断开之前是不会释放的(socket连接),目测同时在线超过30个人,系统就要卡住了。内存是一个很大的瓶颈,然后就是带宽了,1M真的很低。其实买个配置高点的主机,一年也就一两千,这次故意买个最低配置是为了让自己培养珍惜流量意识,希望编程可以考虑到每个
byte 的消耗,等这种意识(或者技术)养成了,再提高主机的配置。

第二个原因就是熟悉后端,数据库方面的处理一直是自己的弱项,如果不试着提高下,以后工作中遇到坎就会很难受了。这段时间在阿里实习,经常会感觉有些知识不够用了,希望返校继续加强学习。

2. 前端也是重点

前端有一个很大胆的尝试,“数据在前端”。

打开一个网页,浏览器发送请求到服务器,服务器从数据库里获取数据,经过后台脚本的拼装处理,然后输出到前端,这是最常见的方式。这种方式的缺点就是,频繁的读取数据库,然后还有一大堆经过HTML标签包装过的数据传到前端,期间的冗余消耗是特别大的。于是有人就想到了,后端的数据全部使用JSON方式输出,到了前端再渲染数据,这种方式获得了一定的优化效果,前端端的分离似乎也很明显,但是前端负担就太重了,数据的处理和渲染都是前台,也就是承担了Controller和Views的角色,前台很累,他累了也会发脾气,比如:数据到了,要半天之后才解析完毕,再花半天将其渲染出来。同时这种处理方式也不利于SEO。

现在的尝试是,前端就是一个数据库,每个用户都有数据库数据的一个备份。


                    +----------+
| |
| Database |
| |
+-----|----+
|
+---------|----------+
/| | / | Server | \
/ | | / +----|----------|----+ / | | \
+---------/+ +------|---+ +---|------+ +\---------+
| | | | | | | |
| Client |..| Client |..| Client |..| Client |
| | | | | | | |
+-----|----+ +-----|----+ +-----|----+ +-----|----+
| | | |
+-----|----+ +-----|----+ +-----|----+ +-----|----+
| | | | | | | |
| Local | | Local | | Local | | Local |
| Storage | | Storage | | Storage | | Storage |
| | | | | | | |
+----------+ +----------+ +----------+ +----------+

浏览器每次连接到服务器,都会将服务器的数据同步到本地,打开页面,第一件事是呈现当前LocalStorage的数据,然后发送一个请求询问服务器,“是否有数据更新啊?”,每次只拉去更新的数据。

有人会觉得这种方式不可取,本地存不了这么多东西啊。当然存不了这么多,一篇文章有作者、标题、日期、概要还有内容,我们可以在本地储存出内容之外的所有东西,就算有100篇文章,其缓存的量也不过几百KB,试想你加载个
JQ 是不是也得上百KB啊~那么每次我们从后端拉取的数据量就十分小了。

至于本地储存的实现方式,这个好处理,LocalStorage、IndexDB、UserData等等,方式很多,还有一些其他比较 hack
的方式,我以后再介绍。

3. 前后端之间的屏障

后端会有很多的服务,比如邮件、HTTP、HTTPS、socket等等,再比如:A域名、B域名、A子域名、B子域名的处理等等。为了处理伪静态,安全,缓存,动静页面分离等多个问题,决定在昨天考虑的架构上再加一层
Nginx。


    +------------------+     +------------------+
| Front-End | | Browser |
| 前端处理 | +--------------+ |
| |←---→| LocalStorage | |
+--↑-----↑-----↑---+ +--------------+---+
| | |
| | |
| | |
+------------------+
| Nginx |
+---- 请求/代理 ---------------------------+
| | | |
| +------------------+ |
| | | | |
| | | | |
| +--↓-----↓-----↓---+ |
| | NodeJS | +-------------+ |
+-->| 处理I/O | | Database | |
| | |←-+-→| | |
| +-----|-----↑------+ | | | |
| | | | | | |
| +-----↓-----|------+ | +----------+ | |
| | PHP | | | | | |
+-->| 处理数据 |←-+-→| cache | | |
| | | | | | |
| +------------------+ +----------+--+ |
| |
+------------------------------------------------+

东西越多,维护成本越高,不过我竟然觉得添加一层会有更多的乐趣...

后续会继续记录建站过程。

时间: 2024-11-13 09:03:42

个人网站架构设计(二)的相关文章

Web网站架构设计考虑的因素

转自http://blog.csdn.net/moshengtan/article/details/8990052 1    Web负载均衡 1.1 - 使用商业硬件实现 最常用的F5 与citrix netscaler.比如12306前端的web好像用的就是F5 的BIGIP.如果公司资金足够的话,相对使用开源软件来说理方便. 优点:维护方便,性能稳定 缺点:费用太高 1.2 - 使用开源软件 可选择使用lvs或者nginx做web应用的负载均衡. Lvs工作在tcp 协议4层下,而nginx

个人网站架构设计(三) - 从设计到前端到后台

在五月份,写过两篇博客,提到了要给自己做个网站,当时人在实习,没太多的时间,只是把大概的思路捋了一番,顺道也买了个云主机(配置比较低,内存才500M).接着返校处理毕业事宜,于是六月也随着同学之间挥泪告别的声音渐渐远去.七月,家里呆着,中旬回公司.想必这也是我近几年最长的一次假期了=. = 一.先说设计 1. 阮一峰的博客 目前我的博客设计是 fork 了 BeiYuu 的主题,然后七改八改,除了主页 BeiYuu 还认得出是他的之外,其他页面已经动了很大的手术,而这些手术灵感都是源自阮一峰阮大

高性能网站架构设计之缓存篇(3)- Redis的配置

我们说Redis是一个强大的Key-Value存储系统,在前面我们已遇到了两个问题: 1.redis server 启动后,独占进程,能不能修改为后台服务呢? 2.redis server 服务是单线程的,而我的机器是多核的,能不能在同一台机器上开启多个实例更充分的利用 cpu 资源呢?但6379端口已经被前一个实例绑定,肯定会有冲突,那能不能修改默认端口呢? 答案是肯定的,redis 提供了灵活的配置方式,一种可以通过配置文件来配置,另一种你可以在运行时通过 config set 命令来修改配

大型分布式网站架构设计与实践

大型分布式网站架构设计与实践(一线工作经验总结,囊括大型分布式网站所需技术的全貌.架构设计的核心原理与典型案例.常见问题及解决方案,有细节.接地气/京东:大型分布式网站所需技术的全貌.架构设计的核心原理与典型案例.常见问题及解决方案) 陈康贤 著   ISBN 978-7-121-23885-7 2014年9月出版 定价:79.00元 460页 16开 编辑推荐 --作者一直奋战在阿里巴巴及淘宝网一线,书中所讲是其亲身经验的总结,显得更加实战和珍贵. --全面介绍大型分布式网站架构所涉及的技术细

大型网站架构设计(图)

=>传统网站架构与优化(图) 大型网站架构设计(图)

《大型分布式网站架构设计与实践》

读后感 逐字逐句看完<大型分布式网站架构设计与实践>第2章,意犹未尽!如标题所言,这是一本“真材实料的分布式资料”,它与我看过的分布式书籍(如<大型网站系统与Java中间件实践>)不同,本书重技术兼并理论,给了新人入手的方向. 我最最感动的是书中介绍了很多分布式的“干货”:分布式缓存可以用memcache.数据库水平/垂直拆分技术.分布式存储可以HBase/Redis等.消息通道可以用ActiveMQ.搜索引擎Lucene/Solr等.当然每一种技术都不是一本书能说完的,作者至少给

高并发高流量的网站架构设计 (转)

Web2.0的兴起,掀起了互联网新一轮的网络创业大潮.以用户为导向的新网站建设概念,细分了网站功能和用户群,不仅成功的造就了一大批新生的网站,也极大的方便了上网的人们.但Web2.0以用户为导向的理念,使得新生的网站有了新的特点——高并发,高流量,数据量大,逻辑复杂等,对网站建设也提出了新的要求. 本文围绕高并发高流量的网站架构设计问题,主要研究讨论了以下内容: 首先在整个网络的高度讨论了使用镜像网站,CDN内容分发网络等技术对负载均衡带来的便利及各自的优缺点比较.然后在局域网层次对第四层交换技

高并发大型网站架构设计

一个大型的网站网站应该由如下6个子系统组成 负载均衡系统 反向代理系统 Web服务器系统 分布式存储系统 底层服务系统 数据库集群系统 为什么要做高并发系统设计? 事实上,针对于任何单一的网络服务器程序,其可承受的同时连接数目是有理论峰值的,通过C++中对TSocket的定义类型:word,我们可以判 定这个连接理论峰值是65535,也就是说,你的单个服务器程序,最多可以承受6万多的用户同时连接.但是,在实际应用中,能达到一万人的同时连接并能保 证正常的数据交换已经是很不容易了,通常这个值都在2

优酷、YouTube、Twitter及JustinTV视频网站架构设计

优酷视频网站架构 一.网站基本数据概览 据2010年统计,优酷网日均独立访问人数(uv)达到了8900万,日均访问量(pv)更是达到了17亿,优酷凭借这一数据成为google榜单中国内视频网站排名最高的厂商.     硬件方面,优酷网引进的戴尔服务器主要以 PowerEdge 1950与PowerEdge 860为主,存储阵列以戴尔MD1000为主,2007的数据表明,优酷网已有1000多台服务器遍布在全国各大省市,现在应该更多了吧. 二.网站前端框架 从一开始,优酷网就自建了一套CMS来解决前