青衫的博客

本文将会讲述结构性模式中的另外一个常用的模式-组合模式，我们平时在面向对象的设计中，我想有一个原则经常被提及就是，我们在设计的时候，对象组合>类的继承，本篇将会将结合简单的实例来说明这方面的优势，并且完成对组合模式的主题思想的掌握。我们这样来简单的理解组合模式，组合模式就是把一些现有的对象或者元素，经过组合后组成新的对象，新的对象提供内部方法，可以让我们很方便的完成这些元素或者内部对象的访问和操作。我。

本文主要是讲述结构型模式中一个比较常用的模式-外观模式，这个模式呢，有个最大的特点将细粒度的对象包装成粗粒度的对象，应用程序通过访问这个外观对象，来完成细粒度对象的调用，外观模式一般是分布式应用和系统架构中的应用服务层的设计中常用的方式，并且一般结合外观模式+DTO来完成服务层的设计，提供分布式应用服务的高效服务，外观模式我们可以这样理解，我们通过外观的包装，使应用程序只能看到外观对象，而不会看到具体的细节对象，这样无疑会降低应用程序的复杂度，并且提高了程序的可维护性。

本文主要是讲述创建型模式中一个比较特殊的模式-原型模式，这个模式呢，有个最大的特点是克隆一个现有的对象，这个克隆的结果有2种，一种是是浅复制，另一种是深复制，这里我们也会探讨下深复制和浅复制的原理，这样可能更方便大家理解这个原型模式的使用。我们都知道，创建型模式一般是用来创建一个新的对象，然后我们使用这个对象完成一些对象的操作，我们通过原型模式可以快速的创建一个对象而不需要提供专门的new()操作就可以快速完成对象的创建，这无疑是一种非常有效的方式，快速的创建一个新的对象。

本文主要是针对创建型模式中的创建者模式进行讲述，创建者模式是创建型模式中最负责的一个设计模式了，创建者负责构建一个对象的各个部分，并且完成组装的过程，我们可以这么理解创建者模式，创建者模式类似与一个步骤基本固定，但是每个步骤中的具体形式却又可以变化的这类对象的创建。也许这样说还是太抽象了，我们这么来理解吧，我感觉让人最容易理解的形式还是图形化的形式，不但接受起来容易，并且让人映象深刻，不知道大家是不是和我有同感呢？

本文主要是针对创建型模式中的抽象工厂模式进行讲述，抽象工厂模式是在简单工厂模式的基础上扩展而成的新模式，将简单工厂中的对象的创建过程进行了很优雅的动态配置来完成无缝的扩展，当然通过一些扩展，可以构建出可支持动态新增或者删除对象的抽象工厂模式。本文将会给出具体的实现方案，相比工厂模式，抽象工厂模式是一个工厂负责多个对象的创建，返回的具体的类型是这个对象的抽象类型。这样，在客户端引用的时候只需要使用这个工厂返回的对象类型，抽象工厂会自动根据对象的类型动态的创建这个类型对象的实例。

本文将会主要是结合项目中的一些实例作为实例来分析工程模式的使用方式和何时使用工程模式，并且分析工程模式的有点和它解决的问题，在我们实际的项目中何时能使用到它，或者说我们在什么情况下，应该考虑使用工厂模式来解决项目中的问题，一般情况下我们可以这样理解设计模式，设计模式是一种方案，为我们遇到与设计模式提出的应用场景想象或者相仿的场景中，这类问题通常是经常发生或者是经常遇到的问题的通用解决方案。本文依然是采用图文讲解的形式来分析工程模式在项目中出现的位置，并且给出几个灵活的实现方案。

园子里面有太多优秀的设计模式文章了，但是可能每个人的出发角度和关注点不同，可能会对每个模式理解的角度和切面不同，我想以我自己理解的方式来跟大家共同探讨下常用的设计模式，并且我会结合工作中的开发实际场景来说明每个模式的用法和特点，希望能对大家有所帮助，当然这些内容都是个人在实际项目中的总结和实践，错误或者理解有误之处，还请大家多多指正，多谢大家前来交流！

