从架构开始谈dubbo(一)

架构发展史

一、单体应用架构

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