微观SOA：服务设计原则及其实践方式

大
量互联网公司都在拥抱SOA和服务化，但业界对SOA的很多讨论都比较偏向高大上。本文试图从稍微不同的角度，以相对接地气的方式来讨论SOA，
集中讨论SOA在微观实践层面中的缘起、本质和具体操作方式，另外也用相当篇幅介绍了当今互联网行业中各种流行的远程调用技术等等，比较适合从事实际工作
的架构师和程序员来阅读。

为了方便阅读，本话题将分为两篇展现。本文是上篇，着眼于微观SOA的定义，并简单分析其核心原则。

亚马逊CEO杰夫•贝佐斯：鲜为人知的SOA大师

由于SOA有相当的难度和门槛，不妨先从一个小故事说起，从中可以管窥一点SOA的大意和作用。

按照亚马逊前著名员工Steve Yegge著名的“酒后吐槽”，2002年左右，CEO贝佐斯就在亚马逊强制推行了以下六个原则：

• 所有团队的程序模块都要以通过Service Interface 方式将其数据与功能开放出来。
• 团队间的程序模块的信息通信，都要通过这些接口。
• 除此之外没有其它的通信方式。其他形式一概不允许：不能使用直接链结程序、不能直接读取其他团队的数据库、不能使用共享内存模式、不能使用别人模块的后门、等等，等等，唯一允许的通信方式只能是能过调用 Service Interface。
• 任何技术都可以使用。比如：HTTP、Corba、Pubsub、自定义的网络协议、等等，都可以，贝佐斯不管这些。
• 所有的Service Interface，毫无例外，都必须从骨子里到表面上设计成能对外界开放的。也就是说，团队必须做好规划与设计，以便未来把接口开放给全世界的程序员，没有任何例外。
• 不这样的做的人会被炒鱿鱼。

据说，亚马逊网站展示一个产品明细的页面，可能要调用200-300个Service，以便生成高度个性化的内容。

Steve还提到：

Amazon已经把文化转变成了“一切以Service第一”为系统架构的公司，今天，这已经成为他们进行所有设计时的基础，包括那些绝不会被外界所知的仅在内部使用的功能。

那
时，如果没有被解雇的的恐惧他们一定不会去做。我是说，他们今天仍然怕被解雇，因为这基本上是那儿每天的生活，为那恐怖的海盗头子贝佐斯工作。不
过，他们这么做的确是因为他们已经相信Service这就是正确的方向。他们对于SOA的优点和缺点没有疑问，某些缺点还很大，也不疑问。但总的来说，这
是正确的，因为，SOA驱动出来的设计会产生出平台（Platform）。

今天，我们都知道亚马逊从世界上最大图书卖场进化为了世界上最成功的云平台……

贝佐斯的六原则展示出高度的远见和超强的信念，即使放到十几年后的今天，依然觉得振聋发聩……想起一句老话：“不谋万世者，不足以谋一时；不谋全局者，不足以谋一隅。”

当然，像贝佐斯这种将神性与魔性集于一身的专横人物，既可能创造划时代的进步，也可能制造前所未有的灾难。

SOA漫谈：宏观与微观

SOA即面向服务架构，是一个特别大的话题。

为了方便讨论，我在此先草率的将SOA分为两个层面（大概模仿宏观和微观经济学，但这里的划分没有绝对界限）：

• 宏观SOA：
  面向高层次的部门级别、公司级别甚至行业级别；涉及商业、管理、技术等方面的综合的、全局的考
  虑；架构体系上包括服务治理（governance，如服务注册，服务监控），服务编排（orchestration，如BPM，ESB)，服务协同
  （choreography，更多面向跨企业集成）等等。我认为SOA本身最主要是面向宏观层面的架构，其带来益处也最能在宏观高层次上体现出来，同时大
  部分SOA的业界讨论也集中在这方面。
• 微观SOA：面向有限的、局部的团队和个人；涉及独立的、具体的服务在业务、架构、开发上的考虑。

很多业界专家都认为SOA概念过于抽象，不接地气，我认为主要是宏观SOA涉及面太广，经常需要做通盘考虑，而其中很多方面距离一般人又比较远。而在微观层面的SOA更容易达到涛哥过去提出的“三贴近”：贴近实际、贴近生活、贴近群众。

