架构纵横谈之一 ---- 架构的基础

 谈到架构，大家都觉得很神秘很高深，然而架构并非高不可攀、遥不可及，架构也是实践发展的产物，是由人创造出来的。那么什么是网站架构呢？网站架构，一般认为是根据客户需求分析的结果，准确定位网站目标群体，设定网站整体架构，规划、设计网站栏目及其内容，制定网站开发流程及顺序，以最大限度地进行高效资源分配与管理的设计。随着业务的扩大、用户需求的不断变化，一个网站架构也是在发展中不断前进、变化的，从简单到复杂，逐步优化和完善。下面就从三个方面来谈谈如何学习和认识网站架构，希望对大家有所帮助。

一、架构的基础

  网站架构包含硬架构与软架构，也是架构的基础。硬架构包括机房的选择、带宽的大小、服务器的角色定义和性能估算。软架构则包括框架和软件的选择、应用子系统的划分和高性能高可用的设计。

  首先说一下硬架构。在选择IDC机房的时候，根据网站目标群体的地域分布，可以选择网通或电信机房，但限于国内南北互联的情况，可能双线机房才是合适的。当然一线的大城市，机房价格都比较贵，从成本的角度来看，可以选择在一些中小城市托管服务器，比如说北京的公司可以考虑把服务器托管在天津，廊坊等地，不是特别远，而且价格也会便宜很多。

  再说说带宽的大小。我们在设计网站架构的时候，常常需要考虑客户提出的一些具体需求，诸如网站每天要能承受100万PV的访问量等等。计算带宽大小主要涉及两个指标（峰值流量和页面大小），我们不妨在计算前先根据客户的需求做出必要的假设，以此预算一下大概需要多大的带宽：

第一：假设峰值流量是平均流量的3倍。

第二：假设每次访问平均的页面大小是100K字节左右。

 客户要求的每天能承受100万PV的访问量是平均流量，那么这些流量在一天内平均分布的话，折合到每秒大约是12次访问，如果按平均每次访问页面的大小是100K字节左右计算的话，这12次访问总计大约就是1200K字节，字节的单位是Byte，而带宽的单位是bit，它们之间的关系是1Byte = 8bit，所以1200K Byte大致就相当于9600K bit，也就是9Mbps的样子，实际情况中，我们的网站必须能在峰值流量时保持正常访问，所以按照假设的峰值流量算，真实带宽的需求应该在27Mbps 左右。当然，这个结论是建立在前面提到的两点假设的基础上，如果你的实际情况和这两点假设有出入，那么结果也会有差别。

再有就是服务器的角色定义和性能估算。根据客户的需求，看看需要哪些服务器：前端、图片服务器、文件服务器、数据库服务器、邮件服务器、日志服务器等等。服务器角色的不同也决定了服务器性能要求的不同，我们可以根据对不同服务器性能的估算来进行硬件资源的配置。

下面附上一例（转自互联网，出处不详）

服务器处理性能估算示例
系统的建设，必须满足未来5年业务发展和管理的需求，所以下面对服务器性能指标的估算，将以满足未来5年的需要为基准。
数据库服务器
TPCC值估算
约定：
系统同时在线用户数为100人（U1）；
平均每个用户每分钟发出2次业务请求（N1）；
系统发出的业务请求中，更新、查询、统计各占1/3；
平均每次更新业务产生3个事务（T1）；
平均每次查询业务产生8个事务（T2）；
平均每次统计业务产生13个事务（T3）；
一天内忙时的处理量为平均值的5倍；
经验系数为1.6；(实际工程经验)
考虑服务器保留30％的冗余；
服务器需要的处理能力为：
TPC-C=U1*N1*（T1+T2+T3）/3*3*经验系数/冗余系数
则数据库服务器的处理性能估算为：
TPC-C= 100*2*（3+8+13）/3*5*1.6/0.7= 18,285 TPM

内存估算
该服务器内存主要由操作系统占用内存、数据库系统占用内存、并发连接占用内存等几部分组成。
约定：
操作系统占用约400M内存空间；
数据库系统占用内存0.8G ；
每个并发连接占用5 M；
考虑服务器内存保留15％的冗余；
则服务器的内存估算为：
Mem =(400M + 0.8GB  + 100*5M) /(1-15%)  = 2 GB
存储容量估算
预算管理系统中存储着预算编制数据等资料信息以及日志等管理信息。
在已经考虑了数据冗余的前提下，约定：
每月有100个分局或部室编制预算；
每月每个分局或部室编制1次预算；
预算模板共含6000个预算指标；
每个预算指标含5条明细项目；
每条记录占用空间300B；

每月的预算数据存储容量需求：6000*5*100*500B=1.5G
每月的日志数据存储容量需求：0.1G
每月进行数据备份一次，数据存储容量需求：12*9G=108G
整年总共需用存储容量：12*1.5G+1.5G+12*0.1G+12*9G=20.7G+108G=128.7G

约定系统中预算编制数据等资料信息以及日志等管理信息在线保存5年(备份数据每年进行清除)，则预算管理系统的存储容量估算为：
5*20.7G+108G =103.5G+108G=211.5G

另外关于服务器的性能需求与估算，还可以通过TPMC来估算，下面是个例子

补充：

tpmc是由第三方测试得出的数据，一般来说是由设备提供商来提供相应配置的tpmc。具体如何选择服务器，可由集成商提交需求测算，给出各类应用和数据库需要的硬件资源。

   最后说一下软架构。软架构则包括框架和软件的选择、应用子系统的划分和高性能高可用的设计。

网站的框架基本上分为开源和商业、混合框架三种，不同的框架也决定了对软件需求的不同选择，至于应该使用哪一种框架并没有唯一的答案，要根据项目成本和团队里成员对各个框架的了解程度而定。一旦框架和所使用的软件确定下来，下一步就是要进行应用子系统的划分和设计了。一般根据该公司或企业的业务和流程进行各应用子系统的划分，没有千篇一律的模子。 高性能和高可用的架构设计涉及很多技术和思想，涵盖前端、后端、中间层、缓存、数据库等，在这里就不一一展开了。

  就拿缓存这一层设计来说，需要考虑客户端浏览器缓存、服务器端转发代理缓存、服务器端反向代理缓存等。一般企业级Web应用程序既有静态部分又有动态部分，只要进行了正确的设计和架构，才能实现动静分离，静态部分从缓存中获取，动态部分从应用服务器获取，使服务器端和客户端都缓存内容，来加速性能。而做缓存设计经常用到的Squid和memcached的又各有特点。比如Squid服务器群，经常把它作为web服务器端的前置cache服务器，缓存相关请求来提高web服务器速度。Squid还能将大部分静态资源(图片，js，css等）缓存起来，并可以缓存频繁访问的网页，直接返回给访问者，以减少应用服务器的负载。memcached服务器群，做为一款分布式缓存产品，也在很多大型网站应用。 它可以应对任意多个连接，使用非阻塞的网络IO。由于它的工作机制是在内存中开辟一块空间，然后建立一个HashTable，Memcached自管理这些HashTable。因为通常网站应用程序中最耗费时间的任务是数据在数据库的检索，而多个用户查询相同的SQL时，数据库压力会增大，而通过memcached的查询缓存命中，数据直接从memcached内存中取，每次缓存命中将替换到数据库服务器的一次往返，这样到达数据库服务器的请求更少，间接地提高了数据库服务器的性能，从而使应用程序运行得更快。

    本系列计划发三篇， 未完待续，请持续关注。