引言

互联网服务和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[]是阿里开源的 ”一个分布式服务框架，致力于提供高性能和透明化的官方文档的架构图