这是我参与「第五届青训营 」伴学笔记创作活动的第 3 天
架构概念
定义：架构，又称软件架构：
- 是有关软件整体结构与组件的抽象描述
- 用于指导软件系统各个方面的设计
重要性
- 架构没设计好，软件容易崩，用户体验上不去。最终要么重构，要么放弃
- 架构设计好了，软件的稳定性上去了，用户体验高了，口碑一点点就打造出来了
- 良好的架构基础，也为软件的未来发展提供了更多的可能。为用户赋能，实现自身价值
单机架构
All in one，所有的东西都在一个进程里，部署在一个机器上。
优点：
- 简单
缺点：
-
运维需要停服，用户体验较差
-
承载能力有限。[服务端经典的C10k问题(译) - 知乎 (zhihu.com)]
单体架构
**单体架构：**在单机架构的基础上，将进程部署到多个机器上。进行分布式部署
优点：
- 具备水平扩容能力
- 运维不需要停服
缺点：
- 后端进程职责太多，越来越臃肿
- 进程中一个很小的模块出现问题，都可能导致整个进程崩溃
垂直用用架构：按应用进行垂直切分部署在不同机器
即使垂直应用架构，每个实例的职责还是多，没有根本解决单体架构的问题，每个实例还需要进行相关的一系列操作，比如都需要进行搬水，打蛋等常用操作。
为了提高效率，因此要让每个实例只做某一个任务，比如单独一个师傅进行搬水操作，分工明确
SOA架构
SOA 架构中，将进程按照不同的功能单元进行抽象，拆分为『服务』。有了服务之后，SOA 定义了服务之间的通信标准，保证各个服务之间通讯的一致性。
优点：
- 各服务的职责更清晰
- 运维粒度减小到服务，爆炸半径可控
缺点：
- ESB (企业服务总线) 往往需要一整套解决方案
ESB的工作就是提供和调用集成系统的服务。使用了ESB，在大多情况下，每个系统和ESB之间，只需要定义一个访问方法，一个接口。
这里发现，所有的服务都需要有相同的沟通技巧，也就是大家都需要有相同的通信标准
微服务架构
微服务架构就是SOA架构的去中心化演进。在 SOA 架构中，ESB 起到了至关重要的作用。但从架构拓扑来看，它更像是一个集中式的模块。微服务则是对其进行分布式改变，微服务服务变得更多，另加零散，同时增加了运维成本
优点：
- 兼具 SOA 解决的问题
- 服务间的通信更敏捷、灵活
缺点：
- 运维成本
拆分成服务之后就需要解决一些问题：
- 数据一致性问题：每台机器的数据同步
- 高可用问题：某个服务挂了，能否继续提供服务
- 治理：某个服务挂了，如何容灾
- 判断是否服务拆分的过于细致而导致激增的运营成本
架构演变思路
- 垂直切分(一台机器变多台机器)
- 水平切分(按服务进行切分)
如何做架构设计
- 先从需求出发。要满足什么样的需求？预期规模有多大？
- 做足够的业界调研。业界对于类似的需求是怎么做的？有无成熟的方案可以借鉴？直接拿来用有什么问题？
- 技术选型。内部/社区都有那些解决方案可以参考
- 异常情况。任何时候，都不能做『输入合法』的假设。容灾能力一定要有
