出现在互联网的早期，访问量比较小；
输入这个taobao.com之后，但是域名并无法告知是哪个服务器，这个时候就会需要进行这个dns转换，这样我们的浏览器或者服务器就会找到这个门牌号，对于这个服务器进行访问；
dns只会在最开始告诉我们门牌号，后来我们的应用服务直接回返回给这个浏览器或者这个app被我们的用户看到；
优点和缺点：
1）部署简单且使用的成本比较低；
2）存在性能的瓶颈（用户的请求量会不断的增加，慢慢的就扛不住了），应用服务和数据库服务之间相互进行这个资源的竞争（访问的时候转转，访问的速度变慢）；
其他事项：
1）初创公司使用，用户的访问量比较低，及时挂掉也影响不大；
2）dns转换主要是这个应用上提供的，我们直接使用；
工作的原理：
优缺点：
1）成本相对可控；
2）性能相比于单机架构有所提高；
3）数据库单独隔离，不会因为我们的应用数据库坏的时候，数据库挂掉，使得我们的这个数据库有容灾能力；
4）但是相对于我们的海量的并发，还是扛不住；
5）因为这个时候两个服务器是分离的，所以消耗的这个硬件的资源就会变多；
出现的原因：
1）请求量变大，因此我们需要加多应用（否则这个相应的速度就会越来越大）；
可以进行横向的扩展，支持海量的请求；
但是这个mysql成为了性能的瓶颈，而且这个硬件的成本增加；
1）主数据库接收到这个写的内容之后，会进行同步到我们的这个从数据库上面的；
读写的性能提高；
出现异常挂掉的时候，会出现主从数据库里面的内容不一致的情况；
热点数据读取的时候仍然会让这个数据库里面的这个负载很高；
秒杀的案例分析：写入的过程
我们的商家想要发布这个秒杀的商品项目，第一步还是进行这个dns的转换，把这个域名转换为我们的ip地址，方便我们去进行这个对应的写入的过程；
如果我们的这个用户进行访问：
访问的如果是我们商家的这个秒杀的项目，这个时候执行的就是这个红色的路径，因为这个时候这个秒杀的内容就是在我们的这个缓存里面存放着的，这个时候访问之后就可以直接获取到了，这个里面的数据就是一些这个热点的数据；
我们的这个缓存可以使用我们的redis；
业务体量的变大导致这个数据量进一步增加，这个时候我们的数据库里面的单表的容量就会进一步变大，使得我们的这个数据库再一次成为这个性能的瓶颈；
演示：不管你的这个背后是是什么，我就是把你当作一个表进行看待，但是实际上这个背后是一个数据库集群；
我们的不同的微服务之间是进行相互的关联和协作的；
满足业务需求就可以了，不一定必须动不动就上微服务；
一千个读者的心目里面由一千个哈姆莱特，不同人的理解和这个架构的演进的阶段的理解是不一样的，有自己的这个理解和体会即可；