SOA,ESB,WebService,微服务的关系
SOA（Service Oriented Architecture）面向服务的架构，探索大概始于 2000 年，概念产生可能更早一些，它是一种架构风格，设计方法，其中包含多个服务， 服务之间通过相互依赖最终提供一系列的功能。一个服务 通常以独立的形式存在与操作系统进程中,各个服务之间 通过网络调用。也是指为了解决在inernet环境下业务集成的需要，通过连接能完成特定任务的独立功能实现的一种软件系统架构
ESB（企业服务总线），指的是传统中间件技术与XML、Web服务等技术结合的产物。是SOA技术架构落地的一个基本部件，现在我们说的SOA集成平台基本都需要有ESB组件，ESB最基本功能即是实现点对点集成到总线式集成的转换，在这个过程中实现了消息协议的转换和适配，数据传输，数据转换和映射，路由等基本功能。ESB提供了网络中最基本的连接中枢，是构筑企业神经系统的必要元素。简单来说ESB就是一根管道，用来连接各个服务节点。为了集成不同系统，不同协议的服务，ESB做了消息的转化解释和路由工作，让不同的服务互联互通。
企业服务总线(EnterpriseServiceBus，ESB)是构建基于面向服务体系结构(SOA)解决方案时所使用基础架构的关键部分，是由中间件技术实现并支持SOA的一组基础架构功能。
WebService是一个平台独立的，低耦合的，自包含的、基于可编程的web的应用程序，可使用开放的XML（标准通用标记语言下的一个子集）标准来描述、发布、发现、协调和配置这些应用程序，用于开发分布式的交互操作的应用程序。它一种分布式部署系统的一种模式，意思就是说分布式的部署系统可以采用WebService技术来写相关的接口。是一种技术方面的标准，真正的跨语言，跨平台，提供了标准的服务定义，服务注册，服务接入和访问的方式。
WebService是SOA的一种实现技术。WebService基于两种协议：soap和rest协议，XML,SOAP和WSDL就是构成WebService平台的三大技术。现阶段，我们能看到的大部分SOA系统好像都是 用WebService实现的。但一定要明确，那些把自己能提供的服务包装一下，对外提供一个ws接口，就声称自己是SOA，肯定是错误的，因为他的系统并不一定符合SOA架构。
有网友这么形容SOA,ESB,WebService的关系
SOA是方法论，就像建筑学一样，指导性质的；
ESB是建筑图纸，理顺整个建筑的架构；
Web S是具体的建筑材料，就好像预制板；
大家知道当初 ERP、CRM、OA 之类的信息系统都是一套套部署起来的，不同系统往往由不同的供应商分别开发的，技术差别也很大，各个系统孤零零的，企业于是有了应用集成和数据集成的需求，SOA 就出来了，各个系统对外提供粗粒度的服务供外部系统访问，所有的服务都集中在一个 ESB 上，曾经 SOA 和 SOA 治理是信息化领域的热门话题，然而这种集成方式开发代价大、通信效率低，且有单点故障的风险， 实际上在企业中并没有得到大规模应用。
微服务，Martin Fowler在2014年正式提出了“微服务”的概念，它出现在互联网相当成熟的时代，将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持。微服务架构是一种将单个应用程序作为一套小型服务开发的方法，每种应用程序都在自己的进程中运行，并与轻量级机制（通常是HTTP资源API）进行通信。这些服务是围绕业务功能构建的，可以通过全自动部署机制独立部署。这些服务的集中管理最少，可以用不同的编程语言编写，并使用不同的数据存储技术。
来看下网上找到的对微服务架构的一些定义和阐述：
微服务可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构（在现有系统中分布一个API）区分开来。在服务公开中，许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程。
微服务不需要像普通服务那样成为一种独立的功能或者独立的资源。定义中称，微服务是需要与业务能力相匹配，这种说法完全正确。不幸的是，仍然意味着，如果能力模型粒度的设计是错误的，那么，我们就必须付出很多代价。如果你阅读了Fowler的整篇文章，你会发现，其中的指导建议是非常实用的。在决定将所有组件组合到一起时，开发人员需要非常确信这些组件都会有所改变，并且规模也会发生变化。服务粒度越粗，就越难以符合规定原则。服务粒度越细，就越能够灵活地降低变化和负载所带来的影响。然而，利弊之间的权衡过程是非常复杂的，我们要在配置和资金模型的基础上考虑到基础设施的成本问题。
参考文献：
