这是我参与「第五届青训营 」伴学笔记创作活动的第 16 天
文章分为两部分:1)什么是架构;2)企业级后端架构剖析(云计算、云原生)
什么是架构
定义
架构
又称软件架构,
- 是有关软件整体结构与组件的抽象描述;
- 用于指导软件系统各个方面的设计。
Q1:定义还是太抽象,能不能再通一点?
A1:实现一个软件有很多种方法,架构在方法选择上起着至关重要的指导作用。
Q2:架构的重要性?
- 地基没打好,大厦容易倒;
- 地基坚实了,大厦才能盖得高;
- 站在巨人肩膀上,才能看得远。
单机
软件系统需要具备对外提供服务,单机,就是把所有功能都实现在一个进程里,并部署在一台机器上。
-
优点:
- 简单
-
问题:
- 运维需要停服
单机服务的模式,除了简单之外没有任何优点。当今互联网时代,单机服务的形态一般只适合出现在预研或初创阶段,但凡业务有发展和迭代的诉求,就应该快速做架构迭代。
什么是架构 - 单体、垂直应用 |垂直切分
单体架构:分布式部署
垂直应用架构:按应用垂直切分的单体
-
优点:
- 水平扩容
- 运维不需要停服
-
问题:
- 职责太多,开发效率不高
- 爆炸半径大
这种经过垂直切分的架构,尝试解决了单机服务的水平扩容、运维停服问题。
既然可以根据应用把架构做垂直拆分,那是否可以根据模块/职责对架构进行水平拆分呢?
SOA、微服务|水平切分
SOA(Service-Oriented Architecture)
- 将应用的不同功能单元抽象为服务
- 定义服务之间的通信标准
微服务架构:SOA 的去中心化演进方向
- 问题:
- 数据一致性
- 装货台共交付了多少蛋糕?
- 高可用
- 这么多师傅,如何合作?
- 治理
- 烤箱坏了,怎么容灾?
- 解耦 vs 过微
- 运维成本高了,值当么?
按照这个思路,我们把原本包含了众多复杂逻辑的进程按照功能单元抽象成多个服务,以服务为一等公民,并为它们之间的通信定义标准,便得到了 SOA架构。
-
服务
- 是根据功能抽象出来的概念。比如说,处理用户登录信息的 Passport 服务,负责持久化存储的数据库服务,以及为了加快查询速度的缓存服务等。
-
通信标准
- 是服务之间通信的基石。没有实现定义好的通信标准,就好比多个做蛋糕的师傅语言不通,难以协作。
为了服务之间更好的通信,有两个大的发展方向:
中心化和去中心化
因为中心化的方案形态较重,拓展性不佳,普及性不佳,跳过。
而去中心化的方向,最终的形态就是微服务架构。
结果:
- 不同模块的 RD 可以专心于自己的业务逻辑了,开发迭代效率得到显著提高;
- 各个服务独立运维,变更操作的影响面可控,应用整体的稳定性得到了提高。
垂直切分和水平切分所产生的一系列问题:
- 由单机部署演进来的分布式架构,如何解决数据一致性;
- 服务越来越多,依赖越来越复杂,如何做到高可用;
- 一个团队甚至一个人可能同时管理多个微服务,如何运维;
- 微服务的目标是强化单一职责,控制爆炸半径,如何在解耦和【过微】之间取舍。
小结
架构的演进初衷:好比做蛋糕。
- 需求量越来越大,终归要增加人手;
- 越做越复杂,终归要分工合作。
架构的演进思路:就像切蛋糕。蛋糕越来越大,一口吃不下终归要切分。
- 竖着切 (垂直切分)
- 横着切 (水平切分)
企业级后端架构剖析
云计算
云计算:
- 是指通过软件自动化管理,提供计算资源的服务网络,是现代互联网大规模数据分析和存储的基石
基础:
- 虚拟化技术 - 整租 vs 合租
- 编排方案 - 业主 vs 租赁平台
架构:
- laas (Infrastructure as a Service)
- 买房子 vs 房屋租赁平台
- Paas (Platform as a Service)
- 清包 vs 全包
- Saas (Software as a Service)
- 从零培训 vs 雇佣培训过的师傅
- FaaS (Function as a Service)
- 纯手工制作 vs 蛋糕机批量生产
-
虚拟化技术: 硬件 (虚拟机) 、操作系统 (容器) 、网络
-
编排方案: 虚拟机编排方案(OpenStack)、容器编排方案 (Kubernetes)
云原生
是云算生(计算)的简称,是元计算发展到现在的一种形态。
云原生技术为组织(公司)在公有云、自由云、混合云等新型的动态环境中,构建和运行可弹性拓展的应用提供了可能。
代表技术有:
- 容器化
- 服务网格
- 微服务
- 不可变基础架构
- 声明式 API
基于这些技术,开发者可以构建出容错性好、易于管理、具备较好观测性的云服务。结合可靠的自动化机制,服务可以轻松应对频繁和可预测的重大变更
云原生主要涉及四个大方面:
1. 弹性资源
- 基于虚拟化容器以及灵活的编排调度机制,可以为云服务提供快速扩缩容能力,而且极大程度地提高了物理资源的利用率。在这方面,kubernetes 技术已经成为了业界的标准。
2. 微服务架构
- 还记得前面我们聊到的微服务架构么? 没错,它也是云原生的重要基石之一。依于功能单元结构,使得云服务具备了快速迭代的可能,业务得以迅速发展,统一的通信标准能够帮助越来越多的组件加入到云原生的大家庭,同时也使得各组件之间的交互变的更容易。
3. DevOps
- 设计->开发>测试->交付->开发->测试->交付,自动化的流程使得软件的工作流程更高效,将微服务架构的优势发挥的淋漓尽致。
4. 服务网格:
- 如果说微服务架构的重要进步,是将庞大的单体服务按照业务功能解耦开来,那么,服务网格的重要进步就是将业务逻辑与网络通信和治理解耦开来。业务不再需要关心异构系统中 RPC 中间件治理能力的不统一,也使得复杂的治理能力的落地成为可能。
弹性计算资源
弹性计算资源类型:
- 服务资源调度
- 微服务:和面、雕花
- 大服务:烤箱
- 计算资源调度
- 在线:热销榜单
- 离线:热销榜单更新
- 消息队列
- 在线:削峰、解糯
- 离线:大数据分析
弹性存储资源类型
- 经典
- 对象:宣传视频
- 大数据:用户消费记录
- 关系型数据库
- 收银记录
- 元数据
- 服务发现:蛋糕店通讯录
- NoSQL
- KV:来个 xx 蛋糕
总结:将存储资源当成服务一样
DevOps
- 是云原生时代软件交付的利器贯穿整个软件开发周期。
- 结合自动化流程,提高软件开发、交付效率
通信标准:
- HTTP (RESTful API)
- RPC (Thrift. gRPC)
微服务中间件 RPC vs HTTP:
- 性能
- 服务治理
- 协议可解释性
云原生场景下,微服务大可不必在业务逻辑中实现符合通信标准的交互逻辑,而是交给框架来做。
服务网格 (Service Mesh):
- 微服务之间通讯的中间层
- 高性能网络代理
- 业务代码与治理解耦
相比较于 RPC/HTTP 框架:
- 异构系统治理统一化
- 与业务进程解耦,生命周期易管理
企业级蛋糕店架构:
- 售卖
- 蛋糕制作(肉松、慕斯)
- 会员激励
- 满意度分析
- 研发新品