云计算实现了业务和技术分离

实现业务和技术分离的途径很多，比如技术平台可以租用公有云，让自己十几号人马更加注重业务，如果试图什么都做，也许什么都不会做得很好，被当成练兵学习的学校了。

基本架构主要分下面几层：
1.负载平衡和健康检查
2.代理 缓存 转发等。
3.Web前端(业务重点)，这部分现在一般用轻量Node.js等完成，这样能够让前端工程师结合客户端和服务器的前端编写出互动效果极好的页面，过去那种让美工设计好平面，然后进行分割给程序员的工作方式已经过时，这样的页面互动性和可触感都很差，等于平面杂志，不是互动媒体。

由于在这层剥离了技术的可伸缩性，使得程序员能够整合前后端资源，更加靠近终端用户，更能做精产品。

4.前端Web缓存
5.事件总线rabbitMQ或ZeroMQ之类Broker，实现异步编程架构，该层实现业务和技术分离。

6.PAAS平台或IAAS数据中心。外部内部的都可以，下图是采取的亚马逊S3公有云。公有云或私有云根据自己的选择，在国内如果不放心公有云，需要打造自己的数据中心和CDN，提供平台的鉴权验证能力，类似OAuth或微博的开放API。就是自己公司打造的PAAS也具备对公司外开放开发的能力。

在这层，也有用来进行大数据分析或耗CPU的大量并行计算的能力。

以上各层的逻辑图如下图，来自：SoundCloud的云演变

注意，云演变这个概念很重要，国人非常期望革命彻底否定的概念，其实这是反逻辑的，真正具有生命的是演变，包括我们人类也不是一天由上帝创造，而是千万年的进化。当初有人讥讽云计算是旧瓶装新酒，实际上就是因为这种感性思维导致，其实旧瓶装新酒不过是演进的贬义词。
[该贴被banq于2012-11-01 09:41修改过]

通过前面我们已经分析出云计算切实带来了业务和技术的分离，业务分析设计实现基本在Web前端这一层实现，具体如何实现呢？

推荐使用面向对象分析设计方法，这是一套以类型从顶层进行解剖的方法学，通过DDD领域驱动设计等方法，帮助我们找出我们业务领域中本质的结构和特点。

根据多年DDD实践和交流讨论，我们在Jdon得出如下图的业务通用语言：

图中左上角的Command代表终端用户通过界面发出的操作命令，而从上至下的领域--聚合--实体这个线路代表了用户需求中的领域性的结构概念，这个领域是用户心目中的领域模型。

图中从左向右的场景--事件--状态，代表系统响应用户的操作命令。用户的每次操作，都会影响领域模型的状态。

注意，图中事件和状态分别引向了事件总线和数据库，事件总线是上贴图中的broker，比如RabbitMQ等等，而状态指向了其持久化的基础实施层IAAS或数据中心。

通过前贴，我们落地了业务实现，那么传统的通用业务中间件应该如何转变到新的云架构呢？

这些通用业务中间件包括工作流，规则引擎等等，或者我们自己编写的行业通用中间件或引擎，比如棋牌类游戏引擎等等。

这些通用业务中间件是应该落地在SAAS层还是PAAS层呢？

如果这些通用业务能够面向普通终端用户提供服务，那么可以落地在SAAS，如果仅仅是面向开发人员，那么落地在PAAS层无疑更合适些。

通过将通用业务中间件以服务形式充实到PAAS，这样我们的平台能力将变得更加强大，但是这种演变并不是想象中那么平滑，关键问题在于：传统通用业务中间件由于过于侧重业务，忽视可伸缩性，因此，必须对这些通过业务中间件有一个分布式部署的要求，如果不能实现分布式部署，也就无法运行在可伸缩的PAAS平台上，就无法实现迁移。

演进中也许已经散发出革命残酷性了。

[该贴被banq于2012-11-01 10:18修改过]

对业务功能进行分布式划分，很能体现系统设计人员的功力

J2EE死了 javacript + 后端JSON服务方式胜出

能不能从业务需求和技术的两方面详细讲一下云的演变过程？

演变培养了业务和技术之间的信赖关系，这也回答了为什么我们当前业务系统选择这样的技术架构。

至于演变过程在soundclouds云架构演变中写得比较清楚，我大概描述如下：

开始是典型的普通Web架构：
apache + rails + mysql
后替换了Nginx:
Nginx + app + mysql
访问量上来之后，加上负载平衡：
HAProxy + app + mysql

然后导入入异步，再导入缓存，就变成现在架构：

但是该架构将持久化任务交给了亚马逊公有云的S3，大部分情况下，我们还是需要自己的持久化底层设施，除了建设自己的数据中心外，当然很耗资，也是可以采取不同于J2EE的JPA或传统ORM的新的持久范式，通过这种新的持久方式应付庞大数据存储和事务追踪：
面向事件数据库Event Oriented Databases: 一种新的持久范式