Devil的个人博客

设计模式–结构型模式之桥接模式 将抽象部分与它的实现部分解耦，使得两个都能够独立变化 1 概述 推荐一读的概述 毛笔和蜡笔是两种很常见的文具，它们都归属于画笔。假设需要大、中、小 3 种型号的画笔，能够绘制 12 种不同的颜色，如果使用蜡笔，需要准备 3 × 12 = 36 支，但是如果使用毛笔，只需要提供 3 种型号的毛笔，外加一个包含 12 种颜色的调色板，涉及的对象个数仅为 3 + 12 = 15，远小于 36 ，却能够实现 36 支蜡笔同样的功能。如果增加一种新型号的画笔，并且也需要具有 12 种颜色，对应的蜡笔需要增加 12 支，而毛笔只需要增加 1 支。 不难得知，在蜡笔中，颜色和型号两个不同的变化维度耦合在一起，无论是对颜色进行扩展还是对型号进行扩展势必会影响另一个维度；但在毛笔中，颜色和型号实现了分离，增加新的颜色或者型号对另一方没有任何影响。如果使用软件工程中的术语，可以认为在蜡笔中颜色和型号之间存在较强的耦合性，而毛笔很好地将二者解耦，使用起来更加的灵活，扩展也更为方便。在软件开发中有一种设计模式可以用来处理与画笔类似的具有多变化维度的情况， ...

设计模式–结构型设计模式之适配器模式 将一个类的接口转换成客户希望的另一个接口。该模式让接口不兼容的类可以一起工作 一、前言1）概述​ 在现实生活中，经常出现两个对象因接口不兼容而不能在一起工作的实例，这时需要第三者进行适配。例如，讲中文的人同讲英文的人对话时需要一个翻译，用直流电的笔记本电脑接交流电源时需要一个电源适配器，用计算机访问照相机的 SD 内存卡时需要一个读卡器等。还有像下面这张图一样： ​ 在软件设计中也可能出现： 需要开发的具有某种业务功能的组件在现有的组件库中已经存在，但它们与当前系统的接口规范不兼容，如果重新开发这些组件成本又很高，这时用适配器模式能很好地解决这些问题。 如果想增加现有组件的复用率也可以使用适配器模式。 2）介绍适配器模式（Adapter）的定义如下：将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类能一起工作。适配器模式分为类结构型模式和对象结构型模式两种，前者类之间的耦合度比后者高，且要求程序员了解现有组件库中的相关组件的内部结构，所以应用相对较少些。 Adapter模式的 ...

Spring Boot Actuator在企业级应用中，学习了如何进行SpringBoot应用的功能开发，以及如何写单元测试、集成测试等还是不够的。在实际的软件开发中还需要：应用程序的监控和管理。SpringBoot的Actuator模块实现了应用的监控与管理。这样的需求在分布式服务中基本是必须的，项目上线后的监控也是如此 简介生产系统中，往往需要对系统实际运行的情况（例如cpu、io、disk、db、业务功能等指标）进行监控运维。在SpringBoot项目中Actuator模块提供了众多HTTP接口端点（Endpoint），来提供应用程序运行时的内部状态信息。 Actuator模块提供了一个监控和管理生产环境的模块，可以使用http、jmx、ssh、telnet等来管理和监控应用。包括应用的审计（Auditing）、健康（health）状态信息、数据采集（metrics gathering）统计等监控运维的功能。同时，提供了可以扩展 Actuator端点（Endpoint）自定义监控指标。这些指标都是以JSON接口数据的方式呈现。 使用使用Spring Boot Actuator需要 ...

Linux 教程 | 菜鸟教程 (runoob.com)

Spring Cloud-Nacos认识NacosNacos 是阿里巴巴的产品，现在是 SpringCloud 中的一个组件。相比 Eureka 功能更加丰富，在国内受欢迎程度较高。 Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service的首字母简称，一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。 服务（Service）是 Nacos 世界的一等公民。Nacos 支持几乎所有猪流类型的“服务”的发现、配置、管理： Kubernetes Service gRPC & Dubbo RPC Service Spring Cloud RESTful Service Nacos 的关键特性包括: 服务发现和服务健康监测 Nacos 支持基于 DNS 和基于 RPC 的服务发现。服务提供者使用 原生SDK、OpenAPI、或一个独立的Agent TODO注册 Service 后，服务消费者可以使用DNS TODO 或HTTP&API查找和发现服务。 Nacos 提供对服务的实时的健康检查 ...

Spring Cloud-Sleuth引言在微服务框架中，一个由客户端发起的请求在后端系统中会经果多个不同的服务节点调用来协同产生最后的请求结果，每一个前端请求都会形成一条复杂的分布式服务调用链路，链路中的任何一环出现高延时或者错误都会引起整个请求最后的失败。因此，就需要一些能够帮助理解系统行为、分析系统性能问题的工具， 以便在系统发生故障的时候，快速定位和解决问题。这些工具就是APM（Application Performance Management） 复杂的分布式服务调用链路 简介Spring Cloud Sleuth 能够跟踪你的请求和消息，以便你可以将该通信与相应的日志条目相关联。 你还可以将跟踪信息导出到外部系统以可视化延迟。 Spring Cloud Sleuth提供了一套完整的服务跟踪的解决方案 在分布式系统中提供追踪解决方案并且兼容支持了zipkin。 通过Seuth产生的调用链监控信息，可以得知微服务之间的调用链路，但监控信息只输出到控制台不方便查看。我们需要一个图形化的工具zipkin。Zipkin是Twitter开源的分布式跟踪系统，主要用来收集系统的时许数 ...

