Kirago
Stay hungry Stay foolish!!

Prometheus 入门及进阶

欢迎大家订阅本人维护的微信公众号或者今日头条头条号,第一时间获取分享:)。 Warning!!!内容较多备好板凳与瓜子矿泉水!! 参考1 参考2 什么是TSDB? TSDB(Time Series Database)时序列数据库,我们可以简单的理解为一个优化后用来处理时间序列数据的软件,并且数据中的数组是由时间进行索引的。 时间序列数据库的特点 大部分时间都是写入操作。 写入操作几乎是顺序添加,大多数时候数据到达后都以时间排序。 写操作很少写入很久之前的数据,也很少更新数据。大多数情况在数据被采集到数秒或者数分钟后就会被写入数据库。 删除操作一般为区块删除,选定开始的历史时间并指定后续的区块。很少单独删除某个时间或者分开的随机时间的数据。 基本数据大,一般超过内存大小。一般选取的只是其一小部分且没有规律,缓存几乎不起任何作用。 读操作是十分典型的升序或者降序的顺序读。 高并发的读操作十分常...
0 9 0 2019-08-16

编译Linux内核源码

此文算是水文一篇了,还是很早以前突发心思搞下 Linux 内核编译时记录的,感觉可装X。。。 欢迎大家订阅本人维护的微信公众号或者今日头条头条号,第一时间获取分享:)。 升级一些依赖包 yum install -y rpm-build redhat-rpm-config asciidoc hmaccalc perl-ExtUtils-Embed pesign xmlto yum install -y audit-libs-devel binutils-devel elfutils-devel elfutils-libelf-develsudo yum install -y ncurses-devel newt-devel numactl-devel pciutils-devel python-devel zlib-devel bison 创建源码的编译书目录及目的源码存放地址 mkdi...
0 8 2 2019-08-16

Kubernetes 使用Prometheus 搭建监控平台

欢迎大家订阅本人维护的微信公众号或者今日头条头条号,第一时间获取分享:)。 转载自阳明老哥技术blog,发现其中有部分问题加上自己实践踩坑 本人维护的yaml配置文件链接 一般情况下我们是直接通过Dashboard的资源统计图标进行观察的,但是很显然如果要上到生产环境,就需要更自动化的方式来对集群、Pod甚至容器进行监控了。Kubernetes内置了一套监控方案:influxdb+grafana+heapster。但由于之前我们的应用的业务监控使用的是Prometheus,所以这里准备使用Prometheus来完成k8s的集群监控。 Prometheus 简介 Prometheus是SoundCloud开源的一款开源软件。它的实现参考了Google内部的监控实现,与源自Google的Kubernetes结合起来非常合适。另外相比influxdb的方案,性能更加突出,而且还内置了报警功能。它...
1 9 0 2019-08-16

Spring Cloud 系列之微服务的容错处理 Hystrix 拓展(八)

Hystrix 线程隔离策略与传播上下文 hystrix 的隔离策略分为两种: THREAD (线程隔离):使用该方式, HystrixCommand 将在单独的线程上执行,并发请求受到线程池中的线程数量的限制。【默认方式,因为此种方式有一个除网络超时以外的保护层】 SEMAPHORE(信号量隔离):使用该方式, HystrixCommand 将在调用线程上执行,开销相对较小,并发请求受到信号量个数的限制。【负载非常高时采用,信号量隔离一般仅适用于非网络调用的隔离】 隔离策略的属性 key 为: execution.isolation.strategy 如果想传播线程本地的上下文到 @HystrixCommand, 默认声明将不会工作,因为 THREAD 是在线程池中执行命令的,但是我们可以通过使用一些配置让 Hystrix 使用相同的线程或者直接在注解中让 Hystrix 使用不同的隔离...
1 10 0 2019-08-08

Spring Cloud 系列之微服务的容错处理 Hystrix(七)

总结前面几篇实际上我们已经经历过了 RestTemplate(restful api 请求构造)、Eureka (服务发现与注册)、Ribbon(负载均衡)、Fegin(声明式Rest)。基础的内容算是有了大概的了解,虽然 demo 例子比较简单,其中也适当了引入了自己对这部分内容的理解与拓展思考。但是仅仅拥有以上的知识栈其实我觉得远远是不够的,肯定是不能够上生产的微服务应用。 此篇的内容实际上就是微服务处理中的高级话题-容错处理。 雪崩效应 在实际的微服务架构中,各个服务之间肯定会存在依赖关系。在生产环境中,对于网络来说可能是脆弱的,那么“基础服务故障”会导致“级联故障”从而引起“雪崩效应”。 如何解决雪崩效应 容错机制是一种普遍采用的方案 容错机制在我理解看来实际上就是一种“预留可用资源”的方案,在应对可能产生雪崩效应的场景下,我们通过及时响应,保证系统资源不要被“无谓的竞争”消耗,从...
1 16 2 2019-08-08

