分析解剖微服务系列(二)-SOA和微服务异同
微服务架构模式成熟之前,软件领域讨论的比较多的是SOA的架构模式。SOA早在1996年就由Gartner提出,作为面向服务的架构模式,SOA的理念是对于复杂的企业IT系统,按照不同的、可重用的粒度划分,将功能相关的一组功能提供者组织在一起为消费者提供服务。SOA在实际的发展过程中并不顺利,随着ESB(Enterprise Service Bus)、Web Service、SOAP等技术出现,SOA才渐渐落地。但其主要解决的是企业内部不同IT资源之间的信息共享、互通等问题,相当长时间内的发展依赖于企业级软件总线的进展,而这类软件总线总体上厚重、大而全,但相互之间由不同的软件厂家提供,自成体系无法互通,从而又制约了其发展。从SOA的面向服务而言,其与微服务架构模式中的服务化这类思想是基本一致的。落地实践的过程中,微服务与SOA又有着明显的区别。
最准确的说法:微服务是SOA的一种实现
最实际的说法:微服务是去ESB的SOA
实际上是两种思想的分歧:分布还是集中
当然这里说的不是服务的分布和集中。服务肯定是分布的,这是大前提,是SOA的本质理念之一。分歧在于对服务的治理,是分布还是集中。
SOA
SOA的提出是在企业计算领域,就是要将紧耦合的系统,划分为面向业务的,粗粒度,松耦合,无状态的服务。服务发布出来供其他服务调用,一组互相依赖的服务就构成了SOA架构下的系统。
基于这些基础的服务,可以将业务过程用类似BPEL流程的方式编排起来,而BPEL反映的是业务处理的过程,这些过程对于业务人员更为直观,调整也比hardcode的代码更容易。
当然企业还需要对服务治理,比如服务注册库,监控管理等。
我们知道企业计算领域,如果不是交易系统的话,并发量都不是很大的,所以大多数情况下,一台服务器就容纳将许许多多的服务,这些服务采用统一的基础设施,可能都运行在一个应用服务器的进程中。虽然说是面向服务了,但还是单一的系统。
微服务
而微服务架构大体是从互联网企业兴起的,由于大规模用户,对分布式系统的要求很高,如果像企业计算那样的系统,伸缩就需要多个容纳续续多多的服务的系统实例,前面通过负载均衡使得多个系统成为一个集群。
但这是很不方便的,互联网企业迭代的周期很短,一周可能发布一个版本,甚至可能每天一个版本,而不同的子系统的发布周期是不一样的。
而且,不同的子系统也不像原来企业计算那样采用集中式的存储,使用昂贵的Oracle存储整个系统的数据,二是使用MongoDB,HBase,Cassandra等NOSQL数据库和Redis,memcache等分布式缓存。
那么就倾向采用以子系统为分割,不同的子系统采用自己的架构,那么各个服务运行自己的Web容器中,当需要增加计算能力的时候,只需要增加这个子系统或服务的实例就好了,当升级的时候,可以不影响别的子系统。这种组织方式大体上就被称作微服务架构。
微服务与SOA相比,更强调分布式系统的特性,比如横向伸缩性,服务发现,负载均衡,故障转移,高可用。互联网开发对服务治理提出了更多的要求,比如多版本,比如灰度升级,比如服务降级,比如分布式跟踪,这些都是在SOA实践中重视不够的。
Docker容器技术的出现,为微服务提供了更便利的条件,比如更小的部署单元,每个服务可以通过类似Node.js或Spring Boot的技术跑在自己的进程中。可能在几十台计算机中运行成千上万个Docker容器,每个容器都运行着服务的一个实例。随时可以增加某个服务的实例数,或者某个实例崩溃后,在其他的计算机上再创建该服务的新的实例。
如果,您认为阅读这篇博客让您有些收获,不妨点击一下右下角的【推荐】按钮。
如果,您希望更容易地发现我的新博客,不妨点击一下【关注我】
出处:http://www.cnblogs.com/xuwendong/
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。