同时，宏观SOA要取得成功，通常的前提也是SOA在微观层面的落地与落实，正如宏观经济学一般要有坚实的微观基础（比如大名鼎鼎的凯恩斯主义曾广受诟病的一点就是缺乏微观基础）

因此，我们着眼于SOA落地的目的，着重来分析微观SOA，也算是对业界主流探讨的一个小小的补充。

SOA定义

按照英文*定义：SOA是一种“软件”和“软件架构”的设计模式（或者叫设计原则）。它是基于相互独立的软件片段要将自身的功能通过“服务”提供给其他应用。

什么是“服务”？按照OASIS的定义：Service是一种按照既定“接口“来访问一个或多个软件功能的机制（另外这种访问要符合“服务描述”中策略和限制）

Service示例（代码通常以java示例）public
interface Echo {    String echo(String text);}public class EchoImpl
implements Echo {    public String echo(String text) {        return
text;    }}

现
在将Echo发布为Java
WebServices，并由底层框架自动生成WSDL来作为标准化的服务契约，这样就能与远程的各种语言和平台互操作了，较好的解决了上面提到的松耦合
和可重用的问题。按照一般的理解，Echo似乎就成为比较理想的SOA service了。

但是……即使这个极端简化的例子，也会引出不少很关键的问题，它们决定SOA设计开发的某些难度：

• 将一个普通的Java对象通过添加注解“透明的”变成WebServices就完成了从面向对象到面向服务的跨越？
• 通过Java接口生成WSDL服务契约是好的方式吗？
• WebServices是最合适远程访问技术吗？

面向对象和面向服务的对比

面向对象（OO）和面向服务（SO）在基础理念上有大量共通之处，比如都尽可能追求抽象、封装和低耦合。

但SO相对于OO，又有非常不同的典型应用场景，比如：

• 多
  数OO接口（interface）都只被有限的人使用（比如团队和部门内），而SO接口（或者叫契约）一般来说都不应该对使用者的范围作出太多
  的限定和假设（可以是不同部门，不同企业，不同国家）。还记得贝佐斯原则吗？“团队必须做好规划与设计，以便未来把接口开放给全世界的程序员，没有任何例
  外”。
• 多数OO接口都只在进程内被访问，而SO接口通常都是被远程调用。

简单讲，就
是SO接口使用范围比一般OO接口可能广泛得多。我们用网站打个比方：一个大型网站的web界面就是它整个系统入口点和边界，可能要面对
全世界的访问者（所以经常会做国际化之类的工作），而系统内部传统的OO接口和程序则被隐藏在web界面之后，只被内部较小范围使用。而理想的SO接口和
web界面一样，也是变成系统入口和边界，可能要对全世界开发者开放，因此SO在设计开发之中与OO相比其实会有很多不同。

小结

在前述比较抽象的SOA大原则的基础上，我们可尝试推导一些较细化和可操作的原则，在具体实践中体现SO的独特之处。请关注本系列文章的下篇！

微观SOA：服务设计原则及其实践方式（下篇）

在
上一篇文章中，我说到SOA是一个特别大的话题，不但没有绝对统一的原则，而且很多原则本身的内容也具备相当模糊性和宽泛性。虽然我们可以说 SOA ≈
模块化开发 + 分布式计算，但由于其原则的模糊性，我们仍然很难说什么应用是绝对符合SOA的，只能识别出哪些是不符合SOA的。

本篇将对8种可操作的服务设计原则进行细化的分析，作为SOA实践的参考。

服务设计原则1：优化远程调用

这里的远程调用特指RPC（Remote Procedure Call）。当然更面向对象的说法应该是远程方法调用或者远程服务调用等等。

由于SO接口通常要被远程访问，而网络传输，对象序列化/反序列化等开销都远远超过本地Object访问几个数量级，所以要加快系统的响应速度、减少带宽占用和提高吞吐量，选择高性能的远程调用方式经常是很重要的。

但是远程调用方式往往又要受限于
具体的业务和部署环境，比如内网、外网、同构平台、异构平台等等。有时还要考虑它对诸如分布式事务，消息级别签名/
加密，可靠异步传输等方面的支持程度（这些方面通常被称为SLA：service level
agreement），甚至还包括开发者的熟悉和接受程度等等。

因此，远程调用方式往往需要根据具体情况做出选择和权衡。

以Java远程Service为例分析不同场景下，传输方式的某些可能较好选择：

