运维/软件架构发展史
涉众
- 产品经理
- 软件开发工程师
- 软件测试工程师
- 运维工程师（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 暂未引起搭建的广泛接受和使用
随着业务的增大，业务会垂直和水平拆分为 分布式架构，分布式架构 能提供系统的容量和能力，并通过冗余服务的方式消除单点故障
|
传统单体架构 |
分布式服务架构 |
| 新功能周期 |
长 |
短 |
| 部署 |
不经常变更且容易部署 |
经常变更，部署复杂 |
| 隔离性 |
故障影响范围大 |
部分故障，影响范围小 |
| 架构设计 |
难度小 |
复杂、难度大 |
| 系统运维 |
简单 |
复杂 |
| 系统性能 |
响应时间快，吞吐小 |
响应时间慢，吞吐大 |
| 系统扩展性 |
差 |
好 |
| 系统管理 |
重点在于开发 |
重点在于服务治理 |
| 技术 |
技术单一 |
技术多样且开发 |
| 新人上手 |
快 |
慢，架构学习成本高 |
| 测试排错 |
简单 |
复杂 |
运维架构的演变
硬件服务器阶段
需要自行购买和维护服务器、网络、机房等，以硬件 为中间心开展业务
云阶段
各种资源通过统一的云管平台管理（相当于屏蔽了 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）是核心
- 系统关键组件：
- 缺点：服务间 RPC 调用量大、服务监控难、负载均衡重要、维护成本高
- 解决：进一步拆分应用，各自承担业务负载；基于 SOA 实时管理集群容量，提高利用率
说明：
- 随着查分的粒度越来越大，集群规模成几倍、几十倍的增长
服务治理的演变
分布式架构治理模式演进：
- SOA/ESB -> Microservices -> Cloud Native
服务治理的目标：
服务治理的迭代：
- 第一代：服务治理能力内嵌在业务代码中，典型技术：SOA、ESB
- 优点：使用简单，依赖少
- 缺点：代码耦合度高、开发复杂、运维复杂
- 第二代：服务治理能力抽象到 SDK 中实现，典型技术：Spring Cloud、Dubbo
- 优点：代码重复少、治理逻辑代码和业务代码分开
- 缺点：SDK 编程语言绑定、使用复杂、系统改造工作量大、治理能力升级影响用户业务
- 第三代：服务治理能力统一到
服务网格，服务网格以基础设施的方式提供无侵入的连接控制、安全、可观测性、灰度发布等治理能力
- 优点：独立进程、用户业务非入侵、编程语言无关；治理逻辑升级业务无感知；可渐进的微服务化
- 缺点：代理的能力和资源开销
综上，服务治理与业务逻辑逐步解耦，服务治理能力下沉到基础设施层