这是我参与「第五届青训营」伴学笔记创作活动的第 7 天
前言
主要内容
- 什么是架构？
- 企业级后端架构剖析
- 企业级后端架构的挑战
- 后端架构实战
详细内容解析
01.什么是架构
--定义
架构又称软件架构
- 是有关软件整体结构与组件的抽象描述
- 用于指导软件系统各个方面的设计
简单来说，实现一个软件可以采用很多方法，架构就在方法选择上起着至关重要的指导作用。
--单机架构
软件系统需要具备对外提供服务，单机，就是把所有功能都实现在一个进程里，并部署在一台机器上
优点：简单
问题：运维需要停服
-单体架构与垂直应用架构
把进程部署到多个机器上，并引入负载均衡层，经过垂直切分，就变成了单体架构。
负载均衡是高可用网络基础架构的关键组件，通常用于将工作负载分布到多个服务器来提高网站、应用、数据库或其他服务的性能和可靠性。说白了，可以理解成一个分配任务的leader
垂直切分是根据业务来拆分数据库，同一类业务的数据表拆分到一个独立的数据库，另一类的数据表拆分到其他数据库。垂直切分可以降低单节点数据库的负载。原来所有数据表都放在一个数据库节点上，无疑所有的读写请求也都发到这个MySQL上面，所以数据库的负载太高。如果把一个节点的数据库拆分成多个MySQL数据库，这样就可以有效的降低每个MySQL数据库的负载。
单体架构：分布式部署
垂直应用架构：按应用垂直切分的单体
优点：
- 水平扩容
- 运维不需要停服 问题：
- 职责太多，开发效率不高
- 爆炸半径大（测试造成的任何损坏或影响都称为“爆炸半径”）
--SOA微服务与水平切分
水平切分： 是按照某个字段的某种规则，把数据切分到多张数据表。一张数据表化整为零，拆分成多张数据表，这样就可以起到缩表的效果了。
SOA(Service-Oriented Architecture)： 也就是面向服务的架构
- 将应用的不同功能单元抽象为服务（服务是根据功能抽象出来的概念）
- 定义服务之间的通信标准（通信标准是服务之间通信的基石）
微服务架构：SOA的去中心化演进方向
- 不同模块的RD可以专心于自己的业务逻辑了，开发迭代效率得到显著提高
- 各个服务独立运维，变更操作的影响面可控，应用整体的稳定性得到了提高
最后，我们还需要回答垂直切分和水平切分所产生的一系列问题:
- 由单机部署演进来的分布式架构，如何解决数据─致性
- 服务越来越多，依赖越来越复杂，如何做到高可用
- 一个团队甚至一个人可能同时管理多个微服务，如何运维
- 微服务的目标是强化单一职责，控制爆炸半径，如何在解耦和『过微』之间取舍
02. 企业级后端架构剖析
--云计算
云计算是指通过软件自动化管理，提供计算资源的服务网络，是现代互联网大规模分析和存储的基石。 云计算的基础：
- 虚拟化技术：硬件（虚拟机）、操作系统（容器）、网络
- 编排方案：虚拟机编排方案（OpenStack）、容器编排方案（Kubernetes）
架构方面:
- IaaS（Infrastructure as a Service）
- PaaS（Platform as a Service）
- SaaS（Software as a Service）
- FaaS（Function as a Service）
--云原生
云原生技术为组织在公有云、自由云、混合云等新型的动态环境中，构建和运行可弹性拓展的应用提供了可能，全称是云原生计算，是元计算发展到现在的一种形态，有如下几种代表技术：
- 容器化
- 服务网格
- 微服务
- 不可变基础架构
- 声明式API
云原生主要涉及四个大方面：
- 弹性资源:基于虚拟化容器以及灵活的编排调度机制，可以为云服务提供快速扩缩容能力，而且极大程度地提高了物理资源的利用率。在这方面， kubernetes技术已经成为了业界的标准
- 微服务架构:还记得前面我们聊到的微服务架构么?没错，它也是云原生的重要基石之一。依托于功能单元解构，使得云服务具备了快速迭代的可能，业务得以迅速发展;统一的通信标准能够帮助越来越多的组件加入到云原生的大家庭，同时也使得各组件之间的交互变的更容易
- DevOps: DevOps 是开发 (Dev) 和运营 (Ops) 的复合词。设计->开发->测试->交付->开发->测试->交付，自动化的流程使得软件的工作流程更高效，将微服务架构的优势发挥的淋漓尽致
- 服务网格:如果说微服务架构的重要进步，是将庞大的单体服务按照业务功能解耦开来，那么，服务网格的重要进步就是将业务逻辑与网络通信和治理解耦开来。业务不再需要关心异构系统中RPC中间件治理能力的不统一，也使得复杂的治理能力的落地成为可能
“云原生蛋糕店”
03. 企业级后端架构的挑战
未完待续。。
04. 后端架构实战
未完待续。。
实战部分
总结
后面太抽象了，笔者没弄懂，等有经验了回来再看看。
