SOA Governance

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. 元数据管理 禁止将 configmap 当 metaserver 服务使用 禁止将 configmap 当 配置中心 使用 禁止将 secret 当 证书中心 使用 禁止将 etcd服务 直接当 服务注册中心 使用 禁止将 对象的label 当做容器运行时的metaserver使用 禁止将 对象的annotation 当做容器运行时的metaserver使用 遏制将 对象的annotation 当做容器运行时的metaserver使用

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

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

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

长/短链接:

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

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

其他

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

Kubeservice博客

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

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

CATALOG
    FEATURED TAGS
    agent apiserver application bandwidth-limit cgo cgroupfs ci/cd client-go cloudnative cncf cni community container container-network-interface containerd controller coredns crd custom-controller deployment docker docker-build docker-image drop ebpf ecology egress etcd gitee github gitlab golang governance hpa http2 image ingress iptables jobs kata kata-runtime kernel kind kubelet kubenetes kubernetes library linux-os logging loki metrics monitor namespace network network-troubleshooting node nodeport pingmesh pod prestop prometheus proxyless pvc rollingupdate schedule scheduler serverless sidecar sigtrem systemd throttling timeout tools traceroute