微服务教程:什么是 Archi结构与实例
什么是微服务?
微服务 是一种面向服务的架构模式,其中应用程序被构建为各种最小独立服务单元的集合。它是一种 软件工程 该方法侧重于将应用程序分解为具有明确定义接口的单一功能模块。这些模块可以由负责整个服务生命周期的小团队独立部署和运营。
“微”是指微服务的规模,必须由一个开发团队(5 到 10 名开发人员)管理。在这种方法中,大型应用程序被划分为最小的独立单元。
什么是单体 Archi结构?
通俗地说,你可以说单片架构就像一个大容器,其中应用程序的所有软件组件都被放在一个包中。
让我们讨论一下单体架构下电子商务商店的一个例子。
在任何电子商务应用程序中,都有一些标准功能,例如搜索, Rev查看和评分以及付款。客户可以使用浏览器或应用程序访问这些功能。当电子商务网站的开发人员部署应用程序时,它是一个单一的整体单元。搜索等不同功能的代码 Rev查看和评级以及付款位于同一台服务器上。要扩展应用程序,您需要运行这些应用程序的多个实例(服务器)。
什么是微服务 Archi结构?
微服务 Archi质地 是一种架构开发风格,允许将应用程序构建为针对业务领域开发的小型自主服务集合。它是结构化风格架构的一种变体,有助于将应用程序安排为松散耦合的服务集合。微服务 Archi结构包含细粒度的服务和轻量级协议。
让我们以使用微服务架构开发的电子商务应用程序为例。在这个微服务架构示例中,每个微服务都专注于单一业务功能。搜索、评级和 Review 和 Payment 各自拥有自己的实例(服务器)并相互通信。
在整体式 Archi架构中,所有组件都合并为一个模块。但在微服务中 Archi它们被分散到单独的模块(微服务)中,这些模块彼此之间可以通信,如上面的微服务示例所示。
微服务之间的通信是无状态通信,其中每对请求和响应都是独立的。因此,微服务可以轻松通信。在微服务中 Archi结构中,数据是联合的。每个微服务都有其单独的数据存储。接下来 Java 微服务教程,我们将了解微服务和单片架构之间的区别。
微服务与单体 Archi质地
微服务 | 单片 Archi质地 |
---|---|
整个应用程序的每个单元都应该是最小的,并且它应该能够实现一个特定的业务目标。 | 满足所有业务目标的单一代码库 |
服务启动相对较快 | 服务启动需要更多时间 |
故障隔离很容易。即使一个服务出现故障,其他服务仍可继续运行。 | 故障隔离很困难。如果任何特定功能无法正常工作,整个系统就会瘫痪。为了解决这个问题,应用程序需要重新构建、重新测试并重新部署。 |
所有微服务都应该松散耦合,以便一个微服务中的更改不会影响另一个微服务。 | 单片架构紧密耦合。一个代码模块的更改会影响另一个模块 |
企业可以将更多资源部署到产生更高投资回报率的服务上 | 由于服务不是孤立的,因此无法进行单独的资源分配 |
可以将更多硬件资源分配给经常使用的服务。在上面的电子商务示例中,与支付相比,查看产品列表和搜索的用户数量更多。因此,可以将更多资源分配给搜索和产品列表微服务。 | 应用程序扩展既有挑战性又很浪费。 |
微服务始终保持一致且持续可用。 | 由于该过程需要从头开始,开发工具负担过重。 |
数据是联合的。这允许单个微服务采用最适合其需求的数据模型。 | 数据集中化。 |
小型专注团队。并行且更快的开发 | 需要大型团队和大量的团队管理工作 |
一个微服务的数据模型的改变不会影响其他微服务。 | 数据模型的改变会影响整个数据库 |
使用定义良好的接口与其他微服务交互 | 不适用 |
微服务的工作原理是关注产品而不是项目 | 强调整个项目 |
代码库之间没有交叉依赖。您可以针对不同的微服务使用不同的技术。 | 一个功能或程序依赖于其他功能或程序。 |
微服务挑战
- 微服务相互依赖,并且它们必须相互通信。
- 与单片系统相比,需要监控的服务更多,这些服务是使用不同的 编程语言.
- 由于它是一个分布式系统,因此它是一个本质上复杂的模型。
- 不同的服务会有其单独的机制,导致大量的内存用于非结构化数据。
- 需要有效的管理和团队合作来防止问题的连锁反应
- 当问题在一个版本中消失,并在最新版本中再次出现时,重现问题将是一项困难的任务。
- 独立部署因微服务而变得复杂。
- 微服务架构带来大量的操作开销。
- 当系统添加新服务时,应用程序难以管理
- 需要大量熟练的专业人员来支持异构分布式微服务
- 微服务的成本很高,因为您需要为不同的业务任务维护不同的服务器空间。
SOA 与微服务
SOA 服务在组织中由充当目录列表的注册表维护。应用程序需要在注册表中查找服务并调用该服务。
在另一个世界里, SOA的 就像一个管弦乐队,每个艺术家都用自己的乐器演奏,而音乐总监则向所有人发出指示。
另一方面,微服务是一种面向服务的架构风格,其中应用程序被构建为不同较小服务的集合,而不是一个软件或应用程序。
微服务就像一个剧团,每个舞者都是独立的,知道自己需要做什么。所以,如果他们错过了一些步骤,他们知道如何回到正确的顺序。现在,在本微服务架构教程中,让我们了解 SOA 和微服务之间的区别。
以下是 SOA 与微服务的详细比较
产品型号 | SOA的 | 微服务 |
---|---|---|
设计类型 | 在SOA中,软件组件以服务的形式暴露给外界供使用。 | 微服务是SOA的一部分,是SOA的一种实现。 |
依赖 | 业务单位相互依赖。 | 它们彼此独立。 |
软件大小 | 软件大小比任何传统软件都大 | 在微服务中,软件的大小总是很小 |
技术栈 | 与微服务相比,技术栈较低。 | 微服务技术堆栈可能非常庞大 |
申请性质 | 本质上是整体的 | 本质上的全栈 |
独立与专注 | SOA 应用程序旨在执行多项业务任务。 | 它们是为执行单一业务任务而构建的。 |
部署 | 部署过程非常耗时。 | 部署简单且耗时较少。 |
成本效益 | 更划算。 | Less 划算的。 |
可扩展性 | Less 与微服务相比。 | 高度可扩展。 |
商业逻辑 | 业务逻辑组件存储在单个服务域内简单的有线协议(带有 XML JSON 的 HTTP)API 由 SDKs/客户端驱动 | 业务逻辑可以跨域企业服务总线,就像服务之间的层中间件 |
微服务工具
1)Wiremock:测试微服务
WireMock 是一个灵活的库,用于存根和模拟 Web 服务。它可以配置 HTTP API 在收到特定请求时返回的响应。它还可用于测试微服务。
下载链接:http://wiremock.org/
2)Docker
Docker 是一个开源项目,它允许我们使用容器创建、部署和运行应用程序。通过使用这些容器,开发人员可以将应用程序作为单个包运行。它允许您在一个包中发送库和其他依赖项。
3)Hystrix
Hystrix 是一个容错 Java 库。此工具旨在在分布式环境(如微服务)中分离对远程服务、系统和第三方库的访问点。它通过隔离故障服务并防止故障的级联效应来改善整个系统。
下载链接:https://github.com/Netflix/Hystrix
微服务最佳实践 Archi质地
- 每个微服务都有独立的数据存储
- 保留相似成熟度级别的代码。
- 为每个微服务单独构建。
- 始终将 – 严重的视为无国籍者。
总结
- 微服务是一种面向服务的架构模式,其中应用程序被构建为各种最小独立服务单元的集合。
- 微服务 Architecture 是一种架构开发风格,允许将应用程序构建为为业务领域开发的小型自主服务的集合。
- 单体架构就像一个大容器,应用程序的所有软件组件都被集中到一个包中
- 在微服务中,整个应用程序的每个单元都应该是最小的,并且应该能够实现一个特定的业务目标
- 在单体架构中,庞大的代码库会拖慢整个开发过程。新版本发布可能需要数月时间。代码维护困难
- 微服务有两种类型:1)无状态 2)有状态
- 微服务 Java 相互依赖,他们必须相互沟通。帮助您强调特定功能和业务需求
- 面向服务架构(SOA)是一种基于同步和异步应用程序的请求或回复设计模型的分布式计算的演变
- 在 SOA 中,软件组件以服务的形式暴露给外部世界,而微服务是 SOA 的一部分。它是 SOA 的一种实现
- Wiremock、Docker 和 Hystrix 是一些流行的微服务工具