这是我参与「第三届青训营 -后端场」笔记创作活动的第四篇笔记

微服务架构

• 服务（service）
  • 一组具有相同逻辑的运行实体。
• 实例（instance）
  • 一个服务中，每个运行实体即为一个实例。
• 实例与进程的关系
  • 实例与进程之间没有必然对应关系，可以一个
  • 实例可以对应一个或多个进程（反之不常见）。
• 集群（cluster）
  • 通常指服务内部的逻辑划分，包含多个实例。
• 常见的实例承载形式
  • 进程、VM、k8s pod ……
• 有状态 /无状态服务
  • 服务的实例是否存储了可持久化的数据（例如磁盘文件）。

---

能够称之为微服务，则需要满足云原生的要求，这样即使上云也是很简单的一个步骤。作为分布式系统中的一个组件，必须满足：

具备熔断机制

某个服务可能依赖另一个服务，当被依赖的服务无法访问时，则外部请求直接返回。当被依赖的服务恢复时，服务必须能够自动更新熔断状态，外部请求可以直接访问被依赖服务。

能够独立构建、测试和部署

微服务开发通常由某个微型团队负责，由于业务边界比较清晰，业务逻辑也非常固定，所以可以按照自己的节奏进行迭代和升级。

支持健康检查 微服务启动后，可能是被依赖的服务，那么被其他服务调用时，熔断器可能会通过健康检查结果设置自身容器状态，所以必须具备健康检查相关的接口。

支持重试机制

服务在访问被依赖服务时，很可能由于网络延迟等原因获取不到结果，但是重试机制可以确保，在一定的时间内获取到结果。所以，分布式系统访问的结果为：成功、失败和超时。

配置注入

微服务实例在运行时，可能会根据负载进行弹性伸缩，所以，依赖必须在运行时注入，而不能在编译打包时固定，更加不能依赖基础设施信息，比如IP地址等。

Kubernetes

Kubernetes 已经成为容器编排的事实标准，提供了很多特性来支持云原生应用的部署。比如 Service、ReplicaSet、Deployment、ConfigMap&Secret 等等，其强大的社区已经逐渐影响到了其他容器编排引擎，比如 Mesos、Swarm 等等。基于 Kubernetes 打造企业轻量级 Paas 平台已经成为了趋势。

核心服务治理功能

• 服务发布
  • 让一个服务升级运行新的代码的过程。
• 流量治理
  • 在微服务架构下，我们可以基于地区，集群，实力，请求等维度，对端到端流量的路由路径进行精确控制。
• 负载均衡
  • 负载均衡负责分配请求在每个下游实例上的分布。
• 稳定性治理
  • 限流
  • 熔断
  • 过载保护
  • 降级

重试

• 意义
  • 降低错误率
  • 降低长尾延时
  • 容忍暂时性错误
  • 避开下游故障实例
• 难点
  • 幂等性
  • 重试风暴
  • 超时设置
• 策略
  • 限制重试比例
  • 防止链路重试
  • Hedged requests

总结

微服务并不是凭空而来的，更不只是规模小。了解微服务的诞生过程，理解了背后的动机就能够准确把握微服务拆分的粒度，以及在实践微服务过程中要把握的要点。