微服务平台主要由服务支撑层、基础服务层、通用服务及业务服务层组成,系统总体功能架构图如下:
1) 基础设施
微服务平台的基础设施包括网络、存储、计算等硬件基础设施,为平台的运行提供基础保障。
2) 服务支撑层
服务支撑层为保证整个服务平台健康、高效运行提供支撑服务,包括服务注册与发现中心、配置中心、日志中心、监控中心、服务限流降级与熔断、微服务网关等支撑服务功能。
3) 基础服务层
基础服务层将平台通用的功能以服务的形式进行封装,为其他业务服务的实施提供基础服务,包括分布式缓存服务、分布式存储服务、搜索服务、消息队列服务、分布式事务服务、任务调度服务、统一认证中心、用户中心、组织机构管理、代办任务中心、流程管理中心等基础服务功能。
4) 通用服务层
通用服务层,是将一般业务功能开发都需要使用的功能进行封装,形成通用服务,提高开发效率,控制开发质量的一种方式。
5) 业务服务层
通过通用服务实现的业务逻辑部署在业务服务层,为前端应用提供服务。
平台架构以Spring Cloud 微服务架构为核心进行构建,集成了Spring Cloud Alibaba Nacos 实现服务注册、发现与配置管理,集成Skywalking、 Elastic Logstash、Elastic Search、Elastic Kibana 实现日志中心功能、集成Prometheus、Grafana 实现监控预警功能、集成Spring Cloud Admin 实现微服务监控功能、集成Alibaba Sentiel 实现服务限流、降级与熔断功能,集成Spring Cloud Gateway 实现了微服务网关功能。
服务支撑层为保证整个服务平台健康、高效运行提供支撑服务,包括服务注册与发现中心、配置中心、日志中心、监控中心、服务限流降级与熔断、微服务网关等支撑服务功能。
Spring Cloud Alibaba Nacos 是阿里巴巴公司的开源组件,Nacos 提供了一组简单易用的特性集,能够快速实现动态服务注册、发现、服务配置、服务元数据及流量管理功能,帮助企业更敏捷和容易地构建、交付和管理微服务平台,是构建以“服务”为中心的现代应用架构服务的基础设施。
Nacos支持基于DNS和基于RPC的服务发现。服务提供者使用原生SDK、OpenAPI或一个独立的Agent TODO注册服务后,服务消费者可以使用DNS TODO 或HTTP&API查找和发现服务。
Nacos提供对服务的实时的健康检查,阻止向不健康的主机或服务实例发送请求。Nacos支持传输层 (PING或TCP)和应用层 (如 HTTP、MySQL、用户自定义)的健康检查。对于复杂的云环境和网络拓扑环境中(如 VPC、边缘网络等)服务的健康检查,Nacos提供了Agent上报模式和服务端主动检测2种健康检查模式。Nacos 还提供了统一的健康检查仪表盘,帮助根据健康状态管理服务的可用性及流量。
动态配置服务可以平台以中心化、外部化和动态化的方式管理所有环境的应用配置和服务配置。
动态配置消除了配置变更时重新部署应用和服务的需要,让配置管理变得更加高效和敏捷。
配置中心化管理让实现无状态服务变得更简单,让服务按需弹性扩展变得更容易。
动态 DNS 服务支持权重路由,让平台更容易地实现中间层负载均衡、更灵活的路由策略、流量控制以及数据中心内网的简单DNS解析服务。动态DNS服务使平台更容易地实现以 DNS 协议为基础的服务发现,以帮助消除耦合到第三方应用私有服务发现API上的风险。
整个平台分布着大量的服务器、中间件、数据库、微服务组件,对他们的性能、运行指标、健康状况的监控就显得尤为重要。方案通过多种组件集成的方式提供了整个平台的可视化监控中心功能。
随着业务的发展,平台中提供的服务会越来越多,服务之间的调用也会越来越错综复杂,一个请求可能会涉及多个服务,而服务本身可能也会依赖其他服务,整个请求路径就构成了一个网状的调用链,而在整个调用链中一旦某个节点发生异常,整个调用链的稳定性就会受到影响,为此方案中通过集成Apache SkyWalking组件,来帮助我们快速定位和解决问题。
Apache SkyWalking包括了分布式追踪、性能指标分析、应用和服务依赖分析功能。SkyWalking 核心包括探针Probo、后台服务Backend、存储Storage、可视化UI 四部分组件,其中存储我们选用Elastic Search 企业级搜索服务来来存储监控日志信息。
SkyWalking 的探针只需要部署到要监测服务的服务器上,即可实现代码无侵入的方式收集服务相关日志信息。
探针收集到数据并进行格式转换后,将数据推送到后台服务,后台服务对收集的数据进行分析和聚和后存储到本方案选取的存储Elastic Search 上,以便可视化展示给最终用户。
为了及时了解平台的健康情况,我们需要建包括服务器的CPU空闲率、CPU 使用率、CPU负载率、可用内存、内存使用率、文件系统空闲空间、网络上传、下载速率、磁盘IO情况,数据库吞吐量、连接情况、缓冲池使用情况、查询性能,Elastic Search 的查询索引性能、内存分配、垃圾回收情况、集群健康及节点可用性等多种指标。为此,本方案采用Prometheus组件实现平台的监控与报警功能。Prometheus 是一套开源的系统监控报警框架,他包含了多个独立的组件,其中有些组件是可选的,我们方案主要选择如下组件:
主要工作流程:
在各个微服务开发实现过程中,根据业务需要我们会设置一些埋点记录应用日志,比如用Log4j记录应用日志信息,以便我们对应用进行分析排查问题或做统计分析。为了能够实时、可视化的方式对日志进行统计、分析、查看,方案选用ELK开源组件实现日志中心功能。ELK核心组件包括:
另外,我们经常遇到一些需要将数据库中的数据同步到Elasticsearch中,以便提高查询效率、降低数据库服务器压力的情况,为了实现这样的功能通常有几个方案:
随着平台中微服务组件的不断增加,如何在其中一个或几个服务出现流量异常的情况下,保障其他服务能够正常运转,而不至于整个平台陷入瘫痪显得越来越重要。
阿里巴巴Sentinel 是面向微服务架构的轻量级流量控制组件,主要以流量为切入点,从限流、流量整形、熔断降级、系统负载保护等多个维度来帮助您保障微服务的稳定性。
平台中部署了很多微服务,这些微服务对外提供API接口以便客户端调用,每个微服务都有各自的地址、端口等信息,一个客户端可能需要访问很多不同的微服务去实现业务功能。这就需要客户端动态维护微服务的信息并与多个微服务之间进行身份验证工作,为了解决这些问题,就需要一个能够统一管理API 的网络关口,作为整个微服务平台请求的唯一入口,在网关层处理所有非业务功能(比如对调用微服务的客户端进行身份验证、记录日志、动态路由等),本方案采用Spring 官方推出的 Spring Cloud Gateway 网关组件,具有如下特性:
客户端向Spring Cloud Gateway发出请求。如果Gateway Handler MApping确定请求与路由匹配,则将其发送到Gateway Web Handler。此handler通过特定于该请求的过滤器链处理请求。而这些匹配是由路由断言Factory完成的,Spring Cloud Gataway包含了很多内置的路由断言Factories,这些断言都匹配HTTP请求的不同属性。多个路由断言Factories可以通过 and 进行组合使用。
主要内置断言Factory包括:
另外,Spring Cloud Gateway 可以与Oauth2、JWT集成实现在网关进行请求的身份验证与授权功能。
基础服务层将平台通用的功能以服务的形式进行封装,为其他业务服务的实施提供基础服务,包括分布式缓存服务、分布式存储服务、搜索服务、消息队列服务、分布式事务服务、任务调度服务等基础服务功能
分布式缓存服务可将高频访问的数据,放入缓存中,可以大大提高微服务平台整体的承载能力,解决数据库服务器和web服务器之间的效率瓶颈。分布式缓存服务应支持高性能的Key-Value存储方式,支持string、list、hash、set、zset、hypeloglog等多种数据结构,支持主动过期和惰性过期的数据过期处理,支持volatile-lru、volatile-ttl等LRU策略,及内存管理、内容存储+磁盘持久化、主从复制等功能;在性能上应满足百万级QPS的资源调用,99.99%的可用性,毫秒级的核心请求响应时间,弹性扩展、易用等指标。
方案采用Redis来提供分布式缓存服务,可以完全满足上述要求:
Redis,是REmote DIctionary Server的缩写。是一个开源、基于C语言、基于内存亦可持久化的高性能NoSQL数据库,同时,它还提供了多种语言的API。它是一款由意大利人由Salvatore Sanfilippo所写的,依据BSD开源协议发行的高性能Key-Value存储系统(cache and store)。它通常被称为数据结构服务器,提供了一些丰富的数据结构,包括 字符串(String), 哈希(Map), 列表(list), 集合(sets) 和 有序集合(sorted sets)等类型。Redis当然还包括了对这些数据结构的丰富操作。
分布式网络存储服务采用可扩展的系统结构,利用多台存储服务器分担存储负荷,利用位置服务器定位存储信息,它不但提高了系统的可靠性、可用性和存取效率,还易于扩展。分布式存储服务应支持文件存储、文件传输、跨机房架构、文件元数据管理、文件搜索、文件处理、文件版本管理、文件日志消息、大数据对接等功能,对外提供RESTfulAPI。
针对以上的需求我们采用MongoDB来应对。
MongoDB是一个基于分布式文件存储的数据库。由C++语言编写。旨在为WEB应用提供可扩展的高性能数据存储解决方案。是介于关系数据库和非关系数据库之间的产品,是非关系数据库当中功能最丰富,最像关系数据库的。他支持的数据结构非常松散,是类似json的bson格式,因此可以存储比较复杂的数据类型。Mongo最大的特点是他支持的查询语言非常强大,其语法有点类似于面向对象的查询语言,几乎可以实现类似关系数据库单表查询的绝大部分功能,而且还支持对数据建立索引。
消息队列服务可以为平台提供消息发布订阅、消息轨迹查询、定时(延时)消息、资源统计、监控报警等一系列消息服务,为平台提供异步解耦、削峰填谷的能力,同时具备海量消息堆积、高吞吐、可靠重试等互联网应用所需的特性。
我们采用Apache Alibaba RocketMQ做为消息队列服务实现方案,Apache Alibaba RocketMQ 是一款分布式、队列模型的消息中间件,具有以下特点:
对比其他主流消息队列组件主要优势有:
通过搜索引擎服务将搜索引擎复杂的索引结构概念简单化、可视化和自助定制化。平台的上层业务应用可以通过控制台创建搜索应用,定制文档字段的结构和属性,包括字段名称、类型、分词方式、搜索属性等。搜索应用在运行过程中可以自由修改,满足业务快速变化的需求,缩短需求变更到上线的过程。
本方案中,我们基于Elastic Search实现搜索引擎服务,Elasticsearch 是一个实时的分布式搜索和分析引擎。它可以帮助用户用前所未有的速度去处理大规模数据、它可以用于全文搜索,结构化搜索以及分析。实现分布式实时文件存储,并将每一个字段都编入索引,使其可以被搜索,他是一个能够实现实时分析的分布式搜索引擎,并可以扩展到上百台服务器,处理PB级别的结构化或非结构化数据。
在微服务架构下,虽然我们会尽量避免分布式事务,但是只要业务复杂的情况下这是一个绕不开的问题,为了保证业务数据原子性、一致性,本方案采用阿里巴巴开源的一站式分布式事务解决方案中间件Seata, Seata能够帮助用户以高效并且对业务 零侵入的方式解决微服务场景下面临的分布式事务问题。
Seata整体事务逻辑是基于两阶段提交 的模型,核心概念包括以下3个角色:
Seata有两种模式可使用分别对应不同业务场景:
基于支持本地 ACID 事务的关系型数据库。
JAVA 应用,通过 JDBC 访问数据库。
① TM 向 TC 申请开启一个全局事务,全局事务创建成功并生成一个全局唯一的 XID。
② XID 在微服务调用链路的上下文中传播。
③ RM 向 TC 注册分支事务,将其纳入 XID 对应全局事务的管辖。
④ TM 向 TC 发起针对 XID 的全局提交或回滚决议。
⑤ TC 调度 XID 下管辖的全部分支事务完成提交或回滚请求。