• 内网 + 同框架Java客户端 + 大并发：多路复用的TCP长连接 + kryo （二进制序列化） （kryo也可以用Protostuff，FST等代替）
• 内网 + 不同框架Java客户端：TCP + Kryo
• 内网 + Java客户端 + 2PC分布式事务：RMI/IIOP （TCP + 二进制）
• 内网 + Java客户端 + 可靠异步调用：JMS + Kryo （TCP + 二进制）
• 内网 + 不同语言客户端：thrift（TCP + 二进制序列化）
• 外网 + 不同语言客户端 + 企业级特性：HTTP + WSDL + SOAP （文本）
• 外网 + 兼顾浏览器、手机等客户端：HTTP + JSON （文本）
• 外网 + 不同语言客户端 + 高性能：HTTP + ProtocolBuffer （二进制）

简单来说，
从性能上讲，tcp协议 + 二进制序列化更适合内网应用。从兼容性、简单性上来说，http协议 +
文本序列化更适合外网应用。当然这并不是绝对的。另外，tcp协议在这里并不是限定远程调用协议一定只能是位于OSI网络模型的第四层的原始tcp，它可
以包含tcp之上的任何非http协议。

所
以，回答上面提到的问题，WebServices
（经典的WSDL+SOAP+HTTP）虽然是最符合前述SOA设计原则的技术，但并不等同于SOA，我认为它只是满足了SOA的底线，而未必是某个具体
场景下的最佳选择。这正如一个十项全能选手在每个单项上是很难和单项冠军去竞争的。更理想的SOA
Service最好能在可以支持WebServices的同时，支持多种远程调用方式，适应不同场景，这也是Spring
Remoting，SCA，Dubbo，Finagle等分布式服务框架的设计原则。

远程调用技术解释：HTTP + JSON适合SOA吗？

JSON简单易读，通用性极佳，甚至能很好支持浏览器客户端，同时也常被手机APP使用，大有取代XML之势。

但
JSON本身缺乏像XML那样被广泛接受的标准schema，而一般的HTTP +
JSON的远程调用方式也缺乏像Thrift，CORBA，WebServices等等那样标准IDL（接口定义语言），导致服务端和客户端之间不能形成
强的服务契约，也就不能做比如自动代码生成。所以HTTP + JSON在降低了学习门槛的同时，可能显著的增加复杂应用的开发工作量和出错可能性。

例如，新浪微博提供了基于HTTP + JSON的Open API，但由于业务操作比较复杂，又在JSON上封装实现了各种语言的客户端类库，来减少用户的工作量。

为了解决这方面的问题，业界有很多不同方案来为HTTP + JSON补充添加IDL，如RSDL、JSON-WSP、WADL、WSDL 2.0等等，但事实上它们的接受度都不太理想。

另外值得一提的是，JSON格式和XML一样有冗余，即使做GZIP压缩之类的优化，传输效率通常也不如很多二进制格式，同时压缩、解压还会引入额外的性能开销。

远程调用技术解释：Apache Thrift多语言服务框架

Thrift
是最初来自facebook的一套跨语言的service开发框架，支持C++, Java, Python, PHP, Ruby, Erlang,
Perl, Haskell, C#, JavaScript, Node.js, Smalltalk,
Delphi等几乎所有主流编程语言，具有极好的通用性。

Thrift被facebook，twitter等巨头以及开源社区都广泛使用，是非常成熟的技术。

Thrift的服务契约通过类似如下形式的IDL定义：

struct
User {    1: i32 id,    2: string name,    3: string password}service
UserService {    void store(1: User user),    UserProfile retrieve(1:
i32 id)}

OO中我们完全可以让用户自己来灵活选择，分别调用这些细粒度的可复用的方法。但在SO中，我们需要将他们封装到一个粗粒度的方法供用户做一次性远程调用，同时也隐藏了内部业务的很多复杂性。另外，客户端也从依赖4个方法变成了依赖1个方法，从而大大降低了程序耦合度。

顺
便值得一提的是，如果上面订单用例中每个操作本身也是远程的service（通常在内网之中），这种粗粒度封装就变成了经典的service
composition（服务组合）甚至service
orchestration（服务编排）了。这种情况下粗粒度service同样可能提高了性能，因为对外网客户来说，多次跨网的远程调用变成了一次跨网
调用 + 多次内网调用。

