共计 2869 个字符，预计需要花费 8 分钟才能阅读完成。
有品：There is no silver bullet；
一、简介
在微服务工程的技术选型中，会波及到很多组件的集成，最罕用包含：缓存、音讯队列、搜寻、定时工作、存储等几个方面；
如果工程是单服务，对于集成组件的治理来说并不算简单；然而在分布式的多服务零碎中，随着拆分的服务数量回升，对立治理各种组件的复杂度也会进步；
如上图，是团队外部保护的一份重要的零碎清单：形容整个微服务体系中外围组件的依赖状况；【并不残缺】
在整个工程外部拆分了几十个服务，基于一份零碎架构图和一份组件依赖清单，如果相熟微服务架构模式，能够十分疾速的理解零碎的根底原理和构造；
简单零碎对于中间件的依赖很重，须要在实际过程中一直的积攒和总结经验，继续优化各种组件的利用策略；
对于组件来说，与我的项目工程的集成模式，外围的利用场景，以及在业务场景中的迭代优化，是研发须要重点关注的方面；
二、缓存治理
【集成模式】
Redis 作为最常见的缓存选型，在与分布式工程集成时，其模式也存在很大的灵便度；
单服务：在分布式工程中，如果服务应用独立的 Redis 组件，通常是该服务反对的业务场景比拟独特，比方高并发或者数据体量较大等；
分布式服务：微服务常见的集成形式，不同的服务应用同一个 Redis 的不同 DB 编号，其余服务必须通过该服务的接口拜访其缓存数据；
缓存核心：整个工程基于一个缓存核心服务来治理，其适配的业务场景比拟非凡，多个服务严密合作，调度和解决雷同的数据主体；
在理论的分布式系统中，通常是 模式一 和模式二 两种都采纳，而 模式三 更多的是应答非凡的需要场景；
【利用形式】
尽管 Redis 能够极大的晋升效率，然而在理论的利用中，波及最多的就是数据缓存和加锁两个外围能力，对于组件的 API 应用并不算简单；
无论是在框架层面的浅封装一层，还是围绕 Redis 组件编写罕用的工具办法，都能够很好的实现工程和 Redis 相干 API 之间的解耦；不同服务之间缓存数据获取，须要通过各个服务提供的接口进行查问；
三、音讯队列
【集成模式】
Kafka 作为音讯队列的常见技术选型，在与分布式工程集成时，在设计上会围绕音讯生产和生产的基本模式；
服务内集成 ：在各个服务外部间接引入音讯组件，服务可能是音讯 生产者 也可能是 消费者，当重度依赖音讯通信时，流程可维护性比拟差；
音讯服务封装 ：独自封装音讯 生产 和生产 两个服务，来对立调度和治理音讯通信，尽管进步了技术面的复杂度，然而极大升高了异步流程的治理难度；
在理论利用时，如果工程内对于音讯的应用并不高频，通常是采纳 模式一 的策略，倡议做好流程正文和文档保护；如果音讯应用十分高频，能够思考 模式二 的策略，加重组件保护的难度；
【利用形式】
生产和生产能力谋求均衡，即使有偏差也只能是音讯的【生产】大于【生产】的效率，能力防止音讯沉积从而影响失常的业务流程；
实际来看单纯的基于 MQ 的重试机制，并不能稳固的解决分布式架构中简单流程的中断问题，须要围绕音讯的存储设计相应的调度策略，从而推动整个流程的残缺执行，无论是向下推动还是向前回滚；
四、搜索引擎
【集成模式】
对于搜索引擎 Elasticsearch 来说，个人感觉在惯例业务场景中是最容易出问题的组件，应用 ES 索引的数据模型，通常结构复杂并且数据体量偏大，还波及到大量的检索条件；
服务内治理索引和数据：通常是外围的业务场景，对数据的实时性要求极高，从惯例的架构设计来思考，尽管索引相干的构造和数据可能来自多个数据库，然而其治理的接口会对立封装在业务联系最亲密的服务内；
独立组件治理索引数据：基于独立的组件（罕用 Logstash）进行调度，动静地采集、转换和传输数据，不受格局或复杂度的影响，数据往往以各种各样的模式，或扩散或集中地存在于很多零碎中；
无论是 模式一 还是 模式二 ，都是 ES 罕用的集成策略，比方 模式一 对于外围数据模型的构建，常见于订单或商品等，模式二 的经典用法之一 ELK 日志采集等；
【利用形式】
以服务外部治理索引的形式来说，少数状况下索引的构造会一直的扩大，构造更新必然也会引起数据和检索条件的同步更新，如果是构造新增的形式更新，治理难度并不大，然而已有字段的类型更新，还须要索引重建；
对于 ES 这种操作起来比较复杂的技术组件，倡议是把各种罕用的操作编写程序脚本来解决，并且开发相应的治理性能，用更加稳固可控的形式来治理索引的构造和数据调度；
五、定时工作
【集成模式】
Quartz 任务调度组件，在分布式系统中并不算简单，基于定时器去触发各种工作执行即可；
服务内构建定时器：在一些简略的绝对独立的服务中，能够在服务内配置定时器，去执行相应的工作流程，这种模式在简单的分布式系统中很难保护；
独立的任务调度服务：能够对立治理工作的调度策略和执行形式（比方同步或异步），同时对任务调度服务进行监控和保护，以此确保任务调度零碎的稳定性和可靠性；
通常 模式一 只会在个别独立的服务中采纳，对于 模式二 来说，封装独立的任务调度服务，能够对立与其余服务进行集成或者通信，比方通过音讯服务及时告诉失败的工作等；
【利用形式】
在任务调度服务中，不免要和其余服务进行通信交互，从而触发相干工作的执行，如果零碎外部定时工作不多的话，能够采纳 feign 接口 的形式触发，如果工作十分多，能够思考间接构建 Http 申请的形式，防止服务频繁的降级迭代；
在调度工作中可能存在数据体量比拟大的场景，通常就是采纳分片算法加线程池并发解决的策略，然而前提也要优化好数据查问和工作解决流程，从整体上晋升工作的执行效率；
六、数据存储
【集成模式】
以 MySQL 为代表的数据存储是零碎中最外围的一层，其集成的模式也是灵便多变，与存储层相干的组件更是形形色色；
多服务共用数据库 ：对于 模式一 来说，在绝对简略的零碎中比拟罕用，或者服务和数据库自身偏差通用的性能性质，能够采纳这种策略；
服务和库的拆分 ： 模式二 是分布式架构中最罕用的设计，每个服务都具备本人相应的独立数据库，其余服务想要拜访必须通过调用相应服务提供的接口才能够；
多数据源模式 ：在一个服务内集成多个数据源，像 模式三 读写拆散和 模式四 分库分表，这是偏数据服务的业务场景中常常应用的模式；
对于零碎中的数据源治理自身就是一件简单的事件，须要兼顾各个方面，比方数据读写性能，数据安全，以及服务的稳定性等；
【利用形式】
在惯例的微服务工程中，通常每个服务都会应用各自独立的数据库，在多数据源的集成模式中，罕用的逻辑就是动静路由、读写拆散、分库分表等，如果逻辑简略能够自定义封装，如果逻辑简单能够应用成熟的组件；
服务集成多数据源的模式中，存在一个比拟显著的简单问题，如何在不进行服务的状况下，进行数据源的动静治理，此前实际过的模式：提供不同数据源的适配服务来实现各自的策略，在实现数据源的动静调整后，进行其中旧服务即可，尽管流程并重偏简单，然而稳固牢靠；
七、参考源码
编程文档：https://gitee.com/cicadasmile/butte-java-note
利用仓库：https://gitee.com/cicadasmile/butte-flyer-parent
