专业的编程技术博客社区

网站首页 > 博客文章 正文

十年架构师带你深入理解微服务,果然大佬底层都很牛逼,实在佩服

baijin 2024-10-26 08:06:08 博客文章 7 ℃ 0 评论

前言

今天带领大家学习微服务,一步步深入理解,原来微服务还可以这么理解!

微服务

服务注册发现

服务注册就是维护一个登记簿,它管理系统内所有的服务地址。当新的服务启动后,它会向登记簿交待自己的地址信息。服务的依赖方直接向登记簿要 Service Provider 地址就行了。当下用于服务注册的工具非常多 ZooKeeper,Consul,Etcd, 还有 Netflix 家的 eureka 等。服务注册有两种形式:客户端注册和第三方注册。

客户端注册(zookeeper)

客户端注册是服务自身要负责注册与注销的工作。当服务启动后向注册中心注册自身,当服务下线时注销自己。期间还需要和注册中心保持心跳。心跳不一定要客户端来做,也可以由注册中心负责(这个过程叫探活)。这种方式的缺点是注册工作与服务耦合在一起,不同语言都要实现一套注册逻辑。

第三方注册(独立的服务 Registrar)

第三方注册由一个独立的服务Registrar负责注册与注销。当服务启动后以某种方式通知Registrar,然后 Registrar 负责向注册中心发起注册工作。同时注册中心要维护与服务之间的心跳,当服务不可用时,向注册中心注销服务。这种方式的缺点是 Registrar 必须是一个高可用的系统,否则注册工作没法进展。

客户端发现

客户端发现是指客户端负责查询可用服务地址,以及负载均衡的工作。这种方式最方便直接,而且也方便做负载均衡。再者一旦发现某个服务不可用立即换另外一个,非常直接。缺点也在于多语言时的重复工作,每个语言实现相同的逻辑。

服务端发现

服务端发现需要额外的 Router 服务,请求先打到 Router,然后 Router 负责查询服务与负载均衡。这种方式虽然没有客户端发现的缺点,但是它的缺点是保证 Router 的高可用。

API 网关

API Gateway 是一个服务器,也可以说是进入系统的唯一节点。这跟面向对象设计模式中的Facade 模式很像。API Gateway 封装内部系统的架构,并且提供 API 给各个客户端。它还可能有其他功能,如授权、监控、负载均衡、缓存、请求分片和管理、静态响应处理等。下图展示了一个适应当前架构的 API Gateway。

API Gateway 负责请求转发、合成和协议转换。所有来自客户端的请求都要先经过 API Gateway,然后路由这些请求到对应的微服务。API Gateway 将经常通过调用多个微服务来处理一个请求以及聚合多个服务的结果。它可以在 web 协议与内部使用的非 Web 友好型协议间进行转换,如HTTP 协议、WebSocket 协议。

请求转发

服务转发主要是对客户端的请求安装微服务的负载转发到不同的服务上

响应合并

把业务上需要调用多个服务接口才能完成的工作合并成一次调用对外统一提供服务。

协议转换

重点是支持 SOAP,JMS,Rest 间的协议转换。

数据转换

重点是支持 XML 和 Json 之间的报文格式转换能力(可选)

安全认证

1. 基于 Token 的客户端访问控制和安全策略

2. 传输数据和报文加密,到服务端解密,需要在客户端有独立的 SDK 代理包

3. 基于 Https 的传输加密,客户端和服务端数字证书支持

4. 基于 OAuth2.0 的服务安全认证(授权码,客户端,密码模式等)

配置中心

配置中心一般用作系统的参数配置,它需要满足如下几个要求:高效获取、实时感知、分布式访问。

zookeeper 配置中心

实现的架构图如下所示,采取数据加载到内存方式解决高效获取的问题,借助 zookeeper 的节点监听机制来实现实时感知。

配置中心数据分类

事件调度(kafka)

消息服务和事件的统一调度,常用用 kafka ,activemq 等。

服务跟踪(starter-sleuth)

随着微服务数量不断增长,需要跟踪一个请求从一个微服务到下一个微服务的传播过程, SpringCloud Sleuth 正是解决这个问题,它在日志中引入唯一 ID,以保证微服务调用之间的一致性,这样你就能跟踪某个请求是如何从一个微服务传递到下一个。

1. 为了实现请求跟踪,当请求发送到分布式系统的入口端点时,只需要服务跟踪框架为该请求创建一个唯一的跟踪标识,同时在分布式系统内部流转的时候,框架始终保持传递该唯一标识,直到返回给请求方为止,这个唯一标识就是前文中提到的 Trace ID。通过 Trace ID 的记录,我们就能将所有请求过程日志关联起来。

2. 为了统计各处理单元的时间延迟,当请求达到各个服务组件时,或是处理逻辑到达某个状态时,也通过一个唯一标识来标记它的开始、具体过程以及结束,该标识就是我们前文中提到的 Span ID,对于每个 Span 来说,它必须有开始和结束两个节点,通过记录开始 Span 和结束 Span 的时间戳,就能统计出该 Span 的时间延迟,除了时间戳记录之外,它还可以包含一些其他元数据,比如:事件名称、请求信息等。

