老树发新芽:微服务

本文涉及的产品
注册配置 MSE Nacos/ZooKeeper,118元/月
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
云原生网关 MSE Higress,422元/月
简介: 如果我告诉你有这样一种软件架构,一个应用程序的组件通过基于网络的通讯协议为其它组件提供服务,我估计你可能会说它是 …是的,它和你编程的年限有关。如果你从上世纪九十年代就开始了你的编程生涯,那么你肯定会说它是 面向服务的架构( Service-Oriented Architecture)(SOA)。但是,如果你是个年青人,并且在云上获得初步的经验,那么,你将会说:“哦,你说的是 微服务(Microservices)。”你们都没错。如果想真正地了解它们的差别,你需要深入地研究这两种架构。

如果我告诉你有这样一种软件架构,一个应用程序的组件通过基于网络的通讯协议为其它组件提供服务,我估计你可能会说它是 …

是的,它和你编程的年限有关。如果你从上世纪九十年代就开始了你的编程生涯,那么你肯定会说它是 面向服务的架构( Service-Oriented Architecture)(SOA)。但是,如果你是个年青人,并且在云上获得初步的经验,那么,你将会说:“哦,你说的是 微服务(Microservices)。”

你们都没错。如果想真正地了解它们的差别,你需要深入地研究这两种架构。

在 SOA 中,服务是一个功能,它是定义好的、自包含的、并且是不依赖上下文和其它服务的状态的功能。总共有两种服务。一种是消费者服务,它从另外类型的服务 —— 提供者服务 —— 中请求一个服务。一个 SOA 服务可以同时扮演这两种角色。

SOA 服务可以与其它服务交换数据。两个或多个服务也可以彼此之间相互协调。这些服务执行基本的任务,比如创建一个用户帐户、提供登录功能、或验证支付。

与其说 SOA 是模块化一个应用程序,还不如说它是把分布式的、独立维护和部署的组件,组合成一个应用程序。然后在服务器上运行这些组件。

早期版本的 SOA 使用面向对象的协议进行组件间通讯。例如,微软的 分布式组件对象模型( Distributed Component Object Model)(DCOM) 和使用 通用对象请求代理架构(Common Object Request Broker Architecture)(CORBA) 规范的 对象请求代理( Object Request Broker)(ORB)。

用于消息服务的最新的版本,有 Java 消息服务( Java Message Service)(JMS)或者 高级消息队列协议(Advanced Message Queuing Protocol)(AMQP)。这些服务通过 企业服务总线(Enterprise Service Bus)(ESB) 进行连接。基于这些总线,QQ交易来传递和接收可扩展标记语言(XML)格式的数据。

微服务 是一个架构样式,其中的应用程序以松散耦合的服务或模块组成。它适用于开发大型的、复杂的应用程序的 持续集成(Continuous Integration)/ 持续部署(Continuous Deployment)(CI/CD)模型。一个应用程序就是一堆模块的汇总。

每个微服务提供一个应用程序编程接口(API)端点。它们通过轻量级协议连接,比如, 表述性状态转移( REpresentational State Transfer)(REST),或 gRPC。数据倾向于使用 JavaScript 对象标记( JavaScript Object Notation)(JSON)或 Protobuf 来表示。

这两种架构都可以用于去替代以前老的整体式架构,整体式架构的应用程序被构建为单个的、自治的单元。例如,在一个客户机 —— 服务器模式中,一个典型的 Linux、Apache、MySQL、PHP/Python/Perl (LAMP) 服务器端应用程序将去处理 HTTP 请求、运行子程序、以及从底层的 MySQL 数据库中检索/更新数据。所有这些应用程序“绑”在一起提供服务。当你改变了任何一个东西,你都必须去构建和部署一个新版本。

使用 SOA,你可以只改变需要的几个组件,而不是整个应用程序。使用微服务,你可以做到一次只改变一个服务。使用微服务,你才能真正做到一个解耦架构。

微服务也比 SOA 更轻量级。不过 SOA 服务是部署到服务器和虚拟机上,而微服务是部署在容器中。协议也更轻量级。这使得微服务比 SOA 更灵活。因此,它更适合于要求敏捷性的电商网站。

说了这么多,到底意味着什么呢?微服务就是 SOA 在容器和云计算上的变种。

老式的 SOA 并没有离我们远去,而因为我们不断地将应用程序搬迁到容器中,所以微服务架构将越来越流行。

目录
相关文章
|
消息中间件 安全 Kafka
服务调用:微服务架构的默契交流
在微服务架构中,服务调用是构建分布式系统的核心组成部分。本博客将深入探讨服务调用的概念、重要性以及如何在微服务环境中有效地进行服务之间的交流。
|
3月前
|
Kubernetes Nacos 微服务
微服务注册与发现的原理与实现
微服务注册与发现的原理与实现
|
5月前
|
前端开发 JavaScript 微服务
|
6月前
|
运维 Java 应用服务中间件
[后端] 微服务的前世今生
[后端] 微服务的前世今生
|
6月前
|
消息中间件 Java API
面试官:微服务通讯方式有哪些?
面试官:微服务通讯方式有哪些?
98 0
|
Dubbo Java 应用服务中间件
阿里面试这些微服务还不会?那还是别去了,基本等通知!
微服务作为一项在云中部署应用和服务的新技术已成为当下最新的热门话题。但大部分围绕微服务的争论都集中在容器或其他技术是否能很好的实施微服务,而红帽说API应该是重点。
83 0
|
安全 NoSQL 前端开发
微服务中的鉴权该怎么做?
微服务中的鉴权该怎么做?
|
缓存 安全 前端开发
【微服务架构】微服务不是魔术:处理超时
【微服务架构】微服务不是魔术:处理超时
|
消息中间件 Kubernetes JavaScript
Twitter下架部分微服务,是微服务错了?
Twitter下架部分微服务,是微服务错了?
|
消息中间件 存储 网络协议
你知道微服务架构中的“发件箱模式”吗
微服务架构如今非常的流行,这个架构下可能经常会遇到“双写”的场景。双写是指您的应用程序需要在两个不同的系统中更改数据的情况,比如它需要将数据存储在数据库中并向消息队列发送事件。您需要保证这两个操作都会成功。如果两个操作之一失败,您的系统可能会变得不一致。那针对这样的情况有什么好的方法或者设计保证呢?本文就和大家分享一个“发件箱模式”, 可以很好的避免此类问题。
223 0