码迷,mamicode.com
首页 > 其他好文 > 详细

从架构开始谈dubbo(一)

时间:2019-10-13 18:38:06      阅读:92      评论:0      收藏:0      [点我收藏+]

标签:bsp   过程   序列   交互   维护   linux   快速   分工合作   关系   

架构发展史

一、单体应用架构

     当网站流量很小时,所有的功能写在一个项目中,打包部署在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概念的落地实现,解决不同服务之间如何通讯,如何传递数据,如何调用




 

从架构开始谈dubbo(一)

标签:bsp   过程   序列   交互   维护   linux   快速   分工合作   关系   

原文地址:https://www.cnblogs.com/liuyangfirst/p/11667335.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!