consul

Prometheus简介 Prometheus受启发于Google的Brogmon监控系统（相似的Kubernetes是从Google的Brog系统演变而来），从2012年开始由前Google工程师在Soundcloud以开源软件的形式进行研发，并且于2015年早期对外发布早期版本。2016年5月继Kubernetes之后成为第二个正式加入CNCF基金会的项目，同年6月正式发布1.0版本。2017年底发布了基于全新存储层的2.0版本，能更好地与容器平台、云平台配合。 Prometheus简史 Prometheus作为新一代的云原生监控系统，目前已经有超过650+位贡献者参与到Prometheus的研发工作上，并且超过120+项的第三方集成。 监控的目标 在《SRE: Google运维解密》一书中指出，监控系统需要能够有效的支持白盒监控和黑盒监控。通过白盒能够了解其内部的实际运行状态，通过对监控指标的观察能够预判可能出现的问题，从而对潜在的不确定因素进行优化。而黑盒监控，常见的如HTTP探针，TCP探针等，可以在系统或者服务在发生故障时能够快速通知相关的人员进行处理。通过建立完善的监控体系，从而达到以下目的： ***长期趋势分析：***通过对监控样本数据的持续收集和统计，对监控指标进行长期趋势分析。例如，通过对磁盘空间增长率的判断

Eureka\Consul\Zookeeper异同 Eureka由于有自我保护机制，属于AP范畴。 组件名 语言 CAP 服务健康检查 对外暴露接口 SpringCloud集成 Eureka Java AP 可配支持 Http 已集成 Consul Go CP 支持 HTTP/DNS 已集成 Zookeeper Java CP 支持 客户端 已集成 CAP理论参考： http://www.ruanyifeng.com/blog/2018/07/cap.html C: Consistency 强一致性 A： Availability 可用性 P: Partition toterance 分区容错性 CAP理论关注粒度是数据，而不是整体系统设计的策略 CAP理论的核心是：一个分布式系统不可能同时满足一致性，可用性和分区容错性这三个需求，因此根据CAP原理将NoSQL数据库分成了满足CA原则，满足CP原则和满足AP原则三大类 CA 单点集群，满足一致性，可用性的系统，通常在可扩展上不太强大 CP 满足一致性，分区容错性的系统，通常性能不是特别高 AP 满足可用性，分区容错性的系统，通常可能对一致性要求低一些。 来源： oschina 链接： https://my.oschina.net/u/1020373/blog/4767804

好长时间没发文了，最近着实是有点忙，当爹的第 43 天，身心疲惫。这又赶上年底，公司冲 KPI 强制技术部加班到十点，晚上孩子隔两三个小时一醒，基本没睡囫囵觉的机会，天天处于迷糊的状态，孩子还时不时起一些奇奇怪怪的疹子，总让人担惊受怕的。 本就不多的写文章时间又被无限分割，哎~ 打工人真是太难了。 本来不知道写点啥，正好手头有个新项目试着用阿里的 Seata 中间件做分布式事务，那就做一个实践分享吧！ 介绍 Seata 之前在简单回顾一下分布式事务的基本概念。 分布式事务的产生 我们先看看百度上对于分布式事务的定义：分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。 额~ 有点抽象，简单的画个图好理解一下，拿下单减库存、扣余额来说举例： 当系统的体量很小时，单体架构完全可以满足现有业务需求，所有的业务共用一个数据库，整个下单流程或许只用在一个方法里同一个事务下操作数据库即可。此时做到所有操作要么全部提交 或 要么全部回滚很容易。 分库分表、SOA 可随着业务量的不断增长，单体架构渐渐扛不住巨大的流量，此时就需要对数据库、表做 分库分表 处理，将应用 SOA 服务化拆分。也就产生了订单中心、用户中心、库存中心等，由此带来的问题就是业务间相互隔离，每个业务都维护着自己的数据库，数据的交换只能进行 RPC 调用。

哪种服务网格最适合你的企业?近年来，Kubernetes服务网格框架数量增加迅速，使得这成为一个棘手的问题。 下面将介绍9种较受欢迎的用以支撑微服务开发的服务网格框架，每种方案都给出了其适用场景。 什么是服务网格 服务网格近年来有很高的话题度，背后的原因是什么? 微服务已经成为一种灵活快速的开发方式。然而，随着微服务数量成倍数地增长，开发团队开始遇到了部署和扩展性上的问题。 容器和Kubernetes这样的容器编排系统 ，将运行时和服务一起打包进镜像，调度容器到合适的节点，运行容器。这个方案可以解决开发团队遇到的不少问题。然而，在这个操作流程中仍存在短板：如何管理服务间的通信。 在采用服务网格的场景下，以一种和应用代码解耦的方式，增强了应用间统一的网络通信能力。服务网格扩展了集群的管理能力，增强可观测性、服务发现、负载均衡、IT运维监控及应用故障恢复等功能。 服务网格概览 服务网格一直有很高的热度。正如Linkerd的作者William Morgan所提到的：“服务网格本质上无非就是和应用捆绑在一起的用户空间代理。” 此说法相当简洁，他还补充道，“如果你能透过噪音看清本质，服务网格能给你带来实实在在的重要价值。” Envoy是许多服务网格框架的核心组件，是一个通用的开源代理，常被用于Pod内的sidecar以拦截流量。也有服务网格使用另外的代理方案。 若论具体服务网格方案的普及程度

