http://hi.baidu.com/gaohong230/blog/item/cd3924396bc7332fb9998f52.html

SOAP

   什么是SOAP，我想不用多说，google一把满眼都是。其实SOAP最早是针对RPC的一种解决方案，简单对象访问协议，很轻量，同时作为应用协议可以基于多种传输协议来传递消息（Http,SMTP等）。但是随着SOAP作为WebService的广泛应用，不断地增加附加的内容，使得现在开发人员觉得SOAP很重，使用门槛很高。在SOAP后续的发展过程中，WS-*一系列协议的制定，增加了SOAP的成熟度，也给SOAP增加了负担。

REST

   REST其实并不是什么协议也不是什么标准，而是将Http协议的设计初衷作了诠释，在Http协议被广泛利用的今天，越来越多的是将其作为传输协议，而非原先设计者所考虑的应用协议。SOAP类型的WebService就是最好的例子，SOAP消息完全就是将Http协议作为消息承载，以至于对于Http协议中的各种参数（例如编码，错误码等）都置之不顾。其实，最轻量级的应用协议就是Http协议。Http协议所抽象的get,post,put,delete就好比数据库中最基本的增删改查，而互联网上的各种资源就好比数据库中的记录（可能这么比喻不是很好），对于各种资源的操作最后总是能抽象成为这四种基本操作，在定义了定位资源的规则以后 ...

使大型分布式系统大型服务化之后足高可用及低运营成本，新的系统架构需要满足以下条件：

1. 服务管理框架需要具备的功能

1.1. 容错性

failover：客户端容错支持，并支持自动失效探测及恢复调用； failfast：快速失败。很多远程服务调用是在关键路径中，它可以容忍失败，但是不能容忍堵塞； failback：故障恢复。能够快速定位错误，进行reset来尝试恢复。

1.2. 中心化的运营管理

【部署】动态启用及停用服务及节点：可以动态启动及停用服务（热发布）； 【配置】配置及推送功能：所有client在同一时刻配置的一致性，并且client会跟配置中心保持长连接； 【性能及可用性】负载均衡策略：支持round robin，least active, consistent hash，或者基于脚本的动态路由策略。这个都是由配置中心来控制； 【监控】访问统计及动态运行参数查看：可以对方法级别进行访问统计及实时观察；

1.3. 开发支持

跨语言：支持client能使用常见主流语言来访问； 零侵入：架构对调用方式和具体业务逻辑透明 ...

主要内容也是来自《SteveY对Amazon和Google平台的长篇大论》

1. 通过服务接口提供全部数据和操作

2. 容错与服务保护

3. 监控与QA

仅有一个确定主进程不死的响应不是监控。如果测试覆盖到能验证所有业务逻辑的程度，当然是最好的。但我迄今为止，没见过太多的团队（仅有一个团队）完成了如此缜密细致的测试用例。 我觉得比较理想的监控系统要让业务人员“看到 ...

本文是《SteveY对Amazon和Google平台的长篇大论》的精编缩略篇，新阳推荐。原文翻译得比较急，缩略过程中对文字进行了修改，尽量让大家阅读得更顺利。

此文很鼓劲儿，我们的SOA步伐还应该再迈得再大些。

注：Steve Yegge， Amazon的前员工，现任Google员工，在两个公司都待了六年以上。

Amazon已经把文化转变成了“一切Service第一”为系统架构的公司，今天，这已经成为他们进行所有设计时的基础，包括那些绝不会被外界所知的仅在内部使用的功能。他们对于SOA的优缺点都了如指掌，能够采取有效的措施克服缺点从而取得成功。因为，SOA驱动出来的设计会产生出平台（Platform）。 对大多数（其他公司）的团队来说，只是让他们开发几个存取他们数据、提供一些运算的小小Servcie，这些服务都提供对外可编程接口。对他们来说就感到翻天覆地了，觉得自己在做产品，但其实只是提供了一些凄惨粗糙的Service。就算是这些粗糙的东西很不错，不过这就好像要汽车的时候，你却只有汽车的零件。//平台提供的服务要具有可用性

没有平台的产品是没用的，再精确一点，去平台化的产品总是被平台化的产品所取代。//提供开放式的API是大势所趋

平台Platform的黄金守则是Eat Your Own Dogfood（吃你自己的狗食——自己都要用自己的平台 ...

