consul

1.进入官网下载consul: https://www.consul.io/downloads.html 2.解压下载好的consul,下面是我解压后的 在上面右键打开cmd输入命令： consul agent -dev -client=0.0.0.0 以开发者模式快速启动 上面就是我们已经启动成功的consul，它内置带web页面，我们访问 http://localhost:8500 服务注册于发现 1.注册服务 我这里用postman演示 { "Datacenter": "dc1", "Node": "node01", "Address": "192.168.74.102", "Service": { "ID":"mysql-01", "Service": "mysql", "tags": ["master","v1"], "Address": "192.168.74.102", "Port": 3306 } } 这时在刷新consul页面 2.服务查询 来源： oschina 链接： https://my.oschina.net/u/2315253/blog/4258589

一句话 用agent更优雅，适合agent遍布每个应用机的情况。用catalog更直接，操作更方便 前言 今天遇到写一个服务启动自注册的逻辑时产生了一点纠结，可以使用 agent 对象的 register 方法进行注册，也可以使用 catalog 的 register 方法进行注册。那么，两种方式有什么区别呢？ agent对象 new 一个consulClient对象,应当是作为一个软consul agent 对API URL对应的节点的属性没有要求. 其可以是server身份也可以是纯agent身份 数据要经过冲突确认后，再存入catalog中 反注册时只可以反注册自身的节点(主机)上的服务,注册时可以注册其他主机上的服务 catalog connect to consul database 连接的节点应当是server节点 操作后数据立马生效 反注册对所有节点生效 用途 编写反注册节点的服务应使用catalog的方法 使用agent方法反注册服务时，需要指定一个serviceID参数，该ID是的唯一维度是node也就是主机唯一的。因此从catalog进行反注册时最好是提供主机名和服务ID，当然也可以是IP和服务ID，服务名和服务ID的结合我没有尝试过。 案例 实现反注册节点的逻辑 用途：删除已经失效的主机信息，用于取消报警触发 // 根据IP删除节点 func (c

Spring Cloud Ribbon Spring Cloud Ribbon是基于Netflix Ribbon实现的一套客户端负载均衡的工具。它是一个基于HTTP和TCP的客户端负载均衡器。它可以通过在客户端中配置ribbonServerList来设置服务端列表去轮询访问以达到均衡负载的作用。 当Ribbon与Eureka联合使用时，ribbonServerList会被DiscoveryEnabledNIWSServerList重写，扩展成从Eureka注册中心中获取服务实例列表。同时它也会用NIWSDiscoveryPing来取代IPing，它将职责委托给Eureka来确定服务端是否已经启动。 而当Ribbon与Consul联合使用时，ribbonServerList会被ConsulServerList来扩展成从Consul获取服务实例列表。同时由ConsulPing来作为IPing接口的实现。 我们在使用Spring Cloud Ribbon的时候，不论是与Eureka还是Consul结合，都会在引入Spring Cloud Eureka或Spring Cloud Consul依赖的时候通过自动化配置来加载上述所说的配置内容，所以我们可以快速在Spring Cloud中实现服务间调用的负载均衡。 下面我们通过具体的例子来看看如何使用Spring Cloud

1.场景描述 因要用到微服务，关于注册中心这块，与同事在技术原型上做了讨论，初步定的方案是使用：阿里巴巴的nacos+springcloud gateway，下面表格是同事整理的注册中心对比，以前用的springcloud的eureka作为注册中心（ springcloud-高可用部署 ），与eurka相比，这次之所以用阿里的nacos，其中还有一个主要的原因就是nacos集成了动态加载，不用重启网关，动态加载服务配置等。 注册中心对比： Feature Zookeeper Eureka Consul Etcd Nacos 服务健康检查 (弱)长连接，keepalive 可配支持 服务状态，内存，硬盘等 连接心跳 心跳/自定义 多数据中心 — — 支持 — 支持 kv存储服务 支持 — 支持 支持 支持 一致性 paxos — raft raft raft CAP定理 CA AP CA CP AP 使用接口(多语言能力) 客户端 http（sidecar） 支持http和dns http/grpc dns/http/rpc watch支持 支持 支持 long polling/大部分增量 全量/支持long polling 支持 long polling 全量/支持long polling 自身监控 — metrics metrics metrics metrics 安全 acl

