什么是 微服务


什么是 微服务

文章插图
微服务架构是一种方法,其中单个应用程序由许多松散耦合且可独立部署的较小服务组成 。
微服务(或微服务架构)是一种云原生架构方法,其中单个应用程序由许多松散耦合且可独立部署的较小组件或服务组成 。
这些服务通常
虽然关于微服务的大部分讨论都围绕架构定义和特征展开,但它们的价值可以通过相当简单的业务和组织优势来更普遍地理解:
微服务也可以通过它们不是什么来理解 。
与微服务架构最常进行的两个比较是单体架构和面向服务的架构 (SOA) 。
微服务和单体架构之间的区别在于,微服务由许多较小的、松散耦合的服务组成一个应用程序,而不是大型、紧密耦合的应用程序的单体方法
微服务和 SOA 之间的区别可能不太清楚 。
虽然可以在微服务和 SOA 之间进行技术对比,尤其是围绕 企业服务总线 (ESB) 的角色,但更容易将差异视为范围之一。
SOA 是企业范围内的一项努力,旨在标准化组织中所有 Web 服务相互通信和集成的方式,而微服务架构是特定于应用程序的 。
微服务可能至少与开发人员一样受高管和项目负责人的欢迎 。
这是微服务更不寻常的特征之一,因为架构热情通常是为软件开发团队保留的 。
原因是微服务更好地反映了许多业务领导者希望构建和运行他们的团队和开发流程的方式 。
换句话说,微服务是一种架构模型,可以更好地促进所需的操作模型 。
在IBM 最近对 1,200 多名开发人员和 IT 主管进行的一项调查中,87% 的微服务用户同意微服务的采用是值得的 。
也许微服务最重要的一个特点是,由于服务更小并且可以独立部署,它不再需要国会的法案来更改一行代码或在应用程序中添加新功能 。
微服务向组织承诺提供一种解毒剂,以解决与需要大量时间的小改动相关的内心挫败感 。
它不需要博士学位 。
在计算机科学中看到或理解一种更好地促进速度和敏捷性的方法的价值 。
但速度并不是以这种方式设计服务的唯一价值 。
一种常见的新兴组织模型是围绕业务问题、服务或产品将跨职能团队聚集在一起 。
微服务模型完全符合这一趋势,因为它使组织能够围绕一个服务或一组服务创建小型、跨职能的团队,并让他们以敏捷的方式运行 。
微服务的松散耦合还为应用程序建立了一定程度的故障隔离和更好的弹性 。
服务的小规模,加上清晰的边界和沟通模式,使新团队成员更容易理解代码库并快速为其做出贡献——在速度和员工士气方面都有明显的好处 。
在传统的 n 层架构模式中,应用程序通常共享一个公共堆栈,其中一个大型关系数据库支持整个应用程序 。
这种方法有几个明显的缺点——其中最重要的是应用程序的每个组件都必须共享一个公共堆栈、数据模型和数据库,即使对于某些元素的工作有一个清晰、更好的工具 。
它造成了糟糕的架构,并且对于那些不断意识到构建这些组件的更好、更有效的方法是可用的开发人员来说是令人沮丧的 。
相比之下,在微服务模型中,组件是独立部署的,并通过 REST、事件流和消息代理的某种组合进行通信——因此每个单独服务的堆栈都可以针对该服务进行优化 。
技术一直在变化,由多个较小的服务组成的应用程序更容易和更便宜地随着更理想的技术发展而变得可用 。
使用微服务,可以单独部署单个服务,但也可以单独扩展它们 。由此产生的好处是显而易见的:如果做得正确,微服务比单体应用程序需要更少的基础设施,因为它们只支持对需要它的组件进行精确扩展,而不是在单体应用程序的情况下对整个应用程序进行扩展 。
微服务的显着优势伴随着重大挑战 。
从单体架构到微服务意味着更多的管理复杂性——更多的服务,由更多的团队创建,部署在更多的地方 。
一项服务中的问题可能会导致或由其他服务中的问题引起 。
【什么是 微服务】
日志数据(用于监控和解决问题)更加庞大,并且在服务之间可能不一致 。
新版本可能会导致向后兼容性问题 。
应用程序涉及更多的网络连接,这意味着出现延迟和连接问题的机会更多 。
DevOps 方法可以解决其中的许多问题,但 DevOps 的采用也有其自身的挑战 。
然而,这些挑战并没有阻止非采用者采用微服务——或者采用者深化他们的微服务承诺 。

推荐阅读