浙江龙网

  1. 首页 > 生活百科 > >

什么是 微服务( 二 )

生活百科单体


新的 IBM 调查数据 显示，56% 的当前非用户可能或非常可能在未来两年内采用微服务，78% 的当前微服务用户可能会增加他们在微服务上投入的时间、金钱和精力
微服务架构通常被描述为针对 DevOps 和持续集成/持续交付 (CI/CD) 进行了优化，在可以频繁部署的小型服务的上下文中，原因很容易理解 。
但另一种看待微服务和 DevOps 之间关系的方式是，微服务架构实际上需要DevOps 才能成功 。
虽然单体应用程序具有本文前面讨论过的一系列缺点，但它们的好处是它不是一个具有多个移动部件和独立技术堆栈的复杂分布式系统 。
相比之下，鉴于微服务带来的复杂性、移动部件和依赖项的大量增加，在部署、监控和生命周期自动化方面没有大量投资的情况下使用微服务是不明智的 。
虽然几乎任何现代工具或语言都可以在微服务架构中使用，但有一些核心工具已成为微服务必不可少的边界定义：
微服务的关键要素之一是它通常非常小 。
（没有任意数量的代码可以确定某物是否是微服务，但名称中的“微”就在那里 。）
当Docker在 2013 年迎来现代容器时代时，它还引入了与微服务最密切相关的计算模型 。
由于单个容器没有自己的操作系统的开销，它们比传统的虚拟机更小更轻，并且可以更快地启动和关闭，使其成为微服务架构中更小、更轻的服务的完美匹配.
随着服务和容器的激增，编排和管理大量容器很快成为关键挑战之一 。
Kubernetes是一个开源容器编排平台，已成为最受欢迎的编排解决方案之一，因为它做得非常好 。
微服务通常通过 API 进行通信，尤其是在首次建立状态时 。
虽然客户端和服务确实可以直接相互通信，但 API 网关通常是一个有用的中间层，尤其是当应用程序中的服务数量随着时间的推移而增长时 。
API 网关通过路由请求、跨多个服务扇出请求以及提供额外的安全性和身份验证来充当客户端的反向代理 。
有多种技术可用于实现 API 网关，包括 API 管理平台，但如果使用容器和 Kubernetes 实现微服务架构，则网关通常使用 Ingress 或最近的Istio 来实现 。
虽然最佳实践可能是设计无状态服务，但状态仍然存在，服务需要了解它 。
虽然 API 调用通常是为给定服务初始建立状态的有效方式，但它并不是保持最新状态的特别有效方式 。
不断的轮询，“我们到了吗？” 保持服务最新的方法根本不切实际 。
相反，有必要将建立状态的 API 调用与消息传递或事件流结合起来，以便服务可以广播状态的变化，而其他相关方可以监听这些变化并进行相应的调整 。
这项工作可能最适合通用消息代理，但在某些情况下，事件流平台（例如Apache Kafka）可能更适合 。
通过将微服务与事件驱动架构相结合，开发人员可以构建分布式、高度可扩展、容错和可扩展的系统，可以实时消费和处理大量事件或信息 。
无服务器架构将一些核心云和微服务模式得出其合乎逻辑的结论 。
在无服务器的情况下，执行单元不仅仅是一个小服务，而是一个函数，它通常可以只是几行代码 。
将无服务器功能与微服务分开的界限很模糊，但通常认为功能比微服务还要小 。
无服务器架构和功能即服务 (FaaS)平台与微服务的相似之处在于，它们都对创建更小的部署单元和根据需求精确扩展感兴趣 。
微服务不一定与云计算完全相关，但它们如此频繁地结合在一起有几个重要原因——这些原因超越了微服务成为新应用程序的流行架构风格以及云成为新应用程序的流行托管目的地的原因 。
微服务架构的主要优势之一是与单独部署和扩展组件相关的利用率和成本优势 。
虽然这些优势在一定程度上仍然存在于本地基础设施中，但小型、独立可扩展的组件与按需、按使用付费的基础设施相结合是可以找到真正成本优化的地方 。
其次，也许更重要的是，微服务的另一个主要好处是每个单独的组件都可以采用最适合其特定工作的堆栈 。
当您自己管理堆栈扩散时，可能会导致严重的复杂性和开销，但是将支持堆栈作为云服务使用可以大大减少管理挑战 。
换句话说，虽然推出自己的微服务基础设施并非不可能，但不可取，尤其是刚开始时 。
在微服务架构中，有许多常见且有用的设计、通信和集成模式有助于解决一些更常见的挑战和机遇，包括：
例如，在桌面上使用的应用程序将具有与移动设备不同的屏幕尺寸、显示和性能限制 。

推荐阅读


上一篇：华为手机开空调怎么开

下一篇：第二季度是哪几个月