网站设计的域名品牌

一定要设计好一个站的域名品牌-为品牌而建站你永远快乐。
　　如果域名品牌没构建好就建站的话那么你就失败了一半，回想刚开始注册域名的那情景，首先那个时候年轻冲动，初生牛崽不怕虎，很冲动地注册了一些自认为很有百万级别的域名，其实这种思想正常，但后来逐渐发觉自己的域名很没常规，很没大站味道，才觉悟一站的品牌域名是如此的重要。如果你想知道一个网站的域名品牌建设性的重要，那么我认为你应该很认真地看一看我这篇文章，或许你会收益良多，当然你也可以大胆质疑，当你带着批判性去阅读一篇文章的时候，那就说明你的阅读能力已经到达了某一程度。胡适之曾经这么说过，阅读，就要带有质疑地去吸取知识，去粗取精。是的，人就是要这样阅读。下面来说下，我所要表达的品牌概念。

　　什么叫做品牌?品牌是一个名称、名词、符号或设计。品牌是否有规律可循?品牌其实不一定是生活的常用词语，比如“海尔”“孩儿”，为啥他不叫大家通俗易懂的“孩儿”，而叫叫做“海尔”?其实这就是品牌建设。品牌往往不一定是常用词汇，而很可能是一些组合词语，尽管开始你读的有点拗口，但当你发觉读起来了，时间久了，之所以为品牌已经凭借莫须有的理由。举个例子，google开始想中文名，想着一个谷歌，而不叫做骨骼，其实这就是一个新词语的绗生。同时也会是一个品牌。再比如，校内，或许校内以前是一个不记载在字典里的词语，字典里并没有校内的具体解释。而校内，现在已经是一个知名SNS站，校内已经可以说逐渐是一个品牌。

　　或许，在很多年前，一个推销员可以拿下几万单的生意网站设计，但是现在，是靠什么去推销呢，还是推销员吗?非也，我认为是靠品牌在推销。我们将心比心地想一下：就算假如你推销一个不知名的产品，你用到100个推销员去上门推销，未必能比得上一个品牌放在那，自然有人去购买。所以，而现在真正成功的经营大师手上的皇牌就是他手上所握的是品牌。同样的道理，如果你将一个站，姑且你不会是一个想浪费光阴的人，你想将你的站建设成为品牌的话，那么我认为你一定要为你的网站选取一个好名字，不管是创意与否，不管那词语不常见与否，不管那词语司空见惯与否，我都认为你必须为你的域名设计一个好概念，这个好概念，就是产生你品牌的关键。

　　当你确立好你的品牌后，你之后所做的工作，不单单是为钱，而是更为了比钱更高尚的东西，创建一个品牌的影响力而工作。朋友，说到这里，我想你已经开始热血沸腾，我想你的思绪已经激波荡漾，我想你的目标已经腾程万里。为品牌而建站。所以，一定要设计好一个站的域名品牌，这样你会感觉为自己的站品牌建立而做站而感觉到愉快，在享受这品牌诞生的过程。

如果说1980年代是PC的时代，1990年代是互联网的时代，那么当下呢？当下是移动互联网的时代。移动互联网的基本要义，一言以蔽之，就是把手机与网站相连，每部手机在网站上都有独立的个人空间，成为手机的镜像。
一部小小的手机里面，可能同时装载着数十个软件。而且在同一时刻，可能好几个软件在同时运行。另外，还得时刻准备暂停运行，把手机CPU等资源让给电话通话等优先级别高的工作。还有，时刻需要准备应付网络连接中断，手机电池耗尽等等情况。总之，手机软件的结构设计，是做小的艺术。
移动网站的架构设计，网站设计与手机软件的架构设计有着本质的不同。如果说手机软件的特点在于小，那么网站的特点在于大。仅中国就有几亿手机用户，作为服务于移动业务的网站，它的质量来自于是否能够同时为大规模并发用户提供服务，是否能够处理海量数据，是否能够在需要扩大网站吞吐量的时候，只需要增加机器，而不需要对网站架构做大手术。这是做大的艺术。
提到做大规模网站，大家一定会想到云计算，想到Google File System，Chubby， BigTable，MapReduce等等。这些技术固然很好，但是它们仅仅是构成一个大型网站的技术要素。实际构建一个大型网站时，光知道技术要素是不够的，还得明白如何把各个要素有机地结合到一起。
“Flickr 网站架构研究”（http://www.ccthere.com/article/2357486）是一篇值得反复阅读的好文章。这篇文章不仅对一个大型网站的架构进行了系统解剖，逐条梳理，而且行文深入浅出。可惜这样的文章不多见。关于大型网站实例的讨论，散落在各处，而且内容零散。
学习和掌握构建大型网站的架构，需要汇总散落的文章，梳理零散的内容。做好这项工作很有意义，但是也比较困难。我们的体会是，不妨抓住以下几个主题，逐个分析大型网站的实例，然后横向比较。

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的性能，是否有高下之分？