架构演变之路

常见概念:

分布式系统就是想要引入更多的硬件资源来解决当前的问题

1)应用/系统:一个应用就是一个或者是一组服务器程序

2)模块或者是组件:针对于一个组或者是一个模块继续进行拆分

一个应用，里面有很多个功能，每一个独立的功能就可以称之为是一个模块或者是组件

3)分布式:引入多个主机或者是多个服务器来进行相互协同配合来完成一系列的工作

4)集群:被部署于多台服务器上的、为了实现特定目标的一个/组特定的组件，整个整体被
称为集群，比如多个 MySQL 工作在不同服务器上，共同提供数据库服务目标，可以
被称为一组数据库集群；

5)分布式 vs 集群，通常不用太严格区分两者的细微概念，细究的话，分布式强调的
是物理形态，即工作在不同服务器上并且通过网络通信配合完成任务，真的部署了多台主机

而集群更在意逻辑形态，即是否为了完成特定服务目标，集群是一个主机部署了多个服务器程序，从硬件角度来看还是在一台主机上面；

6)中间件:和业务无关的服务，是功能更通用的服务，数据库，缓存，消息队列，业务相关:和实际搜索引擎开发的代码，业务无关:缓存，数据库等和业务无关的应用程序

7)可用性:系统可用时间/总时间

8)响应时间:衡量服务器的性能，处理一次请求需要消耗多长时间，和服务器具体所做的业务是相关的，越小越好，和具体的服务器要做的业务是相关的；

9)吞吐量/并发:衡量系统的处理请求的一种能力，衡量系统性能的一种方式并发能够处理多少请求，比如说1s能处理多少请求；

1)所谓的分布式的系统，就是想办法引入更多的硬件资源

2)主从节点是一种比较典型的结构，是拥有多个服务器节点，其中一个是主节点，另外的都是从节点，从节点的数据要从主节点这里面同步过来

一)单机架构:

一)定义:应用服务和数据库服务器共用一台服务器，所有的服务被部署到一台服务器上面

只有一个服务器这个服务器负责完成所有的工作，应用服务器程序+数据库服务器

蓝色的就是我们写的JAVA代码用户服务负责用户的登录和注册，商品服务用于商品的购买和交易，交易模块用于用户的下单和购买，在数据库服务里面创建了用户表，商品表和交易表

二)出现原因:出现在互联网的早期，用户访问量比较小，单服务器机器足够满足需求；

三)架构的工作原理:以电子商城为例，可以看到通过应用服务(划分出了多个模块)和数据库在单个服务器上面协作完成业务的运行；

四)单机架构的优点: 

4.1)部署简单

4.2)成本低

五)单机架构的缺点: 

5.1)用户请求量变大，会存在着严重的性能瓶颈

5.2)数据库服务和其它应用相互竞争资源

现在的计算机硬件，发展速度非常快，哪怕现在只有一台主机，那么这一台主机的性能都是比较高的，可以支持非常高的并发以及非常大的数据存储

如果业务进一步增长，用户量和数据量都水涨船高，一台主机难以应付的时候，就需要引入更多的主机，引入更多的硬件资源，一台主机的硬件资源是有上限的，硬件资源包括以下几种，CPU资源，内存资源，硬盘资源，网络资源；

每当服务器收到一个请求都是需要消耗上述的一部分资源的，如果在同一时刻，处理的请求多了，此时就有可能会导致某一个硬件资源不够用了，无论是哪一方的资源不够用了，都会导致最终的服务器处理请求的时间变长，甚至于处理出错；

1)开源:增加内存条，加硬盘，提升网络带宽，增加更多的硬件资源，但是一台主机上面的能够增加的硬件资源是有限的，主要还是取决于主板的扩展能力，所以一台主机扩展到极限了，但是还不够，所以就只能扩展到多台主机了，不是说新买来的机器买来就可以解决问题了，也是需要在软件上做出相应的调整和适配一但引入了多台主机，就称之为是分布式系统

2)节流:在软件层面上针对于程序进行优化，现在我们自己写的代码是存在问题的，比如说用到的数据结构不合适消耗CPU资源更多，网络协议设计的不合适，占用网络带宽比较多，存储结构不合理内存分配不合理导致内存占用过多，此时就需要通过性能测试的方式，找到是哪一个环节出现了问题

