这是我参与「第五届青训营」笔记创作活动的第12天。
单体架构 VS 微服务架构
- 软件架构：构建应用系统软件元素、元素之间的关系以及属性。分解软件元素以及关系。
重要点： 1.合理调配生产关系与生产力， 高效地协同工作; 2.各个软件元素有清晰的定义与职责，并有一套良好、高效的交互机制.
单体应用架构
所有的代码在一个代码仓库中管理，最后打包成一个部署包，运行在一个进程上。
在项目初期，带来效率提升有以下的好处:
- 应用开发简单
- 非常方便大规模更改;
- 容易测试 4.部署简单明了，横向扩展非常容易.
这时单体架构的弊端逐渐突显：
- 复杂度不断提升，模块耦合度高，维护成本很高;
- 更新迭代周期变长，从代码提交到实际部署的周期会拉长，甚至有时都无法交付;
- 难以扩展与迭代演进
微服务架构
模块化设计的扩展延伸，"功能模块"以单独的部署包的方式运行在各自的进程中。这样每个服务之间都是相互独立的，并且有自己的私有数据库，两者之间仅能通过API的方式进行通信。
以下好处:
- 代码管理服务较小，非常容易维护;
- 运维管理来看，服务独立部署易于扩展;
- 团队管理来看划分职责范围;
- 软件开发总体来看软件系统可持续性交付部署.
微服务架构弊端:
- 服务的拆分和定义的难度;
- 增加了系统的复杂度，使开发、测试、部署都变得更加困难;
- 部署多个服务的功能协调开发团队.
3.微服务架构定义与组成 微服务架构分为应用相关、应用基础相关、基础设施相关三大层。
应用相关模式: 服务拆分、数据库的架构、维护数据一致性问题、测试相关; 应用基础设施相关模式: 边界问题、安全性、事务性消息、通信风格、可靠性、可监测性; 基础设施相关模式: 应用/服务的部署、服务发现等.
服务拆分： 根据业务能力分解 根据子域分解
通信方式： 有以下几种通信模式: 通信风格: 使用哪一种的进程间通信机制; 服务发现: 客户端如何获得具体实例的真实IP地址; 可靠性: 在服务不可用的情况下，如何确保服务之间的可靠通信; 事务性消息: 如何将消息发送、事件发布、更新业务数据的数据库事务集成; 外部API: 应用客户端如何与服务通信.
数据一致性模式
可观测性 在微服务架构下对，一个请求往往会经过多个服务实例的跳转，如高延时等问题就需要以下的模式来设计出一套可监测的服务:
健康检查API 日志聚合 分布式链路跟踪 应用指标 审计日志
部署相关模式 部署一个单体应用是一个比较直观的操作，部署基于微服务的应用程序就要复杂得多，通常应有数十甚至上百个服务组成。需要一个高度自动化部署的基础设施管理需求任务、代码变更， 服务器资源环境于一身的部署平台。
安全相关 用户身份、权限验证的工作通常由网关完成的，常见的解决方式是Outh2协议的访问令牌模式，由网关将访问令牌传递到服务，验证令牌并获取用户有关的信息。
测试相关 拆分的指导原则
单一职责任(SRP):微服务架构中每个微服务都应该是尽可能小的，内聚的，独立完成一个业务的闭环支撑。 闭包原则(CPP):包中的所有类应该是对同类的变化的一个集合，如果对包做出修改，需要更新的类都应该在这个包内
拆分单体应用服务的难点
- 网络延迟; 进程间的通信导致可用性降低，微服务集群所在的网络的流量会增大，哪怕是在局域网内也会因为网络抖动或链路热点而导致可用性降低; 在服务之间保持数据一致，获取一致的数据视图，不同数据库实例的事务较难实现.
5.进程间的通信 通信的方式
一对一: 每个客户端请求由一个服务实例处理; 一对多: 每个客户端请求由多个服务实例处理; 同步模式: 客户端请求需要服务端实时响应，客户端等待响应时间可能会阻塞; 异步模式: 客户端请求不会阻塞进程，服务端的响应可以是非实时的;
异步消息模式的通信 使用消息机制时，服务之间的通信采用异步交换消息的方式完成。发送方中的业逻辑调用发送接口，该接口封装底层通信机制，发送端由信息发送适配器类实现，该消息发送适配器类通过消息通道向接收器发送消息。调用接收器中的消息处理程序适配器类来处理消息。它调用接收方业务逻辑实现的接收端接口。任意数量的发送方都可以向消息通道发送消息，同样，任意数量的接收方都可以从消息通道中接收消息。
