微服务
定义: 使用一套小服务来开发单个应用的方式,每个服务运行在独立的进程里,一般采用轻量级的通讯机制互联,并且它们可以通过自动化的方式部署。
(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网关结合