Category Archives: Microservice

服务注册与发现的原理和实现

什么是服务注册发现？ 对于搞微服务的同学来说，服务注册、服务发现的概念应该不会太陌生。 简单来说，当服务A需要依赖服务B时，我们就需要告诉服务A，哪里可以调用到服务B，这就是服务注册发现要解决的问题。 Service B 把自己注册到 Service Registry 叫做 服务注册 Service A 从 Service Registry 发现 Service B 的节点信息叫做 服务发现 服务注册 服务注册是针对服务端的，服务启动后需要注册，分为几个部分： 启动注册 定时续期 退出撤销 启动注册 当一个服务节点起来之后，需要把自己注册到 Service Registry 上，便于其它节点来发现自己。注册需要在服务启动完成并可以接受请求时才会去注册自己，并且会设置有效期，防止进程异常退出后依然被访问。 定时续期 定时续期相当于 keep alive，定期告诉 Service Registry 自己还在，能够继续服务。 退出撤销 当进程退出时，我们应该主动去撤销注册信息，便于调用方及时将请求分发到别的节点。同时，go-zero 通过自适应的负载均衡来保证即使节点退出没有主动注销，也能及时摘除该节点。 服务发现 服务发现是针对调用端的，一般分为两类问题： 存量获取 增量侦听 还有一个常见的工程问题是 应对服务发现故障 当服务发现服务（比如 etcd, consul, nacos等）出现问题的时候，我们不要去修改已经获取到的 endpoints 列表，从而可以更好的确保 etcd 等宕机后所依赖的服务依然可以正常交互。 存量获取 当 Service A 启动时，需要从 Service Registry 获取 Service B 的已有节点列表：Service B1, Service B2, Service B3，然后根据自己的负载均衡算法来选择合适的节点发送请求。 增量侦听 上图已经有了 Service B1, Service B2, Service B3，如果此时又启动了 Service B4，那么我们就需要通知 Service A 有个新增的节点。如图： 应对服务发现故障 对于服务调用方来说，我们都会在内存里缓存一个可用节点列表。不管是使用 etcd，consul 或者 nacos 等，我们都可能面临服务发现集群故障，以 etcd 为例，当遇到 etcd 故障时，我们就需要冻结 Service B 的节点信息而不去变更，此时一定不能去清空节点信息，一旦清空就无法获取了，而此时 Service B 的节点很可能都是正常的，并且 go-zero 会自动隔离和恢复故障节点。 服务注册、服务发现的基本原理大致如此，当然实现起来还是比较复杂的，接下来我们一起看看 go-zero 里支持哪些服务发现的方式。 go-zero 之内置服务发现 go-zero 默认支持三种服务发现方式： 直连 基于 etcd 的服务发现 基于 kubernetes endpoints 的服务发现 直连 直连是最简单的方式，当我们的服务足够简单时，比如单机即可承载我们的业务，我们可以直接只用这种方式。 在 rpc 的配置文件里直接指定 endpoints 即可，比如：

  zrpc 调用端就会分配负载到这两个节点上，其中一个节点有问题时 zrpc 会自动摘除，等节点恢复时会再次分配负载。 这个方法的缺点是不能动态增加节点，每次新增节点都需要修改调用方配置并重启。 基于 etcd 的服务发现 当我们的服务有一定规模之后，因为一个服务可能会被很多个服务依赖，我们就需要能够动态增减节点，而无需修改很多的调用方配置并重启。 常见的服务发现方案有 etcd, consul, nacos 等。 go-zero内置集成了基于 etcd 的服务发现方案，具体使用方法如下：

  Hosts 是 etcd 集群地址 Key 是服务注册上去的 key 基于 […]

服务的注册与发现（Consul、zookeeper、etcd、eureka、Nacos）

