为什么需要服务治理
服务治理是随着微服务一起出现的。在远古时代的单体服务，所有业务部署在一个进程，共享相同的资源，包括机器、网络等资源。所以业务之间通信或者交互简单。但是微服务中的每个服务都有自己独立的资源，服务之间交互就变得复杂多了。服务独立了，问题也随之而来。怎么知道其他服务在哪（服务发现），能不能提供服务（注册中心或者服务探活），资源如何调度（资源调度）、服务如何通信（流量治理）等等问题如何解决，服务治理应运而生。
如何做服务治理
基础
我们在日常中想要管理或者解决一些人或者事情，需要尽可能地了解对方，才能进行。所以想要服务治理，我们也要了解服务。但是需要了解哪些方面呢？
指标
我们可以通过指标来了解服务状态。指标可以分为两种：基础指标和业务指标。
基础指标
基础指标主要是一些通用的指标。下面是一些常见的基础指标：
• 机器指标（cpu、内存、网络）
• jvm metric
• pod metric
• 基础组件指标（db metric、redis metric等）
业务指标
业务指标是指和业务相关的指标。这些指标反映了业务的状态。比如业务处理延迟、速度等。
资源
我们在管理服务时需要知道服务需要哪些资源，需要多少。这样我们才能给服务分配资源。资源调度的前提是：我们知道还剩多少资源。所以我们需要基础指标。只有基础指标健全，我们才能获得剩余资源的信息，才能进行资源调度。目前资源调度一般都是用k8s来管理。
依赖
服务正常运行需要其依赖的服务正常运行。所以我们需要知道服务的依赖关系，调用链情况。通过调用链我们可以知道依赖关系，业务瓶颈在哪，哪些业务是关键业务，需要扩缩容。
常见的调用链中间：jeager、skywalking、zipkin。在选型时，优先考虑业务入侵小的方案，例如Java 字节码技术。
基础设施
随着服务数量的增加，管理的难度也随之剧增。所以我们需要搭建基础设施来辅助管理。
k8s
k8s 是目前最火的服务编排系统，我们也就在赘述了。
配置中心
配置中心是为服务提供配置的，我们可以通过配置中心对服务进行管理，比如业务使用哪套算法模型，业务出现线程数量等。常见的配置中心有：zookeeper、consul、Nacos、apollo、spring cloud config。
zookeeper和consul 只具有简单的配置中心功能，相当于nosql db。在服务体量不大，服务治理场景简单的时候可以使用。但是对于复杂或者高级的服务治理场景还是捉襟见肘。比如灰度发布。
Nacos、apollo、spring cloud config 提供了配置中心高级功能：配置推送，配置刷新，配置隔离等。有如下场景的时优先从三者中选择：
• 多环境（开发、测试、线上）
• 多租户
• 灰度发布
• 资源隔离
注册中心
注册中心的本质是服务探活。注册中心会对外提供可用服务地址查询。比如gprc 可以使用注册中心查询存活实例，然后做负载均衡。在spring cloud 中的feign的负载均衡也都是基于注册中心。
自动化
服务治理的最终目标就是实现自动化。但是自动化是建立在前面两项之上的，拥有必要的数据我们才能自动化。
流量治理
流量治理有两种主要场景：激增大流量和灰度发布。激增大流量可以通过自动扩缩容解决，我们后面在说。
灰度发布
不同版本配置不同：这个问题需要使用配置中心解决。
不同版本流量不同：service mesh 可以解决这个问题。
自动扩缩容
要实现自动扩缩容，我们就需要知道哪些服务需要扩缩容。我们需要定义一系列指标，用于衡量服务。
负载负载情况：我们可以监控pod cpu 情况；api 调用时长P99情况；api 调用频率情况。
流量情况：api 调用数量；网络情况。
通过各种指标我们可以知道服务状态，从而我们可以指定扩缩容规则。
上面提到的每项技术都能展开讲很久，之后的文章我们在详细聊聊。
