本文转载自微信公众号「爱笑的架构师 」，作者雷架 。转载本文请联系爱笑的架构师 公众号。
原始时代
1969年11月，为了便于高校间共享资源，美国国防部高级研究计划管理局建立一个名为阿帕网络ARPAnet，起初只有四个节点。
阿帕网起源
一年后阿帕网的节点数量增至15个，此后平均每隔二十天就有一台大型计算机接入。
随着网络在世界范围不断扩大，不同国家不同地区各自形成了一个网络，操着不同方言彼此间互不相通，诸侯割据格局已经形成。
隔离的阿帕网
这个时候机器与机器之间通信是靠彼此约定的方式进行。
计算机靠方言通信
机器需要自行处理网络通信过程中遇到的丢包、乱序、重试等问题。
青铜时代
为了解决各国家各地区网络不能互通的问题，1973年两位年轻的小伙子开始发力了，致力于研究一种通讯方法，能够解决不同机器型号的计算机互相通信，简单说就是用普通话替代方言，这就是大家熟知的“TCP/IP”协议。
鲍勃·卡恩(左)与温顿·瑟夫(右)
随着 TCP/IP 协议逐渐普及后，一张大的 Internet 网络由此形成。
Internet
这个时候机器与机器之间通信的问题已经解决，TCP/IP 可以保证信息可靠性传输，我们只用关系业务逻辑即可。
依赖 TCP/IP协议实现机器间传输
黄金时代
在 TCP/IP 协议刚兴起时，计算机上的应用还很贫乏，机器与机器之间通信一般用来简单的数据传输。
随着 WEB 互联网技术兴起，基于 TCP/IP 协议出现了很多应用层协议，国内出现了一批优秀的互联网公司如腾讯、新浪、搜狐、淘宝等。
当时访问量并不大，采用单体架构基本就可以满足。
单体应用之间调用
服务的数量不多，每个服务都有一个唯一的IP 地址，服务与服务之间交互通过 IP寻址。
铂金时代
网民数量越来越多，单个实例扛不住日益增长的访问量。通常会在一个机器上部署多个实例组成集群，服务1访问服务2不再是之前的点到点了，现在变成了点到多点，中间会加一个负载均衡解决流量均衡问题。
单体应用集群之间调用
钻石时代
随着互联网业务访问量井喷，通过横向扩展服务实例的方法也开始遇到瓶颈了，单个服务越来越大，代码模块耦合严重，修改一行代码可能影响整个系统。
问题来了，解决方案也随着而来，“微服务”横空出世了。将一个业务服务按功能模块切分为多个微服务，比如将 Service1 切分为 Micro Service1，Micro Service2，Micro Service3。
在单体服务中Micro Service1调用Micro Service2可能就是一个模块调用另外一个模块，调用一个公开的函数就能搞定，拆为微服务之后就变成了两个微服务直接的调用，这种调用是要通过网络通信实现。
微服务间调用
星耀时代
随着业务扩张，对系统的高可用要求越来越高，一些重点微服务如订单、账单等可能会部署成百上千个实例，运维人员的负担也在逐渐加大，如果机器挂了要手动删除，如果遇到重大活动如双十一可能要扩展几千个实例，运维人员需要手工添加，人工干预越多出错的概率越大。
第一代微服务技术应运而生。
代理内嵌
每个微服务内嵌一个代理用来处理服务注册和发现的逻辑，国内以阿里的 Dubbo，微博的 Motan 为代表。这类框架不足的地方很明显：微服务与代理耦合、不支持多语言。
王者时代
针对第一代微服务框架的不足，大家在纷纷探索下一代微服务框架。
在每一个主机上单独部署一个代理进程，多个微服务共用一个代理进程，实现服务发现和负载均衡。
代理进程
这种模式通常被大家称为“sideCar”，也就是“边车模式”。
什么叫“边车”，在早期有一种摩托车，驾驶位置旁边挂着一个拖斗，对比微服务旁边挂一个代理进程，所以形象地称为“边车模式”。
摩托车拖斗
在新一代的 ServiceMesh 架构中，服务消费者和服务提供者都会部署SideCar。
SideCar 模式
服务与服务之间是靠 sideCar 连接起来，sideCar 用来处理与业务无关的注册、发现、熔断、限流等治理能力。
略去业务服务和其他无关的东西，将所有的 sideCar 连接起来可以得到下面这张图：
服务网格
是不是长得像网格，服务网格(service mesh)由此得名。
维基百科是这样定义服务网格：
服务网格是一个基础设施层，用于处理服务间通信。云原生应用有着复杂的服务拓扑，服务网格保证请求在这些拓扑中可靠地穿梭。在实际应用当中，服务网格通常是由一系列轻量级的网络代理组成的，它们与应用程序部署在一起，但对应用程序透明。
总结
ServiceMesh(服务网格)的特点：
- 场景：用于微服务间的服务通信和服务治理
- 方案：边车模式
- 定位：基础设施层
服务网格是一种比较新的架构风格，大家在技术选型时不要盲目追新，适合当前业务发展的技术才是最好的技术。大家学会了吗?
