TIPS之 关于服务治理的个人看法

服务治理之 关于服务治理的个人看法

Posted by 董江 on Monday, November 27, 2023

服务治理之 关于服务治理的个人看法

一、熵增现象

在软件开发维护过程中。软件的生命力总是从最初的理想状态,逐步趋向于复杂混乱无序状态发展,软件将会进入寂静状态(谁也不敢动),再到软件不可维护而被迫下线重构。 这种损坏软件质量的因素的逐步增长,叫做软件的熵增现象

表象引起原因:

  1. 不合理的需求,不合理的实现,放到不合理模块中;
  2. 有外部因素(时间紧,多方妥协结果)等,导致不合理的过程;
  3. 业务指数增长,目前架构不符合当下负荷量;
  4. 未知的未知

软件 熵增现象 不可避免,但对于特定环境、特定场景下, 可遏制熵增加剧。

发展到一定地步的企业和服务,服务治理产品迭代两条腿平行走。

二、 软件 服务治理 本质是啥?

我个人浅薄理解:服务治理 本质在于两个字

  • 的能力:将公共、抽象、可复用能力平台,收拢在一起,形成通用平台/服务,方便应用方聚焦;
  • 的能力:限制在一个团队/组织/企业中,限制对软件语言、软件框架、软件实现方式、软件运维方式等纬度使用,避免不必要的技术炫技小众技术泛滥

PS: 说明几个点

  1. 并非对 研发友好,并不会100%减少工作量,返而在前期会增加工作量;
  2. 服务治理运维、管理、管控、审计、安全、统计等纬度要求,并不能达到短平快的研发实现;
  3. 服务治理 在一定范围里面(一款完整产品-淘宝,一个组织-消费者云等),一定需要100%全部接入(包括历史不同版本、不同环境等)

三、 服务治理: 从 A点B点 实现路径是什么?

服务治理中,不可否认管理手段技术手段都不能少,但需要有先后关系相辅相成的. 原则上,以技术手段为主, 管理手段手段为辅。管理手段在关键节点上,才会发挥作用。

3.1 如何找A点和B点的实现路径

A点:需要『架构师』数据驱动方式,找到痛点,现解决当下问题是什么? B点是最终在这个组织内服务治理是怎样的蓝图;

实现路径: 从 A点B点 实现的每一个Step 以及 需要达到的预期点.

每家公司,每套产品都有差异,但公共部分也不少。 公共部分包括:

  • 统一的session服务单点登入SSO
  • 统一的iam认证验权体系
  • 全局的产品树/服务树(组织->产品->模块->实例->{流量、资源利用率、xx率})
  • 实时运维/运营(旭日图、转化漏斗)

差异化服务:

  • 语言框架 Framework/SDK
  • 基础设施(内部DNS服务、知识库、API管理中心)
  • 基础服务体系(AB灰度、配置中心、注册中心、熔断中心、音视频处理、图床、消息、OCR等)
  • 平台能力服务(订单中心、用户中心、事件/消息中心)

3.2 管理手段技术手段 介入时机

在 整个服务治理过程中,管理手段 使用次数不超过3次.

  • 从0到1的过程,技术手段手段为主,找到第一个种子用户; 确实可以达到双赢目标;
  • 关键节点:推动铺量,可通过管理手段 推动接入;
  • 以此反复;

注意:

  1. 切记 啥也没有,直接上 管理手段; DDDD;
  2. 切记 平凡上管理手段,会对平台失去公信力;

四、具体案例(聚焦与Kubernetes场景)

  1. 遏制应用无止境的使用operator来控制应用 内部Kubernetes使用云平台(web)管理,只能有少数SRE可登入机器中心CLI命令行,研发、QA和运维都使用平台操作.
    1. 磨练内部云平台功能稳定性和兼容性
    1. 数据化统计功能易用性 和 是否合理(点击事件)

在这个基础上,平台开启operator应用商店,类似于operatorhub, 来管理组织内部内源高可用的operator(可能也就是几个到十几个)。 核心:

  • 维护kubernetes版本与operator兼容性版本管理;
  • 维护operatorhub对底层基础设施依赖管理(特殊的os、特殊的kernel版本),来做安装check
  1. 元数据管理 禁止configmapmetaserver 服务使用 禁止configmap配置中心 使用 禁止secret证书中心 使用 禁止etcd服务 直接当 服务注册中心 使用 禁止将 对象的label 当做容器运行时的metaserver使用 禁止将 对象的annotation 当做容器运行时的metaserver使用 遏制将 对象的annotation 当做容器运行时的metaserver使用

Kubernete的资源是用于资源调度和一致性管理,禁止用于服务数据传递

构建全局的配置中心注册发现中心源数据中心分布式锁中心证书管理中心, 方便用户接入;

  1. 高可用 要求服务驱逐时,长/短链接、流量(东西、南北)无损; 建议无状态多实例部署;有状态实例支持sharding;

长/短链接:

  • 长链接:长链接主动connect close. 通过client 链接重新选实例建立,将链接全部驱逐掉;
  • 短链接:确保本次处理结束。优雅关闭链接;

流量: 通过设置 perStop + 实例按Step步进变更/回滚,实现流量无损;

其他

「如果这篇文章对你有用,请随意打赏」

Kubeservice博客

如果这篇文章对你有用,请随意打赏

使用微信扫描二维码完成支付