暂时未有相关云产品技术能力~
暂无个人介绍
拷贝对象是很常见的,主要是为了在新的上下文环境中复用现有对象的部分或全部数据。
外观模式(又称门面模式),通过外观的包装,使应用程序只能看到外观对象,而不会看到具体的细节对象,这样无疑会降低应用程序的复杂度,并且提高了程序的可维护性。
桥接模式是将抽象部分与它的实现部分分离,使它们都可以独立地变化,而不会直接影响到其他部分。是一种对象结构型模式,又称接口(interface)模式。
命令模式:请求以命令的形式包裹在对象中,并传给调用对象。调用对象寻找可以处理该命令的合适的对象,并把该命令传给相应的对象,该对象执行命令。
用原型实例指定创建对象的种类,并且通过拷贝这些原型创建新的对象。大概意思就是:允许一个对象再创建另外一个可定制的对象,根本无需知道对象创建的细节。
建造者模式,将其构建对象和组装成一个对象这两步给分开来。构建部分为(Builder)和组织部分(Director),实现了构建和装配的解耦。
装饰模式指的是在不必改变原类文件和使用继承的情况下,动态地扩展一个对象的功能。它是通过创建一个包装对象,也就是装饰来包裹真实的对象。
迭代器模式(Iterator),提供一种方法顺序访问一个聚合对象中的各种元素,而又不暴露该对象的内部表示。
凡事都有例外,就是设计新系统的时候考虑使用第三方组件,因为没必要为了迎合第三方组件修改自己的软件设计风格,可以尝试使用适配器模式。
今天分享一道算法题,关于两个长字符串数字相加。
默认http_image_filter_module模块是不会编译进nginx的,所以要在configure时候指定编译http_image_filter_module模块。另外http_image_filter_module模块需要依赖gd-devel的支持,可以使用yum install gd-devel先安装,如果未安装会报“/configure: error: the HTTP image filter module requires the GD library.”错误。
HTTP数据传输时没有对数据进行加密,所以导致数据不安全。而HTTPS在HTTP上加了一层,对数据进行加密,这样就保证了数据的安全性。防止传输的数据过程中被不法分子盗用、劫持、篡改,而导致数据信息的泄露。
随着应用服务的增多,服务可能部署在不同的服务器上。这些服务有可能存在IP、端口Port、请求的ContextPath等一样的情况,怎么合理的配置他们的跳转呢?下面介绍三种常见的跳转方式。
ngx_http_secure_link_module模块用于检查请求链接的真伪,保护资源免受未经授权的访问,限制链接的生命周期。
nginx_upstream_check_module为淘宝技术团队开发的nginx模块,用来检测后方server的健康状态,如果后端服务器不可用,则请求不再转发到这台服务器。
根据主机列表和端口定义列表批量查询服务器上开启的端口并保存到日志里,命名规则为IP_port.log。
本篇内容记录了nginx负载均衡代理配置脚本的相关代码。
查看nginx软件包里的auto文件夹里的option文件,带YES的表示默认安装时候自带的模块. 这些模块使用-V是查看不到的.
Apollo(阿波罗)是携程框架部门研发的分布式配置中心,能够集中化管理应用不同环境、不同集群的配置,配置修改后能够实时推送到应用端,并且具备规范的权限、流程治理等特性,适用于微服务配置管理场景。
APISIX是基于云原生的微服务API网关,它是所有业务流量的入口,可以处理传统的南北向流量(server-client),也可以处理服务间的东西向流量(server-server),也可以当做 k8s ingress controller 来使用。
今天讲解一下如何在微服务中引入Zipkin Client,然后结合Zipkin Server监控各微服务间的调用链路。
Zipkin是一个开放源代码分布式的跟踪系统,它提供了在分布式环境下发送、接收、存储和可视化跟踪的机制。这使我们能够对服务之间的活动进行关联,并更清楚地了解我们服务中发生的情况。
网关zuul配置的最后一种方式给微服务名指定path,这种方式也是zuul默认时,内置的方式。
这一篇讲解一下path-serviceId这种转发方式。path-serviceId这种方式需要使用到注册中心eureka
为了解决请求路由和安全过滤,Spring Cloud推出了一个API gateway组件:Spring Cloud Zuul。
模板引擎根据一定的语义,将数据填充到模板中,产生最终的HTML页面。模板引擎主要分两种:客户端引擎和服务端引擎。
最早期使用JavaMail的相关api来进行发送邮件的功能开发,后来spring整合了JavaMail的相关api推出了JavaMailSender更加简化了邮件发送的代码编写,现在springboot对此进行了封装就有了现在的spring-boot-starter-mail。
目前使用较多的消息队列有ActiveMQ、RabbitMQ、Kafka、RocketMQ、MetaMQ等。spring boot提供了对JMS系统的支持;springboot很方便就可以集成这些消息中间件。
spring支持多种定时任务的实现,今天介绍一下spring定时器和quartz定时器的使用。
springboot 中自带的页面渲染工具为thymeleaf ,freemarker这种模板引擎用的也比较多。
本文将结合之前学习的注册中心Eureka、服务提供者Provider、断路器Hystrix和仪表盘Dashboard,学习断路器集群监控Turbine。
今天结合数据库操作和reids操作,来看看如何使用SpringCache。SpringCache提供了基于注解的缓存配置方法。它本质上不是一个具体的缓存实现方案(例如EHCache),而是一个对缓存使用的抽象和封装,通过在已有代码中打上几个预定义的注释,就可以实现希望达到的缓存效果。
HttpSession是通过Servlet容器创建和管理的,像Tomcat/Jetty都是保存在内存中的。但是把应用搭建成分布式的集群,然后利用F5、LVS或Nginx做负载均衡,那么来自同一用户的Http请求将有可能被分发到多个不同的服务器中。
这篇讲解一下如何使用 spring-boot-starter-test进行单元测试。
Redis是一种nosql数据库,以键值对<key,value>的形式存储数据,其速度相比于MySQL之类的数据库,相当于内存读写与硬盘读写的差别,所以常常用作缓存,用于少写多读的场景下,直接从缓存拿数据比从数据库(数据库要I/O操作)拿要快得多。
比如说代码改了,但是接口文档还没来得及修改等问题,而Swagger2则给我们提供了一套完美的解决方案,下面来看看Swagger2是如何来解决这个问题的。
本篇讲解一下Feign如何整合断路器监控Hystrix Dashboard。本篇主要整合sc-eureka-client-consumer-feign-hystrix项目和sc-hystrix-dashboard项目。
今天的项目主要整合sc-eureka-client-consumer-ribbon-hystrix项目和sc-hystrix-dashboard项目
Hystrix Dashboard作为断路器监控的一个重要组件,提供了数据监控及非常友好的图形化界面,方便运维人员对服务进行监控;,通过界面反馈的信息可以快速发现系统中存在的问题。另外Hystrix Dashboard是一个独立的服务结点,不需要配置任何的注册中心。
这篇来看看如何Feign整合断路器Hystrix,Feign整合断路器Hystrix也是相对比较简单的。Feign默认已经自带断路器Hystrix,所以不需要像RestTemplate+Ribbon整合断路器Hystrix那样需要在SpringBoot的启动类添加注解。但是Feign自带断路器并没有打开,需要做些额外的配置。
当对某个服务的调用的不可用达到一个阀值(Hystric 默认是5秒20次) 断路器将会被自动被打开。断路打开后, fallback方法可以直接返回一个预先设置的固定值。
今天看看如何实现服务提供者使用配置中心的配置文件。
logback-access访问模块与Servlet容器集成提供通过Http来访问日志的功能。 Logback是要与SLF4J结合起来用的。
Feign :spring cloud feign 是一个使用起来更加方便的 HTTP 客戶端。 在使用ribbon时,通常会使用RestTemplate实现对http请求的封装,形成了模板化的调用方法。
这篇说下服务发现(服务消费者),通常服务消费者是部署在与互联网联通的服务器上,提供restful接口给H5和App调用。
本篇将和大家看看如何编写一个Config Client从Config Server获取配置。
本篇内容学习springcloud整合mybatis注解方式。
服务提供者(Service Provider):是指服务的被调用方(即:为其它服务提供服务的服务);服务提供者,作为一个Eureka Client,向Eureka Server做服务注册、续约和下线等操作,注册的主要数据包括服务名、机器ip、端口号、域名等等。
spring cloud config可以实现微服务中的所有系统的配置文件的统一管理,而且还可以实现当配置文件发生变化的时候,系统会自动更新获取新的配置。
Eureka作为spring cloud的服务发现与注册中心,在整个的微服务体系中,处于核心位置。Eureka通过“伙伴机制”实现高可用。每一台Eureka都需要在配置中指定另外两个Eureka的地址伙伴,Eureka启动时会向自己的伙伴节点获取当前已经存在的注册表,这样在向Eureka集群中新加机器时就不需要担心注册表的不完整。