但是引入分布式，这是万不得以，系统的复杂程度会大大提高，出现bug的频率也会变高

二)应用数据分离架构是最简单的分布式的架构

一)定义:应用服务和数据库服务使用不同的的服务器，这个时候的应用服务和数据库服务不是在一台主机上进行交互的，而是需要通过网络来进行交互

注意:当用户访问到应用服务器的时候，首先由DNS服务器将用户输入的域名转化成IP地址，这个时候必须是应用服务器的IP地址而不能是数据库服务的IP地址，否则会产生安全问题

 二)出现原因:当用户访问量过大的时候，单机服务存在着严重的资源竞争例如CPU资源，内存资源，导致站点变慢

三)架构的工作原理:以电子商城为例，可以看到应用服务(划分出了多个模块)和数据库在各自的服务器上面通过网络传输完成业务运行；

四)优点:成本相对可控，性能相比于单机服务是有提升的，数据库单独隔离，不会因为应用把数据库搞坏是有一定的容灾能力的

五)缺点:硬件成本变高，性能还是存在瓶颈，无法应对于海量并发 

在应用服务器里面，可能会包含很多的业务逻辑，可能会吃很多的CPU和内存

数据库存储服务器需要更大的磁盘空间，需要更快的数据访问速度，于是就可以进行配置更大的硬盘的服务器，甚至还可以上SSD硬盘(固态硬盘)

在市面上，机械硬盘便宜但是快，固态硬盘贵但是快

三)应用服务器集群架构:

负载均衡器:是流量请求的入口，就像是公司里面的一个组的领导一样，要负责管理，要负责任的把任务分发给每一个组员，保证公平公正；

因为应用服务器比较吃CPU资源和内存资源，如果把CPU资源或者是内存资源吃没了，此时应用服务器就顶不住了，此时引入更多的应用服务器(引用更多的CPU和内存资源)就可以有效地解决上述问题，下面的图中看起来是两个用户服务器，而实际上可能是多个应用服务器，让每一台应用服务器分担一部分的请求，降低每一台机器所承担的压力，假设此时有1W个用户请求，有两个应用服务器，此时就可以按照负载均衡的方式，就可以让每一个应用服务器承担5K的访问量，本质上就是引入多台机器降低每一个服务器所产生的压力，引入更多的CPU，引入更多的主机

用户的请求首先是到达负载均衡器，网关均衡器(是一个单独的服务器)

简介:引入例如负载均衡操作，应用以集群的方式运作，负载均衡器对于请求量的承担能力，是远超应用服务器

出现原因:单个应用不足以支持海量的并发请求，高并发的时候站点响应变慢)

1)Round-Robin 轮询算法，即非常公平地将请求依次分给不同的应用服务器

2)Weight-Round-Robin 轮询算法，为不同的服务器(比如性能不同)赋予不同的权
重(weight)，能者多劳
3)一致哈希散列算法，通过计算用户的特征值(比如 IP 地址或者是用户的唯一身份标识)得到哈希值，根据哈希结果做分发，优点是确保来自相同用户的请求总是被分给指定的服务器，也就是我们平时遇到的专项客户经理服务

4)注意:用户在输入域名解析的时候，解析的是负载均衡的IP地址

架构工作原理:以电子商城为例，可以看到应用不只是一个，而是变成了多个，通过负载均衡来进行支持海量的并发

此时DNS服务器在进行域名解析的时候将一部分用户输入的域名变成IP1，此时这个HTTP请求就去寻找第一个LSV/F5，其他的请求被域名解析系统解析成IP2，此时这个HTTP请求就去寻找第二个LSV/F5；

但是此时用户的访问量进一步加大，连DNS服务器都处理不了域名的转换了，这个时候浏览器本身做缓存，这时浏览器就直接可以绕过DNS服务器直接去请求对应的LVS/F5 

优点:

1)应用服务高可用，应用满足高可用，不会因为一个服务器出问题把整个站点挂掉

2)应用服务器具备一定的高性能，如果说不访问数据库，应用处理通过扩展可以支持海量请求快速响应

3)应用服务器可以支持一定的扩展能力，支持横向扩展

缺点:

