微服务
定义： 使用一套小服务来开发单个应用的方式，每个服务运行在独立的进程里，一般采用轻量级的通讯机制互联，并且它们可以通过自动化的方式部署。
（1）微服务模型框架
优势：
- 解决单体复杂度（耦合）
- 服务可独立开发
- 独立部署
- 独立扩展
劣势：
- 通信机制（分布式）
- 拆分数据库架构（分布式事务）
- 部署（高自动化）
- 测试（需要mock其依赖的服务）
- 跨服务的改动（服务之间的依赖关系）
（2）API网关
定义：API网关是提供系统唯一入口的一台服务器
API网关封装了内部的系统架构并向每个客户端提供裁剪的API，它也可能负责诸如用户验证、监控、负载均衡、缓存、请求改造和管理以及静态内容响应等职责。
为什么需要API网关
一些服务可能使用对web并不友好的协议实现。一个服务可能使用Thrift二进制的RPC而另一个服务可能使用AMQP消息协议。这些协议都不是浏览器和防火墙友好的，最好是在应用内部被使用。防火墙之外呢，应用最好使用HTTP或者WebSocket。
优势
- 可扩展性
- 使用响应式编程模式（可并行处理请求）
- 服务调用（支持不同的通信机制）
- 服务发现（服务端发现、客户端发现）
- 处理局部故障
（三）通信（IPC）
进程间通信（IPC）
服务如何交互
- 一对一还是一对多
- 同步还是异步
| 一对一 | 一对多 |
|---|---|
| 同步 | 请求/响应 |
| 异步 | 通知 |
| 异步 | 请求/异步响应 |
如何为服务定义API？
与客户端开发者（服务消费者）一起review你的设计，先对API定义进行迭代，再去实现这些服务。这样做设计的话将会使你构建更加符合客户需求的服务！
如何处理API进化？
使用旧版本服务API的客户端可以在新版本服务API下正常工作，服务端为客户端缺失的属性提供默认值，客户端自动忽略额外添加的响应属性。
如何处理局部故障？
Netflix给出了一些处理局部故障比较好的方法：
- 网络超时：等待响应时不要一直阻塞，而是使用超时，超时能够保证资源不会一直被占用
- 限制未完成请求的数量：针对一个请求某服务的客户端，需要设置其未处理请求数量的上限，一旦超过限制就不再处理任何请求，这样就做到快速失败。
- 断路器模式：跟踪成功和失败请求的数量，如果比率超过了设置的阀值，打开断路器使得后续请求快速失败。如果大量请求失败，就建议服务为不可以状态并决绝处理新请求，过一段时间之后，客户端可以再次重试，一旦成功，关闭断路器。
- 提供fallback机制：请求失败时提供fallback，比如返回缓存值或者为失败的推荐服务返回默认空集合作为默认值。
Netflix Hystrix是一个实现了这些模式的开源工具包，如果你使用JVM那么一定要考虑使用它！如果你的服务不是运行在JVM中，那也要考虑有等效的实现来处理此类问题。
（四）服务注册/发现
为什么使用服务发现？
一组服务实例可能会因为自动扩展、失败或者升级发生动态变化，因此 你的客户端代码应该使用更加精细的服务发现机制。
有两种主要的服务发现机制：客户端发现 和 服务端发现。
区别在于： 客户端是否保存服务列表信息。
1. 客户端发现
2. 服务端发现
| 客户端模式 | 服务端模式 |
|---|---|
| 只需要周期性获取列表，在调用服务时可以直接调用少了一个RT。但需要在每个客户端维护获取列表的逻辑 | 简单，不需要在客户端维护获取服务列表的逻辑 |
| 可用性高，即使注册中心出现故障也能正常工作 | 可用性由路由器中间件决定，路由中间件故障则所有服务不可用，同时，由于所有调度以及存储都由中间件服务器完成，中间件服务器可能会面临过高的负载 |
| 服务上下线对调用方有影响（会出现短暂调用失败） | 服务上下线调用方无感知 |
为什么使用服务注册？
服务注册表 是服务发现的关键部分，它是一个包含服务实例网络地址的的数据库。
一个服务注册表需要高可用和实时更新，客户端可以缓存从服务注册表获取的网络地址。
（五）Token访问令牌
如何让所有的服务知晓用户这个状态？
方案：
1. 单点登录（SSO）方案
2. 分布式会话方案
3. token客户端令牌方案
token 就像把钥匙，每次获取服务都要有对应的钥匙，并且这个钥匙有时效。
-
4. 客户端令牌与API网关结合