那一年，有个小程序
![image_thumb[10]](http://images.cnblogs.com/cnblogs_com/Chaos/201102/201102191343478647.png "image_thumb[10]")
业务简单，规模小，一个小程序直接搞定。
后来规模大了
![image_thumb[23]](http://images.cnblogs.com/cnblogs_com/Chaos/201102/201102191343495450.png "image_thumb[23]")
将前台逻辑和后台业务分开了，变成了客户/服务器模式。
再后来用的人多了，安装特麻烦
![image_thumb[24]](http://images.cnblogs.com/cnblogs_com/Chaos/201102/201102191343505318.png "image_thumb[24]")
换成了B/S结构，前台0安装了。
然后，使用范围扩大，上线的人更多了，响应变慢了
![image_thumb[25]](http://images.cnblogs.com/cnblogs_com/Chaos/201102/201102191343511598.png "image_thumb[25]")
将处理用户请求和业务计算的任务分离了。
稳定了，规模大了，后台业务计算变慢了
![image_thumb[26]](http://images.cnblogs.com/cnblogs_com/Chaos/201102/201102191343536383.png "image_thumb[26]")
将业务按照业务种类垂直切分后台。
后台多了，RPC连接麻烦又低效
![image_thumb[27]](http://images.cnblogs.com/cnblogs_com/Chaos/201102/201102191343554757.png "image_thumb[27]")
换成基于消息的通信方式，提高性能相互解耦。
性能高了，规模不断扩大，新需求不断出现，发布时间不断缩短
![image_thumb[28]](http://images.cnblogs.com/cnblogs_com/Chaos/201102/201102191343583446.png "image_thumb[28]")
所以，按照语言无关的契约定义服务，用最适合业务的语言实现服务，通过SR（Service Runtime）将服务请求和应答转换成消息，由MQ负责通信。一个业务一种服务，开发一个发布一个。搭上了SOA的班车，算是一种SOA实践吧-_-!
说明：
BC：浏览器客户端
WS：Web Server
BS：后台业务服务