目录
1 单机小型机时代
第一个计算机网络诞生于1969年，也就是美军的阿帕网，阿帕网能够实现与其它计算机进行联机操作，但是早期仅仅是为了军事目的而服务
2000年初，中国的网民大约890万，很多人都不知道互联网为何物，因此大多数服务业务单一且简单，采用典型的单机+数据库模式，所有的功能都写在一个应用里并进行集中部署
论坛业务、聊天室业务、邮箱业务全部都耦合在一台小型机上面，所有的业务数据也都存储在一台数据库上。
2 垂直拆分
随着应用的日益复杂与多样化，开发者对系统的容灾，伸缩以及业务响应能力有了更高的要求，如果小型机和数据库中任何一个出现故障，整个系统都会崩溃，若某个板块的功能需要更新，那么整个系统都需要重新发布，显然，对于业务迅速发展的万物互联网时代是不允许的。
如何保障可用性的同时快速响应业务的变化，需要将系统进行拆分，将上面的应用拆分出多个子应用。
优点：应用跟应用解耦，系统容错提高了，也解决了独立应用发布的问题
应用垂直拆分解决了应用发布的问题，但是随着用户数量的增加，单机的计算能力依旧是杯水车薪
3 集群化负载均衡架构
用户量越来越大，就意味着需要更多的小型机，但是小型机价格昂贵，操作维护成本高。
此时更优的选择是采用多台PC机部署同一个应用的方案，但是此时就需要对这些应用做负载均衡，因为客户端不知道请求会落到哪一个后端PC应用上的。
负载均衡可以分为硬件层面和软件层面。
硬件层面：F5
软件负载层面：LVS、Nginx、Haproxy
负载均衡的思想：对外暴露一个统一的接口，根据用户的请求进行对应规则转发，同时负载均衡还可以做限流等等
有了负载均衡之后，后端的应用可以根据流量的大小进行动态扩容，我们称为"水平扩展"
阿里巴巴在2008提出去“IOE”，也就是IBM小型机、Oracle数据库，EMC存储，全部改成集群化负载均衡架构，在2013年支付宝最后一台IBM小型机下线
优点：应用跟应用解耦，系统容错提高了，也解决了独立应用发布的问题，同时可以水平扩展来提供应用的并发量
4 服务化改造架构
虽然系统经过了垂直拆分，但是拆分之后发现在论坛和聊天室中有重复的功能，比如，用户注册、发邮件等等，一旦项目大了，集群部署多了，这些重复的功能无疑会造成资源浪费，所以会把重复功能抽取出来，名字叫"XX服务（Service）"
为了解决服务跟服务如何相互调用，需要一个程序之间的通信协议，所以就有了远程过程调用（RPC），作用就是让服务之间的程序调用变得像本地调用一样的简单
优点：在前面的架构之上解决了业务重用的问题
5 服务治理
随着业务的增大，基础服务越来越多，调用网的关系由最初的几个增加到几十上百，造成了调用链路错综复杂,需要对服务进行治理。
服务治理要求：
1、当我们服务节点数几十上百的时候，需要对服务有动态的感知，引入了注册中心
2、当服务链路调用很长的时候如何实现链路的监控
3、单个服务的异常，如何能避免整条链路的异常（雪崩），需要考虑熔断、降级、限流
4、服务高可用：负载均衡
典型框架比如有：Dubbo,默认采用的是Zookeeper作为注册中心。
6 微服务时代
分布式微服务时代
微服务是在2012年提出的概念，微服务的希望的重点是一个服务只负责一个独立的功能。
拆分原则，任何一个需求不会因为发布或者维护而影响到不相关的服务，一切可以做到独立部署运维。
比如传统的“用户中心”服务，对于微服务来说，需要根据业务再次拆分，可能需要拆分成“买家服务”、“卖家服务”、“商家服务”等。
典型代表：Spring Cloud，相对于传统分布式架构，SpringCloud使用的是HTTP作为RPC远程调用，配合上注册中心Eureka和API网关Zuul，可以做到细分内部服务的同时又可以对外暴露统一的接口，让外部对系统内部架构无感，此外Spring Cloud的config组件还可以把配置统一管理。
马丁大师对微服务的定义：https://martinfowler.com/articles/microservices.html
微服务真正定义的时间是在2014年
The term "Microservice Architecture" has sprung up over the last few years to describe a particular way of designing software applications as suites of independently deployable services. While there is no precise definition of this architectural style, there are certain common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data.大概意思：可独立部署服务，服务会越来越细
spring cloud地址：https://spring.io/projects/spring-cloud
7 服务网格新时期 （service mesh）
7.1 背景
早期
我们最开始用Spring+SpringMVC+Mybatis写业务代码微服务时代
微服务时代有了Spring Cloud就完美了吗？不妨想一想会有哪些问题?
（1）最初是为了业务而写代码，比如登录功能、支付功能等，到后面会发现要解决网络通信的问题，虽然有 Spring Cloud里面的组件帮我们解决了，但是细想一下它是怎么解决的？在业务代码里面加上spring cloud maven依赖，加上spring cloud组件注解，写配置，打成jar的时候还必须要把非业务的代码也要融合在一起，称为“侵入式框架”；
（2）微服务中的服务支持不同语言开发，也需要维护不同语言和非业务代码的成本；
（3）业务代码开发者应该把更多的精力投入到业务熟悉度上，而不应该是非业务上，Spring Cloud虽然能解决微服务领域的很多问题，但是学习成本还是较大的；
（4）互联网公司产品的版本升级是非常频繁的，为了维护各个版本的兼容性、权限、流量等，因为Spring
Cloud是“代码侵入式的框架”，这时候版本的升级就注定要让非业务代码一起，一旦出现问题，再加上多语言之间的调用，工程师会非常痛苦；
（5）其实我们到目前为止应该感觉到了，服务拆分的越细，只是感觉上轻量级解耦了，但是维护成本却越高了，那么怎么 办呢？
我们不是说spring cloud不好，只是为了引出service mesh, 目前spring cloud微服务还是比较主流的， 我们指出spring cloud的不好也只是为了突出service mesh的优点
问题解决思路
本质上是要解决服务之间通信的问题，不应该将非业务的代码融合到业务代码中
也就是从客户端发出的请求，要能够顺利到达对应的服务，这中间的网络通信的过程要和业务代码尽量无关
服务通信无非就是服务发现、负载均衡、版本控制等等
- 在很早之前的单体架构中，其实通信问题也是需要写在业务代码中的，那时候怎么解决的呢？
解决方案：把网络通信，流量转发等问题放到了计算机网络模型中的TCP/UDP层，也就是非业务功能代码下沉，把这些网络的问题下沉到计算机网络模型当中，也就是网络七层模型 网络七层模型：应用层、表示层、会话层、传输层、网络层、数据链路层、物理层
思考：
我们是否也可以把每个服务配置一个代理，所有通信的问题都交给这个代理去做，就好比大家熟悉的nginx,haproxy其实它们做反向代理把请求转发给其他服务器,也就为 Service Mesh的诞生和功能实现提供了一个解决思路
7.2 SideCar
它降低了与微服务架构相关的复杂性，并且提供了负载平衡、服务发现、流量管理、电路中断、遥测、故障注入等功能特性。
Sidecar模式是一种将应用功能从应用本身剥离出来作为单独进程的方式。该模式允许我们向应用无侵入添加多种功能，避免了为满足第三方组件需求而向应用添加额外的配置代码。
很多公司借鉴了Proxy模式，推出了Sidecar的产品，比如像Netflix的Prana，蚂蚁金服的SofaMesh
服务业务代码与Sidecar绑定在一起，每个服务都配置了一个Sidecar代理，每个服务所有的流量都经过sidecar,sidecar帮我们屏蔽了通信的细节，我的业务开发人员只需要关注业务就行了，而通信的事情交给sidecar处理总结：可以理解成是代理，控制了服务的流量的进出，sidecar是为了通用基础设施而设计，可以做到与公司框架技术无侵入性
SideCar的探索之路还在继续
很多公司借鉴了Proxy模式，推出了Sidecar的产品，比如像Netflix的Prana，蚂蚁金服的SofaMesh 2014年 Netflix发布的Prana 2015年 唯品会发布local proxy 2016年 Twitter的基础设施工程师发布了第一款Service Mesh项目：Linkerd (所以下面介绍Linkerd)
7.3 Linkerd
2016年1月，离开Twitter的基础设施工程师打造的一个服务网格项目,第一个Service Mesh项目由此诞生，解决通用性。
Linkerd很好地结合了Kubernetes所提供的功能，以此为基础，在每个Kubernetes Node上都部署运行一个Linkerd实例，用代理的方式将加入Mesh的Pod通信转接给Linkerd，这样Linkerd就能在通信链路中完成对通信的控制和监控。
Linkerd设计思想
Linderd的思想跟sidecar很类似，目标也是屏蔽网络通信细节
Linkerd除了完成对Service Mesh的命名，以及Service Mesh各主要功能的落地，还有以下重要创举：
- 无须侵入工作负载的代码，直接进行通信监视和管理；
- 提供了统一的配置方式，用于管理服务之间的通信和边缘通信；
- 除了支持Kubernetes，还支持多种底层平台。
总结：
- 跟我们前面sidecar很类似，以前的调用方式都是服务来调用服务，在Linkerd思想要求所有的流量都走sidecar，Linkerd帮业务人员屏蔽了通信细节，通信不需要侵入到业务代码内部了，这样业务开发者就专注于业务开发的本身
- Linkerd在面世之后，迅速获得用户的关注，并在多个用户的生产环境上成功部署、运行。2017年，Linkerd加入CNCF，随后宣布完成对千亿次生产环境请求的处理，紧接着发布了1.0版本，并且具备一定数量的商业用户，一时间风光无限，一直持续到Istio横空出世。
问题: 在早期的时候又要部署服务，又要部署sidecar，对于运维人员来说比较困难的，所以没有得到很好的发展，其实主要的 问题是Linkerd只是实现了数据层面的问题，但没有对其进行很好的管理。
数据层面:通过sidecar解决了数据处理的问题
打开github:搜索linkerd，是由scala语言编写的
7.4 istio
由Google、IBM和Lyft共同发起的开源项目
打开github:搜索istio，是由go语言编写的什么是istio?
地址：https://istio.io/docs/concepts/what-is-istio/#why-use-istioIstio makes it easy to create a network of deployed services with load balancing, service-to-service authentication, monitoring, and more, with few or no code changes in service code. You add Istio support to services by deploying a special sidecar proxy throughout your environment that intercepts all network communication between microservices, then configure and manage Istio using its control plane functionality 翻译： 通过Istio，可以轻松创建带有负载平衡，服务到服务的身份验证，监视等功能的已部署服务网络，使得服务中的代码更改很少或没有更改。 通过在整个环境中部署一个特殊的sidecar代理来拦截微服务之间的所有网络通信，然后使用其控制平面功能配置和管理，可以为服务添加Istio支持。注意这句话：
使得服务中的代码更改很少或没有更改这句描述非常重要，如果我们用的是spring cloud通信功能，是不是要加依赖、加注解、改配置
什么是控制平面？
控制平面就是来管理数据平面，也就是管理sideCar
所以istio既有数据平面也有控制平面
istio能干什么?
Automatic load balancing for HTTP, gRPC, WebSocket, and TCP traffic. Fine-grained control of traffic behavior with rich routing rules, retries, failovers, and fault injection. A pluggable policy layer and configuration API supporting access controls, rate limits and quotas. Automatic metrics, logs, and traces for all traffic within a cluster, including cluster ingress and egress. Secure service-to-service communication in a cluster with strong identity-based authentication and authorization. 翻译： 1.HTTP、gRPC、WebSocket和TCP流量的自动负载平衡。 2.路由、重试、故障转移和故障注入对流量行为进行细粒度控制。 3.支持访问控制、速率限制、配置API。 4.集群内所有流量的自动衡量、日志和跟踪，包括集群入口和出口。 5.使用基于身份验证和授权来保护集群中服务跟服务之间的通信。**总结：**很明显Istio不仅拥有“数据平面（Data Plane）”，而且还拥有“控制平面（Control Plane），也就是拥有了数据 接管与集中控制能力。
7.5 什么是服务网格
服务网格：指的是微服务网络应用之间的交互，随着规模和复杂性增加，服务跟服务调用错综复杂
如下图所示
如果每一个格子都是一个sidecar数据平面，然后sidecar进行彼此通信，那么servicemech就是来管理每个格子的控制平面,这就是服务网格，从架构层面看起来跟网格很像
特点：
基础设施：服务网格是一种处理服务之间通信的基础设施层。
支撑云原生：服务网格尤其适用于在云原生场景下帮助应用程序在复杂的服务间可靠地传递请求。
网络代理：在实际使用中，服务网格一般是通过一组轻量级网络代理来执行治理逻辑的。
对应用透明：轻量网络代理与应用程序部署在一起，但应用感知不到代理的存在，还是使用原来的方式工作。
7.6 什么是Service Mesh
istio官网 也对什么是service mesh给出了定义
地址：https://istio.io/docs/concepts/what-is-istio/#what-is-a-service-meshIstio addresses the challenges developers and operators face as monolithic applications transition towards a distributed microservice architecture. To see how, it helps to take a more detailed look at Istio’s service mesh. 翻译： 解决开发与运维部署分布式微服务面临的问题The term service mesh is used to describe the network of microservices that make up such applications and the interactions between them. As a service mesh grows in size and complexity, it can become harder to understand and manage. Its requirements can include discovery, load balancing, failure recovery, metrics, and monitoring. A service mesh also often has more complex operational requirements, like A/B testing, canary rollouts, rate limiting, access control, and end-to-end authentication. 翻译： 也是解决微服务之间服务跟服务之间通信的问题，可以包括服务发现、负载平衡、故障恢复、度量和监视，服务网格通常还具有更复杂的操作需求，如A/B测试、速率限制、访问控制和端到端身份验证
7.7 CNCF云原生组织发展和介绍
云原生发展历史时间轴
- 微服务
马丁大师在2014年定义了微服务
- Kubernetes
从2014年6月由Google宣布开源，到2015年7月发布1.0这个正式版本并进入CNCF基金会，再到2018年3月从CNCF基金会正式毕业，迅速成为容器编排领域的标准，是开源历史上发展最快的项目之一
- Linkerd
Scala语言编写，运行在JVM中，Service Mesh名词的创造者
2016年01月15号，0.0.7发布
2017年01月23号，加入CNCF组织
2017年04月25号，1.0版本发布
- Envoy
envoy是一个开源的服务代理，为云原生设计的程序，由C++语言编程[Lyft]
2016年09月13号，1.0发布
2017年09月14号，加入CNCF组织
- Istio
Google、IBM、Lyft发布0.1版本
Istio是开源的微服务管理、保护和监控框架。Istio为希腊语，意思是”起航“。
CNCF介绍
CNCF 是一个开源软件基金会，致力于使云原生计算具有普遍性和可持续性。 云原生计算使用开源软件技术栈将应用程序部署为微服务，将每个部分打包到自己的容器中，并动态编排这些容器以优化资源利用率。 云原生技术使软件开发人员能够更快地构建出色的产品。
CNCF解决了什么问题
统一基础平台：kubernetes
如果我们需要日志监控：Prometheus
需要代理：Envoy
需要分布式链路跟踪：Jaeger
…
地址：https://www.cncf.io/介绍几个常用的已经毕业的云原生项目
- Kubernetes
Kubernetes 是世界上最受欢迎的容器编排平台也是第一个 CNCF 项目。 Kubernetes 帮助用户构建、扩展和管理应用程序及其动态生命周期。
- Prometheus
Prometheus 为云原生应用程序提供实时监控、警报包括强大的查询和可视化能力，并与许多流行的开源数据导入、导出工具集成。
- Jaeger
Jaeger 是由 Uber 开发的分布式追踪系统，用于监控其大型微服务环境。 Jaeger 被设计为具有高度可扩展性和可用性，它具有现代 UI，旨在与云原生系统（如 OpenTracing、Kubernetes 和 Prometheus）集成。
- Containerd
Containerd 是由 Docker 开发并基于 Docker Engine 运行时的行业标准容器运行时组件。 作为容器生态系统的选择，Containerd 通过提供运行时，可以将 Docker 和 OCI 容器镜像作为新平台或产品的一部分进行管理。
- Envoy
Envoy 是最初在 Lyft 创建的 Service Mesh（服务网格），现在用于Google、Apple、Netflix等公司内部。 Envoy 是用 C++ 编写的，旨在最大限度地减少内存和 CPU 占用空间，同时提供诸如负载均衡、网络深度可观察性、微服务环境中的跟踪和数据库活动等功能。
- Fluentd
Fluentd 是一个统一的日志记录工具，可收集来自任何数据源（包括数据库、应用程序服务器、最终用户设备）的数据，并与众多警报、分析和存储工具配合使用。 Fluentd 通过提供一个统一的层来帮助用户更好地了解他们的环境中发生的事情，以便收集、过滤日志数据并将其路由到许多流行的源和目的地。孵化中的项目，
- Open Tracing
OpenTracing：为不同的平台，供应中立的API，使开发人员可以轻松地应用分布式跟踪。
- GRPC
gRPC 是一个高性能、开源和通用的 RPC 框架,语言中立，支持多种语言。
- CNI
CNI 就是这样一个标准，它旨在为容器平台提供网络的标准化。不同的容器平台能够通过相同的接口调用不同的网络组件。
- Helm
Helm 是 Kubernetes 的包管理器。包管理器类似于我们在Centos中使用的yum一样，能快速查找、下载和安装软件包。
- Etcd
一个高可用的分布式键值(key-value)数据库。etcd内部采用raft协议作为一致性算法，etcd基于Go语言实现。一般用的最多的就是作为一个注册中心来使用
7.8 国内兴起的服务网格
前面提到，在Service Mesh这个概念得到具体定义之前，实际上已经有很多厂商开始了微服务新的尝试，这一动作势必引发对微服务治理的强劲需求。在Service Mesh概念普及之后，有的厂商意识到自身产品也具备Service Mesh的特点，也有厂商受其启发，将自有的服务治理平台进行完善和改造，推出自己的Service Mesh产品。例如，蚂蚁金服、腾讯和华为都推出自己的网格产品，华为的产品甚至已被投入公有云进行商业应用。
- 蚂蚁金服 sofa Mesh
代理架构
前身是SOFA RPC ，2018年07月正式开源
- 腾讯 Tencent Service Mesh
代理架构
- 华为 CSE Mesher
代理架构
总结:基本上都借鉴了Sidecar、Envoy和Istio等设计思想