3. 在快速入门示例中,我们轻松实现了日志级别的跟踪信息接入,这完全归功于spring-cloud-starter-sleuth 组件的实现。在 Spring Boot 应用中,通过在工程中引入 spring-cloud-starter-sleuth 依赖之后, 它会自动的为当前应用构建起各通信通道的跟踪机制,比如:

? 通过诸如 RabbitMQ、Kafka(或者其他任何 Spring Cloud Stream 绑定器实现的消息中间件)传递的请求。

? 通过 Zuul 代理传递的请求。

? 通过 RestTemplate 发起的请求。

服务熔断(Hystrix)

在微服务架构中通常会有多个服务层调用,基础服务的故障可能会导致级联故障,进而造成整个系统不可用的情况,这种现象被称为服务雪崩效应。服务雪崩效应是一种因“服务提供者”的不可用导致“服务消费者”的不可用,并将不可用逐渐放大的过程。

熔断器的原理很简单,如同电力过载保护器。它可以实现快速失败,如果它在一段时间内侦测到许多类似的错误,会强迫其以后的多个调用快速失败,不再访问远程服务器,从而防止应用程序不断地尝试执行可能会失败的操作,使得应用程序继续执行而不用等待修正错误,或者浪费 CPU时间去等到长时间的超时产生。熔断器也可以使应用程序能够诊断错误是否已经修正,如果已经修正,应用程序会再次尝试调用操作。

Hystrix 断路器机制

断路器很好理解, 当 Hystrix Command 请求后端服务失败数量超过一定比例(默认 50%), 断路器会切换到开路状态(Open). 这时所有请求会直接失败而不会发送到后端服务. 断路器保持在开路状态一段时间后(默认 5 秒), 自动切换到半开路状态(HALF-OPEN). 这时会判断下一次请求的返回情况,如果请求成功, 断路器切回闭路状态(CLOSED), 否则重新切换到开路状态(OPEN). Hystrix 的断路器就像我们家庭电路中的保险丝, 一旦后端服务不可用, 断路器会直接切断请求链, 避免发送大量无效请求影响系统吞吐量, 并且断路器有自我检测并恢复的能力。

API 管理

SwaggerAPI 管理工具。

由于swagger功能强大,集成工具非常之多,今天我们主要了解swagger-ui。

  1. 为什么使用swagger-ui?

程序界里面经常传这样一句话,程序员最讨厌的两件事:

1.写注释写文档 2.别人不写注释、不写文档。

为什么这样说?因为管理文档注释比较麻烦,经常会出现API更新了,文档还是老的,各种同步不一致的情况。造成很多问题,从而耽搁彼此的时间,所以大家不太喜欢进行写文档注释。

而之所以使用swagger主要是swagger它可以降低我们前后端开发文档同步问题,swagger可以从我们代码注释里面自动生成API文档,以此方便前端对接使用。

其次它可以展示我们所有接口列表情况,非常方便我们前后端进行接口调试。前端同学对接接口直接在页面就能操作了,完全不需要在postman,PAW这些网络工具进行切换,非常简单方便。

下面我来一个官方的预览图数据表定义:

  1. Django swagger安装使用

接下来我们就来就来讲下安装使用过程,由于我们主要是Python为主,大家介绍swagger-ui,这里面我们简单Django为主介绍下使用:

pip install django-rest-swagger要求: Django 1.8+ Django REST framework 3.5.1+ Python 2.7, 3.5, 3.6

在 INSTALLED_APPS

    INSTALLED_APPS = (
        ...        'rest_framework_swagger',
    )

添加文档地址:

from django.conf.urls import urlfrom rest_framework_swagger.views import get_swagger_view

schema_view = get_swagger_view(title='Pastebin API')

test_urlpatterns = [
    url(r'^#39;, schema_view)  # 这儿你自定义文档目录]#这里面我们需要注意这儿在本地或者测试环境使用,线上不能使用,最简单的办法就是我之前提到过的的,通过环境变量来进行判断当前环境从而是否加上这个test_urlpatterns。if current_env not in ['product', 'staging']:
    url_patterns = url_patterns + test_urlpatterns

最后得到的效果就是类似的效果:


如果配合Django-filter,会更加方便进行前端筛选测试,几乎是对于XXX管理页面就是举手之间。swagger配合Django-REST-Framework可以说大大提高了后端写增删查改(CRUD)并且对接完成的速度。

3.其他语言使用

swagger不仅Python使用,其他语言框架都能进行使用swagger。推荐大家去使用,不管是否是Python程序员。

其他语言工具集成的地址:https://swagger.io/tools/open-source/open-source-integrations/


不清楚还有多少公司,每次API更新了,文档没有更新,造成对接起来彼此不一致的情况,反正听到过身边的朋友反馈过。

如果你发现自己公司有这种情况,赶紧swagger一把梭。

上面就是我对swagger-ui的介绍,实际swagger tools 还有其他两个功能强大的工具 swagger-editor,swagger-codegen。大家感兴趣可以自己去了解。

多多转发关注不迷路,每天更新技术好文~~~~

感谢大家支持术!!!!

本文暂时没有评论,来添加一个吧(●'◡'●)

欢迎 发表评论:

最近发表
标签列表