consul

发现&配置中心选型 2020-06-08 配置中心产品功能对比 功能 spring cloud config apollo nacos consul 管理端配置管理 自己开发基于gitlab管理 支持 支持 支持 配置刷新 依赖Git的WebHook<br />Spring Cloud Bus和客户端/bus/refresh http poll http poll http poll 权限控制 依赖gitlab 支持 简单 不支持 灰度发布 依赖destination 不完整 支持 支持 不支持 配置回滚 不支持 支持 支持 不支持 程序支持 java java .net java、go、node、Python、c# 最小依赖 config3 + kafka3 + zk3 + gitlab2 Config 2+Admin 3+Portal*2+Mysql nacos3 + mysql consul server、 agent 厂商 netflix 携程 阿里 HashiCorp 多环境支持 支持 支持 支持 支持 多项目支持 可以支持 支持 支持 可以支持 配置共享 支持 支持 支持 不支持 注册发现功能 无 无 有 有 注册中心对比 Nacos Eureka Consul 一致性协议 CP+AP AP CP 健康检查 TCP/HTTP/MYSQL/Client Beat

云栖号资讯：【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ 面对可能出现的网络延迟，不可预估的请求流量等情况，设计一个分布式系统，我们通常围绕系统高可用，数据一致性的目标去规划和实现，想要完全实现这个目标，却并非易事。由此，分布式系统领域诞生了一个基本定理，即 CAP 定理，用于指导分布式系统的设计，从系统高可用，数据一致性，网络容错三个角度将分布式系统的特性抽成一个分区容错一致性模型。这样一来，让系统设计者只需根据业务场景特点，进行权衡设计适合业务场景的分区容错一致性模型即可，很大程度简化了分布式系统设计的难度。 也因此，CAP 定理是架构师所必须要掌握的内容，它影响着架构师对分布式系统的技术选型，技术决策。既然如此重要，接下来，我们就一起学习下 CAP 定理吧。 什么是 CAP CAP 定理最初是由加州大学伯克利分校的计算机科学家埃里克·布鲁尔（Eric Brewer）在 2000 年的 ACM PODC 上提出的一个猜想，也因此被叫做布鲁尔定理。后来在 2002 年，麻省理工学院的赛斯·吉尔伯特（Seth Gilbert）和南希·林奇（Nancy Lynch）发表了 CAP 定理的证明，让它成为分布式系统领域公认的一个定理。 CAP 定理指出了，在一个跨区域网络连接，共享数据的分布式系统中，一致性（Consistency），可用性

上篇文章给大家讲解了Ocelot的一些特性并对路由进行了详细的介绍，今天呢就大家一起来学习下Ocelot的请求聚合以及服务发现功能。希望能对大家有所帮助。 作者：依乐祝 原文地址： https://www.cnblogs.com/yilezhu/p/9695639.html 请求聚合 Ocelot允许你声明聚合路由，这样你可以把多个正常的ReRoutes打包并映射到一个对象来对客户端的请求进行响应。比如，你请求订单信息，订单中又包含商品信息，这里就设计到两个微服务，一个是商品服务，一个是订单服务。如果不运用聚合路由的话，对于一个订单信息，客户端可能需要请求两次服务端。实际上这会造成服务端额外的开销。这时候有了聚合路由后，你只需要请求一次聚合路由，然后聚合路由会合并订单跟商品的结果都一个对象中，并把这个对象响应给客户端。使用Ocelot的此特性可以让你很容易的实现前后端分离的架构。 为了实现Ocelot的请求功能，你需要在ocelot.json中进行如下的配置。这里我们指定了了两个正常的ReRoutes,然后给每个ReRoute设置一个Key属性。最后我们再Aggregates节点中的ReRouteKeys属性中加入我们刚刚指定的两个Key从而组成了两个ReRoutes的聚合。当然我们还需要设置UpstreamPathTemplate匹配上游的用户请求

