接着上篇的继续

在做扩展满足了基本的性能需求后，我们会逐渐关注“可用性”（也就是我们通常听别人吹牛时说的SLA、几个9）。如何保证真正“高可用”，也是个难题。

几乎主流的大中型互联网公司，都会有用到类似的架构，只是节点数不同而已。

还有一招用的比较多的，那就是动静分离。可以需要开发人员配合（把静态资源放独立站点下），也可以不需要开发人员配合（利用7层反向代理来处理，根据后缀名等信息来判断资源类型）。有了单独的静态文件服务器之后，存储也是个问题，也需要扩展。多台服务器的文件怎么保持一致，买不起共享存储怎么办？分布式文件系统也派上用场了。

还有一项目前国内外用的非常普遍的技术CDN加速。目前该领域竞争激烈，也已经比较便宜了。国内南北互联网问题比较严重，使用CDN可以有效解决这个问题。

CDN的基本原理并不复杂，可以理解为智能DNS+Squid反向代理缓存 ，然后需要有很多机房节点提供访问。

截止目前为止，都没有怎么去改动应用程序的架构，或者说通俗点，都不怎么需要大面积的修改代码。

如果上面那些手段都用光了，还是支撑不住怎么办？不停的加机器也不是办法啊？

随着业务越来越复杂，网站的功能越来越多，虽然部署层面是采用的集群，但是应用程序架构层面还是“集中式”的，这样会导致很多耦合，不便于开发、维护，而且容易“一荣俱损”。所以，通常会把网站拆分出不同的子站点来单独宿主。

应用都拆了，由于单个数据库的连接，QPS，TPS，I/O处理能力都非常有限，DB层面也可以去做垂直分库操作

拆分应用和DB之后，其实还是会有很多问题。不同的站点，里面可能会有相同逻辑和功能的代码。当然，对于一些基础的功能我们可以封装DLL或者Jar包去到处提供引用，但是这种强依赖也很容易造成一些问题（版本问题、依赖关系等处理起来非常麻烦）。这样，传说中的SOA的价值就得到体现了。

应用、服务之间还是会出现一些依赖问题，这时候，高吞吐量的解耦利器出现了

最后，还介绍一个大型互联网公司都用的绝技--分库分表。个人经验，不是业务发站和各方面非常迫切，不要轻易走这一步。

因为分库分表谁都会干，关键是拆完之后怎么办。目前，市面上还没有完全开源免费的方案，能让你一劳永逸地解决数据库拆分问题。