曾今SOA的概念犹如今日“云计算、大数据”一样，被炒得火热，不少企业便纷纷响应，并宣称会拥抱和实施SOA。而事实上，业界出现了两种极端：一种是由于各类文章和书籍关于SOA的描述往往太过抽象，再加上各大厂商的呼吁，使得SOA往往显得“高大上”，令不少企业和架构师们望而却步。第二种恰好相反，有部分人却认为SOA无非是“新瓶装旧酒”。

个人理解，SOA在宏观上确实太复杂，因为它涉及到的不仅仅是技术和架构本身。而从技术的视角来看，并非难以落地。

SOA全称“面向服务架构”，它提供的是一种架构风格和理念，而并非是一种技术或者产品。并不是说项目中用了WebService、WCF、Hessian、RMI之类的就是SOA了。

通俗点来讲，SOA提倡将不同应用程序的业务功能封装成“服务”并宿主起来，通常以接口和契约的形式暴露并提供给外界应用访问（通过交换消息），达到不同系统可重用的目的。

流行的WebService等可以看作是实现SOA基础设施的技术方法。当然，实践SOA不仅需要解决服务调用的问题，还包括服务编排、服务治理、服务路由、服务监控等一系列的问题。在大型分布式系统中，SOA被广泛实践，但是在不同的应用场景中，设计方法也大不相同。

SOA是一个组件模型，它能将不同的服务通过定义良好的接口和契约联系起来。服务是SOA的基石，在开始服务设计和SOA实践之前，有必要先了解服务的概念以及服务的常见特性。

何为服务

服务的概念非常宽泛，在宏观上，服务的理解是“为他人做事，满足他人需要，而且通常是不以实物形式提供劳动的…”。在SOA系统中，服务指的是应用程序的功能单元，它通常体现了业务功能。服务是一种抽象，它向服务使用者隐藏了服务内部的实现细节。根据服务设计的基本原则，服务可能会具有以下特性：

l  自治（理）性

服务应该是独立部署和运行存在的，且边界清晰，应尽量减少对外部的引用和依赖。

l  粗粒度

服务调用是需要开销的，这也是实现松耦合的分布式系统必须付出的代价。因此，应尽量通过一次服务调用传输所有需要的数据，而不是分多次去调用服务和组装数据。

l  可见性

服务是对外提供的，必须在某公共的地方可搜寻和发现，且服务要有必要的描述。

l  无状态

服务不应该依赖于其他服务的上下文、会话等，尽量减少不必要的状态管理流程所带来的资源消耗。但是，对于业务流程服务而言，状态数据是不可避免的。

l  幂等性

当消费者调用服务后，服务调用可能会有“成功、失败、超时”这三种状态，当服务并没有最终响应完成时，消费者可以尝试反复地调用服务，这样仍不会影响到最终结果。

l  可重用性

服务应该是可以被重用的，相同功能应可以调用相同的服务，这也是软件设计的原则。

l  可组合

服务是可以被当作成一个步骤的，服务也可以调用其它的服务。这样能够灵活的组合。

有关服务的“粗粒度、无状态、幂等性”等特性，一直是饱受争议的话题，可谓见仁见智。这里有必要说明下，这些特性并不是服务不可或缺的，应当在实践中根据需求来取舍。

SOA所面临的问题

SOA架构将公共的业务拆分出来，形成可共用的服务，最大程度的保障了代码和逻辑的复用，避免了系统的重复建设，并且让应用程序的部署找到了一种持续可扩展的方案，给应用抗负载能力带来了质的飞跃。

SOA架构所面临的一大问题就是如何解决集成服务应用普遍存在的一致性问题，举例来说，同时调用多个服务，当其中一个服务调用失败时，其他服务已经处理执行的结果该如何进行回滚，这在单机本地调用的情况下使用事务比较好处理，而分布式环境下的事务将问题复杂化，并且性能开销难以承受，因此，只有在极端情况下才会考虑强一致性，一般情况下更多的关注最终一致性。另外一个就是安全问题，面向企业的平台级的SOA架构，需要对参数传递、响应内容以及各种用户私有信息的交互，有着更严格的且特殊的安全需求，如何构建一个安全的SOA架构体系，也给技术人员带来了很大的挑战。

在讲了很多“大而空”的理论之后，估计很多人要拍砖了。后面文章中将会讲一些干货，更贴合实际应用。先预告一下后面文章：

1.SOA之基于服务总线的设计

（从设计的角度讲述服务总线--比较适合企业级系统集成的设计方式）

2.大型分布式网站的演变历程

（随着网站快速发展，解决业务复杂化、大流量、稳定性等问题的必经之路。正所谓“天下大势，分久必合，合久必分”。

重点不是讲负载均衡这些手段，而是设计层面的“集中式”到“分布式”）

3.SOA架构体系之通信协议和远程调用（RPC）

（讲解具体的实现技术，对比各自优缺点）

4.SOA之基于服务框架的应用

（服务化实践--介绍流行的服务框架，重点演示一种服务框架的使用）