当前位置: 首页 > 科技观察

微服务架构简介

时间:2023-03-15 16:20:13 科技观察

微服务架构描述了一种使用一组松散耦合的服务来开发应用程序的方法。以前,应用程序基于集中式多层架构。在大型机和台式机时代,这很有效。但在云计算和移动设备中,后端必须随时可供各种设备使用。错误修复和功能必须在不停机或不部署整个应用程序的情况下快速交付。微服务是独立部署的,并通过webapi或消息队列进行通信以响应传入的事件。它们协同工作以提供各种功能,例如用户界面前端、推荐、物流、计费等。微服务通常运行在容器中。容器简化了微服务的部署,但微服务可以在没有容器的情况下运行。微服务是封装业务场景的自治和独立服务。它包含代码和状态。通常,微服务甚至包含自己的数据存储。这使得它可以独立版本化、可扩展和可部署。微服务松散耦合,并通过使用http等协议的定义良好的接口与其他微服务交互。它们保持一致并且在发生故障时可用。微服务是可以独立发布的。每个微服务都可以自行扩展,而无需扩展整个应用程序。微服务有哪些类型?从广义上讲,有两种类型的微服务:无状态:没有状态或可以从外部存储(缓存/数据库)中检索。它可以在不影响状态的情况下扩展。可以有N个实例。示例:Web前端、协议网关等。无状态服务不是缓存或数据库。它频繁访问元数据,没有实例关联,节点丢失不明显。正面:保持强势、权威的姿态。对于大型超大规模应用程序,状态保持接近计算状态。N通过复制和本地持久化实现了一致性副本。示例:数据库、文档、工作流、用户配置文件、购物车等。有状态服务由数据库和缓存组成,节点丢失是一个值得注意的事件。它有时是一个包含大量数据的自定义应用程序。作为变体,一位作者确定了三种类型:无状态(计算)、持久(存储)、聚合(编排)。聚合微服务依赖于其他微服务,因此具有网络和磁盘I/O依赖性。当我们将微服务视为分层架构时,我们可以识别以下类型:核心/原子服务:细粒度的独立服务。没有外部服务依赖性。主要是业务逻辑。通常没有网络电话。组合/集成服务:由多个核心服务组成的业务功能。包括业务逻辑和网络调用。实施路由、转换、编排、弹性和稳定性模式。通常与遗留或专有系统接口。API/边缘服务:一组选定的集成服务和核心服务,作为用户的托管API提供。实施路由、API版本控制、API安全和限制。微服务与API有何不同?API不是微服务,微服务也不是API的实现。API是一个接口。微服务是一个组件。术语“微”指的是组件,而不是暴露接口的粒度。微服务可用于公开一个或多个API。但是,并非所有微服务组件都会公开API。微服务架构和面向服务的架构(SOA)之间有什么关系?SOA和微服务架构涉及不同的范围。SOA与企业服务开放相关,而微服务架构与应用架构相关。两者都试图实现许多相同的事情(将业务功能创建为独立的组件),但规模不同。它们在可维护性、粒度、敏捷性等方面有所不同。SOA是一个非常广泛的术语,微服务是该用法的一个子集。Netflix指出微服务是“细粒度的SOA”。微服务被认为是“正确的SOA”。一些微服务原则与SOA有很大不同:1.重用不是目标:由于公共组件创建的依赖关系,不鼓励公共组件的重用。最好通过复制重复使用。2.同步不好:进行API或Web服务等同步调用会产生实时依赖性。尽可能使用微服务之间的消息传递。3.运行时服务发现:假定组件是易变的。因此,通常客户有责任找到实例,甚至对实例进行负载平衡。4、采用数据复制技术:事件源等技术可以生成多个独立的数据“视图”,确保微服务真正解耦。设计微服务架构时要牢记哪些重要原则?通常,在设计微服务架构时,以下原则是好的:围绕业务领域建模、自动化文化、隐藏实现细节、高度可观察性、分散一切、隔离故障、消费者至上、独立部署。使用微服务架构有什么好处?收益跨越开发和运营。简单地说,我们注意到以下优势:大规模构建和运营服务、提高资源利用率以降低成本、故障隔离、持续创新、小型专用团队、使用任何语言或框架。可扩展性来自微服务支持的模块化。由于容器,在各种环境中部署微服务变得更加容易。由于服务的隔离,还有一个安全优势:对一个服务的攻击不会影响其他服务。微服务是关于代码和开发的。容器是关于部署的。容器支持微服务。容器提供了一个隔离的环境,因此非常适合部署微服务。但是,可以在没有容器的情况下部署微服务。例如,微服务可以独立部署在AmazonEC2上。每个微服务都可以在自己的自动缩放组中独立缩放。为什么我不应该为我的应用程序采用微服务?这样的分布式系统更难管理和监控,因为应用程序是跨微服务分布的。操作复杂性随着微服务及其实例的数量增加而增加,尤其是当它们是动态创建和销毁时。网络调用可能很慢,有时会失败。因为是分布式,很难保持强一致性,应用必须保证最终一致性。微服务需要更多的时间来规划和划分应用程序。它们的设计应该考虑到失败。当您构建最小可行产品(MVP)或尝试评估哪些有效或可以为业务增加价值时,单一方法会更快、更容易。只有在您的想法和业务价值得到证实并需要扩展时才采用微服务。如果您正在管理遗留应用程序,迁移到微服务的工作可能会非常昂贵。技术堆栈可能比单个应用程序大得多。应用程序对网络及其性能有很强的依赖性。微服务可以独立测试,但是要测试整个应用就比较难了。