在作扩展知足了基本的性能需求后,咱们会逐渐关注“可用性”(也就是咱们一般听别人吹牛时说的SLA、几个9)。如何保证真正“高可用”,也是个难题。数据库
几乎主流的大中型互联网公司,都会有用到相似的架构,只是节点数不一样而已。缓存
还 有一招用的比较多的,那就是动静分离。能够须要开发人员配合(把静态资源放独立站点下),也能够不须要开发人员配合(利用7层反向代理来处理,根据后缀名 等信息来判断资源类型)。有了单独的静态文件服务器以后,存储也是个问题,也须要扩展。多台服务器的文件怎么保持一致,买不起共享存储怎么办?分布式文件 系统也派上用场了。服务器
还有一项目前国内外用的很是广泛的技术CDN加速。目前该领域竞争激烈,也已经比较便宜了。国内南北互联网问题比较严重,使用CDN能够有效解决这个问题。微信
CDN的基本原理并不复杂,能够理解为智能DNS+Squid反向代理缓存 ,而后须要有不少机房节点提供访问。架构
截止目前为止,都没有怎么去改动应用程序的架构,或者说通俗点,都不怎么须要大面积的修改代码。分布式
若是上面那些手段都用光了,仍是支撑不住怎么办?不停的加机器也不是办法啊?性能
随着业务愈来愈复杂,网站的功能愈来愈多,虽然部署层面是采用的集群,可是应用程序架构层面仍是“集中式”的,这样会致使不少耦合,不便于开发、维护,并且容易“一荣俱损”。因此,一般会把网站拆分出不一样的子站点来单独宿主。网站
应用都拆了,因为单个数据库的链接,QPS,TPS,I/O处理能力都很是有限,DB层面也能够去作垂直分库操做ui
拆 分应用和DB以后,其实仍是会有不少问题。不一样的站点,里面可能会有相同逻辑和功能的代码。固然,对于一些基础的功能咱们能够封装DLL或者Jar包去到 处提供引用,可是这种强依赖也很容易形成一些问题(版本问题、依赖关系等处理起来很是麻烦)。这样,传说中的SOA的价值就获得体现了。spa
应用、服务之间仍是会出现一些依赖问题,这时候,高吞吐量的解耦利器出现了
最后,还介绍一个大型互联网公司都用的绝技--分库分表。我的经验,不是业务发站和各方面很是迫切,不要轻易走这一步。
由于分库分表谁都会干,关键是拆完以后怎么办。目前,市面上尚未彻底开源免费的方案,能让你一劳永逸地解决数据库拆分问题。
打一下纯ad:欢迎你们关注微信公众号:neihanrukou