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

微服务——在这种程度上 , 很少有软件趋势能吸引IT决策者的注意 。 他们应该能够让你的应用程序更高效和可扩展 。 但这到底意味着什么?什么时候投资于它们而不是其他类型的软件架构是个好主意?软件公司将技术细节转化为可操作的信息 , 供您在业务中使用 。
对于许多软件开发人员来说 , 基于微服务的架构已经成为他们日常工作的一个重要组成部分 , 因为越来越多的应用程序是这样制作的 。 但是 , 由于宣传太多 , 很容易把微服务当成一个时髦词 。 本文试图让每个可能从微服务中受益的人更容易就微服务在组织中的使用做出明智的决定 。 让我们来谈谈微服务;它们使用的利弊等等 。
微服务——它们到底是什么?根据Gartner的一个流行定义 , microservice是应用程序的一个“紧密限定范围、强封装、松散耦合、可独立部署和独立扩展”的组件 。 让我们把它分解 。
严格的范围-它有一个明确的定义 , 通常是非常狭窄的用途 。 强封装——作为代码的一部分 , 它包含其功能的整个实现 。 松散耦合——在大多数情况下 , 它是独立的 , 不需要其他微服务来工作 。 独立部署-它可以单独部署 , 而不必损害其他微服务 。 独立的可扩展性——即使一个微服务处理了大部分流量 , 我们也不需要扩展整个系统 , 而是只关注于扩展受影响的微服务 。还在困惑吗?基于微服务的应用程序的一个很好的例子可以是一个电子商务商店 , 其中每个业务领域(例如处理订单、产品目录、内部搜索、帐单、付款、交货单、PCIDSS认证)都是一个单独的微服务 。 微服务通常按照特定的业务用例进行组织 , 但是诸如身份验证或通知之类的功能也可以作为单独的微服务工作 。
这种将所有这些功能划分为完全独立的块的独特能力使微服务成为分散/分布式团队的理想选择 。 因此 , 拥有诸如Netflix或Twitter这样的分布式团队的大公司可以通过将不同的微服务分配给不同的团队来高效地工作 。 但这并不是许多创新科技公司选择微服务的唯一原因 。 当你继续读下去的时候 , 这些优势应该会越来越明显 。
让我们更深入地研究微服务是如何工作的 。 如您所知 , 在一个标准的单片应用程序中 , 代码库可以大致分为两部分:前端和后端 。 每一个都有一个独立的代码库 。 通常 , 不同的团队会处理这些问题 , 并且每一层都可以拥有自己的主导技术(例如 , 针对前端和节点.js用于后端) 。 如下所示 。
产业气象站 「微服务架构」面向CTO的微服务简介:微服务对企业的利弊
文章图片
在基于微服务的体系结构中 , 前端层保持不变 , 但后端被分成多个部分 , 专门用于特定功能 。 它们中的每一个都可以有自己的存储库 。 由于它们是强封装的 , 每个微服务都可能用不同的语言编写 , 如下图所示 。
产业气象站 「微服务架构」面向CTO的微服务简介:微服务对企业的利弊
文章图片
对于许多项目——在这些项目中 , 没有必要(或能力)涉及这么多不同的技术 , 而且存在如此多的存储库会造成混乱(复杂的项目结构、存储库之间代码组织的差异等等) , 这些都超过了这种分离的好处——可以使用简化的版本 。 通过使用monorepos , 可以创建包含所有使用相同技术堆栈的微服务的代码的存储库 。
产业气象站 「微服务架构」面向CTO的微服务简介:微服务对企业的利弊
文章图片
回到单片与微服务的问题 。 基于微服务的体系结构与整体式架构还有什么不同?
产业气象站 「微服务架构」面向CTO的微服务简介:微服务对企业的利弊
文章图片
你设置了一次 。 不需要太多的编排 。 但是 , 如果出现问题 , 您根本无法部署应用程序 。 维护需要DevOps关于Docker、Kubernetes等的知识易于维护可靠性中断一个服务并不会破坏其他服务 , 因此只有一组功能可能会受到影响 。 破坏了应用程序中的一个地方 , 破坏了一切 。 可扩展性每个服务都是独立扩展的 。 我们只使用我们需要的资源 。 为了扩展系统的单个部分 , 您必须扩展整个系统 , 这可能导致资源没有得到充分利用 。 发布您发布了一个服务 , 因此只需要与此特定服务相关的测试 。 一次发布整个系统 , 所以每次都需要整个回归 。


推荐阅读