对
这种粗粒度service封装和组合，经典解决方案就是引入OO中常用的Facade模式，将原来的对象屏蔽到专门的“外观”接口之后。同时，这
里也很可能要求我们引入新的service参数/返回值的数据结构来组合原来多个操作的对象模型，这就同样用到前述的DTO模式。

一个简单Facade示例（FooService和BarService是两个假想的本地OO service，façade将它们的结果值组合返回）：

class
FooBarFacadeImpl implements FooBarFacade {    private FooService
fooService;    private BarService barService;    public FooBarDto
getFooBar() {        FooBarDto fb = new FooBarDto();    
   fb.setFoo(fooService.getFoo());    
   fb.setBar(barService.getBar());        return fb;    }}

虽然OO和SO都追求低耦合，但SO由于使用者范围极广，就要求了更高程度的低耦合性。

比
如前述的article
service，OO中可以直接返回article对象，而这个article对象在OO程序内部可能做为核心的建模的domain
model，甚至作为O/R
mapping等等。而在SO如果还直接返回这个article，即使没有前面所说的冗余字段，复杂类型等问题，也可能让外部用户与内部系统的核心对象模
型，甚至O/R mapping机制，数据表结构等等产生了一定关联度，这样一来，内部的重构经常都会可能影响到外部的用户。

所以，这里再次对Facade和DTO产生了需求，用它们作为中介者和缓冲带，隔离内外系统，把内部系统变化对外部的冲击减少到最小程度。

服务设计原则6：契约先行

Service
是往往涉及不同组织之间的合作，而按照正常逻辑，两个组织之间合作的首要任务，就是先签订明确的契约，详细规定双方合作的内容，合作
的形式等等，这样才能对双方形成强有力的约束和保障，同时大家的工作也能够并行不悖，不用相互等待。因此SOA中，最佳的实践方式也是契约先行，即先做契
约的设计，可以有商务，管理和技术等不同方面的人员共同参与，并定义出相应的WSDL或者IDL，然后在开发的时候再通过工具自动生成目标语言的对应代
码。

对
于WSDL来说，做契约先行的门槛略高，如果没有好的XML工具很难手工编制。但对于Thrift
IDL或者ProtocolBuffer等来说，由于它们和普通编程语言类似，所以契约设计相对是比较容易的。另外，对于简单的HTTP +
JSON来说（假设不补充使用其他描述语言），由于JSON没有标准的schema，所以是没法设计具有强约束力的契约的，只能用另外的文档做描述或者用
JSON做输入输出的举例。

但
是，契约先行，然后再生成服务提供端的代码，毕竟给service开发工作带来了较大的不便，特别是修改契约的时候导致代码需要重写。因此，这里
同样可能需要引入Facade和DTO，即用契约产生的都是Facade和DTO代码，它们负责将请求适配和转发到其他内部程序，而内部程序则可以保持自
己的主导性和稳定性。

另外，契约先行可能会给前面提到的多远程调用支持带来一些麻烦。

当然契约先行也许并不是能被广泛接受的实践方式，就像敏捷开发中“测试先行”（也就是测试驱动开发）通常都是最佳实践，但真正施行的团队却非常之少，这方面还需要不断摸索和总结。但我们至少可以认为Echo中Java2WSDL并不被认为是SOA的最佳实践。

服务设计原则7：稳定和兼容的契约

由于用户范围的广泛性，所以SO的服务契约和Java标准API类似，在公开发布之后就要保证相当的稳定性，不能随便被重构，即使升级也要考虑尽可能的向下兼容性。同时，如果用契约先行的方式，以后频繁更改契约也导致开发人员要不断重做契约到目标语言映射，非常麻烦。

这就是说SO对契约的质量要求可能大大高于一般的OO接口，理想的情况下，甚至可能需要专人（包括商务人员）来设计和评估SO契约（不管是否用契约先行的方式），而把内部的程序实现交给不同的人，而两者用Facade和DTO做桥梁。

服务设计原则8：契约包装

前述原则基本都是针对service提供端来讲的，而对service消费端而言，通过契约生成对应的客户端代码，经常就可以直接使用了。当然，如果契约本身就是Java接口之类（比如在Dubbo，Spring Remoting等框架中），可以略过代码生成的步骤。

但是，service的返回值（DTO）和service接口（Facade），可能被消费端的程序到处引用到。

这样消费端程序就较强的耦合在服务契约上了，如果服务契约不是消费端定义的，消费端就等于把自己程序的部分主导权完全让渡给了别人。

