-
让品牌有温度、有情感
专注品牌策划15年
微服务和soa（微服务和soa架构的区别）
发布时间：2023-04-13 22:08:00
稿源：
创意岭 阅读：
53
大家好！今天让创意岭的小编来大家介绍下关于微服务和soa的问题，以下是小编对此问题的归纳整理，让我们一起来看看吧。
开始之前先推荐一个非常厉害的Ai人工智能工具，一键生成原创文章、方案、文案、工作计划、工作报告、论文、代码、作文、做题和对话答疑等等
只需要输入关键词，就能返回你想要的内容，越精准，写出的就越详细，有微信小程序端、在线网页版、PC客户端
创意岭作为行业内优秀的企业，服务客户遍布全球各地，如需了解SEO相关业务请拨打电话175-8598-2043，或添加微信：1454722008
本文目录:
一、soa架构的优点有哪些？
利用SOA架构开发的优点：
第一、更易维护
业务服务提供者和业务服务使用者的松散耦合关系及对开放标准的采用确保了该特性的实现。建立在以 SOA基础上的信息系统，当需求发生变化的时候，不需要修改提供业务服务的接口，只需要调整业务服务流程或者修改操作即可，整个应用系统也更容易被维护。
第二、更高的可用性
该特点是在于服务提供者和服务使用者的松散耦合关系上得以发挥与体现。使用者无须了解提供者的具休实现细节。
第三、更好的伸缩性
依靠业务服务设计、开发和部署等所采用的架构模型实现伸缩性。使得服务提供者可以互相彼此独立地进行调整，以满足新的服务需求。
二、SOA和WebService
传统服务架构模型中，服务请求者和服务调用者之间是紧密耦合的关系。
SOA 模型最大程度解耦合服务请求者和服务提供者。
SOA 是概念层级的架构模型，需要使用其他技术来具体实现 SOA 模型，比如 Web Service（主流方式）、组件服务、REST 服务等。
Web Service 不是一个协议标准，它是一系列协议标准的集合。它主要包括：XML、XML Schema、NameSpace、SOAP、WDSL、WS-BPEL/WS-CDLUDDI、WSIL、WS-*
Web Service 协议与具体的平台、语言、技术无关，在各开发平台、语言、环境中均有相关支撑。
三、软件架构入门-分层架构、事件驱动、微服务架构和云原生架构
软件架构（software architecture）就是软件的基本结构。
合适的架构是软件成功的最重要因素之一。大型软件公司通常有专门的架构师职位（architect），只有资深程序员才可以担任。
O'Reilly 出版过一本免费的小册子《Software Architecture Patterns》（PDF）， 介绍了五种最常见的软件架构，是非常好的入门读物。
软件架构就是软件的基本结构。架构的本质是管理复杂性。 如果你觉得架构不重要，可能是你做的事情不够复杂，或者是你没有管理好复杂性。架构模式虽多，经过抽象沉淀之后，也就那么几种：
1. 分层架构（比较传统的单体架构）
2. 事件驱动架构 （一般适用于应用局部场景，用来实现异步解耦）
3. 微核架构（又称插件架构，开发难度较高，一般用来做工具软件开发，如Eclipse，不太适合分布式业务场景）
4. 微服务架构（当前比较流行的服务化架构，解决单体架构面临的问题，适合敏捷开发，快速迭代）
5. 云架构（现在的说法是云原生架构-Cloud Native，基于Docker、Kubernetes、Service Mesh 云原生架构）
在原文的基础上，我按照自己的想法，进行了小幅调整。
分层架构（ layered architecture ）是最常见的软件架构，也是事实上的标准架构。如果你不知道要用什么架构，那就用它。
这种架构将软件分成若干个水平层，每一层都有清晰的角色和分工，不需要知道其他层的细节。层与层之间通过接口通信。
虽然没有明确约定，软件一定要分成多少层，但是四层的结构最常见。
有的软件在逻辑层（business）和持久层（persistence）之间，加了一个服务层（service），提供不同业务逻辑需要的一些通用接口。
用户的请求将依次通过这四层的处理，不能跳过其中任何一层。
优点
缺点
事件（event）是状态发生变化时，软件发出的通知。
事件驱动架构（event-driven architecture）就是通过事件进行通信的软件架构。它分成四个部分。
事件驱动架构（event-driven architecture）核心组件：
对于简单的项目，事件队列、分发器和事件通道，可以合为一体，整个软件就分成事件代理和事件处理器两部分。
优点
缺点
事件驱动架构在通信产品中应用得也非常广泛，典型的如状态机处理。 事件驱动架构不适于做顶层架构，但适合做局部实现，几乎遍布在通信软件的各个角落。
微核架构（microkernel architecture）又称为"插件架构"（plug-in architecture），指的是软件的内核相对较小，主要功能和业务逻辑都通过插件实现。
内核（core）通常只包含系统运行的最小功能。插件则是互相独立的，插件之间的通信，应该减少到最低，避免出现互相依赖的问题。
优点
缺点
微核架构的设计和开发难度较高，这就注定它在企业产品中用得不多，虽然它的优点还不少。
微服务架构（microservices architecture）是服务导向架构（service-oriented architecture，缩写 SOA）的升级。
每一个服务就是一个独立的部署单元（separately deployed unit）。这些单元都是分布式的，互相解耦，通过远程通信协议（比如REST、SOAP）联系。
微服务架构分成三种实现模式。
现在开源的微服务框架比较多，如常用的有Spring Cloud、Dubbo、ServiceComb等等。
优点
缺点
云架构（cloud architecture，现在的说法是云原生-Cloud Native）主要解决扩展性和并发的问题，是最容易扩展的架构。
它的高扩展性，主要原因是可以基于云上计算资源弹性伸缩。然后，业务处理能力封装成一个个处理单元（prcessing unit）。访问量增加，就新建处理单元（Docker容器）；访问量减少，就关闭处理单元（Docker容器）。由于没有中央数据库，所以扩展性的最大瓶颈消失了。由于每个处理单元的数据都独立分库。
这个模式主要分成两部分：处理单元（processing unit）和虚拟中间件（virtualized middleware）。
虚拟中间件又包含四个组件：
随着Docker、Kubernetes等容器化技术的快速发展，上述关于云架构描述有点陈旧了。当前最新的云原生架构，以Docker+Kubernetes为核心，尤其是容器编排Kubernetes 已经成为事实上的行业标准。
云原生架构图的主要特征：
主要目标：
1. 让开发人员聚焦业务逻辑的实现，其他交给容器云平台来完成；
2. 支持业务系统的快速迭代，支撑业务的快速变化和发展；
3. 构建以共享服务体系为核心的业务中台；
下面是我针对某新零售企业设计的云原生架构图，以云和微服务架构为基础构建云原生应用，这里云可以是公有云、私有云、混合云等等。
以上是从不同的视角，对架构进行了分类。实际应用中，各种架构并不是孤立的，可以根据业务环境和业务诉求，对各种架构进行综合和嫁接。每种架构都有其优点和缺点。优点不必多说，缺点则几乎都是通过工具工程（比如自动化发布工具、自动化测试等等）能力的方法来规避，工具工程对软件架构非常重要。
四、如何快速搭建一个微服务架构
什么是微服务？
微服务(Microservices Architecture)是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。
微服务的概念源于2014年3月Martin Fowler所写的文章“Microservices” martinfowler.com/articles/mi…
单体架构(Monolithic Architecture )
企业级的应用一般都会面临各种各样的业务需求，而常见的方式是把大量功能堆积到同一个单体架构中去。比如：常见的ERP、CRM等系统都以单体架构的方式运行，同时由于提供了大量的业务功能，随着功能的升级，整个研发、发布、定位问题，扩展，升级这样一个“怪物”系统会变得越来越困难。
这种架构模式就是把应用整体打包部署，具体的样式依赖本身应用采用的语言，如果采用java语言，自然你会打包成war包，部署在Tomcat或者Jetty这样的应用服务器上，如果你使用spring boot还可以打包成jar包部署。其他还有Rails和Node.js应用以目录层次的形式打包
上图：单体架构
大部分企业通过SOA来解决上述问题，SOA的思路是把应用中相近的功能聚合到一起，以服务的形式提供出去。因此基于SOA架构的应用可以理解为一批服务的组合。SOA带来的问题是，引入了大量的服务、消息格式定义和规范。
多数情况下，SOA的服务直接相互独立，但是部署在同一个运行环境中（类似于一个Tomcat实例下，运行了很多web应用）。和单体架构类似，随着业务功能的增多SOA的服务会变得越来越复杂，本质上看没有因为使用SOA而变的更好。图1，是一个包含多种服务的在线零售网站，所有的服务部署在一个运行环境中，是一个典型的单体架构。
单体架构的应用一般有以下特点：
微服务架构（Microservices Architecture）
微服务架构的核心思想是，一个应用是由多个小的、相互独立的、微服务组成，这些服务运行在自己的进程中，开发和发布都没有依赖。不同服务通过一些轻量级交互机制来通信，例如 RPC、HTTP 等，服务可独立扩展伸缩，每个服务定义了明确的边界，不同的服务甚至可以采用不同的编程语言来实现，由独立的团队来维护。简单的来说，一个系统的不同模块转变成不同的服务！而且服务可以使用不同的技术加以实现！
上图：微服务架构
微服务设计
那我们在微服务中应该怎样设计呢。以下是微服务的设计指南：
微服务消息
在单体架构中，不同功能之间通信通过方法调用，或者跨语言通信。SOA降低了这种语言直接的耦合度，采用基于SOAP协议的web服务。这种web服务的功能和消息体定义都十分复杂，微服务需要更轻量的机制。
同步消息 REST
同步消息就是客户端需要保持等待，直到服务器返回应答。REST是微服务中默认的同步消息方式，它提供了基于HTTP协议和资源API风格的简单消息格式，多数微服务都采用这种方式（每个功能代表了一个资源和对应的操作）
异步消息 – AMQP, STOMP, MQTT
异步消息就是客户端不需要一直等待服务应答，有应到后会得到通知。某些微服务需要用到异步消息，一般采用AMQP, STOMP, MQTT 这三种通讯协议
消息格式 – JSON, XML, Thrift, ProtoBuf, Avro
消息格式是微服务中另外一个很重要的因素。SOA的web服务一般采用文本消息，基于复杂的消息格式（SOAP）和消息定义（xsd）。微服务采用简单的文本协议JSON和XML，基于HTTP的资源API风格。如果需要二进制，通过用到Thrift, ProtoBuf, Avro。
服务约定 – 定义接口 – Swagger, RAML, Thrift IDL
如果把功能实现为服务，并发布，需要定义一套约定。单体架构中，SOA采用WSDL，WSDL过于复杂并且和SOAP紧耦合，不适合微服务。
REST设计的微服务，通常采用Swagger和RAML定义约定。
对于不是基于REST设计的微服务，比如Thrift，通常采用IDL（Interface Definition Languages），比如Thrift IDL。
微服务集成 (服务间通信)
大部分微服务基于RPC、HTTP、JSON这样的标准协议，集成不同标准和格式变的不再重要。另外一个选择是采用轻量级的消息总线或者网关，有路由功能，没有复杂的业务逻辑。下面就介绍几种常见的架构方式。
点对点方式
点对点方式中，服务之间直接用。每个微服务都开放REST API，并且调用其它微服务的接口。
上图：通过点对点方式通信
很明显，在比较简单的微服务应用场景下，这种方式还可行，随着应用复杂度的提升，会变得越来越不可维护。这点有些类似SOA的ESB，尽量不采用点对点的集成方式。
API-网关方式
API网关方式的核心要点是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能个。通常，网关也是提供REST/HTTP的访问API。服务端通过API-GW注册和管理服务。
上图：通过API-网关暴露微服务
所有的业务接口通过API网关暴露，是所有客户端接口的唯一入口。微服务之间的通信也通过API网关。
采用网关方式有如下优势：
目前，API网关方式应该是微服务架构中应用最广泛的设计模式。
消息代理方式
微服务也可以集成在异步的场景下，通过队列和订阅主题，实现消息的发布和订阅。一个微服务可以是消息的发布者，把消息通过异步的方式发送到队列或者订阅主题下。作为消费者的微服务可以从队列或者主题共获取消息。通过消息中间件把服务之间的直接调用解耦。
上图：异步通信方式
通常异步的生产者/消费者模式，通过AMQP, STOMP, MQTT 等异步消息通讯协议规范。
数据的去中心化
单体架构中，不同功能的服务模块都把数据存储在某个中心数据库中。
每个微服务有自己私有的数据库，其它微服务不能直接访问。单体架构，用一个数据库存储所有数据
微服务方式，多个服务之间的设计相互独立，数据也应该相互独立（比如，某个微服务的数据库结构定义方式改变，可能会中断其它服务）。因此，每个微服务都应该有自己的数据库。
每个微服务有自己私有的数据库，其它微服务不能直接访问。每个微服务有自己私有的数据库，其它微服务不能直接访问。
数据去中心话的核心要点：
数据的去中心化，进一步降低了微服务之间的耦合度，不同服务可以采用不同的数据库技术（SQL、NoSQL等）。在复杂的业务场景下，如果包含多个微服务，通常在客户端或者中间层（网关）处理。
微服务架构的优点：
微服务架构的缺点：
微服务的一些想法在实践上是好的，但当整体实现时也会呈现出其复杂性。
关于微服务架构的取舍
以上就是关于微服务和soa相关问题的回答。希望能帮到你，如有更多相关问题，您也可以联系我们的客服进行咨询，客服也会为您讲解更多精彩的知识和内容。
推荐阅读：
赣公网安备 50019002502384号
