单片应用
好处
- 方便测试，容易部署
所带来的问题 - 应用膨胀，过于巨大
- 使得后续的开发人员难以完全理解整个应用。难以修bug或者添加新的功能
- 减缓开发进度，启动应用的时间变长
- 单机应用启动的是一个进程
- 难以使用新的框架和语言
微服务
微服务的先决条件
- 快速配置，能够几个小时内配置并启动全新的设备 （使用云服务和容器技术）
- 基础运维和监控
- 快速部署(CI/CD)
微服务的缺点
- 会带来复杂性，需要选择消息传递或者RPC进程通信
- 分区数据库体系
- 测试上的困难
- 跨服务更改
API网关的特性
- 优点：封装了应用程序的内部结构，客户端不必调用特定的服务，只需要和网关进行对话
- 缺点：必须开发、部署和管理高可用性的组件
微服务带来的复杂性
- 服务依赖管理：服务间直接调用，依赖混乱
- 服务调用统计：调用记录无处可寻，调用统计和分析无从谈起
- 服务接口规范：环境与接口规范缺失，维护困难
- 服务安全管理：安全靠白名各自为战
- 服务治理能力：大量代码实现路由，分级，熔断，降级
- 服务接口测试：拆分过程中接口行为不一致
- 服务灰度发布：上线功能借助大量if else
- 服务压力测试：对于峰值压力无历史数据
- 服务调用链分析：当服务请求缓慢，难以定位问题
- 测试环境治理：测试环境多，难管理
熔断
起因：
一是 增加了整个链路的请求时间
二是 下游系统本身就出现了问题，不断的请求又把系统问题加重了，恢复困难。
作用
熔断模式可以防止应用程序不断地尝试 可能超时和失败的服务，能达到应用程序执行而不必等待下游服务修正错误服务。
熔断器模式最牛的是能让应用程序自我诊断下游系统的错误是否已经修正，如果没有，不放量去请求，如果请求成功了，慢慢的增加请求，再次尝试调用。
强调服务之间的调用实现自我恢复状态
降级
降级就是为了解决资源不足和访问量增加的矛盾.
在有限的资源情况下，为了能抗住大量的请求，就需要对系统做出一些牺牲，有点“弃卒保帅”的意思。放弃一些功能，保证整个系统能平稳运行
牺牲
强强一致性变成最终一致性：
干掉一些次要功能：停止访问不重要的功能，从而释放出更多的资源
注意点：对业务进行仔细的梳理和分析
什么指标下能进行降级：吞吐量、响应时间、失败次数等达到一个阈值才进行降级处理
如何降级：降级最简单的就是在业务代码中配置一个开关或者做成配置中心模式，直接在配置中心上更改配置，推送到相应的服务。
维护系统内部的评级服务或者业务的维度考虑 干掉一些不用的，保护正常的
限流
实现：漏斗，令牌桶
注意点：限流不要成为瓶颈，最好又开关可以直接介入
强调保护系统的作用
