架构发展史
一、单体应用架构
当网站流量很小时,所有的功能写在一个项目中,打包部署在tomcat中.
例如:公司管理系统,超市的收银系统
也可以将单体应用部署在两个及两个以上的服务器中(即Linux1、LInux2分别放Tomcat和war包分担流量)
这种架构模式一般适用于创业型企业和小型企业,小型团队模式,比如:1-50个开发规模的团队
优点:
开发简单,部署简单,节约成本(适用于一个请不起架构师的小型团队,可以快速让项目上线,快速出现成果,使得老板能看到团队的价值)
缺点:
1、扩展不容易
修改或添加某个功能的时候,需要修改完成后,整个项目重新打包,重新部署.
2、协同开发不容易
多个人都去改同一个应用,会导致版本紊乱,不利于维护
3、项目单体体积过大,已经无法进行性能提升了
项目越写越大,达到例如500MB,服务器的内存分配就会很大压力,性能无法提升.
二、垂直应用架构
拆分应用功能,每个应用都是从前端到后端独立完整的,如果哪个应用访问量大,就给其增加服务器,以便降低系统承载压力.
优点:
拆分应用功能,每个应用都是从前端到后端独立完整的,如果哪个应用访问量大,就给其增加服务器,以便降低系统承载压力.
优点:
1、分工合作很容易
每个人负责不同模块,分工合作,互不干扰
2、性能扩展很容易
某个模块访问量比较大,就将其多放在几个服务器上
缺点:
1、无法做到界面和业务逻辑实现分离
需要经常修改界面的时候,后端也需要跟着经常修改
2、应用不可能完全独立,大量的应用之间需要交互
业务模块之间互相调用的时候,需要模块之间互相调用
三、分布式服务架构(RPC:远程过程调用)
抽取出核心业务模块前后端分离部署,前端修改不影响后端,后端修改不影响前端,业务之间互相调用也不影响后端.
抽取出核心业务模块前后端分离部署,前端修改不影响后端,后端修改不影响前端,业务之间互相调用也不影响后端.
缺点:
1、业务不在同一个服务器上,前后端不在同一个服务器上,代码如何互调(互调的方式叫做RPC)
2、核心难点如何进行RPC调用以及如何拆分业务,提高业务的服用程度
3、一个好的分布式框架,能很好的解决RPC问题,就能极大的简化开发
4、拆分的业务越来越多,会造成极大的资源浪费
5、需要一个基于访问的调度中心,能够动态的调度,提高资源的利用率
四、流动计算架构
引入调度中心,来维护复杂的服务关系,实时管理整个服务集群,如果某个服务器A访问量大,就多给其几台服务器,提高整个服务的利用率.
RPC(网络通信,实现远程过程调用)
1、序列化与反序列化的速度快不快
2、通信效率
Dubbo是RPC概念的落地实现,解决不同服务之间如何通讯,如何传递数据,如何调用