首页 > 编程知识 正文

微服务的劣势,微服务与传统的优势

时间:2023-05-06 06:55:12 阅读:144629 作者:3380

在知道什么是微服务的微服务之前,需要知道与微服务相对应的单体式(Monolithic )体系结构。 在Monolithic体系结构中,系统通常采用分层体系结构模式,并按技术维度对系统进行分类,包括可持续发展层、业务逻辑层和表示层。 Monolithic体系结构主要存在以下问题:

系统之间通常以API的形式相互访问,结合紧密,维护困难;

各业务领域需要采用相同的技术堆栈,难以快速应用新技术;

所有对系统的更改都必须在整个系统中重新部署/升级,运输成本很高

在系统负荷增加的情况下,水平扩展变得困难;

如果系统中的某个地方出现问题,就会影响整个系统。

为了解决这些问题,微服务体系结构应运而生。 微服务也称为微服务体系结构。 微服务体系结构是一种体系结构类型,它将复杂的APP应用程序划分为多个独立自主的服务,并在服务和服务之间以松散耦合的形式进行交互。

例如,在以下示例中,将一个系统的后端划分为三个微服务:帐户/库存/shipping,每个微服务具有自己的数据库存储,对外提供样式一致的REST API

微服务的主要特点单一职责各项微服务必须符合单一职责原则,微服务本身是凝聚的,因此微服务通常很小。 例如,每个微服务按业务逻辑分类,每个微服务只负责自己属于自己业务领域的功能。

微服务的开发通常与DevOps相结合,例如根据亚马逊提供的经验,一个微服务应该可以由一个Two Pizza Team负责设计、开发、测试和运输。

自主微服务是独立的实体,可以独立部署和升级,服务和服务之间通过REST等形式的标准接口进行通信,微服务实例可以在不影响其他微服务的情况下安装到其他实现中

例如,可以用具有相同接口的不同实现方法的实例替换示例帐户服务。 替换后,不影响其他服务。 或者,如果修复了错误,则灰度升级技术允许其他服务在升级期间使用帐户服务提供的服务。

微服务的单一责任要求带来了为什么微服务逻辑需要清晰的特点。 负责明确业务的微服务肯定比复杂系统更容易逻辑理解。

逻辑清晰是微服务的可维护性,当我们对微服务进行修改时,可以更容易地分析这种修改会产生什么影响,通过完整的测试来保证修改质量。

要简化部署到单个系统,只需修改一行代码,就可以重建、测试整个系统并部署整个系统。 微服务可以引入微服务。

这样做的一个好处是,您可以更频繁地修改软件,以更低的成本快速发布新功能。

适应可扩展系统业务增长的方法通常在向外扩展或向上扩展的方向上扩展。 在分布式系统中,通常用Scale out方式进行扩展。 由于每个功能都会面临不同的负载变化,因此采用微服务的系统比单个系统具有更好的可扩展性。

通过灵活地组合在微服务架构中,组合现有的微服务可以实现功能复用的目的。

例如,如果添加Booking Service,则可以在保留时直接重用Account Service和Inventory Service以检查用户权限和库存情况。

技术在一个大型系统中可能不同,功能不同,特点不同,团队的技术能力也不同。 由于微服务之间的松散耦合,不同的微服务可以选择不同的技术堆栈来开发。

另外,应用新技术时,可以只快速改造一个微服务,不影响系统内的其他微服务,有利于系统的发展。

例如,由于清单系统中的数据量较大,如果需要将数据从当前sqlite数据库更改为MySQL,则无需替换整个系统中的所有数据库,只能更改库存服务。

在可靠的微服务之间独立部署,一个微服务的异常不会导致其他微服务同时异常。 可以避免隔离、熔断等技术大大提高微服务的可靠性。

微服务缺点复杂度高的微服务之间以REST、RPC等形式进行交换,对于Monolithic模式下的API形式,需要考虑调用方的故障、过载、消息丢失等各种异常情况,代码逻辑较好

对于微服务之间的事务操作,由于每个微服务都使用不同的数据库,因此无法利用数据库本身的事务机制来保证一致性,需要引入两阶段提交等技术。

另外,如果微服务之间存在共同功能的一部分,但不能提取为微服务,则每个微服务通常需要对该功能的一部分进行重复开发,或者至少进行代码复制,以避免微服务之间的耦合,从而实现开发副本

运维采用复杂微服务体系结构时,系统由多个独立运行的微服务组成,一个设计良好的监控系统需要监控各个微服务的运行状态。 运输业者必须对系统有详细的了解,才能建立更好的运输系统。

与Monolithic体系结构相比,影响性能的是微服务之间通过REST、RPC等形式进行交流,通信延迟受到很大影响。

微服务是近几年的火灾,具有灵活的部署、可扩展性、技术异构化等优点,但同时也带来了开发、运输的复杂性。 是否采用微服务体系结构,需要根据系统特点,结合企业组织体系结构、团队能力等多个方面进行综合判断,而不是

为了微服务而微服务。

个人建议,在开发一个新的系统时,因为业务逻辑和系统边界还不是那么清晰,可以先采用Monolithic方式开发,直到能够识别出稳定逻辑后再进行微服务的拆分,从而避免因为边界不清而进行重划分所带来的返工。

版权声明:该文观点仅代表作者本人。处理文章:请发送邮件至 三1五14八八95#扣扣.com 举报,一经查实,本站将立刻删除。