一旦契约做更改，或者消费端要选择完全不同的service提供方（有不同的契约），甚至改由本地程序自己来实现相关功能，修改工作量就可能非常大了。

另外，通过契约生成的客户端代码，经常和特定传输方式是相关的（比如webservices stub），这样给切换远程调用方式也会带来障碍。

因
此，就像在通常应用中，我们要包装数据访问逻辑（OO中的DAO或者Repository模式），或者包装基础服务访问逻辑（OO中的
Gateway模式）一样，在较理想的SOA设计中，我们也可以考虑包装远程service访问逻辑，由于没有恰当的名称，暂时称之为Delegate
Service模式，它由消费端自己主导定义接口和参数类型，并将调用转发给真正的service客户端生成代码，从而对它的使用者完全屏蔽了服务契约，
这些使用者甚至不知道这个服务到底是远程提供的的还是本地提供的。

此外，即使我们在消费端是采用某些手工调用机制（如直接构建和解析json等内容，直接收发JMS消息等等），我们同样可以用delegate service来包装相应的逻辑。

delegate service示例1：

//
ArticlesService是消费端自定义的接口class ArticleServiceDelegate implements
ArticlesService {    // 假设是某种自动生成的service客户端stub类    private
ArticleFacadeStub stub;    public void deleteArticles(List<Long>
ids) {        stub.deleteArticles(ids);    }}

delegate service示例2：

//
ArticlesService是消费端自定义的接口class ArticleServiceDelegate implements
ArticlesService {    public void deleteArticles(List<Long> ids) { 
      // 用JMS和FastJson手工调用远程service    
   messageClient.sendMessage(queue, JSON.toJSONString(ids));    }}   从面向对象到面向服务，再从面向服务到面向对象

service消费端：OO程序 -> Delegate Service -> SOA层（Facade和DTO 或者 其他动态调用机制）-> 远程提供端

Facade、DTO和Delegate Service负责做OO到SO和SO到OO的中间转换。

现在，可以回答Echo示例中的问题：通过“透明的”配置方式，将OO程序发布为远程Service，虽然可能较好的完成了从本地对象到远程对象的跨越，但通常并不能较好的完成OO到SO的真正跨越。

同时，透明配置方式也通常无法直接帮助遗留应用（如ERP等）转向SOA。

当然，在较为简单和使用范围确定很有限应用（比如传统和局部的RPC）中，透明式远程service发布会带来极大的便利。

另外，上面对SO的所有讨论都集中在RPC的方式，其实SO中也用message的方式做集成，它也是个大话题，暂时不在此详论了。

为什么不能放弃面向对象？

SO是有它的特定场景的，比如远程的，范围不定的客户端。所以它的那些设计原则并不能被借用来指导一般性的程序开发，比如很多OO程序和SO原则完全相反，经常都要提供细粒度接口和复杂参数类型以追求使用的使用灵活性和功能的强大性。

就
具体架构而言，我认为SOA层应该是一个很薄的层次（thin
layer），将OO应用或者其他遗留性应用加以包装和适配以帮助它们面向服务。其实在通常的web开发中，我们也是用一个薄的展现层（或者叫Web
UI层之类）来包装OO应用，以帮助它们面向浏览器用户。因此，Façade、DTO等不会取代OO应用中核心的Domain
Model、Service等等 （这里的service是OO中service，未必是SO的）。

综合起来，形成类似下面的体系结构：

file:///C:/Users/Administrator/AppData/Local/YNote/Data/[e-mail]/cd143961251a4105a0deb55584f22161/architecture.png

理想和现实

需要特别指出的是，上面提到的诸多SO设计原则是在追求一种相对理想化的设计，以达到架构的优雅性，高效性，可重用性，可维护性，可扩展性等等。

而在现实中任何理论和原则都可能是需要作出适当妥协的，因为现实是千差万别的，其情况远比理论复杂，很难存在放之四海而皆准的真理。

而且很多方面似乎本来也没有必要追求完美和极致，比如如果有足够能力扩充硬件基础设施，就可以考虑传输一些冗余数据，选择最简单传输方式，并多来几次远程调用等等，以减轻设计开发的工作量。

那
么理想化的原则就没有意义了吗？比如领域驱动设计（Domain-Driven
Design）被广泛认为是最理想的OO设计方式，但极少有项目能完全采用它；测试驱动开发也被认为是最佳的敏捷开发方式，但同样极少有团队能彻底采用
它。但是，恐怕没有多少人在了解它们之后会否认它们巨大的意义。

