dubbo起源的思考

写作原因

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

阅读笔记

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

单一应用架构

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

垂直应用架构

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

分布式服务架构

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

流动计算架构

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

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

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

<script type="text/javascript"> $(function () { $('pre.prettyprint code').each(function () { var lines = $(this).text().split('\n').length; var $numbering = $('<ul/>').addClass('pre-numbering').hide(); $(this).addClass('has-numbering').parent().append($numbering); for (i = 1; i <= lines; i++) { $numbering.append($('<li/>').text(i)); }; $numbering.fadeIn(1700); }); }); </script>