学习笔记 | 微服务架构

前言

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

什么是微服务

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

微服务架构的通用特性

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

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

微服务的交互模式

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

微服务的分解和组合模式

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

微服务的容错模式

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

微服务的粒度

合理拆分服务。拆的越细，服务的耦合度越小，内聚性越好，越适合敏捷发布和上线

不要拆的太细，要考虑团队建设、人员的数量和分配，因为每一个微服务都是一个团队在构建与后续的维护，分的太细人员需求量太大。

没有必要把每个接口包装成一个微服务

注意事项

• 永远不要在本地事务中调用远程服务。如果远程服务出现了问题会拖长事务，导致服务器占用太多的数据库连接，让服务器负载迅速攀升，甚至压垮数据库。
• 微服务项目需要实现自动化的持续部署和持续集成的功能。包括：代码管理、自动编译、发布QA、自动化测试、性能测试、准生产部署和测试、生产环境发布等。

参考

• 《分布式服务架构 原理、设计与实战》--第一章
• developerWorks 中文社区