有没有男女做那个的网站,做外贸网站 用国外空间 还是 国内空间 区别,wordpress 删除线,无版权的图片素材网站作者#xff1a;一路凯歌来源#xff1a;http://zhiyi.us/ 开了自己域名的博客#xff0c;第一篇就得来个重磅一点的才对得起这4美金的域名。作为一个技术从业者十年#xff0c;逛了十年发现有些知识东一榔头西一棒槌的得满世界 看个遍才整理出个头绪#xff0c;那咱就系统… 作者一路凯歌来源http://zhiyi.us/ 开了自己域名的博客第一篇就得来个重磅一点的才对得起这4美金的域名。作为一个技术从业者十年逛了十年发现有些知识东一榔头西一棒槌的得满世界 看个遍才整理出个头绪那咱就系统点的从头一步一步的说一个从日几千访问的小小网站到日访问一两百万的小网站怎么才能让它平滑的度过这个阶段别在 技术上出现先天不足写给一些技术人员也写给不懂技术的创业者。 对互联网有了解的人都有自己的想法有人就把想法付诸实现做个网站然后开始运营。其实从纯网站技术上来说因为开源模式的发展现在建一个小网站 已经很简单也很便宜。当访问量到达一定数量级的时候成本就开始飙升了问题也开始显现了。因为带宽的增加、硬件的扩展、人员的扩张所带来的成本提高是显而 易见的而还有相当大的一部分成本是因为代码重构、架构重构甚至底层开发语言更换引起的最惨的就是数据丢失辛辛苦苦好几年一夜回到创业前。 减少成本就是增加利润。很多事情我们在一开始就可以避免先打好基础往后可以省很多精力少操很多心。 假设你是一个参与创业的技术人员当前一穷二白什么都要自己做自己出钱初期几十万的资金做一个应用不是特别复杂的网站那么就要注意以下几点 一、开发语言一般来说技术人员程序员创业都是根据自己技术背景选择自己最熟悉的语言不过考虑到不可能永远是您一个人写程序这点还得仔细想想。无论用什么语言最终代码质量是看管理所以我们还是从纯语言层面来说实际一点。现在流行的java、php、.net、python、ruby都 有自己的优劣python和ruby现在人员还是相对难招一些性能优化也会费些力气.net平台买不起windows server。java、php用的还是最多。对于初期应用几乎都是靠前端支撑的网站来说php的优势稍大一些入门简单、设计模式简单、写起来快、 性能足够等不过不注重设计模式也是它的劣势容易变得松散隐藏bug稍多、难以维护。java的优势在于整套管理流程已经有很多成熟工具来辅助强类 型也能避免一些弱智BUG大多数JAVA程序员比较注重设计模式别管实不实际代码格式看起来还是不错的。这也是个劣势初学者可能太注重模式而很难 解决实际需求。 前端不只是html、css这类。整个负责跟用户交互的部分都是前端包括处理程序。这类程序还是建议用php主要原因就是开发迅速、从业人员广泛。至于后端例如行为分析、银行接口、异步消息处理等随便用什么程序那个只能是根据不同业务需求来选择不同语言了。 二、代码版本管理如果开发人员之间的网络速度差不多就SVN比较分散例如跨国就hg。大多数人还是svn的. 假设选了svn那么有几点考虑。一是采用什么树结构。初期可能只有一条主干往后就需要建立分支例如一条开发分支一条上线分支再往后可能 要每个小组一个分支。建议一开始人少时选择两条分支开发和线上每个功能本地测试无误后提交到开发分支最后统一测试可以上线时合并到上线分支。如果 喜欢把svn当做移动硬盘用写一点就commit一次也无所谓就是合并的时候头大一些这些人可以自己建个分支甚至建立个本地代码仓库随便往自己的 分支提交测试完毕后再提交到开发分支上。 部署可以手工部署也可以自动部署。手工部署相对简单一般是直接在服务器上svn update或者找个新目录svn checkout再把web root给ln -s过去。应用越复杂部署越复杂没有什么统一标准只要别再用ftp上传那种形式就好一是上传时文件引用不一致错误率增加二是很容易出现开发人员 的版本跟线上版本不一致导致本来想改个错字结果变成回滚的杯具。如果有多台服务器还是建议自动部署更换代码的机器从当前服务池中临时撤出更新完毕后 再重新加入。 不管项目多小养成使用版本管理的好习惯最起码还可以当做你的备份我的 http://zhiyi.us 虽然就是一个wordpress可还是svn了只改动一两句css那也是劳动成果。 三、服务器硬件别羡慕大客户和有钱人看看机房散户区一台服务器孤独的支撑的网站数不清。如果资金稍微充足建议至少三台的标准配置分别用作web处理、数据 库、备份。web服务器至少要8G内存双sata raid1如果经济稍微宽松或静态文件或图片多则15k sas raid10。数据库至少16G内存15k sas raid 10。备份服务器最好跟数据库服务器同等配置。硬件可以自己买品牌的底板也就是机箱配主板和硬盘盒CPU内存硬盘都自己配也可以上整套品牌也可 以兼容机。三台机器市场行情6、7万也就配齐了。 web服务器可以既跑程序又当内存缓存数据库服务器则只跑主数据库假如是MySQL的话备份服务器干的活就相对多一些web配置、缓存配置、数据库配置都要跟前两台一致这样WEB和数据库任意一台出问题把备份服务器换个ip就切换上去了。备份策略可以drbd可以rsync或者其他的很多很多的开源备份方案可选择。rsync最简单放cron里自己跑就行。备份和切换建议多做测试选最安全最适合业务的并且尽可能异地备份。 四、机房三种机房尽量不要选联通访问特别慢的电信机房、电信访问特别慢的联通机房、电信联通访问特别慢的移动或铁通机房。那网通机房呢亲网通联通N久 以前合并改叫联通了。多多寻找实地参观多多测试多方打探北京、上海、广州等各个主节点城市还是有很多优质机房的找个网络质量好管理严格的机 房特别是管理要严格千万别网站无法访问了打个电话过去才知道别人维护时把你网线碰掉了这比DOS都头疼。自己扯了几根光纤就称为机房的看您抗风 险程度和心理素质了。机房可以说是非常重要直接关系到网站访问速度网站访问速度直接关系到用户体验我可以翻墙看风景但买个网游vpn才能打开你这 个还不怎么知名的网站就有难度了。或许您网站的ajax很出色可是document怎么也不ready一些代码永远绝缘于用户。 五、架构初期架构一般比较简单web负载均衡数据库主从缓存分布式存储队列。大方向上也确实就这几样东西细节上也无数文章都重复过了按照将来 会有N多WEBN多主从关系N多缓存N多xxx设计就行基本方案都是现成的只是您比其他人厉害之处就在于设计上考虑到缓存失效时的雪崩效应、主 从同步的数据一致性和时间差、队列的稳定性和失败后的重试策略、文件存储的效率和备份方式等等意外情况。缓存总有一天会失效数据库复制总有一天会断掉 队列总有一天会写不进去电源总有一天会烧坏。根据墨菲定律如果不考虑这些网站早晚会成为茶几。 六、服务器软件Linux、nginx、php、mysql几乎是标配我们除了看名字还得选版本。Linux发行版众多只要没特殊要求就选个用的人最多的社区最活跃的配置最方便的软件包最全最新的例如debian、ubuntu。 至于RHEL之类的嘛你用只能在RHEL上才能运行的软件么剩下的nginx、php、mysql、activemq、其他的等等除非你改过这些软 件或你的程序真的不兼容新版本否则尽量版本越新越好版本新意味着新特性增多、BUG减少、性能增加。总有些道听途说的人跟你说老的版本稳定。所谓稳 定是相对于特殊业务来说的而就一个php写的网站大多数人都没改过任何服务器软件源代码绝大多数情况是能平稳的升级到新版本的。类似于jdk5到 jdk6python2到python3这类变动比较大的升级还是比较少见的。看看ChangeLog看看升级说明结合自己情况评估一下越早升级 越好别人家都用php6写程序了这边还php4的逛游呢。优秀的开源程序升级还是很负责任的看好文档别怕。 以上这六点准备完毕现在我们有了运行环境有了基本架构骨架有了备份和切换方案应该开始着手设计开发方面的事情了。开发方面的事情无数下一篇会先说一些重点。 原文地址 七、数据库 几乎所有操作最后都要落到数据库身上它又最难扩展存储也挺难。对于mysql什么样的表用myisam什么样的表用innodb在开发 之前要确定。复制策略、分片策略也要确定。表引擎方面一般更新不多、不需要事务的表可以用myisam需要行锁定、事务支持的用innodb。 myisam的锁表不一定是性能低下的根源innodb也不一定全是行锁具体细节要多看相关的文档熟悉了引擎特性才能用的更好。现代WEB应用越来 越复杂了我们设计表结构时常常设计很多冗余虽然不符合传统范式但为了速度考虑还是值得的要求高的情况下甚至要杜绝联合查询。编程时得多注意数据一 致性。 复制策略方面多主多从结构也最好一开始就设计好代码直接按照多主多从来编写用一些小技巧来避免复制延时问题并且还要解决多数据库数据是否一致可以自己写或者找现成的运维工具。 分片策略。总会有那么几个表数据量超大这时分片必不可免。分片有很多策略从简单的分区到根据热度自动调整依照具体业务选择一个适合自己的。避免自增ID作为主键不利于分片。 用存储过程是比较难扩展的这种情形多发生于传统C/S特别是OA系统转换过来的开发人员。低成本网站不是一两台小型机跑一个数据库处理所有业务的模式是机海作战。方便水平扩展比那点预分析时间和网络传输流量要重要的多的多。 NoSQL。这只是一个概念。实际应用中网站有着越来越多的密集写操作、上亿的简单关系数据读取、热备等这都不是传统关系数据库所擅长的于是 就产生了很多非关系型数据库比如Redis/TCTT/MongoDB/Memcachedb等在测试中这些几乎都达到了每秒至少一万次 的写操作内存型的甚至5万以上。例如MongoDB几句配置就可以组建一个复制自动分片failover的环境文档化的存储也简化了传统设计库 结构再开发的模式。很多业务是可以用这类数据库来替代mysql的。 八、缓存。数据库很脆弱一定要有缓存在前面挡着其实我们优化速度几乎就是优化缓存能用缓存的地方就不要再跑到后端数据库那折腾。缓存有持久化缓存、 内存缓存生成静态页面是最容易理解的持久化缓存了还有很多比如varnish的分块缓存、前面提到的memcachedb等内存缓 存memcached首当其冲。缓存更新可用被动更新和主动更新。被动更新的好处是设计简单缓存空了就自动去数据库取数据再把缓存填上但容易引发雪 崩效应一旦缓存大面积失效数据库的压力直线上升很可能挂掉。主动缓存可避免这点但是可能引发程序取不到数据的问题。这两者之间如何配合程序设计要多 动脑筋。 九、队列。用户一个操作很可能引发一系列资源和功能的调动这些调动如果同时发生压力无法控制用户体验也不好可以把这样一些操作放入队列由另几个模块 去异步执行例如发送邮件发送手机短信。开源队列服务器很多性能要求不高用数据库当做队列也可以只要保证程序读写队列的接口不变底层队列服务可随 时更换就可以类似Zend Framework里的Zend_Queue类java.util.Queue接口等。 十、文件存储。除了结构化数据我们经常要存放其他的数据像图片之类的。这类数据数量繁多、访问量大。典型的就是图片从用户头像到用户上传的照片还要生成不 同的缩略图尺寸。存储的分布几乎跟数据库扩展一样艰难。不使用专业存储的情况下基本都是靠自己的NAS。这就涉及到结构。拿图片存储举例图片是非常容 易产生热点的有些图片上传后就不再有人看有些可能每天被访问数十万次而且大量小文件的异步备份也很耗费时间。 为了将来图片走cdn做准备一开始最好就将图片的域名分开且不用主域名。很多网站都将cookie设置到了.domain.ltd如果图片也在这个域名下很可能因为cookie而造成缓存失效并且占多余流量还可能因为浏览器并发线程限制造成访问缓慢。 如果用普通的文件系统存储图片有一个简单的方法。计算文件的hash值比如md5以结果第一位作为第一级目录这样第一级有16个目录。从0 到F可以把这个字母作为域名0.yourimg.com到f.yourimg.com客户端dns压力会增大还可以扩展到最多16个NAS集群 上。第二级可用年月例如201011第三级用日第四级可选根据上传量比如am/pm甚至小时。最终的目录结构可能会是 e/201008/25/am/e43ae391c839d82801920cf.jpg。rsync备份时可以用脚本只同步某年某日某时的文件避免计 算大量文件带来的开销。当然最好是能用专门的分布式文件系统或更专业点的存储解决方案。 下面我们要谈谈代码了。 这一系列的最后一篇写给普通编程人员如果不感兴趣可直接看本文最后几段。开始设计代码结构之前先回顾一下之前准备过的事情我们有负载均衡的WEB服务器有主从DB服务器并可能分片有缓存有可扩展的存储。在组织代码的各个方面跟这些准备息息相关我一二三的列出来分别说并且每一条都以“前面讲到”这个经典句式开头为了方便对照。 别着急看经典句式我思维跳跃了插一段。实际开发中我们总会在性能和代码优雅性上作折中。对于当今的计算机和语言解释器多几层少几层对象调 用、声明变量为Map还是HashMap这种问题是最后才需要考虑的问题永远要考虑系统最慢的部分从最慢的部分解决。例如看看你用的ORM是不是做了 很多你用不到的事情是不是有重复的数据调用。我们做的是web应用开发不是底层框架API代码易读易懂是保证质量很重要的一方面你的程序是为了什 么而设计有不同的方法……算了这个话题另起一篇文章来说扯远了想交流可关注我的微博 http://t.sina.com.cn/liuzhiyi咱继续…… 前面讲到WEB 服务器是要做负载均衡的图片服务器是要分开的。对于这点代码在处理客户端状态时不要把状态放到单机上举例不要用文件session嗯常识。 如果有可能最好在一开始就做好用户单点认证的统一接口包括跨域如何判断状态、静态页面如何判断状态需要登录时的跳转和返回参数定义底层给好接口 应用层直接就用可参考GAE的 user服务。登录方面的设计要考虑移动设备的特性比如电脑可以用浮动层窗口但NOKIA自带的浏览器或UCWEB就无法处理这种表现形式程序一 定既能处理AJAX请求又能直接通过URL来处理请求。图片服务器分开资源文件最好也布局到图片服务器也就是WEB服务器只服务动态程序。虽然开发测 试时稍微复杂因为需要绝对URI才能访问但将来页面前端优化上会轻松许多并且你的WEB服务器IO优化也轻松许多。程序引用资源文件时要有一个 统一的处理方法在方法内部可以自动完成很多事情例如将css/js根据组合拼成一个文件或者自动在生成的URI后面加上QUERYSTRING 如果将来前端用了缓存服务那生成QUERYSTRING是最简单的刷新服务端缓存和客户端缓存的办法。 前面讲到 数据库会有复制可能会多主多从可能会分片。我们程序在处理数据的过程中最好能抽象出来单独放做一层。拿现在流行的MVC模式来说就是在M层下方再 放一个数据层这个数据层不是通常所说的JDBC/PDO/ActiveRecord等而是你自己的存取数据层仅对外暴露方法隐藏数据存取细节。这 个数据层内部不要怕写的难看但一定要提供所有的数据存储功能其他任何层次不要看到跟数据库打交道的字眼。之所以这样做是因为在单关系数据库的情况 下可能会SELECT…JOIN…或直接INSERT…INTO…可你可能会将一些表放到key-value数据库里存储或者分片这么做之后原来 的语句和方式要全部改变如果过于分散则移植时会耗费很大精力或得到一个很大的Model。在数据层面的设计上尽量避免JOIN查询我们可以多做 冗余多做缓存每种数据尽量只需要一次查询然后在你的程序里面进行组合。对于比较复杂的数据组合在实时性要求不高的情况下可采用异步处理用户访 问时只取处理后的结果。在对于主键的处理上避免使用自增ID可以用一定规则生成的唯一值当做主键这种主键是最简单的分片分布策略。即使用自增ID 也最好用一个自增ID发生器否则从数据库不小心被写了一下那主键很容易冲突。 前面讲到咱数据库前面还有某些缓存挡着。别把mysql的query cache当缓存应用稍复杂的时候QUERY CACHE反而会成为累赘。缓存跟数据库和业务结合的很紧密正因为跟业务关系紧密所以这点没有放之四海而皆准的方法。但我们还是有一些规则可参照。规 则一越接近前端缓存的颗粒度越大。例如在WEB最前端缓存整个页面再往后一层缓存部分页面区域再往后缓存区域内的单条记录。因为越靠近后端我们 的可操作性越灵活并且变化最多的前端代码也比较方便编写。在实践中因为产品需求变化速度非常快迭代周期越来越短有时很难将Controller和 Model分的那么清楚Controller层面处理部分缓存必不可免但要保证如果出现这种情况Controller所操作的缓存一定不要影响其他 数据需求方也就是要保证这个缓存数据只有这一个Controller在用。规则二没有缓存时程序不能出错。在不考虑缓存失效引发的雪崩效应时你的程 序要有缓存跟没缓存一个样不能像新浪微博一样缓存一失效粉丝微博全空整个应用都乱套了。在缓存必不可少的情况下给用户出错信息都比给一个让人误 解的信息强。规则三缓存更新要保证原子性或称作线程安全特别是采用被动缓存的方式时很可能两个用户访问时导致同一个缓存被更新通常情况这不是大问 题可缓存失效后重建时很可能是引发连锁反应的原因之一。规则四缓存也是有成本的。不只是技术成本还有人工时间成本。如果一个功能使用缓存和不使用 在可预见的访问量情况下区别微小但使用缓存会使复杂度增加那就不用我们可以加个TODO标注在下次迭代的时候加上缓存处理。 前面讲到文件存储是独立的那么所有的文件操作就都是远程调用。可以在文件服务器上提供一个很简单的RESTful接口也可以提供xmlrpc 或json serveiceWEB服务器端所生成和处理的文件全部通过接口通知文件服务器去处理WEB服务器本身不要提供任何文件存储。你会发现很多大网站的 上传图片跟保存文章是分两步完成的就是基于这个原因。 以上几条“前面讲到”其实无数人都讲过我也只是结合前几篇文章用自己的话重复了一遍真正分析起来精髓很简单——除了良好的功能逻辑分层我们 还要为数据库存储、缓存、队列、文件服务等程序外层资源调用单独设计接口你可以把你的程序想象成是运行在 Amazon EC2 上并用他的所有web service服务你的数据库就是它的SimpleDB你的队列就是他的SQS你的存储就是他的S3唯一不同是amazon的接口是远程调用你的是内部调用。 将支撑服务接口化意味着将MySQL更换到PostgreSQL不需要更改业务处理程序移植团队甚至不需要跟业务开发团队过多沟通意味着业务开发团队是对接口编程而不是对数据库编程意味着不会因为某个业务开发人员的失误而拖垮性能。 对程序扫盲不感兴趣的直接看这里—— 产品设计完了程序框架搭完了可能有矛盾在这个节骨眼儿产生了。不断有产品设计抱怨说他的创意没实现到预期效果有程序员抱怨说产品设计不切实 际。这种抱怨多缘于产品人员不懂技术技术人员不理解产品。从广义上来讲产品包含市场策略、营销手段、功能设计产品和技术在争论时往往把焦点放在功能 上而实际重点是实现这个功能所消耗的成本跟能这个功能带来的利益能否换算能否取其轻重。若可以争议解决。若不能则抛硬币看运气。因为一个功能的 加强而引发指标井喷或因项目拖延而导致贻误战机的例子比比皆是。激进的决策者注重利益保守的决策者注重损失聪明的决策者会考虑这个问题是否真的那么 严重。 关系到未来的事情谁都说不准要不怎么说创业一半靠运气呢。不过总有能说的准的事情那就得靠数据说话。 没有100%也有99.9%的网站安装了访问统计代码连我的 http://zhiyi.us 也不例外新闻联播也总说科学决策科学发展的。有了统计能确定的事情就很多了。例如可以根据来源-目标转化率来分析哪类渠道的人均获取成本低根据来 源-内容访问猜测用户跳出率原因根据用户点击行为判断链接位置是否合理等。将数据以不同方式组合起来找到内在联系分析内因外因制定对应策略减少 拍脑门决策。靠数据支撑运营是个非常专业的事情虽然不懂深奥的数学模型不会复杂的公式计算渐渐学会因为A所以B因为A和B所以C还是相对简单的。 全系列完毕。老话大半夜连抽烟带码字的挺伤身转载请注明出处 文章来源 http://zhiyi.us/internet/thinking-twice-before-building-your-site-one.htmlhttp://zhiyi.us/internet/thinking-twice-before-building-your-site-two.htmlhttp://zhiyi.us/internet/thinking-twice-before-building-your-site-final.html 转载于:https://www.cnblogs.com/wangbin/archive/2010/12/15/1906710.html
