「微服务架构」面向CTO的微服务简介:微服务对企业的利弊

简介: 「微服务架构」面向CTO的微服务简介:微服务对企业的利弊

微服务——在这种程度上,很少有软件趋势能吸引IT决策者的注意。他们应该能够让你的应用程序更高效和可扩展。但这到底意味着什么?什么时候投资于它们而不是其他类型的软件架构是个好主意?软件公司将技术细节转化为可操作的信息,供您在业务中使用。

对于许多软件开发人员来说,基于微服务的架构已经成为他们日常工作的一个重要组成部分,因为越来越多的应用程序是这样制作的。但是,由于宣传太多,很容易把微服务当成一个时髦词。本文试图让每个可能从微服务中受益的人更容易就微服务在组织中的使用做出明智的决定。让我们来谈谈微服务;它们使用的利弊等等。

微服务——它们到底是什么?

根据Gartner的一个流行定义,microservice是应用程序的一个“紧密限定范围、强封装、松散耦合、可独立部署和独立扩展”的组件。让我们把它分解。

  • 严格的范围-它有一个明确的定义,通常是非常狭窄的用途。
  • 强封装——作为代码的一部分,它包含其功能的整个实现。
  • 松散耦合——在大多数情况下,它是独立的,不需要其他微服务来工作。
  • 独立部署-它可以单独部署,而不必损害其他微服务。
  • 独立的可扩展性——即使一个微服务处理了大部分流量,我们也不需要扩展整个系统,而是只关注于扩展受影响的微服务。

还在困惑吗?基于微服务的应用程序的一个很好的例子可以是一个电子商务商店,其中每个业务领域(例如处理订单、产品目录、内部搜索、帐单、付款、交货单、PCI DSS认证)都是一个单独的微服务。微服务通常按照特定的业务用例进行组织,但是诸如身份验证或通知之类的功能也可以作为单独的微服务工作。

这种将所有这些功能划分为完全独立的块的独特能力使微服务成为分散/分布式团队的理想选择。因此,拥有诸如Netflix或Twitter这样的分布式团队的大公司可以通过将不同的微服务分配给不同的团队来高效地工作。但这并不是许多创新科技公司选择微服务的唯一原因。当你继续读下去的时候,这些优势应该会越来越明显。

微服务是如何工作的?

让我们更深入地研究微服务是如何工作的。如您所知,在一个标准的单片应用程序中,代码库可以大致分为两部分:前端和后端。每一个都有一个独立的代码库。通常,不同的团队会处理这些问题,并且每一层都可以拥有自己的主导技术(例如,针对前端和节点.js用于后端)。如下所示。


在基于微服务的体系结构中,前端层保持不变,但后端被分成多个部分,专门用于特定功能。它们中的每一个都可以有自己的存储库。由于它们是强封装的,每个微服务都可能用不同的语言编写,如下图所示。


对于许多项目——在这些项目中,没有必要(或能力)涉及这么多不同的技术,而且存在如此多的存储库会造成混乱(复杂的项目结构、存储库之间代码组织的差异等等),这些都超过了这种分离的好处——可以使用简化的版本。通过使用monorepos,可以创建包含所有使用相同技术堆栈的微服务的代码的存储库。


回到单片与微服务的问题。基于微服务的体系结构与整体式架构还有什么不同?




你设置了一次。不需要太多的编排。但是,如果出现问题,您根本无法部署应用程序。维护需要DevOps关于Docker、Kubernetes等的知识易于维护可靠性中断一个服务并不会破坏其他服务,因此只有一组功能可能会受到影响。破坏了应用程序中的一个地方,破坏了一切。可扩展性每个服务都是独立扩展的。我们只使用我们需要的资源。为了扩展系统的单个部分,您必须扩展整个系统,这可能导致资源没有得到充分利用。发布您发布了一个服务,因此只需要与此特定服务相关的测试。一次发布整个系统,所以每次都需要整个回归。


使用微服务的好处

为您的软件选择基于微服务的体系结构对您的组织有很多潜在的好处。

  1. 代码库与业务领域保持一致—您的微服务通常是围绕组织的实际业务功能/目标来组织的,这意味着开发人员和业务人员更容易理解技术和业务是如何联系在一起的。
  2. 非常适合分布式团队——不同的开发人员/团队可以在不同的微服务上工作,而不会相互妨碍。对于分布式团队来说,这比一个整体式的团队要方便得多。
  3. 更易于构建和维护——根据功能将代码库拆分为更小的独立片段意味着它们更易于理解和维护。Docker等许多工具简化了新微服务的创建。
  4. 易于部署–因为您不会中断整个应用程序,所以您可以经常修改和部署新的和现有的微服务。还有一些工具可以让它变得更简单,比如Kubernetes。
  5. 提高生产力——从事特定微服务的开发人员不需要等待其他开发人员完成他们的工作。接管自己的工作也更容易,因为较小的代码库更容易理解。质量保证也在这个过程中得到了突破。
  6. 选择技术的自由度——每个微服务都可以用不同的技术开发,这样就可以为每个问题选择最有效的解决方案。这也在很大程度上消除了技术和供应商的锁定——你的应用程序并不完全依赖于任何第三方软件。
  7. 高性能、高效率和可扩展性–您可以单独扩展每个微服务。这意味着单个服务可以部署在多个服务器中,以服务于增加的流量,而其他服务同时只消耗标准数量的资源。您可以以经济高效的方式保持高性能。
  8. 可靠性—故障隔离意味着单个服务的故障不太可能影响其他服务的性能。在一个巨石应用程序中,类似的错误可能会导致整个系统崩溃。

