从架构开始谈dubbo(一)

架构发展史

1、单体应用架构

     当网站流量很小时,全部的功能写在一个项目中,打包部署在tomcat中.

         例如:公司管理系统,超市的收银系统 

       也能够将单体应用部署在两个及两个以上的服务器中(即Linux一、LInux2分别放Tomcat和war包分担流量)  

       这种架构模式通常适用于创业型企业和小型企业,小型团队模式,好比:1-50个开发规模的团队

优势:

      开发简单,部署简单,节约成本(适用于一个请不起架构师的小型团队,能够快速让项目上线,快速出现成果,使得老板能看到团队的价值)

缺点:

      一、扩展不容易

      修改或添加某个功能的时候,须要修改完成后,整个项目从新打包,从新部署.

      二、协同开发不容易

      多我的都去改同一个应用,会致使版本紊乱,不利于维护

      三、项目单体体积过大,已经没法进行性能提高了

      项目越写越大,达到例如500MB,服务器的内存分配就会很大压力,性能没法提高.

2、垂直应用架构
      拆分应用功能,每一个应用都是从前端到后端独立完整的,若是哪一个应用访问量大,就给其增长服务器,以便下降系统承载压力.
       优势:

             一、分工合做很容易

             每一个人负责不一样模块,分工合做,互不干扰

             二、性能扩展很容易

             某个模块访问量比较大,就将其多放在几个服务器上

        缺点:      

              一、没法作到界面和业务逻辑实现分离

              须要常常修改界面的时候,后端也须要跟着常常修改

              二、应用不可能彻底独立,大量的应用之间须要交互

              业务模块之间互相调用的时候,须要模块之间互相调用

3、分布式服务架构(RPC:远程过程调用)
      抽取出核心业务模块先后端分离部署,前端修改不影响后端,后端修改不影响前端,业务之间互相调用也不影响后端.

  缺点:

        一、业务不在同一个服务器上,先后端不在同一个服务器上,代码如何互调(互调的方式叫作RPC)   

        二、核心难点如何进行RPC调用以及如何拆分业务,提升业务的服用程度

        三、一个好的分布式框架,能很好的解决RPC问题,就能极大的简化开发

        四、拆分的业务愈来愈多,会形成极大的资源浪费

        五、须要一个基于访问的调度中心,可以动态的调度,提升资源的利用率

4、流动计算架构

       引入调度中心,来维护复杂的服务关系,实时管理整个服务集群,若是某个服务器A访问量大,就多给其几台服务器,提升整个服务的利用率.

 

RPC(网络通讯,实现远程过程调用)

       一、序列化与反序列化的速度快不快

       二、通讯效率

 

Dubbo是RPC概念的落地实现,解决不一样服务之间如何通信,如何传递数据,如何调用