架构师-第四阶段：微服务架构

1、为什么要实施微服务架构？

• 痛点
  • 代码到处拷贝、导致代码冗余
  • 底层复杂性扩散，例如每个业务都需要加入缓存层
  • 公共库耦合，user.jar 更新会导致业务线的问题
  • SQL 质量无法保障
  • 不易扩展，数据库耦合
• 一个服务层就能解决以上痛点
• 服务化的好处
  • 复用性，消除代码拷贝
  • 专注性，防止复杂性扩散
  • 解耦合，消除公共库的耦合
  • 高质量，SQL 稳定性有保障
  • 易扩展，消除数据库耦合
  • 一个极大的好处是：高效率、业务调用方，代码写得更爽了，业务研发效率提升了！

      User = UserService::getUserById(uid);
    

    

2、微服务粒度，是不是越细越好？

• 统一服务层
• 一个子业务一个服务
• 一个数据库对应一个服务
• 一个接口一个服务（需要语言特性，例如 go 语言）
• 互联网公司，最佳实践：以子业务作为微服务拆分粒度（用户服务、订单服务、支付服务…）

3、高可用，一次搞定

• 方法论：集群化（冗余）、故障自动转移
• 端 到 反向代理 的高可用
• 反向代理 到 站点应用 的高可用
• 站点应用 到 微服务 的高可用，连接池是基础组件
• 微服务 到 缓存 的高可用，redis 可以在中间加一层代理，例如 onecache
• 微服务 到 读库 的高可用
• 微服务 到 写库 的高可用

4、高性能，一次搞定

• 高并发相关指标
  • 相应时间
  • 吞吐量
  • 每秒查询率 QPS
  • 并发用户数
• 方法论
  • 垂直扩展 Scale up，资源有瓶颈
    • 增强单机硬件性能（提升 cpu 内存 磁盘 ssd）
    • 提升单机架构性能（增加 cache 异步增加吞吐量 无锁数据结构减少响应时间）
  • 水平扩展 Scale out，理论上可以做到性能无限
    • 分层微服务架构
      • 反向代理水平扩展
      • 站点应用水平扩展
      • 微服务的水平扩展
      • 数据层的水平扩展（缓存、数据库）
        • 存储量的扩展，无限容量
        • 处理能力的扩展，无限读性能，无限写性能
        • 数据层水平扩展：范围水平切分、哈希水平切分

5、负载均衡，一次搞定

• 反向代理层的负载均衡，DNS轮询
• 站点层的负载均衡，是通过反向代理去实现的
• 微服务处的负载均衡，是通过连接池去实现的
• 数据层的负载均衡，通过 hash水平切分
• 异构服务器的负载均衡，通过动态权重（成功加小分，失败减大分），并能实现过载保护

6、连接池，微服务的关键（上）

• 核心
  • init 初始化，创建多个连接
  • getConnection 拿出一个连接
  • freeConnection 放回一个连接

7、连接池，微服务的关键（下）

• 连接池的位置：在调用方内部