新书上线 大家好，笔者的新书《Spring Boot+Spring Cloud+Vue+Element项目实战：手把手教你开发权限管理系统》已上线，此书内容充实、材质优良，乃家中必备垫桌脚垫菜盘之良器，欢迎大家无情购买使用，欢迎大家共同学习交流，欢迎大家提出改进意见。 内容简介： 本书从项目实践出发，手把手、心贴心地带领读者从零开始，一步一步地开发出功能相对完整的权限管理系统，从而深入掌握当前主流的Spring Boot + Spring Cloud + Vue前后端集成开发技术。 全书分为三篇共32章。第一篇为系统介绍篇，对系统的功能、架构和界面进行介绍，对系统的安装运行给出指南，对涉及的关键技术进行简单介绍。第二篇为后端实现篇，从数据库设计和搭建开发环境开始，全面细致地讲解权限管理系统的后端实现全过程。第三篇为前端实现篇，从搭建开发环境开始，全面细致地讲解权限管理系统的前端实现全过程。 本书适合前后端开发人员和全栈工程师阅读，也适合高等院校和培训学校相关专业的师生教学参考。 购买途径 通过天猫、京东、当当等各大网站，搜索 “Spring Boot+Spring Cloud+Vue+Element” 或 “手把手教你开发权限管理系统” 等相关关键字，即可检索到相关图书购买链接，为方便大家查找，下面附上一些简单查找流程示例。 京东 参考链接： https://item.jd.com

一拍即合 　　上一篇《 .Net微服务实战之技术选型篇 》，从技术选型角度讲解了微服务实施的中间件的选择与协作，工欲善其事，必先利其器，中间件的选择是作为微服务的基础与开始，也希望给一直想在.Net入门微服务的同行有一个很好的方向。在此篇重新整理了一下整个微服务项目的demo，希望对有需要的朋友起到一定的帮助：https://github.com/SkyChenSky/Sikiro 　　那么我在公司实施微服务的时候，也不是一拍脑袋想上就上的。刚入职公司的时候才3、4个人，产品给到我的规划只有一个很简单的系统，包含权限、客服IM、内容管理三个模块，我当时想着优先证明我们的开发能力和效率，于是使用简单的单体架构不到三个星期项目就完成了。产品在我们开发的期间把整个项目的规划和平台系统的划分给梳理了一遍，终于让我有一个很明确的技术实施方向，同时公司的人力成本预算也批了下来开始进行团队扩招。 　　于是我与老领导商量了一下，在现在这个情况，无论 业务 还是 团队 都具有使用微服务架构的可操作性，再采用部分DevOps的思想给与微服务实施的支持，能顺利的实施落地微服务问题不大。我们俩讨论了一番，我有良好的微服务技术储备，他有很好的运维支撑，就这样咱两达成了共识。于是我着手翻出了 收藏已久 的微服务中间件、架构分层、服务拆分的资料，从此开始了我的微服务实施之路。 PS

一拍即合 　　上一篇《 .Net微服务实战之技术选型篇 》，从技术选型角度讲解了微服务实施的中间件的选择与协作，工欲善其事，必先利其器，中间件的选择是作为微服务的基础与开始，也希望给一直想在.Net入门微服务的同行有一个很好的方向。在此篇重新整理了一下整个微服务项目的demo，希望对有需要的朋友起到一定的帮助：https://github.com/SkyChenSky/Sikiro 　　那么我在公司实施微服务的时候，也不是一拍脑袋想上就上的。刚入职公司的时候才3、4个人，产品给到我的规划只有一个很简单的系统，包含权限、客服IM、内容管理三个模块，我当时想着优先证明我们的开发能力和效率，于是使用简单的单体架构不到三个星期项目就完成了。产品在我们开发的期间把整个项目的规划和平台系统的划分给梳理了一遍，终于让我有一个很明确的技术实施方向，同时公司的人力成本预算也批了下来开始进行团队扩招。 　　于是我与老领导商量了一下，在现在这个情况，无论 业务 还是 团队 都具有使用微服务架构的可操作性，再采用部分DevOps的思想给与微服务实施的支持，能顺利的实施落地微服务问题不大。我们俩讨论了一番，我有良好的微服务技术储备，他有很好的运维支撑，就这样咱两达成了共识。于是我着手翻出了 收藏已久 的微服务中间件、架构分层、服务拆分的资料，从此开始了我的微服务实施之路。 PS