一. 对比常用的注册中心 Consul、zookeeper、etcd、eureka、Nacos Feature Consul Zookeeper Etcd Eureka Nacos 服务健康检查  服务状态，内存，硬盘等  (弱)长连接，keepalive  连接心跳  可配支持 传输层 (PING 或 TCP)和应用层 (如 HTTP、MySQL、用户自定义）的健康检查 多数据中心  支持  —  —  — 支持 kv存储服务  支持  支持  支持  —  支持 一致性   Raft  Paxos   Raft  — Raft CAP定理  CP  CP  CP  AP CP: 配置中心 AP: 注册中心 使用接口 (多语言能力)  支持http和dns  客户端  http/grpc  http（sidecar） Nacos 支持基于 DNS 和基于 RPC 的服务发现。服务提供者使用 原生SDK、OpenAPI、或一个独立的Agent watch支持  全量/支持long polling  支持  支持 long polling 支持 long polling/大部分增量 支持 long polling/大部分增量 自身监控  metrics  —  metrics  metrics   安全  acl /https  acl  https支持（弱）  — acl Spring Cloud集成  已支持  已支持  已支持  已支持  已支持 备注 可以作为eureka的替代使用     2.0不在更新 1. 支持dubbo […]

Nacos – 阿里开源配置中心

配置中心相信大家都有听过，zookeeper、apollo等等都是配置中心的代表，但大部分都是JAVA系为主的，笔者主要开发语言使用的是Golang当然也有类似于ETCD这样的组件，但是并不方便管理也无法可视化，在无意之间发现了阿里爸爸开源了nacos这个服务发现+配置中心组件，也经过了一段时间的时候在这里分享给大家 附上: 喵了个咪的博客:w-blog.cn Nacos官方Git地址:https://github.com/alibaba/nacos Nacos官方文档地址:https://nacos.io/zh-cn/docs/ Go语言SDK地址:https://github.com/sunmi-OS/gocore/tree/master/nacos PS：当前官方最新版本为 V1.1.3，阿里云有提供配置中心服务ACM使用方式和Nacos相同，使用阿里云的前提下免运维是个不错的选择 一、Nacos介绍 Nacos是阿里云中间件团队开源的一个项目，基于阿里云内部提供的ACM配置管理服务进行独立，截止到现在github已经有8K以上的star了，虽然成熟度还不能和携程开源的apollo相提并论，比较也是在阿里云上提供服务的组件稳定性还是值得相信的，当然要使用介绍Nacos必须要介绍介绍配置中心这样一个思想了。 配置中心是个老生常谈的话题，从有软件编程开始配置管理都是工程中重要的一步，当然对与一个单体应用只需要单个配置文件或环境变量的方式来管理配置就好了所以不再本文的讨论范围内，配置中心主要解决服务化或微服务化下的配置管理中的如下问题： 有效的密码管理，开发不碰触密码配置，运维人员和架构团队统一管理避免泄露； 多项目下的配置绝对统一性，不会出现配置写错导致的BUG 对于配置的编辑、存储、分发、变更管理、历史版本管理、变更审计有完善的能力 配置分组和灰度发布 有好处当然也有坏处，相对于使用配置文件我们还需要解决如下问题： 配置中心异常情况下服务怎么保障可用（SDK提供Cache功能当中心服务不可用会使用上一次加载的缓存配置） 配置变更后的程序生效逻辑（SDK提供配置变动订阅逻辑可以订阅配置变动编写处理逻辑） 开发过程中的配置文件调试（需要框架进行设计） 对于部分语言来说（PHP）配置中心性能的问题（Nacos的吞吐量8C16G 15K并发） 对比下来还是可以总结出配置中心利大于弊的结论 二、Nacos部署 Nacos不止支持二进制部署也支持支持Docker和K8S部署，因为Nacos是有状态服务存储的数据需要依赖于Mysql而且集群的方式需要指定slave的IP所以使用K8S并不是很好的选择（K8S使用StatefulSet来运行有状态服务），笔者这里用Docker-Composer的方式来运行Nacos

访问：http://localhost:8848/nacos/ 就可以看到登录界面了 PS：默认用户名和密码都是 nacos 阿里云ACM服务 当然自己部署Nacos还会面临很多挑战，比如： 集群搭建 稳定性 Mysql数据库维护 配置安全保护（Nacos没有密码一说，但是ACM需要使用阿里云的密钥可以提高安全程度） PS：秉着能用服务就不自己搭建的原则笔者最终使用的是阿里云的ACM服务（当前ACM服务免费） PS：需要注意阿里云ACM和Nacos在SDK中的链接方式有不同 三、基础使用 Nacos有几个基础概念，我们只有先了解清楚之后才能更好的结合到业务场景： namespace 命名空间 Group 配置分组 DataID 具体的配置名称 一般我们使用namespace来区分不同的项目或环境，Group区分配置的差异系比如A业务获取的配置和B团队的有一些细微的差别可以通过Group来区分，最后使用DataId来区分具体的配置项 增加一个namespace 新增一个配置 支持很多种配置格式，也可以使用自定义的格式甚至直接存放代码都行 也有对应的JAVA系的示例代码 四、SDK和OpenApi使用配置 Nacos支持一下语言的SDK（当然GIT上也有很多非官方的SDK库）： Java go cpp python nodejs 大家可以在官方文档中查看具体的使用方式 上面已经配置好的配置我们可以使用OpenApi来访问它

特别注意tenant就是需要输入namespace的名称，但是不是原名是如下的名称 from:https://www.cnblogs.com/cuiyubo/p/11756777.html

微服务之consul（一）

一、概述 consul是google开源的一个使用go语言开发的服务发现、配置管理中心服务。内置了服务注册与发现框 架、分布一致性协议实现、健康检查、Key/Value存储、多数据中心方案，不再需要依赖其他工具（比如ZooKeeper等）。服务部署简单，只有一个可运行的二进制的包。每个节点都需要运行agent，他有两种运行模式server和client。每个数据中心官方建议需要3或5个server节点以保证数据安全，同时保证server-leader的选举能够正确的进行。 @client CLIENT表示consul的client模式，就是客户端模式。是consul节点的一种模式，这种模式下，所有注册到当前节点的服务会被转发到SERVER，本身是不持久化这些信息。 @server SERVER表示consul的server模式，表明这个consul是个server，这种模式下，功能和CLIENT都一样，唯一不同的是，它会把所有的信息持久化的本地，这样遇到故障，信息是可以被保留的。 @server-leader 中间那个SERVER下面有LEADER的字眼，表明这个SERVER是它们的老大，它和其它SERVER不一样的一点是，它需要负责同步注册的信息给其它的SERVER，同时也要负责各个节点的健康监测。 @raft server节点之间的数据一致性保证，一致性协议使用的是raft，而zookeeper用的paxos，etcd采用的也是raft。 @服务发现协议 consul采用http和dns协议，etcd只支持http @服务注册 consul支持两种方式实现服务注册，一种是通过consul的服务注册http API，由服务自己调用API实现注册，另一种方式是通过json个是的配置文件实现注册，将需要注册的服务以json格式的配置文件给出。consul官方建议使用第二种方式。 @服务发现 consul支持两种方式实现服务发现，一种是通过http API来查询有哪些服务，另外一种是通过consul agent 自带的DNS（8600端口），域名是以NAME.service.consul的形式给出，NAME即在定义的服务配置文件中，服务的名称。DNS方式可以通过check的方式检查服务。 @服务间的通信协议 Consul使用gossip协议管理成员关系、广播消息到整个集群，他有两个gossip  pool（LAN pool和WAN pool），LAN pool是同一个数据中心内部通信的，WAN pool是多个数据中心通信的，LAN pool有多个，WAN pool只有一个。   二、consul集群搭建 1）安装 首先去官网现在合适的consul包：https://www.consul.io/downloads.html 安装直接下载zip包，解压后只有一个可执行的文件consul，将consul添加到系统的环境变量里面。 #unzip consul_1.2.3_linux_amd64.zip #cp -a consul  /usr/bin #consul

输入consul，出现上面的内容证明安装成功。   2）启动 consul必须启动agent才能使用，有两种启动模式server和client，还有一个官方自带的ui。server用与持久化服务信息，集群官方建议3或5个节点。client只用与于server交互。ui可以查看集群情况的。 server： cn1： #consul agent  -bootstrap-expect 2  -server   -data-dir /data/consul0 -node=cn1 -bind=192.168.1.202 -config-dir /etc/consul.d -enable-script-checks=true  -datacenter=dc1 cn2: #consul agent    -server  -data-dir /data/consul0 -node=cn2 -bind=192.168.1.201 -config-dir /etc/consul.d -enable-script-checks=true  -datacenter=dc1  -join 192.168.1.202 cn3: #consul agent  -server  -data-dir /data/consul0 -node=cn3 -bind=192.168.1.200 -config-dir /etc/consul.d -enable-script-checks=true  -datacenter=dc1  -join 192.168.1.202 参数解释： -bootstrap-expect:集群期望的节点数，只有节点数量达到这个值才会选举leader。 -server： 运行在server模式 -data-dir：指定数据目录，其他的节点对于这个目录必须有读的权限 -node：指定节点的名称 -bind：为该节点绑定一个地址 -config-dir：指定配置文件，定义服务的，默认所有一.json结尾的文件都会读 […]

etcd和redis的比较和日常使用场景

个人观点：etcd的红火来源于kurbernetes用etcd做服务发现，而redis的兴起则来源于memcache缓存本身的局限性。 etcd是一种分布式存储，更强调的是各个节点之间的通信，同步，确保各个节点上数据和事务的一致性， 使得服务发现工作更稳定，本身单节点的写入能力并不强。 redis更像是内存型缓存，虽然也有cluster做主从同步和读写分离， 但节点间的一致性主要强调的是数据，并不在乎事务，因此读写能力很强，qps甚至可以达到10万+ 两者都是k-v存储，但redis支持更多的存储模式，包括KEY，STRING，HMAP，SET，SORTEDSET等等， 因此redis本身就可以完成一些比如排序的简单逻辑。而etcd则支持对key的版本记录和txn操作和client对key的watch，因此适合用做服务发现。 日常使用中，etcd主要还是做一些事务管理类的，基础架构服务用的比较多，容器类的服务部署是其主流。 而redis广泛地使用在缓存服务器方面，用作mysql的缓存，通常依据请求量，甚至会做成多级缓存，当然部分情况下也用做存储型redis做持续化存储。   from:https://www.cnblogs.com/nmap/p/9398346.html