大型网站技术架构的演变历程
最新看了《大型网站技术架构》的一些内容，记录一下网站演变的进程和一些感悟。
演进历程：
1.初始阶段的网站架构
这种网站的初创时期，一台服务器就充当了所有的角色，应用程序，数据库，文件等内容都部署在上面，很多个人开发者可能也就是这样部署的，还有可能媒体文件也是放到数据库里面的。
流量不大，所以也没什么压力和问题。
2.应用服务和数据服务分离
随着网站的发展，我觉得这个确实是必然的，书中也说了对于应用服务器和数据服务器，服务器的硬件需求其实是不一样的。应用服务器需要大量的计算，提供稳定的服务，需要高性能的CPU，
这里我觉得可能也需要较大的内存，毕竟各种计算的中间结果和处理流程都是在内存中完成的。对于数据服务器那磁盘一定是得够大，对应的取数据的话就会需要较大的内存。文件服务也是和数据服务器类似。
对于某些情况如果服务要一直稳定运行下去，数据又是会不断的增长的话，数据服务和文件服务需要有GC的机制，自动定期的清理过期的数据。
3.网站使用缓存
一开始可能要缓存的数据都是放在内存中，但是如果数据量大起来对于应用服务器的内存还是有一定压力的既要完成服务的运算，又需要保存大量的缓存，而且如果没有同步机制的话。服务器重启或者宕机了，
缓存数据就没了，对数据库的压力也会瞬间起来。所以除了本地的缓存还会需要远程的分布式缓存，缓存的集群架构也不会导致一台缓存服务器挂了，导致整个网站流量飞速攀升。不过这个里面技术难度还是有的怎么同步数据，
怎么保证不会缓存雪崩。
4.应用服务器集群
流量越来越大，一台应用服务器肯定是扛不住的，这个时候需要多台服务器一起分配流量，处理问题。这里我觉得把一台服务器的配置加到很高确实不如两台配置没那么高的服务器要好，配置越高价格也就爱越高，
而且一台服务器即使配置再好也会存在可能挂掉的情况，这个时候多台服务器的优势就出来了，整个服务还是高可用的不会因为一台服务器的问题导致访问不了，交易失败等问题。只要流量能正常发到其他服务器上整体服务对外
就还是正常的。这里还有一个点想到的就是，架构可以早点在应用服务器前面加上负载均衡的这一层，后期需要加服务器，也只需要配置下负载均衡服务器的配置，就能很快的扩展，很灵活。可能不太方便的就是查日志的时候，
需要到好几台机器上查询，看错误日志是在哪一台机器上。
5.数据库读写分离
上面已经有多台应用服务器了，应用层面可能压力没那么大了，但是数据库还是有压力的，这么多台服务器的连接，疯狂的请求。这个时候可以把数据库的读写分离，对于数据库的读只要不是慢sql，还一直频繁的查询这种，基本上不会有太大的问题。
而且读写分离之后，网站可以根据自己的需求，是读的场景比较多还是写的场景压力比较大，明确压力来源之后也可以对读和写的服务器分别增加不同的硬件来缓解数据的压力。不过这边可能存在的问题就是，主从同步，数据能都保持一致的问题。
6.使用反向代理和CDN加速访问
达到这一层感觉这个网站已经比较大了，至少已经是跨省级别以上的了。使用反向代理服务器缓存一些网站的静态资源的话，也可以减少访问压力。使用CDN就更快速了，毕竟现实世界的物理距离在那里，咱们总不能要求，*到海南的直接访问还很快，
所以可能需要在中间距离用户比较近的一些地方，存放一些服务器，这样用户从距离自己比较近的地方去读取数据的话，网络延时会小很多。
7.使用分布式文件系统和分布式数据库
我感觉到这一块的大网站可能不是那么多，数据库和文件系统同上面应用服务器一样，一台解决不了问题，就多弄几台，然后可能按照业务情况在拆一拆。基本上就是靠集体的力量来解决问题，
这个好像是架构的一个比较通用的思路。
8.使用Nosql和搜索引擎
对待不同的数据，有不同的需求，这时候可能就要用到nosql和搜索引擎了。这里我个人并不能确定什么样的场景和数据量才需要使用这些技术，一般的搜索可能就数据库直接完成了。可能会需要加速查询时间，然后有全文搜索的时候需要用到搜索引擎。
9.应用拆分
其实我觉得这个层级应该不算是最后一个层级，应该是发展到中期就可以有这样的业务拆分了，每个项目负责好自己的模块，然后通过一些分布式框架或者消息队列之类的东西来完成通信交互。
而不是发展到很后面才拆分，这样后期代码已经耦合在一起很严重了在拆分也是一件难度很大的事情。
感想：
1.感觉书中说的误区都非常的中肯有很好的指导和借鉴作用，比如说不能一味追求大公司的解决方案，技术架构应该是不断的演进的，而不是一开始就能设计好，到未来都不用变化的。再就是大公司的方案不一定就适合自己，
可能照搬过来只会水土不服，加大工程师改造的压力。所以要通过学习和借鉴大公司架构的优势，再走自己公司的特色架构模式，因材施教。
2.不能为了技术而技术，这句话也说的很好，咱们做技术的不能为了炫技，故意去弄一个复杂的很难弄的架构或者去用一个很新的没有经过实战的技术。仅仅为了做技术而去使用技术，脱离了业务发展这样是不对的，本末倒置了。
3.技术是为业务服务的，开公司做业务首先那要解决的是生存问题，先解决了业务上的问题才能更好的发展技术，储备技术手段。可以提前学习和了解最新的技术，为将来技术架构做准备。
4.不是所有问题都能靠技术来解决，书中举的例子就是12306买票，咱们自己也亲身体会过，以前12306买票是真的难，而且服务器会崩溃掉。大家最后很多人都没法买到票。你想想十几亿的人，
就算只有几亿人在春节要回家，在同一天买票的话压力也是天大。这种情况下，就应该提前放票，分很多批次去放票，把流量的峰值给降下来，分摊到不同的时间段。在引入排队的机制，服务器在顶得住压力的情况下，把票给放出来，
这样才比较合理。这种情况下，就不要想去解决这个技术问题，应该从业务上的方案去尽量给技术提供更好的背景条件，而不是把所有压力都放到技术上，不解决问题就是技术人员的问题，这样做是不对的。
5.系统架构没有绝对的演进阶段，不是必须要在某个阶段就一定只能用那个阶段的技术，书中也只是给出了一些具体的架构思路和方向，具体问题要具体分析，根据自己的实际情况也是可以将各个架构给拆开来找到适合自己的架构方式。