引文
开始看文章之前不妨先思考几个问题：服务治理是什么，什么样子的服务需要治理，为什么需要治理服务，应该怎样治理服务，治理服务的哪些方面，不治理的话服务会怎样？这些问题基本就是服务治理的关键思想了，搞懂这些问题，就相当于是掌握了服务治理的基本概念。
服务演变过程
我们在解决上述问题之前，先来看一下服务架构的发展过程。
单体服务
对于单体服务来说，应用结构一般比较简单，一般不需要特别的服务治理手段，但随着服务承载的业务越来越庞大，服务内部逻辑变得复杂起来，扩展性也越来越差，这时最好的治理办法就是将其进行拆分，除此之外的治理手段都是徒劳，反而会让应用变得越来越臃肿。
集群服务
单体架构在流量较少时能够满足基本需求，随着业务的发展，产品流量越来越多，一秒钟的服务宕机都可能造成很大的损失，基于此，将由单体架构延伸到集群架构。集群中每台服务器都提供相同的服务，使用负载均衡器来实现每台服务器的负载分配，这其实也能算是一种治理，在分配请求时需要选择出最适合的健康的服务器，将请求发送过去，并且要时刻的检查集群中节点的健康状态，及时将故障节点从健康服务列表中剔除。
分布式服务
当单体应用变得臃肿之后，整个团队维护同一套代码，所有的业务都集中在一个应用中，服务的健壮性会随着业务的发展变得越来越脆弱，当维护一个服务变得困难的时候，就需要考虑将此服务拆分成若干个小而美的服务了，即微服务化，将单一服务架构向微服务架构演进。
当服务演进到微服务架构之后，会出现新的问题，比如之前所有的业务逻辑都在一个进程中执行，日志查看、问题排查等都很方便，也不存在进程之间的通信，更不存在依赖服务状态的监控等情况。那么既然拆分成微服务之后会遇到这么多问题，为什么还要拆呢？其实大部分由单体服务拆分成微服务的初衷都是想分而治之，也就是单一职责的服务更方便优化和维护。
-
服务定义：服务拆分要根据一定的规则进行，定义拆分后每个服务的业务范围和边界，不能为了拆而拆，微服务的提出者Matin Fowler在首提微服务的时候是以业务为拆分基准，后续发展过程中，越来越多的条件都可以作为拆分的理由了，比如业务、流量大小等。
-
服务注册与发现：微服务架构体系中，必定会出现服务之间的调用依赖，这就需要调用方知道目标服务的地址，从而发起请求。如果将服务端的地址预先告知调用方，其实也是可行的，缺陷就是当服务越来越多时，服务URL的配置管理变得非常困难，所以在这个过程中我们需要借助一个中介来提供一个接口让我们可以随时获取健康的服务列表，所以服务注册中心应运而生(Zookeeper、Etcd、Consul、Eureka、Dubbo等)，它的理念是由服务端将可提供的服务注册到服务中心，并由服务中心来维护每个服务节点的健康状态，客户端从服务中心获取健康的服务列表用于发送请求。
-
接口调用链监控：微服务架构体系中以服务多著称，服务都具有单一职责，服务之间需要互相调用才能完成一次请求的处理。在单体应用架构中，调用链都是在同一个进程中，只要通过线程ID或者MDC即可查询到请求的整个调用链，定位很轻松；但是在分布式架构中，想要跟踪一次请求的整个调用链就比较麻烦了，一般需要通过第三方组件来完成，比如Twitter的Zipkin。
-
应用服务监控：SpringBootAdmin提供了一套开箱即用的监控工具箱，可以看到监控的每个微服务实例的运行情况，具体操作稍后再嗷嗷
-
负载均衡：在服务拆分设计过程中，每一个服务都需要保证是高可用的，也就是每一个微服务又都是高可用的。
-
服务降级熔断：单体服务拆分后导致服务变多了，调用链出故障的概率就更大了，我们在保证了服务的高可用的同时，仍然需要保证接口的可用性，如果接口出现故障，要能够将故障快速转移并响应调用端，否则可能会造成大量的请求积压，进而拖垮整个系统。断路器和服务降级为接口的快速故障转移提供了保障。
-
服务调用：在分布式架构中，服务之间可以通过http、rpc等方式互相调用，比如Feign是一种http方式的声明式调用，在SpringCloud中有广泛的使用。
-
服务安全：服务自身需要保证接口、数据和服务的安全性，不能出现被随意调用的现象。
-
服务版本：服务在升级过程中，需要考虑到对老版本的兼容性，避免造成因升级带来的系统故障。
回看
简单的描述了一下服务架构的演进路线，我们来看看前面说的几个问题：
-
服务治理是什么
服务治理是通过一系列手段来更好的管理服务，确保系统能够顺利、安全、稳定的运行。
-
什么样子的服务需要治理
任何服务都需要治理
-
为什么需要治理服务
- 为了提升系统的稳定性
- 保证服务的可用性
-
应该怎样治理服务
- 建立授权的责任链
- 评估服务的有效性
- 服务监控告警
- 故障转移
-
治理服务的哪些方面
- 服务定义
- 服务注册与发现
- 接口调用链
- 应用服务监控
- 负载均衡
- 服务降级熔断
- 服务调用协议
- 服务安全
- 服务版本
-
不治理的话服务会怎样
场景一：周末你正在逛街，然后老板在群里艾特你，说系统服务器宕机了、机房停电了、光缆被施工队挖断了，系统没办法使用了。这个时候你是不是需要立刻赶到公司去搬砖，直到系统恢复正常。
场景二：正在与周公下棋，然后一阵滴滴声，发现某个服务节点的故障告警邮件快撑爆收件箱了，并且还不断的有流量打到这个服务节点，如果没有治理的话，你要立刻起床打开电脑尽快恢复这个节点。有了服务治理，你打开服务管理器，一键熔断降级，搞定。然后可以起床吃个早饭再来修复了(呸~当然立刻修复，哪还有心思吃早饭)。