理想化的原则可以更好的帮助人们理解某类问题的本质，并做为好的出发点或者标杆，帮助那些可以灵活运用，恰当取舍的人取得更大的成绩，应付关键的挑战。这正如孔子说的“取乎其上，得乎其中；取乎其中，得乎其下；取乎其下，则无所得矣”。

另外，值得一提的是，SOA从它的理念本身来说，就带有一些的理想主义的倾向，比如向“全世界”开放，不限定客户端等等。如果真愿意按SOA的路径走，即使你是个土豪，偷个懒比浪费网络带宽重要，但说不定你的很多用户是土鳖公司，浪费几倍的带宽就大大的影响他们的利润率。

延伸讨论：SOA和敏捷软件开发矛盾吗？

SOA的服务契约要求相当的稳定性，一旦公开发布（或者双方合同商定）就不应该有经常的变更，它需要对很多方面有极高的预判。而敏捷软件开发则是拥抱变化，持续重构的。软件设计大师Martin Fowler把它们归结为计划式设计和演进式设计的不同。

计划理论（或者叫建构理论）和演进理论是近代哲学的两股思潮，影响深远，派生出了比如计划经济和市场经济，*和*主义等等各种理论。

但
是，计划式设计和演进式设计并不绝对矛盾，就像计划经济和市场经济也不绝对矛盾，非此即彼，这方面需要在实践中不断摸索。前面我们讨论的设计原则
和架构体系，就是将SOA层和OO应用相对隔离，分而治之，在SOA层需要更多计划式设计，而OO应用可以相对独立的演进，从而在一定程度缓解SOA和敏
捷开发的矛盾。

延伸讨论：SOA和REST是一回事吗？

从最本质的意义上讲，REST（Representational State Transfer）实际是一种面向资源架构（ROA），和面向服务架构（SOA）是有根本区别的。

例
如，REST是基于HTTP协议，对特定资源做增（HTTP POST）、删（HTTP DELETE）、改（HTTP PUT）、查（HTTP
GET）等操作，类似于SQL中针对数据表的INSERT、DELETE、UPDATE、SELECT操作，故REST是以资源（资源可以类比为数据）为

中心的。而SOA中的service通常不包含这种针对资源（数据）的细粒度操作，而是面向业务用例、业务流程的粗粒度操作，所以SOA是以业务逻辑为中
心的。

但
是在实际使用中，随着许多REST基本原则被不断突破，REST的概念被大大的泛化了，它往往成为很多基于HTTP的轻量级远程调用的代名词（例
如前面提到过的HTTP + JSON）。比如，即使是著名的Twitter REST API也违反不少原始REST的基本原则。

在这个泛化的意义上讲，REST也可以说是有助于实现SOA的一种轻量级远程调用方式。

SOA架构的进化

前面讨论的SOA的所有问题，基本都集中在service本身的设计开发。但SOA要真正发挥最大作用，还需要不断演进成更大的架构（也就是从微观SOA过渡到宏观SOA），在此略作说明：

• 第一个层次是service架构：开发各种独立的service并满足前面的一些设计原则，我们前面基本都集中在讨论这种架构。这些独立的service有点类似于小孩的积木。
• 第二个层次是service composition（组合）架构：
  独立的service通过不同组合来构成
  新的业务或者新的service。在理想情况下，可以用一种类似小孩搭积木的方式，充分发挥想象力，将独立的积木（service）灵活的拼装组合成新的
  形态，还能够*的替换后其中的某个构件。这体现出SOA高度便捷的重用性，大大提高企业的业务敏捷度。
• 第三个层次是service inventory（清单）架构：通过标准化企业服务清单（或者叫注册中心）统一的组织和规划service的复用和组合。当积木越来越多了，如果还满地乱放而没有良好的归类整理，显然就玩不转了。
• 第四个层次是service-oriented enterprise架构……

总结

至此，我们只是简要的探讨了微观层面的SOA，特别是一些基本设计原则及其实践方式，以期能够略微展示SOA在实践中的本质，以有助于SOA更好的落地，进入日常操作层面。

最后，打个比方：SOA不分贵贱（不分语言、平台、组织），不远万里（通过远程调用）的提供服务（service），这要求的就是一种全心全意为人民服务的精神……