架构师训练营第四周总结

本周老师主要通过维基百科，淘宝，微博的演化，来讲解架构的演化，让大家理解架构没有银弹，架构的演化是针对不同业务，不同并发量自然而然发生的。



大型互联网也是从小型互联网开始的，在从小到大的过程中，随着并发的增加，为了继续保持服务的高可用和高性能，演化出了很多技术方案与手段，具体如下：



创业公司的应用一般都是从一个应用服务器和一个数据库服务器开始的，随着业务的扩张，用户的增加，最开始一般是一个应用服务器不够用了，能够开启的线程数有限，另外，也不能随便停机服务了， 这时候，可以先搭建应用服务器集群，同时引入负载均衡，提高应用服务器的可用性。



随着业务量的继续增加，QPS和TPS越来越高，数据库服务器开始承受不住压力了，一般情况下，读操作要比写操作多很多，这时候可以根据业务的情况，决定先做数据库的读写分离还是先引入缓存。比如针对电商业务，有很多热销商品，或者只是某个垂直行业电商，商品数有限，则可以先做缓存，将所有商品存入缓存。这将大大降低数据库的压力。



如果业务量继续增加，即使只有10%的读操作落在数据库上，还是会让数据库压力太大，则应该开始做数据库的读写分离，根据业务量的大小，做一个或多个只读数据库，跟主库做同步。将读操作引导至从库。



那么业务量继续增加呢，单一数据库主库无法支撑写操作呢？这里可以考虑数据写操作是怎么来的？是否比较平均的落在各个模块中？如果是，则可以考虑微服务，同时每个微服务有自己的数据库。如果写操作都是集中在某一个模块，则可以考虑针对具体业务分库分表。