架构初探 | 青训营笔记

130 阅读6分钟

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

架构定义解析

什么是架构

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

实现一个软件有很多种方法,架构在方法选择上起着至关重要的指导作用

架构的重要性

  • 地基没打好,大厦容易倒
  • 地基坚实了,大厦才能盖得高
  • 站在巨人肩膀上,才能看得远

单机

软件系统需要具备对外提供服务,单机,就是把所有功能都实现在一个进程里,并部署在一台机器上

优点:

  • 简单

问题:

  • C10K problem

The C10K problem

  • 运维需要停服

那么想要提升服务能力与负载能力呢?直观想法就是增加服务人员

单体

使用分布式部署,将进程部署到多个机器上。

优点:

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

缺点:

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

垂直应用架构

单体架构每个服务器的职能实际上都是一样的,大差不差,后端进程职能太多

如果将原本的进程垂直切分为多个进程,再按照单体架构分布式部署,可以进一步缓解后端臃肿问题,减小爆炸半径

优点:

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

缺点:

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

但实际上,每个师傅还是完完整整从头到尾的做了一个蛋糕,如果可以根据每道工序来分工,形成一个类似于流水线一样的模式,会不会更好呢?(进行一定程度上的 水平切分

SOA (面向服务架构)

(Service-Oriented Architecture) (面向服务的体系结构)

  1. 将应用的不同功能单元抽象为 服务
  2. 定义服务之间的 通信标准

SOA 架构中,服务为一等公民,将进程按照不同的功能单元进行抽象,拆分为『服务』。有了服务之后,SOA 还为服务之间的通信定义了标准,保证各个服务之间通讯体验的一致性。

优点:

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

缺点:

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

图中可以发现,兰师傅蛋糕店的员工都要通过一套特殊的沟通技巧来相互传递信息,这里就很可能成为一个业务上解决的难点,可能需要一套解决方案。为了进一步完善架构,SOA 的去中心化是必须的,而进行去中心化之后就演进为了微服务:

微服务

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

优点:

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

缺点:

  • 运维成本

相关问题思考

最后两种架构中,可能会出现一些问题:

  • 数据一致性

    在多个服务和节点间如何保证数据一致

  • 高可用

    服务间如何协同合作

  • 治理

    某一环节或服务瘫痪,如何容灾

  • 解耦过度,过微

    微服务过多了,运维压力也直线上升,是否应当考虑不要过分解耦编写过多微服务

架构演进的过程中,需求量变大就增加服务节点,功能越来越复杂就不断切分

企业级后端架构剖析

云计算

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

云计算基础

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

云计算架构

  • 云服务
    • IaaS(Infrastructure as a Service) - 云基础设施,对底层硬件资源池的抽象
    • PaaS(Platform as a Service) - 基于资源池抽象,对上层提供的弹性资源平台
    • SaaS(Software as a Service) - 基于弹性资源平台构建的云服务
    • FaaS(Fuction as a Service) - 更轻量级的函数服务。好比 LeetCode 等 OJ,刷题时只需要实现函数,不需要关注输入输出流
  • 云部署模式(拓展)
    • 私有云 - 企业自用
    • 公有云 - AWS/Azure/Google Cloud/Huawei
    • 混合云

云原生

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

  • 弹性资源
    • 虚拟化容器
    • 快速扩缩容
  • 微服务架构
    • 业务功能单元解耦
    • 统一的通信标准
  • DevOps
    • 敏捷开发
    • CI/CD
  • 服务网格
    • 业务与治理解构
    • 异构系统的治理统一化
    • 复杂治理能力

弹性资源

弹性计算资源:

  • 计算资源调度
    • 在线计算 - 互联网后端服务
    • 离线计算 - 大数据分析。Map-Reduce/Spark/Flinnk
  • 服务资源调度
    • 微服务
    • 大服务
  • 消息队列
    • 在线队列 - 削峰、解耦
    • 离线队列 - 结合数据分析的一整套方案,如 ELK

弹性存储资源:

  • 经典存储
    • 对象存储 - 视频、图片等。结合 CDN 等技术,可以为应用提供丰富的多媒体能力
    • 大数据存储 - 应用日志、用户数据等。结合数据挖掘、机器学习等技术,提高应用的体验
  • 关系型数据库
  • 元数据
    • 服务发现 - etcd(注册登记服务,微服务常用)
  • NoSQL
    • KV 存储 - Redis
    • 文档存储 - Mongo(适合更加灵活的数据类型)

DevOps

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

结合自动化流程,提高软件开发、交付效率

微服务架构

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

  • HTTP - H1/H2
  • RPC - Apache Thrift/gRPC

如何在 HTTP 和 RPC 之间选择?

  • 性能 - RPC 协议往往具备较好的压缩率,性能较高。如 Thrift, Protocol Buffers
  • 服务治理 - RPC 中间件往往集成了丰富的服务治理能力。如 熔断、降级、超时等
  • 可解释性 - HTTP 通信的协议往往首选 JSON,可解释性、可调试性更好

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

服务网格

服务网格:微服务进入2.0时代 - 掘金 (juejin.cn)

服务网格(Service Mesh):

  • 微服务之间通讯的中间层(所以是加了一层中间层)
  • 一个高性能的 4 层网络代理
  • 将流量层面的逻辑与业务进程解耦

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

  • 实现了异构系统治理体验的统一化
  • 服务网格的数据平面代理与业务进程采取进程间通信的模式,使得流量相关的逻辑(包含治理)与业务进程解耦,生命周期也更容易管理