[微服务感悟] 服务发现与常见架构

朱雀 2023-06-29 05:41 318阅读 0赞

### 文章目录 ###

*   *   *   *   *  什么是服务发现
                 *  服务发现原始架构
                 *  程序内集成网关架构
                 *  统一网关架构（总线架构）
                 *  service mesh微服务架构

这时一篇务虚的博文，主要记录对微服务发现的感悟。

##### 什么是服务发现 #####

微服务架构中，服务都运行在许许多多的机器中，调用其他服务时首先需要找到这个服务在哪里呢，找服务对应的机器的过程就是服务发现。

##### 服务发现原始架构 #####

最初的做法是在程序中写死服务对应的域名，让运维人员配置域名解析到对应的ngnix网关，网关做负载均衡，分发到对应服务器节点。这种做法相当于程序内保存服务对应域名，ngnix做网关，保存服务器节点地址，并负责负载均衡和转发。

随着业务进一步发展，服务越来越多，服务的节点服务器也越来越多，稍微上点规模的业务，都有20+的服务，每个服务又存在2+个节点服务器。这时如果服务的域名，服务的节点要发生更改，就需要改动很多文件，甚至需要许多服务重新发版，而且随着服务多了，总有某些服务会需要发生更改，这存在极大的工作量和风险。所以服务多了，这套就不适用了。

A域名

B域名

生产服务, 项目配置文件中存在其他服务信息

网关, 负载均衡

A服务节点1

A服务节点2

A服务节点3

网关B

B服务节点1

B服务节点2

##### 程序内集成网关架构 #####

这套架构是在每个程序中都存放所有服务，所有节点的信息，程序自己做负载均衡。同时存在一个服务中心，它负责同步每个服务的最新节点信息，注册服务（当有新服务上线时，像服务中心发送自己的ip和服务名，服务中心添加该条服务信息），健康检查（定时发送心跳包到每个服务，对发送不成功的服务，按下线规则做处理），提供查看所有节点信息的http接口。

这时服务中心就十分重要，如果服务中心挂了，其他服务就不能感知到存在的新的服务变化，所以它一定要高可用。每个服务实际访问的是本地的服务节点信息，那么就一定存在本地和服务中心节点数据不同步的情况，所以从设计上说，这是一个偏向高可用的设计，而不是高一致。

常见的实践是在框架中即成服务节点信息同步，服务发现，负载均衡等功能，程序只实现业务员逻辑。spring cloud便是这一套架构，eureka是服务注册中心，spring cloud框架中集成了服务信息的同步。

这种架构需要统一的框架支持某套服务节点信息同步的通信协议，这会技术栈依赖某一个框架，并不能实现微服务中，每个服务任意使用某个技术栈的愿想。如采用spring cloud做微服务技术栈，那么每个服务都要采用springcloud/boot框架，但是我如果想使用python/go/.net/c++的服务，就不太容易集成到这套架构中去。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1bzQxMDU_size_16_color_FFFFFF_t_70]

##### 统一网关架构（总线架构） #####

这是一种偏向AP的架构，高一致，低可用，每个微服务程序都需要将请求发给服务中心，由服务中心找到对应可用节点，再进行分发。它抽象出的服务中心，负责负载均衡，服务注册，服务转发的功能功能。

这套的好处是，服务中心统一管理所有的服务节点信息，可以保证高一致性，每个服务不用集成负载均衡等模块，不存在框架/代码依赖，每个微服务都可以采用各自技术栈，不受限制。

缺点是每个请求都要穿透一次服务中心，有性能损耗；而且服务中心作用太大，一旦挂掉，所有业务都会停止，只适合内网比较稳定的环境中运行。

服务关键字

客服端服务

服务中心

服务A节点1

服务A节点2

服务B节点1

> 我工作中的某家公司，用的就是这套架构。做法是这样的，规定统一的发送协议，即采用http做通信协议，在请求头中加一个系统code，代表要转发的系统编号。所有请求都要发给middleware（服务中心）的服务做转发，middleware中存有所有服务IP地址；每个服务启动时都会向middleware服务发送注册信息；middleware定期向所有服务发送心跳监控服务是否在线；middleware提供统一的负载均衡策略，熔断策略；middleware提供统一的http接口以供其查询服务器信息，middleware在内网中。

> PS：当时设计这套的架构师称为总线架构，后来被绿厂高薪挖过去搞架构了，他说过去推广这一套。

> 架构如下，不过我已经离职有段时间了，这个架构应该还能再拆拆，合合。如open-Platform、face功能重合，没有合并的原因是历史原因；如middleware可以拆成柜机基本服务和服务中心。  
> ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1bzQxMDU_size_16_color_FFFFFF_t_70 1]

##### service mesh微服务架构 #####

service mesh是现在比较火的概念，它的思想和程序内集成网关架构有点像，不过它的网关在每个系统镜像包中，而不是代码/框架集成在程序中，它配合来使用docker会非常方便。服务中心同步每个容器中网关的服务节点信息，每个程序都向系统/容器内的网关发送请求，网关在进行服务发现和负载均衡，找到对应的容器发送过去。

这套架构也支持每个服务采用各自的技术栈，互不干扰；服务都是通过容器内的网关做转发，即使服务中心不可用，也能使用，是高可用架构

缺点是没启动一个应用，都要重新打一个对应的镜像包，运维工作更加复杂，必须有集成一整套自动化开发部署工具才行，也就是devops工具箱，只有技术实力强的公司可以试试这套。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1bzQxMDU_size_16_color_FFFFFF_t_70 2]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1bzQxMDU_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200110154159409.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1bzQxMDU=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1bzQxMDU_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20200113143423463.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1bzQxMDU=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1bzQxMDU_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20200110154253816.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1bzQxMDU=,size_16,color_FFFFFF,t_70