简单说说服务治理之服务注册和发现

Posted 2021-04-25 比昂日记

最近在准备分布式Topic的分享，逐步总结了一些资料，陆续总结中，今天先简单说说服务注册和发现。

1. 背景

微服务实例在scaling或故障时实例数发生变化

2. 服务发现

使用发现服务来发现web空间提供的服务。发现服务是一个目录服务，服务在其中注册，并根据它的属性进行查找，简单的说就通过服务发现找你你想调用具体应用的物理信息（ip， port等）。

有两种主要的服务发现模式：客户端服务发现， 服务端服务发现。

客户端服务发现模式：

上图展示了客户端发现模式的架构，简单来说：

服务端服务发现模式：

本质上就是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）服务发现

从领域模型的角度，领域的scenario可以通过规范有效的组织起来，业务场景的链路或者pattern可以规范化，后续不管是支撑系统变化（从系统A改成系统B），服务版本升级，只要符合领域规范，相关系统不需要做任何系统适配。一方面解决系统集成问题的同时也解决了系统的依赖性。

举个例子， 地图行业，现在有一些坐标规范，但是缺乏某些应用场景的领域模型规范，比如，驾车场景，导航，自动驾驶？等，如果第三方企业想要调用LBS的某些应用场景，需要引入web service， SDK等， 以web service为例，米兔如果想用地图，当时处于不同用户的使用习惯的角度，同时支持了高德和百度，那么在没有领域规范的情况下，需要对高德和百度的API进行适配。如果另一个应用由于某些原因从一个地图迁移到另一个，需要进行很大的适配。

如果介入OSLC的思路，如果规范了领域模型会有什么变化呢？开发只关注resource和对应的资源操作能力（linked data）编程对象就是rdf中的属性和资源（针对接口、规范编程），那么不管切换什么地图应用，底层代码不需要做任何更改。

这个思路也类似于Oauth，数据库driver，但是OSLC思路的高度会更高一个level，在解决领域问题时，面临的问题会更复杂，不仅仅是一个接口的问题。

如下是一个服务发现的关联图。

服务的发现：

2）基于HTTP的CRUD

基于HTTP的CRUD：

上文提到，领域模型针对的是resource和资源的操作能力，例如提供的CRUD 服务， 如CreationFactory， 只需要关联resource和能力， 不需要关注实现和提供的系统， 比如， 咱们提供了各种扫描工具， Tesla， 贤者石，STC等等， 集成过程中，只要满足领域（扫描）规范，不管换成任何一种实现方式， 其中的创建任务，执行，反馈等相关任务的调用，相关系统不需要做任何更改， 可以看成是在系统集成领域的结构抽象（数据连接抽象）。

如下：一个例子， 说明资源和链接资源，以及能提供的能力。资源具备鉴权，关联，检索等能力。

CreationFactory：

3）标准化的资源描述， 通过RDF（资源描述框架）可以参考，提供了一套统一的描述语言，可以是XML，Json等，来结构化的描述资源和资源之间的关系。

https://www.w3.org/TR/rdf11-concepts/

https://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/

https://tools.oasis-open.org/version-control/browse/wsvn/oslc-core/trunk/specs/oslc-query.html

资源的RDF描述：

资源操作：

规范会带来一定的前期系统复杂性， All in one的过程本来就不是”一蹴而就“的， 从短期， 长期， 从整体业务的需求，逐步整合。

架构本身就是一种权衡和取舍， 人员素质， 能力，规范， 效率，交付短期和长远的利益，在取舍之后不要忘了后面长远的事情。

不管怎样， 创新是公司发展的原动力，永远给创新留出一条开放和包容的态度， 把信息部门看作是一种可能，而不是成本。

跳出固有的本位主义，站在业界的视角， 开源，拉通， 格局就会不一样。

最后，有一颗改变世界的心，仰望星空，脚踏实地，让咱们砥砺前行。

参考：

https://zhuanlan.zhihu.com/p/31862384

http://jasonwilder.com/blog/2014/02/04/service-discovery-in-the-cloud/

https://www.nginx.com/blog/service-discovery-in-a-microservices-architecture/

Microservices_Designing_Deploying.pdf

https://juejin.im/post/5bb77923f265da0af3348aa3

https://microservices.io/patterns/service-registry.html

https://dzone.com/articles/service-registration-and-discovery-amp-configurati

http://www.uddi.org/pubs/Iru_UDDI_Technical_White_Paper.pdf

http://www.mamicode.com/info-detail-2356133.html

https://archive.open-services.net/bin/view/Main/OslcCoreSpecification

THE END

- 晚安 -