1)数据库成为性能瓶颈，应用满足高可用，不会因为一个服务器出现问题而把整个站点挂掉，但是数据库只有一个，高可用能力非常差，是无法应对数据库的海量查询

2)数据库是单节点，可用性非常差，如果数据库挂了，那么整个节点也就挂了

3)运维工作增多，扩展之后部署运维工作增多，需要开发对应的工具完成快速部署

4)硬件成本比较高

DNS做一级负载均衡，LSV做二级负载均衡，NGINX做三级负载均衡，Tomact做水平扩展

负载均衡器能够处理的请求量远远比应用服务器多，引入负载均衡器，引入更多的机器，势必会提高维护服务器的成本；

四)读写分离主从分离架构 

如上面讨论，如果增加应用服务器会使应用服务器可以处理更高的请求量，但是随之而来的存储服务器要进行承担的请求量也就更多了，解决方案就是开源(引入更多的机器)节流(门槛高况且更复杂)，解决方案就是数据库读写分离

节流:门槛高，更复杂

1)定义:将数据库读写操作分到不同的节点上面，数据库服务器搭建主从集群，一主一从或者是一主多从都可以，数据库主机负责进行写入操作，从机只是负责读取操作

2)出现原因:数据库成为瓶颈，而互联网应用一般要求读多写少，数据库承载压力比较大，主要是这些读的请求造成的，所以我们就可以把读操作和写操作分离开，高流量过来，读取要有一个快速的响应；

3)在实际开发中，读的概率是比写的概率高的，主服务器一般只有一个，但是从服务器是可以有多个，从而降低单独一台数据库访问的压力，一主多从，从服务器可以通过负载均衡的方式让应用服务器来进行访问；

3)架构工作原理:以电子商城为例，可以看到很多数据库服务器不再是一个，而是变成了多个，数据库的主机负责进行写操作，从机负责读操作，数据库主机通过主从复制将数据从主机同步到从机；

4)mycat组件时进行判断用户的请求是读操作还是写操作，如果是读操作，就分发到从MYSQL，如果是写操作，就分发到写的MYSQL，写完之后写MYSQL会进行同步给从数据库；

优点: 

1)数据库的读取性能和写的性能都会提升，因为增加了多个从服务器，所以读的性能提升了，因为读取操作被其他服务器分担，所以写的性能被进一步提升了

2)数据库有从库，数据库的可用性会大大的提升

缺点:

1)热点数据的频繁读取会使数据库的负载很高

2)当主节点同步的时候挂掉，或者是主从同步延时比较大的时候，写数据库和读数据库的信息是不一致的

3)服务器的成本需要进一步增加

五)冷热分离架构: 

1)定义:引入缓存，实现冷热分离，将热点数据保存到缓存中快速响应，把冷数据还是存放到数据库中，这样一个HTTP请求过来的时候，先查看缓存中是否存在，缓存中如果存在，直接返回，不需要和数据库进行交互，缓存通常使用内存存储，那么响应的速度才会非常快；

2)演变原因:海量的请求导致数据库负载变高，站点响应速度变慢，尤其是秒杀业务，可能在几秒钟就有数百万量的请求过来，数据库直接负载打满；

缓存服务器中只是存放一些一小部分热点的数据，也就是频繁访问到的数据，但是数据库存储的仍然是全量数据，redis主要就是作为缓存服务器，从而减少用户服务器的压力，此时缓存服务器就是来帮助数据库服务器负重前行；

 3)架构的工作原理:以电子商城为例，可以看到使用了很多的缓存服务器，对于热点数据全部存放到缓存中，不常用数据再去查询数据库，再写数据的时候，先写入到主数据库中，主数据库将信息同步到从数据库中，在写到Redis中，两者要么全部执行成功要么全部执行失败

4)优点:大幅度的降低了对数据库的访问请求，性能提升非常明显

5)缺点:带来了缓存雪崩，缓存穿透，缓存击穿，缓存失效的问题，还会增加服务器的成本

业务体量变大以后，数据不断增加，数据库单库太大导致单个表的体量也会太大，数据库查询还是会很慢，导致数据库再次成为性能瓶颈

 六)垂直分库架构(分库分表):

1.1)引入分布式系统，不光要能够去应对更高的请求量，同时也要能够应对更多的数据量，在实际的开发中很有可能会出现一台服务器已经无法存储所有的数据，虽然说一个服务器存储的数据量可以达到几十个TB，即便如此也有可能存不下，比如说抖音短视频，占据空间特别大，一台主机存不下去，就需要多台主机来进行存储，那么就需要针对于数据库做拆分，也就是分库分表；

1.2)本来一个数据库服务器，这个数据库服务器上面有多个数据库(本来指的是逻辑上面的数据集合，create database创建的那个东西)，现在就可以引入多个数据库服务器，每一个数据库服务器存储一个或者是一部分数据库，本来用户表，商品表和交易表都是存放在同一个数据库中的，但是现在将他们存放到不同机器上面的不同的数据库里面，每一个机器上面都可以插不同的硬盘，每一台主机都可以获取到一个比较大的存储空间，按照这样的方式进行拆分，那么总体的存储量就更大了，从主库里面去写，从从库里面读，redis缓存也是生效的

1.3)如果数据库中的某一张表特别大，大到连一个主机都存不下，那么此时也可以根据表来进行拆分，比如说可以将1张表拆分成5张表，搞5个数据库服务器来进行存储，每一个服务器存储这张表的一部分数据；

0)简介:数据库中的数据被拆分，数据库数据分布式存储，分布式处理，分布式查询，也可以理解成是分布式数据库架构；

出现原因:单机器的写库会逐渐达到性能瓶颈，需要进行拆分出数据库，数据库的表数据量太大，处理压力太大，需要进行分表操作，为降低运维的难度，业界逐渐研发了分布式数据库，库表天然支持分布式；

架构工作原理:以电子商城为例，数据库是有多个主从库或者存储集群构成，支持分布式大规模处理

1)当我们进行读操作的时候，有多个服务器并行地去处理读请求，当我们进行写操作的时候也是有多个服务器来并行处理写请求；

2)当我们进行写商品的时候，是写到一台服务器上面

而进行写用户的时候，是在另外一台服务器上

3)原来只有一个主从架构，现在按照业务上进行分库分表之后变成了多个主从结构

1)一开始是由电商库来进行抗住所有写的流量，但是后来扛不住了，于是就按业务上做了一个拆分，拆分成了用户库，商品库，以及交易库；

2)但是后期又发现交易商品库出现了性能瓶颈，针对交易库又进行了拆分，但是后期表也变得越来越大，这时候也针对表进行了拆分；

3)但是我们假设要求出商品总量，我们还需要select * from db1，select * from db2，select * from db3，SQL写起来非常的麻烦，这个时候有一个中间件MyCat自动地完成分库分表的操作，程序员不需要进行干涉分库分表的操作；

1)用户表可能不是一张表，可能是有几十台甚至几百台这样的服务器来提供读或者写的服务

2)包括流量的出口也不是一个节点，而是有多台服务器来提供一个并行的出口

好处就是当我们进行读写商品的时候不会影响到用户数据库服务器和交易商品数据库服务器，可以有自己结点的配置

1)写入:当用户想要进行新增商品表的时候，用户发送过来的域名将会被DNS服务器解析成负载均衡的IP地址，然后由负载均衡服务器将请求随机发送到一台应用服务器，然后应用服务器会先向缓存服务器redis中写入缓存，再向主库商品表服务器中插入数据，最后再将商品表主库中的数据同步给从库；

2)读取:当用户想要进行查询商品表的时候，用户发送过来的域名将会被DNS服务器解析成负载均衡的IP地址，然后由负载均衡服务器将请求随机发送到一台应用服务器，然后应用服务器会先向缓存服务器redis中查询商品信息，redis服务器将商品信息返回给应用服务器，应用服务器将商品信息返回给负载均衡服务器，负载均衡服务器将查询结果返回给用户的浏览器，如果缓存中没有对应的商品信息，那么此时就会访问商品表中存储集群的从数据库，从数据库将商品信息返回给应用服务器，用服务器将商品信息返回给负载均衡服务器，负载均衡服务器将查询结果返回给用户的浏览器

3)分库分表配合中间件就组成了一个分布式数据库

Greenplum是分布式数据库

优点:数据库吞吐量大幅度提升，不再是瓶颈

