[引用]Dubbo之旅--架构路线

从自己开始接触Dubbo到现在也有段时间了,在这段时间里,随着项目的不断进行,在项目中也遇到了各种各样的问题,而这些问题和相应的解决方案逐渐加深的对Dubbo有了认识和了解.

       先说说什么是Dubbo?

        官方的说法是:Dubbo是阿里巴巴SOA服务化治理方案的核心框架，每天为2,000+个服务提供3,000,000,000+次访问量支持，并被广泛应用于阿里巴巴集团的各成员站点.

       现在我们知道了,Dubbo是阿里巴巴的一个框架,不过自开源后，已有不少其他公司在使用Dubbo,例如:京东,去哪儿,大智慧等等.听起来好像很厉害的样子.

       现在我们大概知道它是什么,SOA的框架,阿里巴巴的,开源的,好多公司在用的.接下来我们会用比较大的篇幅来了解一下关于SOA的演变,这样会帮助我们更好的理解Dubbo这个东西.

         互联网是一直都在发展着的,这个大家都看在眼里,尤其是IT行业的.如果读者有做网站应用的话会有一个体会,现在随着网站规模的不断扩大,以前常见的那种垂直的应用架构已经满足不了,现在主要的趋势是分布式架构和流动计算架构.但是这些的演化需要一个治理系统去确它有条不紊的进行.具体的阶段如下.

        第一个阶段:

    当网站的访问量比较小的时候,我们只需要简单的一个应用,把需要的功能都部署到一起,此时用于简化增删改查的数据库访问框架(ORM)是当时的主角,它的好处是减少了部署节点和成本.这个阶段采用的架构是单一应用架构.

     第二个阶段:

  当你的访问量逐渐开始变大的时候,我们会将应用拆分互不相干的几个应用来提升效率,这时候加速前段页面开发的Web框架(MVC)成关键了.这个阶段采用的架构是垂直应用架构.

    第三个阶段:

  当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式服务框架(RPC) 是关键。这个阶段采用的架构是分布式服务架构.

    第四个阶段:

   当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。这个阶段用于提高机器利用率的 资源调度和治理中心(SOA) 站到舞台上了.这个阶段的架构是流动计算架构.

         以上的四个阶段可以用官方的Dubbo架构路线图来概括,如下:

 

         至此,关于Dubbo的架构路线介绍的差不多了,简单概括:它的架构路线是跟着需求进行适应和变化.

          接下来会主要对Dubbo的需求进行深一步的了解.