SOA定义
SOA是一个组件模型，它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。
这种具有中立的接口定义(没有强制绑定到特定的实现上)的特征称为服务之间的松耦合。SOA的目的，就是要将复杂的紧耦合的系统进行解耦，划分成面向业务的，细粒度，松耦合，无状态的服务。松耦合系统的好处有两点，一点是它的灵活性，另一点是，当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。而另一方面，紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当需要对部分或整个应用程序进行某种形式的更改时，它们就显得非常脆弱，变更可能会导致部分乃至整个系统的重构。
对松耦合的系统的需要来源于业务应用程序需要根据业务的需要变得更加灵活，以适应不断变化的环境，比如经常改变的政策、业务级别、业务重点、合作伙伴关系、行业地位以及其他与业务有关的因素，这些因素甚至会影响业务的性质。我们称能够灵活地适应环境变化的业务为按需(On demand)业务，在按需业务中，一旦需要，就可以对完成或执行任务的方式进行必要的更改。
SOA是传统的面向对象架构模型的替代模型，面向对象的模型是紧耦合的，已经存在二十多年了。虽然基于 SOA 的系统并不排除使用面向对象的设计来构建单个服务，但是其整体设计却是面向服务的。由于它考虑到了系统内的对象，所以虽然 SOA 是基于对象的，但是作为一个整体，它却不是面向对象的。不同之处在于接口本身。SOA 系统原型的一个典型例子是通用对象请求代理体系结构(Common Object Request Broker Architecture，CORBA)，它已经出现很长时间了，其定义的概念与 SOA 相似。
然而，现在的 SOA 已经有所不同了，因为它依赖于一些更新的进展，这些进展是以可扩展标记语言(eXtensible Markup Language，XML)为基础的。通过使用基于 XML 的语言(称为 Web 服务描述语言(Web Services Definition Language，WSDL))来描述接口，服务已经转到更动态且更灵活的接口系统中，非以前 CORBA 中的接口描述语言(Interface Definition Language，IDL)可比了。更新的，如protobuf，Thrift等标记语言，则已经在RPC与其他服务协议中占有极为重要的角色。
Web 服务并不是实现 SOA 的惟一方式。前面刚讲的 CORBA 是另一种方式，这样就有了面向消息的中间件(Message-Oriented Middleware)系统。但是为了建立体系结构模型，您所需要的并不只是服务描述。您需要定义整个应用程序如何在服务之间执行其工作流。您尤其需要找到业务的操作和业务中所使用的软件的操作之间的转换点。因此，SOA 应该能够将业务的商业流程与它们的技术流程联系起来，并且映射这两者之间的关系。例如，给供应商付款的操作是商业流程，而更新您的零件数据库，以包括进新供应的货物却是技术流程。因而，工作流还可以在 SOA 的设计中扮演重要的角色。
此外，动态业务的工作流不仅可以包括部门之间的操作，甚至还可以包括与不为您控制的外部合作伙伴进行的操作。因此，为了提高效率，您需要定义应该如何得知服务之间的关系的策略，这种策略常常采用服务级协定和操作策略的形式。
最后，所有这些都必须处于一个信任和可靠的环境之中，以同预期的一样根据约定的条款来执行流程。因此，安全、信任和可靠的消息传递应该在任何 SOA 中都起着重要的作用。
SOA原则
FROM WIKI
以下指导原则是开发，维护和使用SOA的基本原则：
- 可重复使用, 粒度, 模组性, 可组合型, 物件化原件, 构件化以及具交互操作性
- 符合开放标准(通用的或行业的)
- 服务的识别和分类，提供和发布，监控和跟踪。
下面是一些特定的体系架构原则：
- 服务封装
- 服务松耦合(Loosely coupled) – 服务之间的关系最小化，只是互相知道。(Decouple Infrastructure)
- 服务契约 - 服务按照服务描述文档所定义的服务契约行事。
- 服务抽象 - 除了服务契约中所描述的内容，服务将对外部隐藏逻辑。
- 服务的重用性 - 将逻辑分布在不同的服务中，以提高服务的重用性。
- 服务的可组合性 - 一组服务可以协调工作并组合起来形成一个组合服务。
- 服务自治 – 服务对所封装的逻辑具有控制权
- 服务无状态 – 服务将一个活动所需保存的资讯最小化。
- 服务的可被发现性 – 服务需要对外部提供描述资讯，这样可以通过现有的发现机制发现并访问这些服务。[4]
除此以外，在定义一个SOA实现时，还需要考虑以下因素：
- 生命周期管理
- 有效使用系统资源
- 服务成熟度和性能
SOA用途
对 SOA 的需要来源于需要使业务 IT 系统变得更加灵活，以适应业务中的改变。通过允许强定义的关系和依然灵活的特定实现，IT 系统既可以利用现有系统的功能，又可以准备在以后做一些改变来满足它们之间交互的需要。
改变和 SOA 系统适应改变的能力是最重要的部分。对于开发人员来说，这样的改变无论是在他们工作的范围之内还是在他们工作的范围之外都有可能发生，这取决于是否有改变需要知道接口是如何定义的以及它们相互之间如何进行交互。与开发人员不同的是，架构师的作用就是引起对 SOA 模型大的改变。这种分工，就是让开发人员集中精力于创建作为服务定义的功能单元，而让架构师和建模人员集中精力于如何将这些单元适当地组织在一起。
SOA与微服务
相比于基于业务的SOA，微服务则纯粹基于服务模块，也就是每个服务独立为一个子系统，平行扩容对其他服务透明，强调系统的伸缩性，服务发现，负载均衡，故障转移，高可用。微服务是互联网时代的新产物，它对服务的容错与可用提出了更新的思考，比如多版本，灰度发布，服务降级，分布式跟踪，这些都是SOA在实践中重视不够的地方，。
SOA在企业领域的应用更为广泛，对服务的可用性保证也很高，而很多现代互联网企业，对实时性的要求，对数据一致性的要求，甚至对大流量下可用性的要求都是弹性的，比如腾讯，很多业务服务的运营核心是：有损服务，动态运营，这时候，微服务的作用就显现出来，在海量请求下，尽量保证大多数用户的服务，尽量快（弱一致性）的实现数据的同步。可以说，SOA与微服务在不同的领域，但做法可以相互借鉴。