微服务:不同场景下的利弊

到目前为止,您可能已经对微服务能够很好地配合的项目有了一个很好的想法。总而言之:

  • 由于微服务提供了出色的可伸缩性并鼓励基于敏捷的工作流,因此它们非常适合于在这些领域有高要求的应用程序。
  • 由于代码库可以根据功能划分为完全独立开发的单元,因此对于分布式团队来说,这是一个明显的选择,特别是对于代表各种技术堆栈的开发人员。
  • 项目越复杂、流量密集、面向长期,就越适合基于微服务的架构。

现在,让我们来看看微服务什么时候不是最好的选择——微服务的缺点。让我们考虑几个场景。

对Netflix有利的事情可能对我们不利

大型公司,如Netflix,在各地都有不同的开发团队,可以从微服务的模块化特性中获益匪浅。实现基于微服务的体系结构的成本往往比构建一个单一的应用程序要高(您需要考虑日志监视系统、请求跟踪和部署整个系统以及任何单个微服务的能力)。对于那些不希望出现大流量、可伸缩性问题和混合各种技术的系统来说,这可能不值得。

太过敏捷会让你变得僵硬

多亏了微服务,您可以通过单独部署每个微服务来更轻松地进行迭代。测试和部署成为日常工作流程的重要组成部分,而不是很少发生。但随之而来的是巨大的责任。随着动态变化的微服务数量的增加,需要大量的DevOps功能和丰富的经验才能掌握它们。

我只是在试水!

你在创建一个新的(绿地)项目吗?你是否有一个想法,并想创造一个最有价值球员?你最好的选择可能是一块巨石。你不仅不知道你需要什么样的微服务,而且从一开始就不需要微服务的复杂性。毕竟,如果有必要的话,将来您总是可以从一个整体式架构转向基于微服务的架构。

如何开始使用微服务?

有几件事你应该记住。首先,让我们考虑一下在任何情况下都成立的观点

从头开始

  1. 不要急于求成-确保项目证明了微服务的合理性。根据我们上面所做的所有考虑,确保您的项目适合微服务。
  2. 不要仅仅从理论上讲敏捷。如果没有强大的敏捷文化,您将无法从微服务中获益。
  3. 投资于您的DevOps文化/能力。DevOps也是如此——你的架构越大,你需要管理的微服务越多,它就越明显。

现在,谈谈更具体的问题(很有可能!)从单一体系结构到微服务的场景。

从单体到微服务

  1. 不要从头开始!既然你已经有了一个应用程序,你应该从它开始作为你的基础。即使你不打算马上去“微服务一路走来”,你也可以简单地在微服务中开发新功能,同时暂时保持你的基础作为一个整体。
  2. 避免分散的整体。不要从传统的巨石直接进入微服务。否则,你可能会得到一个分布式的整体——一个表面上模块化的应用程序,其中所有模块实际上都高度依赖于彼此。
  3. 去做一个模块化的整体。最好的方法是将你的整体分割成更小的、独立的部分,然后逐步地将它们转化为服务。

微服务TSH方式

你想知道软件公司是如何使用微服务的吗?我们将把最佳实践的细节留待下次讨论,但以下是TSH主管的一些最重要的观点节点.js亚当·波拉克。

TSH的一个重要实践就是不要浪费时间创建所谓的样板(创建新服务结构所需的一切)。通过在项目早期阶段创建的一组工具,我们可以快速创建新的服务,并专注于最重要的业务逻辑。”

DevOps对微服务的仔细监控对于效率、稳定性和快速恢复至关重要。

另一个重要的问题是DevOps功能,以及对服务性能的仔细监控——日志记录、跟踪、指标配置。感谢所有这些,我们的服务是稳定的。一旦出现问题,我们就能迅速找到原因。

结论

此时,您应该知道微服务是否适合您。总而言之:

  • 微服务潜力巨大
  • 但是,只有当项目复杂到足以超过维护和迁移到基于微服务的体系结构的成本时,才应该在项目中使用它们
  • 从整体到微服务的转变应该考虑到很多因素
