微服务架构的起源

     可以说微服务架构并不是什么技术创新，而是开发过程发展到一定阶段对技术架构的要求，是在实践中不断摸索而来的。

为什么采用微服务架构

单体架构与微服务架构对比

什么时候开始微服务架构

单体、组件化、微服务架构成本趋势

如何决定微服务架构的拆分粒度

微服务架构中的微字，并不代表足够小，应该解释为合适

微服务拆分粒度决策参考表

微服务设计原则

• 垂直划分优先原则

下图简单描述了一个按业务领域垂直划分的微服务架构示例，在业务垂直方向切分服务，通过API Gateway聚合内容。

• 持续演进原则
  应逐步划分、持续演进，避免服务数量的爆炸性增长。
  
• 服务自治、接口隔离原则
  服务通过标准的接口隔离，隐藏内部实现细节
  
• 自动化驱动原则
  

微服务架构实施的先决条件

• 研发环境和流程上的转变
  

• 自动化工具链
  
• 微服务框架
  
• 快速申请资源
  
• 故障发现反馈机制
  
• 研发流程上的转变
  

• 拆分前先做好解耦
•   状态外置

• 无状态（Statelessness）指的是服务内部变量值的存储。有状态的服务伸缩起来非常复杂，可以通过将服务的状态外置到数据库、分布式缓存中，使服务变成无状态
  
• 无状态不代表状态消失，只是把状态转移到分布式缓存和数据库中了
  
• 并不是所有的业务服务都能设计成无状态，例如客户端与服务端的长连接，这种状态很难外置。
  
• 以下三种常见的状态需要和业务服务拆分开来，否则扩展性将受到很大限制。定时任务  本地存储   本地缓存
  

•    去触发器、存储过程

• 解决方案通常是通过外部的业务服务或者定时任务替换触发器及存储过程。
  

•    通过接口隔离

• 如果存在多个系统共享一个数据库，就会导致耦合，影响可用性和扩展性。
  

微服务划分模式

• 基于业务复杂度选择服务划分方法
  当业务复杂度足够高的时候，应该基于领域驱动划分服务，而领域驱动本身足够复杂，很多概念比较抽象，应用范围并不是特别广泛，所以当业务复杂度较低时，可以选择基于数据驱动划分服务。数据驱动更容易理解和上手。也就是说，除非业务复杂度非常高，否则应该优先以数据驱动划分服务。

• 基于数据驱动划分服务
  数据驱动是一个自下而上的架构设计方法，数据驱动强调的是数据结构，也就是通过分析需求，确定整体数据结构，根据表之间的关系划分服务
  
• 基于领域驱动划分服务
  领域驱动是一个自上而下的架构设计方法，通过和领域专家建立统一的语言，不断交流，确定关键业务场景，逐步确定边界上下文。
  
• 从已有单体架构中逐步划分服务
  
• 微服务拆分策略
  

• 比较独立的新业务优先采用微服务架构。
  
• 优先抽象通用服务。
  
• 优先抽象比较容易识别的、边界比较明显的服务。
  
• 优先抽象核心服务。
  
• 优先抽象具有独立属性的服务
  
• 采用绞杀者模式，在遗留系统外围，随着时间的推移，让新的服务逐渐“绞杀”老的系统。
  

• 如何衡量服务划分的合理性
  

• 一个小功能的修改从需求到上线需要多长时间？正常情况下的微服务架构交付周期应该是以天为单位的。
  
• 大多数功能修改是否可以在一个服务内完成？
  
• 是否要频繁修改接口？
  
• 响应时间是否能满足要求？
  
• 是否存在大量的跨服务更新？
  

微服务划分反模式

• 根据代码行数划分服务
  
• 划分粒度越小越好
  
• 一次性划分服务
  
• 服务划分一旦完成，不能改变
  
• 先实施组件化，再实施微服务架构
  

微服务API设计

• 优秀API的设计原则
  

• 简单
  
• 易懂
  
• 一致
  
• 稳定
  
• 安全
  

•  服务间通信——RPC
  

           影响RPC性能的因素

• 序列化
  
• 传输协议
  
• 连接
  
• IO模型
  

• 服务间通信——RESTful
    API如何设计才能满足RESTful的要求呢？
  

• 协议
  
• 域名
  
• 版本
  
• 路径
  
• 方法
  
• 参数
  
• 编码
  

• HTTP协议的进化---HTTP/2
  

• 在HTTP/1.x的协议中，浏览器在同一时间对同一域名下的请求数量是有限制的，这会导致大量并发请求阻塞，这个问题也被称为线端阻塞（head-of-lineblocking）。如表所示。HTTP/1.1对不同浏览器连接数的限制不同，很多互联网公司为了解决这个问题，做了大量优化，包括建立多域名，通过CDN缓存大量静态资源等。

• HTTP/2是基于二进制协议的
  
• HTTP/2的多路复用机制（Multiplexing）
  

• HTTP/2完全兼容HTTP/1.1的语义
  
• HTTP/2引入服务端推送模式，即服务端向客户端发送数据

• HTTP/2和Protobuf的组合——gRPC
  

• HTTP/2支持流（streaming），在批量发送数据的场景下使用流可以显著提升性能——服务端和客户端在接收数据的时候，可以不必等所有的消息全收到后才开始响应，而是在接收到第一条消息的时候就可以及时响应
  
• gRPC默认使用Protobuf进行序列化和反序列化
  
• gRPC默认采用HTTP/2进行传输
  
• gRPC 的流可以分为三类：客户端流式发送、服务器流式返回，以及客户端/服务器同时流式处理，也就是单向流和双向流
  
• HTTP/2相比于基于TCP的通信协议，性能上也有显著的差距。
  

微服务框架

• 微服务框架有很多，综合起来看需要实现如下几个重要的功能。
  

• 需要微服务框架能够设定最大容量，采用洪峰策略，隔离关键服务，控制版本，对服务分级，优雅降级。
  
• 服务治理
  
• 容量规划
  
• 高效通信
  
• 负载均衡
  

• 基于Dubbo框架实现微服务

• 基于Spring Cloud框架实现微服务
  
• 微服务部署策略
  

• 服务独享数据库
  
• 服务独享虚拟机/容器