分布式服务框架--注册中心
这是我参与8月更文挑战的第19天,活动详情查看: 8月更文挑战
本文使用源码地址:simple-rpc
分布式服务框架部署在多台不同的机器上,如下图所示:
这将面临如下问题需要解决:
- 集群A中的服务调用者如何发现集群B中的服务提供者。
- 集群A中的服务调用者如何选择集群B中的某一台服务提供者机器发起调用。
- 集群B中的服务某台提供者机器下线后,集群A中的服务调用者如何感知到这台机器的下线,不再对已下线的机器发起调用。
- 集群B提供的某个服务如何获知集群A中的那些机器正在消费改服务。
以上问题都通过注册中心来解决,我们采用服务注册中心来实时存储更新服务提供者信息及该服务的实时调用者信息。
服务注册中心有如下优点:
- 软负载及透明化路由:服务提供者和服务调用者之间互相解耦,服务调用者不需要硬编码服务提供者地址。
- 服务动态发现及可伸缩扩展能力:服务提供者机器增减能被服务调用者通过注册中心动态感知,而且通过增减机制可以实现服务的弹性伸缩。
- 通过注册中心可以动态监控服务运行质量及服务依赖,为服务提供服务治理能力。
Zookeeper实现服务注册中心
如何部署Zookeeper可以参考使用 Docker 一步搞定 ZooKeeper 集群的搭建。
ZkClient
ZkClient是一个开源的ZooKeeper客户端,是在原生的ZooKeeper API接口之上进行包装,是一个更易使用的ZooKeeper客户端。ZkClient在内部实现了Session超时重连、Watcher反复注册等功能,使得ZooKeeper客户端的繁琐细节对开发人员透明。如何使用可以参考zookeeper之ZkClient。
服务注册中心实现
目标:
- 服务端服务启动时将服务提供者信息(主机IP地址、服务端口、服务接口类全限类名等)组成znode作为临时节点写入Zookeeper叶子节点,这样就完成了服务的注册动作。
- 服务的消费端在发起服务调用之前,先连接到Zookeeper,对服务提供者节点路径注册监听器,同时获取服务提供者信息到本地缓存。
- 服务注册中心能够感知服务提供者集群中某一台机器下线,将该机器服务提供者信息从服务注册中心删除,并主动通知服务调用者集群中的每一台机器,使得服务调用者不再调用该机器。
- 可以通过服务注册中心收集服务消费者信息。
主要方法
public interface IRegisterCenter {
/**
* 注册服务提供者信息
* @param providers 服务提供者
*/
void registerProvider(List<Provider> providers);
/**
* 获取服务提供者列表
* key:接口
* @return
*/
Map<String, List<Provider>> getProvidersMap();
/**
* 销毁
* @param serviceItfName 接口名称
*/
void destroy(String serviceItfName);
/**
* 消费端初始化本地服务缓存
* @param remoteAppKey 服务提供者唯一标识
* @param groupName 服务组名
*/
void loadProviderMap(String remoteAppKey, String groupName);
/**
* 获取服务提供者信息
* @return
*/
Map<String, List<Provider>> getServiceMetadata();
/**
* 注册服务消费者信息 用于监控
* @param invoker
*/
void registerInvoker(Invoker invoker);
}
整个实现比较长,我们分段来看,服务提供者和服务消费者注册比较类似就不看了,销毁操作也只是本地缓存的清楚,所以我们只看两个最重要的方法void registerProvider(List<Provider> providers)
和void loadProviderMap(String remoteAppKey, String groupName)
。
首先看一下相关变量设置:
private volatile ZkClient zkClient = null;
/**
* zk 服务列表 127.0.0.1:2181,127.0.0.1:2182,127.0.0.1:2183
*/
private static final String ZK_SERVERS = SimpleRpcPropertiesUtil.getZkServers();
/**
* zk会话超时时间
*/
private static final int ZK_SESSION_TIMEOUT = SimpleRpcPropertiesUtil.getSessionTimeout();
/**
* zk 连接超时时间
*/
private static final int ZK_CONNECT_TIMEOUT = SimpleRpcPropertiesUtil.getConnectionTimeout();
/**
* zk 根目录
*/
private static final String ROOT_PATH = "/config_register";
private static final String PROVIDER_TYPE = "/provider";
private static final String INVOKER_TYPE = "/invoker";
private static final int SERVER_PORT = SimpleRpcPropertiesUtil.getServerPort();
private static final String LOCAL_IP = IpUtil.getLocalIP();
/**
* 服务提供者列表
* key:interface name
* value: List<Provider> (methods)
*/
private static final Map<String, List<Provider>> PROVIDER_MAP = Maps.newConcurrentMap();
/**
* 客户端引入的服务列表,启动时加入本地缓存
* key:interface name
*/
private static final Map<String, List<Provider>> SERVICE_METADATA = Maps.newConcurrentMap();
最重要肯定还是PROVIDER_MAP
和SERVICE_METADATA
,使用ConcurrentHashMap
来保存服务提供者和客户端引入的服务列表保证线程安全,保存的key
为服务的全限类名,value
则是服务的具体信息(目前的服务发现还是类级别,一个类下有多个方法,就代表有多个服务)。
接着我们继续看两个重要方法的实现。
registerProvider-完成服务注册
这个方法看名字也知道是干什么的,这是执行服务注册的方法。我们看下具体执行步骤如下:
具体代码如下:
@Override
public void registerProvider(List<Provider> providers) {
if (CollectionUtils.isEmpty(providers)) {
log.debug("RegisterCenterImpl registerProvider providers is empty, ignore it, providers={}", providers);
} else {
synchronized (RegisterCenterImpl.class) {
// 加载zkClient
this.lazyInitZkClient();
// 设置本地服务列表
this.setLocalCache(providers);
String rootNode = ROOT_PATH + UrlConstants.SLASH + providers.get(0).getAppKey();
// 创建根节点
this.createRootNode(rootNode);
for (Map.Entry<String, List<Provider>> entry : PROVIDER_MAP.entrySet()) {
// 服务接口类路径
String serviceItfName = entry.getKey();
Provider provider = entry.getValue().get(0);
// 服务组名
String groupName = entry.getValue().get(0).getGroupName();
// 创建服务提供者节点
String servicePath = rootNode + UrlConstants.SLASH + groupName + UrlConstants.SLASH + serviceItfName + PROVIDER_TYPE;
this.createServiceNode(servicePath);
// 创建当前服务器临时节点
String currentServiceIpNode = servicePath + UrlConstants.SLASH + LOCAL_IP + UrlConstants.VERTICAL_LINE
+ SERVER_PORT + UrlConstants.VERTICAL_LINE + provider.getWeight() + UrlConstants.VERTICAL_LINE
+ provider.getWorkerThreads() + UrlConstants.VERTICAL_LINE + groupName;
this.createCurrentServiceIpNode(currentServiceIpNode);
log.debug("create current service node success, node path = {}", currentServiceIpNode);
// 监听本地服务变化,加入本地缓存
this.subscribeChildChanges(servicePath, PROVIDER_MAP);
}
}
}
}
整个逻辑还是较为简单的,本质上就是将服务发现(这个后面会说)中获取到的服务列表List<Provider>
封装成znode
,作为临时节点(Zookeeper会监听服务端的存活,一旦服务端下线,该临时节点会被自动删除,同时推送给服务消费端,从而达到服务提供者自动下线的母的)保存到zookeeper
中,并且注册监听器监听服务变化的过程。这个过程中可能有一些特殊的处理,如锁、懒加载等也都是为了安全和性能上的考量。
loadProviderMap-加载服务列表
具体代码如下:
@Override
public void loadProviderMap(String remoteAppKey, String groupName) {
if (MapUtils.isEmpty(SERVICE_METADATA)) {
SERVICE_METADATA.putAll(fetchOrUpdateServiceMetaData(remoteAppKey, groupName));
}
}
/**
* 获取或更新服务元数据信息
* @param remoteAppKey 服务提供者appkey
* @param groupName 服务组名
* @return
*/
private Map<String, List<Provider>> fetchOrUpdateServiceMetaData(String remoteAppKey, String groupName) {
final Map<String, List<Provider>> providerServiceMap = Maps.newHashMap();
// 连接ZK
this.lazyInitZkClient();
// 服务提供者节点
String providerNode = ROOT_PATH + UrlConstants.SLASH + remoteAppKey + UrlConstants.SLASH + groupName;
// 从ZK获取方服务提供者列表
List<String> providerServices = zkClient.getChildren(providerNode);
for (String serviceName : providerServices) {
String servicePath = providerNode + UrlConstants.SLASH + serviceName + PROVIDER_TYPE;
List<String> nodeList = zkClient.getChildren(servicePath);
log.info("get zk nodeList={} from path={}", nodeList, servicePath);
for (String node : nodeList) {
// 封装服务信息 : ip|port|weight|workerThreads|groupName
String[] serverAddress = StringUtils.split(node, UrlConstants.VERTICAL_LINE);
if (ArrayUtils.isNotEmpty(serverAddress)) {
String serverIp = serverAddress[0];
int serverPort = Integer.parseInt(serverAddress[1]);
int weight = Integer.parseInt(serverAddress[2]);
int workerThreads = Integer.parseInt(serverAddress[3]);
String group = serverAddress[4];
List<Provider> providerList = providerServiceMap.get(serviceName);
if (providerList == null) {
providerList = new ArrayList<>();
}
Provider provider = Provider.builder().serverIp(serverIp).serverPort(serverPort).weight(weight)
.workerThreads(workerThreads).groupName(group).build();
try {
provider.setServiceItf(ClassUtils.getClass(serviceName));
} catch (Exception e) {
log.error("get service interface class error", e);
throw new SRpcException("get service interface class error", e);
}
providerList.add(provider);
providerServiceMap.put(serviceName, providerList);
} else {
log.debug("illegal service address, ignore it");
}
}
// 监听远程服务变化,加入本地缓存
this.subscribeChildChanges(servicePath, SERVICE_METADATA);
}
return providerServiceMap;
}
加载服务列表是在服务引入时的重要代码,它根据appKey
和groupName
两个信息加载所有服务到本地缓存,并且注册监听器监听远程服务变化,以此保证服务能够正常使用。
小结
注册中心是整个分布式服务框架中的核心功能,它为在分布式服务中的服务质量提供了保障,并且为服务监控和服务治理提供了入口。
下一篇: 华为开源镜像站体验:好事多磨
推荐阅读
-
跪求!分布式/开源框架/微服务/性能调优都有全方位注解的 Java,不知不觉已经火遍全网!
-
分布式服务框架--注册中心
-
微服务注册中心:Consul - 概念和基本操作
-
反传销网8月30日发布:视频区块链里的骗子,币里的韭菜,杜子建骂人了!金融大V周召说区块链!——“一小帮骗子玩一大帮小白,被割韭菜,小白还轮流被割,割的就是你!” 什么区块链,统统是骗子 作者:周召(知乎金融领域大V,毕业于上海财经大学,目前任职上海某股权投资基金合伙人) 有人问我,区块链现在这么火,到底是不是骗局? 我的回答是: 是骗局。而且我并不是说数字货币是骗局,而是说所有搞区块链的都是骗局。 -01- 区块链是一种鸡肋技术 人类社会任何技术的发明应用,本质都是为了提高社会的生产效率。而所谓区块链技术本质不过是几种早已成熟的技术的大杂烩,冗余且十分低效,除了提高了洗钱和诈骗的效率以外,对人类社会的进步毫无贡献。 真正意义上的区块链得包含三个要素:分布式系统(包括记账和存储),无法篡改的数据结构,以及共识算法,三者互为基础和因果,就像三体世界一样。看上去挺让人不明觉厉的,而经过几年的瞎折腾,稍微懂点区块链的碰了几次壁后都已经渐渐明白区块链其实并没有什么卵用,区块链技术已经名存实亡,沦为了营销工具和传销组织的画皮。 因为符合上述定义的、以比特币为代表的原教旨区块链技术,是反效率的,从经济学角度来说,不但不是一种帕累托改进,甚至还可以说是一种帕累托倒退。 原教旨区块链技术的效率十分低下,因为要遍历所有节点,只能做非常轻量级的数据应用,一旦涉及到大量的数据传输与更新,区块链就瞎了。 一方面整条链交易速度会极慢,另一方面数据库容量极速膨胀,考虑到人手一份的存储机制,区块链其实是对存储资源和能源的一种极大的浪费。 这里还没有加上为了取得所谓的共识和挖矿消耗的巨大的能源,如果说区块链技术是屎,那么这波区块链投机浪潮可谓人类历史上最大规模的搅屎运动。 区块链也验证不了任何东西。 所谓的智能合约,即不智能,也非合约。我看有人还说,如果有了智能合约,就可以跟老板签一份放区块链上,如果明年销售业绩提升30%,就加薪10%,由于区块链不能篡改,不能抵赖,所以老板必须得执行,说得有板有眼,不懂行的愣一看,好像还真是那么回事。 但仔细一想,问题就来了。首先,在区块链上如何证明你真的达到了30%业绩提升?即便真的达到老板耍赖如何执行? 也就是说,如果区块链真这么厉害,要法院和仲裁干什么。 人类社会真正的符合成本效益原则的是代理制度。之前有人说要用区块链改造注册会计师行业,我不知道他准备怎么设计,我猜想他思路大概是这样的,首先肯定搞去中心化,让所有会计师到链上来,然后一个新人要成为注册会计师就要所有会计师同意并记录在链上。 那我就请问了,我每天上班累死累活,为什么还要花时间去验证一个跟我无关的的人的专业能力?最优做法当然是组织一个委员会,让专门的人来负责,这不就是现在注册会师协会干的事儿吗?区块链的逻辑相当于什么事情都要拿出来公投,这个绝对是扯淡的。 当然这么说都有点抬举区块链了,区块链技术本身根本没有判断是非能力,如果这么高级的人工智能,靠一个无脑分布式记账就能实现的话,我们早就进入共产主义社会了。 虽然EOS等数字货币采用了超级节点,通过再中心化的方式提高效率,有点行业协会的意思,是对区块链原教旨主义的一种修正,但是依然无法突破区块链技术最本质的局限性。有人说,私有链和联盟链是区块链技术的未来,也是扯淡,因为区块链技术没有未来。如果有,说明他是包装成区块链的伪区块链技术。 区块链所涉及的所有底层技术,不管是分布式数据库技术,加密技术,还是点对点传输技术等,基本都是早已存在没什么秘密可言的技术。 比特币系统最重要的特性是封闭性和自洽性,他验证不了任何系统自身以外产生的信息的真实性。 所谓系统自身产生的信息,就是数据库数据的变动信息,有价值的基本上有且只有交易信息。所以说比特币最初不过是中本聪一种炫技的产物,来证明自己对几种技术的掌握,你看我多牛逼,设计出了一个像三体一样的系统。因此,数字货币很有可能是区块链从始至终唯一的杀手应用。 比特币和区块链概念从诞生到今天已经快10年了,很多人说区块链技术在爆发的前夜,但这个前夜好像是不是有点过长了啊朋友,跟三体里的长夜有一拼啊。都说区块链技术像是90年代初的互联网,可是90年代初的互联网在十年发展后,已经出现了一大批伟大的公司,阿里巴巴在99年都成立了,区块链怎么除了币还是币呢? 正规的数字货币未来发展的形式无外乎几种,要么就是论坛币形式,或者类似股票的权益凭证等。问题是论坛币和股票之前,本来也都电子化了,区块链来了到底改变了什么呢? 所有想把TOKEN和应用场景结合起来的人最后都很痛苦,最后他们会发现区块链技术就是脱裤子放屁,自己辛苦搞半天,干嘛不自己作为中心关心门来收钱?最后这些人都产生了价值的虚无感,最终精神崩溃,只能发币疯狂收割韭菜,一边嘴里还说着我是个好人之类的奇怪的话。 因此,之前币圈链圈还泾渭分明,互相瞧不起,但这两年链圈逐渐坐不住了,想着是不是趁着泡沫没彻底破灭之前赶快收割一波,不然可能什么都捞不着了。 前段时间和一个名校毕业的链圈朋友瞎聊天,他说他们“致力于用区块链技术解决数字版权保护问题”,我就问他一个问题,你们如何保证你链的版权所有权声明是真实的,万一盗版者抢先一步把数据放在链上怎么办。他说他们的解决方案是连入国家数字版权保护中心的数据库进行验证…… 所以说区块链技术就是个鸡肋,研究到最后都会落入效率与真实性的黑洞,很多人一头扎进链圈后才发现,真正意义上的区块链技术,其实什么都干不了。 -02- 不是蠢就是坏的区块链媒体 空气币和区块链的造富神话,让区块链自媒体也开始迎风乱扭。一群群根本不知道区块链为何物的妖魔鬼怪纷纷进驻区块链自媒体战场,开始大放厥词胡编乱造。 任何东西,但凡只要和区块,链,分,分布式,记账,加密,验证,可追溯等等这些个关键词沾到哪怕一点点,这些所谓的区块链媒体人就会像狗闻到了屎了一样疯狂地把区块链概念往上套。 这让我想起曾经一度也是热闹非凡的物联网,我曾经去看过江苏一家号称要改变世界的“物联网”企业,过去一看是生产路由器的,我黑人问号脸,对方解释说没有路由器万物怎么互联,我觉得他说得好有道理,竟无言以对。 好,下面让我们进入奇葩共赏析时间,来看看区城链媒体经常有哪些危言耸听的奇谈怪论 区块链(分布式记账)的典型应用是*?? 正如前面所说,真正意义上的区块链分布式记账,不光包括“记”这个动作,还包括分布式存储和共识机制等。而*诞生远远早于区块链这个词的出现,勉强算是“分布式编辑”吧,就被很多区块链媒体拿来强行充当区块链技术应用的典范。 其实事实恰恰相反,*恰恰是去中心化失败的典范,现在如果没有精英和专业人士的编辑和维护,*早就没法看了。 区块链会促进社会分工?? 罗振宇好像就说过类似的话,虽然罗振宇说过很多没有逻辑的话,但这句话绝对是最没逻辑思维的。很多区块链自媒体也常常用这句话来忽悠老百姓,说分工代表效率提高社会进步,而区块链“无疑”会促进分工,他们的理由仅仅是分工和分布式记账都共用一个“分”字,就强行把他们扯到一起。 实际情况恰恰相反,区块链是逆分工的,区块链精神是号召所有人积极地参与到他不擅长也不想掺合的事情里面去。 区块链不能像上帝一样许诺他的子民死后上天国,只能给他们许诺你们是六度人脉中的第一级,我可以赚后面五级人的钱,你处于金字塔的顶端。
-
[十亿美元数据专题]"分布式服务框架" 回顾我们今年为探索服务的保证能力而实施的三个关键方案。
-
Spring Cloud 构建面向企业的大规模分布式微服务快速开发框架 + 技术栈介绍
-
SpringCloud 微服务 - 尤里卡注册中心
-
微服务day01-认识微服务与Eureka注册中心
-
实战教程:Go-Micro微服务框架结合Nacos的 service 注册与发现操作指南
-
微服务篇之注册中心