精华内容
下载资源
问答
  • 自android 4.1 开始实现了一个网络服务的发现服务NsdService,其基于苹果的Bonjour服务发现协议,支持远程服务的发现和零配置。  Bonjour协议包括IP地址的自动分配、服务名称与地址的转换以及服务的发现三部分内容...

              自android 4.1 开始实现了一个网络服务的发现服务NsdService,其基于苹果的Bonjour服务发现协议,支持远程服务的发现和零配置。

            Bonjour协议包括IP地址的自动分配、服务名称与地址的转换以及服务的发现三部分内容,ANDROID4.1借助第三方开源工程mDNSResponder实现了Bonjour协议的服务名称与地址的转换以及服务的发现等 Bonjour部分协议的支持。Bonjour协议的服务名称与地址的转换以及服务的发现采用的流程和DNS流程近似包括:登记过程、服务发现过程、服务地址解析过程以及建立连接等过程,服务发现采用的协议也和DNS协议相似,不过与DNS协议采用的单播方式不同的是采用了组播方式,因此被称为mDNS。

                               

                                




             ANDROID4.2 对网络服务发现的实现架构包括四层:NSD应用客户端、服务发现服务框架层(对应NsdService)、MDns后台监视层(对应运行在netd本地服务进程的MDnsSdListener类 )以及MDns后台服务(对应mdnsd本地服务进程)。架构的每层作为其上一层的服务端对上一层提供服务,上层通过connect与下层服务建立连接。其中NsdService 和NSD应用客户端采用JAVA语言实现 ,MDns后台监视采用C++实现,而MDns后台服务为采用C语言的开源代码。四层分别运行在不同的进程,采用相应的跨进程通讯方式进行交互。

      NsdService处于整个层次的承上启下层,其通过NsdManager对上层应用客户端提供调用和回调服务,NsdManager客户和NsdService服务之间采用AsyncChannel异步通道进行消息交互。NsdService服务对下在其NativeDaemonConnector线程对象中使用UNIX SOCKET接口与MDns后台监视层建立跨进程连接,传输命令和接收响应,MDns后台监视层的MDnsSdListener对象运行在netd本地服务中。

       在MDnsSdListener类中调用mDNSResponder开源工程提供的客户端桩接口与MDns后台服务建立本地SOCKET通讯,并采用Monitor对象来启动MDns后台服务,实现MDns后台服务的事件监听和事件回调处理等工作。MDnsSdListener及Monitor对象与MDns后台服务的交互也是采用UNIX SOCKET机制进行跨进程交互。

      MDns后台服务的整个实现代码及客户端的桩实现由第三方工程mDNSResponder提供,代码位于 external目录下 的mdnsresponder中,包括mDNSCore(包括MDNS核心协议引擎代码)、mDNSShared多个平台共享的非核心引擎代码、mDNSPosix  Posix平台相关代码、Clients包括如何使用后台服务提供的API的客户端例子代码等四个目录,整个工程编译生成一个mdnsd后台服务和一个MDns监视层使用的库libmdnssd,而Clients中的代码生成一个dnssd执行文件用于测试。

             一个应用为了让网络上的其它应用发现它需要通过网络声明自己,即服务登记,这通过调用NsdManager的registerService接口实现。

               下面分步骤描述服务登记流程。

     1、应用通过调用Context.getSystemService(Context.NSD_SERVICE)获得NsdManager的实例。

      在NsdManager的实例化过程中对使用到的资源进行实例化,包括调用NsdService的getMessenger函数获得服务的Messenger对象用作客户端消息的发送目标,实例化和启动事件处理线程HandlerThread及实例化事件接收处理对象ServiceHandler,AsyncChannel对象的实例化并且调用AsyncChannel对象的connect函数与目标建立连接。

     在NsdService服务接收到连接消息后,实例化一个服务端的AsyncChannel对象,并根据消息的源和服务端的AsyncChannel对象实例化一个ClientInfo对象放入mClients HashMap数组中。

         2、应用调用NsdManager实例的registerService接口,registerService接口参数中包含一个NsdServiceInfo参数(指示要登记的服务信息)、一个protocolType参数(指定协议类型)以及一个监听对象listener,用来接收响应事件回调。

       在registerService接口中调用putListener函数分别把NsdServiceInfo参数和监听对象listener保存到mServiceMap和mListenerMap的映射数组中,并返回数组的键值key;然后registerService通过NsdManager的AsyncChannel对象向目标发送REGISTER_SERVICE消息,发送的消息参数包括putListener函数返回的key以及NsdServiceInfo信息。

         3、NsdService服务收到REGISTER_SERVICE消息后,首先根据消息源从mClients数组中获得clientInfo对象,然后调用getUniqueId获得一个UniqueId作为登记请求ID;接着调用服务端的registerService函数,registerService的参数为UniqueId和消息传进来的NsdServiceInfo信息。在registerService函数中调用NativeDaemonConnector对象的execute函数,execute函数的命令参数为”mdnssd”,其它参数包括登记命令名称标示"register"、登记ID、从NsdServiceInfo中获得的ServiceName、ServiceType和port等参数。

       NativeDaemonConnector对象在NsdService服务实例化时实例化, NativeDaemonConnector对象实例化mSocket参数为"mdns",mCallbacks参数指向NsdService服务内部NativeCallbackReceiver对象。NativeDaemonConnector对象本身是一个派生自Runnable的线程对象,因此其线程函数run也在实例化后启动。

     在run函数中首先实例化和启动了一个事件处理线程HandlerThread及其事件处理Handler,接着进入while循环调用listenToSocket函数。

        listenToSocket首先实例化一个本地socket对象,LocalSocket对象的LocalSocketAddress地址的 Socket名称为已初始化的mSocket,并使用该地址调用connect函数,从init.rc 可以看到名称为"mdns"的Socket对应的本地服务为netd,因此NativeCallbackReceiver对象与netd服务建立了连接;然后listenToSocket函数调用socket的getInputStream和getOutputStream函数获得输入和输出流对象;最后listenToSocket函数进入while循环不断从输入流读取事件进行分析。解析后的事件发给HandlerThread线程的Handler函数进行处理,在Handler函数中调用mCallbacks的onEvent回调函数,即NsdService服务内部NativeCallbackReceiver对象的onEvent回调函数。

        4、在NativeDaemonConnector对象的execute函数中首先根据传进的参数调用makeCommand函数生成一个字符串类型的命令,然后调用本地socket的输出流对象 mOutputStream的write函数来发送命令。

        5、在本地服务netd的进程中调用其MDnsSdListener对象的startListener函数启动命令的监听。

     MDnsSdListener对象通过FrameworkListener间接派生自SocketListener,在MDnsSdListener对象实例化时其成员mSocketName初始化 为"mdns",因此对应的socket通道和NativeCallbackReceiver对象中的socket通道相同。MDnsSdListener实例化时还初始化一个Monitor对象和一个FrameworkCommand类型的Handler对象。

     Handler对象初始化时其mCommand属性赋值为"mdnssd",用来和发送来的命令匹配,Handler对象也保存到FrameworkCommand命令列表对象中mCommands。

    Monitor对象实例化时调用socketpair函数建立一个Socket组mCtrlSocketPair,还创建一个监听线程,线程中调用Monitor对象的run函数。

         6、startListener函数首先调用android_get_control_socket函数根据mSocketName名称获得其SOCKET fd;然后调用listen函数监听socket通道;

        然后创建一个线程,在线程中执行runListener函数,在runListener函数循环调用accept接收客户端连接。当有客户端连接后,根据accept返回的socket fd实例化一个SocketClient对象保存到SocketClient对象列表中mClients,并调用onDataAvailable函数。

             onDataAvailable函数调用read函数读取客户端发送的命令,并调用dispatchCommand函数提交命令。

      在dispatchCommand函数中解析命令参数,并与mCommands命令对象列表进行命令匹配,并调用匹配后命令对象的runCommand函数,这里即调用MDnsSdListener对象中的Handler对象的runCommand函数。

        7、在Handler对象的runCommand函数中进行命令参数的匹配,这里匹配的是"register",因此在获得命令参数后调用serviceRegister函数,serviceRegister函数参数包括匹配的SocketClient对象以及命令参数信息。

        8、在serviceRegister函数中,首先调用mMonitor的allocateServiceRef函数根据请求ID实例化一个Element对象放入链表中,并返回Element对象的DNSServiceRef指针,DNSServiceRef指向_DNSServiceRef_t结构,其成员包括DNS操作或应答类型,接收消息回调接口、客户端回调和上下文、客户端与服务端连接socket等参数。

      然后调用DNSServiceRegister函数,DNSServiceRegister函数用来向本地MDns后台服务发起连接和消息请求,DNSServiceRegister函数的参数包括allocateServiceRef函数返回的DNSServiceRef指针变量以及serviceRegister传进来的命令请求参数,以及事件接收回调函数MDnsSdListenerRegisterCallback。

    在DNSServiceRegister函数调用后接着调用mMonitor的startMonitoring函数,参数为请求ID,startMonitoring函数用来准备与服务器已建立连接的SOCKET监视通道和启动监视通道的监听。最后调用SocketClient对象的sendMsg函数向客户端返回CommandOkay应答消息。

            9、DNSServiceRegister函数为mDNSResponder开源工程提供的客户端调用API接口,用来与MDns后台服务建立连接,并向其提交请求。

            在DNSServiceRegister函数中首先通过ConnectToServer函数与MDns后台服务建立连接。

    在ConnectToServer函数首先实例和初始化一个_DNSServiceRef_t类型DNSServiceOp变量,然后创建一个本地socket,且新建socket的文件句柄赋值给DNSServiceOp对象的sockfd。   

            然后调用connect与MDns后台服务建立连接,最后把实例化后的DNSServiceOp对象通过DNSServiceRef参数带回。

        ConnectToServer函数返回后接着调用create_hdr函数为实例化一个ipc_msg_hdr类型的请求消息,并对请求消息赋值后连同ConnectToServer函数带回的DNSServiceRef参数一同传给deliver_request函数,通过deliver_request函数提交请求。

             10 、在Monitor对象的run函数中循环对mPollFds进行poll操作。

      在startMonitoring函数通过向mCtrlSocketPair[1]写入RESCAN命令后,由于mPollFds[0].fd指向mCtrlSocketPair[0],因此mMonitor的run函数在mPollFds[0]通道读取到RESCAN命令并调用RESCAN函数,在RESCAN函数中根据已建立的与服务器的连接为mPollFds的其它通道赋值,这些mPollFds通道的文件句柄位赋值为服务器已建立连接的socket 的句柄。

        在服务端的响应事件到来时在这些通道poll到事件,然后调用DNSServiceProcessResult函数,参数为DNSServiceRef。

           11、 在DNSServiceProcessResult函数中读取响应事件和数据,并调用DNSServiceRef参数的事件回调ProcessReply函数,即对于服务登记请求对应的是MDnsSdListenerRegisterCallback函数。

     在MDnsSdListenerRegisterCallback中向Handler对象的监听对象的sendBroadcast函数发送ResponseCode::ServiceRegistrationSucceeded应答消息,Handler对象的监听对象为MDnsSdListener对象本身,因此这里调用SocketListener的sendBroadcast函数。

    在sendBroadcast函数中遍历mClients对象的成员对象,并调用其调用sendMsg函数,即调用SocketClient的sendMsg函数。

    在sendMsg函数中通过与客户端(即NsdService服务的NativeDaemonConnector对象)建立的SOCKET向客户端发送应答消息。

          12、在NsdService的NativeDaemonConnector对象的listenToSocket函数 收到服务端的应答消息后,调用NsdService服务内部NativeCallbackReceiver对象的onEvent回调函数。

    在onEvent回调函数中向NsdService服务的状态机发送NsdManager.NATIVE_DAEMON_EVENT事件,假如这时NsdService服务处于EnabledState状态,状态机收到NsdManager.NATIVE_DAEMON_EVENT事件后调用handleNativeEvent函数。 

     handleNativeEvent函数首先根据响应消息的请求ID从mIdToClientInfoMap中获得先前客户端建立连接时保存的clientInfo对象及从clientInfo对象获得clientId,然后执行响应事件代码为NativeResponseCode.SERVICE_REGISTERED的事件处理,事件处理先根据返回的响应事件实例化一个NsdServiceInfo对象,然后通过clientInfo中的AsyncChannel对象成员向NsdService服务的客户端发送NsdManager.REGISTER_SERVICE_SUCCEEDED响应事件。

     13、NsdManager的事件接收对象ServiceHandler接收到NsdManager.REGISTER_SERVICE_SUCCEEDED响应事件,在其handleMessage函数中调用其监听对象(NSD应用客户端)的onServiceRegistered回调。到此整个服务登记流程结束。

             服务发现和服务地址解析流程采用服务登记流程基本相同的流程。在服务发现和服务地址解析后就可以向服务收发数据了。

                                                                                                              

                                                                                                                版权所有,转载时请尊重原创显要处注明链接,谢谢!

    第十七篇 --ANDROID DisplayManager 服务解析一

     第十五篇 Android 的Backup服务管理机制--助手模式

    
    展开全文
  • 使用 Avahi 命令行程序发现服务

    千次阅读 2014-01-16 09:56:32
    使用 Avahi 命令行程序发现服务 如果您使用的是 Linux 计算机,那么您可以使用 Avahi 来浏览以查找本地网络上广播的服务。 准备工作: 您必须安装适用于您所用的 Linux 操作系统的 Avahi RPM 包,然后才能使用...

    使用 Avahi 命令行程序发现服务

    如果您使用的是 Linux 计算机,那么您可以使用 Avahi 来浏览以查找本地网络上广播的服务。

    准备工作: 您必须安装适用于您所用的 Linux 操作系统的 Avahi RPM 包,然后才能使用这些命令行程序。

    使用 avahi-browse 命令行程序 /usr/bin/avahi-browse

    使用 avahi-browse 命令行程序执行以下操作:
    • 在网络上浏览以查找所有 mDNS 广播
    • 对执行广播的设备的主机名和 IP 地址进行解析

    Avahi-browse 命令行选项:avahi-browse <options> <service type>

    将以下命令行选项与 avahi-browse 程序配合使用:
    选项 描述
    -d <domain> 指定想要在其中浏览以查找服务的域。如果您不指定域,那么将浏览所有的域。IBM® Security Network Protection 设备在 .local 域上进行广播。
    --resolve 显示 IBM Security Network Protection 设备的主机名和 IP 地址,包括服务通告字符串。
    示例: "ISNP 5.1 XGS 5100 [serial number]"
    -t 在转储已命名的服务的最新列表后终止 avahi-browse 程序,avahi-browse 程序将不再运行或侦听新广播。
    -a 显示网络上的所有服务广播。您不必为此命令行选项指定 <service type>
    --no-db-lookup 指示 avahi-browse 程序不要转换服务类型。
    示例: 将 _ssh._tcp 转换为更加友好的名称(例如,“SSH 远程终端”),或将 _http._tcp 转换为“网站”

    在网络上发现 IBM Security Network Protection 设备后,请在浏览器中浏览到设备主机名或 IP 地址,以访问本地管理接口。

    使用 avahi-discover-standalone 命令行程序 /usr/bin/avahi-discover-standalone

    avahi-discover-standalone 命令行程序是显示全部域中的所有可发现服务的 X Window 程序。您只能从 X Window 会话中运行此程序。

    此命令行程序的作用与 avahi-browse -a --resolve 命令的作用相同。在网络上发现 IBM Security Network Protection 设备后,请在浏览器中输入设备主机名或 IP 地址,以访问本地管理接口。

    展开全文
  • 【CDH CM版本5.13以下】通过Parcel对spark2版本升级无法发现服务前言现象报错报错原因新升级方案操作留档准备升级升级验证版本回退回退验证后记 前言 公司对于CDH5.10(注意这个版本)有三个物理集群(非云服务,自有...

    【CDH CM版本5.13以下】解决「通过Parcel对spark2版本升级无法发现服务」问题

    前言

    公司对于CDH5.10(注意这个版本)有三个物理集群(非云服务,自有机房),其中两个作为生产,一个作为测试,。生产集群目前都处于满负荷运载的状态,随着业务数据增生,计算方面的瓶颈已较为明显。
    对于生产集群的性能提升团队已经想了很多办法,从jar、脚本、底层文件这些都进行了调整,虽然有效果,但还是存在不少问题。
    而对于分布式计算框架+引擎的spark来说,目前我们使用的版本还停留在2.1,经过商讨,决定对这块进行升级,打算从spark2.1升级到spark2.4。
    那由于生产集群每天有数千作业要跑,直接在生产集群上测试方案是不可行的,于是我先在测试集群上进行了升级测试,结果是整个升级过程十分顺利,于是我信心满满地在一个普通的周六和同事配合停掉了一切计算任务,开始进行生产集群上spark的升级,结果坑出现了!

    现象

    尽管spark相关包裹都放在了应在的位置上,相应的权限也都做了更改,甚至Pacel都进行了正常地激活、分配,但是在添加服务至集群的时候,我惊愕地发现spark2服务不见了,没错就是这么突然!

    报错

    有个有趣的现象是:
    当我把SPARK2_ON_YARN-2.1.0.cloudera1.jar重新放入csd文件夹下,重启CM服务后spark2服务又奇迹般出现。
    也就是说问题是在于SPARK2_ON_YARN-2.4.0.cloudera2.jar不能被识别,查看/var/log/cloudera-scm-server下的cloudera-scm-server.log后,果然发现了异常:

    2020-08-22 15:06:13,355 WARN mian:com.cloudera.csd.components.CsdLocalRepository: 
    Skipping[/opt/cloudera/csdSPARK2_ON_YARN-2.4.0.cloudera2.jar]:
    {
     Could not read service descriptor for csd [SPARK2_ON_YARN-2.4.0.cloudera2.jar]: Could not resolve type id 'provided' into a subtype of [simple type,class com.cloudera.csd.descreptors.parameters.Parameter<java.lang.Object>] at [Source: [B@#1f408ab6; line: 124,column: 45](through reference chain: ServiceDescriptor["parameters"])]
    }
    

    这段异常的大致意思是不能识别SPARK2_ON_YARN-2.4.0.cloudera2.jar里面的一些子类型而导致跳过了这个包,从而在我们的CM页面上添加服务时就不出现spark2服务了。

    报错原因

    为什么对于CDH5.10升级spark2会有这个异常?
    又为什么测试集群上一样是CDH5.10环境,却不会报这样的异常?
    对这个异常和现象我进行了很长很长时间的搜索,中文回答大多集中在文件权限和csd文件位置这两块,对于这两方面内容我很确定自己的操作在这上面没有失误。当我搜遍全网(墙内)也没能发现什么有效的信息的时候,我近乎放弃。
    但天无绝人之路,冷静了一会儿,我也察觉到可能是环境出了问题,这时我搜到了一篇外网的提问帖子Installing Nifi with cloudera ,这个老兄是想在cloudera安装Nifi,但也是在激活并分配包裹又重启CM之后,怎么也发现不了Nifi服务,与我的情况十份类似。
    还有另一篇Problem for adding cdsw service ,这两个帖子的回答都很有价值,
    其中有个大佬的回答帮助了我:
    在这里插入图片描述
    他大致讲到(我也是靠翻译才读懂),因为CM版本的问题,导致组件识别的不兼容,这一下真的是醍醐灌顶,我立马意识到问题的关键,于是我去查看了测试集群的版本信息:
    在这里插入图片描述
    生产集群的版本信息:
    在这里插入图片描述
    看到这一幕,我如同遭受雷击,当时虎躯一震,嘴里大骂“王德发”,既有苦心找到问题的关键的喜悦,又有因为这种低级问题白费精力的懊恼!
    测试集群的CM不知道被哪个升级到5.15(在2018年10月份的时候),但是用的CDH版本仍然是5.1,所以从外部看来生产集群的环境与测试集群如出一辙,难以发现有什么差异,但二者对于服务组件的支持程度是不一致的,这也是为什么测试环境能够识别spark2.4服务而生产环境不能的原因。

    新升级方案

    在这种情况下,如果仍需要对spark2进行升级,则先要对CM进行升级(CM调整到5.13以上,CDH版本保持5.10不变),然后在对spark2进行升级。

    操作留档

    这里对我在测试集群所做的spark2版本升级和版本回退操作做个记录.

    准备

    进入spark2.4Parcel下载地址下载文件:

    SPARK2-2.4.0.cloudera2-1.cdh5.13.3.p0.1041012-el7.parcel
    SPARK2-2.4.0.cloudera2-1.cdh5.13.3.p0.1041012-el7.parcel.sha1
    manifest.json
    

    进入csd jar下载地址下载文件:

    SPARK2_ON_YARN-2.4.0.cloudera2.jar
    

    注意
    manifest.json页面可能不能下载,考虑复制下载链接,然后在linux命令行下使用wget手动下载。

    文件均成功下载后,将四个文件打包命名为:spark2.4.0-129-data-test.zip
    上传spark2.4.0-129-data-test.zip至生产CM Server节点上的cd /data/spark-update目录下,依次执行:

    cd /data/spark-update
    unzip spark2.4.0-129-data-test.zip
    mv /opt/cloudera/parcel-repo/mainifest.json 	/opt/cloudera/parcel-repo/mainifest_CDH5.json
    mv SPARK2-2.4.0.cloudera2-1.cdh5.13.3.p0.1041012-el7.parcel.sha1 	SPARK2-2.4.0.cloudera2-1.cdh5.13.3.p0.1041012-el7.parcel.sha
    mv SPARK2-2.4.0.cloudera2-1.cdh5.13.3.p0.1041012-el7.parcel     	/opt/cloudera/parcel-repo
    mv SPARK2-2.4.0.cloudera2-1.cdh5.13.3.p0.1041012-el7.parcel.sha    	/opt/cloudera/parcel-repo
    mv manifest.json    /opt/cloudera/parcel-repo
    mv SPARK2_ON_YARN-2.4.0.cloudera2.jar    /opt/cloudera/csd
    

    版本升级

    进入cloudera主页面,先确保spark2服务停止:
    在这里插入图片描述
    然后删除spark2服务:
    在这里插入图片描述
    接着执行命令重启CM:

    service cloudera-scm-agent restart
    service cloudera-scm-server restart
    

    重启完成后,重新登录,依次点击 主机 - Parcel-spark2-分配-激活spark2.4.0,等待激活完成:
    在这里插入图片描述
    在这里插入图片描述
    点击集群添加服务:
    在这里插入图片描述
    勾选spark2点击继续:
    在这里插入图片描述
    选择依赖关系:
    在这里插入图片描述
    接下来依次选择主机、继续、审核项目、继续后等待添加完成就可以了:
    在这里插入图片描述
    最后,返回页面,cloudera提示过期配置,重启所有服务:

    在这里插入图片描述

    升级验证

    执行 spark2-shell,查看spark版本:
    在这里插入图片描述
    命令执行正常:
    在这里插入图片描述

    版本回退

    这里的回退是指从spark2.4回退到spark2.1,是在升级过程出现问题,需要回到以前的版本时的操作,先执行:

    mv /opt/cloudera/parcel-repo/mainifest_CDH5.json 	/opt/cloudera/parcel-repo/mainifest_CDH5_SPARK2.4.json
    mv /opt/cloudera/parcel-repo/mainifest_CDH5.json 	/opt/cloudera/parcel-repo/mainifest.json
    

    然后进行【升级】的各项操作,包含删除spark2.4、激活spark2.1.0,添加spark2服务,都完成后,shell base环境执行 spark2-shell,查看spark版本并执行命令,恢复spark2.1.0并使用正常(可能spark2.1.0重启history会报错,那是因为Parcel中的spark2.4服务没有移除,导致csd版本出问题,彻底移除后重启即可)。

    回退验证

    执行 spark2-shell,查看spark版本:
    在这里插入图片描述
    命令执行正常:
    在这里插入图片描述

    后记

    希望这篇博客能够帮助到你,有问题留言交流。

    展开全文
  • 今天在用springcloud+consul注册服务时,出现了critical红叉报错,这导致我消费者服务调用提供者服务时一直出现“No instances available for XXX”错误,最后发现原来是我的服务配置文件 yml里多谢了一个host ...

    今天在用springcloud+consul注册服务时,出现了critical红叉报错,这导致我消费者服务调用提供者服务时一直出现“No instances available for XXX”错误,最后发现原来是我的服务配置文件 yml里多谢了一个host在这里插入图片描述

    展开全文
  • 在这里,你将了解 Kubernetes 集群如何实现通过服务名,进行服务发现,负载均衡,调用后端服务。 这里,我们以服务名为ticknet为例,假设我们要访问内部服务ticknet的某个http接口,则,我们的请求链接格式可以是:...
  • WCF 4.0中的动态发现服务WS-Discovery

    千次阅读 2009-12-15 22:20:00
    现在,WCF 4.0中提供了发现服务的支持,当我们再想调用一个服务时,没必要去知道该服务的具体地址,WCF 4.0实现了OASIS的WS-Discovery标准,相关的类定义在System.ServiceModel.Discovery命名空间中。这是一个单独的
  • 1. 创建自动发现 配置-&gt;自动发现-&gt;创建发现规则 设置名称 配置IP范围 设置延迟时间 设置IP地址为唯一性准则 启用发现规则 2. 创建动作 配置-&gt;动作-&gt;创建动作 2.1 设置...
  • 【BLE】CC2541之发现服务与特征值

    万次阅读 2015-07-16 12:33:08
    本文以SimpleBLECentral工程为例,介绍CC2541作为主机时是如何发现从机的服务和特征值的
  • <蓝牙BLE>cc2541发现服务与特征值

    千次阅读 2015-11-05 22:27:50
    声明,本文转载自“甜甜的大香瓜”的博客,原文地址如下: ...本篇以SimpleBLECentral工程为例,解析CC2541作为主机时是如何发现从机的服务和特征值的。 二、实验平台 协议栈版本:BLE-CC254x-1.3.2 编译软件:I
  • 查看窗口中如果发现“ EXITING DUE TO SIGNAL 28 Exit reason 5”如此字眼,那么说明是你计算机的防火墙设置影响了Arcgis的许可服务检测。 解决办法: 1、关闭防火墙; 2、重启“许可服务” 3、再次诊断,是否...
  • 如题,测试了在每次请求时从consul获取服务发现Service().Result这一步很慢,大概需要两秒。这基本不可用呀。难道只能在客户端启动的时候从consul获取服务?但这样好像就丢失了服务的自动注册与发现的功能了呀,从...
  • 服务发现服务注册

    千次阅读 2018-06-10 10:17:52
    一 硬编码问题1 适用场景有局限:如果服务提供者的网络地址(IP和端口)发生了变化,将会影响服务消费者。例如,用户微服务的网络地址发生了变化,就需要修改电影微服务的配置,...二 服务发现服务提供者、服务消...
  • spring cloud 为开发人员提供了快速构建分布式系统的一些工具,包括配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等。它运行环境简单,可以在开发人员的电脑上跑。另外说明...
  • NsdService服务发现协议

    千次阅读 2013-03-28 20:42:32
    自android 4.1 开始实现了一个网络服务的发现服务NsdService,其基于苹果的Bonjour服务发现协议,支持远程服务的发现和零配置。  Bonjour协议包括IP地址的自动分配、服务名称与地址的转换以及服务的发现三部分...
  • Istio:服务发现和Pilot的架构机制

    千次阅读 2020-01-11 23:03:09
    Istio服务发现 Istio服务配置 stio服务发现&规则管理与Kubernetes结合 ShowCase Istio架构&Pilot介绍 Istio架构 Pilot功能 服务发现 服务配置 Istio服务发现 服务发现基本原理 a.app 88.88....
  • python zookeeper 服务发现

    千次阅读 2016-07-14 15:33:13
    如果你开发的是一个小系统,那么完全没有必要应用这种技术,因为,你面临的问题不是如何发现服务。对于那些大型的,需要强大处理能力的系统来说,有一个讨厌的问题,那就是如何有效的管理这些服务。  举一个简单的...
  • Eureka服务发现与消费

    千次阅读 2018-07-13 19:47:30
    一 介绍构建一个服务消费者,它主要完成两个目标,发现服务以及消费服务。发现服务任务由Eureka客户端完成,而服务消费任务由Ribbon完成。Ribbon是基于HTTP和TCP的客户端负载均衡器,它可以在客户端中配置...
  • springcloud服务发现

    万次阅读 2019-10-15 22:45:30
    下面我们接着上一篇eureka的自我保护继续讲springcloud服务发现 controller层代码: package com.atguigu.springcloud.controller; import java.util.List; import org.springframework.beans.factory....
  • 简单服务发现协议SSDP

    千次阅读 2014-04-16 14:23:06
    SSDP:Simple Sever Discovery Protocol,简单...协议客户端在保留的多播地址:239.255.255.250:1900(IPV4)发现服务,(IPv6 是:FF0x::C)同时每个设备服务也在此地址上上监听服务发现请求。如果服务监听到的发现请
  • kubernetes 服务发现和负载均衡

    万次阅读 2018-06-24 15:44:38
    kubernetes中如何发现服务如何发现pod提供的服务如何使用kube-dns发现服务 service:服务,是一个虚拟概念,逻辑上代理后端pod。众所周知,pod生命周期短,状态不稳定,pod异常后新生成的pod ip会发生变化,之前pod...
  • SSDP,简单服务发现技术

    千次阅读 2016-07-25 16:23:15
    SSDP:Simple Sever Discovery Protocol,简单...协议客户端在保留的多播地址:239.255.255.250:1900(IPV4)发现服务,(IPv6 是:FF0x::C)同时每个设备服务也在此地址上上监听服务发现请求。如果服务监听到的发现请
  • 大纲: • Kubernetes中如何发现服务 • 如何发现Pod提供的服务 • 如何使用Service发现服务 • 如何使用kube-dns发现服务 • kube-dns原理 • 组成 • 域
  • Eureka服务发现注册详解

    万次阅读 2019-06-25 16:48:38
    Eureka是Netflix开发的服务发现框架,本身是一个基于REST的服务,主要用于定位运行在AWS域中的中间层服务,以达到负载均衡和中间层服务故障转移的目的。SpringCloud将它集成在其子项目spring-cloud-netflix中,以...
  • Spring cloud服务发现服务提供者和服务消费者 1.服务提供者 2.服务提供者 3.启动运行 4.综上 1.服务提供者根据上节讲述的服务注册之Eureka注册中心,这节讲述服务提供者和服务消费者,首先新建一个工程,...
  • 如何理解服务注册和服务发现

    千次阅读 2019-05-06 11:49:28
    三者的关系是:通过服务注册机制将启动服务的信息上传至服务注册表,服务发现机制通过服务注册表实时获取可用服务的信息。 服务注册的方式包括:自注册和第三方注册。自注册的意思是当服务启动时,服务自动将信息...
  • SpringCloud服务发现服务注册

    万次阅读 2018-01-17 07:21:05
    服务发现服务注册更多干货spring cloud 微服务spring cloud 知识点服务发现服务注册定制Rabbon客户端负载均衡策略Spring Cloud Feign使用1SpringCloud Feign使用二SpringCloud Hystrix 实现SpringCloud超时机制...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 170,554
精华内容 68,221
关键字:

发现服务