缺点:

1)需要跨库，分布式事务等问题，这些需要对应的方案去解决

2)数据库与缓存结合目前可以抗住海量的请求，但是整体的代码耦合在一起，修改一行代码需要整体进行重新发布；

七)微服务架构:

1)定义:微服务是一种架构风格，会按照业务模块来进行划分具体的应用代码，是的单个应用的职责变得更清晰，相互之间可以做到独立升级迭代

2)出现原因:

1)扩展性差:应用程序无法进行轻松扩展，因为每一次需要进行更新应用程序的时候，都必须重新构建整个系统；

2)持续开发困难，一个很小的代码改动都需要重新部署整个应用，所以无法频繁并轻松的发布版本；

3)不可靠:即使系统中的一个功能出现问题了，那么可能会导致整个系统都无法进行工作

4)不灵活:无法使用不同的技术来进行构建单体应用程序

5)代码维护难:所有的功能都耦合在一起，新人不知道该如何进行下手

3)架构的工作原理:以电子商城为例，一个商城应用拆分成了多个微服务，比如说用户服务，交易服务和商品服务，相互之间协作来进行支持整个复杂商城的应用；

直播服务可以复用商城系统中的用户子系统，商品子系统和交易子系统

底项的这些微服务最终就沉淀成了公共的微服务层

上面的就是具体的一个个应用服务层

微服务之间需要进行相互调用，相互协作来完成一个完整的功能，而不是像之前一样，在一个系统一个大的应用里面直接就能进行调用；

用户要去查询指定的商品详情:

之前的应用服务器，一个服务器程序里面做了很多的业务，这就有可能会导致一个服务器里面的代码变得越来越复杂，为了更方便地进行维护，就可以把这样的一个复杂的服务器，拆分成更多的，功能更单一的，但是也是功能越小的服务器，那么此时会导致服务器的种类和数量也就增加了；

1)用户经过DNS服务器把域名转化成负载均衡的IP地址，负载均衡将请求分发给商城系统，这个HTTP请求就被分发到了商城子系统，商城子系统又去用户子系统去查询发布商品的人的信息(因为在商品的具体信息里面，还要打印出是谁发布的这个商品，也就是商家)，于是就去了用户的微服务去查询发布商品的人的信息；

2)从用户的微服务直接去查询用户信息，如果缓存中存在就直接返回用户信息，缓存中没有用户信息就去查询数据库用户从库，但是此时查询的是从库，用户的微服务将发布的商品用户信息返回给商品的微服务，此时商品的微服务向商品库中的从库商品表中进行查询，从商品的从数据库中查询出指定的商品信息之后返回给商品的微服务(不考虑商品缓存)；

3)拿用户信息的时候同时去拿商品信息；

微服务的优点:

1)微服务架构的灵活性高，各个服务独立测试，部署，升级，发布不会相互影响；

2)独立扩展:每一个服务可以进行各自的扩展，假设要新增一个监控服务，只需要加一个监控微服务即可，而不需要将所有的微服务全部进行修改；

3)提高容错性:假设交易功能挂了，但是用户和商品的微服务全部正常，而不是说因为一个交易功能把整个商城和直播功能全部搞挂了；

4)新技术的应用容易:加入一个其它语言的服务非常容易，支持多种编程语言，微服务之间都是通过标准的协议，例如HTTP协议，RPC协议来进行沟通的，这些协议之间是跨语言的，方便人员进行管理，有利于组织的优势划分；

微服务的缺点:

1)运维工作量大:运维复杂度高，因为业务在不断发展，应用和服务都会不断增多，应用和服务之间的部署也变得越来越复杂，同一台服务器上部署多个服务还要进行解决运行环境冲突的问题，此外，对于如大促销这类需要进行动态扩容的场景，需要水平扩展服务的性能，就需要在新增的服务上准备运行环境，部署环境等，运维将会变得十分困难；

2)资源使用变多:所有这些独立运行的微服务都需要占用内存和CPU

3)处理故障困难:

一个请求需要跨多个服务调用，需要进行查看不同服务的日志来完成问题定位，而不是像单体应用一样，日志都在一个地方；

1)之前的一个应用服务器程序里面做了很多的业务，这就很可能导致一个服务器里面的代码变得越来越复杂，一个机器既要去做用户相关的逻辑，又要去做商品相关的逻辑，又要去实现交易相关的逻辑，现在这个功能我们拆分成三组微服务来进行实现，第一组微服务专门针对于用户服务来进行处理，第二组微服务专门针对于商城微服务来进行处理，第三组微服务专门针对于交易微服务来进行处理，这样就把一组应用服务器分成了三组，这里面的每一组微服务并不是一台机器，而是多台机器，使用多台机器来处理更高的并发量，每一组微服务服务器都有着自己的功能存储集群和缓存模块；

2)引入负载均衡是为了处理请求量过高的问题，引入分库分表是为了解决数据存储空间不足的问题，引入微服务实际上是为了解决人的问题，引入微服务是为了解决人的问题，因为应用服务器代码特别的多，应用功能也特别的多，开发一个需求或者是改一个BUG，就需要更多的人，就会消耗更多的人力成本，因为当应用服务器变得复杂了，势必就需要更多的人来进行维护，招聘更多的人，组件更大的团队；

3)当人多了之后，就需要配套的管理，把这些人组织好，防止人摸鱼，划分组织结构，分成多个组，分一个组分别配备领导来进行管理，把人分成多个组就需要分工，责任和活都好分担，之前把一个代码写在一起不好分组解决，按照功能，拆分成多组微服务，就可以有利于上面组织人员的结构分配了，假设将人力分成了三个组，这样也划分出了很多的微服务模块，每一个组负责微服务模块中的一部分，这样此时的工作职责划分的是更明确的，人员进行分组工作内容上也要划分；

4)同时这一个组的每一个技术人员专精于各自的微服务，专精于单独的模块，就可以把这个模块打造得更好，微服务方便人员进行管理，进行组织结构的划分，使用微服务更方便与功能的复用，可以单独的提取一个模块给其他模块使用，还可以针对不用的微服务配置部署，可以给微服务进行不同的机器配置和硬件资源的使用；

缺点:

1)引入微服务，虽然解决了人的问题，会使系统的整体性能功能下降，原来的用户模块，商品模块和交易模块都是都是集成在一台主机上面的，相互调用只是需要在进程内调用操作内存就可以了，但是引入微服务之后，由于不同的微服务在不同的主机上，要是用户模块想要调用交易模块就会涉及到跨主机之间的调用，跨主机之间进行网络通信比进程之间通信要慢很多，就需要网络传输，拆分出更多的微服务，多个功能之间可能要更依赖于网络通信，网络通信的速度可能是比读取硬盘的时间还要慢，要想保证性能不下降太多，只能引入更多的机器，更多的硬件资源，也就只能是充钱，幸运的是由于经验技术的发展，网卡现在有万兆网卡(支持网线)，读写的速度已经可以超过硬盘的读写速度了；

2)系统复杂程度提高，可用性会受到影响，服务器变多了，整体的出现BUG的概率更高了，这就需要一系列的手段，来保证系统的可用性就需要更丰富的报警系统以及配套的运维人员，监控程序也要更加复杂，成本会提高不少，运维人员的工作量也会增大；

1)解决了人的问题；

2)实现了解耦合，更方便的用于代码的复用，用户模块单独提取出来；

3)对不同的服务做不同的部署，不同的服务部署到的机器不同；

八)容器编排架构

定义:借助容器化技术比如说docker将应用或者服务可以打包成镜像，通过容器编排工具比如说k8s来进行动态分发和部署镜像，服务以容器化的方式来运行；

出现原因:

1)微服务拆分比较细，服务多部署，况且工作量比较大，出错性高

2)微服务数量多况且缩容麻烦，而且容易出错，每一次缩容之后又进行扩容又需要重新进行配置服务对应的环境参数信息

3)微服务之间可能运行环境冲突，需要更多的资源来进行部署或者(例如说端口号冲突)修改配置来进行解决冲突；

1)最上面的商城和直播是应用服务层，下面的各种微服务是基础服务层

2)小型公司可以把应用服务层和基础服务层共用一个k8s

3)这个公司分为基础平台部，商城平台部和直播平台部

