这是我参与「第五届青训营」伴学笔记创作活动的第 9 天
本次课程主要讲微服务的架构和原理
单体架构 VS 微服务架构
软件架构具备两个特点：
- 合理调配生产关系与生产力，让具备不同专业知识与技术栈的的人士都参与到软件系统开发中来， 高效地协同工作;
- 能让各个软件元素有清晰的定义与职责，并有一套良好、高效的交互机制.
单体架构
应用开发采用单体架构，所有的代码在一个代码仓库中管理，最后打包成一个部署包，运行在一个进程上。典型的有三层应用架构与六边形应用架构两种。
单体架有以下的好处:
- 应用开发简单，基本所有的代码都在一个仓库中管理;
- 非常方便进行大规模的更改;
- 容易测试，只需要写几个端对端的测试;
- 部署简单明了，横向扩展非常容易.
单体架构的弊端
- 复杂度不断提升，模块之间的耦合度越来越高，维护成本很高;
- 更新迭代周期变长，从代码提交到实际部署的周期会拉长，甚至有时都无法交付;
- 难以扩展与迭代演进，使用过时的技术栈或组件一直无法升级.
微服务架构
微服务架构其实可以理解为”模块化设计"的扩展延伸，只是这些"功能模块"以单独的部署包的方式运行在各自的进程中. 每个服务之间都是相互独立的，并且有自己的私有数据库，两者之间仅能通过API的方式进行通信。
微服务架构好处:
- 从代码管理来看，每个服务较小，大部分由于十几个接口或服务方法组成，非常容易维护;
- 从运维管理来看，每个服务都可以独立部署，非常易于扩展;
- 从团队管理来看，可以更好地划分职责范围;
- 从软件开发总体来看，可以使软件系统可持续性交付部署.
微服务架构弊端:
- 服务的拆分和定义有一定的难度;
- 增加了系统的复杂度，使开发、测试、部署都变得更加困难;
- 在部署多个服务的功能时需要在协调开发团队.
微服务架构组成
服务拆分
- 根据业务能力分解
- 根据子域分解
通信方式
- 通信风格: 使用哪一种的进程间通信机制;
- 服务发现: 客户端如何获得具体实例的真实IP地址;
- 可靠性: 在服务不可用的情况下，如何确保服务之间的可靠通信;
- 事务性消息: 如何将消息发送、事件发布、更新业务数据的数据库事务集成;
- 外部API: 应用客户端如何与服务通信.
数据一致性模式，可观测性，部署相关模式，等等
总结
本次课程讲述的主要是微服务的定义以及应用场景，原理十分重要，希望这些笔记能够有所帮助。
