SOA与微服务有太多的相似之处，搜索到的资料表明，很多人赞成微服务非常类似于SOA。
SOA
于是找到了维基上一些关于SOA的定义
企业系统的架构师认为SOA能够帮助业务迅速和高效地响应变化的市场条件 . 服务导向的架构在宏观（服务）上，而不是在微观上（对象）因此提高了重复使用性。同时，服务导向的架构可以简化与传统系统的互连和使用。
在某种意义上说，服务导向的架构可以被认为是一种演化，而不是革命。它捕捉到了之前体系架构的许多最佳实践或实际应用。比如在通信系统中，近年来进展有限的解决方案多采用完全静态的绑定来与网络中的其他设备沟通，但若正式采用SOA方式，解决方案就更能妥善定位，进而突显定义明确且可高度跨平台操作接口的重要性。
有些人质疑服务导向的架构是不是1970年代模块化编程，1980年代的面向事件设计，1990年代的基于接口/构件设计的一种复兴？(1990s)。 服务导向的架构提升了将用户从服务实现分开的目标。服务可以运行在不同的服务器上，并通过网络被访问。 这也大大增加了服务的重用。
而仅仅是这些东西我们就可以发现他和SOA有诸多的相似之处。
对于一些SOA的原则是
- 可重复使用, 粒度, 模组性, 可组合型, 构件化以及具交互操作性
- 符合开放标准(通用的或行业的)
- 服务的识别和分类，提供和发布，监控和跟踪。
SOA vs Microservices
我们能找到最多的被引用的关于Microservies文章，想必就是Martin Fowler的Microservices 。文中对两者也做了一个对比:
当我们谈到微服务有一个问题达到了一致，这是否意味着微服务仅仅是我们在十年前看到的SOA。有一个明显的迹象表明了上面那一点，多数人赞成微服务风格有着一些SOA的主张。
然而，问题是SOA也意味着太多不同的东西，而且在大多数时候我们遇到了一些所谓的"SOA"与我们这里描述的风格明显不同，通常是因为一个侧重于ESBs（Enterprise Service Bus）被集成在宏应用(monolithic applications)。
特别是，我们已经看到了面向服务的这么多拙劣的实现——从在ESB中远离隐藏复杂性的趋势，它有时是很难看到过去的这些问题，花费多年的举措，耗资数百万，没有提供价值，以集中治理模式，积极抑制变革。
In particular we have seen so many botched implementations of service orientation - from the tendency to hide complexity away in ESB's [7], to failed multi-year initiatives that cost millions and deliver no value, to centralised governance models that actively inhibit change, that it is sometimes difficult to see past these problems.
当然，在微服务社区中使用的技术已经从开发者在大型组织中整合服务的经验中获得更多的经验。Tolerant Reader模式是这样的例子。努力利用网络作出了贡献，用简单的协议是从这些经验中得出另一种方法。——反应距离已经达到一个复杂性度，坦率地中央标准，是惊人的。（任何时候你需要一个本体来管理你的本体，你知道你有麻烦。）
SOA的这种常见的表现使得一些微服务的倡导者，完全拒绝SOA的标签，虽然别人认为微服务是一种形式的SOA，也许是面向服务做好。无论哪种方式，认为SOA是指这样的不同的事情的事实意味着它是有价值的有一个术语，它更脆定义这个架构风格。
或许您还需要下面的文章: