1.7.1　服务网格诞生的背景

任何一个架构都会有缺点，当微服务数量越来越多时，也逐步暴露出了一些问题。

·微服务的拆分和边界如何定义？应该拆分多少微服务？

·微服务间相互调用时，如何快速找到目标服务提供者？如何保障调用方的身份安全？

·下游微服务不可用时，如何快速熔断，保护当前微服务从而避免雪崩？

·如何通过调整权重和路由快速上下线微服务，治理微服务的负载均衡？

·如何管理复杂的上下游微服务依赖，快速定位出问题的微服务？

工程师除了关注业务功能实现外，还要聚焦微服务治理的控制。上述问题基本就是微服务治理要关注的服务发现、服务鉴权、服务熔断、负载均衡、服务依赖等内容。当然这些功能的实现有很多种方法，我们直接往微服务中增加对应的服务治理功能就好，但这样做往往有一个致命的缺点，就是复用性很差。当只有1个微服务的时候，服务治理的功能放在哪里都无可厚非，但是当我们拥有成百上千，甚至上万个微服务时，我们不能对每个微服务都增加相同的功能模块。更合理的做法是把共用的能力抽象后提取出来，作为一个独立的模块，常用的做法是抽象出通用的SDK（Software Development Kit，软件开发工具包），比如common-hystrix（熔断功能的通用包）。

通过通用能力的抽象，实现了服务治理功能的复用。它与业务功能耦合在同一个进程、同一个代码仓库里，业务开发人员还是会关注Common包的更新和维护，既然通用服务治理能力相对独立，能不能像PaaS或AOP（Aspect Oriented Programming，面向切面编程）一样，把它抽象成独立的一个层次出来，与业务代码解耦，交给专人来维护呢？答案就是服务网格。