一拍即合 　　上一篇《 .Net微服务实战之技术选型篇 》，从技术选型角度讲解了微服务实施的中间件的选择与协作，工欲善其事，必先利其器，中间件的选择是作为微服务的基础与开始，也希望给一直想在.Net入门微服务的同行有一个很好的方向。在此篇重新整理了一下整个微服务项目的demo，希望对有需要的朋友起到一定的帮助：https://github.com/SkyChenSky/Sikiro 　　那么我在公司实施微服务的时候，也不是一拍脑袋想上就上的。刚入职公司的时候才3、4个人，产品给到我的规划只有一个很简单的系统，包含权限、客服IM、内容管理三个模块，我当时想着优先证明我们的开发能力和效率，于是使用简单的单体架构不到三个星期项目就完成了。产品在我们开发的期间把整个项目的规划和平台系统的划分给梳理了一遍，终于让我有一个很明确的技术实施方向，同时公司的人力成本预算也批了下来开始进行团队扩招。 　　于是我与老领导商量了一下，在现在这个情况，无论 业务 还是 团队 都具有使用微服务架构的可操作性，再采用部分DevOps的思想给与微服务实施的支持，能顺利的实施落地微服务问题不大。我们俩讨论了一番，我有良好的微服务技术储备，他有很好的运维支撑，就这样咱两达成了共识。于是我着手翻出了 收藏已久 的微服务中间件、架构分层、服务拆分的资料，从此开始了我的微服务实施之路。 PS

【今日推荐】：为什么一到面试就懵逼！>>> 目录 限流 熔断 缓存 Header转化 HTTP方法转换 负载均衡 注入/重写中间件 后台管理 最后 在上篇 .Net微服务实践（三）[网关]：Ocelot配置路由和请求聚合 中我们介绍了Ocelot的配置，主要特性路由以及服务聚合。接下来，我们会介绍Ocelot的限流、熔断、缓存以及负载均衡。 限流 我们先来看限流的配置 Reroute节点中的配置如下： { "DownstreamPathTemplate": "/api/orders", "DownstreamScheme": "http", "DownstreamHostAndPorts": [ { "Host": "localhost", "Port": 5001 } ], "UpstreamPathTemplate": "/api/orders", "UpstreamHttpMethod": [ "Get" ], "RateLimitOptions": { "ClientWhitelist": [], "EnableRateLimiting": true, "Period": "10m", "PeriodTimespan": 3, "Limit": 1 } } GlobalConfiguration中的配置如下： "GlobalConfiguration": {

一、前言 大家一直都在谈论微服务架构，园子里面也有很多关于微服务的文章，前几天也有一些园子的朋友问我微服务架构的一些技术，我这里就整理了微服务架构的技术栈路线图，这里就分享出来和大家一起探讨学习，同时让新手对微服务相关技术有一个更深入的了解。 二、技术栈 2.1 工欲善其事，必先利其器 现在互联网盛行的年代，互联网产品也层出不穷，受欢迎的互联网产品都有一个比较牛的技术团队，我这里分享下.net 微服务架构技术栈图如下： 俗话说得好：工欲善其事，必先利其器。一个优秀的工程师应该善于使用框架和工具，在微服务这一块的技术选型并非一蹴而就，需要经过日积月累和落地的项目才能完善。 下文我会一一分享技术栈中的主要框架和工具的使用场景，这篇文章就不一一分享实战例子。 2.2 微服务 微服务如何“微”？ 微服务，当然核心是主题是“微”，怎么微呢？应该如何微呢？在我刚来杭州的时候接触过一个电商系统的 单体架构 ，系统比较庞大，结合了各种电商该拥有的业务逻辑和场景， 代码也比较难于维护，前前后后接手的人也比较多，代码耦合度太高，改个业务逻辑基本上是牵一发而动全身，跟我上个月分享的关于 Asp.Net Core 中IdentityServer4 授权中心之应用实战 的文章中的电商系统最初的架构图类似，如下： 那针对这个架构就有可“微”之谈了。 这里针对该 单体架构 可以做如下几个原则上进行“微”服务: