微服务和soa的区别

① 无服务架构和微服务器架构的区别

微服务架构中有两个阵营，一是坚持微服务是无状态的HTTP API服务，另一阵营认为微服务本身就要内求把整个系统当做一个容完整的分布式应用来对待，而不是原来那种把各种组件堆积在一起，“拼接”系统的做法。
无服务架构就是原来那种把各种组件堆积在一起，拼接系统的做法。

② 什么是微服务架构

指开发一个单个 小型的但有业务功能的服务。
微服务架构系统灵活性，健壮性，扩专展性好，特别适合属需求变化迅速的场景。但系统复杂度高，部署，管理难度大。微服务除了开发期框架之外，还有需要一系列的运行期中间件支撑，如API网关，服务注册中心，统一配置中心等。 目前国内东软做的比较成熟，可以查查官网。

③ SOA和微服务架构的区别

如果一句抄话来谈袭SOA和微服务的区别，即微服务不再强调传统SOA架构里面比较重的ESB企业服务总线，同时SOA的思想进入到单个业务系统内部实现真正的组件化。
微服务架构强调的第一个重点就是业务系统需要彻底的组件化和服务化，原有的单个业务系统会拆分为多个可以独立开发，设计，运行和运维的小应用。
这些小应用之间通过服务完成交互和集成。
每个小应用从前端webui，到控制层，逻辑层，数据库访问，数据库都完全是独立的一套。
在这里不用组件而用小应用这个词更加合适，每个小应用除了完成自身本身的业务功能外，重点就是还需要消费外部其它应用暴露的服务，同时自身也将自身的能力朝外部发布为服务。

④ 别炒概念了，咱认真思考下soa与微服务到底有什么区别

微服务是来一个新概念，但这绝不源是一个全新架构，更不是一个包治百病的架构。由于有服务二字，很容易让人联想到面向服务架构（SOA），其实微服务架构属于应用技术架构，和以B/S
为代表的三层架构相对应，强调将巨石型应用拆分为由微服务组成的应用，在数据上也视情况从集中的存储拆解为更小的存储单元。而SOA属于企业架构的范畴，从企业架构出发把业务分解为不同领域的服务，不同物理系统提供不同服务，注重系统之间通过服务互联互通的规范，对服务如何实现并不关注。因此，面向服务架构的服务应该是一个业务意义的服务，而微服务是系统中的技术服务，更关注服务的实现，虽然提供了业务意义的服务，但是不能混为一谈。微服务使用也不是无限度的，事实上由于数据一致性等问题的限制，不能无限度拆分微服务，可以把微服务分为系统对外提供的远程服务、系统内部的远程服务和系统内部的本地服务，显式声明、明确职责。事实上，在企业架构上使用SOA支撑业务，而在应用技术架构上使用微服务架构，是一个合适的选择。

⑤ SOA和微服务架构的区别

如果一句话来谈SOA和微服务的区别，即微服务不再强调传统SOA架构里面比较重的ESB企业服务总线，同时SOA的思想进入到单个业务系统内部实现真正的组件化。

微服务架构强调的第一个重点就是业务系统需要彻底的组件化和服务化，原有的单个业务系统会拆分为多个可以独立开发，设计，运行和运维的小应用。这些小应用之间通过服务完成交互和集成。每个小应用从前端web ui，到控制层，逻辑层，数据库访问，数据库都完全是独立的一套。在这里我们不用组件而用小应用这个词更加合适，每个小应用除了完成自身本身的业务功能外，重点就是还需要消费外部其它应用暴露的服务，同时自身也将自身的能力朝外部发布为服务。

⑥ soa架构的优点有哪些

面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务内）通过这些服务之间容定义良好的接口和契约联系起来。构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。 SOA是一种粗粒度、松耦合服务架构，基于soa服务思想进行功能的抽取(重复代码问题解决),以服务为中心各个系统之间依靠ESB进行调用。 随着业务复杂性与规模的不断增长，以及业务的多变性因素，使得敏捷软件开发变得尤其重要，在尽可能满足客户需求的同时，维持良好的软件质量与系统可用性。 将整体应用拆分开来，从而确保以业务为中心的服务设计理念更加符合敏捷交付与DevOps文化的实际要求。而这，正是微服务架构的真正来源。 一句话总结SOA和微服务的区别，即微服务不再强调传统SOA架构里面比较重的ESB企业服务总线，同时SOA的思想进入到单个业务系统内部实现真正的组件化。如今微服务越来越重要，

⑦ SOA和微服务架构的区别

微架构也是SOA的一种，只是其component更小更多而已。
Spring等框架中，版常有依赖注入权，Ioc等技术，通过配置文件，决定API调用，一个不是很恰当的比喻，把这些API分开，包装成Service，放在网络上，每个有自己的process，通过与语言无关的协议通讯，类似Rest之类的，这就成了微架构。
据说，好处是容易deploy，更灵活，解耦；坏处是网络限制性能，不易确定系统state等等。
个人感觉，微架构只是把复杂性推到了其他的地方，过分强调解耦，可能造成不必要的细化，导致系统更为复杂，难以维护，不是很看好这种思路。

