dubbo起源的思考

写作原因

最近这段过程中一直在看dubbo的一些信息,在这个过程中有个问题一直萦绕在我的心头,那就是dubbo是因为什么原因而产生的呢,一下是我带着这个问题翻阅资料的一些记录

阅读笔记

先来介绍下我自己对当前IT技术架构的一个演进过程
这个是我个人的观点

单一应用架构

  最开始的开发过程中,我们的开发模式就是很单一的应用,这种单一应用的一体式开发(ORM)。随着互联网产业的迅猛发展,这种单一应用的架构模式的不足就逐渐的暴露出来了。
例如:
  a、所有的代码都融合在一起,代码阅读性差,并且应用越来越重
  b、多团队协调性差,开发效率低
  c、系统扩展性差

垂直应用架构

  垂直应用架构,从词义来看就是分层开发,提到这我们会不由自主的想到MVC这种开发模式。以这种架构去做开发工作,我们工作中会以一种分层的方式来进行开发,这样极大的方便的代码的可读性,使得代码看起来更清晰明了,这种架构除了水平分层以为,在垂直方向上也会进行分割(一般是依据业务),这个时候每个团队在开发过程中的相互影响越来越小。随着互联网流量的增长,传统的整体打包部署的方式对于现有应用的支持能力越来越差,单机响应已经成为了瓶颈

分布式服务架构

  在分布式应用架构中,应用相互独立,每个应用代码独立开发,独立部署,应用通过有限的API接口互相关联。API接口属于应用一部分,一般和表示层处于同一层次,两者共享业务逻辑层,API和表示层采用同样的web端技术,通讯协议一般使用HTTP,数据格式是JSON,应用集成方式比较简化,随着应用的不断增多,各个应用之间的相互调用会变得十分杂乱,将一些公用的应用做成一些通用的服务支持,在这个过程中产生了一些列的分布式框架(RPC)如 dubbo、hessian等

流动计算架构

  在这个架构中要引入了SOA
  在上面介绍的分布式架构中存在一些问题比如 :依赖上过于复杂、可靠性差、数据唯一性保障不足、维护成品高等等,因此在分布式的基础上就衍生出了一些列的分布式的增强技术。比如说:
  a、系统中的不同应用完成的功能不同,因此对于机器硬件的要求也不同,并且不同的业务情况在不同的时间需要的资源也是不同的,为了提高资源利用率就会引入了弹性伸缩自动扩展的技术。
  b、因为分布式架构的维护成本比较高,因此就有了一系列的监控管理工具来辅助

在此过程中我个人感觉dubbo作为一个分布式的框架,应该是随着互联网纵向切割分流之后,为了更方便的实现不同的分系统之间的数据互通的一个产物

本文参考资源部分列出
在首席架构师手里,应用架构如此设计
为什么选择分布式垂直架构
dubbo

你可能感兴趣的:(dubbo,dubbo,技术架构,开发模式)