微服务是近几年非常火热的架构设计理念,大部分人认为是 Martin Fowler提出了微服务概念,但事实上微服务概念的历史要早得多,也不是 Martin Fowler创造出来的, Martin Fowler只是将微服务进行了系统的阐述。不过不能否认 Martin Fowler在推动微服务火热起来的作用,微服务能火, Martin Fowler功不可没。
参考维基百科英文版,我们简单梳理一下微服务的历史:
- 2005年:Dr. PeterRodgers在Web ServicesEdge大会上提出了“Micro-Web-Services”的概念。
- 2011年:一个软件架构工作组使用了“microservice”一词来描述一种架构模式。
- 2012年:同样是这个架构工作组,正式确定用“microservice”来代表这种架构。
- 2012年:ThoughtWorks的James Lewis针对微服务概念在QCon San Francisco 2012发表了演讲。
- 2014年:James Lewis和 Martin Fowler合写了关于微服务的一篇学术性的文章,详细阐述了微服务。
由于微服务的理念中也包含了“服务”的概念,而SOA中也有“服务”的概念,我们自然而言地会提出疑问:微服务与SOA是什么关系,有什么区别,为何有了SOA还要提微服务?这几个问题是理解微服务的关键,否则如果只是跟风拿来就用,既不会用,也用不好,用了不但没有效果,反而还可能有副作用。
SOA为什么被提出?
对于了解过SOA的人来说,第一次看到微服务这个概念肯定会有所疑惑:为何有了SOA还要提微服务呢?等到简单看完微服务的介绍后,很多人可能就有一个疑惑:这不就是SOA吗?
我们看一下,什么是SOA?
OASIS给予出的SOA定义:SOA是一个范式,用于组织和利用可能处于不同所有权范围控制下的分布式系统。维基百科给出的SOA定义:“面向服务的体系结构(Service-oriented architecture)是构造分布式系统的应用程序的方法。它将应用程序功能作为服务发送给最终用户或者其他服务。它采用开放标准、与软件资源进行交互并采用表示的标准方式。”。百度百科:面向服务的体系结构(SOA)是一个组件模型,它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。看了这些规范定义,小编只想说一句,说人话!说人话,说人话!幸好,有人还搞了一个SOA标准模型。
以笔者了解的电信行业为例,大量的系统由第三方厂商提供或者是外包厂商维护,形成若干的数据孤岛和服务离散。A系统要访问B系统,需要B提供接口;C需要访问B系统,也需要B提供接口。由于异地系统的复杂性,大量竖井式应用无法响应日益变化和复杂的业务流程。在这种背景下,IBM 等公司提出了 SOA理念,将应用系统抽象成一个个粗粒度的服务,构建松耦合服务架构,可以通过业务流程对服务进行灵活组合,提升企业 IT 资产复用,提高了系统的适应性、灵活性和扩展性,解决“信息孤岛”问题。
SOA 提出了一系列构建分布式系统的原则,这些思考直到今天也依然适用:服务具备明确定义的标准化的接口服务应该是松耦合的服务应该是无状态的服务是可以组合
服务的发现、注册机制
微服务与SOA的关系
关于SOA和微服务的关系和区别,大概分为几个典型的观点。
- 微服务是SOA的实现方式
如下图所示,这种观点认为SOA是一种架构理念,而微服务是SOA理念的一种具体实现方法。例如,“微服务就是使用HTTP RESTful协议来实现ESB的SOA”,“使用SOA来构建单个系统就是微服务”“微服务就是更细粒度的SOA”。
- 微服务是去掉ESB后的SOA
如下图所示,这种观点认为传统SOA架构最广为人诟病的就是庞大、复杂、低效的ESB,因此将ESB去掉,改为轻量级的HTTP实现,就是微服务。
- 微服务是一种和SOA相似,但本质上不同的架构理念
如下图所示,这种观点认为微服务和SOA只是有点类似,但本质上是不同的架构设计理念。相似点在于下图中交叉的地方,就是两者都关注“服务”,都是通过服务的拆分来解决可扩展性问题。本质上不同的地方在于几个核心理念的差异:是否有ESB、服务的粒度、架构设计的目标等。
以上观点看似都有一定的道理,但都有点差别,到底哪个才是准确的呢?单纯从概念上是难以分辨的,我们对比一下SOA和微服务的一些具体做法,再来看看到底哪一种观点更加符合实际情况。