Browsed by
日期:2020年6月8日

Logstash下字段以及嵌套Json字段类型转换

Logstash下字段以及嵌套Json字段类型转换

閱讀本文約花費: 2 (分鐘)前言 从filebeat传输到Logstash的数据,某个字段需要由string类型装换成float类型。但是不管怎么改logstash的配置文件都不生效,其实官方文档都有,但是具体细节方面的东西就得自己不断的实践验证最后达到自己想要的目标了。整整一天,都在弄这一个,中间实在想放弃了。但是就如张靓颖的“终于等到你,还好没放弃”,最后在某一篇博文得到了启发,才解决。 这里类型转换分两个类型: 1)字段是单纯的字段,也就是直接在_source下的 2)字段是在json里的,在_source下还有嵌套一层json里的字段 一、单一字段 可以从下面的图中看出,字段就在顶层机构_source下,这种情况下的Logstash配置文件设置如下: filter { mutate { convert => { “request_time” => “float” } convert => { “upstream_response_time” => “float” } } } 二、嵌套Json下的字段 如果需要转换的字段是在非顶级结构下,是在一个JSON里,因为在filebeat做decode的时候指定了,如我需要转换的字段是在jsonn的json字段里: processors: – decode_json_fields: fields: [“mes…

Read More Read More

微服务网关 | Zuul1.0和2.0我们该如何选择?

微服务网关 | Zuul1.0和2.0我们该如何选择?

閱讀本文約花費: 12 (分鐘) 文章介绍了Zuul1、Zuul2,同步阻塞模式,异步非阻塞模式,编程模型和优劣,希望对大家的学习有所帮助。 在今年 5 月中,Netflix 终于开源了它的支持异步调用模式的 Zuul 网关 2.0 版本,真可谓千呼万唤始出来。从 Netflix 的官方博文 [附录 1] 中,我们获得的信息也比较令人振奋: The Cloud Gateway team at Netflix runs and operates more than 80 clusters of Zuul 2, sending traffic to about 100 (and growing) backend service clusters which amounts to more than 1 million requests per second. Netflix 部署了超过 80+ 的 Zuul2 云网关集群,流量经过 Zuul2 集群被路由到后端超过 100+ 的微服务,且每秒钟经过 Zuul2 集群的请求超过 100 万。 Zuul2 看起来很强大,支持异步高并发 (Zuul1 仅支持同步) 特性看起来很亮眼,那么我们是否就应该抛弃 Zuul1,开始拥抱 Zuul2 呢?作为架构师,我们不能盲目追时髦,技术的选择必须基于实践和理性的分析,基于我之前对 Zuul1 的一线…

Read More Read More

微服务写的最全的一篇文章

微服务写的最全的一篇文章

閱讀本文約花費: 14 (分鐘) 本文来自于网络,本文主要讲解的是微服务,详细阐述了微服务的利弊、服务分层、微服务的服务发现的三种方式微服务的路由发现体系等相关知识。 今年有人提出了2018年微服务将疯狂至死,可见微服务的争论从未停止过。在这我将自己对微服务的理解整理了一下,希望对大家有所帮助。 1.什么是微服务 1)一组小的服务(大小没有特别的标准,只要同一团队的工程师理解服务的标识一致即可) 2)独立的进程(java的tomcat,nodejs等) 3)轻量级的通信(不是soap,是http协议) 4)基于业务能力(类似用户服务,商品服务等等) 5)独立部署(迭代速度快) 6)无集中式管理(无须统一技术栈,可以根据不同的服务或者团队进行灵活选择) ps:微服务的先行者Netflix公司,开源了一些好的微服务框架,后续会有介绍。 2. 怎么权衡微服务的利于弊 利: 强模块边界 。(模块化的演化过程:类–>组件/类库(sdk)–>服务(service),方式越来越灵活) 可独立部署。 技术多样性。 弊: 分布式复杂性。 最终一致性。(各个服务的团队,数据也是分散式治理,会出现不一致的问题) 运维复杂性。 测试复杂性。 3. 企业在什么时候考虑引入微服务 从生产力和系统的复杂性这两个方面来看。公司一开始的时候,业务复杂性不高,这时候是验证商业模式的…

Read More Read More

K8S基础概念

K8S基础概念

閱讀本文約花費: 9 (分鐘)一、核心概念 1、Node Node作为集群中的工作节点,运行真正的应用程序,在Node上Kubernetes管理的最小运行单元是Pod。Node上运行着Kubernetes的Kubelet、kube-proxy服务进程,这些服务进程负责Pod的创建、启动、监控、重启、销毁、以及实现软件模式的负载均衡。 Node包含的信息: Node地址:主机的IP地址,或Node ID。 Node的运行状态:Pending、Running、Terminated三种状态。 Node Condition:… Node系统容量:描述Node可用的系统资源,包括CPU、内存、最大可调度Pod数量等。 其他:内核版本号、Kubernetes版本等。 查看Node信息: 2、Pod Pod是Kubernetes最基本的操作单元,包含一个或多个紧密相关的容器,一个Pod可以被一个容器化的环境看作应用层的“逻辑宿主机”;一个Pod中的多个容器应用通常是紧密耦合的,Pod在Node上被创建、启动或者销毁;每个Pod里运行着一个特殊的被称之为Pause的容器,其他容器则为业务容器,这些业务容器共享Pause容器的网络栈和Volume挂载卷,因此他们之间通信和数据交换更为高效,在设计时我们可以充分利用这一特性将一组密切相关的服务进程放入同一个Pod中。 同一个Pod里的容器之间仅需通过l…

Read More Read More