项目架构的演变

垂直架构

今天开始，仙鱼发现要学习的技术真的太多了，就我目前所掌握的来看，我就是一个渣渣，要深挖的东西太多了~对，今天开始我就一个热爱学习的渣渣，本渣决定不学秃头不停止。

今天记录一下新学习的项目架构的演变过程，图文并谈，希望对阅读文章的您能有帮助。

第一代

• 网络条件：拨号猫的时代 56kb–>7kb/s

• 项目特点：非常简单，基本上都是文本内容，夸张的来说，基本上几个Servlet就搞定了，访问量很低，有时候会出现无法访问得情况，但是无所谓，因为没有人会去特别留意（那个年代一台电脑上万…..体会一下……）。

  

第二代

• 网络条件：ADSL(Asymmetric Digital Subscriber Line,非对称性数字用户线路)：1-8M/s，这个时候出现了图片和渣渣像素得视频，网站内容变多，用户也开始增加。

• 第一个问题：Tomcat能无限接收请求吗？

  答：不能，只能增加服务器。然后就出现了新问题，即下面得第二个问题；

  

• 第二个问题：如何将用户得请求分配到不同得服务器？

  解决：通过负载均衡（又叫方向代理，路由）将请求分发到不同的服务器（集群：相同功能的服务器的集合：服务器1，服务器2，服务器3），通过第三方的服务器进行数据的同步。

  

第三代

• 网络条件：网络继续发展，用户越来越多，服务器越来越多(所有服务器的代码都是一样的)。

• 作为Bug的生产者，我们每天都要制造无数的Bug（当解决了Bug，那服务器是不是要重新部署一下，那维护的成本巨高，而且还不能全部停机，于此同时Bug还在不停的产生…）以及添加无数的功能，于是开始使用MVC，新加的功能放到其他的服务器，这样子新功能出现问题只需要维护对应的服务器就可以了。如果出现了新的Bug，我们发现这个功能对应的服务器需要全部重新部署，但是在之前，我们将大量的功能写在了一起（如注册功能嵌套于其他的功能中Oh My God!）导致，任意一个功能出现了问题后需要将其他的功能都要进行部署，速度特别慢，所以我们开始想能不能拆分（即功能的模块化设计）？

  

• 还有一种情况：公司大了之后会有很多不同的部门，每个部门都有自己的系统，有可能某天会出现系统之间的相互调用。

分布式架构

• 随着项目的增大，代码越来越多，服务器越来越多，维护成为一个大问题，为了降低运维的压力，我们对项目进行了拆分，按照功能也好，业务也好，按照某种方式进行拆分，将整个项目拆分成不同的小项目。

RPC

• Remote Procedure Call（远程过程调用）：通过服务器(这时服务器就算是客户端)调用服务器的方式来实现网络通信获取数据

  

• 问题：缺少服务治理，最终会出现混乱，理不清情况，不知道谁调用了谁，各种Controller服务器调用不同的Service，调用关系比较混乱，假设其中的一个服务接口出现了问题，那调用这个服务接口的就会跟着崩。

• 服务器的增删问题：要在被调用的服务器增加或者删除了服务器的情况下保证稳定，这是就要进行服务治理(注册中心，动态感知，分布式最重要的核心内容)。

服务治理

• dubbo+zk的方式实现，dubbo内置了服务治理功能，包含监控平台查看服务的使用情况

微服务

• 微服务任然是分布式的范畴，只是将上面的服务拆分的更小了，累了，不放图了。

下篇预告

缓存四大问题：缓存穿透，缓存穿刺(击穿)，缓存有效期-缓存雪崩，缓存倾斜

敬请期待。

感谢阅读，有问题请在留言中，指出记得点赞欧~