一、序幕
最近在思考，自己哪些不足，需要学习点什么？看着Java基础知识，千遍一律，没有太大的动力需深挖，只能在写业务项目的时候边写边思考边夯实自己的基础。于是看了网上的一些资料，结合以前面试被问到的问题：如何设计微服务，于是带着思考去了解这个技术广度问题。
二、服务设计
1、负载均衡+API网关
实现负载均衡+API网关的常见技术方案:
1). Nginx + Lua 脚本 ：利用Nginx的负载均衡和Lua模块开发API网关。
2). HAProxy + HAProxy API Gateway：HAProxy具备负载均衡功能,其API网关模块可以实现API管理。
3). Kong + Kong Gateway ：Kong开源API网关,可以集成Nginx实现负载均衡。
4). Traefik + Traefik API Gateway：Traefik同时支持负载均衡和API网关能力。
5). Spring Cloud Gateway：Spring Cloud Gateway具备API网关功能,可以与Ribbon、Eureka等组件搭配使用。
6). Tyk API Gateway：Tyk开源的轻量级API网关,可以自定义插件实现负载均衡。
7). Amazon API Gateway ：亚马逊的API网关服务,可与其ELB集成。
根据需求选择合适的网关和负载均衡实现,利用其路由、流量控制等能力构建API管理层。
详情介绍：
Kong是基于Nginx的微服务API网关,提供动态服务发现、监控、灰度发布等功能。
使用:
启动Kong服务器,可以通过docker方式部署
配置服务路由及插件,通过Admin API或声明式配置
应用调用网关代理的服务
Spring Cloud Gateway网关,可以路由及过滤请求,集成Hystrix等组件实现高可用。
使用:
引入Spring Cloud Gateway依赖
通过Java配置定义路由规则
可以设置过滤器、断路器等
Zuul Netflix开源的网关,可以进行认证、监控、路由等功能。
使用:
加入Zuul启动器
配置规则表映射路径到服务
设置过滤器进行请求预处理等逻辑
2、无状态与独立有状态集群
无状态化(Stateless)是构建高可扩展和高可用应用的重要设计原则。
区分有状态和无状态应用:
– 有状态应用:应用需要保存用户会话状态、业务状态等数据。这些状态保存在应用进程内存或磁盘上。
– 无状态应用:应用不保存任何状态信息,每个请求独立,不依赖之前的请求。
有状态应用的问题:
– 扩展困难:状态数据无法共享到多台服务器
– 故障恢复复杂:节点故障时状态数据丢失,难以恢复
– 资源浪费:内存或磁盘用来保存状态数据
无状态应用的优点:
– 易扩展:任意增加节点,请求可以分布到任意节点
– 故障容错:节点故障后可以直接重启或切换,不需要恢复状态
– 资源高效:不需要内存或磁盘保存状态
实现无状态:
– 使用无状态服务组件,如无服务器存储
– 将状态外部化,例如保存到数据库、缓存或消息队列
– 在请求间不保存会话上下文,全面无状态化
无状态应用是云原生应用的重要特征,有利于实现弹性扩展和高可用。
3、数据库的横向发展
数据库的横向扩展主要的实现方式有:
1). 主从复制
– 一主多从的拓扑结构
– 主负责写,从负责读
– 可扩展读性能,实现读写分离
2). 分库分表
– 按业务拆分多个数据库
– 一个库内还可以分表,通过哈希等分数据
– 通过中间件路由分库分表,实现扩展
3). Sharding
– 通过分片策略存储不同数据到不同节点
– 支持按范围、哈希等方式分片
– 在中间件实现分片路由和查询
4). 数据库集群
– 采用类似Memcached的K-V存储模式
– 通过一致性哈希分布和复制数据
– 支持弹性扩容节点
5). 采用非关系数据库
– 非关系数据库可轻松扩展
– 通过扩展节点实现基于应用需求的扩展
6).同步复制/异步复制
– 不同场景下选择同步或异步机制,实现数据复制和扩展。
综上,根据应用特点选择合适的横向扩展方案,可实现数据库的可扩展性。
4、缓存
常用的缓存技术有:
1). 本地缓存
– 在应用内存中开辟一块空间作为缓存
– 通过Map、Guava Cache等实现
– 优点:快速、简单
– 缺点:容量受限、无法共享
2). 分布式缓存
– Memcached、Redis等分布式缓存
– 支持集群,可扩展性好
– 通过Key-Value模式缓存数据
– 使用客户端访问缓存集群
3). 数据库缓存
– 使用MySQL、Redis等数据库的缓存功能
– 数据缓存到数据库端
– 数据库负责缓存失效、回收机制
– 优点:和数据耦合度高
4). Web服务器缓存
– 通过Web服务器本地缓存静态资源
– 对动态内容也可以缓存生成的页面
– 支持各种缓存策略、缓存控制
– 可以大量提升网站性能
5). CDN缓存
– 在边缘节点缓存内容
– 就近响应用户请求,加速访问
综上,根据需求选择合适的缓存手段,能有效提升系统性能。
实现缓存常见的技术选型如下:
1). 本地缓存
– Guava Cache – Google的Java缓存实现,有内存和磁盘缓存。
– Ehcache – Java进程内缓存框架,有立即写回、事务支持等特性。
– Caffeine – 基于Java8的高性能本地缓存。
2). 分布式缓存
– Memcached – 简单的分布式内存KV缓存。
– Redis – 支持多种数据结构的分布式缓存。
– GemFire – Pivotal的分布式内存数据库和缓存。
3). 数据库缓存
– MySQL/PostgreSQL 数据库自带的查询缓存。
– Redis/Memcached集成到数据库引擎层,如Redisson。
4). Web缓存
– Nginx/Apache 的高速内存反向代理缓存。
– Varnish Cache – 高性能的HTTP缓存代理。
根据需要选择本地缓存或分布式缓存机制,来加速应用程序。
5、服务拆分与服务发现
服务拆分和服务发现是构建分布式系统的重要手段。
1). 服务拆分
– 将系统功能模块划分为不同的服务
– 规则:高内聚、松耦合,按业务领域(DDD)划分
– 优点:隔离变化,明确服务边界
– 实现:SOA、微服务都依赖服务拆分
2). 服务发现
– 服务实例动态注册到注册中心
– 服务消费者向注册中心获取服务提供者信息
– 调用者可通过负载均衡选择实例
– 常用实现:Zookeeper、Eureka、Consul、Nacos等
– 优点:服务位置透明、动态扩容
拆分后服务位置不固定,引入服务发现中间件,消费者可以动态获取服务信息并访问。
服务拆分与发现是构建大规模分布式系统的基石,能够实现服务治理和弹性扩展。
实现服务拆分与服务发现常用的技术方案包括:
1). Spring Cloud Netflix – Spring生态对Netflix组件的整合,如Eureka、Hystrix等。
2). Apache Dubbo – 阿里开源的高性能RPC框架,内置服务注册中心。
3). gRPC – Google开源的高性能RPC框架,支持服务注册。
4). Linkerd – 云原生应用的服务网格,支持服务发现、负载均衡。
5). CoreDNS – 云原生 DNS和服务发现,支持Kubernetes。
6). Consul – HashiCorp的服务发现与配置工具,有DNS和HTTP接口。
7). Etcd – 一个分布式KV存储,可用于服务注册。
8). ZooKeeper – 分布式协调服务,支持服务注册。
9). Nacos – 阿里服务发现和配置管理组件。
10). Kubernetes – 原生支持服务注册和负载均衡。
核心思路是将系统拆分为松耦合服务,通过服务注册表实现服务发现。可以选择适合技术栈进行实现。
6、服务编排与弹性伸缩
服务编排与弹性伸缩都是实现应用弹性和可扩展的重要手段。
1). 服务编排
– 协调调用复杂分布式服务的过程
– 编排服务间依赖,执行工作流协调调用
– 常用:Kubernetes、Docker Swarm实现服务编排
– 优点:简化服务交互,自动部署和管理
2). 弹性伸缩
– 根据负载情况调整服务实例数
– 规则:CPU、内存使用阈值、请求QPS等
– 自动水平扩展或收缩实例数量
– 常用:Kubernetes HPA,AWS Auto Scaling
– 优点:弹性应对流量变化,资源高效
服务编排简化了服务交互复杂度。弹性伸缩实现了资源的自动调节,提高资源利用率,应对变化的负载。
两者共同实现应用的敏捷性和高效性。是云原生应用的重要特征。
实现服务编排与弹性伸缩常用的技术方案包括:
1). Kubernetes – 开源的容器编排框架,支持服务部署、扩缩容、负载均衡等。
2). Docker Swarm – Docker自身的容器编排工具,可实现容器集群管理。
3). Mesos – Apache的资源统一管控和任务调度平台,可实现服务编排。
4). Amazon ECS – 亚马逊的容器管理服务,支持容器部署、伸缩。
5). OpenStack Heat – OpenStack的编排引擎服务,通过模板定义架构栈。
6). Spring Cloud – Spring生态的微服务编排组件,如Netflix、Zookeeper。
7). HashiCorp Nomad – 一致性的工作流调度和资源编排工具。
8). Alibaba Cloud ACK – 阿里云的托管Kubernetes集群服务。
核心是根据业务需求,利用编排调度器实现服务部署、资源分配、伸缩等。可以选择适合的开源或商业解决方案。
7、统一配置中心
统一配置中心是集中管理应用配置的服务,主要有以下优点:
1). 集中管理配置
– 提供服务端的配置存储空间
– 集中存储应用的外部化配置
– 一处修改,全局生效
2). 动态更新
– 支持热更新配置,不停服应用
– 应用可以获取配置变化通知
– 实现应用的动态重配置
3). 版本管理
– 可以版本化管理配置
– 支持配置修改历史回溯
– 方便查看配置变更记录
4). 权限管理
– RBAC访问控制配置的访问
– 安全可控,避免非授权修改
5). 易操作
– 简单的UI界面管理配置
– 支持各种语言的SD服务器托管网K接入
实现统一配置中心常见的技术方案包括:
1). Spring Cloud Config – Spring生态的配置中心实现,支持Git/SVN等存储后端。
2). Apollo – 携程开源的配置中心项目,有服务端和客户端实现。
3). Disconf – Baidu开源的本地配置管理平台,支持应用版本管理。
4). Diamond – Alibaba开源的配置管理平台,支持多种语言。
5). etcd – 一个分布式KV存储,可以用来实现配置中心。
6). Consul – HashiCorp的服务发现和配置管理工具,内置KV存储。
7). Zookeeper – 分布式协调服务,其数据节点可以用来保存配置。
8). Nacos – 阿里巴巴的配置和服务发现组件。
核心原理是实现一个集中式的、支持高可用的配置管理服务,应用可以共享这个配置中心。开源技术组合可以实现。
8、统一日志中心
统一的日志中心具有以下优点:
1). 集中存储日志
– 应用日志统一发送到日志中心
– 不再分散存储在各服务器
– 方便日志数据收集
2). 日志查询
– 提供日志查询接口和界面
– 通过条件过滤日志数据
– 支持全文索引等高级查询
3). 日志统计
– 可以统计日志数量以及各种聚合分析
– 分析异常或业务指标等
4). 日志监控
– 可以设置报警规则
– 异常日志实时报警
5). 日志转发
– 支持多种日志接入方式
– 统一日志转发格式
– 方便发送到其他系统
统一日志中心便于日志存储、查询与监控,有助于分析业务情况。
实现统一日志中心常用的技术选型如下:
收集代理:Fluentd,Logstash
Fluentd和Logstash都可以收集各服务器的日志数据,支持多种数据源。
传输方式:Kafka, Logstash-forwarder
Kafka是一个高吞吐的日志传输管道。Logstash-forwarder可以安全高效地传输日志。
存储数据库:ElasticSearch
ElasticSearch是一个分布式日志存储和搜索引擎,可以用于存储大量日志。
展示可视化:Kibana
Kibana可以用来分析和可视化ElasticSearch中的日志数据。
分析处理服务器托管网:Logstash,Spark
Logstash可以解析和处理日志。Spark也可以进行流式及批处理分析。
告警系统:ElasticSearch + Kibana/Grafana
通过Kibana或者Grafana连接ElasticSearch实现日志告警。
典型组合是Fluentd+Kafka+ElasticSearch+Kibana构成的EFK日志架构。也可以替换其中的组件实现自定义的日志中心。
9、熔断，限流，降级
熔断、限流与降级都是保障系统高可用的 Important 手段。
1). 熔断
A、依赖服务调用频繁失败时断开调用
B、 快速失败,避免资源占用
C、 后续恢复调用链路
D、 实现:
Hystrix:Netflix开源的熔断器实现,提供断路器模式,快速失败。
Sentinel:阿里巴巴的熔断组件,支持流量整形、熔断降级。
resilience4j:简单的熔断器实现。
2). 限流
A、 当请求流量过大时进行限制
B、避免服务过载
C、常用算法:漏桶、令牌桶等
D、 实现:
Guava RateLimiter:通过令牌桶算法实现简单的Rate Limiting。
Resilience4j: 提供基于语义的限流。
Sentinel:支持各种限流策略,如QPS、线程数等。
Nginx:可以通过nginx限流模块实现限流。
3). 降级
A、当服务压力过大时,减少处理
B、如无核心功能服务降级为备用逻辑
C、减小调用耗时,保证核心服务
D、实现：
Hystrix: 支持为依赖设置回退逻辑,实现服务降级。
Sentinel: 支持各种降级策略,如RT、异常比例、成功率等。
resilience4j: 提供重试、回退、隔离等机制。
熔断、限流快速失败,防止级联故障。降级平滑应对故障。共同提高系统弹性。
10、全方位的监控
全方位监控系统涵盖多个方面:
1). 基础监控
监控CPU、内存、磁盘、网络等基础资源指标,定位系统瓶颈。
2). 服务监控
监控各个服务的可用性、延迟、吞吐量等指标,定位问题服务。
3). 业务监控
根据关键业务指标监控系统运行情况,如转换率、订单量等。
4). 日志监控
分析日志错误、异常信息,尤其关注报警日志。
5). 用户监控
跟踪用户操作流程,分析用户行为数据。
6). 接口监控
监控各个接口的响应时间、成功率等指标。
7). 外部服务监控
监控外部依赖服务的可用性、延迟指标。
8). 全链路追踪
跟踪一个请求调用的整个过程,清晰系统运行情况。
全方位监控可以从不同维度对系统运行状态进行把控,对于分析问题、保障高可用非常关键。需要选用合适的监控系统来实现。
根据全方位监控的要求,可以考虑使用以下技术:
1). 基础资源监控:Zabbix、Nagios、Prometheus等进行基础指标数据的收集。
2). 服务监控:通过 Micrometer、Prometheus 等模块采集服务运行指标,并设置告警规则。
3). 业务监控:通过 Grafana 等工具定义关键业务指标面板,并设置告警。
4). 日志监控:使用 ELK 或 Graylog 收集和分析日志,设置日志告警。
5). 用户监控:通过 Google Analytics、存量用户平台等分析用户行为数据。
6). 接口监控:使用 Cat、Zipkin 等实现接口调用链路监控。
7). 外部服务监控:通过端点检查等方式监测外部服务可用性。并联合监控系统设置告警。
8). 全链路追踪:通过 Zipkin、SkyWalking、Jeager 等落地分布式链路追踪。
此外,可以使用 Grafana 等工具实现统一的监控数据展示和告警。
根据选择的监控系统和技术栈进行对应集成,可以实现全方位的系统监控。
三、总结
文档内容来源网上或者AI的回答，经过自己的整理而来，方便自己复习，也增加自己的技术广度。
借鉴地址：https://zhuanlan.zhihu.com/p/51535879
原始文档地址：https://github.com/krycai/gc-framework/blob/master/%E5%BE%AE%E6%9C%8D%E5%8A%A1%E8%AE%BE%E8%AE%A1.xmind
服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net
前言 重试，其实我们其实很多时候都需要的，为了保证容错性，可用性，一致性等。一般用来应对外部系统的一些不可预料的返回、异常等，特别是网络延迟，中断等情况。还有在现在流行的微服务治理框架中，通常都有自己的重试与超时配置，比如dubbo可以设置retries=1，…
