认识达内从这里开始

微服务编程开发技术随着互联网的不断发展而被越来越多的程序员掌握，今天我们就通过案例分析来简单了解一下，微服务架构组件都有哪些类型。

一、简介

在微服务工程的技术选型中，会涉及到很多组件的集成，常用包括：缓存、消息队列、搜索、定时任务、存储等几个方面;

如果工程是单服务，对于集成组件的管理来说并不算复杂;但是在分布式的多服务系统中，随着拆分的服务数量上升，统一管理各种组件的复杂度也会提高;

在整个工程内部拆分了几十个服务，基于一份系统架构图和一份组件依赖清单，如果熟悉微服务架构模式，可以非常快速的了解系统的基础原理和结构;

复杂系统对于中间件的依赖很重，需要在实践过程中不断的积累和总结经验，持续优化各种组件的应用策略;

对于组件来说，与项目工程的集成模式，核心的应用场景，以及在业务场景中的迭代优化，是研发需要重点关注的方面;

二、缓存管理

【集成模式】

Redis作为常见的缓存选型，在与分布式工程集成时，其形式也存在很大的灵活度;

单服务：在分布式工程中，如果服务使用独立的Redis组件，通常是该服务支持的业务场景比较独特，比如高并发或者数据体量较大等;

分布式服务：微服务常见的集成方式，不同的服务使用同一个Redis的不同DB编号，其他服务必须通过该服务的接口访问其缓存数据;

缓存中心：整个工程基于一个缓存中心服务来管理，其适配的业务场景比较特殊，多个服务紧密协作，调度和处理相同的数据主体;

在实际的分布式系统中，通常是模式一和模式二两种都采用，而模式三更多的是应对特殊的需求场景;

【应用方式】

虽然Redis可以极大的提升效率，但是在实际的应用中，涉及多的就是数据缓存和加锁两个核心能力，对于组件的API使用并不算复杂;

无论是在框架层面的浅封装一层，还是围绕Redis组件编写常用的工具方法，都可以很好的实现工程和Redis相关API之间的解耦;不同服务之间缓存数据获取，需要通过各个服务提供的接口进行查询;

三、消息队列

【集成模式】

Kafka作为消息队列的常见技术选型，在与分布式工程集成时，在设计上会围绕消息生产和消费的基本模式;

服务内集成：在各个服务内部直接引入消息组件，服务可能是消息生产者也可能是消费者，当重度依赖消息通信时，流程可维护性比较差;

消息服务封装：单独封装消息生产和消费两个服务，来统一调度和管理消息通信，虽然提高了技术面的复杂度，但是极大降低了异步流程的管理难度;

在实际应用时，如果工程内对于消息的使用并不高频，通常是采用模式一的策略，建议做好流程注释和文档维护;如果消息使用非常高频，可以考虑模式二的策略，减轻组件维护的难度;

【应用方式】

生产和消费能力追求平衡，即便有偏差也只能是消息的【消费】大于【生产】的效率，才能避免消息堆积从而影响正常的业务流程;

实践来看单纯的基于MQ的重试机制，并不能稳定的解决分布式架构中复杂流程的中断问题，需要围绕消息的存储设计相应的调度策略，从而推动整个流程的完整执行，无论是向下推进还是向前回滚;

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!请读者仅作参考。更多内容请加抖音太原达内IT培训学习了解。