ycgg的GO语言之路Day10——架构初探｜ 青训营笔记

用户3295945537528
24 阅读8分钟

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

Day10——架构初探

01.什么是架构

定义

架构，又称软件架构,是有关软件整体结构与组件的抽象描述，用于指导软件系统各个方面的设计

通俗的说就是实现一个软件在方法选择上的指导

单机架构

软件系统需要具备对外提供服务，单机,就是把所有功能都实现在一个进程里，并部署在一台机器上

比如开蛋糕店自己作师傅，一个人打理

优点是简单

缺点是运维需要停服

单体、垂直应用/垂直切分

单体架构:分布式部署

可以类比成多请几个蛋糕师傅

image-20230205212735010.png

垂直应用框架：按应用垂直切分的单体

比如按做蛋糕的类型请多个师傅

image-20230205212745669.png

优点：水平扩容，运维不需要停服

问题:职责太多，开发效率不高，爆炸半径大

SOA，微服务/水平切分

SOA (Service-Or iented Architecture)

1.将应用的不同功能单元抽象为服务

2.定义服务之间的通信标准

微服务架构:SOA的去中心化演进方向

以服务为中心，整个架构都面向服务，让服务间产生交互与沟通

image-20230205213126836.png

如图沟通技巧部分显然需要频繁交互，是中心，而微服务在逐渐去中心化

image-20230205213207093.png

需要解决的问题：

1.数据一致性问题，统计卖出蛋糕的个数

2.高可用，许多的蛋糕师傅如何高效合作

3.治理，假如烤箱坏了，如何容灾

4.解耦和过微的问题，平衡耦合和过度微小的问题

02.企业级后端架构剖析

背景：

image-20230205213819518.png

根据这个实际的问题可以映射企业级架构

云计算

云计算:是指通过软件自动化管理，提供计算资源的服务网络，是现代互联网大规模熟悉分析和存储的基石。

基础:

虚拟化技术–整租（整个机器都自己用）vs合租（许多人一起用这几台虚拟机）

编排方案–业主vs租赁平台

架构：

