架构发展史
一、单体应用架构
当网站流量很小时,所有的功能写在一个项目中,打包部署在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概念的落地实现,解决不同服务之间如何通讯,如何传递数据,如何调用
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
