⑴ 跨境电商网做网站，对服务器配置的有什么具体要求
跨境电商平台做网站的话，一般是自建站对吧？
有几点需要注意的：
服务内器最好选择目标国或容目标地区的，亦或是周边地区。有利于访问体验
服务器配置根据网站的大小而定，一般建议至少要1核2G 3M带宽的配置，如果想要访问时能够支撑更多数据并发的话，建议带宽可以加大。
服务器系统，尽量选择linux，因为windows的有几率会遇到勒索病毒等，安全系数来说linux更高，而且PHP的站点在linux运行更好一些，asp的在win运行更好一些。
尽量根据自己的需求和技术要求来。
⑵ 论述电子商务网站建设流程
电子商务网站开发的流程主要有以下几步：
第一步：需要客户提供一个完整的需求说明。
说明书的标准：
1、正确性：每个功能必须清楚描写交付的功能;
2、可行性：确保在当前的开发能力和系统环境下可以实现每个需求;
3、必要性：功能是否必须交付，是否可以推迟实现，是否可以在削减开支情况发生时"砍"掉;
4、简明性：不要使用专业的网络术语;
5、检测性：如果开发完毕，客户可以根据需求检测。
第二步是做系统分析。
网站总体设计：在拿到客户的需求说明后，并不是直接开始网站制作，而是需要对项目进行总体设计，详细设计，出一份网站建设方案给客户。总体设计是非常关键的一步。
它主要确定：
1、网站需要实现哪些功能;
2、网站开发使用什么软件，在什么样的硬件环境;
3、需要多少人，多少时间;
4、需要遵循的规则和标准有哪些。
同时需要写一份总体规划说明书，包括：
1、网站的栏目和版块;
2、网站的功能和相应的程序;
3、网站的链接结构;
4、如果有数据库，进行数据库的概念设计;
5、网站的交互性和用户友好设计。
网站建设方案在总体设计出来后，一般需要给客户一个网站建设方案。很多网页制作公司在接洽业务时就被客户要求提供方案。那时的方案一般比较笼统，而且在客户需求不是十分明确的情况下提交方案，往往和实际制作后的结果会有很大差异。所以应该尽量取得客户的理解，在明确需求并总体设计后提交方案，这样对双方都有益处。
网站建设方案的包括以下几个部分：
1、客户情况分析;
2、网站需要实现的目的和目标;
3、网站形象说明;
4、网站的栏目版块和结构;
5、网站内容的安排，相互链接关系;
6、使用软件，硬件和技术分析说明;
7、开发时间进度表;
8、宣传推广方案;
9、维护方案;
10、制作费用;
11、本公司简介：成功作品，技术，人才说明等。
第三步是做网站建设方案。
在总体设计出来后，一般需要给客户一个网站建设方案。很多网页制作公司在接洽业务时就被客户要求提供方案。那时的方案一般比较笼统，而且在客户需求不是十分明确的情况下提交方案，往往和实际制作后的结果会有很大差异。所以应该尽量取得客户的理解，在明确需求并总体设计后提交方案。
⑶ 电子商务网站部署什么样的证书
电子商务网站因为包含大量的客户信息，支付信息，并且容易被钓鱼假冒专网站仿冒，所以必须按照属OV级以上的SSL证书，如EV SSL证书来加密传输数据，认证服务器真实身份。基本上所有的电子商务网站都部署了OV或者EV SSL证书，如淘宝、天猫、支付宝、京东、亚马逊等等。参见EV SSL证书的详细介绍网页链接
⑷ 如何在阿里云上部署Magento电子商务网站
其实阿里抄云服务器还可以的 不管你需要什么环境 你在服务器运行一个镜像和你的这个网站一样的环境 然后自动配置好环境的 一般都是免费的 最后把你的网站打包丢进去就可以了
我之前有用过Windows 服务器版本 装载了 java环境 因为windows的服务器都有可视化桌面的 所以直接远程 把网页压缩然后丢到云服务器就自动部署了
⑸ 电子商务网站服务器需要什么配置
电子商务网站来的服务器需要企业级高性能的机型。商城网站因为属于在线交易类型的性质，所以在线人数较多，安全性、稳定性、速度都有要求的。
对于电子商务网站而言，安全性一直是客户网络交易的最大问题之一，所以,选择一个快速、安全的托管解决方案很有必要，关键是能从黑客和钓鱼网站中保护你用户数据安全。
1、快速而稳定的服务器
无论是什么行业或者类型的网站，快速稳定的服务器是每个网站正常运行的前提，是支撑电商网站运营的支柱，一旦服务器出现了问题，将会带来严重的后果。所以服务器的选择非常重要，我们在租用服务器时一定要对其进行全面的考察以及使用过该服务器的用户的一些评价。在选择时，最 好选用知 名品牌主机，即使对服务器不是很了解，也不会上当受坑。
2、合适的网站空间与流量
电商网站的图片一般比较多，特别是为了更好地展示产品或服务，我们会找专人设计优质的页面，这样也就导致图片比较大。再者就是电商网站一般访客比较多，所以在空间和流量方面不要太小，不然会导致空间和流量不够用，网站被迫停止访问。当然也不要一味追求大的空间和流量，以免导致资源的浪费。当您对此不知道如何选择时，在购买时可以咨询下技术支持人员，他们会给您推荐最合适的主机。
3、服务器安全加密
Linux操作系统和cPanel的安全加密增加了的服务器安全性。通过增加服务器强化举措，它大大提高了用户的服务器和软件的安全性、可靠性和兼容性。
4、安装SSL数字证书
电商网站都是线上交易，必须保证用户线上交易的安全，所以需要强大的加密系统。SSL数字证书通过加密最大程度的保护网站用户的访问数据，而且具有安全标示的网站更容易获取用户的信任。
电商网站对服务器配置的要求还是非常高的，不但要速度、空间、流量，更需要安全稳定，所以再次提醒您，如果是电商网站尽量选择知 名品牌锐讯网络的服务器，它是您安全交易的保障。
⑹ 电子商务网站一般架构有哪些
大型电子商务网站架构，摘抄 7.同一个网站的多语言该如何处理是好,使用配置文件然后cookie或url来判别?===客户是自己公司，使用标准方法即可
8.电子商务网站最多的就是 商品的打折方式和积分的赠送了,这里要怎么设计才好(工厂模式)?===采购成熟的规则引擎
9.如果同一时间并发大量订单的话,如果确保一个订单的有效提交呢?
==电子商务一般要使用MQ，推荐IBM MQ；使用MSMQ也可
第一点是数据库要设计好，要达到什么级别，你可能需要考虑哪些表需要拆分，哪些表的核心数据需要冗余，如果是mysql，还要考虑其他的问题，比如存储引擎。
新闻肯定是要生成纯静态页，对数据库压力就小很多，不过静态页也有管理上的不方便，更新删除添加都要对磁盘文件进行操作
做一个自定义缓存层，对缓存逻辑进行控制，可以采用第三方缓存模块，如果使用.net来做，可以层层缓存，页面缓存，数据缓存（memcache，不过在win下效率不高）
电子商务网站特点就是对事务的严格，需要数据库设计的时候要求高性能，也需要合适的索引，支持高并发，经常对产品表用户表等进行索引检查，是否有很多索引扫描和表扫描（即使是局部的，也要将逗局部地控制到最小范围）
mssql语句对不需要事务的查询要附带上with(nolock),以利于并发更新。
有些功能模块不能按照想当然的方式开发，比如产品访问次数，切不可将这些更新非常频繁的字段置于核心表内，明确的做法是将其剥离开来 还有就是切不可经常性将字段设计成bool类型，这样会给以后的扩展留出路，即使是男女这种字段，也建议采用tiny类型
其他还有就是在产品设计的时候充分考虑seo，网站目录结构清晰可读，而不是带着一串串的查询参数。
对安全要有整体的把握，最好全都是用存储过程，在项目上线前将数据库存储过程全部导出再查找貌似exec的语句，查找是否需要替换成sp_executesql。
另外，如果采用mssql，全文搜索直接用mssql fte就可以，速度和精确度都还是可以的，最重要的是维护和管理开发很简单。
打折的处理可以按照电信的一次，二次批价功能，如果你做过电信方面的系统。
当然也可以设计得更简单的一些。 静态的页面建议使用CDN加速，以解决网通和电信之间访问速度的问题；
数据的缓存方面建议考虑用memcache，另外也可以分别在表现层和数据层利用.net中的现存缓存机制作业可；
简单执行的sql可以不用存储过程，存储过程会占用数据库服务器的处理时间，造成死锁；
mvc建议还是做些CMS的项目上应用，电子商城不是很适合，个人观点。url上可以做转义，使url显示更友好；
数据库建议建立分布数据库，这样可以转移查询和大访问量对数据库带来压力；
图片可以考虑单独放在一台服务器上；1.三层架构
2.使用手写sql,手写entity(生成也可),缓存反射绑定(不是缓存数据哦,缓存映射关系),要考虑网站的长期发展还是手写吧 灵活 性能也好
3.没有这种问题,商业驱动的,纯购物就好了,千万别搞什么圈子,wiki
4.纯.net的mvc不建议,webform不搞viewstate,不搞服务端控件(除repeater)再加点mvc的思想已足够用了
5.不需要缓存数据(除搜索产品部分),要考虑多台服务器的程序快速部署,config文件会很多,config要序列化缓存
6.当然是先生成好了,参照jd吧,按业务每张图片对应几个不同大小的图
7.据经验,电子商务网站仅靠中英双语来达到多语言是不靠谱的(文化 用户习惯不是简单的语言切换),如果想真正运营英语的就要重新开发一个版本
8.不搞模式
9.负载均衡(web,db)+ssb异步处理数据
10.你是业务类型的日志还是异常日志? 前台订单流程上异常日志不需要了,找个工具录个脚本不停的跑 保证随时发现问题发邮件就可以了
11.找第三方搜索组件 类似endeca的
12.负载均衡挺简单的,初期靠软件就可以,一切图片找第三方放cdn,前台网站用到ajax的地方很少,如果用的话jquery 1，一个电子商务网站用户99.5%的行为时Find
2、对于商品检索部分，能不用数据库就不用数据库（网上切词等相关的开源平台很多）
3、分布式缓存（Memcached 、Volecity），个人测试volecity 3还是不错的
4、系统设计时必须要考虑可运营。从这个角度去设计系统
5、对于电子商务网站改动很频繁，必须考虑架构设计如何适应频繁的版本更新
6、必须设计一个好的单点登录系统。
7、建议能不用sqlserver就不用它。
8、对于大型电子商务网站来说，系统的I/O是起决定因素而不是CPU和内存。1.项目划分是否会有问题,图中分别是 实体层,数据访问接口层,数据访问层,业务逻辑接口层,业务逻辑,网站A,B,C
项目划分其实不重要，重要的的是你在写代码的时候是否能把代码合理的分到对应的项目里。
2.数据访问层是要开发效率(NBear,Linq,Nh等),还是访问效率(直接使用sql等)?是否可以先使用开发效率高的,等日后访问量大了,再重写并替换数据访问层?
开发效率优先，访问量大了以后，我相信是有钱投到硬件上的，在你程序写的不是很烂的情况下，升级硬件远比优化程序节省成本。
3.网站被切割成了多个子网站,有一些控件(如header,footer)是要共享的,如何跨网站项目共享这些控件呢?
那就做成自定义控件啦。
4.ms的mvc 1.0也出来不少时间了,是否已经够成熟运用到项目中?或者是网站后台使用webform的,前台使用mvc?
推荐使用使用webform的,前台使用mvc，对于前台来说使用mvc能更好的提升性能，更方便的更换页面表现形式。后台界面相对稳定，用webform可以提高开发效率。
5.网站数据的缓存是自己开发一个hashtable什么的来维护呢,还是使用Memcached ?
初期建议用hashtable，因为简单，将来升级到Memcached 。
6.缩略图的处理,我看有的网站是在上传图片的时候直接生成,有的是在httpmodle里处理,访问的时候生成.
直接生成缩略图的好处是节约性能。httpmodle相反，每次浏览图片的时候都会生成新的图片，服务器压力大，建议直接生成。
7.同一个网站的多语言该如何处理是好,使用配置文件然后cookie或url来判别?
多语言建议使用asp.net自带的资源文件的方式实现，当前语言保存在cookie里面。
8.电子商务网站最多的就是 商品的打折方式和积分的赠送了,这里要怎么设计才好(工厂模式)?
规则引擎
9.如果同一时间并发大量订单的话,如果确保一个订单的有效提交呢?
使用MQ队列
10.日志方面,log4net?
log4net只能记录程序运行日志，主要目的是用来调试程序的，系统业务操作日志还你是得自己建一个表来保存。
11.电子商务的全文检索,这也是个头疼的问题
lucene，微软索引服务，sqlserver全文检索，方案很多的。
12.负载均衡方面,有什么好的文章推荐码?
可以看windows 2003 集群方面的文章 1.项目划分是否会有问题,图中分别是 实体层,数据访问接口层,数据访问层,业务逻辑接口层,业务逻辑,网站A,B,C
目前我也是这样分的,不过当数据表结构有修改时,会带动其它层的联级修改,非常不方便，所以开发之前最好将数据库设计地完善一点。另外，当网站分成多个以后，其它项目生成的DLL文件要部署到每个网站的bin文件夹里，更新一次都要重新部署，这也是个挺烦人的事，当然可以将DLL部署到GAC里来解决这个问题，不过这样的话本地调试起来就不太方便了，因为项目一有改动，就要将生成的DLL重新拷贝到GAC里才能看到效果。
2.数据访问层是要开发效率(NBear,Linq,Nh等),还是访问效率(直接使用sql等)?是否可以先使用开发效率高的,等日后访问量大了,再重写并替换数据访问层?
这个我也在考虑。目前我还没有采用ORM框架，都是在DAL里直接访问DB的。
3.网站被切割成了多个子网站,有一些控件(如header,footer)是要共享的,如何跨网站项目共享这些控件呢?
自定义控件。
4.ms的mvc 1.0也出来不少时间了,是否已经够成熟运用到项目中?或者是网站后台使用webform的,前台使用mvc?
正在学习这一块。
5.网站数据的缓存是自己开发一个hashtable什么的来维护呢,还是使用Memcached ?
现在我用的比较多的是.net自带的数据缓存。
6.缩略图的处理,我看有的网站是在上传图片的时候直接生成,有的是在httpmodle里处理,访问的时候生成.
直接生成好，快一点。
7.同一个网站的多语言该如何处理是好,使用配置文件然后cookie或url来判别?
我没涉及到这一块，不过我觉得资源文件应该就是用来处理这个问题的。
8.电子商务网站最多的就是 商品的打折方式和积分的赠送了,这里要怎么设计才好(工厂模式)?
这些都放在逻辑层好了。
9.如果同一时间并发大量订单的话,如果确保一个订单的有效提交呢?
MSMQ
10.日志方面,log4net?
目前我是自已写代码存在库里的。
11.电子商务的全文检索,这也是个头疼的问题
用lucene.net分词建索引，再直接从索引库里搜索，又快又准。
12.负载均衡方面,有什么好的文章推荐码?
不清楚了。 这样的设计要达到新蛋的效果肯定不可能的，新蛋少说几百台服务器，不同数据库之间的发布订阅链路都有几千条。有复杂的缓存，负载均衡机制。新蛋所有的通讯都是基于WCF的。另外对于这么大型的网站来说，数据库一刻都不停止，所以读写分离也很重要，因为你也不可能让数据库停下来进行备份。总归要做到新蛋这样的大型电子商务网站，靠你上面画的这点好像远远不够。
不过关于公共的header,footer,我不建议做成自定义控件，这个维护起来不方便，稍有变动就要发布dll，麻烦的。
如果你的header和footer不是很大的话，建议采用js+css的方式。然后加上压缩和cdn缓存，应该效率上能接受。
⑺ UV 5w-10w 左右电子商务网站的服务器配置及部署请教
谢谢各位大虾了，顶起~
⑻ 网站的部署文件和内容资源要怎么放置
大型电子商务网站的框架，相同的抽取。多语言网站如何处理好，那么使用配置文件来cookie或URL来确定你的公司呢？=顾客，使用标准方法至公元8年。电子商务网站是最大的商业折扣和积分这里介绍，如何设计它（工厂）？=成熟规则引擎> 9。采购如果同一时间与大量的订单，如果提交的订单，以确保有效？
= =电子商务使用MQ，IBM推荐使用MSMQ或
MQ；第一是设计数据库，到什么程度，你可能需要考虑哪些表需要分离，这表需要冗余的核心数据，如果它是MySQL，但也在考虑其他的问题，如存储引擎。
消息真是生成静态页面，数据库要小得多，但也有静态页面管理不方便的添加、更新和删除磁盘文件操作
做一个自定义的缓存层来控制缓存逻辑，可以使用第三方缓存模块，如果你用.net做的可以，层缓存，页面缓存，数据缓存（memcache，但赢得效率不高）交易
电子商务网站是严格的，在高性能的数据库设计的要求，但还需要正确的指标，高并发、产品索引表的用户表定期检查，如果有很多索引扫描和表扫描（即使是局部的，但也要“本地”控制到最低）
MSSQL语句不需要问查询偶然事务上（NOLOCK）方便并发更新。一些
功能模块不与开发产品如想当然的按照访问次数，不得这些非常频繁的更新，在表中的核心领域，它是明确的分离
没有定期的现场设计为bool类型，这将给未来发展留下了，即使这是男性和女性的领域，也推荐使用小
和其他类型的产品设计是在充分考虑了SEO网站，目录结构清晰，而不是一个字符串查询参数。
对安全有一个整体的把握，最好是使用所有的存储过程，将项目存储在数据库中的出口的整个过程之前，然后像EXEC语句找到需要更换sp_executesql。
另外，如果使用的是MSSQL，直接与MSSQL FTE全文搜索可以速度和精度仍然是可能的，最重要的是维护和管理发展很简单。根据电信一次折扣，两倍的价格，如果你做过电信系统。当然，也可以设计为更简单。
静态页面推荐使用CDN解决加速度之间的网通和电信的访问速度；
数据缓存应该被缓存，也可分别在表示层和数据层使用现有的缓存操作机制。净；
简单实现的SQL可以存储程序，处理时间的存储过程将占用数据库服务器的僵局；
MVC的建议或做CMS项目的应用，电子商城不是很适合个人的看法。URL可以做的是逃避，URL显示更友好；数据库建议建立分布式数据库，它可以将查询和访问转移给数据库带来压力；图像可以在单独的服务器上考虑；三层结构的< > > > > 1。 2 >。用手写SQL，手写实体（生成可以），反映缓存绑定（不缓存数据哦，缓存映射），考虑网站的长期开发性能或灵活或手写3。没有这个问题，业务驱动，纯购物是好的，为什么不循环，wiki 4。纯.NET MVC Web窗体不推荐，不使用ViewState，不搞服务器控件（除了中继器）添加MVC的概念是足够使用
5。不需要缓存数据（搜索部分除外），考虑到多服务器程序的快速部署，配置文件会有很多配置。序列化缓存
6。当然是Right先生，根据JD，根据每个图片的业务对应几个不同大小的< 7。根据电子商务网站的经验，双语实现多语言不可靠（语言切换文化不是一个简单的用户习惯），如果你想要一个真正的英语重新运行开发的一个版本。不参与模式 > 9。负载平衡（Web，DB）+ SSB异步处理的数据在10。您是业务类型还是异常日志？异常日志的顺序进程不需要找到一个工具来记录脚本在任何时候运行，以确保
⑼ 搭建一个日点击量百万以上的 电子商务网站，它的硬件设备投资大概会是多少
百万级访问量网站的技术准备工作
当今从纯网站技术上来说，因为开源模式的发展，现在建一个小网站已经很简单也很便宜，所以很多人都把创业方向定位在互联网应用。这些人里大多数不是很懂技术，或者不是那么精通，而网站开发维护方面的知识又很分散，学习成本太高，所以这篇文章将这些知识点结合起来，系统的来说，一个从日几千访问的小小网站，到日访问一两百万的小网站，中间可能会产生什么问题，以及怎么才能在一开始做足工作尽量避免这些问题。
你的网站因为努力经营，访问量逐渐升高，在升高的过程中，问题也可能开始显现了。因为带宽的增加、硬件的扩展、人员的扩张所带来的成本提高是显而易见的，而还有相当大的一部分成本是因为代码重构、架构重构，甚至底层开发语言更换引起的，最坏的情况就是数据丢失，所有努力付之一炬。这类成本支出大多数在一开始就可以避免，先打好基础，往后可以省很多精力，少操很多心。
对于不同的初期投资成本，技术路线的选择是不同的。这里假设网站刚刚只是一个构想，计划第一年服务器硬件带宽投入5万左右。对于这个资金额度，有很多种方案可选择，例如租用虚拟主机、租用单独服务器，或者流行的私有云，或者托管服务器。前两种选择，网站发展到一定规模时需迁移，那时再重做规划显然影响更大。服务器托管因为配置自主、能完全掌握控制权，所以有一定规模的网站基本都是这种模式。采用自己托管服务器的网站，一开始要注意以下几点——
一、开发语言
一般来说，技术人员（程序员）都是根据自己技术背景选择自己最熟悉的语言，不过不可能永远是一个人写程序，所以在语言的选择上还要是要费些心思。首先明确一点，无论用什么语言，最终代码质量是看管理，因此我们从前期开发成本分析。现在国内流行的适用于网站的语言，大概有java、php、.net、 python、ruby这五大阵营。python和ruby因为在国内流行的比较晚，现在人员还是相对难招一些。.net平台的人相对多，但是到后期需要解决性能问题时，对人员技能的要求比较高。剩余的java、php用人可以说是最多的。java和php无法从语言层面做比较，但对于初期，应用几乎都是靠前端支撑的网站来说，php入门简单、编写快速，优势相对大一点。至于后端例如行为分析、银行接口、异步消息处理等，等真正需要时，就要根据不同业务需求来选择不同语言了。
二、代码版本管理
稍微有点规模的网站就需要使用代码版本管理了。代码版本管理两点最大的好处，一是方便协同工作，二是有历史记录可查询比较。代码版本管理软件有很多，vss/cvs/svn/hg等，目前国内都比较流行，其中svn的普及度还是很高的。
假设选了svn，那么有几点考虑。一是采用什么树结构。初期可能只有一条主干，往后就需要建立分支，例如一条开发分支，一条上线分支，再往后，可能要每个小组一个分支。建议一开始人少时选择两条分支，开发和线上，每个功能本地测试无误后提交到开发分支，最后统一测试，可以上线时合并到上线分支。如果每人都建自己的分支，合并时会浪费很大精力，对于几乎每天都要修改几次的WEB应用来说，所费时间太多。
向服务器部署代码，可以手工部署也可以自动部署。手工部署相对简单，一般可直接在服务器上svn update，或者找个新目录svn checkout，再把web root给ln -s过去。应用越复杂，部署越复杂，没有什么统一标准，只是别再用ftp上传那种形式，一是上传时文件引用不一致错误率增加，二是很容易出现开发人员的版本跟线上版本不一致，导致本来想改个错字结果变成回滚。如果有多台服务器还是建议自动部署，更换代码的机器从当前服务池中临时撤出，更新完毕后再重新加入。
三、服务器硬件
在各个机房里，靠一台服务器孤独支撑的网站数不清，但如果资金稍微充足，建议至少三台的标准配置，分别用作web处理、数据库、备份。web服务器至少要8G内存，双sata raid1，如果经济稍微宽松，或静态文件或图片多，则15k sas raid10。数据库至少16G内存，15k sas raid 10。备份服务器最好跟数据库服务器同等配置。硬件可以上整套品牌，也可以兼容机，也可以半品牌半组装，取决于经济能力。当然，这是典型的搭配，有些类型应用的性能瓶颈首先出现在web上，那种情况就要单独分析了。
web服务器可以既跑程序又当内存缓存，数据库服务器则只跑主数据库（假如是MySQL的话），备份服务器所承担就相对多一些，web配置、缓存配置、数据库配置都要跟前两台一致，这样WEB和数据库任意一台出问题，很容易就可以将备份服务器切换过去临时顶替，直到解决完问题。要注意，硬件是随时可能坏掉的，特别是硬盘，所以宁可WEB服务器跟数据库服务器放在一起，也一定不能省掉备份，备份一定要异机，并且有异步，电力故障、误操作都可能导致一台机器上的所有数据丢失。很多的开源备份方案可选择，最简单的就是rsync，写crontab里，定时同步。备份和切换，建议多做测试，选最安全最适合业务的，并且尽可能异地备份。
四、机房
三种机房尽量不要选：联通访问特别慢的电信机房、电信访问特别慢的联通机房、电信联通访问特别慢的移动或铁通机房。机房要尽可能多的实地参观，多测试，找个网络质量好，管理严格的机房。机房可以说是非常重要，直接关系到网站访问速度，网站访问速度直接关系到用户体验，访问速度很慢的网站，很难获得用户青睐。
五、架构
在大方向上，被熟知的架构是web负载均衡+数据库主从+缓存+分布式存储+队列。在一开始，按照可扩展的原则设计和编程就可以。只是要多考虑缓存失效时的雪崩效应、主从同步的数据一致性和时间差、队列的稳定性和失败后的重试策略、文件存储的效率和备份方式等等意外情况。缓存失效、数据库复制中断、队列写入错误、电源损坏，在实际运维中经常发生，如果不注意这些，出现问题时恢复期可能会超出预期很长时间。
六、服务器软件
操作系统Linux很流行。在没有专业运维人员的情况下，应倾向于择使用的人多、社区活跃、配置方便、升级方便的发行版，例如RH系列、 debian、ubuntu server等，硬件和操作系统要一起选择，看是否有适合的驱动，如果确定用某种商业软件或解决方案，也要提前知晓其对哪种操作系统支持最佳。web服务器方面，apache、nginx、lighttpd三大系列中，apache占有量还是最大，但是想把性能调教好还是需要很专业的，nginx和 lighttpd在不需要太多调整的情况下可以达到一个比较不错的性能。无论选择什么软件，除非改过这些软件或你的程序真的不兼容新版本，否则尽量版本越新越好，版本新，意味着新特性增多、BUG减少、性能增加。一个典型的php网站，基本上大多数人都没改过任何服务器软件源代码，绝大多数情况是能平稳的升级到新版本的。类似于jdk5到 jdk6，python2到python3这类变动比较大的升级还是比较少见的。看看ChangeLog，看看升级说明，结合自己情况评估测试一下，越早升级越好，升级的越晚，所花费的成本越高。对于软件包，尽量使用发行版内置的包管理工具，没有特殊要求时不建议自己编译，那样对将来运维不利。
七、数据库
几乎所有操作最后都要落到数据库身上，它又最难扩展（存储也挺难）。数据库常见的扩展方法有复制、分片，设计时要考虑到每种应用的数据如何复制、分片，当然这种考虑一般会推迟到技术设计时期。在初期进行数据库结构设计时，要根据不同的业务类型和增长量预期来考虑是否要分库、分区，并且尽量不要使用联合查询、不使用自增ID以方便分片。复制延时问题、主从数据库数据一致性问题，可以自己写或者用已有的运维工具进行检测。
用存储过程是比较难扩展的，这种情形多发生于传统C/S，特别是OA系统转换过来的开发人员。低成本网站不是一两台小型机跑一个数据库处理所有业务的模式，是机海作战。方便水平扩展比那点预分析时间和网络传输流量要重要的多的多。
另外，现在流行一种概念叫NoSQL，可以理解为非传统关系型数据库。实际应用中，网站有着越来越多的密集写操作、上亿的简单关系数据读取、热备等，这都不是传统关系数据库所擅长的，于是就产生了很多非关系型数据库，比如Redis/TC&TT/MongoDB/Memcachedb等，在测试中，这些几乎都达到了每秒至少一万次的写操作，内存型的甚至5万以上。在设计时，可根据业务特点和性能要求来选择是否使用这类数据库。例如 MongoDB，几句配置就可以组建一个复制+自动分片+failover的环境，文档化的存储也简化了传统设计库结构再开发的模式。但是当你决定采用一项技术时，一定要真正了解其优劣，例如可能你所选择的技术并不能支持你所需要的事务和数据一致性要求。
八、文件存储
存储的分布几乎跟数据库扩展一样困难，不过只有百万的PV的情况下，磁盘IO方面一般不会成大问题，一两台采用SATA做条带RAID的机器可以应付，反而是自己做异步备份比较复杂，因为小文件多。如果只有一台机器做存储，可以做简单的优化，例如放最小缩略图的分区和放中等缩略图的分区，根据平均大小调整一下块大小。存储要规划好目录结构，否则文件增多后维护起来复杂，也不利于扩展。同时还要考虑将来扩容，例如采用LVM，或者把文件根据不同规则散列到不同机器。磁盘IO繁重的情况下更容易出现故障，所以要做好备份，若发现有盘坏掉，要马上行动更换，很多人的硬盘都是坏了一块之后，接二连三的坏下去。
为了将来图片走cdn做准备，一开始最好就将图片的域名分开，且不用主域名。因为很多网站都将cookie设置到了.domain.ltd，如果图片也在这个域名下，很可能因为cookie而造成缓存失效，并且占多余流量，还可能因为浏览器并发线程限制造成访问缓慢。
九、程序
一定硬件条件下，应用能承载多少访问量，很大一部分也取决于程序如何写。程序写的不好，可能一万的访问都承载不了，写的好，可能一两台机器就能承担几百万PV。越是复杂、数据实时性要求越高的应用，优化起来越难，但对普通网站有一个统一的思路，就是尽量向前端优化、减少数据库操作、减少磁盘IO。向前端优化指的是，在不影响功能和体验的情况下，能在浏览器执行的不要在服务端执行，能在缓存服务器上直接返回的不要到应用服务器，程序能直接取得的结果不要到外部取得，本机内能取得的数据不要到远程取，内存能取到的不要到磁盘取，缓存中有的不要去数据库查询。减少数据库操作指减少更新次数、缓存结果减少查询次数、将数据库执行的操作尽可能的让你的程序完成（例如join查询），减少磁盘IO指尽量不使用文件系统作为缓存、减少读写文件次数等。程序优化永远要优化慢的部分，换语法是无法“优化”的。
然而编程时不应该把重点放在优化上，应该关注扩展性。当今的WEB应用，需求变化非常之快，适应多种需求的架构是不存在的，我们的扩展性就要把要点放在跟底层交互的架构上，例如持久化数据的存取规则、缓存的存取规则等，还有一些共用服务，例如用户信息等。先把不变的部分做完善，剩下的部分就很容易将精力放在业务逻辑上面了。