从'0'到微服务框架

微服务

• 理解

  • 背景

    • 从头开发的网上超市！

  • 当时

    • 网站：

      • 用户注册、登录功能
      • 商品展示
      • 下单

    • 总体架构图

      • 

  • 时间(变化)轴

    • 故事
      • 小明和小皮一起创业做网上超市。小明负责程序开发，小皮负责其他事宜。当时互联网还不发达，网上超市还是蓝海。只要功能实现了就能随便赚钱。所以他们的需求很简单，只需要一个网站挂在公网，用户能够在这个网站上浏览商品、购买商品；另外还需一个管理后台，可以管理商品、用户、以及订单数据
    • 随着时代，用户增长，渐渐发生——
    • 

  • 知识点简介

    • 抽象出公共服务

      • 理解
        • 也就是抽象出公用的业务能力，来做成公共服务
      • 图
        • 

    • 烟囱式系统

      • 缺点
        • 数据库成为性能瓶颈，并且有单点故障的风险。
        • 数据管理趋向混乱。即使一开始有良好的模块化设计，随着时间推移，总会有一个服务直接从数据库取另一个服务的数据的现象。
        • 数据库表结构可能被多个服务依赖，牵一发而动全身，很难调整

    • 监控—–发现故障的征兆

      • 实现步骤

        • 微服务架构中组件繁多，各个组件所需要监控的指标不同
        • 比如Redis缓存一般监控占用内存值、网络流量，数据库监控连接数、磁盘空间，业务服务监控并发数、响应延迟、错误率等
        • 因此如果做一个大而全的监控系统来监控各个组件是不大现实的，而且扩展性会很差 so↓
        • 一般的做法是让各个组件提供报告自己当前状态的接口(metrics接口)，这个接口输出的数据格式应该是一致的。然后部署一个指标采集器组件，定时从这些接口获取并保持组件状态，同时提供查询服务。
        • 最后还需要一个UI，从指标采集器查询各项指标，绘制监控界面或者根据阈值发出告警

      • 定位问题——链路跟踪

        • 理解
          • 通过链路跟踪的方式来对用户调用某个服务时查看所调用的全部接口或服务，另外还需要调用日志收集与存储的组件，以展示链路调用的UI组件
            • 这里的UI组件
              • 请查找答案

      • 网关—权限控制，服务治理

        • 背景

          • 拆分成微服务后，出现大量的服务，大量的接口，使得整个调用关系乱糟糟的
          • 经常在开发过程中，写着写着，忽然想不起某个数据应该调用哪个服务。或者写歪了，调用了不该调用的服务，本来一个只读的功能结果修改了数据……

        • 解决调用错误接口服务

          • so,微服务的调用需要一个把关的东西，也就是网关
          • 在调用者和被调用者中间加入一层网关，每次调用都会进入权限校验，同时，网关可以作为一个提供服务接口文档的平台

        • 使用网关的粒度

          • 最粗力度
            • 指整个微服务一个网关，
          • 最细粒度
            • 则是所有调用，不管是微服务内部，调用过着来自外部服务的调用，都要通过网关
          • 折中方案
            • 按照业务领域将微服务分成几个区，区内直接调用，区间通过网关调用
          • 

        • 熔断，服务降级，限流

          • 熔断

            • 理解
              • 当一个服务因为各种原因停止响应时，调用方通常会等待一段时间或者收到了错误返回
              • 如果调用链路必将长，可能会导致请求堆积，整条链路占用大量资源一直在等待下游(也就是基层)的响应，
              • so
              • 当我们多次访问一个服务失败时，我们应该熔断，标记该服务已停止工作
            • 

          • 服务降级

            • 背景
              • 当下游的服务停止工作后，如果该服务并非核心业务，则上有服务应该降级，以保证核心业务不中断
            • 实例
              • 网上超市的下单页面有一个推荐商品凑单的功能，当该模块挂了后，只需要暂时关闭推荐功能即可

          • 限流

            • 当一个服务挂掉后，用户会习惯性的进行重复访问，，这导致一旦服务恢复正常很可能瞬间error

            • 

            • so

              • 服务里需要自我保护–也就是限流，

                • 限流的策略有很多

                  • 当单位时间内请求次数过多，丢弃多余的请求，

                  • 考虑分区限流。仅拒绝来自产生大量请求的服务的请求

                    • 例如商品服务和订单服务都需要访问促销服务
                    • 商品服务由于代码问题发起了大量请求
                    • 促销服务则只限制来自商品服务的请求，来自订单服务的请求则正常响应

• 总结

  • 微服务框架
    • 引入组件以及功能
      • 指标接口、链路跟踪注入、日志引流、服务注册发现、路由规则等组件以及熔断、限流等功能都需要在应用服务上添加一些对接代码
    • 如果让每个应用服务自己实现是非常耗时耗力的
      • so
        • 基于DRY的原则，便有了我们现在如火如荼的微服务框架
        • 将与各个组件对接的代码和另外一些公共代码抽离到框架中，所有的应用服务都统一使用这套框架进行开发
    • 自定义的功能
      • 代码级的链路跟踪
        • 甚至可以将程序调用堆栈信息注入到链路跟踪，实现代码级别的链路跟踪。或者输出线程池、连接池的状态信息，实时监控服务底层状态
    • 缺点
      • 框架更新成本很高
      • 每次框架升级，都需要所有应用服务配合升级
      • 当然，一般会使用兼容方案，留出一段并行时间等待所有应用服务升级。但是如果应用服务非常多时，升级时间可能会非常漫长。并且有一些很稳定几乎不更新的应用服务，其负责人可能会拒绝升级
      • so
        • 因此，使用统一微服务框架需要完善的版本管理方法和开发管理规范