这是我参与「第五届青训营」伴学笔记创作活动的第 10 天，今天接着上一篇笔记对后端开发与迭代中需要经常使用的架构进行初步的学习，并进行一些总结
上一篇文章链接：架构定义学习（一） | 青训营笔记
架构的分类
垂直划分
单体架构
垂直架构
上面两种在上一篇文章中已经把简单的概念写明了，在这进行再次标注只是希望保持文章标题结构完整
水平划分
分布式划分（SOA）
概念： SOA的全称为Service-Oriented Architecture，就是面向服务的架构，它是在垂直架构的基础上将每个项目拆分出多个具备松耦合的服务。一个服务通常以独立的形式存在于操作系统进程中，各个服务之间通过网络调用，这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。
项目拆分时需要考虑的几点因素：
分层： 按照业务逻辑分层，每一层都需要维护简单
分级： 每一层都需要按照业务的重要程度做好分级
隔离： 不同性质、不同重要性的业务需要进行隔离
调用： 各级间的调用要做到单向，不要出现逆向的调用
优点：
- 业务分层后架构更加清晰，并且每个业务模块职责单一，扩展性更强
- 数据隔离，权限回收，数据访问都 通过接口，让系统更加稳定安全
- 服务责任易确定，每个服务可以确定服务责任人，这样更容易保证服务质量和稳定
缺点：
- 服务接口数量不易控制，容易引发接口爆炸，所以服务接口建议以业务场景进行单位划分，并对相近的业务做抽象，防止接口爆炸。
- 版本升级兼容困难
微服务架构
概念： 微服务架构是一种将单个应用程序作为一套小型服务开发的方法，每种应用程序都在其自己的进程中独立运行，并使用轻量级机制进行通信。
优点：
- 每个服务都比较简单，只关注于一个业务功能
- 微服务架构方式是松耦合的，可以提供更高的灵活性
- 每个微服务可由不同团队独立开发，互不影响，加快推出市场的速度
缺点：
- 微服务架构是一个分布式系统，必须构建一个相互通信机制并处理部分故障，处理故障难度高
- 测试复杂度高，微服务在一定程度上也会导致系统变得越来越复杂