本文将主要讲解创建型模式中的单例模式先来讲解，因为单例模式是最简单也是最容易理解的设计模式，上手快，易使用的设计模式。本文将从下面的流程来讲解单例模式，后面讲述的设计模式也将使用这样的方式。1、什么是单例模式？2、单例模式的应用场景。3、举例说明单例模式的使用。4、总结单例模式的用法。本章我们将来讲述下单例模式的使用，首先我们来看看单例模式的定义：单例模式：是一种软件设计中常用的设计模式，主要是用来控制某个类必须在某个应用程序中只能有一个实例存在。

在前面的文章中，我们已经成功的使用Zipkin收集了项目的调用链日志。但是呢，由于我们收集链路信息时采用的是http请求方式收集的，而且链路信息没有进行保存，ZipkinServer一旦重启后就会所有信息都会消失了。基于性能的考虑，我们可以对它进行改造，使用SpringCloud Stream进行消息传递，使用Elasticsearch进行消息的存储。

Zipkin是SpringCloud官方推荐的一款分布式链路监控的组件，使用它我们可以得知每一个请求所经过的节点以及耗时等信息，并且它对代码无任何侵入，我们先来看一下Zipkin给我们提供的UI界面都是提供了哪些信息。

我们来看一下如何使用它吧。

今天我们来学习一下actuator这个组件，它不是SpringCloud之后才有的，而是SpringBoot的一个starter，Spring Boot Actuator。我们使用SpringCloud的时候需要使用这个组件对应用程序进行监控与管理虽然actuator默认给我们提供了这么多的端点供我们使用，但是为了安全起见，在SpringBoot2.0中它仅仅开放了health和info两个端口，如果想要使用其他的端口就需要我们增加一些配置了，一起来看一下如何使用actuator吧。

怎么样，学会这个以后Leader还会担心你的代码臃肿么。本文出自,转载请保留。

由于Apollo支持的图形化界面相对于我们更加的友好，所以此次我们使用Apollo来做配置中心本篇文章实现了使用Apollo配置了dev和fat两个环境下的属性配置。Apollo官方文档。

先来看一下下方这个图[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-KKzFMT0A-1692921015947)(https://zhixiang.org.cn/usr/local/blogImg/cd704830-4f9f-43a0-a972-d0ae09190687.png)]假如现在我们具有四个微服务，分别是用户、订单、支付、催收微服务，它们的调用方式分别是使用http、restful、thrift、kafka。

Spring Cloud Ribbon是基于Netflix Ribbon实现的一套客户端负载均衡的工具Ribbon是Netflix发布的开源项目，主要功能是提供客户端的软件负载均衡算法和服务调用。Ribbon客户端组件提供一系列完善的配置项如连接超时、重试等。简单的说，就是在配置文件中列出Load Balance（简称LB）后面所有的机器，Ribbon会自动的帮组你基于某种规则（如简单轮询，随机连接等）去连接这些机器，我们很容易使用Ribbon实现自定义的负载均衡算法。

本章使用的Consul版本是 1.7.2。

基于Spring Cloud实现服务的发布与调用。而在18年7月份，Eureka2.0宣布停更了，将不再进行开发，所以对于公司技术选型来说，可能会换用其他方案做注册中心。本章学习便是使用ZooKeeper作为注册中心。本章使用的zookeeper版本是 3.6.0。

既然SpringCloud的是微服务结构，那么对于同一种服务，当然不可能只有一个节点，需要部署多个节点架构图如下：由上可以看出存在多个同一种服务提供者（Service Provider）

Eureka是一项基于REST（代表性状态转移）的服务，主要在AWS云中用于定位服务，以实现负载均衡和中间层服务器的故障转移。我们称此服务为Eureka Server。Eureka还带有一个基于Java的客户端组件Eureka Client，它使与服务的交互更加容易。客户端还具有一个内置的负载均衡器，可以执行基本的循环负载均衡。在Netflix，更复杂的负载均衡器将Eureka包装起来，以基于流量，资源使用，错误条件等多种因素提供加权负载均衡，以提供出色的弹性。服务治理。