学习笔记|学习笔记 | 微服务架构学习笔记|微服务架构

前言本文是对微服务架构知识点的梳理，主要是对《分布式服务架构》一书第一章的阅读笔记整理，旨在从整体上把握微服务架构设计，帮助自己在整体架构上规避与解决问题。
什么是微服务

微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。

微服务架构的通用特性

通过服务实现应用的组件化
产品而非项目模式：微服务架构倡导一个团队应该如开发产品般负责一个“微服务”完整的生命周期，倡导“谁开发，谁运营”的开发运维一体化方法。
“去中心化”治理：微服务架构鼓励使用合适的工具完成各自的任务，不必局限于编程语言、框架等。更倾向于使用其他开发者已经验证过的技术来解决问题。
“去中心化”数据管理：倾向于每个微服务使用独立的数据库
故障处理设计：保证每个微服务的容错机制足够强大才能避免集成时的各种问题，比如日志机制、架构及相关指标的实时监控。

微服务架构与SOA
两者都是架构风格范畴，但其关注领域与涉及范围不同。SOA更关注企业规模范围，微服务架构则更关注应用规模范围。
微服务的交互模式

读者容错模式
- 服务提供者和消费者之间对接口改变的容错
- 推荐使用宽松的校验策略。消费者需要对拿到的消息进行容错性处理，即使拿到的消息发生了变化也不应该直接挂掉，而是提取自己需要的信息并忽略不需要或者未知的部分。
消费者驱动契约模式
- 服务契约分为：提供者契约、消费者契约及消费者驱动的契约
- 提供者契约：以提供者为中心，提供者提供了什么功能和消息格式，各消费者无条件遵守这些约定
去数据共享模式
- 微服务架构，一定不要共享缓存和数据库等资源，也不要使用总线模式，服务之间的通信和交互只能依赖定义良好的接口，一般使用RESTful API或者透明的RPC调用框架

微服务的分解和组合模式

服务代理模式
- 在调用者与被调用者之间设置一个代理，来对被调用者输出的数据做加工处理
服务聚合模式
- 场景：聚合服务按一定的顺序调用依赖的多个微服务，对依赖的微服务返回的数据进行组合、加工和转换，最后以一定的形式返回给使用方。
服务串联模式（同步调用）
服务分支模式（服务代理模式、服务聚合模式和服务串联模式相结合的产物）
服务异步消息模式
服务共享数据模式

微服务的容错模式

舱壁隔离模式
- 微服务容器分组
  - 案例：社交平台将名人的自媒体流量全部路由到服务的核心池子中，而降普通用户的流量路由到另外一个服务池子中，有效的隔离了普通用户和重要用户的负载。
- 线程池隔离
熔断模式
- 类似于电闸，超电流之后会自动跳闸。当服务中有大量的请求超时，可以启动熔断机制，快速失败，防止负载过大压垮服务器。
限流模式（针对服务的突然上量，使用限流机制控制访问的并发量）
- 计数器（通过原子变量计算单位时间内的访问次数，如果超出某个阈值，则拒绝后续的请求，等到下一个时间单位再重新计数）
- 令牌筒（通过一个线程在单位时间内生产固定数量的令牌，然后将令牌放入队列，每次请求调用需要从桶中拿取一个令牌，拿到令牌后才有资格执行请求调用，否则只能等待拿到令牌再执行，或者直接丢弃）
- 信号量
失效转移模式
- 主要解决被拒绝的请求，方案如下
  - 快速失败，直接通知使用方调用失败，由调用方自己处理
  - 如果有备份服务，切换到备份服务
  - 失败的服务有可能是某台机器有问题，而不是所有机器有问题，例如OOM问题，在这种情况下适合使用failover策略，采用重试的方法来解决，但是这种方法要求服务提供者的服务实现了幂等性。

微服务的粒度合理拆分服务。拆的越细，服务的耦合度越小，内聚性越好，越适合敏捷发布和上线
【学习笔记|学习笔记 | 微服务架构】不要拆的太细，要考虑团队建设、人员的数量和分配，因为每一个微服务都是一个团队在构建与后续的维护，分的太细人员需求量太大。
没有必要把每个接口包装成一个微服务
注意事项