从技术角度讲解网站是如何从小成长起来(5)
我们来分析一下我们的业务。
其实我们的业务大多可以分为两类：
一、与实际的产品相关的业务，比如：blog、news等等。这些业务之间的耦合度不是很高，往往可以通过提供HTTP的接口即可实现业务需要的互通。因此，从这个层面上来看，是可以基本做到业务垂直拆分的。
二、基础服务，比如：用户帐号管理、消息通知等等。这些服务往往被多个业务所依赖。他们需要提供更通用的、更安全的、更稳定的接口和服务。但是，关于基础业务的理解和划分，是没有一个特定的规则的。比如，image图片服务，他有可能刚开始是一个业务服务，到一定阶段以后，多个系统需要对他有强的依赖，自然也就成为了一个基础服务。
所以，从上面的描述，我们可以发现服务的类型，并不是固定的。要很好的解决服务耦合的问题，也并没有一个十分完美的解决方案。我们能做的就是尽量降低耦合，通过某种方式，能够很好的达到耦合和可维护性的平衡。
总的来看，MVC模式其实给我们提供了一个比较好的方案。
我们把系统从两个维度上进行划分：垂直（业务）和水平（逻辑）。
我们做了这样的划分以后，似乎看起来没有实质性的改变。但是，我们可以明确了我们设计的原则，并强化了代码的可复用性。另外，最关键的是，服务之间的依赖和耦合关系，有了明确的地方来做。同时，我们还可以将业务内部的结构进行拆分，更好的增强复用。
数据访问和组织层、数据存储层，这两个位于下游的层次，应该是属于系统内部的层次，原则上是最好不要对外开放接口的，否则，系统间的耦合就会非常的大。并且可维护性会非常的难。而逻辑控制和视图层，实际上是提供对外（对用户或者是外系统）最好的访问的入口。当然，这个入口可以是HTTP协议的，也可以是非HTTP协议的。
比如，对于account服务，可以提供基于HTTPS对用户开放的login和logout服务，也提供基于XXX Protocol数据交换的协议的给内部的get_session服务。从简单的设计上来看，只是根据服务不同，提供不同的数据交换格式、以及不同的安全控制。这样也是秉承了一个高内聚低耦合的原则。
这里还有几个及其重要的问题没有详细的提及：系统内外的数据传输协议、接口API、服务访问定位。这几个问题实际上还跟运维问题紧密相关，都会放到后面来详细讨论。
【第十阶段：数据存储优化】
在前面的阶段中，我们都使用数据库作为默认的存储引擎，很少谈论关于关于数据存储的话题。但是，数据的存储却是我们现在众多大型网站面临的最核心的问题。现在众多网络巨头纷纷推出自己的“高端”存储引擎，也吸引了众多的眼球。比如：google的BigTable、facebook的cassandra、以及开源的Hadoop等等。国内众多IT巨头也纷纷推出自己的“云”存储引擎。
其实这些存储引擎用的一些关键技术有许多的共性，比如：Meta信息管理、分片、冗余备份、数据自动恢复等。因为之前我也做过一些工作和研究，但是不是特别深入，不敢在此指手画脚、高谈阔论。相关的资料网上比比皆是，大家有兴趣有search吧。^_^
关系型数据库常用的有几个，比如：MySQL、PostgreSQL、SQLServer、DB2等，当然还有NB的Oracle（唉，作为DB科班出生的屌丝，没有真正意义上使用过这样的高帅富数据库，惭愧啊）。
互联网使用频率最高的应该要算是MySQL。最重要的是开源；其次是他提供的一些特性，比如：多种存储引擎、主从同步机制等，使用起来非常的方便；再次，就是一个单词：LAMP，几乎成为搭建网站的必备利器；还有，较高服务的稳定性。
关系型数据使得建立网站变得及其轻松，几乎是个网站都会有一个数据库。试想一下，如果没有这种通用的关系型数据库，我们的生活会是怎么样的？
关系型数据库在95%的场景下是工作的非常好的。而且只要配置得当、数据切分合理、架构设计符合要求，性能上是绝对能够承受业务的需求。现在很多大型网站的后台，几乎都是数据库作为标准的存储引擎。
另外，最近炒的比较热的一个概念就是NoSQL。说起来，其实就是放弃关系型数据库中许多的特性，比如：事务、外键等等。简化设计，将视线更关注于存储本身。比较有名的，比如：BDB、MongoDB、Redis等等。这些存储引擎提供更为直接的Key-Value存储，以满足互联网高效快速的业务需求。其实，从另外一个角度来看，关系型数据库（比如MySQL），如果不使用那么多的关系型数据库特性，也可以简化成KV模式，提升效率。
不过，有些时候，为了节省机器资源，提升存储引擎的效率，就不得不开发针对业务需要的专用存储引擎。这些存储引擎的效率，往往较关系数据库效率高10－100倍。比如，当一个图片服务，存储的图片量从1亿到10亿，甚至100亿；现在流行的微薄，假如发布总量达到10亿或者100亿。这样级别的数据量，如果用数据库来存储固然可以，但是有可能需要耗费相当多的机器，且维护成本和代价不小。
其实分析我们通常的业务，我们对数据的操作无非就是四个：查、插、删、改。对应数据库的操作就是select、insert、delete、update。那自己设计的存储引擎无非就是对这四个操作中的某几个做针对性的优化，让其中几个根据不同的业务特点，使其变的更加的高效。比如：对于微薄而言，可能就需要插入和查询具有很高的效率，而删除和修改的需求不是那么高。这个时候，就可以牺牲一部分删除和修改的性能，而重点放在插入和查询上。
在业务上，我们的提交通常可以看作在某一个维度上是有序的。比如，每一个微薄或者博客可能都会有一个id，这些id可能是按照序列递增、或是时间递增等。而查询的时候，则是按照另外一个维度的顺序组织的，比如：按关注的人组织微薄的信息。这样就造成了一个冲突，就是提交的组织顺序和查询的组织顺序不一致。
再来看看我们的磁盘。我们现在常规磁盘还是机械方式运转的：有盘片、有磁头等等。当需要写入或者读取的时候，磁头定位到不同的盘片的不同扇区上，然后找到或修改对应的信息。如果信息分散在不同的盘片、扇区上，那么磁头寻道的时间就会比较长。
反过来，我们再来看看我们的业务和磁盘的组织。A、如果我们按照写入有序的方式存储数据，那么磁盘会以很高的效率，将数据连续的写入到盘片中，无需多次寻道。那么读取的时候，可能就会出现按照另外的维度来组织数据，这样就有可能需要在多个地方来读取。从而造成我们磁盘来回寻道定位，使得查询效率低下。B、如果我们按照某一种查询维度来存储数据（因为同一业务往往有多种查询模式），那读取的时候，就让磁盘顺序读取即可。但带来的麻烦就是，写入的时候有可能需要反复的寻道定位，将提交的数据一条条写入。这样就会给写入带来麻烦。
其实矛盾的主体就是：僵化的磁盘存储方式不能满足网站日益增长的提交和查询需求！
是否有解决方案呢？那必须有！
要解决这个问题，可以从两方面入手。
1、改变现有的磁盘存储方式。随着硬件快速的发展，磁盘本身的效率得到了极大提升。磁盘的转速，盘片的个数等都大幅增加，本身寻道的速度提升很快。加上缓存等的加强，效率提升还是很明显。另外，Flash Disk、Solid State Disk等新技术的引入，改变了原来的随机读取的低效（没有数据，根据经验，Flash或SSD的效率可以达到10－100倍普通硬盘的随机访问的效率）。
2、根据不同的业务，有效的组织数据。比如微薄（我没有写过微薄，但是做过微薄类似的东东），因为读取业务组织的维度是按人，而提交组织的维度则是时间。所以，我们可以将某个人一段时间提交的数据，在内存里面进行合并，然后再一次性的刷入到磁盘之中。这样，某个人一段时间发布的数据就在磁盘上连续存储。当读取的时候，原来需要多次读取的数据，现在可以一次性的读取出来。
第一点提到的东东现在也逐步的开始普及，其实他给我们的改变是比较大的。不用花太多的精力和时间，去精心设计和优化一个系统，而只需要花一些钱就能使得性能大幅提升，而且这样的成本还在降低。
但是，资源永远是不够的。多年前，当内存还是64K的时候，我们畅想如果内存有个32M该多美妙啊。但是，随着数据的膨胀，即使现在64G内存，也很快就不能满足我们的需求。
所以，在一些特殊的应用下面，我们还是需要更多的关注第二个点。
对于存储优化，一直是一个持久的话题，也有很多成熟的方案。我这里可能提几个点。