这是我参与「第五届青训营」伴学笔记创作活动的第 17 天
一、本堂课重点内容
- 架构的定义
- 单机
- 单体
- SOA
二、详细知识点介绍
什么是架构
架构，又称软件架构。
软件框架（Software framework）通常指的是为了实现某个业界标准或完成特定基本任务的软件组件规范，也指为了实现某个软件组件规范时，提供规范所要求之基础功能的软件产品。
理解架构---面包房demo
背景：兰师傅开店做蛋糕，在保证质量的前提下要尽可能多的产量。
可以把蛋糕店理解为软件系统，同样都是对外提供服务。
round1---小店开张
兰师傅一人搞定，边卖边做。人流量不多，尚可。如下图：
上图所示为 单机
单机就是把所有功能都实现在一个进程，并且部署在一台机器上。
- 优点：简单
- 问题：运维需要停服（兰师傅休息时就不能提供服务）
round2---增加人手，店面升级
背景：人流量增多，店里雇佣了一些师傅来增加人手。并且雇佣了一个经理，来管理和分配客人，哪里人少了就往哪里引人（负载均衡）。
这就是单体框架。采用分布式部署（每一个师傅都能提供完整的服务）。
- 优点：水平扩容方便；运维无需停服。
- 缺点：职责太多，效率不高；爆炸半径大
升级管理方法：分工产生效率。如下：
以上就是垂直应用架构 将不同职责的应用分开，提高效率同时也可以缩小爆炸半径。
round3---做大做强，再创辉煌
蛋糕店成了网红店，人更多了。需要进行更细致的分工来提升整体的效率。
这就是SOA（Service-Oriented Architecture）
- 将应用的不同功能单元抽象为服务
- 定义服务之间的通信标准
还是延续之前的方式，继续颗粒化。但是增加了一个通信！！！
这里的通信会有很大隐患，只要是通信出现错误，后面的步骤就会接连出错。这里应该参考大公司的部门设计，将各个职位的职责明晰，减少通信，就能减少通信时出现的错误。
蛋糕店成为品牌企业，需要进一步分工和明确职能，避免沟通时出现问题。
微服务架构，SOA去中心化的演进。
职能进一步细分，且职责固定，功能单一。减少了出错的机会。
问题：
- 数据一致性
- 高可用：服务之间的沟通
- 治理
- 解耦和过微
四、课后个人总结
架构可以理解成建筑的设计理念，具有很强的指示性。
架构的整体进化思想和工业的进化思想是一样的：分工产生效能。减小每个应用的颗粒度，极致的封装，将功能单一化。这样提高效率的同时，又增加了整体的稳定性（如果单应用出现bug，还有其他同样功能的应用可以使用）。
当出现一个中心点时，那么整体的容错性就会大幅降低。在设计的时候需要特别注意。
在解耦过程中的两种切法：
- 垂直切分：功能拆分，让每一个单元都有自己的功能。
- 水平切分：过程拆分，将功能实现的过程拆成步骤。