一. 前言 1.业务背景 　　我们前面尝试了在业务服务器上加IDS4校验，实际上是不合理的， 在生产环境中，业务服务器会有很多个，如果把校验加在每个业务服务器上，代码冗余且不易维护(很多情况下业务服务器不直接对外开放)， 所以我们通常把校验加在Ocelot网关上，也就是说校验通过了，Ocelot网关才会把请求转发给相应的业务服务器上.(我们这里通常是网关和业务服务器在一个内网中，业务服务器不开放外网) (和前面：Jwt配合中间件校验流程上是一样的，只不过这里的认证和授权都基于IDS4来做) PS：关于IDS4服务器，可以配置在网关后面，通过网关转发; 　　 也可以不经网关转发，单独存在, 这里要说明的是，如果经过网关转发，那么对于IDS4而言，只是单纯的转发,不走Ocelot上的校验,其实也很简单,就是 不配置AuthenticationProviderKey即可. 2.用到的项目 (1).Case2下的GateWay_Server ：网关服务器 (2).Case2下的ID4_Server：认证+授权服务器 (3).GoodsService + OrderService：二者都是资源服务器 (4).PostMan：充当客户端(即第三方应用) (5).MyClient2：用控制台充当客户端(即第三方应用) (6).Consul：网关Ocelot已经集成Consul服务发现了

系列目录 前面我们介绍了如何在windows单机以及如何基于docker部署consul集群,看起来也不是很复杂,然而如果想要把consul部署到kubernetes集群中并充分利用kubernetes集群的伸缩和调度功能并非易事.前面我们首先部署一个节点,部署完成以后获取它的ip,然后其它的ip都join到这个ip里组成集群. 前面的部署方式存在以下问题: 集群易主 我们知道,在kubernetes里,当节点发生故障或者资源不足时,会根据策略杀掉节点的一些pod转而将pod移到其它节点上.这时候我们就需要重新获取主节点ip,然后将新的节点加入进去,以上做法不利于充分发挥kubernetes自身的伸缩功能. 新节点加入 不管是新节点加入或者失败后重新生成的节点重新加入集群,都需要知道主节点ip,这会产生和上面相同的问题,就是需要人工介入. 理想的状态是,当集群主节点切换时,新节点仍然能够在无需人工介入的情况下自动加入集群.我们解决这个问题的思路如下:使用kubernetes集群的dns功能,而不直接硬编码节点的ip.如果集群中有三个server,则这三个sever中必然有一个是主节点,我们可以依次尝试通过dns来解析到具体的节点,依次尝试加入每一个sever节点,尝试到真正的主节点时便能够加入集群. 我们首先创建服务,定义服务的文件名为consul-service.yml

传统的键配置信息写到文件的方式(xml, json) 是行不通的，因为当处理基于云的应用程序可能包含数百个微服务, 而且每个微服务可能有多个运行时服务实例. 这样就使得配置管理成了一个问题, 因为云环境中的应用程序和运维团队必须全力应付配置文件到哪去. 配置管理 隔离: 我们希望将服务配置信息与服务的实际物理部署完全分离， 应用程序配置不一样部署到服务实例中，相反, 在服务启动时，配置信息应该作为环境变量传递到正在启动的服务或中央仓库中读取. 抽象: 抽象服务接口背后的配置数据的访问。通过 REST 的 JSON 服务检索配置数据. 集中: 基于云的应用可能有数百个服务，将应用程序配置集中到尽可能少的存储库中. 稳定: 因为你的应用程序的配置信息与你部署的服务完全隔离和中心化, 无论你使用何种解决方案，都可以实现高可用和冗余。 应用程序配置数据需要跟踪和版本控制, 因为管理不善的应用配置是不易察觉的错误和意外中断的一个肥沃滋生地. 这里的 Configuration management service , 个人理解, 它本身也是一个微服务, 提供的也是 http restful API 接口, 而不是文件(xml, json) 有很多类似的产品, Etcd, Eureka, Consul, Spring Cloud configuration server, 我们使用的是

