架构初探 | 青训营笔记

82 阅读5分钟

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

这节课介绍了软件工程架构及其演进史,并包含了企业级后端架构刨析、企业级后端架构的挑战等内容。

什么是架构

架构,又称软件架构:

  • 是有关软件整体结构与组件的抽象描述

  • 用于指导软件系统各个方面的设计

软件架构是有关软件整体结构与组件的抽象描述,用于指导大型软件系统各个方面的设计。软件架构会包括软件组件、组件之间的关系,组件特性以及组件间关系的特性。

单机架构

All in one,所有的东西都在一个进程里,部署在一个机器上。

这种架构的好处是,开发和部署起来十分简单,对于小型应用来说足矣。但对于大型应用来说,他的并发性不足,存在性能瓶颈(如著名的 The C10K problem),并且无法保证高可用性,此外在对应用进行运维时,需要停服。

单体架构和垂直应用架构

在单机架构的基础上,将进程部署到多个机器上。

而竖直应用架构则更进一步,将服务进行竖直切分,让将一个服务切分成多个功能互不相干的服务,独立运行。

值得一提的是,无论是单体架构还是垂直应用架构,都需要一个中心化的负载均衡层引导用户使用需要的服务。

单体架构和垂直应用架构解决了单机架构的停服问题,保证了高可用性,因为其中一个服务下线并不影响其他服务正常运行,或可由其他服务替代线下服务;同时,这种架构还支持水平扩容,只需要简单增加服务数量,就可以轻松服务更多用户。但是这种架构的缺点是,每个服务虽然各自独立,却负责了太多职能,这导致每个服务开发效率急剧降低,模板代码增多,且爆炸半径巨大。

SOA和微服务框架

SOA 以水平切分的思想,通过将一个应用之间有关联和无关联的功能都切分成一个个单独运行的服务,并通过某种通信标准(例如 HTTP, RPC)交换数据,最终构成一个完整的服务整体。

SOA 架构中,服务为一等公民,将进程按照不同的功能单元进行抽象,拆分为『服务』。有了服务之后,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 - 云基础设施,对底层硬件资源池的抽象
    • PaaS - 基于资源池抽象,对上层提供的弹性资源平台
    • SaaS - 基于弹性资源平台构建的云服务
    • FaaS - 更轻量级的函数服务。好比 LeetCode 等 OJ,刷题时只需要实现函数,不需要关注输入输出流
  • 云部署模式(拓展)

    • 私有云 - 企业自用
    • 公有云 - AWS/Azure/Google Cloud/Huawei
    • 混合云

云原生

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

  • 弹性资源

云原生可以为企业提供弹性计算资源(如服务资源调度,计算资源调度,消息队列等)和弹性存储资源(如对象存储,关系型数据库,NoSQL 等)。

  • 微服务架构

云原生场景下,可使用微服务中间件(使用 RPC,HTTP 等协议进行通信)或服务网格(Service Mesh)组织容器之间的沟通。

  • DevOps

DevOps 是云原生时代软件交付的利器,贯穿整个软件开发周期。结合自动化流程,提高软件开发,交付效率。常见的 DevOps 有敏捷开发,CI/CD 等。

  • 服务网格

服务网格是微服务之间通讯的中间层,一个高性能的 4 层网络代理,将流量层面的逻辑与业务进程解耦。

没有什么是加一层代理解决不了的问题,服务网格相比较于 RPC/HTTP 框架:实现了异构系统治理体验的统一化,服务网格的数据平面代理与业务进程采取进程间通信的模式,使得流量相关的逻辑(包含治理)与业务进程解耦,生命周期也更容易管理。

企业级后端架构的挑战

问题:

  • 物理资源有限(机器、带宽)
  • 资源利用率受制于部署服务
  • 网络通信和网络抖动导致成本提高
  • 异构环境下,不同实例资源水位不均

解决方案:

  • 离在线资源并池,自动缩扩容(在线业务是指 IO 密集型业务,有实时性要求,离线业务是指计算密集型业务。在不同的时间以在线资源资源占用为量度,为在线资源和离线资源分配不同的空间来动态利用剩余资源)
  • 微服务亲和性部署,通过将微服务调用形态与资源调度系统结合,将一些调用关系紧密、通信量大的服务部署在同一个机器上,并且使用 IPC 代替 RPC 的方式,降低网络通信带来的开销
  • 流量治理
  • CPU 水位复杂均衡