新阳写了一个很棒的Thrift技术演进方案，甚至包含了架构基础代码。这个SOA方案有以下几个闪亮的特性： 1. 可用性：消除单点故障隐患，提供水平扩容的基础； 2. 可维护性：提高服务监控的粒度、规范化程度、自动化程度 3. 可改进性：包括Client端调用方式和Server端实现方式 这个方案最大的亮点就是层次分明：虽然是为Thrift量身定做的技术架构，但这些特性对采取什么具体技术来说并没有强制性的要求。

那么还有没有其它需求可以在SOA框架中满足呢？判断标准又是什么呢？我给出我的思考，希望能看到大家的真知灼见。

首先先给出选择特性的基本原则，然后讨论要为需求提供的特性及实现思路。 基本原则

1. 适用性原则 在架构层面被满足的需求应该是对大多数服务来说都必须要满足的需求。 从公司业务情况来看，高可用性、水平可扩展性（Scale out）、可维护性等是所有服务都必须满足的特性。
2. 投入产出比原则 主要考虑两方面因素，架构层面实现特性的代价和具体应用获得特性的代价。 举例来说，如果想要的特性在具体业务中的表现是不一样的，那么在架构上实现这个特性时还得考虑到具体业务的场景，那么直接把这个特性放到具体应用中就更合理； 如果具体应用能够添加一个组件或者依靠继承来获得架构特性，这个代价就是合理的。
3. 轮子原则 大家都知道，在工作中不要重新发明轮子，用现成的就好了。 再往具体了说，如果有现成的工具或系统能支持的特性，一般来说不要带到架构层面实现了 ...

1. 生成基础代码 1) 创建接口定义文件

   namespace java com.li3huo.thrift.example

struct UserProfile { 1: i32 uid, 2: string name, 3: string email } service UserStorage { void store(1: UserProfile user), UserProfile retrieve(1: i32 uid) } 2) 生成Java基础代码

thrift -r -gen java:java5 example.thrift

mkdir java #own code mkdir ...

Thrift的入门文档需要更新

运行Thrift的应用（Java）

其实Thrift不用安装就能跑。 为了安装Thrift，在Mac（Lion）上还得装Xcode4才能configuration和make，Turorial的顺序不是最简单路径。 应该准备一个QuickStart（只要提供tutorial.jar，80多k的jar包就够了），让大家直接拿一个可运行的程序，这样能吸引更多新手啊。 如果手头儿没有现成儿可以跑的程序，那就得安装Thrift（Gen Java Code）之后编译示例文件从头开始生成tutorial.jar了。

安装Thrift

chmod +x configure ./configure ./make sudo ...

感觉今天两个主题搭配的不错，应该很少有同时关注服务架构和前端开发的人。不过听了淘宝小马的发言，好像也不是那么回事，前端的工程师也是很关心架构的。

下面开始记录今天的流水账，第一个议题是InfoQ团队介绍，米国、罗马尼亚、加拿大和中国的，台上站满了，一共11个左右，挺精干的组成。

Jim Webber《使用 REST构建成功的SOA》 - 四星

第一场是Jim Webber演讲《使用 REST构建成功的SOA》。Jim是个很精悍的小个子，像个海军陆战队员。他的演讲特点就是非常有激情。他讲的重点主题有两个，一个是数据库并不适合扩展性，建议大家都NoSQL吧，然后给出了在安全性、事务性方面的解决方案；第二个是倡导基于HTTP的中间件，人家就是将REST的嘛。很不错。

谢恩伟《微软 Azure云计算平台的应用与发展》 - 三星

第二场是来自微软工具和平台事业部的谢恩伟讲《微软 Azure云计算平台的应用与发展》。老实说我觉得讲得还可以，ppt里面给出了微软的云计算定义、云计算内涵，对微软的战略给出比较清晰的描述。会后给评价，贴了笑脸儿。

萧百龄《性能 ...

原文： http://horicky.blogspot.com/2010/01/roadmap-to-saas.html

托GFW的福，我们看不到Richy Ho写的博客，更看不到Roadmap to SaaS里面的示意图。但这篇文章真的很不错，文字很简单，翻译出来和大家分享。

以下进入正文：

我发现了如何从传统Web应用一步一步迁移到SaaS的迁移模式。我会用一个J2EE的web应用架构做示例进行讲解，但对于其他技术平台来说，也是一样的。

1. 初始的web应用

At the very beginning, we have an web application that works well. We analyze the function of the web application and group the implementation classes ...