其实这两种架构在原则上确实相当近似,但仍有不同之处。在围绕服务的概念创建架构这一方面,微服务提供了一种更清
晰、定义更良好的方式。这两者之间最关键的区别在与微服务更专注于以自治的方式产生价值。
对于微服务,我们可以这么理解:经过分离的组件可以各自拥有独立的生命周期,独立部署(Docker),并且按需进行扩
展。不仅如此,这种方式也打破了组件之间的技术依赖,这就允许每个服务各自选择最合适的技术进行实现,即不同的服务甚
至可以采用不同的编程语言来实现,由独立的团队负责。不同的服务通过一下轻量级交互机制来通信,例如RPC、HTTP等们
每个服务定义了明确的边界。(这是一种模块到服务的转变)。微服务的设计思想就是通过将较大的问题分解为几个较小的问
题,让每个问题更易于进行分析,也更利于开发者选择最合适的解决方案。但由此也带来了一些问题,这种分解方式对大问题
进行分解也增加了整个解决方案的复杂度,尤其是在那些使用不同技术或方式创建各种服务的系统中体现得更为明显。这种架
构将系统的整合点推移到了服务之间的接口,因此这些服务的接口需要良好的定义,在系统中也要对服务级别达成一致,并且
还需要定义其他的非功能需求。(明确服务边界)。
微服务相对于SOA而言,微服务只是一种为经过良好架构设计的SOA解决方案实现的面向服务的交互方案。SOA是一种能
够改变整个企业的IT结构的战略创新,他将企业系统划分为不同的服务,为企业赋予了更大的灵活性......微服务必须能够独立的
进行部署,而SOA服务往往是按照一体性的部署方式实现的,SOA的实现专注于ESB、SOAP、和WSDL。因此,虽然SOA与微
服务技术有一定程度的相似性,但他们的本质完全不同的,
在微服务架构中,每个操作(或方法)都是独立开发的。而且每个微服务都可以按照自身的需要,独立的整合相应的变更,
每个微服务都实现了独立部署、停用或是重启等操作。在大多数场景中,各个独立的微服务将在一个统一的平台中执行。
微服务的原则与敏捷软件开发思想是高度一致的,而它与SOA原则的演化的目标也是相同的,则减少传统的企业服务总线
开发的高度复杂性。
不管是SOA还是微服务,我认为都是一种在开发流程上的一种设计理念的体现,他们都是围绕这服务这一关键字进行讨论,
SOA对服务定义的比较粗粒度无状态服务,而微服务定义的比较细粒度高内聚的服务,而且微服务的服务可以独立部署。
SOA的提出是在企业计算领域,就是要将紧耦合的系统,划分为面向业务的,粗粒度,松耦合,无状态的服务。服务发布出来供其他服务调用,一组互相依赖的服务就构成了SOA架构下的系统。
基于这些基础的服务,可以将业务过程用类似BPEL流程的方式编排起来,而BPEL反映的是业务处理的过程,这些过程对于业务人员更为直观,调整也比hardcode的代码更容易。
当然企业还需要对服务治理,比如服务注册库,监控管理等。
我们知道企业计算领域,如果不是交易系统的话,并发量都不是很大的,所以大多数情况下,一台服务器就容纳将许许多多的服务,这些服务采用统一的基础设施,可能都运行在一个应用服务器的进程中。虽然说是面向服务了,但还是单一的系统。
微服务
而微服务架构大体是从互联网企业兴起的,由于大规模用户,对分布式系统的要求很高,如果像企业计算那样的系统,伸缩就需要多个容纳续续多多的服务的系统实例,前面通过负载均衡使得多个系统成为一个集群。
但这是很不方便的,互联网企业迭代的周期很短,一周可能发布一个版本,甚至可能每天一个版本,而不同的子系统的发布周期是不一样的。
而且,不同的子系统也不像原来企业计算那样采用集中式的存储,使用昂贵的Oracle存储整个系统的数据,二是使用MongoDB,HBase,Cassandra等NOSQL数据库和Redis,memcache等分布式缓存。
那么就倾向采用以子系统为分割,不同的子系统采用自己的架构,那么各个服务运行自己的Web容器中,当需要增加计算能力的时候,只需要增加这个子系统或服务的实例就好了,当升级的时候,可以不影响别的子系统。这种组织方式大体上就被称作微服务架构。
微服务与SOA相比,更强调分布式系统的特性,比如横向伸缩性,服务发现,负载均衡,故障转移,高可用。互联网开发对服务治理提出了更多的要求,比如多版本,比如灰度升级,比如服务降级,比如分布式跟踪,这些都是在SOA实践中重视不够的。
Docker容器技术的出现,为微服务提供了更便利的条件,比如更小的部署单元,每个服务可以通过类似Node.js或Spring Boot的技术跑在自己的进程中。可能在几十台计算机中运行成千上万个Docker容器,每个容器都运行着服务的一个实例。随时可以增加某个服务的实例数,或者某个实例崩溃后,在其他的计算机上再创建该服务的新的实例。