面向服务架构（SOA）是一种建设企业 IT 生态系统的架构指导思想。SOA 的关注点是服务。服务最基本的业务功能单元，由平台中立性的接口契约来定义。
通过将业务系统服务化，可以将不同模块解耦，各种异构系统间可以轻松实现服务调用、消息交换和资源共享。
（1）从宏观的视角来看，不同于以往的孤立业务系统，SOA 强调整个企业 IT 生态环境是一个大的整体。整个 IT 生态中的所有业务服务构成了企业的核心 IT 资源。
各系统的业务拆解为不同粒度和层次的模块和服务，服务可以组装到更大的粒度，不同来源的服务可以编排到同一个处理流程，实现非常复杂的集成场景和更加丰富的业务功能。
（2）从研发的视角来看，系统的复用可以从以前代码级的粒度，扩展到业务服务的粒度；能够快速应对业务需求和集成需求的变更。
（3）从管理的角度来看，SOA 从更高的层次对整个企业 IT 生态进行统一的设计与管理，对消息处理与服务调用进行监控，优化资源配置，降低系统复杂度和综合成本，为业务流程梳理和优化提供技术支撑。
SOA 落地方式
SOA 的落地方式与水平，跟企业 IT 特点、服务能力和发展阶段直接相关。目前常见的落地方式主要有分布式服务化和集中式管理两种。
（1）分布式服务化
互联网类型的企业，业务与技术发展快，数据基数与增量都大，并发访问量高，系统间依赖关系复杂、调用频繁，分布式服务化与服务治理迫在眉睫。
通过统一的服务化技术手段，进一步实现服务的注册与寻址、服务调用关系查找、服务调用与消息处理监控、服务质量与服务降级等等。
现有的一些分布式服务化技术有 Dubbo（基于 Java）、Finagle（基于 Scala）和 ICE（跨平台）等。
（2）集中式管理
传统企业的 IT 内部遗留系统包袱较重，资源整合很大一部分是需要打通新旧技术体系的任督二脉，所以更偏重于以 ESB 作为基础支撑技术。
以整合集成为核心，将各个新旧系统的业务能力逐渐的在 ESB 容器上聚合和集成起来。
比较流行的商业 ESB 有 IBM 的 WMB 和 Oracle 的 OSB，开源 ESB 有 Mule、ServiceMix/WSO2 ESB、JBoss ESB 和 OpenESB。
一方面，集中式管理的 SOA，其优势在于管理和集成企业内部各处散落的业务服务能力，同时一个明显的不足在于其中心化的架构方法，并不能解决各个系统自己内部的问题。
另一方面，随着自动化测试技术、轻量级容器技术等相关技术的发展，分布式服务技术越来越像微服务架构方向发展。
分布式架构：微服务架构（MSA）
James Lewis 和 Martin Fowler 给微服务架构的定义如下：
微服务架构风格，以实现一组微服务的方式来开发一个独立的应用系统的方法。其中每个小微服务都运行在自己的进程中，一般采用 HTTP 资源 API 这样轻量的机制相互通信。
这些微服务围绕业务功能进行构建，通过全自动化的部署方式来进行独立部署。这些微服务可以使用不同的语言来编写，也可以使用不同的数据存储技术，并且基于最低限度的集中管理。
同时 Martin Fowler 总结有如下 9 个特性：
组件以服务的形式提供
围绕业务功能进行组织
产品而不是项目
强化终端与弱化管道
“去中心化” 地治理技术署
“去中心化” 地管理数据
“基础设施” 自动化
“容错” 设计
“演进式” 设计
微服务架构可以看作是一种 SOA 的发展实现，其将 SOA 中原本可能聚合在同一个系统内的多个服务组件拆分到各自独立的系统进程。
微服务架构的优势在于：
更加彻底的组件化，系统内部各个组件之间解耦的比较干脆，单个系统的规模小很多；
可以组建每个服务独立的维护团队，利于各自团队独立的开发和维护；
每个微服务独立部署，只要服务间的接口稳定，各系统可以相互之间互不干扰的独立发展；
微服务架构使得每个服务本身可以独立的扩展，性能出现瓶颈，优化或增加这个服务的配置即可。
微服务架构的劣势也很明显，拆分的过细则要求自动化测试能力必须跟得上。一个全流程的测试跨 8~10 个系统是所有测试人员的恶魔。
问题的排查，数据的一致性保障，系统的监控等等，都会因为拆分的太细，复杂度大幅度增加。
如果代码或设计上有一个修改涉及到多个不同的微服务，那么在团队之间协调配合成本也会增加。对旧系统的微服务架构和组件化改造也是一个比较大的问题。
在组件化上所做的任何工作的成功度，取决于软件与组件的匹配程度。
但是合理的组件边界应该如何确定，这是非常困难的，演进式的处理方式是我们觉得比较合理和靠谱的。
因此，Martin Fowler 也建议，不要一上来就以微服务架构作为系统设计的起点。相反地，要用一个单块系统作为起点，并保持其模块化。
当这个单块系统出现了问题后，再将其分解为微服务。