前言: \textcolor{Green}{前言:} 前言:
💞这个专栏就专门来记录一下寒假参加的第五期字节跳动训练营
💞从这个专栏里面可以迅速获得Go的知识
架构对于一个系统来说是非常重要的,因为一个完整系统的开发如果交给一个人那么这个人是吃不消的。分工合作又会导致其他的一些问题,那么最终有利于我们的结果是什么呢?先来了解一下架构是什么。
01. 什么是架构
1.1 定义
架构,又称软件架构。
- 是关于软件整体结构与组件的抽象描述
- 用于指导软件系统各个方面的设计
通俗点来说就是:实现一个软件有很多种方法,架构在方法选择上起着至关重要的指导作用
架构的重要性
- 地基没打好,大厦容易倒
- 地基坚实了,大厦才能盖的高
- 站在巨人的肩膀上,才能看得远
1.1 问题
我们通过一个蛋糕店来将架构的例子明显表示出来
一个蛋糕坊要开张了,需要解决如下的几个问题
- 如何做蛋糕
- 独家秘方,还是亲自做比较好
- 如何卖蛋糕
- 刚开始客流量应该不大,边做边卖
此时看着问题解决了,那么开店营业试试
1.2 什么是架构 - 单机
软件系统需要具备对外提供服务,单机
:就是把所有功能都实现在一个进程里,并部署在一个机器上,如下图中:
优点:是简单
问题:C10K problem。运维的时候需要停服
这里讲一下 C10K problem
C10K problem是指如何让服务器能够支持10k并发
此时我们想卖更多的蛋糕应该怎么做?
首先想到的就是,卖蛋糕,一个人不够,那么我就多雇几个蛋糕师傅做。
1.3 什么是架构 - 单体、垂直应用|垂直切分
单体架构:分布式部署
垂直应用架构:按应用垂直切分的单体
优点:
- 水平扩容
- 运维不需要停服
问题: - 职责太多,开发效率不高
- 爆炸半径大
此时就出现了新的问题:如何提高做蛋糕的效率。
那么就需要分工协作了。
把进程部署在多个机器上
,并引入负载均衡层
,经过垂直拆分,就到了单体架构。多个机器就好比把蛋糕切成几大块,负载均衡层引导用户去事先切好的几块蛋糕处。在单体架构基础上,进一步地再把不同应用的代码从之前一个大的进程中拆分出来,就来到了垂直应用架构。按应用拆分进程,就例如不同种类的蛋糕在不同的点发配。
经过垂直切分,尝试解决了单机服务的水平扩容、运维停服问题,当然只是简单的,细节的如多个机器上部署的进程如何保证数据一致性等会在后面进行讨论。
解决了两个重要问题,也面临着很多挑战,导致我们必须放弃单体和垂直应用架构。
随着业务场景的复杂,服务的职责也越来越多。在软件架构中,开发者需要关心 Web 后端业务逻辑,还要关心缓存、持久化存储,甚至机器。至此,开发人员很难专注于业务能力的开发。
1.4 什么是架构 - SOA、微服务|水平切分
将原本包含了众多复杂逻辑的进程按照功能单元抽象成多个服务,以服务为一等公民,并为它们之间的通信定义标准,得到了SOA架构(Service-Oriented Architecture)。
服务
:是根据功能抽象出来的概念。例如:处理用户登录信息的 Passport 服务,负责持久化存储的数据库服务,以及为了加快查询速度的缓存服务等。(将应用的不同功能单元抽象为服务)
通信标准
:是服务之间通信的基石。没有定义好的通信标准,就像多个做蛋糕的师傅语言不通,难以协作。
为了服务之间更好的通信,有两个发展方向:中心化和去中心化。去中心化的最终形态就是微服务架构
。(定义服务之间的通信标准)
此时。不同模块的RD可以专心于自己的业务逻辑,开发迭代效率得到了显著提高。各个服务独立运维,变更操作的影响面可控,应用整体的稳定性得到了提高。
再次看一下垂直拆分和水平切分产生的一系列问题:
由单机部署演进来的分布式架构,如何解决数据一致性。(装货台共支付了多少蛋糕)
服务越来越多,依赖越来越复杂,如何做到高可用。(这么多的师傅,如何合作)
一个团队甚至一个人可能同时管理多个微服务,如何运维。(烤箱坏了,怎么容灾)
微服务的目标是强化单一职责,控制爆照半径,如何在解耦和过微之间取舍。(运维成本高了,值当吗?)
小结
架构的演进初衷:好比做蛋糕
- 需求量越来越大,终归要增加人手
- 越做越复杂,终归要分工合作
架构的演进思路:就像切蛋糕。蛋糕越来越大,一口吃不下终归要切分
- 竖着切(垂直切分)
- 横着切(水平切分)