1.1.3 微服务架构的核心组件
对于开发人员而言,学习微服务架构的主体内容就是学习它的技术体系。同样,不同的开发工具和框架都会基于自身的设计理念给出对应的技术体系及其实现方式。抛开这些具体的工具和框架,我们可以基于目前业界主流的微服务实现技术提炼出一组技术组件,本节将对这组技术组件展开讨论。
1.服务治理
在微服务架构中,服务治理可以说是最为关键的一个技术组件,因为各个微服务需要通过服务治理实现自动化的注册和发现。
试想一下,如果系统中服务数量不是很多,那么我们有很多办法可以获取这些服务的IP地址、端口等信息,管理起来也不是很复杂。但当服务数量达到一定量级时,可能连开发人员自己都不知道系统中到底存在多少个服务,也不知道系统中当前到底哪些服务已经变得不可用。这时候,我们就需要引入独立的媒介来管理服务的实例,这个媒介一般被称为服务注册中心。图1-3展示了服务注册中心的作用。
图1-3 服务注册中心的作用
服务注册中心是保存服务调用所需路由信息的存储仓库,也是服务提供者和服务消费者进行交互的媒介,充当着服务注册和发现服务器的作用。诸如Dubbo、Spring Cloud/Spring Cloud Alibaba等主流的微服务框架都基于Zookeeper、Nacos等分布式系统协调工具构建了服务注册中心。
2.服务路由
现在,我们已经通过注册中心构建了一个多服务的集群化环境,当客户端请求到达该环境时,如何确定由哪一台服务器对请求做出响应就是服务路由问题。可以认为负载均衡是最常见的一种路由方案,常见的客户端/服务端负载均衡技术都可以完成服务路由。在Spring Cloud/Spring Cloud Alibaba等主流的微服务框架中也都内置了客户端负载均衡组件。图1-4展示了注册中心和负载均衡器之间的交互关系。
图1-4 注册中心与负载均衡器之间的交互关系
另外,负载均衡的出发点更多是提供服务分发而不是只解决路由问题,常见的静态、动态负载均衡算法也无法实现精细化的路由管理,这时候我们就可以采用路由规则。路由规则常见的实现方案是白名单或黑名单,即把需要路由的服务地址信息(如服务IP)放入可以控制是否可见的路由池中进行路由。同样,路由规则也是微服务开发框架的一项常见功能。
3.服务容错
对于微服务架构中的服务而言,服务自身会出现失败,还会因为依赖其他服务而导致失败。除了比较容易想到和实现的超时、重试和异步解耦等手段之外,我们还需要考虑针对各种场景的容错机制。图1-5展示了服务容错的常见技术。
业界存在一批与服务容错相关的实现策略,包括以失效转移为代表的集群容错策略,以线程隔离、进程隔离为代表的服务隔离机制,以滑动窗口、令牌桶算法为代表的服务限流机制,以及服务熔断机制。而从技术实现方式上看,在Spring Cloud中,这些机制部分包含在下面要介绍的服务网关中,而另一部分则被提炼成单独的开发框架,例如专门用于实现服务熔断的Spring Cloud Circuit Breaker。而在Spring Cloud Alibaba中也内置了专用的服务可用性框架Sentinel。
图1-5 服务容错的常见技术
4.服务网关
服务网关也叫API(应用程序编程接口)网关,它封装了系统内部架构,为每个客户端提供一个定制的API。在微服务架构中,服务网关的核心要点在于:所有的客户端和消费端都通过统一的网关接入微服务,在网关层处理所有的非业务功能。图1-6展示了服务网关的常见功能。
在功能设计上,服务网关在完成客户端与服务端报文格式转换的同时,可能还具有身份验证、监控、缓存、请求管理、静态响应处理等功能。另外,开发人员也可以在网关层制定灵活的路由策略。针对一些特定的API,我们需要设置白名单、路由规则等各类限制。业界主流的网关系统有很多,例如Spring家族的Spring Cloud Gateway就是其中的代表性实现框架。
图1-6 服务网关的常见功能
5.服务配置
在微服务架构中,考虑到服务数量和配置信息的分散性,一般都需要引入配置中心的设计思想和相关工具。与注册中心一样,配置中心也是微服务架构中的基础组件,其目的也是对服务进行统一管理,区别在于配置中心管理的对象是配置信息而不是服务的实例信息。图1-7展示了配置中心与注册中心之间的交互关系。
为了满足实现要求,配置中心通常需要依赖分布式协调机制,即通过一定的方法确保配置信息在分布式环境的各个服务中都能得到实时、一致的管理。我们可以采用诸如Zookeeper等主流的开源分布式协调框架来构建配置中心。当然,Spring Cloud和Spring Cloud Alibaba也分别提供了专门的配置中心实现工具Spring Cloud Config和Nacos。
图1-7 配置中心与注册中心之间的交互关系
6.服务安全
一般意义上的访问安全性,都是围绕认证和授权这两个核心概念来展开的。也就是说,我们首先需要确定用户身份,然后再确定这个用户是否具备访问指定资源的权限。站在单个微服务的角度,我们希望每次服务访问都能与授权服务器进行集成以便获取访问Token。而站在多个服务交互的角度,我们需要确保Token在各个微服务之间的有效传播。另外,在服务内部,我们可以使用不同的访问策略限制服务资源的访问。图1-8展示了基于Token机制的服务安全实现方案。
图1-8 基于Token机制的服务安全实现方案
为了实现对微服务的安全访问,我们通常使用OAuth2协议来实现对服务访问的授权机制,使用JWT技术来构建轻量级的认证体系。Spring家族也提供了Spring Security和Spring Cloud Security框架来简化这些组件的构建过程。
7.服务跟踪
在微服务架构中,当服务数量达到一定量级时,我们难免会遇到两个核心问题:一个是如何管理服务之间的调用关系;另一个是如何跟踪业务流的处理过程和结果。这就需要构建分布式服务跟踪机制。图1-9展示了分布式服务跟踪机制的核心功能。
分布式服务跟踪机制的建立需要完成调用链数据的生成、采集、存储及查询,同时需要对这些调用链数据进行运算和可视化管理。这些工作不是一个简单的工具和框架就能全部完成的,因此,在开发微服务系统时,我们通常会整合多个开发框架来完成整个链路跟踪。例如,在Spring Cloud中,就提供了Spring Cloud Sleuth与Zipkin的集成方案。
图1-9 分布式服务跟踪机制的核心功能