1. 背景
在微服务架构中，每个微服务通常有多个实例，每个实例具有不同的位置，而且实例会动态变化，比如在负载发生变化时服务会进行扩容或缩容，失败或者更新，服务实力的配置变化等，都会导致服务实例地址的变化。因此使用微服务架构开发的应用，必须通过服务注册和发现技术解决此问题。
2. 服务发现
使用发现服务来发现web空间提供的服务。发现服务是一个目录服务，服务在其中注册，并根据它的属性进行查找，简单的说就通过服务发现找你你想调用具体应用的物理信息（ip， port等）。
有两种主要的服务发现模式：客户端服务发现， 服务端服务发现
上图展示了客户端发现模式的架构，简单来说：
Service Registry 类似企业黄页，保存了所有服务的信息， client通过注册表找到对应的企业电话（是一个list）， 然后客户端使用自身提供的负载均衡算法，选择需要的电话。
当然client可以保存查找过的地址（缓存）而不需要每次都去Service Registry 获取； 因为服务的实例（企业信息，电话）可能终止（从Registry删除）， 或者新的服务实例加入（新的企业），使得本地缓存和Registry可能有差异，（从分布式CAP的角度，对于服务发现，可用性比数据一致性更加重要，AP胜过CP，后文会简单介绍CAP）， 需要服务实例的注册表通过心跳机制进行更新。
服务端服务发现模式
本质上就是LB从客户端解耦了出来， 常见的服务发现Eureka, etcd， Consul，Zookkeeper，最近阿里出了Nacos， 本文不详细介绍工具的使用。
3. 服务注册
服务注册分为，Self-Registration Pattern 和 Third-party registration pattern。之前没了解过Thrid-party，本文主要介绍Self-Registration
以Eureka为例， 通过DiscoveryClient这个annotaition， 在应用启动时，被加载到容器中，并注册到注册中心，然后通过CacheRefreshThread 和 HeartbeatThread 执行刷新注册信息到本地和续约任务，思路不是复杂，对于服务注册，简单带过。
4. CAP
说说自己的理解，引用我知乎上关于CAP的回答，举个例子， 服务或者存储部署的机器是分region或者zone的， 比如，北京移动机房，北京联通机房， 上海铁通机房，正常情况下虽然处于不同的网络或者运营商，但是实际是可以联通的。 但是如果部署在一个机房，那么出口的网络，光纤断了（也可能是入口负责调度的如nginx等不可用了等），或者运营商提供的网络出了问题，那么会造成整个服务的不可访问的问题， 所以要分区， 分到不同的机房， 不同的运营商。就类似分region或者分zone。
这样如果一个机房出了问题，或者一个一个网络出了问题，还可以访问其他的网络或者机房了， 这样就提高了分区容错性（P）。
顺着这样一个思路， 是不是越多机房（全国各个城市，国外的），越多运营网络越好？越多可用性（A）提高了， 这个就带来了一个新的问题， 如果访问分不到不同的机房或者网络，数据存储到了对应的机房，机房见的访问速度和跨城市的访问延迟比较大， 这样写入到上海联通机房的数据同步到北京移动机房的速度就会比较长，这样造成一个新的问题就是，上个用户如果落到北京机房查询相关的数据，这个时候上海机房的数据可能还没有来得及复制到北京机房， 这样造成了一个问题就是一致性（C）的问题。
所以正常情况下， 都是在A -- 可用性和C--一致性之前的权衡， 是要更多的机房保证可用性，还是为了快速的节点同步保证一致性。
架构本身就是基于业务形态的平衡的权衡， 在CAP这个问题中，就是A与C的权衡。
5. RDF（Resource Description Framework）， OSLC（Open Services for Lifecycle Collaboration）
从领域模型， 领域规范角度， 服务注册和发现解决了服务实现服务可发现的状态； 在大型公司公，不同的领域，可能由于异构系统，工具，异构平台，不同的UI风格等，服务注册和发现没解决注册服务之前关联和集成关系的问题，比如现在流行的All in one, 期望整合资源，整合系统， 解决系统集成的问题，更大范围的拉通和透明化。
那么就需要借鉴OLCS和RDF的经验， 通过建立领域模型，规范来解决系统间集成的问题。核心的思路就是Linked Data， 通过让各个系统无缝链接起来。
1）服务发现
服务发现是OSLC重要特性之一，也是不太容易理解的地方。OSLC技术规范中的服务接口不是以“固定API”的形式标识，而是通过服务发现的方式由客户端进行层层解析得出。对于客户端而言，只需要知道基础服务的入口地址，即可根据OLSC协议，逐步发现所需要的服务。
从领域模型的角度，领域的scenario可以通过规范有效的组织起来，业务场景的链路或者pattern可以规范化，后续不管是支撑系统变化（从系统A改成系统B），服务版本升级，只要符合领域规范，相关系统不需要做任何系统适配。一方面解决系统集成问题的同时也解决了系统的依赖性。
举个例子， 地图行业，现在有一些坐标规范，但是缺乏某些应用场景的领域模型规范，比如，驾车场景，导航，自动驾驶？等，如果第三方企业想要调用LBS的某些应用场景，需要引入web service， SDK等， 以web service为例，米兔如果想用地图，当时处于不同用户的使用习惯的角度，同时支持了高德和百度，那么在没有领域规范的情况下，需要对高德和百度的API进行适配。如果另一个应用由于某些原因从一个地图迁移到另一个，需要进行很大的适配。
如果介入OSLC的思路，如果规范了领域模型会有什么变化呢？开发只关注resource和对应的资源操作能力（linked data）编程对象就是rdf中的属性和资源（针对接口、规范编程），那么不管切换什么地图应用，底层代码不需要做任何更改。
这个思路也类似于Oauth，数据库driver，但是OSLC思路的高度会更高一个level，在解决领域问题时，面临的问题会更复杂，不仅仅是一个接口的问题。
如下是一个服务发现的关联图。
转载于：https://www.jianshu.com/p/0c3bd308bcba