⑧ 什么是微服务

什么是微服务

微服务架构的系统是一个分布式的系统，按业务进行划分为独立的服务单元，解决单体系统的不足，同时也满足越来越复杂的业务需求。

一.单体架构

1.1什么是单体架构

在软件设计的时候经常提到和使用经典的3层模型，即表现层，业务逻辑层，数据访问层。虽然在软件设计中划分了3层模型，但是对业务场景没有划分，一个典型的单体架构就是将所有的业务场景的表现层，业务逻辑层，数据访问层放在一个工程中最终经过编译，打包，部署在一台服务器上。此时服务架构如图：

1.2单体架构存在的不足

在小型应用的初期，访问量小的时候这种架构的性价比还是比较高的，开发速度快，成本低，但是随着业务的发展，逻辑越来越复杂，代码量越来越大，代码得可读性和可维护性越来越低。用户的增加，访问量越来越多单体架构的应用并发能力十分有限。可能会有人想到将单体应用进行集群部署，并增加负载均衡服务器，再来个缓存服务器和文件服务器，数据库再搞个读写分离。这种架构如图：

这种架构虽然有一定的并发能力，及应对一定复杂业务，但是依然没有改变系统为单体架构的事实。大量的业务必然会有大量的代码，代码得可读性和可维护性依然很差。如果面对海量的用户，它的并发能力依然不够。基于以上单体架构系统的不足，提出了微服务架构。

二.微服务

2.1什么是微服务

说了这么多现在来看看到底什么是微服务。微服务最初是由Martin Fowler提出来的他的理解如下：

微服务架构就是将单一程序开发成一个微服务，每个微服务运行在自己的进程中，并使用轻量级的机制通信，通常是HTTP RESTFUL API。这些服务围绕业务能力来划分，并通过自动化部署机制来独立部署。这些服务可以使用不同的编程语言，不同数据库，以保证最低限度的集中式管理。

1

总结起来微服务就是将一个单体架构的应用按业务划分为一个个的独立运行的程序即服务，它们之间通过HTTP协议进行通信（也可以采用消息队列来通信，如RoocketMQ，Kafaka等），可以采用不同的编程语言，使用不同的存储技术，自动化部署（如Jenkins）减少人为控制，降低出错概率。服务数量越多，管理起来越复杂，因此采用集中化管理。例如Eureka，Zookeeper等都是比较常见的服务集中化管理框架。

2.2微服务的优势

1）将复杂的业务拆分成多个小的业务，每个业务拆分成一个服务，将复杂的问题简单化。利于分工，降低新人的学习成本。

2）微服务系统是分布式系统，业务与业务之间完全解耦，随着业务的增加可以根据业务再拆分，具有极强的横向扩展能力。面对搞并发的场景可以将服务集群化部署，加强系统负载能力。

3）服务间采用HTTP协议通信，服务与服务之间完全独立。每个服务可以根据业务场景选取合适的编程语言和数据库。

4）微服务每个服务都是独立部署的，每个服务的修改和部署对其他服务没有影响。

2.3微服务和SOA的关系

SOA即面向服务的架构，SOA是根据企业服务总线（ESB）模式来整合集成大量单一庞大的系统，微服务可以说是SOA的一种实现，将复杂的业务组件化。但它比ESB实现的SOA更加的轻便敏捷和简单。

⑨ 什么是SOA架构

SOA架构即面向服务架构。

面向服务的体系结构，是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。

接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。

(9)微服务和soa的区别扩展阅读:

SOA具有以下五个特征：

1、可重用

一个服务创建后能用于多个应用和业务流程。

2、松耦合

服务请求者到服务提供者的绑定与服务之间应该是松耦合的。因此，服务请求者不需要知道服务提供者实现的技术细节，例如程序语言、底层平台等等。

3、明确定义的接口

服务交互必须是明确定义的。Web服务描述语言（Web Services Description Language，WSDL）是用于描述服务请求者所要求的绑定到服务提供者的细节。WSDL不包括服务实现的任何技术细节。服务请求者不知道也不关心服务究竟是由哪种程序设计语言编写的。

4、无状态的服务设计

服务应该是独立的、自包含的请求，在实现时它不需要获取从一个请求到另一个请求的信息或状态。服务不应该依赖于其他服务的上下文和状态。当产生依赖时，它们可以定义成通用业务流程、函数和 数据模型。

5、基于开放标准

当前SOA的实现形式是Web服务，基于的是公开的W3C及其他公认标准．采用第一代Web服务定义的SOAP、WSDL和UDDI以及第二代Web服务定义的WS-*来实现SOA。