服务发现 —— ServiceLoader

在java开发中,有一些这样的场景:
           
项目中加入了某些jar包,编译时也没有错,但运行时就报错了,
找不到类——这其实就涉及到java中面向接口编程。
            大家都知道面向接口开发有很多好处,特别是在java中要实现回调这样的功能,
        你还必须使用接口。面向接口开发中涉及两个要部分:接口(定义)和接口的实现,
         在有些情况下,接口的定义与实现并不在同一个项目中,或者接口定义方跟实现方式分属不同组织,
         这时候我们要使用这一类接口所拥有的功能时,就需要加入两部分依赖:接口定义部分jar包及
         该接口的实现jar包,这就是开始提出问题的答案。
         
 其实java开发中这样的场景比较多:JDBC、JPA、JMS、WebSocket等都是接口定义方与实现方分离,
 不属于同一个组织,java方一般都是规范的定义者。

 开发中经常遇到这样的事,但是你有没有问过自己:定义接口的jar包与实现jar包加入项目后,
 java在运行时是如何将二者关联起来的,他怎么知道谁是谁的实现呢?
     
    有人可能说这还不简单,直接将所有项目jar包扫描一遍不就知道了!?  
    没错,这办法行得通,但是想想都觉得麻烦,效率不高,其实java研发者在1.6的时候就加入了
    一个实现这种需求的类——ServiceLoader,这就是服务发现功能。
    
    服务发现功能约定:
    
       1、服务实现方必须在自己提供的jar包中的META-INF目录下放置一个目录,
           名字就叫services
            
       2、在services目录下放置服务接口类与实现类的关系文件,该文件要求:
            a、文件的名字是被实现的接口的全路径名(如:a.b.c.IHeHe),文件没有后缀,
               每个文件代表一个接口。
            b、文件内容是该文件名字所代表的接口的实现类的全路径名
                 (如:x.y.x.HaHa ,HaHa实现了IHeHe接口),
               如果该接口有多个实现类,则每个实现类占一行。
   
     这里给一个小的demo,借用一下网友的例子:
     http://blog.csdn.net/is_zhoufeng/article/details/50722440
时间: 2024-10-14 14:46:23

服务发现 —— ServiceLoader的相关文章

Spring Cloud官方文档中文版-服务发现:Eureka服务端

官方文档地址为:http://cloud.spring.io/spring-cloud-static/Dalston.SR3/#spring-cloud-eureka-server 文中例子我做了一些测试在:http://git.oschina.net/dreamingodd/spring-cloud-preparation Service Discovery: Eureka Server 服务发现:Eureka服务端 How to Include Eureka Server 如何创建Eurek

Android网络服务发现(NSD)协议的使用

Android的网络服务发现协议(NSD)可以用于在小范围的网络中发现邻近设备上的某个应用.这对于一些社交网络.多人游戏类的应用会非常有帮助. Android的NSD的使用方法大致上分为四种操作: 1. 注册网络服务 2. 发现网络服务 3. 连接网络服务 4. 注销网络服务 使用NSD时一定要注意: 记得在Manifest中加入android.permission.INTERNET 权限,不然程序会崩溃. 一. 注册网络服务 注册网络服务需要两样东西: 网络服务的信息(NsdServiceIn

Spring Cloud官方文档中文版-服务发现:Eureka客户端

官方文档地址为:http://cloud.spring.io/spring-cloud-static/Brixton.SR7/#_spring_cloud_netflix 文中例子我做了一些测试在:http://git.oschina.net/dreamingodd/spring-cloud-preparation Spring Cloud Netflix This project provides Netflix OSS integrations for Spring Boot apps th

Kubernetes如何使用kube-dns实现服务发现

大纲: ?       Kubernetes中如何发现服务 ?       如何发现Pod提供的服务 ?       如何使用Service发现服务 ?       如何使用kube-dns发现服务 ?       kube-dns原理 ?       组成 ?       域名格式 ?       配置 注:本次分享内容基于Kubernetes 1.2版本! 下面从一个简单的例子开始讲解. 1.Kubernetes中如何发现服务 ◆   发现Pod提供的服务 首先使用nginx-deploym

服务发现系统etcd介绍

一.概述 etcd是一个高可用的键值存储系统,主要用于共享配置和服务发现.etcd是由CoreOS开发并维护的,灵感来自于 ZooKeeper 和 Doozer,它使用Go语言编写,并通过Raft一致性算法处理日志复制以保证强一致性.Raft是一个新的一致性算法,适用于分布式系统的日志复制,Raft通过选举的方式来实现一致性,在Raft中,任何一个节点都可能成为Leader.Google的容器集群管理系统Kubernetes.开源PaaS平台Cloud Foundry和CoreOS的Fleet都

微服务架构下的服务发现

编者的话]这是关于使用微服务架构创建应用系列的第四篇文章.第一篇介绍了微服务架构的模式,讨论了使用微服务架构的优缺点.第二和第三篇描述了微服务架构内部的通讯机制.这篇文章中,我们将会探讨服务发现相关问题. 为什么要使用服务发现? 我们设想一下当正在写代码时,使用了提供REST API或者Thrift API的服务,为了完成一次服务请求,代码需要知道服务实例的网络位置(IP地址和端口).传统应用都运行在物理硬件上,服务实例的网络位置都是相对固定的.例如,代码可以从一个经常变更的配置文件中读取网络位

服务发现之美:Consul集群搭建

近几年随着Docker容器技术.微服务等架构的兴起,人们开始意识到服务发现的必要性.微服务架构简单来说,是一种以一些微服务来替代开发单个大而全应用的方法, 每一个小服务运行在自己的进程里,并以轻量级的机制来通信, 通常是 HTTP RESTful API.微服务强调小快灵, 任何一个相对独立的功能服务不再是一个模块, 而是一个独立的服务.那么,当我们需要访问这个服务时,如何确定它的地址呢?这时就需要服务发现了. Consul 是 HashiCorp 公司推出的开源工具,用于实现分布式系统的服务发

Redola.Rpc 集成 Consul 服务发现

Redola.Rpc 解决了什么问题? Redola.Rpc 是一个使用 C# 开发的 RPC 框架,代码开源在 GitHub 上.目前版本仅支持 .NET Framework 4.6 以上版本,未来待系统稳健后再考虑移植 .NET Standard 和 .NET Core. Redola.Rpc 在 0.3.2 版本中,尝试解决几个 RPC 设计问题: 我是谁?(Local Actor) 如何告诉别人我是谁?(Actor Directory) 我提供什么服务?(Service Catalog

服务发现:Zookeeper vs etcd vs Consul

摘自:http://dockone.io/article/667 [编者的话]本文对比了Zookeeper.etcd和Consul三种服务发现工具,探讨了最佳的服务发现解决方案,仅供参考. 如果使用预定义的端口,服务越多,发生冲突的可能性越大,毕竟,不可能有两个服务监听同一个端口.管理一个拥挤的比方说被几百个服务所使用的所有端口的列表,本身就是一个挑战,添加到该列表后,这些服务需要的数据库和数量会日益增多.因此我们应该部署无需指定端口的服务,并且让Docker为我们分配一个随机的端口.唯一的问题