前言 最近参加了几场 Java 面试，发现大多数的微服务实践还是 Eureka 偏多，鉴于笔者的单位选型 Consul，这里对 Consul 做简单总结。 该篇是 Docker 实战系列的第三篇。传送门: Docker 实战之 MySQL 主从复制 Docker 实战之 Redis-Cluster 集群 为什么选 Consul？ 首先 Consul 有以下几个关键特性: 服务发现：支持服务发现。你可以通过 DNS 或 HTTP 的方式获取服务信息。 健康检查：支持健康检查。可以提供与给定服务相关联的任何数量的健康检查（如 web 状态码或 cpu 使用率）。 K/V 存储：键/值对存储。你可用通过 consul 存储如动态配置之类的相关信息。 多数据中心：支持多数据中心，开箱即用。 WEB-UI：支持 WEB-UI。点点点，你就能够了解你的服务现在的运行情况，一目了然，对开发运维是非常友好的。 作为高频的提问方式，面试官永远从十万个为什么开始。但是最为程序员，还是需要 知其然，知其所以然 。以下是几个常用的服务发现组件的对比。 服务发现组件的选型主要从以下几个方面进行。CAP 理论、一致性算法、多数据中心、健康检查、是否支持 k8s 等。 1. CAP 一致性的强制数据统一要求，必然会导致在更新数据时部分节点处于被锁定状态，此时不可对外提供服务，影响了服务的可用性。 2.

容器网络 在前面的博客中已经详细讲解了几种网络方案： none, host, bridge,user-defined。但是他们只是解决了单个主机间的容器的通信问题，并不能实现多个主机容器之间的通信。本篇博客将详细介绍如何实现该功能。 跨主机网络方案包括两大类： docker原生的：overlay和macvlan 第三方方案：flannel、weave和calico 本篇博客将详细讲解overlay以及weave两种方案。 overlay Docerk overlay 网络需要一个 key-value 数据库用于保存网络状态信息，包括 Network、Endpoint、IP 等。Consul、Etcd 和 ZooKeeper 都是 Docker 支持的 key-vlaue 软件，我们这里使用 Consul。 在 docker 主机 host1（172.20.10.2）和 host2（172.20.10.7）上实践各种跨主机网络方案，在 172.20.10.2 上部署支持的组件，比如 Consul。 第一步：启动路由转发功能 两台主机上面都需要开启 [root@ken3 ~]# echo " 1 " > /proc/sys/net/ipv4/ip_forward 第二步：运行consul 最简单的方式是以容器方式运行 Consul： [root@ken1 ~]# docker run

一、了解 二、下载和安装 1、下载 2、安装 三、使用 一、了解 Consul 是一个支持多数据中心分布式高可用的服务发现和配置共享的服务软件。 默认端口号是： 8500 二、下载和安装 1、下载 1）、百度搜索 consul ，点开第一个。 2）、点击 Download 下载 3）、根据自己的 win 版本下载，我的是 64bit 2、安装 把下载的文件 解压 出来，根据自己的情况选择路径。我把 consul.exe 放在 D:\soft\consul\consul.exe 三、使用 1、 win + r ，输入 cmd , 然后 回车 2、切换到 d 盘： d: ， 回车 3、指定到目录 cd D:\soft\consul 4、启动命令 .\consul.exe agent -dev ； 访问地址为： http://localhost:8500 或 http://127.0.0.1:8500 5、指定IP访问 .\consul.exe agent -dev -client 192.168.3.10 ； 访问地址为： 192.168.3.10:8500 来源： oschina 链接： https://my.oschina.net/u/4321696/blog/4715699

1，istio 概念 1.2 istio 是什么？ 使用云平台可以为组织提供丰富的好处。然而，不可否认的是，采用云可能会给 DevOps 团队带来压力。开发人员必须使用微服务已满足应用的可移植性，同时运营商管理了极其庞大的混合和多云部署。istio允许你连接、保护、控制和观测服务。 在较高的层次上，istio 有助于降低这些部署的复杂性，并减轻开发团队的压力。它是一个完全开源的服务网络，可以透明地分层到现有的分布式应用程序上。它也是一个平台，包括允许它集成到任何日志记录平台、遥测或策略系统的API。istio 的多样化功能集使您能够成功高效地运行分布式微服务架构，并提供保护、连接和监控微服务的统一方法。 1.3 什么是服务网络？ 在从单位应用程序向分布式微服务架构的转型过程中，开发人员和运维人员面临诸多挑战，使用 istio 可以解决这些问题。 服务网路（Service Mesh）这个术语通常用于描述构成这些应用程序的微服务网路以及应用之间的交互。随着规模和复杂性的增长，服务网路越来越难以理解和管理。它的需求包括服务发现、负载均衡、故障恢复、指标收集和监控以及通常更加复杂的运维需求，例如 A/B 测试、金丝雀发布、限流、访问控制和端到端认证等。 istio 提供了一个完整的解决方案，通过为服务网络提供行为洞察和操作控制来满足微服务应用程序的多样化需求。 1.4 为什么要使用