最近在研究istio相关知识，正好做个知识梳理，从小白的角度学习istio，这篇的内容是关于Service Mesh的发展史，服务网格究竟是如何一步步发展起来的。
首先，我们先了解下什么是微服务
微服务（英语：Microservices）是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模组化的方式组合出复杂的大型应用程式，各功能区块使用与语言无关 (Language-Independent/Language agnostic）的API集相互通讯。 --来自维基百科
简单来说，就是将服务拆分为更细粒度的‘微服务’，各个服务之间功能更聚焦，且服务间使用语言无关的API进行通讯，比如RPC。
1、抽象的调用关系下图来表示:
2、实际的情况如下图所示，服务除了要做自己的功能外，还要负责流量控制的一部分‘额外’功能，但服务其实本身不应该关注，所以需要把流量控制这一块摘出去
3、网络层的功能摘出来，通过网络协议来解决，也就是TCP协议，来帮我们做了流量控制的功能
4、第一代微服务，随着技术发展，出现了分布式系统，随后出现了例如负载均衡、服务认证、网络授权等功能，这些也是服务所不关注的。
5、那下一步就是将这些功能抽象到框架，不需要每个服务自己管理。
6、但是框架管理仍然存在问题，引入额外的框架，引入了多余的复杂度、维护成本，排查问题比较困难，于是乎，第一代Service Mesh 出现了。
以Linkerd，Envoy，NginxMesh为代表的代理模式应运而生,通过代理模式，将流量全部接入进来，在Sidecar内部做比如流量限制、负载均衡等操作
7、但是使用后，仍然存在单机维护各自的服务网格，那我们还需要一层抽象，也就是现在的Service Mesh，通过一个控制平面来管理所有的sidecar，代表产品为Istio，关于每个组件的详解我们放到后面去一一讲述。
官方文档:序言 · Istio Handbook - Istio 服务网格进阶实战 by ServiceMesher(服务网格社区)
看完了发展史，个人总结一下几点：
一、为了保证服务的功能单一性，不要让服务关心它自身功能外的其他功能
二、抽象，将一些公共模块抽象出来，通过统一的框架、组件来维护
三、可扩展性、可维护性、出问题易于排查。
后续会逐步更新每个模块的详解。
