微服务介绍

    个人认认为重量级框架对于公司层面是有一定好处的，其优势主要在于以下几点：

    • 能够有统一完整的标准
      • 每个人写的代码都基本一致，谁都可以维护
      • 线上出了问题，不用问repo在哪，配置在哪、日志在哪
      • 框架中的基础组件可以更好的适应基础建设，省去无谓的适配
    • 统一mono repo
      • 对业务方屏蔽具体底层实现，业务方只需要对框架升级版本即可
      • 节约人力成本、方便ci

    理解了框架的优点后，我们再来看下公司级别框架的示意图。 公司级别的框架一般都是建立在公司的基础规范之上，与基础建设进行紧密结合，从而降低公司的运维成本、提升研发效率、提升服务线上运行的稳定性。

    接下来我们就来讲下微服务相关的一些概念，来提升我们的微服务能力

    如果微服务没有标准和规范，一旦达到上百个微服务，每个微服务都进行编写编译脚本、配置路径、监控模版，这是对运维人力的一个极大浪费。因此微服务最为核心的就是标准。

    我们会使用系统将编译文件makefile、dockerfile存储在远端。如果本地没有编译文件，则默认选择远端编译规范。如果本地有编译文件，那么则选用本地编译文件。 我们会将许多元数据编译到二进制包里，作为应用的元数据。

    • 应用名称
    • 编译时间
    • 编译机器
    • 框架版本
    • 应用版本

    编译好的二进制包，我们可以通过./main —version，排查该二进制的编译情况 image

    2.2 配置规范

    我们会将所有的开源组件做一次wrapper，这样的好处有几方面

    • 统一所有组件的配置方式、调用方式
    • 兜底默认配置
    • 统一配置形式

    2.2.1 统一组件配置方式

    我们通过配置去驱动组件，业务方无需关注组件的初始化，就能够直接使用组件。同时统一调用组件的API方式，能够降低业务方的心智负担。例如调用一个redis和mysql的配置和API如下所示。

    可以看到调用方式都是Load一个配置key，在通过Build方法，创建一个组件。所有组件都可以这样，依葫芦画瓢的使用。

    2.2.2 兜底默认配置

    会先使用一个default config，作为兜底参数，然后在根据用户配置项进行解析，如果用户配置了，那么就是使用用户配置。如果用户没有配置，就使用框架默认配置。例如以上redis组件，用户直接使用该组件，可能会漏配dial、read、write参数，在一些情况下可能触发问题。

    2.2.3 统一配置形式

    • 每个组件的配置名称统一，例如都叫password，不会存在有的是pwd，有的是password
    • 调试配置
    • 日志配置
    • 链路配置
    • 监控配置
    • 降级配置

    注册需要约定好，注册的方式，例如有三种：

    • 自行注册
    • k8s的dns注册
    • k8s的api注册

    以上内容后面可以单独来讲，这一块的注册主要是服务调用的注册。我们这边还要讨论另外的注册信息。一个是元数据、一个是监控注册、一个是双向注册。

    2.3.1 元数据

    这个分为两个

    • key为/prefix/poviders/appname

    这个key是provider启动的时候，将编译元数据，还有运行时获取的region、zone、env、启动时间等数据写入value

    这个key是后台将流控、sentinel等治理信息写入value

    2.3.2 监控注册

    • 一种是自行注册，然后通过agent，写入prometheus的conf文件，做到监控的服务发现
    • 一种是通过打标签，通过prometheus的operator做服务发现

    2.3.3 双向注册

    通常我们只有服务注册，而忽略了客户端注册。客户端注册的有dubbo，好处可以做分组、权限控制、治理。

    2.4 日志规范

    日志我们要区分为四类

    • 系统日志systemd
    • K8S日志
    • 框架日志
    • 业务日志

    系统日志、k8s日志、框架日志都是可以是结构化日志，确定索引类型，统一采集，关闭全文索引。

    2.4.1 日志性能

    2.4.2 日志查bug

    结合配置中心，zap的动态日志能力，可以让研发养成好习惯多打debug日志，线上关闭，出现问题动态开启。

    2.5.1 监控维度

    • 黄金指标
      • 流量
      • 延迟
      • 错误
      • 饱和度
    • 维度
      • 系统分层
        • 应用维度
        • 机器维度
        • 资源维度
      • 应用维度
        • 应用实例
        • 单个应用大盘
        • 多个应用大盘
        • top榜

    2.5.2 框架监控五个维度

    • 应用基本信息
    • 服务端监控：http、grpc
    • 客户端监控：http、grpc、mysql、redis、mongo、kafka
    • 缓存监控：命中率

    2.5.3 统一字段用法

    如果对prometheus不做规范，业务方自行使用，可能会造成prometheus的性能急剧下降。举个例子，当a业务方使用http的路径叫url，b业务方使用http的路径叫method，那么同一种类型的业务，两个字段产生的数据就会成为笛卡积，影响性能。

    为了进一步优化日志和监控字段，我们这里是有一个实现细节，例如之前我们把redis 的命令叫 command，mysql 语句叫 sql，http 请求叫 url，这样就导致我们排查以上问题的时候，写的查询语句特别复杂，很难收敛做分析和发现问题，所以我们后来将一些共性的指标统一成一个名字，将刚才所说的一些问题在日志和监控分成不同的模块，但取名都叫 method，将查询正交化，方便我们用一条语句就可以把所有错误都找出来。

    收敛后的日志可以做大盘

    监控可以根据应用进行筛选 image.png

    2.5.4 统一错误码

    业务方错误码根据aid*10000 框架错误码10000以下

    2.6 Governor

    后面在聊

    现实排查故障如下所示 以上问题，研发和运维不想疲于应付问题，那么就需要从底层自上而下设计，通过框架的错误收敛找到根因、结合监控、报警、混沌工程、全链路压测手段形成sop手册，作为解决方案。如下所示。

    image.png