4)在我们进行查看商品信息的时候，不光要去访问商品信息，还要进行访问商品对应的用户信息，最后都是在商品的微服务进行汇总的(商品微服务调用用户子系统的用户微服务的过程和商品微服务调用从库查询商品信息的这两个过程可以是同步的)；

当然也可以有商城系统直接分别调用用户的微服务和商品的微服务，两个微服务分别查询信息之后再由商城系统直接将信息汇总

4)商城微服务可以使用容器来包裹一下，直播微服务也可以使用容器来包裹一下，然后再使用两个k8集群来分别包裹一下，最终就可以形成三个k8s集群也是可以的

5)不需要服务器上面的操作系统和文件，而是需要容器里面的文件和操作系统就可以运行起来服务是跑在小盒子里面也就是容器里面，盒子与盒子之间的文件，盒子和容器的文件是不会相互干扰的；

6)下面的两件衣服就相当于是JAVA应用和C++应用，通过箱子把衣服打包成包裹，箱子就相当于是docker，包裹就相当于是镜像，快递公司要进行发货，就相当于是kf8，包裹和包裹之间并不会发生冲突，都是互相隔开的，都在箱子里面，箱子就又被称之为是容器

工作原理:以电子商城为例，一个商城应用拆分出了多个多个微服务，比如说用户服务，交易服务和商品服务，每一个微服务打包到一个容器里面，相互协作来完成系统功能，通过容器编排来完成部署运维；

在没有k8s和容器之前:我们要在第一台服务器上面部署四个用户微服务，一个商品微服务和一个交易微服务，运维同学要把所有发布的jar包拷贝过来，拷贝成六份，然后调用java -jar xxx.jar进行启动，一共启动六次；

有了k8s之后:直接告诉k8s，我要在第一个服务器上部署四个用户的微服务，一个商品的微服务和一个用户的微服务，k8s会自动打包镜像，会把所有的微服务直接部署好；

 

优点:

1)部署运维简单快速，一条命令就可以完成几百个服务的部署或者是缩招扩容

2)隔离型好:容器和容器之间文件系统和网络相互隔离，不会产生环境冲突

3)轻松支持滚动更新，版本之间进行切换可以通过一个命令来进行升级或者是回滚

缺点:

1)技术栈变多，对研发团队要求高；

2)闲置机器增多:机器还是要通过公司本身来进行管理，虽然我们可以做到扩容和缩容，很多机器只有在促销的时候，也就是用户访问量大的时候才会用到，日常就空闲下来了，仍然闲置着大量的机器，就可以借助云厂商，也就是云服务器，双11到的时候，就多买10几台云服务器，双11过后，就把云服务器还给云厂商，不能说因为双11，备用10台物理机，双11的时候用11台，日常的时候只是使用1-2台，剩下8台在那里休息；

实战架构:

1)MongoDB:评论和商品的描述都是大段的文字，而这些文字和描述信息在MYSQL中存储非常的浪费空间，就需要使用文档存储库MongoDB集群；

2)Hadoop:当发现数据量非常的大，况且数据非常的有价值，这时就要使用Hadoop集群

3)统一的数据服务层:当用户微服务想要向数据库中插入数据的时候，针对于缓存数据要使用一大堆的API，针对于基础数据要学习一大堆的API，针对于对象存储，要学习一大堆的API，为了解决这个问题，就抽象出了一个统一的数据服务层，这里提供的所有的API接口都是增删改查，好处就是提升了开发效率，缺点就是屏蔽了底层的技术实现细节，对底层的数据实现就不太了解了；

 docker核心作用:代码可以容器化的运行还有完成核心的打包

1)例如说现在有一个电子商城应用，用四台4C8G服务器来部署用户的应用，需要四台8C16G服务器来部署商品的应用， 用四台4C16G来进行部署订单的应用；

2)这个时候难道我们要购买12台服务器吗？

今天你说用户服务器使用的是4C8G，明天又说要使用4C16G，今天商品要使用8C16G，明天双11过去了，商品服务器回到2C4G就可以了，所以可不可以搞一个非常大的服务器，直接进行切分好，你要4C8G就给你4C8G，你要4C16G就给你4C16G，这就是所谓的一种资源隔离的技术，但是这个隔离的进度是进程级别的，两个4C8G的微服务之间不要进行相互干扰，所以进程集资源的隔离就成为了诉求；