运维/软件架构进化史

运维/软件架构发展史

涉众

产品经理
软件开发工程师
软件测试工程师
运维工程师（SRE 工程师）
- SRE(Site reliability engineering, 站点可靠性工程）主要目标是创建可扩展和高可用性的软件系统。

软件开发模式

瀑布模式（1970年最初期初）：设计、开发、测试完成后才部署到生产环境，周期长
敏捷模式（1990年代兴起）：
- 产品设计完成后，功能被拆分为足够小的部分，开发完一个模块就测试（反复迭代），最后集成测试并交付，开发周期可控
- 更加强调队伍中的高度协作
DevOps：
- 产品设计完成后，功能被拆分为足够小的部分，小功能开发完成后，测试接入，测试完成后发布生产环境
- 一般需要结合：CI（持续集成） -> CD（持续交付） -> CD（持续部署） -> CT（持续运维），参考：常用 CI/CD/CT 工具介绍

IT 技术的发展趋势

软件架构：单体架构 -> 封层架构 -> 微服务 -> Function
资源粒度：物理机 -> 虚拟机 -> 应用容器 -> Serverless
开发模式：瀑布模式 -> 敏捷模式 -> DevOps -> AIOps/NoOps
发布部署：冷部署 -> 热部署 -> 持续部署（CD）

说明：

持续部署（CD）与 DevOps 有紧密的关系
热部署如金丝雀发布等

常见的应用架构

传统运维架构

架构：访问层（APP） -> 接入层（Nginx...） -> 逻辑层（Java...） -> 存储层 -> 云 -> IDC

缺点：

架构层次多，组件多，排查问题困难
扩展性性若，大多不支持弹性伸缩
资源浪费严重，为实现高可用冗余大量服务
扩展性差
监控不全面
发布流程复杂
救火式运维

微服务架构

出现背景
- 敏捷模式开发、CICD、DevOps 文化的发展和实践中
- 以 Docker 为代表的现代应用容器技术的出现
定义：微服务 是一种开发应用程序的架构和组织方法
特点：
- 应用程序 由通过明确定义的 API 进行通信的小型独立服务组成
- 基于小团队敏捷开发
- 服务镜像原子化拆分
- 每个 微服务 独立打包、部署和升级
- 微服务 间通过 注册中心 实现服务注册和发现
- 微服务 通过 配置中心 加载配置信息
- 微服务 间通过 API 网关 被外部访问
微服务架构 下 服务治理 面临的挑战，包括：
- 分布式环境中，网络的波动不可忽略
- 服务注册和服务发现
- 服务健康状态监测
- 服务间路由
- 异常点监测
- 客户端重试
- 可配置的超时机制
- 负载均衡
- 限速
- 流量整形
- 熔断

分布式架构

分布式架构需求，图片来源

分布式应用程序的需求：

声明周期（Lifecycle）: Kubernetes
网络（Networking）: Istio
绑定（Binding）: knative
- Service
- Event
- Build -> Tekten / ArgoCD
状态（State）: Dapr 暂未引起搭建的广泛接受和使用

随着业务的增大，业务会垂直和水平拆分为 分布式架构，分布式架构 能提供系统的容量和能力，并通过冗余服务的方式消除单点故障

传统单体架构 vs 分布式服务架构

	传统单体架构	分布式服务架构
新功能周期	长	短
部署	不经常变更且容易部署	经常变更，部署复杂
隔离性	故障影响范围大	部分故障，影响范围小
架构设计	难度小	复杂、难度大
系统运维	简单	复杂
系统性能	响应时间快，吞吐小	响应时间慢，吞吐大
系统扩展性	差	好
系统管理	重点在于开发	重点在于服务治理
技术	技术单一	技术多样且开发
新人上手	快	慢，架构学习成本高
测试排错	简单	复杂

运维架构的演变

硬件服务器阶段

需要自行购买和维护服务器、网络、机房等，以硬件 为中间心开展业务

云阶段

各种资源通过统一的云管平台管理（相当于屏蔽了 IaaS 层的资源），开始以 资源 为中心开展业务

云原生阶段

云原生阶段基于云原生的基础设施，开始以 应用/微服务 为中心

应用部署工具演变

手动发布 -> 脚本发布 -> 工具化发布 -> 自动化发布

应用架构的演变

参考：dubbo architecture roadmap

单体应用（All in one）：ORM
- 特点：小业务，代码集中一个项目，管理简单；基于 ORM 实现 CRUD 操作
- 优点：开发快、成本低、易于测试和部署
- 缺点：代码耦合度高、扩展性差、协同开发难度大
垂直应用（Vertical Application）：MVC
- 特点：根据业务特点拆分（如：用户中心、订单中心、产品中心、客服中心等）；分离前后台逻辑
- 优点：协同开发效率高、耦合度底、水平扩展方便
- 缺点：烟囱架构，依赖其他组件（如 RabbitMQ、Redis）实现高可用
水平拆分及服务化（Distributed Service）：RPC、MQ、json-p
- 特点：以分布式服务架构（RPC）为中心，先后台分离
- 缺点：服务间的耦合度高、调用关系复杂、维护难
- 常见的 RPC 框架：
  - 阿里巴巴 Dubbo
  - 蚂蚁金服 SOFA-RPC
  - 百度 bRPC
  - Google gRPC
  - Facebook Thrift
弹性计算架构（Elastic Computing）：SOA
- 特点：需要实现API 网关、服务配置、服务发现、服务治理等工作。资源调度中心和治理中心（SOA）是核心
- 系统关键组件：
  - 注册中心：Nacos、Consul、Zookeeper、Etcd 介绍、Eureka 等
  - 配置中心：spring-cloud-config、Apollo、Disconf 等
- 缺点：服务间 RPC 调用量大、服务监控难、负载均衡重要、维护成本高
  - 解决：进一步拆分应用，各自承担业务负载；基于 SOA 实时管理集群容量，提高利用率

说明：

随着查分的粒度越来越大，集群规模成几倍、几十倍的增长

服务治理的演变

分布式架构治理模式演进：

SOA/ESB -> Microservices -> Cloud Native

服务治理的目标：

服务发现
负载均衡
熔断容器
动态路由

服务治理的迭代：

第一代：服务治理能力内嵌在业务代码中，典型技术：SOA、ESB
- 优点：使用简单，依赖少
- 缺点：代码耦合度高、开发复杂、运维复杂
第二代：服务治理能力抽象到 SDK 中实现，典型技术：Spring Cloud、Dubbo
- 优点：代码重复少、治理逻辑代码和业务代码分开
- 缺点：SDK 编程语言绑定、使用复杂、系统改造工作量大、治理能力升级影响用户业务
第三代：服务治理能力统一到 服务网格，服务网格以基础设施的方式提供无侵入的连接控制、安全、可观测性、灰度发布等治理能力
- 优点：独立进程、用户业务非入侵、编程语言无关；治理逻辑升级业务无感知；可渐进的微服务化
- 缺点：代理的能力和资源开销

综上，服务治理与业务逻辑逐步解耦，服务治理能力下沉到基础设施层

涉众