laas ( lnfrastructure as a Service）

买房子vs房屋租赁平台

PaaS (Platform as a Service) 清包vs全包（自己装修，外包装修）

Saas (Software as a Service)

从零培训vs雇佣培训过的师傅（不使用云计算提供的功能，使用云计算）

FaaS (Function as a Service)

纯手工制作vs蛋糕机批量生产（使用云计算就如同批量生产蛋糕）

如果使用云计算，可以使我们更加专注于业务开发，而不是底层细节

云原生

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

image-20230205214758505.png

弹性计算资源类型:

1.服务资源调度 微服务:和面、雕花

大服务:烤箱 2.计算资源调度 在线:热销榜单

离线:热销榜单更新

3.消息队列 在线:削峰处理海量数据削峰、解耦

离线:大数据分析

弹性存储资源类型：

1.经典

对象存储:宣传视频

大数存储据:用户消费记录

2.关系型数据库

收银记录

3.元数据

服务发现:蛋糕店通讯录，师傅，用户都住在哪里，电话号码是什么

4.NoSQL

KV（key-value）:来个xx蛋糕

Devops

Dev0ps是云原生时代软件交付的利器,贯穿整个软件开发周期。结合自动化流程，提高软件开发、交付效率

image-20230205215737765.png

微服务架构

通信标准:

  • HTTP (RESTful API)
  • RPC (Thrift,gRPC)

image-20230205220114545.png

在微服务中间件的选择上可以考虑以下几个方面

1.性能

一般情况RPC会比HTTP的性能要好一些

2.服务治理

对于一些RPC中间件天生有服务治理的性质

3.协议可解释性

RPC有很多压缩方案，HTTP绝大多数json，有很好的解释性

云原生场景下，微服务大可不必在业务逻辑中实现符合通信标准的交互逻辑，而是交给框架来做

服务网格

服务网格(Service Mesh):

  • 微服务之间通讯的中间层
  • 高性能网络代理
  • 业务代码与治理解耦

相比较于RPC/HTTP框架

  • 异构系统治理统一化
  • 与业务进程解耦,生命周期易管理

image-20230205220853272.png

容器可以看成虚拟化机器，此处只观察数据流 即可

根据以上知识，可以对蛋糕店进行架构设计：

image-20230205221208820.png

03.企业级后端架构的挑战

问题

基础设施层面：

1.物理资源是有限的：机器，带宽

2.资源利用率受制于部署服务，比如有很多buffer的资源是可以利用的

用户层面：

1.网络通信开销较大

2.网络抖动导致运维成本提高

3.异构环境下，不同实例资源水位不均

离，在线资源并池

核心收益:降低物理资源成本，提供更多的弹性资源，增加收入

解决思路:离在线资源并池

在线业务的特点：IO密集型为主，潮汐性、实时性

离线业务的特点：计算密集型占多数（做数据分析等），非实时性

下面是并池模型：

image-20230205222257771.png

可以应对一些潮汐

同一个机器可以用虚拟化技术对离在线进程隔离

自动扩缩容

核心收益:降低业务成本

解决思路:自动扩缩容，利用在线业务潮汐性自动扩缩容

当不需要很多资源时，可以进行缩容，需要资源时进行扩容

这样在闲时资源量就变多了，也可以让在线资源得到充分利用

image-20230205222555418.png

扩缩容依据指标：主要以cpu分位数，也会以内存作为依据

对于IO为指标进行扩缩容，目前还有很大难度

微服务亲和性部署

核心收益:降低业务成本(序列化反序列化成本等），提高服务可用性

解决思路:微服务亲合性部署

将满足亲合性条件的容器调度到一台宿主机，微服务中间件与服务网格通过共享内存通信，服务网格控制面实施灵活、动态的流量调度

image-20230205223010189.png

会充分利用服务网格的控制面的流量调度

流量治理

核心收益:提高微服务调用容错性，容灾，进一步提高开发效率，Dev0ps发挥到极致

解决思路:基于微服务中间件&服务网格的流量治理

  • 熔断、重试
  • 单元化
  • 复杂环境(功能、预览)的流量调度

CPU水位负载均衡

核心收益：打平异构环境算力差异，为自动扩缩容提供正向输入

解决思路:CPU水位负载均衡

  • laaS：提供资源探针
  • 服务网格：动态负载均衡

image-20230205223408416.png

比如两个B容器CPU能力不同，可以根据两个B容器资源能力进行负载均衡

04.后端架构实战

问题背景：

不同师傅的效率不同，有些师傅希望多干多挣钱，有些能力差的完不成任务，想少干一些

这就是是CPU水位负载均衡的设计

问题提炼

输入：

1.服务网格数据面：支持带权重的负载均衡策略

2.注册中心存储了所有容器的权重信息

3.宿主机能提供：容器的资源使用情况，物理资源信息（如CPU型号)

关键点:

紧急回滚能力，大规模（系统稳定性），极端场景

image-20230205224018867.png

方案：自适应静态权重

方案:采集宿主机物理资源信息，调整容器注册的权重

优势:复杂度低，完全分布式，可用性，高微服务中间件无适配成本

缺点:无紧急回滚能力（比如权重改错了），缺乏运行时自适应能力（比如CPU能力变化，无法动态调整）

image-20230205224247743.png

方案：自适应动态权重1

方案:容器动态权重的自适应调整，服务网格的服务发现&流量调度能力

演进方向:解决无法紧急回滚的问题，运行时权重自适应

缺点:过度流量倾斜可能会有异常情况，就是大权重容器出现问题，会造成大流量请求失败

image-20230205224602288.png

如果动态权重出现问题，会紧急切换到静态权重

方案：自适应动态权重2

方案:服务网格上报 RPC指标

演进方向:极端场景的处理成为可能

缺点:时序数据库压力较大，动态权重决策中心职责越来越多，迭代→>变更→>风险

image-20230205224853996.png

时刻检测RPC指标，防止过于突变，导致流量倾斜

方案：自适应动态权重（最终版）

演进方向:微服务化，引入消息队列削峰、解耦，离在线链路切分，梳理强弱依赖

image-20230205225230173.png

小结：

  • 没有最好的架构，只有最合适的架构，要根据实际设计，一开始不要过度设计
  • 业界调查，查找可行方案
  • 技术选型，看内部和社区有哪些基础组件
  • 异常情况怎么办
avatar
文章
阅读
粉丝