网站设计控制流和数据流

1. Database
数据存储历来是麻烦，尤其是需要存储海量数据的时候，往往单个数据库容量不够，甚至一个数据库集群也不够。常见的解决办法是分割，譬如按用户ID把海量数据分割成若干块，每块存储到一个独立的数据库里去。但是分割的做法降低了join操作的效率。
Google Bigtable的效率如何？好处是什么，缺陷是什么？Bigtable对什么样的情景最适用？根据Bigtable原理实现的开源软件，Hadoop/HBase的运行效率如何？
2. Cache
用户访问网站时，通常读的操作比写的操作更频繁。为了提高读的操作，不妨把相关内容缓存到内存里，减少Disk IO的消耗。
MemCached 最近大热，Wikipedia， YouTube， Digg， Twitter等等大型网站都在用MemCached作为缓存工具。SquidCache和Varnish等等工具，也与缓存沾边。Twitter的做法是把MemCached和Varnish结合起来，同时使用。什么样的内容，应该用什么样的缓存工具？不同的工具间如何协调？各大网站的实际运行的结果，有哪些经验和教训？
3. File System
有些内容，既没必要存放在数据库里，网站设计也不适合存放在缓存中，譬如log 和images。在这种情况下，我们需要文件系统。当有海量内容需要存放在文件系统中时，我们需要使用分布式文件系统。Google File System对于什么样的情景适用，什么样的情景不适用？分布式文件系统常常需要相应的锁机制，保证并发的读写操作不相互干扰。Chubby有什么好处？什么情形下不适用？
据说MogileFS更适合存储大量的，但是单体尺寸不大的文件，譬如images。而Google File System更适合存放大尺寸但是数量不多的文件。有没有可能把小尺寸的多个文件，合并成一个大文件，然后存储到Google File System中去。在这种情况下，比较MogileFS与Google FS的性能，是否有高下之分？
4. Thread Management
一套工序通常由若干任务组成。多线程的办法是由一根线程全权负责整套工序的操作。另外一个办法是把工序斩成几段，每一段由一根或几根线程负责，这种办法称为工作台。
常见的是多线程的办法。但是工作台的做法有利于集中计算资源处理繁重的任务，避免瓶颈的出现。但是缺陷是需要在不同线程之间，传递记录中间状态的数据。什么样的情形适合用多线程，什么时候用工作台？
5. Scheduler
同一个网站通常会提供多种服务，不同的服务需要调用不同的业务逻辑。有些业务逻辑可以在同一台服务器上完成，但是当业务逻辑复杂的时候，需要调用多台服务器合作完成。不同服务的受众对象不同，流量也不同，不同时段的流量也不同，同一时段不同服务的流量也不同，所以需要动态地分配计算资源。这是 scheduler的工作。
Scheduler给不同服务器分配工作时，最简单的办法是启动预先安装在该服务器上的相关程序。由于不能保证每个程序都十分完美，当一个程序发生错误时，应当避免整个服务器因此而崩溃，影响其它工作的正常进行。是否需要动用virtual machine，实现各个不同工作之间相互隔绝？
6. Signal Flow and Data Flow
大型网站后台系统经常由众多服务器组成，网站设计服务器与服务器之间时不时会发生数据交换，譬如Web Server解析完用户请求后，把请求转发给某一台App Server，这一台App Server完成了部分工作后，把中间数据转发给下一台App Server。而第二台App Server完成任务后，整个工作就结束了，结果应该返回给Web Server。
问题是如何让第一台App Server如何知道应该把中间结果给第二台App Server，而第二台App Server又如何知道它的目的地是Web Server？一个比较有效率的做法，是区别数据流和控制流。Server与Server之间常设通道，专供控制流使用，传递指令去控制数据流的发送。数据流不占用控制流通道，只有在需要时，才建立数据流的通道。
控制流和数据流的组织，需要结合具体的业务逻辑，才能优化设计，减少带宽消耗，缩短数据传输的时间。
7. Instrumentation
网站后台各个部分是否运转正常，哪里是瓶颈，哪里空闲。这些都需要实时监控。不仅及时避免整个后台系统的崩溃，而且可以分析各个部分运行的规律，从而找到优化系统的途径。
问题是，应该选用什么样的监控工具，才能够尽量减少对系统程序的干扰，同时提供有价值的信息？
8. Anti-abuse
通常网站面对的是形形色色的用户，绝大多数用户的行为是友好的，但是不排除少数用户蓄意恶作剧。如果事先没有设计防范措施，少数恶意用户的胡作非为，会干扰其他用户享受正常的服务。
问题是，如何防范并且及时制止恶意行为的发生？
9. Exception Handling
不论预先设想有多周密，实际运行时，总会遇到这样那样的意外情况。譬如敏感词的出现，往往事先没有征兆。所以，在设计系统架构时，应该给网管提供必要工具，应付突发事件。

一句话，要不要标准规范？绝对要！网站设计站点大了嘛，内容多了嘛，涉及的方面和参与的人员广了嘛，不建立一套标准和规范怎么行？对这个有异议或不肯定的同行们可去读一读阿里、淘宝、雅虎等的ued博客，国内这些大的网站UI部门运作的相对成熟。

产品和UI的前期
以我所在单位房价网为例，UI框架标准规范的建立并不是一开始就花时间做这个东西，而是网站发展过程中逐步制定和完善起来的，早期，在产品策划上可能是个模糊未很成型的东西，这时候ui是与产品及公司高层的详尽沟通下，尽可能的了解他们的愿望及暂时可用的质料对产品进行定位，比如是做行业门户、新闻资讯、企业形象、社区、电子商务、功能服务等等，各种类型的网站在UI设计的思想上都不同，进而在后面细节上都有非常大的区别和取向。这个定位是个大方向上的，这点最好公司上下不要含糊。然后分析网站的受众和服务群体，美工在脑中初步对设计风格、色彩有个把握。有了这些酝酿和准备，再根据提供的产品原型设计出平面稿，待产品和高层审稿修改确认后制作demo，如果有UE人员，将对demo进行评审，确认后交由功能开发上线。

制定标准规范的时机
这个阶段是网站最初版本上线，设计开发告一段落，那这个时候是做标准规范的时机，因为早点时候所有东西都是新的未经受用户客户的考验，许多东西没法做成定标准和规范，而再往后就会进入东西多头绪乱甚至回头修改设计和代码以符合标准的状态。所以这个时候制定UI框架的标准和规范比较合适，可能这个标准的制定会耗很长的时间和资源，甚至某些组件没法制定标准，这都是值得并且有必要去做的，这是个最初UI的构想和规范网站设计，是要后面不断去完善的。磨刀不误砍柴功!