相关文章
|
6天前
|
Cloud Native 安全 数据安全/隐私保护
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####
|
7天前
|
Dubbo Java 应用服务中间件
服务架构的演进:从单体到微服务的探索之旅
随着企业业务的不断拓展和复杂度的提升,对软件系统架构的要求也日益严苛。传统的架构模式在应对现代业务场景时逐渐暴露出诸多局限性,于是服务架构开启了持续演变之路。从单体架构的简易便捷,到分布式架构的模块化解耦,再到微服务架构的精细化管理,企业对技术的选择变得至关重要,尤其是 Spring Cloud 和 Dubbo 等微服务技术的对比和应用,直接影响着项目的成败。 本篇文章会从服务架构的演进开始分析,探索从单体项目到微服务项目的演变过程。然后也会对目前常见的微服务技术进行对比,找到目前市面上所常用的技术给大家进行讲解。
17 1
服务架构的演进:从单体到微服务的探索之旅
|
6天前
|
Cloud Native 安全 API
云原生架构下的微服务治理策略与实践####
—透过云原生的棱镜,探索微服务架构下的挑战与应对之道 本文旨在探讨云原生环境下,微服务架构所面临的关键挑战及有效的治理策略。随着云计算技术的深入发展,越来越多的企业选择采用云原生架构来构建和部署其应用程序,以期获得更高的灵活性、可扩展性和效率。然而,微服务架构的复杂性也带来了服务发现、负载均衡、故障恢复等一系列治理难题。本文将深入分析这些问题,并提出一套基于云原生技术栈的微服务治理框架,包括服务网格的应用、API网关的集成、以及动态配置管理等关键方面,旨在为企业实现高效、稳定的微服务架构提供参考路径。 ####
27 5
|
7天前
|
负载均衡 监控 Cloud Native
云原生架构下的微服务治理策略与实践####
在数字化转型浪潮中,企业纷纷拥抱云计算,而云原生架构作为其核心技术支撑,正引领着一场深刻的技术变革。本文聚焦于云原生环境下微服务架构的治理策略与实践,探讨如何通过精细化的服务管理、动态的流量调度、高效的故障恢复机制以及持续的监控优化,构建弹性、可靠且易于维护的分布式系统。我们将深入剖析微服务治理的核心要素,结合具体案例,揭示其在提升系统稳定性、扩展性和敏捷性方面的关键作用,为读者提供一套切实可行的云原生微服务治理指南。 ####
|
8天前
|
缓存 负载均衡 JavaScript
探索微服务架构下的API网关模式
【10月更文挑战第37天】在微服务架构的海洋中,API网关犹如一座灯塔,指引着服务的航向。它不仅是客户端请求的集散地,更是后端微服务的守门人。本文将深入探讨API网关的设计哲学、核心功能以及它在微服务生态中扮演的角色,同时通过实际代码示例,揭示如何实现一个高效、可靠的API网关。
|
17天前
|
弹性计算 Kubernetes Cloud Native
云原生架构下的微服务设计原则与实践####
本文深入探讨了在云原生环境中,微服务架构的设计原则、关键技术及实践案例。通过剖析传统单体架构面临的挑战,引出微服务作为解决方案的优势,并详细阐述了微服务设计的几大核心原则:单一职责、独立部署、弹性伸缩和服务自治。文章还介绍了容器化技术、Kubernetes等云原生工具如何助力微服务的高效实施,并通过一个实际项目案例,展示了从服务拆分到持续集成/持续部署(CI/CD)流程的完整实现路径,为读者提供了宝贵的实践经验和启发。 ####
|
8天前
|
监控 API 微服务
后端技术演进:从单体架构到微服务的转变
随着互联网应用的快速增长和用户需求的不断演化,传统单体架构已难以满足现代软件开发的需求。本文深入探讨了后端技术在面对复杂系统挑战时的演进路径,重点分析了从单体架构向微服务架构转变的过程、原因及优势。通过对比分析,揭示了微服务架构如何提高系统的可扩展性、灵活性和维护效率,同时指出了实施微服务时面临的挑战和最佳实践。
26 7
|
7天前
|
Kubernetes 负载均衡 Cloud Native
云原生架构下的微服务治理策略
随着云原生技术的不断成熟,微服务架构已成为现代应用开发的主流选择。本文探讨了在云原生环境下实施微服务治理的策略和方法,重点分析了服务发现、负载均衡、故障恢复和配置管理等关键技术点,以及如何利用Kubernetes等容器编排工具来优化微服务的部署和管理。文章旨在为开发者提供一套实用的微服务治理框架,帮助其在复杂的云环境中构建高效、可靠的分布式系统。
21 5
|
8天前
|
监控 持续交付 Docker
Docker 容器化部署在微服务架构中的应用有哪些?
Docker 容器化部署在微服务架构中的应用有哪些?
|
8天前
|
监控 持续交付 Docker
Docker容器化部署在微服务架构中的应用
Docker容器化部署在微服务架构中的应用