云原生技术中台:从分布式到云平台设计
上QQ阅读APP看书,第一时间看更新

分布式架构通过建立注册中心来管理服务之间的通信,服务之间的寻址由注册中心协助完成,服务之间使用轻量级的通信协议直接通信。对于单个独立的大型业务,软件服务商需要将核心业务抽取出来作为独立服务,这些服务逐渐形成稳定的服务中心,能够更快速地响应多变的市场需求。

分布式架构的设计理念是将核心业务抽取出来作为独立的服务,这些服务逐渐形成稳定的服务中心,然后拆分这些核心服务来提升服务中心的性能,达到更快速的需求响应。

以电商系统为例,其中很多核心业务是公共模块(如会员中心、购物车和商品管理)。不管是在微信小程序还是在移动端,这些模块的后台系统都是相同的。可以将这些模块拆分成单独的服务,对外提供统一的接口,从而提高模块的复用效率。分布式架构的核心思想是性能优化,主要有两个指标:吞吐量系统容错性。对吞吐量而言,不同种类的服务的吞吐量需求是不一样的。为了实现高吞吐量,需要一个健壮的通信框架,该框架能够同时保持大量的连接并及时处理请求,如基于Java NIO多路复用技术的通信框架Netty。对系统容错性而言,通信框架需要支持自定义容错策略配置,如失败以后重试、失败以后抛出异常、失败以后忽略异常信息等。

分布式架构的实现依赖高并发的通信框架。在分布式架构场景下,最重要的问题之一是解决分布式服务之间的通信问题,然后才进入设计服务集群方式的环节,这个问题很有挑战性。在分布式场景下编写高并发、高可用的应用,需要相当丰富的编程经验,这对于一些中小型团队是一个巨大的挑战。对大型团队来说,提供一个高并发的框架也需要投入大量的研发人员。因而,良好的通信框架需要具备开箱即用的特性和简单的设计模式,同时需要有开源社区的支持。活跃的社区能够通过不断升级第三方组件依赖版本来优化性能,并修复安全漏洞。

分布式架构依赖高可用的注册中心,在生产环境下,注册中心必须是一个集群。注册中心需要提供原子性的操作,否则多个服务在同时注册时可能会产生冲突。注册中心以集群的方式对外提供接口,避免了单点故障,以应对不稳定的网络环境。此外,注册中心还需要提供分布式锁等集群通用功能。

在分布式架构中,提供者需将服务注册到注册中心中,由注册中心持久化提供者信息。注册中心本身是一个集群,会把提供者信息同步到集群的每个节点上,以提供主备能力。消费者从注册中心拉取信息并将信息缓存到本地,然后向注册中心订阅提供者实例状态信息。当提供者失去和注册中心的连接或者提供者主动注销时,注册中心向订阅提供者实例状态信息的消费者发送通知。消费者将不可用的提供者信息从本地缓存中删除。注册中心集群工作方式如图1-8所示。

图1-8 注册中心集群工作方式

注册中心还提供对服务治理功能进行统一配置的功能。注册中心需要对消费者和提供者做统一的配置,当消费者和提供者实例启动时,消费者和提供者将从配置中心获取动态配置信息。这些动态配置信息包括负载均衡策略、路由策略、重试策略、访问限制、黑白名单、鉴权方式、令牌验证、黏滞连接、服务降级和发布模式等。

在分布式场景下,具有相同服务能力的提供者会被分组管理。消费者调用提供者时,实际上是调用这一组服务。这种消费者按组调用服务的功能依赖于注册中心的能力,消费者从注册中心订阅一种服务接口,该接口的实现方式对应一组提供者实例。同时,消费者能及时从注册中心获取提供者的变化信息,这是一种经典的观察者设计模式。

分布式应用发生故障的情况无法避免且很难预测,如应用崩溃、网络突发故障等情况。正是这些不得不面对的情况,要求我们在构建分布式系统时,要综合考虑系统的一致性、可用性、吞吐量。

一致性要求在分布式系统中的任意一个节点都会查询到相同的信息。解决一致性的问题要求分布式框架能够提供中心化协同工作机制,提供服务注册和订阅功能,即注册中心。此外,通信框架需要设计统一的控制中心来分发服务配置,或者把调整的配置通知到各个服务应用实例,以支持服务配置热加载的功能。中心化协同工作机制需要提供安全策略、加解密的算法、序列化消息等通用功能。

服务的可用性指的是当部分提供者失效时,整个分布式系统服务依然可用的特性。例如,各种原因导致的网络或硬件故障,甚至是软件自身的故障,都可能会使提供者不可用,在这种情况下,消费者需要能够及时发现并排除这些不可用的提供者,避免整个系统瘫痪。系统的通信框架需要支持自定义容错策略配置,如失败以后重试、失败以后抛出异常、失败以后忽略异常信息等。

分布式框架在设计上需要考虑服务之间调用的吞吐量。在解决了可用性的问题后,接下来需要解决稳定性的问题。由于网络请求不稳定,因此需要建立完备的负载均衡策略,把流量分散开来,以降低部分节点的突发负荷。也就是说,这是如何增大吞吐量的问题。

吞吐量问题本质上是分布式框架性能的问题。通信框架需要在支持业内主流负载均衡策略的同时,支持动态配置自定义路由机制,以适应复杂的业务调用关系。