如何设计微服务

一、序幕

最近在思考,自己哪些不足,需要学习点什么?看着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界面管理配置

  • 支持各种语言的SDK接入

实现统一配置中心常见的技术方案包括:

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

相关推荐
牛角上的男孩14 分钟前
Istio Gateway发布服务
云原生·gateway·istio
JuiceFS2 小时前
好未来:多云环境下基于 JuiceFS 建设低运维模型仓库
运维·云原生
deephub2 小时前
Tokenformer:基于参数标记化的高效可扩展Transformer架构
人工智能·python·深度学习·架构·transformer
想进大厂的小王2 小时前
Spring-cloud 微服务 服务注册_服务发现-Eureka
微服务·eureka·服务发现
景天科技苑2 小时前
【云原生开发】K8S多集群资源管理平台架构设计
云原生·容器·kubernetes·k8s·云原生开发·k8s管理系统
架构师那点事儿3 小时前
golang 用unsafe 无所畏惧,但使用不得到会panic
架构·go·掘金技术征文
wclass-zhengge3 小时前
K8S篇(基本介绍)
云原生·容器·kubernetes
颜淡慕潇3 小时前
【K8S问题系列 |1 】Kubernetes 中 NodePort 类型的 Service 无法访问【已解决】
后端·云原生·容器·kubernetes·问题解决
W Y5 小时前
【架构-37】Spark和Flink
架构·flink·spark
Gemini19956 小时前
分布式和微服务的区别
分布式·微服务·架构