微服务架构实践：服务注册与发现中负载方案选型

Posted 2021-04-14 EAWorld

微服务架构不是银弹，在微服务架构中，我们将面临很多新的问题，这时候势必会引入一个服务注册发现问题。本文作者向大家介绍了随着负载均衡位置的不同，三种主要的服务注册与发现和负载均衡方案。

1.微服务架构下服务注册与发现机制

随着微服务架构深入人心，越来越多的企业将微服务架构付诸实践。相比于传统的单体应用架构，微服务架构有着得天独厚的优势；在传统的单体应用架构下，因为功能集中，代码中心化，一个发布包部署发布在一个进程的应用程序中，单体应用架构已经无法满足企业业务快速变化的需求。一方面，代码维护困难，扩展性较差，灵活性较低，另一方面，系统的修改成本，维护成本在增加以及构建时间，发布周期很长。而微服务架构，因为服务之间独立部署，每个服务在开发，测试，部署的时候，无论是开发周期还是难易程度，都比单块应用要好。

2.常见的服务注册与发现的方案

1.集中式负载均衡方案

集中式负载均衡也叫服务端负载均衡，如图1所示，负载均衡器在一台单独的主机上，可以采用软负载，如nginx，apache等，也可以采用硬负载，如F5等，它负责多实例服务的负载均衡，客户端直接通过域名访问负载均衡器，DNS服务器将域名解析到负载均衡器IP上：

（图1 集中式负载）

该方案实现较为简单，仍是业界的主流，可以充分利用负载均衡器的能力，根据不同的负载策略将请求分发到后面的服务实例上；同时，该方案缺点也很明显，负载均衡器存在单点问题，所有的流量都需要通过负载均衡器，如果负载均衡器存在问题，则直接导致服务不能正常提供服务；中间经过负载均衡器做代理，性能也有一定损耗。

2.客户端负载均衡方案

（图2 客户端负载）

该方案在解决了服务端负载的单点问题，每个客户端都实现了自己的负载功能，负载能力和客户端进程在一起，和客户端的生命周期一致，如果负载均衡进程down了，则客户端也down了，而且只影响本身客户端，不会影响其他客户端；同时，该方案也有一定的缺点，负载要求每个客户端自己实现，如果不同的技术栈，每个客户端则需要使用不同的语言实现自己的负载能力，技术难度较大；业界的motan，dubbo采用此方案做服务注册与发现。

3.客户端主机独立负载均衡方案

（图3 客户端独立主机负载）

该方案是一个典型的分布式方案，没有单点问题，如果一个主机的负载均衡器出问题，只影响一个节点调用，不影响其他的节点，负载均衡器本身负载也较小，性能损耗较低；同时也不需要多种语言实现自己的负载能力，负载能力是公用的；但是该方案部署复杂，维护困难，出了异常之后，调试负载，定位问题都比较麻烦。

 

3.新一代的选择

（图4 DevOps 逻辑视图）

服务注册与发现在DevOps的技术平台中，作为基础框架给上层DevOps后台服

务使用。

DevOps的运行视图如图5所示：

（图5 DevOps运行视图）

从图中可以看出，微服务之间存在错综复杂的调用关系，SRD主要解决各个微服务之间服务注册与发现的问题。在数字化企业云平台中，我们综合考虑了服务注册与发现几个方案的优缺点，同时结合我们平台的一些特点及技术栈，我们考虑了以下问题： 

1. 如何选择负载方案，我们选择了和方案三类似的负载方案；因为方案三弥补了前面两种方案的优缺点，带来的问题是部署复杂，但是我们采用K8S管理微服务的部署，负载本身的复杂由K8S自己解决了，不需要我们花很多成本解决部署难题。 

2. 在选择客户端主机独立负载的情况下，无法在服务提供者启动时获取到Cluster IP，我们的解决办法是通过域名访问，域名默认和当前应用名保持一致。 

下面是我们服务注册与发现的架构图：

（图6 新一代服务注册与发现架构图）

服务提供者在启动时，将当前应用的域名注册到服务注册表，客户端通过服务注册表拿到服务提供者的服务域名，客户端通过dns解析到Cluster IP，然后发起调用。

杨勇

现任普元SOA产品部高级软件工程师，曾带领团队完成BPFF，BPS Platform 7.2等研发项目。互联网技术高手，分布式，云计算，机器学习技术爱好者。

关于EAII

EAII（Enterprise Architecture Innovation Institute）企业架构创新研究院，致力于软件架构创新与实践，加速企业数字化转型。

eaworld是EAII的官方微信账号。