上次说的“分”是一个比较大的原则也是一个比较高层的原则，这次我想说一下其它两个原则：并与换。

并

为什么要分？是因为我们希望通过分来提高系统的承载能力，那并又是并什么呢？我想了一下有几个方面可以并：

1.       合并用户请求，最基本的就是合并CSS/图片/脚本，还可以合并页面。不过合并就可能产生流量的浪费，需要有一个平衡点。

2.       合并接口的粒度，如果做分布式应用的话，我们可能不会直接访问数据库而是调用应用层提供的接口，由于是网络调用，代价比较大，因此在设计的时候尽量提供粒度比较粗的接口，一次调用返回比较多的数据，而不是细化到添加删除修改的层次。

3.       合并接口的部署，对于频繁的跨机器调用可以考虑有一些数据冗余，把跨网络的服务编程进程间通讯，甚至转到客户端来做。比如论坛发贴时候脏词的过滤，直接调用应用层提供的接口（跨机器）是可以的，但是可能代价比较大，可以把这个接口使用IPC方式部署在本机。

换

时间换空间，空间换时间是常见的做法，具体一点说：

1.       缓存。缓存的重要性早计算机的硬件中就有重要的体现。对于网站，有很多种缓存，可以是客户端资源的缓存，可以是页面输出缓存，也可以是应用层的数据缓存，目的都是一样的，或是减少了服务器请求次数，或是减少了请求的处理过程，或是减少了数据库的访问次数。当然，生成静态文件也可以算是一种缓存。不访问磁盘固然不可能，但是我们要极大限度降低磁盘访问的机会。

2.       有的时候为了获取极快的响应，我们还会不惜代价采用重复计算。比如，我们的某个操作很可能会由于网络问题等原因响应比较慢，在设计的时候可以有一个统一的处理接口，由这个接口分发到不同的服务器去异步实现这个操作，哪个服务器先返回了结果我们就用这个结果，然后杀死其他服务器的冗余操作。

3.       网站一般追求比较快的响应，一般不太会在比较高的层次用时间来换取空间，但是在一些用户独有数据的处理算法上可能还是会考虑到空间的节省问题。

4.       有的时候我们会用一些聚合表来存放聚合数据，也就是进行一些预计算提高复杂计算（比如报表）的性能。当然，对于数据分析，构建多维数据库也是一种不错的选择。

有很多网友留言说说的比较粗，没有什么具体的东西。我觉得架构这个东西很难去说具体怎么做，因为具体实施的时候要看情况去应用的，由于没有完美的东西，所以做架构通常是去做一个平衡，很可能某一个侧重不同会影响到架构的实施。希望我的这些文章能给大家一个提示的作用，看了之后如果你觉得“这点我倒没有考虑到，以后要注意”那或许就是最大的帮助了，下面我想说一些其它方面的问题，每一条都很零散，算是一个补充吧：

1.       到底是采用已有的东西还是自己去做需要详细考虑的，采用别人的东西可能比较稳定，但是自己的控制少了一点，采用自己做的东西可以很灵活，但是可能会问题比较多。不管怎么样，我们在采用一个第三方框架的时候务必要进行缜密的调查，看到他的不足，否则项目很可能在后期被这个框架制约，反之，决定自己去做一个框架的时候也要看到自己需要什么其他框架不能提供的东西。

2.       数据传输的时候可以做压缩，但要考虑到压缩解压缩需要CPU资源，在IO（磁盘，带宽，传输能力）和CPU之间有一个平衡的考虑。

3.       理想的可伸缩性架构是可以自由增加或替换服务器，无需去停机维护或做很大的调整。在使用一个统一的调度中心来调度这些服务器，分配请求的时候，我们要考虑一下调度服务器能承受多少流量。

4.       使用大量的廉价服务器还是少量的高配服务器？如何根据需求来组合服务器发挥最大作用。

5.       对于分布式构架，我们尽量让每一个节点保持简单的逻辑，尽量减少同一层次节点之间的依赖，另外。需要有统一的地方来管理所有的节点。

6.       功能分解、使用异步进行整合、故障转移、失效保护。

7.       软件的架构升级和计算机硬件的架构升级很像，可能有一段时期，我们是在慢慢提高整体能力，2年也才提高了几倍，之后发现只有通过某种彻底的架构改变才能提高数十倍的能力，升级之后，我们或许又会遇到其他问题。就像CPU，是简单提高主频还是彻底更换架构。

8.       数据方面，读写分离、数据库分隔、功能划分、缓存、镜像。

9.       硬件网络上的架构很重要，但软件开发中的一些细节不可忽略，好的架构不意味着不需要代码审阅。