Spring Cloud 系列之声明式 REST 调用(六)

由于在分布式框架处理中,我们对于 Restful 风格的请求可能在实际的场景中会越来越多,对于前面章节的几篇文章,我们是通过字符串拼接的方式构造 URL 的: public User findById(String id) { return this.ribbonRestTemplate.getForObJect("http://microservice-provider-user/+ id, User.class) } 多说一句源码范畴的解释就不在这个系列搞了,有机会和精力另起一系列吧 对于这种构造方式,我觉得肯定是个蛋疼的问题,当然在 Spring Cloud 中有更爽的方式去处理,此篇就是通过 Fegin 实现声明式 REST 调用。 【随机扯淡】在这里会发现 Java 中面向接口编程是真的强,透过抽象一层接口,在接口中规范定义好相关规则,然后直接调用接口而无需去关注内部具...
2 15 0 2019-08-06

Spring Cloud 系列之负载均衡(五)

鉴于章节(四)文章中引入了拓展思考,在很多场景下,我们需要自定义 Ribbon 的配置,此篇主要 demo 示例为修改 Ribbon 的负载均衡策略。 Ribbon 配置自定义 配置自定义可以分为如下两种: 使用 Java 代码自定义 Ribbon 配置,配置指定名称的 Ribbon Client IClientConfig ribbonClientConfig: DefaultClientConfigImpl IRule ribbonRule: ZoneAvoidanceRule IPing ribbonPing: DummyPing ServerList<Server> ribbonServerList: ConfigurationBasedServerList ServerListFilter<Server> ribbonServerListFilter: ZonePreferenc...
2 19 4 2019-08-03

Spring Cloud 系列之负载均衡(四)

通过前几篇章节,初步认识了通过 RestTemplate 调用微服务拆分的服务的 rest 请求,进一步引入了通过 Eureka 来实现服务注册于发现(此部分的拓展内容其实还有很多,牵扯到自定义元数据及 Eureka 的自我保护等)。 那么问题来了,在实际的场景中我们会遇到很多服务端其实是存在多个副本以实现高可用,那么客户端的请求是如何做分发控制的呢?当然,朋友你肯定第一个想到的是老毛子搞的 nginx。Nice!!nginx 确实很强大,基于 nginx 我们能做很多事情【后续我也会对 nginx 做进一步的分享:)】。在 Spring Cloud 生态圈,其实大佬们早已准备好了开箱即用的组件,就是今天的主角:Riboon。 Eureka 与 Ribbon 配合的架构图 服务消费者 microservice-consumer-movie-ribbon 将之前的 microservice-...
4 25 0 2019-08-01

Spring Cloud 系列之服务注册与发现(三)

鉴于上篇内容提出的思考拓展部分,此部门其实就是做了 application.yaml 的配置文件的更改。此篇的 Demo 通过单节点多端口来模拟多节点分布的 Eureka Server HA 集群。由于篇幅比较简单,我就直接将 microservice-discovery-eureka 做了 yaml 配置文件更改最终输出为 microservice-discovery-eureka-ha 的模块,就暂且不实现生产者服务和消费者服务了。 Eureka Server HA microservice-discovery-eureka-ha application.yaml 文件如下: spring: application: name: microserver-discovery-eureka-ha #eureka: # client: # service-url: # ...
2 13 0 2019-08-01

Spring Cloud系列之服务注册与发现(二)

鉴于上篇初识(一)引入如下思考: 如果每个组件的服务分布在不同的节点,那么通过每次的硬编码去实现域名(服务识别)解析是多么痛苦的一件事,况且还没有涉及到服务的主动发现。这个时候我们急需引用一种方案来解决此问题,那么此阶段我将引入 EureKa 的应用。而在 Dubbo 体系中是通过 Zookeeper 集群来实现服务注册与发现的,后续有机会将会对 Dubbo 做学习与分析。:) Eureka 架构 通过架构图我们会发现实际上 Eureka 包含两个组件:Eureka Server 和 Eureka Client,它们的作用如下: Eureka Server 提供服务发现的能力(这种能力个人理解是被动的),即各个微服务启动的时候会主动向 Server 注册自己的信息(例如IP、端口、微服务名称等) Eureka Client 则是一个客户端,与 Eureka Server 进行交互 微服务启...
1 25 2 2019-07-31
文章分组
暂无数据