引言
互联网服务和BS架构的传统企业软件相比，系统规模上产生了量级的差距。例如
- 传统BS企业内部门户只需要考虑数百人以及几千人的访问压力，而大型互联网服务有时需要考虑的是千万甚至上亿的用户；
- 传统企业管理系统管理的物料信息等，可能只有数万或数十万条记录，而一个大型B2C网站的商品SKU动辄千万，考虑到商品信息更新的历史记录，商品订单记录等数据，更是天文数字。
原始的SSH+DB的BS开发模式，显然已经无法满足现代互联网服务的需要。随着企业软件不断地向云端迁移的趋势越来越明显，最终中小型企业软件系统的开发将变得越来越非主流，模式和架构被淘汰后，只熟悉原始的开发模式和架构的工程师，也将遭遇被淘汰的压力。
SOA化
大型互联网服务的体系架构有什么特点呢？以大型B2C电商网站为例，其功能至少应该包含以下几个部分
- 商铺
- 商品及库存
- 销售（促销，活动等）
- 订单
- 支付
- 物流
- 用户
- 财务等数据统计和报表功能
- 其他支撑系统（例如访问统计功能）
每个功能模块都有自身的业务逻辑，且侧重点各有不同，需要着眼的技术难点也不相同
- 商品的数据量较大，前端用户对于高性能的检索有较高要求，高并发时的库存管理也要处理好；
- 订单的状态控制业务较复杂，数据量的累积很快；
- 支付和物流，与外部对接的技术复杂度一般较高；
- 报表功能一般后台计算量很大；
如何开发这样的复杂大型系统，经过不断地迭代和发展基本上找到了一条比较合适的道路：
- 将每个模块都作为一个单独的系统来进行架构设计和实现
- 模块与模块之间定义一定的接口规则来交互
- 每个模块可以交由不同的团队负责开发，并且可以根据需求选用不同的架构和技术栈
这时的每个模块都拥有自己的输入和输出结构，相对独立，可以被称作一个服务。这种系统的整体架构就是SOA（面向服务的体系结构）。“它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。”，最重要的一点，“接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言”。
“这使得构建在各种各样的系统中的服务可以使用一种统一和通用的方式进行交互。” --- 百度百科
随着规模的增大，系统架构如何变迁到SOA的，Dubbo官方网站上有个很好的总结：
- 单一应用架构
- 当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。
- 此时，用于简化增删改查工作量的 数据访问框架(ORM) 是关键。
- 垂直应用架构
- 当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。
- 此时，用于加速前端页面开发的 Web框架(MVC) 是关键。
- 分布式服务架构
- 当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。
- 此时，用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。
- 流动计算架构
- 当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。
- 此时，用于提高机器利用率的 资源调度和治理中心(SOA) 是关键。
网站系统更加细节具体的架构演化，还可以参考一篇很好的博文 http://www.cnblogs.com/pflee/p/4507579.html
或者阅读一本好书 《构建高性能Web站点》
服务框架Dubbo
服务化的思路简化了一些事情，但是也有一些问题尚未解决：
- 如果某个处理需要调用其他服务的接口，不像本地调用某个库函数那么直观方便，性能也有影响；
- 某个服务如果发生了变化，例如由于容量不够进行了集群化，依赖这个服务的其他服务需要相应的做什么样的调整，梳理需要花不少时间。
- 随之系统规模的增大，服务数量也不断增多，接口的URL很快的出现了爆炸式的增长，管理困难；服务与服务之间的依赖关系将越来越难控制，那个服务必须先启动？我的服务瘫痪了会影响到谁？谁又会影响到我？
Dubbo[
]是阿里开源的 ”一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案“，帮助我们解决上述的那些问题。
其核心部分包含:
- 远程通讯: 提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“同步转异步”和“请求-响应”模式的信息交换方式。 基础功能
- 集群容错: 提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。 特色功能
- 自动发现: 基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。 重要功能
Dubbo的主要特点
首先看一下来自于官方文档的架构图
（Dubbo更具体的架构组成，请参考这里）
从官方文档中，可以提炼出Dubbo的一些重要特点
特色1：服务注册与发现的注册中心Registry
- 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。 这个功能是应有之义
- 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。这个就很好很强大了，
注册中心的这两个特性大大提高了系统的可用性和扩展性。注册中心既可以采用Multicast注册中心，也可以集成Zookeeper,也可以采用Redis，非生产环境也可以使用一个Dubbo自己实现的Simple注册中心，非常灵活。
特色2：统计服务的调用次调和调用时间的监控中心Monitor
- 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。
监控负载，排查性能瓶颈就方便多了。简易监控中心的安装，请参考这里。
特色3：使用上，采用全Spring配置方式，透明化接入应用，对应用没有任何API侵入，只需用Spring加载Dubbo的配置即可，Dubbo基于Spring的Schema扩展进行加载。
特色4：开源部分中，还包含有一个管理控制台的实现（内部裁剪版本，开源部分主要包含：路由规则，动态配置，服务降级，访问控制，权重调整，负载均衡，等管理功能）。
Dubbo的必读官方文档
--------------------------------------------------------------------------------
参考文献：
http://www.iteye.com/magazines/103
http://www.tuicool.com/articles/YRRjq2E