从架构设计师的角度来看，架构就是一套构建系统的准则。通过这套准则，我们可以把一个复杂的系统划分为一套更简单的子系统的集合，这些子系统之间应该保持相互独立，并与整个系统保持一致。而且每一个子系统还可以继续细分下去，从而构成一个复杂的企业级架构。
一 选择技术方案和物理架构
如何选择技术方案和物理架构，对很多刚接触平台网站研发的人来说这可能是个头疼的问题。这些问题的源头很简单就是能否提高开发效率，使平台具有高性能高负载性。就我遇到的常见的有这么几个问题：
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这样的目录下，方便以后根据目录来划分服务器。
搜索
当平台网站的访问量不断增长的同时，数据搜索也变成了一个问题。肯定有朋友会说，直接数据库模糊查询有什么问题，你试想当你的数据表里有几百万数据你用like没法用索引，那就是全表扫描，拿得花多少时间，一个人查询还没问题，那几百个呢，那你的平台不就歇菜了。还好现在已经有了成熟方案Lucene，只要按照它提供的接口去实现，你就可以使用。
