跳转至

引言

DevOps(Development and Operations) 是一种文化、运动或实践，提倡尽可能地自动化软件开发和部署流程。

20240625195627

图片来源：https://juejin.cn/post/6844904078485504008

单体架构

20240625181650

就是将应用程序的所有功能都打包成一个独立的单元。当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。

以 Java 为例，所有功能打包在一个 WAR 包里，部署在 Tomcat 这样的应用服务器里即可，群化部署也很容易，多个 Tomcat + 一个 Nginx 分分钟搞定。

不够灵活，可靠性差，单体应用越来越大时，阻碍持续交付。

垂直架构

20240625181627

相同逻辑代码不能复用，系统性能扩展只能通过扩展集群结点，成本高、有瓶颈

SOA 架构

Service Oriented Architecture, 面向服务的架构

20240625181855

当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。

将重复公用的功能抽取为组件，以服务的形式给各系统提供服务，服务之间采用 WebService、RPC 等方式进行通信，使用 ESB（企业服务总线）作为项目与服务之间通信的桥梁。

ESB 是一个抽象层，为了集成不同系统，不同协议的服务，承担消息转化解释和路由工作，让不同的服务互联互通。

虽然使用了 ESB，但是服务的接口协议不固定，种类繁多，不利于系统维护。另外系统与服务的界限模糊，服务关系复杂，运维、测试部署困难

分布式微服务架构

微服务没有单一的定义，随着时间推移所形成的共识。

20240625182620

基本沿用了 SOA 的思想，但是服务拆分粒度更细，将系统服务层完全独立出来，并将服务层抽取为一个一个的微服务，微服务中每一个服务都对应唯一的业务能力，遵循单一原则，因此团队可以拆分成一个个的小组

微服务之间采用 RESTful 等轻量协议传输，因此不同微服务之间实现技术独立，可使用不同的编程语言。

引入了服务治理组件，结合流行的容器化技术，实现 Devops 自动化部署与运维。

微服务过多，服务治理成本高，技术成本高，不利于系统维护和测试。

微服务就是将一个单体架构的应用按业务划分为一个个的独立运行的程序即服务

  • 服务之间通过 HTTP 协议进行通信，也可以采用消息队列来通信（如 RabbitMQ，Kafaka 等）
  • 可以采用不同的编程语言，使用不同的存储技术，自动化部署减少人为控制，降低出错概率。
  • 服务数量越多，管理起来越复杂，因此采用集中化管理（如 Eureka，Zookeeper 等）。

服务拆分

通常采用分布式系统开发形式，实现高性能，高扩展，高可用

20240625185022

  • Y 轴，基于不同业务拆分
  • X 轴，就是将单体系统多运行几个实例，成为集群加负载均衡的模式
  • Z 轴，基于请求或用户独特的需求进行系统划分，比如 CDN

无状态服务

如果一个数据需要被多个服务共享，才能完成一笔交易，那么这个数据被称为状态，依赖这个数据的服务称之为有状态服务，反之称为无状态服务。

把这些数据迁移到分布式缓存中存储，让业务服务变成一个无状态的计算节点，微服务应用在运行时动态增删节点，就不再需要考虑缓存数据如何同步的问题

20240625191516

通信方式

  • 同步通信：RPC、REST
  • 异步通信：MQ

微服务组件

API Gateway

API 网关提供统一服务入口，让微服务对前台透明，提供安全、流控、过滤、缓存、计费、监控等 API 管理功能

常用的有：Zuul1, Spring Cloud Gateway

服务治理

在分布式环境下让多个实例同时获取到同一份信息的服务，被称作分布式协调服务。

  • 服务注册，实例将自身服务信息注册到注册中心
  • 服务发现，实例通过注册中心获取其它实例的信息，然后去请求它们提供的服务。
  • 服务剔除：注册中心将出问题的服务自动剔除到可用列表之外，使其不会被调用到。

比如 Eureka, Consul, ZooKeeper 等

ZooKeeper 不仅可以用于服务注册和发现，还可用于分布式锁、配置管理等场景

负载均衡

为了保证高可用，每一个微服务都需要部署多个服务实例来提供服务，此时就需要根据不同的负载均衡策略对服务进行调用

  • 轮询策略
  • 权重轮询策略
  • 随机策略
  • 最少并发数策略
  • 重试策略
  • 可用性敏感策略
  • 区域敏感性策略

服务容错

服务与服务之间的依赖性，故障会传播，造成连锁反应，形成雪崩

  • 请求缓存：支持将一个请求与返回结果做缓存处理；
  • 请求合并：将相同的请求进行合并然后调用批处理接口；
  • 请求限流：当请求过多时，可能会拖垮整个网站，通常会采取限流措施，降低机器的负载；
  • 服务隔离：限制调用分布式服务的资源，某一个调用的服务出现问题不会影响其他服务调用；
  • 服务熔断：牺牲局部服务，保全整体系统稳定性的措施；
  • 服务降级：服务熔断以后，客户端调用自己本地方法返回缺省值

链路追踪

完整记录一次任务的开始到结束，期间调用的所有系统及耗时（时间跨度），进行日志记录，性能监控等

配置中心

MySQL、Redis 、Security 等基础配置，以及七牛存储、短信和邮件等业务相关的配置。

采用 Spring Cloud Config, Consul, Apollo, Nacos 等配置中心集中管理每个服务的配置信息。

安全认证

用户登录信息和权限管理最好有一个统一的地方维护管理

  • 单点登录 SSO
  • 分布式 Session
  • 客户端 Token，比如 JWT
  • Token 与 API 网关结合

通常采用 OAuth 2.0 + JWT 的方式

OAuth 2.0 一般用于第三方接入的场景，管理对外的权限，所以比较适合与 API 网关结合，针对于外部的访问进行鉴权。

JWT 更加轻巧，在微服务之间进行认证和授权已然足够，并且可以避免和身份认证服务直接打交道

分布式原则及理论

CAP

20240625192159

CAP 原则/定理，是指在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可兼得。

于是便有三种取舍策略：CA without P, CP without A, AP without C

随着集群规模越来越大，节点和网络故障是常态，因此分区容错性是必然要面对的问题，只能选择在 C, A 之间做取舍

对于金融系统，数据一致性是至关重要的，所以通常采用 CP 模式，而非金融普遍采用 AP 模式。

BASE

由 ebay 架构师提出

BASE 理论是对 CAP 中 C, A 权衡的结果，来源于对大型互联网分布式实践的总结

虽然无法做到强一致性，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。

  • Basically Available（基本可用），出现故障时允许损失部分可用性，比如延长响应时间，功能降级等
  • Soft state（软状态），允许系统存在不影响系统整体可用性的中间状态，比如副本数据延时同步
  • Eventually consistent（最终一致性），软状态要有一个期限，期限过后最终要保持一致，取决于网络延时，系统负载，数据复制方案设计等

评论