这个是笔者几年前面淘宝某事业部岗位的时候，遇到的一道面试题。
面试官问：都在说微服务需要治理，那你说说什么是服务治理？为什么需要治理？具体又是怎么治理呢？
接下来这篇文章我将采用大白话形式，结合图文，把服务治理这个知识点讲清楚。保证让小白看完也能快速理解这个知识点。
思路
讲解服务治理这个话题，我将从以下几个问题入手即什么是服务治理？为什么需要治理？怎么治理？回答完这几个问题相信你也就了解了这个知识点了。
什么是服务治理
我们先看下百度关于治理的解释：
意思是“整修”或“管理”的意思。那可以肯定的一点是必定是哪个地方出问题了，我们才会需要通过手段去治理它。生活中到处都是案例。比如环境污染很严重，需要治理吧、水污染很严重，所谓的“五水共治”要去治理它，对不对。我们回到微服务治理上来，微服务会出什么问题呢，也要去治理。
单体服务问题
很多项目原来一开始可能都在一个工程下开发，分了下package而已比如product是一个包表示商品服务，order是一个订单服务，大家都在一个工程内开发。
公司发展初期没什么流量，大家各自相安无事，和谐共处。忽然公司融了很多钱，发展了很多业务，流量蹭蹭往上涨，特别是部分模块比如用户中心负载很高，影响了整个应用的稳定性，于是我们想到“拆”，把它独立出来，单独部署。这也是一种“治理”手段。
微服务问题
按照上述节奏演进，用户数一上来，可能不止用户中心需要拆，比如商品、订单也要拆，那么开始出现一个问题，拆出来之后彼此之间怎么通信？我们要做到服务上下线对调用方自动感知，熔断限流需要考虑，还要考虑监控，告警，链路追踪，安全，发布支持灰度、蓝绿等。
服务为什么要治理
具体细分治理项，下面这个截图是我早些时候看到的一篇文章，作者详细介绍了各个微服务治理项，供大家做个参考：
6.我再补充一点像上文说的微服务框架引入其实也会带来了一些列问题；同样面临治理难题。
1）虽然框架本身屏蔽了分布式系统通信的一些通用功能实现细节，但开发者却要花更多精力去掌握和管理复杂的框架本身，在实际应用中，去追踪和解决框架出现的问题也绝非易事；我们希望开发人员更关注业务本身
2）以SpringCloudAlibaba中的RPC框架Dubbo为例，其对于业务逻辑代码都有一定的侵入性，也就是说服务治理相关的代码与业务逻辑有一定的耦合。比如拿我们公司来说：RPC 框架由中间件事业部统一开发与维护，以 SDK 形式提供给集团内的其他事业部使用。由于 SDK 与应用逻辑是耦合在同一个进程中的，当 SDK 向前演进所增加的特性并不是某些业务方所需要的时，这些业务方就没有动力配合中间件事业部去同步升级自己应用中的 SDK 版本，使得 SDK 在整个集团存在多个版本甚至变成长尾而形成包袱。类似的包袱反过来制约了 RPC 框架自身的演进效率。
其他道理也一样比如升级二方包版本，都需要统一推动
- 多语言支持不足
对于稍具规模的团队，尤其是在高速成长的互联网创业公司，多语言的技术栈是常态，跨语言的服务调用也是常态，但目前开源社区上并没有一套统一的、跨语言的微服务技术栈。目前主流的微服务框架SpringCloud、Dubbo都是基于Java所开发，当整个系统同时涉及到多种语言时，这些框架的能力就有些捉襟见肘了。
手段
上述治理项，从框架层面也得到了部分支持，比如springcloudAlibaba套件有注册中心Nacos,限流组件sentinel等。其他中间价比如skywalking等都有对应支持。平台侧k8s支持服务快速扩容缩容等
从微服务过度到服务网格
引入serverMesh主要解决的是微服务框架现存的一些问题：多语言不支持、框架本身需要在应用中各种配置与业务代码藕合过紧，而我们其实追求的是让开发者更加关注业务开发。不要为了所谓的配置这配置那框架浪费太多时间与精力。
serviceMesh解决方案如下