本文源码： GitHub·点这里 || GitEE·点这里 一、注册中心简介 1、基础概念 在分布式架构的系统中注册中心这个概念就已经被提出了，最经典的就是Zookeeper中间件。 微服务架构中，注册中心是最核心的基础服务之一，注册中心可以看做是微服务架构中的通信中心，当一个服务去请求另一个服务时，通过注册中心可以获取该服务的状态，地址等核心信息。 服务注册主要关系到三大角色：服务提供者、服务消费者、注册中心。 2、流程和原理 基础流程 服务启动时，将自身的网络地址等信息注册到注册中心，注册中心记录服务注册数据。 服务消费者从注册中心获取服务提供者的地址，并通过地址和基于特定的方式调用服务提供者的接口。 各个服务与注册中心使用一定机制通信。如果注册中心与服务长时间无法通信，就会注销该实例，这也称为服务下线，当服务重新连接之后，会基于一定的策略在线上线。 服务地址相关信息发生变化时，会重新注册到注册中心。这样，服务消费者就无需手工维护提供者的相关配置。 核心功能 通过上面的基本流程，不难发现一个注册中心需要具备哪些核心功能： 服务发现 服务发现是指服务在启动后，注册到注册中心，服务方提供自身的元数据，比如IP地址、端口、运行状况指标的Uri 、主页地址等信息。 服务记录 记录注册中心的服务的信息，例如服务名称、IP地址、端口等。服务消费方基于查询获取可用的服务实例列表。

　　试用了Overt.Core.Grpc, 把 GRPC 的使用改造得像 WCF, 性能测试也非常不错, 非常推荐各位使用. 　　但已有项目大多是 http 请求, 改造成 GRPC 的话, 工作量比较大, 于是又找到了 Steeltoe.Discovery, 在 Startup 给 HttpClient 添加 DelegatingHandler, 动态改变请求url中的 host 和 port, 将http请求指向consul 发现的服务实例, 这样就实现了服务的动态发现. 　　经过性能测试, Steeltoe.Discovery 只有 Overt.Core.Grpc 的20%, 非常难以接受, 于是自己实现了一套基于 consul 的服务发现工具. 嗯, 名字好难取啊, 暂定为 ConsulDiscovery.HttpClient 吧 　　功能很简单: webapi 从json中读取配置信息 ConsulDiscoveryOptions; 如果自己是一个服务, 则将自己注册到consul中并设置健康检查Url; ConsulDiscovery.HttpClient 内有一个consul client 定时刷新所有服务的url访问地址. 　　比较核心的两个类 using Consul; using Microsoft.Extensions.Options; using

1、准备工作 获取google.golang.org/grpc包 go get -u google.golang.org/grpc 安装protobuf工具 brew install protobuf 获取github.com/golang/protobuf/protoc-gen-go包 go get -u github.com/golang/protobuf/protoc-gen-go 安装consul brew install consul 后台启动consul nohup consul agent -dev > consul-out.file 2 > & 1 给grpc服务生成ssl证书，保存在keys文件内，将keys文件夹存放在server/目录下，取出keys文件夹中的server.crt，存放在client/目录下 openssl genrsa -out server.key 2048 openssl req -new -x509 -sha256 -key server.key -out server.crt -days 36500 -subj /C = CN/ST = CQ/L = fanxp/O = cq/OU = bx/CN = go-grpc-test/emailAddress = xxx@gmail.com 2、代码开发 描述 ​ 开发一个用户登录函数

consul、eureka、nacos对比 配置中心 eureka 不支持 consul 支持 但用起来偏麻烦，不太符合springBoot框架的命名风格，支持动态刷新 nacos 支持 用起来简单，符合springBoot的命名风格，支持动态刷新 注册中心 eureka 依赖：依赖ZooKeeper 应用内/外：直接集成到应用中，依赖于应用自身完成服务的注册与发现， ACP原则：遵循AP（可用性+分离容忍）原则，有较强的可用性，服务注册快，但牺牲了一定的一致性。 版本迭代：目前已经不进行升级 集成支持：只支持SpringCloud集成 访问协议：HTTP 雪崩保护：支持雪崩保护 界面：英文界面，不符合国人习惯 上手：容易 consul 依赖：不依赖其他组件 应用内/外：属于外部应用，侵入性小 ACP原则：遵循CP原则（一致性+分离容忍） 服务注册稍慢，由于其一致性导致了在Leader挂掉时重新选举期间真个consul不可用。 版本迭代：目前仍然进行版本迭代 集成支持：支持SpringCloud K8S集成 访问协议：HTTP/DNS 雪崩保护：不支持雪崩保护 界面：英文界面，不符合国人习惯 上手：复杂一点 nacos 依赖：不依赖其他组件 应用内/外：属于外部应用，侵入性小 ACP原则：通知遵循CP原则（一致性+分离容忍） 和AP原则（可用性+分离容忍） 版本迭代