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

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

一、熵增现象

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

表象引起原因：

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. 磨练内部云平台功能稳定性和兼容性
• 2. 数据化统计功能易用性 和 是否合理（点击事件）

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

• 维护kubernetes版本与operator兼容性版本管理；
• 维护operatorhub对底层基础设施依赖管理（特殊的os、特殊的kernel版本），来做安装check

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

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

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

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

长/短链接:

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

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

其他

• SOA governance
• 系统设计之降低复杂性