【鹅厂摸鱼日记(一)】(工作篇)认识八大技术架构

💓博主CSDN主页:杭电码农-NEO💓
 
⏩专栏分类:重生之我在鹅厂摸鱼⏪
 
🚚代码仓库:NEO的学习日记🚚
 
🌹关注我🫵带你学习更多知识
  🔝🔝

---

---

1. 前言

这不是前几天刚拿到鹅厂的offer嘛,由于想表达我对工作的热情,于是我主动向我上司请缨想要提前了解一下公司的业务,不问不知道,一问吓一跳,我上司也是给我抛出了一堆概念,包括RPC,gRPC,k8s,docker还有open telemetry,我心里一惊,哥们我是听都没听过啊,不知从何下手,感觉以目前的知识储备直接去学习这些东西,属于是不自量力了,于是这几天我对前面的铺垫知识进行了恶补

本章重点:

本篇文章着重讲解八大架构的演化过程,以及它们的优缺点,并且会在其中介绍负载均衡,redis,docker,以及k8s它们的定位,最后会讲解什么是分布式系统,为后面的gRPC学习打下基础

---

2. 架构简介&单机架构

首先第一个问题,什么是架构?
为什么要有它?

架构是指系统或应用程序的整体结构或设计，包括不同组件之间的关系、功能模块的划分、数据流程、通信协议等方面。架构设计旨在确保系统具有良好的可扩展性、可维护性、安全性和性能。在软件开发中，架构设计是非常重要的步骤，它直接影响到系统的质量和效率

现在来了解一下最简单的架构:

单机架构
即应用服务和数据库服务都在一台服务器的架构

它属于最早期,最简单的架构
现在实战中基本已经不用了
可以适合初学者来写demo

由于单机架构的缺点十分致命,所以后来又出现了许多架构,而新出现的架构又有自己的缺陷,所以技术就不断的更新迭代!

---

3. 应用数据分离架构&集群架构

由于单机架构的缺陷非常致命
所以将应用和数据进行分离十分重要
于是衍生出了 应用数据分离架构

一些小公司或小网站,它的并发量不大,并且预算也有限,于是选择了将应用和数据分离的做法，可以最小代价的提升系统的承载能力

---

显而易见,上面的架构对于少量访问量来说,是可取的,但是并发量一旦起来,这个服务器必会崩溃!所以架构又向后演进了一级

应用服务集群架构
即我无法承担大并发量,就叫上我的兄弟一起

什么是负载均衡?

一个应用对应一个服务器,而集群架构会有多个应用,即多个服务器一起运行,那么当一个请求到来时,我怎么知道哪个服务器正在运行?哪个服务器处于空闲?甚至是哪个服务器接受的任务少,就用谁这种问题,正所谓没有什么问题是加一层软件层解决不了的,所以负载均衡的作用就是一个决策层

程序员的两句真言:

1. 我自己做不到,那就叫上我的兄弟一起抗
2. 没有什么是加一层软件层做不到的

同理,如果一个负载均衡(比如nginx,LVS等)不足以承受百万级甚至是亿级的并发请求,那么就多用几个负载均衡,或者使用并发性更好的负载均衡

---

4. 读写分离&冷热分离架构

对于集群架构而言,虽然说确实解决了应用层的并发问题,但是现在新的问题出现在了数据库服务,一旦上层频繁访问数据库(读或写)就会导致整个服务变得很慢,并且一般情况下,对于服务器资源都是读多而写少,所以进化出了新的架构

读写分离架构
即将数据库的读和写放在不同服务器

将数据服务一分为二后
会出现一个主服务器和从服务器
主服务器负责写入,而从服务器负责简单读取

还是程序员两句真言,应用并不知道用户要读还是要写,所以在应用和数据间加一层软件层(例如mycat)来解决这个问题,所以实际上读写分离架构是这样的

---

虽然读写分离架构确实能解决数据库承载压力大的问题,但是一旦某个数据频繁的被用户读取,那么这个架构也会导致数据库的负载很高,所以推出了新的架构

冷热分离架构
即把热点数据放在缓存中
请求到来时直接去缓存中取,速度很快
把冷数据继续放在数据库磁盘

常见的缓存软件有大家熟知的redis,冷热分离架构虽然说会进一步增加服务器的成本,但是确实突破了之前的瓶颈

---

5. 垂直分库架构&微服务架构

由于应用层可以通过不断喊上兄弟来一起抗,所以到目前为止,整个服务的效率瓶颈都在数据库方面,而垂直分库结构就是将一个数据库分为多个库甚至多个表

分库分表:

垂直分库架构,又叫分布式数据库架构
到底什么是分布式?

系统中的多个模块被部署于不同服务器之上，即可以将该系统称为分布式系统。如 Web 服务器与数据库分别工作在不同的服务器上，或者多台 Web 服务器被分别部署在不同服务器上。生活例子类比：为了更好的满足现实需要，一个在同一个办公场地的工作小组被分散到多个城市的不同工作场地中进行远程配合工作完成目标。跨主机之间的模块之间的通信基本要借助网络支撑完成

并且进行了分库分表后,前面的冷热分离,以及读写分离也能套用在这个架构中

---

垂直分库架构的缺陷页十分明显,虽然数据库现在可无限拓展,但是代码的运维成本太高了,修改一行代码就需要整体将服务重新发布,于是又有新的架构来代替它

微服务架构
即按照业务板块来划分业务代码
使之相互之间可独立进行更新迭代

微服务架构和前面的结构的最大的区别就是,前面的架构中,每个服务器都对应用户,商品,交易三个整体的应用服务,而微服务架构则是将每个用户当作一个微服务放在一个服务器中,用户和商品要进行交互就是服务器之间进行交互

---

6. 容器编排架构&互联网实战

容器编排架构是目前比较成熟的架构,由于微服务拆分巨细,服务多部署时工作量大,并且容易出错,所以容器编排架构本质就是借助容器化技术(比如docker)将应用或服务打包成为镜像,然后通过容器编排工具(比如k8s)来快速的发布和部署镜像

可以将这个架构类比于发快递,你分别向北京和上海寄一件衣服一件裤子一双鞋子,一共是六件物品,那么在寄东西前你肯定需要将这六件物品两两分组,每组都有衣服裤子鞋子,然后再用顺丰发送到不同的地点,这里的分组就类似于docker,而发送快递就类似于k8s

一台服务器可以部署多个容器,而这些容器可相互交流数据,并且又相互不影响

---

在实际的互联网实战中,情况可能比我们学习的架构要复杂的多,但是万变不离其宗,掌握了基本的架构原理后,它再怎么拓展应用,再怎样细分数据库服务,我们都能快速掌握它的核心,下面是一些公司常用的服务,大家可以了解一下:

显而易见,统一数据服务层出现的原因就是因为下层的数据库服务很多,并且每个服务都有自己的API接口,要是程序员自己要去了解所有的数据库服务就十分的麻烦,所以增加了一层来辅助完成这一个工作

---

7. 总结

其实我发现,做C/C++开发的话,并不是单纯的了解语言和操作系统就可以稳住脚跟,掌握不同的架构思想以及像redis,docker,k8s,protobuf这种工具也十分重要,毕竟只是单纯写代码完成任务的时代早就过去了,公司的整个架构和业务才是重心啊

---