最后
经过日积月累， 以下是小编归纳整理的深入了解Java虚拟机文档，希望可以帮助大家过关斩将顺利通过面试。
由于整个文档比较全面，内容比较多，篇幅不允许，下面以截图方式展示 。
由于篇幅限制，文档的详解资料太全面，细节内容太多，所以只把部分知识点截图出来粗略的介绍，每个小节点里面都有更细化的内容！
我们在讨论负载层的几篇文章中，我们要假设系统架构中各层的设计都没有对系统性能产生瓶颈
如果您已经思考好了，那么可以继续看以下的内容。
2、负载方案构想
========
2.1、解决方案一：独立的Nginx/Haproxy方案
很显然，第一个业务场景下，系统并没有多大的压力就是一套简单业务系统，日访问量也完全没有“有访问压力”这样的说法。但是客户有一个要求值得我们关注：要保证系统以后的功能和性能扩展性。为了保证功能和性能扩展性，在系统建立之初就要有一个很好的业务拆分规划，例如我们首先会把用户信息权限子系统和订单系统进行拆分，独立的车辆信息和定位系统可能也需要拆分出来。
这也是我们在系统建立时就要引入负载均衡层的一个重要原因。也是负载均衡层的重要作用之一。如下图所示：
可以看出，这时负载均衡层只有一个作用，就是按照设定的访问规则，将访问不同系统的请求转发给对应的系统，并且在出现错误访问的情况下转发到错误提示页面。
2.2、解决方案二：Nginx/Haproxy + Keepalived方案
此后，系统的访问压力进一步加大，系统的稳定性越来越受到我们的关注。所以在单节点处理还能满足业务要求的情况下，我们为负载层（还有各层）引入热备方案，以保证一个节点在崩溃的情况下，另一个节点能够自动接替其工作，为工程师解决问题赢得时间。如下图所示：
2.3、解决方案三：LVS（DR）+ Keepalived+ Nginx方案
在第三版本架构方案中，为了保证负载层足够稳定的状态下，适应更大的访问吞吐量还要应付可能的访问洪峰，我们加入了LVS技术。LVS负责第一层负载，然后再将访问请求转发到后端的若干台Nginx上。LVS的DR工作模式，只是将请求转到后端，后端的Nginx服务器必须有一个外网IP，在收到请求并处理完成后，Nginx将直接发送结果到请求方，不会再经LVS回发（具体的LVS工作原理介绍将在后文中详细介绍）。
这里要注意的是：
-
有了上层的LVS的支撑Nginx就不再需要使用Keepalived作为热备方案。因为首先Nginx不再是单个节点进行负载处理，而是一个集群多台Nginx节点；另外LVS对于下后端的服务器自带基于端口的健康检查功能；
-
LVS是单节点处理的，虽然LVS是非常稳定的，但是为了保证LVS更稳定的工作，我们还是需要使用Keepalived为 LVS做一个热备节点，以防不时之需。
2.4、解决方案四：DNS轮询 + LVS（DR）+ Keepalived + Nginx方案
场景四中，为了满足平均上亿的日PV访问，在对业务进行外网暴露的基础上，我们在互联网的最前端做了一个DNS轮询。然后将（对用户信息系统）访问压力首先分摊到两个对称LVS组上，再由每个组向下继续分拆访问压力。
注意上图的负载层方案的不同：
-
首先我们不在像前面的方案中，使用目录名分割业务系统了，而是直接将业务系统的访问使用不同的二级域名进行拆分。这样的变化有利于每个业务系统都拥有自己独立的负载均衡层。
-
请注意上图中的细节，这个负载均衡层是专门为“用户信息子系统”提供负载均衡支撑的，而可能还存在的“订单子系统”、“车辆信息子系统”都会有他们独立的负载均衡层。
-
在LVS下方的Nginx服务可以实现无限制的扩展，同样的就像场景三种所给出的解决方案一样，Nginx本身不在需要Keepalived保持热备，而是全部交由上层的LVS进行健康情况检查。而即使有一两台Nginx服务器出现故障，对整个负载集群来说问题也不大。
方案扩展到了这一步，LVS层就没有必要再进行扩展新的节点了。为什么呢？根据您的业务选择的合适的LVS工作模式，两个LVS节点的性能足以支撑地球上的所有核心WEB站点。如果您对LVS的性能有疑惑，请自行谷歌百度。这里我们提供了一份参考资料：《LVS性能，转发数据的理论极限》http://www.zhihu.com/question/21237968
3、为什么没有独立的LVS方案
===============
在下一篇文章《架构设计：负载均衡层设计方案（2）——LVS、keepalived、Nginx安装和核心原理解析》中我们将提到这个问题。实际上通过本篇文章的架构演进分析，一些读者都可以看出端倪。如果用一句话说明其中的原因，那就是LVS为了保证其性能对配置性有所牺牲，单独使用的话往往无法满足业务层对负载层灵活分配请求的要求。
4、说明
====
4.1、术语说明
-
TPS: 衡量业务层处理性能的重要指标（每秒钟request/事务的处理数量）。业务服务处理一个完整的业务过程，并向上层返回处理结果的过程就是一个 request/事务。那么在一秒钟内整个业务系统能够完成多少个这样的过程，其衡量单位就是TPS。TPS不但和系统架构有很大的关系（特别是业务层和业务通信层的架构祥泰），和物理环境、代码质量的关系也非常密切。
-
PV: 网页浏览数是评价网站流量最常用的指标之一，简称为PV。Page Views中的Page一般是指普通的html网页，也包含php、jsp等动态产生的html内容。注意是完整的显示一个Page成为一个PV。但是一个PV，一般需要多次HTTP请求，以便获取多个静态资源，这是需要注意的。
-
UV: Unique Visitor 一个独立IP，在一个单位时间内（例如一日/一小时）对系统的一个PV请求，成为一个UV（重复的PV不在进行计数）。
-
RUV: Repeat User Visitor 一个独立用户，在一个单位时间内（例如一日/一小时）对系统的一个PV请求，并且重复的访问要进行计数。
最后
既已说到spring cloud alibaba，那对于整个微服务架构，如果想要进一步地向上提升自己，到底应该掌握哪些核心技能呢？
就个人而言，对于整个微服务架构，像RPC、Dubbo、Spring Boot、Spring Cloud Alibaba、Docker、kubernetes、Spring Cloud Netflix、Service Mesh等这些都是最最核心的知识，架构师必经之路！下图，是自绘的微服务架构路线体系大纲，如果有还不知道自己该掌握些啥技术的朋友，可根据小编手绘的大纲进行一个参考。
如果觉得图片不够清晰，也可来找小编分享原件的xmind文档！
且除此份微服务体系大纲外，我也有整理与其每个专题核心知识点对应的最强学习笔记：
-
出神入化——SpringCloudAlibaba.pdf
-
SpringCloud微服务架构笔记（一）.pdf
-
SpringCloud微服务架构笔记（二）.pdf
-
SpringCloud微服务架构笔记（三）.pdf
-
SpringCloud微服务架构笔记（四）.pdf
-
Dubbo框架RPC实现原理.pdf
-
Dubbo最新全面深度解读.pdf
-
Spring Boot学习教程.pdf
-
SpringBoo核心宝典.pdf
-
第一本Docker书-完整版.pdf
-
使用SpringCloud和Docker实战微服务.pdf
-
K8S(kubernetes)学习指南.pdf
另外，如果不知道从何下手开始学习呢，小编这边也有对每个微服务的核心知识点手绘了其对应的知识架构体系大纲，不过全是导出的xmind文件，全部的源文件也都在此！
558
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
