架构初探｜青训营笔记

路有所思
129 阅读7分钟

这是我参与「第五届青训营」伴学笔记创作活动的第 8 天

1. 概述

我将主要介绍如下知识点：

  1. 什么是架构
  2. 企业级后端架构的形态

2. 架构定义解析

2.1 定义

架构，又称软件架构，

  • 是有关软件整体结构与组件的抽象描述
  • 用于指导软件系统各个方面的设计

通俗来说，实现一个软件有很多种方法，架构在方法选择上起着至关重要的作用。

2.2 单机架构

概念：软件系统需要对外提供服务，单机(All in one)，就是把所有功能都实现在一个进程里，并部署在一台机器上

优点：

  • 简单

问题：

  • 运维需要停服，用户体验较差

    任何运维操作都需要停服，因为只有一个单体服务，有用户使用的时间点没有办法运维

  • 承载能力有限，C10K problem

    C10K problem，也即单机处理 10k 个并发连接的问题。随着 epoll、kqueue 等技术的不断发展，高性能网络编程逐渐回答了 C10K 问题。但在互联网飞速发展的今天，我们正陆续面临 C10M、C10B 等问题。也就是说，单体服务一定是有架构瓶颈的。

演进：当今互联网时代，单机服务的形态一般只适合出现在预研或初创阶段，但凡业务有发展和迭代的诉求，就应该快速做架构迭代

2.3 单体架构

概念：在单机架构的基础上，将进程部署到多个机器上

我们把进程部署在多个机器上，并引入负载均衡层，经过这样的垂直切分，就来到了单体架构。多个机器就好比把蛋糕切成几大块，负载均衡层负责引导用户去事先切好的几块蛋糕处

优点：

  • 具备水平扩容能力
  • 运维不需要停服

缺点：

  • 后端进程职责太多，越来越臃肿，开发效率不高
  • 爆炸半径较大，进程中一个很小的模块出现问题，都可能导致整个进程崩溃

2.4 垂直应用架构

概念：在单机架构基础上，将进程按照某种依据切分开

按应用拆分进程，就好比慕斯、戚风等蛋糕在不同的点发配，这种经过垂直切分的架构，尝试解决了单机服务的水平扩容、运维停服问题

优点：

  • 一定程度上减少了后端进程职责
  • 一定程度上缩小爆炸半径

缺点：

  • 没有根本解决单体架构的问题

演进：随着业务场景越来越复杂，服务的职责也越来越多。在软件架构里单一职责的重要性也是不言而喻的，开发者不仅要关心 Web 后端业务逻辑，还要关心缓存、持久化存储，甚至跟机器打交道。长此以往，RD 很难分出精力专注于业务能力的开发，一旦出问题，影响不可估量，既然可以根据应用把架构做垂直拆分，那是否可以根据模块/职责对架构进行水平拆分呢？

2.5 SOA (面向服务架构)

概念：SOA(Service-Oriented Architecture)

以服务为一等公民，并为它们之间的通信定义标准，便得到了 SOA 架构

  • 将应用的不同功能单元抽象为服务
  • 定义服务之间的通信标准，保证各个服务之间通讯体验的一致性

这里有两个相对比较重要的概念：

服务，是根据功能抽象出来的概念。比如说，处理用户登录信息的 Passport 服务，负责持久化存储的数据库服务，以及为了加快查询速度的缓存服务等

通信标准，是服务之间通信的基石。没有实现定义好的通信标准，就好比多个做蛋糕的师傅语言不通，难以协作，为了服务之间更好的通信，有两个大的发展方向：中心化和去中心化

优点：

  • 各服务的职责更清晰
  • 运维粒度减小到服务，爆炸半径可控

缺点：

  • ESB (企业服务总线) 往往需要一整套解决方案

2.6 微服务架构

概念：SOA 的去中心化演进方向

在 SOA 架构中，ESB 起到了至关重要的作用。但从架构拓扑来看，它更像是一个集中式的模块。有一个 SOA 分布式演进的分支，最终的形态便是微服务

优点：

  • 兼具 SOA 解决的问题
  • 服务间的通信更敏捷、灵活

缺点：

  • 运维成本

2.7 小结

架构演进的初衷：

  • 满足软件迭代诉求，提高迭代效率

架构演进的思路：

  • 垂直切分——分布式
  • 水平切分——分层/模块化

3. 企业后端架构剖析

3.1 云计算

概念：是指通过软件自动化管理，提供计算资源的服务网络，是现代互联网大规模熟悉分析和存储的基石

基础：

  • 虚拟化技术
    • 硬件层面（VM 虚拟机）- KVM/Xen/VMware
    • 操作系统层面（Container 容器）- LCX/Docker/Kata Container
    • 网络层面 - Linux Bridge/Open v Switch
  • 编排方案
    • 虚拟机编排方案 (OpenStack)
    • 容器编排方案 (Kubernetes)

架构：

  • IaaS (Infrastructure as a Service)
    • 云基础设施，对底层硬件资源池的抽象
  • PaaS (Platform as a Service)
    • 基于资源池抽象，对上层提供的弹性资源平台
  • SaaS (Software as a Service)
    • 基于弹性资源平台构建的云服务
  • FaaS (Function as a Service)
    • 更轻量级的函数服务

3.2 云原生

概念：实际是云原生(计算)的简称，它是云计算发展到现在的一种形态

云原生技术为组织（公司）在公有云、自由云、混合云等新型的动态环境中，构建和运行可弹性拓展的应用提供了可能

下面将介绍其主要涉及的四个方面：

3.2.1 弹性资源

基于虚拟化容器以及灵活的编排调度机制，可以为云服务提供快速扩缩容能力，而且极大程度地提高了物理资源的利用率。可以分为弹性计算资源和弹性存储资源两个方面。

弹性计算资源：

  • 服务资源调度
    • 微服务
    • 大服务
  • 计算资源调度
    • 在线计算：互联网后端服务
    • 离线计算：大数据分析
  • 消息队列
    • 在线队列：削峰、解耦
    • 离线队列：大数据分析

弹性存储资源：

  • 经典存储
    • 对象存储：视频、图片等
    • 大数据存储：应用日志、用户数据等
  • 关系型数据库
  • 元数据
    • 服务发现
  • NoSQL
    • KV 存储：Redis
    • 文档存储：Mongo

总结：将存储资源当成服务一样

3.2.2 DevOps

云原生时代软件交付的利器，贯穿整个软件开发周期

  • 敏捷开发
  • CI/CD

3.2.3 微服务架构

通信标准：微服务架构下，服务之间的通讯标准是基于协议而不是 ESB 的

  • HTTP (RESTful API)
  • RPC (Thrift，gRPC)

微服务中间件 RPC vs HTTP：

  • 性能 - RPC 协议往往具备较好的压缩率，性能较高
  • 服务治理 - RPC 中间件往往集成了丰富的服务治理能力
  • 可解释性 - HTTP 通信的协议往往首选 JSON，可解释性、可调试性更好

云原生场景下，微服务大可不必在业务逻辑中实现符合通信标准的交互逻辑，而是交给框架来做

3.2.4 服务网格

概念：

  • 微服务之间通讯的中间层
  • 一个高性能的 4 层网络代理
  • 业务代码与治理解耦

服务网格相比较于 RPC/HTTP 框架：

  • 异构系统治理统一化
  • 与业务进程解耦，生命周期易管理

4. 总结

架构对于一个软件的重要性，就类似地基对于一栋楼房的重要性，良好的架构基础，为软件的未来发展提供了更多的可能！

参考：

  • 字节内部课：架构初探
avatar
文章
阅读
粉丝