从宏观的角度来讲，整个时代是大众创业万众创新的时代，作为程序员我们每个人都有一个梦想，吊打面试官，很多人给我说，我想进百度，想进阿里，想进腾讯，等一线互联网公司。你就需要知道面试官的一些大招，这样才能有效躲避，进而反击；
目前大多数企业都属于中小企业， 所有的大企业都是从小公司一步一步发展起来，我曾经所在的京东也同样如此；
大家看一下，目前中小企业IT架构面临的问题
- 当业务发生变化，不断的在原有系统的上打补丁
- 当业务发展时，系统不断出现各种瓶颈
- 卡顿，数据库锁死，网站打不开，
- 各种502错误，流量上来系统就挂了
为什么会出现这么多问题呢？
因为企业没有优秀的架构师，作为面试官，他需要招聘一些更懂架构的人。
怎么才能成为一名优秀的架构师
- 有实战经验
- 实战的应用场景
接下来给大家介绍一下京东的15次架构演变的过程，作为架构师，你经过这15次架构，接下来你去架构日均亿级的架构，每秒并发5000qps，没有一点问题。
京东历经15次技术架构的演进过程
首先要干一件事情，
定义，你当前企业的架构，目前所处的一个架构阶段，就像打仗一样， 先看地图，摸清楚地形，制定战术。
定位问题：根据实际公司的实际情况定义新的架构图片（重构）
好了，大家跟我一起看一下京东的15次技术架构的演进过程
第一单体架构
一．单体架构
浏览器访问，通过DNS把域名转换IP地址，访问后台的应用服务器，
这个是目前很多企业早期用的架构。
应用服务和数据库部署到同一台服务器上。
问题：
- 随着用户的增长，应用服务器和数据库服务器之间相互竞争服务器资源
- 单机不足以支撑业务
- 一个单点故障出现，整个服务宕机
二． 应用服务器和数据库分库部署
应用服务和数据库分别独占服务器资源，这样能够缓解服务占用资源大的问题，能显著提高两者性能
问题：
用户在增长时候，并发读写都在同一个数据库，数据库的压力变大，数据库成为瓶颈
- 引入本地缓存和分布式缓存
应用服务器增加本地缓存，在外部增加分布式缓存，另外缓存热门数据和一些静态页面，通过缓存把我们大多数请求，在我们读写数据库之前拦截掉，这样的话数据库压力就降低了。
我们需要会掌握哪些技术栈呢？
Memcached，Redis作为分布式缓存，一旦用到缓存，就会涉及到缓存一致性问题，缓存穿透/击穿问题，缓存雪崩，热点数据的集中失效问题等，这个怎么办呢？
在接下来我们要解决的问题，如你还没有遇到，你可能还没有进入架构领域里面来。
问题：
- 缓存抗住了大部分的请求，用户增长，大部分的请求落到了应用服务器上，导致应用服务器响应慢。
- 通过本地缓存和分布式缓存还是无法解决问题，数据库抗住了，但是应用服务器又扛不住了。
四． 引入反向代理实现负载均衡
怎么实现负载均衡呢？当请求过来的时候，我们使用Nginx，原来请求到一台应用服务器，现在变成多台应用服务器，使用Nginx分发把请求分发到每一台应用服务器。
假设：
应用服务器最多支持100并发
Nginx请求分发到500个应用服务器 ，就能支持50000个并发。
问题：
- 使用nginx又会造成Sesson共享一致性问题，
- 文件上传下载问题，
- 当我们使用Nginx反向代理服务器增加我们的并发，我们单机的数据库成为最终的瓶颈。
接下来我们进行进入下一次演进。
五． 数据库分库
当数据库成为瓶颈的时候，数据库要进行业务的分库，数据库分为读库和写库，读库可以有多个，通过数据库的同步机制，把写库的数据同步到读库。中间会涉及到哪些技术栈呢：
Mycat，SharedingJDBC等等数据库中间件，实现数据库的读写分离
数据的同步问题，数据的一致性问题
面临的问题：
-业务增长，不同业务之间访问的差距比较大，相互竞争数据库资源，影响性能
六． 数据库按业务分库
按照业务分库，同样我们使用分布式缓存，数据库按照业务划分，不同的业务保存到不同的数据上。
面临的问题：
业务和用户量增加，单机的写库会逐渐达到性能的瓶颈
接下来我们要进入一个部分。第七次演进把数据库大表拆分成小表
七． 把数据库大表拆分成小表
大表拆小表，按照月，按周，按照商品ID进行hash，按照小时创建小表，只要能拆分成小表，大家可以通过MyCat中间件进行查询，这种是典型的MBP的架构，最终由数据库汇总数据进行返回。
面临的问题
数据库和应用服务器Tomcat能够水平扩展，后端通过数据库读写分离，大表拆小表，后端可以抗住目前的流量，随着流量增加，Nginx会成为性能瓶颈。
八． 使用LVS或F5使用多个Nginx负载均衡
由于瓶颈是Nginx ，无法通过两层Nginx实现多个负载均衡，
LVS是一个软件，工作在网络四层负载方案，运行在操作系统内核，支持的协议很丰富，性能远高于Nginx，比如说，单机支持几十万个并发请求
F5是一个负载均衡硬件服务器，与LVS类似，性能也比LVS高，价格高
LVS是单机版的软件，如果LVS宕机，导致后端服务无法访问
因此需要有备用的节点，我们使用Keepalive
模拟虚拟IP，通过虚拟IP绑定的多台LVS服务器上，用户访问会路由的真实的LVS IP地址上，实现LVS服务器高可用效果。
问题：
用户访问地点千差万别，随着用户流量增加，单机房无法支撑现有业务
九． 通过DNS轮询实在机房间的负载均衡
一个域名多个IP，当用户访问的时候，通过DNS服务器轮询，来实现多个机房或跨机房的访问，达到千万级别到亿级别，通过增加机房解决，跨机房的一致性问题，接下来的课程中会介绍。
问题：
业务复杂度增加，传统数据库无法支撑现有的查询搜索服务
十． 引入NoSQL数据库和搜索引擎
原来的架构存储不变，对于海量的文件存储我们用HDFS
Key，Value类型的数据库：HBase，Redis
全文检索我们用ElasticSeach
现在问题又来了：
随着业务的越来越复杂，应用包含业务代码越来越多，业务迭代困难，业务代码复杂
接下来需要把大应用拆分成不同的小应用
十一． 把大应用拆分成小应用
等下我们讲微服务和容器，按照业务拆分，淘宝，天猫，天猫国际，聚划算，支付宝等等，
- 按照业务板块划分成不同的应用代码
- 使单个应用职责清晰，相互应用独立升级迭代
- 应用之间涉及公共配置
- 分布式配置中心zookeeper来解决
问题：
淘宝，天猫，天猫国际，聚划算，支付宝相互之间有重复代码（公共部分升级，每个都需要升级）非常麻烦
十二． 复用的功能抽离成微服务
接下来就是我们最熟知的微服务，到底什么是微服务？
最早开始使用微服务是springboot，很多企业从springmvc转向springboot，
现在公司很多用的都是springboot
使用springboot，简化了很多操作，从部署到发布的模型都变了，把应用代码和tomcat打成jar包，以前都是打成war包，每个微服务是独立的应用，只有这么做才能为微服务做好铺垫，并不是说springboot和springcould就是一个微服务，它只是实现他的基础架构而已，微服务本质就是一种思想。
像淘宝，天猫，支付宝的公用的功能抽取出来；比如用户管理，订单，支付，这个时候需要把公共的部分代码单独抽离出来，形成一个独立的服务来管理，应用之间通过多种通信方式来访问，并由单独的团队进行管理，独立维护。通过服务的限流，熔断，降级处理，提高服务的稳定性和可用性，例如：到双11之前几天，商家价格尽快修改，到双十一那天是不能修改，这个是典型的降级处理。
这个时候会不会问题呢：
这个时候，由于微服务越来越多，服务之间相互访问，调用链路也越来越复杂，难以维护，引入企业的服务总线和屏蔽服务接口的访问差异
十三． 引入企业的服务总线和屏蔽服务接口的访问差异
今天没有办法讲的特别细，接下来的课程会越来越细，唯一不同的是增加了ESB企业服务总线，
ESB统一协议转换，服务相互调用，降低服务的耦合程度，
公共服务单独提供服务，类似SOA，面向服务的架构，SOA服务架构与微服务架构很类似，
微服务是公共功能抽取公共服务，SOA是一种拆分服务，并使服务接口变的统一的架构思想。
现在面临什么呢问题
无法动态水平扩展，运维变得困难
有了微服务就一定要引入容器化呢？引入容器技术，实现环境隔离与动态服务管理
十四． 引入容器技术实现环境隔离与动态服务管理
每次架构的演进，代码越来越简单了，企业的技术升级后，不需要那么多开发人员，通过K8S进行编排里面会用到docker，为什么微服务一定要用docker，docker就是为微服务而生，目前最流行的，包括现在的阿里，京东，美团，滴滴，现在全部用docker；
目前最流行的技术是Docker，目前所有的应用服务打包成docker镜像都放到docker容器中运行，容器管理：K8S
双11之前：在现有的机器上划分出服务器启动Docker镜像，增加服务性能
双11之后：活动结束之后：可以关闭镜像，对服务器上其他的服务不会咋成任何影响。
使用容器，服务的动态扩容迎刃而解。运维服务器还需要自身管理
十五． 云平台承载系统
把多台物理服务器虚拟化后，构成一个资源池，实现共同计算，共享。
也就是现在所谓“云计算”。
例如：一个应用的高峰时段是白天，而一个应用的高峰时段是晚上。如果两个应用使用独立的计算资源，那么为了应对高峰时期的需求二者都要配备较大的计算能力，但在非峰值的时候这些资源就闲置了，形成浪费。
云服务的共享的计算资源，因为二者峰值时段不重叠，只需要配备满足两个应用中峰值需求较大的那个的资源就足够了。这样闲置资源减少、提高资源的利用率。
云服务器则将成千上万个这样的应用分配到一个共享的平台上，经济效益非常可观。
双11几千亿的订单，阿里巴巴，京东所有的核心系统全部上云。
