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
大概意思：可独立部署服务，服务会越来越细
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的探索之路还在继续
很多公司借鉴了Proxy模式，推出了Sidecar的产品，比如像Netflix的Prana，蚂蚁金服的SofaMesh 2014年 Netflix发布的Prana 2015年 唯品会发布local proxy 2016年 Twitter的基础设施工程师发布了第一款Service Mesh项目：Linkerd (所以下面介绍Linkerd)