Spring Cloud Stream引言为什么要引入Spring Cloud Stream？ 如今市场上有着4大流行的 MQ （消息中间件）如：ActiveMQ、RabbitMQ、RocketMQ、Kafka。在不同系统中可能使用的消息中间件不同，这就需要程序员对每种的消息中间件去掌握，如果每一种消息中间件都去掌握的话，是一件费时又费力的事情，而且还要涉及到消息中间件的切换，维护，和开发。 有没有一种新的技术诞生？ 让我们不再关注具体 MQ 的细节，我们只需要用一种适配绑定的方式，自动的给我们在各种 MQ 内切换。（类似于JDBC） Spring Cloud Stream 响应诞生，它是屏蔽底层消息中间件的差异，降低切换成本，统一消息的编程模型。 简介官方定义 Spring Cloud Stream 是一个构建消息驱动微服务的框架。 应用程序通过 inputs 或者 outputs 来与 Spring Cloud Stream 中 binder 对象交互。 通过我们配置来binding（绑定），而Spring Cloud Stream 的 binder 对象负责于消息中间件交互。 所 ...

Eureka 注：Eureka中各个节点都是平等的，没有ZK中角色的概念，即使N-1个节点挂掉也不会影响其他节点的正常运行。 虽然Eureka已经停止维护了，但是并不代表我们不去学习它，理解它的思想也是后来为学习其他注册中心打下基础。 以下所有Demo都是基于上述入门案例改编。 服务调用出现的问题 服务消费者该如何获取服务提供者的地址信息？ 如果有多个服务提供者，消费者该如何选择？ 消费者如何得知服务提供者的健康状态？ 服务治理Spring Cloud封装NetFlix公司开发的Eureka模块来实现服务治理 那么什么事服务治理呢？ 当服务较少的时候，可能我们根本不需要什么所谓的服务治理，会觉得这不就是中间商赚差价吗，为什么我能直接调用还要再中间加个服务治理呢？其实啊在传统的RPC框架中当服务多到一定程度时，管理每个服务与服务之间依赖关系比较复杂，管理比较复杂，所以需要使用服务治理，管理服务与服务之间的依赖关系，可以实现服务调用，负载均衡，熔断等，实现服务的注册与发现。 服务注册/发现Eureka采用了C/S的设计架构，Eureka Server作为服务注册功能的服 ...

RabbitMQ基本概念**MQ**全称 Message Queue（消息队列）,是在消息传输过程中保存消息的容器。多用于分布式系统之间进行通信。 分布式系统通信两种方式：直接远程调用 和 借助第三方完成间接通信 发送方称为生产者，接收方称为消费者 MQ的优势与劣势优势 应用解耦 异步提速 削峰填谷 劣势 系统可用性降低 系统复杂度提高 一致性问题 MQ的优势应用解耦 系统的耦合性越高，容错性就越低，可维护性就越低。 有了MQ服务订单服务不需要集成库存服务、支付系统、物流系统或者其他系统，而是将系统全部解耦，拆分成不同的分布式微服务。微服务们通过监听MQ的信息，获取到符合的消息，然后消费。解耦也避免了某一个服务无法使用导致的整个系统崩溃问题。 同时多个服务耦合在一起也比解耦成单个服务的维护好做的多。 使用MQ使得应用间解耦，提升容错性和可维护性。 异步提速 如果不适用MQ服务就必须等待服务远程调用到返回结果在响应。但是使用了MQ我们只需要将消息放入MQ中即可返回响应，分布式的系统只需要监听MQ，消费其中的消息即可。 用户点击完下单按钮后，只需等待25ms就能得到下单响 ...

Spring Cloud-Bus前言由Spring Cloud Config我们知道单单靠它之能实现手动的分布式微服务配置的动态刷新，但这依然够大部分项目的使用。如果想要提高灵活度，让配置更加方便的更新就需要引入我们的消息总线了—–Spring Cloud Bus 简介Spring Cloud Bus 配合 Spring Cloud Config使用可以真正意义上实现分布式微服务配置的自动动态刷新。 Spring Cloud-Bus 支持两种消息代理：RibbitMQ和Kafka 利用消息总线触发一个客户端 /busrefresh ，而刷新所有的 Config 客户端的配置，如下图： Spring Cloud Bus是用来将分布式系统的节点与轻量级消息系统链接起来的框架，它整合了Java的事件处理机制和消息中间件的功能。Spring Cloud Bus目前支持RabbitMQ和Kafka。 能干什么？Spring Cloud Bus能管理和传播分布式系统间的消息，就像一个分布式执行器，可用于广播状态更改、事件推送等，也可以当作微服务间的通信通道。 利用消息总线触发一个 ...