从架构规划师的视点来看，架构便是一套构建体系的原则。经过这套原则，我们能够把一个复杂的体系区分为一套更简单的子体系的集合，这些子体系之间应该保持彼此独立，并与整个体系保持一致。快速开发框架把每一个子体系还能够继续细分下去，从而构成一个复杂的企业级架构。
一 挑选技能计划和物理架构
快速开发框架如何挑选技能计划和物理架构，对许多刚触摸渠道网站研制的人来说这或许是个头疼的问题。这些问题的源头很简单便是能否进步开发功率，使渠道具有高功用高负载性。就我遇到的常见的有这么几个问题：
a） 开发言语和数据库
一说到开发言语和数据库，许多人便开端做言语的比较，最常见的争论有：“asp.net和java哪个好”，“解释性言语和编译性言语哪个好”等。我个人觉的最关键是你和你的团队最拿手的开发言语和数据库是哪个，古语有云：“工欲善其事，必先利其器！”，趁手的开发言语和数据库有助于事半功倍。试想假如你挑选了一个并不很了解的言语，或许这个言语和数据库在基础功用上确实比你把握的言语好，可是在研制过程中学习曲线肯定长。而且遇到问题的时分由于不了解的原因，糟蹋更多的时刻去寻觅处理办法，而且找到的办法纷歧定是最好的，说不定还不如你自己用了解的言语处理来的快。
或许有朋友会说：“这几种开发言语和数据库我都了解”，那么就要看你对这几种开发言语和数据库的了解程度了，对各种开发言语和数据库的特性了解的越深化，越有助于进步开发功率。而且现在干流的开发言语和数据库都供给功用调优，只需深化了解了开发言语和数据库的特性和原理，那么功用调优就很简单。
个人觉的重要的就这两点，开发功率和功用。
b） 老练结构仍是自己实现
现在快速开发框架干流的开发言语的运用者中有许多前辈都供给了他们自己总结实现的结构，比方JAVA中的“S-S-H”组合，PYTHON的DJANGOO等。我个人的一些经历是，尽量运用开源的老练结构，由于渠道研制初期运用老练的开源结构，能进步开发功率，而且在质量上有保证。我曾经接手过一个渠道的改版，结构是前面开发人员自己写的，里边的一些规划思想不是很老练，导致渠道在负载增高后功用很差，整改起来很费事，只能一点一点的分离出来，耗费时刻和经历。
有的朋友或许会问什么才是老练的结构，个人总结的几点：
1 能供给运用指南，比方 COOKBOOK， USE GUIDE等。有这些供给，那么入门运用变的简单，也方便保护，而且有助于深化了解其特性和原理。
2 有官方支撑，比方官方评论社区，邮件列表等，而且有BUG搜集处理机制。有句话叫大树底下好乘凉，有了官方支撑，当运用过程中遇到问题的时分，直接就能够经过查找前人的运用心得和问题来处理问题，遇到BUG的时分，提交上去，也能找到处理之法。
3 官方在不断的更新发布安稳版别。这一点很重要，官方假如及时帮你处理现在已知的或许不知道的BUG，那么对运用者来讲，就没什么后顾之忧了，假如官方停止更新了，那么我主张仍是早点换下家吧，由于假如这个结构好，那么肯定会越来越好，官方也会不断的更新它。还有便是安稳永远是第一位，能够在不影响出产环境的状况下进行无缝晋级更新。
4 身边运用者许多，常常能看到相关的评论或许总结。现在许多老练结构都是国外开发者发布的，假如运用者E文不好也是个厌烦的事情，那么假如身边有许多同样的运用者和许多评论，那么关于运用者来说是种福音，共同讨论和学习。
那么除此之外最好是开源的结构，渠道初期拜访量不大，因而对功用的要求不高，老练的结构的运用都不会呈现什么问题。当拜访量急剧增高之后，那么功用要求也变高，一些结构中躲藏的问题也因而呈现。这时分假如是开源的结构，运用者能够深化了解它的源代码，洞悉其实现机制，依据自己的实际状况进行调优。假如不是那么运用者也只能改变方向去处理问题，条条大路通罗马。
c） web server/db server/cache server 相关
在快速开发框架架构规划中web server/db server/cache server是很重要的一点，我个人觉的这一块有必要是运用具有前瞻性，易装备，能监控和保护的产品，总结的几点：
1 丰厚和深化的装备选项。假如能供给丰厚和深化的装备选项，那么在安全和功用调整上能够很方便的进行操作，而且不中断实际的出产环境。
2 依据高并发模型。比方这几年热门的依据epoll的nginx，能够有用的削减连接处理时刻，增大一起并发数。
3 支撑负载均衡和恳求分发。当渠道的拜访量增高之后，单台服务器肯定是很难支撑，这时分就需求增加服务器来分管压力，这时分server的负载均衡和恳求分发就很重要了。
4 高效的缓存机制。高效的缓存机制能够帮助渠道进步负载能力，削减重复资源的读取和处理时刻。比方用于小文件缓存的SQUID，VARNISH，用于数据库缓存的memcached等。
5 实时的状态监控机制。实时的监控状态陈述，能够有助于渠道保护人员迅速了解渠道功用运行状况，依据状况进行调整。
假如是开源的那就更好了，能够深化了解其源代码，并依据自己的实际需求进行装备和定制。
d） 操作体系
挑选适宜的操作体系，个人觉的最主要是安稳安全，易办理和保护，易监控。安稳安全的操作体系一般官方会持续的发布补丁和新版别，处理BUG和漏洞等。而且官方或许第三方会不断的供给新的办理保护监控工具，而且能让办理保护人员经过编写脚原本保护办理。而且适宜的操作体系能让研制人员充沛运用其特性，发挥渠道的最大功用。
f） 物理架构
这儿的快速开发框架物理架构是指服务器的树立方法。有的朋友或许资源有限只需一台服务器，有的朋友资源充沛有十几台服务器或许更多，我个人觉的这都不是问题。渠道初期的话，我想大部分拜访量都不高，web server/db server/cache server放在一台服务器上都没问题。可是自己心里最好能预估一下这个渠道会发展到什么样的规模，在做架构规划的时分，依照事先预估的来决定怎么做物理架构，并为以后的架构晋级做准备。说到这儿，想到前百度架构师雷鸣说过的一句话，当你的会员数达到现在的5倍或10倍的时分，架构就要晋级。
二 渠道研制
前期做好了技能计划，就进入到实质研制过程中来了，个人感觉渠道网站的研制有别于传统的IT项目研制，由于曾经便是客户/需求剖析人员/美工之间进行交涉，而现在渠道网站研制会多触摸一个角色叫产品，产品决定了最终的渠道网站是什么样的，有什么功用，每个功用的流程和用例是什么样子的，也便是原型规划。而且在研制人员实现之后，还要由测验人员进行测验。关于原型规划，请看我的别的一篇文章《项目需求原型规划》。
在上述过程中，产品会常常要求研制人员：“某某功用是这样的，你赶快给我实现并处理。这个功用不对，要改。那个功用呈现问题，要改”，而研制人员或许正在忙着其他功用的实现，于是很简单产生冲突。在此我推荐运用灵敏开发方法，树立短的发布周期进行迭代开发，产品提出来的问题一致在一个周期内处理，到下一个周期一起发布，到下一个周期再进行下一周期的功用改进和BUG修正。并运用JIRA这种老练的项目办理体系进行办理，为曾经的更改留下历史，总结经历。
那么在正常的研制过程中，特别是团队研制，我个人觉的需求注意的几点：
1 适宜的开发工具。仍是那句话“工欲善其事，必先利其器！”，运用适宜的开发工具和插件，能进步开发功率，节省开发本钱。团队运用一致的开发工具，能够削减犯错的几率，防止版别冲突等。
2 如何操控代码质量。由于团队里我们的水平有高有低，所以团队研制的时分，需求去树立固定的开发标准，比方：“命名标准”，“代码包引证标准等”。当某个人处理某个功用的时分，为了保证代码质量和削减犯错几率，最好能画出流程图和配上规划目的说明，来进行评论确认，一起也能够帮助新人快速生长。
3 快速开发框架需求引进新结构。有时分，某个成员会觉的某某结构的新特性十分好用或许十分适宜手头的问题，那么就想引进这个新结构，我的主张，在充沛了解的基础上来决定，不能由于某个特性而引进一堆用不到的特性，那样会让项目代码显的冗余。
4 常识总结和培训。当某个成员遇到问题，并处理后或许学习到新东西的时分，无妨拿出来我们一起讨论一下，说不定就有助于进步渠道的功用，为我们供给更好的规划思路。
三 架构优化
“过早优化是万恶之源”，所以关于架构优化，我放在研制完成并上线之后来讲。个人觉的没有百分百可用的架构，得看你实际的业务流程和运行状况来进行优化。当你运行了一段时刻后，搜集到必定的数据，找出功用的缺点后进行针对性调整和优化，当渠道的负载强度达到必定程度，就得立即着手做架构晋级。
有的朋友会问，有时分网站便是莫名其妙的变慢，可是不知道从何下手怎么办，或许凭经历改改这个改改那个选项，好了一点但好的不完全。我的经历是从数据开端，从最外围开端画圈，找到源头。先从外围开端搜集日志，比方access_log拜访日志或sql_log数据库操作日志，找出拜访最多的10条日志和执行时刻最长的10条日志，然后依据日志去反查究竟是什么引起的操作，然后一条条的处理。假如处理不了，那么就考虑重构。其他问题处理方法跟这个差不多，就不赘述了。从我自己已有的经历来看，往往便是由于几个功用点的恶化，引起了全体的功用变差。
所以在研制的时分，功用点的实现要好好考虑，前端部分，页面，图片等的巨细和有用缓存，后端的局部数据和大局数据的缓存高效运用，数据库层SQL句子尽量防止跨表查询，数据库索引的运用等。
四 其他相关
存储
当渠道网站的拜访量不断增加的一起，数据也会跟着不断的增加，所以前期做好数据如何存储的计划十分重要。
现在比较常见的是HASH URL，依据文件名的HASH来挑选存储不同的目录，比方20091014131213_abc.xxx 那么就存储到 2009/10/14/a/20091014131213_abc.xxx这样的目录下，方便以后依据目录来区分服务器。
查找
当快速开发框架渠道网站的拜访量不断增加的一起，数据查找也变成了一个问题。肯定有朋友会说，直接数据库模糊查询有什么问题，你试想当你的数据表里有几百万数据你用select * from table where title like '%key%' 没法用索引，那便是全表扫描，拿得花多少时刻，一个人查询还没问题，那几百个呢，那你的渠道不就歇菜了。还好现在已经有了老练计划Lucene，只需依照它供给的接口去实现，你就能够运用。
