题记
这是我参与「第五届青训营 」伴学笔记创作活动的第 16天,本文用于记录在青训营的学习笔记和一些心得。
day16 2月9日
课程目标
本课程的包含以下四个方面:
-
什么是架构
- 围绕架构的定义和演进两部分内容展开
-
企业级后端架构剖析
- 详细介绍企业级后端架构的形态
-
企业级后端架构的挑战
- 企业级架构都面临着哪些挑战,如何解决
-
后端架构实战
- 结合前三部分的知识点,以第三部分中的一个挑战为例,讲解如何做架构设计
01 什么是架构
架构,又称软件架构。
- 是有关软件整体结构与组件的抽象描述
- 用于指导软件系统各个方面的设计
Q:定义还是太抽象,能不能再通俗一点?
- 实现一个软件有很多种方法,架构在方法选择上起着至关重要的指导作用
Q:架构的重要性?
- 地基没打好,大厦容易倒
- 地基坚实了,大厦才能盖得高
- 站在巨人肩膀上,才能看得远
单机架构
软件系统需要具备对外提供服务,单机,就是把所有功能都实现在一个进程里,并部署在一台机器上。
优点:
- 简单
问题:
- C10K problem,也即单机处理10k个并发连接的问题,随着epoll,kqueue等技术的不断发展,高性能网络编程逐渐回答了C10K问题。但在互联网飞速发展的今天,我们正陆续面临C10M,C10B等问题,也就是说,单体服务一定是有架构瓶颈的。回到兰师傅蛋糕店,仅靠兰师傅自己买蛋糕,就算在怎么磨练手速,每天能卖出去的量有上限的。。。
- 运维需要停服。任何运维操作都需要停服,因为只有一个单体服务,有用户使用的时间点没有办法运维。再看我们的蛋糕店,如果兰师傅去上厕所了。。。
单机服务的模式,除了简单之外没有任何优点。当今互联网时代,单机服务的形态一般只适合出现在预研或初创阶段,但凡刚业务有发展和迭代的诉求,就应该快速做架构迭代。
单体架构,垂直应用架构
我们把进程部署在多个机器上,并引入负载均衡层,经过这样的垂直切分,就来到了单体架构。多个机器就好比把蛋糕切成几大块,负载均衡层负责引导用户去事先切开的几块蛋糕处在单休架构基础上,进一步地,再把不同应用的代码从之前一个大的进程中拆分出来,就来到了垂直应用架构。按应用拆分进程,就好比慕斯、戚风等蛋糕在不同的点发配。
单体架构:分布式部署
垂直应用架构:按应用垂直切分的单体
优点:
- 水平扩容
- 运维不需要停服
问题:
- 职责太多,开发效率不高
- 爆炸半径大(比如肉松师傅有一步骤失误,会导致整个肉松蛋糕链无法供应肉松蛋糕)
SOA,微服务架构
我们把原本包含了众多复杂逻辑的进程按照功能单元抽象成多个服务,以服务为一等公民,并为它们之间的通信定义标准,便得到了SOA架构,这里有两个相对比较重要的概念:服务,是根据功能抽象出来的概念。比如说,处理用户登录信息的Passport服务,负责持久化存储的数据库服务,以及为了加快查询速度的缓存服务等通信标准,是服务之间通信的基石。没有实现定义好的通信标准,就好比多个做蛋糕的师傅语言不通,难以协作。
为了服务之间更好的通信,有两个大的发展方向:中心化和去中心化。因为中心化的方案形态较重,拓展性不佳,普及性不佳,我们跳过不讲。而去中心化的方向,最终的形态就是微服务架构。
这下, 1.不同模块的RD可以专心于自己的业务逻辑了,开发迭代效率得到显著提高
⒉各个服务独立运维,变更操作的影响面可控,应用整体的稳定性得到了提高
小结
架构的演进初衷:好比做蛋糕。
- 需求量越来越大,终归要增加人手
- 越做越复杂,终归要分工合作
架构的演进思路:就像切蛋糕。蛋糕越来越大,一口吃不下终归要切分。
- 竖着切(垂直切分)
- 横着切(水平切分)
02 企业级后端架构剖析
云计算的精髓就是把有形的产品(网络设备、服务器、存储设备、各种软件等)转化为服务产品,并通过网络让人们远距离在线使用,使产品的所有权和使用权分离。
云计算基础:
-
虚拟化技术
- 硬件层面(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,刷题时只需要实现函数,不需要关注输入输出流
聊完云计算,有必要马上来看一下云原生。云原生,实际是云原生(计算)的简称,它是元计算发展到现在的一种形态。
云原生技术为组织(公司)在公有云、自由云、混合云等新型的动态环境中,构建和运行可弹性拓展的应用提供了可能。它的代表技术有:
- 容器化
- 服务网格
- 微服务
- 不可变基础架构
- 声明式 API
基于这些技术,开发者可以构建出容错性好、易于管理、具备较好观测性的云服务。结合可靠的自动化机制,服务可以轻松应对频繁和可预测的重大变更。
云原生主要涉及四个大方面:
弹性资源:基于虚拟化容器以及灵活的编排调度机制,可以为云服务提供快速扩缩容能力,而且极大程度地提高了物理资源的利用率。在这方面,kubernetes 技术已经称为了业界的标准
微服务架构:还记得前面我们聊到的微服务架构么?没错,它也是云原生的重要基石之一。依托于功能单元解构,使得云服务具备了快速迭代的可能,业务得以迅速发展;统一的通信标准能够帮助越来越多的组件加入到云原生的大家庭,同时也使得各组件之间的交互变的更容易
DevOps:设计->开发->测试->交付->开发->测试->交付,自动化的流程使得软件的工作流程更高效,将微服务架构的优势发挥的淋漓尽致
服务网格:如果说微服务架构的重要进步,是将庞大的单体服务按照业务功能解耦开来,那么,服务网格的重要进步就是将业务逻辑与网络通信和治理解耦开来。业务不再需要关心异构系统中 RPC 中间件治理能力的不统一,也使得复杂的治理能力的落地成为可能
什么是云原生DevOps:t.csdn.cn/FvTzb
服务网格是什么“格”:t.csdn.cn/GMtvx
云计算到底是什么?: www.bilibili.com/video/BV1yh…
03 业内后端架构面临的挑战
扩缩容指标:CPU(多数,比如CPU统计单位数)和内存作为指标,IO可行性比较难。
04 后端架构实战
尾声
-
没有最好的架构,只有最合适的架构
-
做架构设计
- 先从需求出发。要满足什么样的需求?预期规模有多大?
- 做足够的业界调研。业界对于类似的需求是怎么做的?有无成熟的方案可以借鉴?直接拿来用有什么问题?
- 技术选型。涉及的技术组件是自研,还是使用开源的?
- 异常情况。任何时候,都不能做『输入合法』的假设。容灾能力一定要有
-
学好架构,是工程师成长的一个重要标志
课后作业
兰师傅蛋糕房要支持线上售卖了!请帮忙做整套系统的架构设计
设计需求:
-
多端支持
- 微信/支付宝小程序
- App
- 网页
-
使用云原生基础设施
-
用户画像很重要
-
积极参加妇女节/光棍节等活动
⚠️注意: 不需要考虑与做蛋糕相关服务的交互