add .

README.md

@@ -202,6 +202,10 @@
 - [26、你们是如何基于网关实现灰度发布的？说说你们的灰度发布方案？](/docs/distributed-system/gray-environment.md)[代码下载点击这里哦!](https://github.com/shishan100/Java-Interview-Advanced/raw/master/docs/distributed-system/code/code3.zip)
 - [27、说说你们一个服务从开发到上线，服务注册、网关路由、服务调用的流程？](/docs/distributed-system/service-register-gateway-router.md)
 - [28、作业：看看你们公司的服务注册中心能否支撑上万服务实例的大规模场景？](/docs/distributed-system/work-register.md)
+- [29、画一下你们系统的整体架构图，说说各个服务在生产环境怎么部署的？](/docs/distributed-system/system-framework.md)
+- [30、你们系统每天有多大访问量？每个服务高峰QPS多少？压测过服务最大QPS吗？](/docs/distributed-system/system-qps.md)
+- [31、如果系统访问量比现在增加10倍，你们考虑过系统的扩容方案吗？](/docs/distributed-system/system-dilatation.md)
+- [32、作业：独立画出自己系统的生产部署架构图，梳理系统和服务的QPS以及扩容方案](/docs/distributed-system/work-system-dilatation.md)
 
 
 ### 第二季-高并发

docs/distributed-system/system-dilatation.md

@@ -0,0 +1,12 @@
+
+如果访问量扩大10倍，如何扩容？
+
+网关直接多部署10倍的机器即可，前面的Nginx做会负载均衡，把流量均匀分发给各个网关机器
+
+服务扩容，都很简单的，多加机器，部署启动，自动注册到注册中心里去，此时其他服务会自动感知到你的服务多加了一些机器
+
+服务实例变多了10倍，此时几十个服务实例，几百个服务实例，对eureka机器会造成每秒几百请求，没问题，eureka机器，8核16G的配置，单机抗上千请求，很轻松
+
+数据库本来是每秒几百请求，10倍，每秒高峰期是三四千请求，横向扩容很麻烦，此时可以考虑给单个数据库部署的机器提高配置，32核128G高配物理机，每秒钟抗几千请求问题不大
+
+

docs/distributed-system/system-framework.md

@@ -0,0 +1,51 @@
+
+### 服务框架、注册中心、网关系统
+
+即使你没有用很多微服务架构里的东西，只要有上述三个东西，配合上写一些文档，接口文档，分布式系统架构，其实就出来了，很多中小型公司，一个小型技术团队，后端开发工程师总共就10多个人
+
+关注分布式系统一些生茶实践的问题，应对你们公司的流量，各个服务、网关、注册中心，都是如何部署的，部署几台机器，每台机器的配置是什么，每天整体的流量有多少，高峰期的请求量有多少，你的整体系统是否抗住了
+
+各个服务之间的超时、重试、幂等，是否搞定了
+
+数据库配置和部署
+
+
+很多同学，他们因为在自己公司里面开发的都是一些单块系统，微服务架构，但是公司没什么流量，他对机器的配置抗多少并发请求，其实没多大的概念，都不是什么技术问题，很多同学出去面试的时候
+
+死扣生产细节问题，每秒3000并发请求，各个服务部署多少机器，机器的配置，数据库的机器和配置，网关的机器和配置，注册中心的机器和配置，什么样的机器配置能抗多大的流量和请求
+
+
+
+中小型的系统，拆分为10~20个服务，微服务，庞大的互联网公司，都有几百个、几千个、几万个服务，服务规模，服务注册中心，妥妥的，2~3台机器就足够了，把服务的上线、故障以及发现优化到极致
+
+服务上线，注册表多级缓存同步1秒，注册表拉取频率降低为1秒
+服务心跳，1秒上报1次
+故障发现，1秒钟检查一次1心跳，如果发现2秒内服务没上报心跳，认为故障了
+
+服务注册中心都没任何压力，最多就是每秒钟几十次请求而已
+
+服务注册中部署个2台机器，每台机器就是4核8G，高可用冗余，任何一台机器死掉，不会影响系统的运行
+
+服务注册中心这样的一个处理逻辑，4核8G的机器，每秒钟轻松抗几百请求，上千请求也是可以的
+
+通常来说，如果每秒钟的并发在1000以内的话，很少部署的，每个服务部署2台机器，每台机器4核8G，每台机器每秒抗个几百请求，一点问题都没有，别搞出来一个请求过来，查数据库SQL写的太烂了，一条SQL要跑3秒钟
+
+大部分的系统，高峰期每秒几百请求，低峰期每秒几十请求，甚至几个请求
+
+
+
+网关系统，4核8G的机器，一台机器抗每秒几百请求，部署3~4台机器，保证可以网关系统每台机器的压力比较小，进一步保证网关系统可靠性
+
+
+
+数据库，MySQL，16核32G，物理机最佳，32核64G，最多抗个每秒钟几千请求问题不大，平时抗个每秒钟几十或者几百请求，三四千请求，但是只不过此时会导致MySQL机器的负载很高，CPU使用率很高，磁盘IO负载很高，网络负载很高
+
+
+
+
+
+
+
+
+
+

docs/distributed-system/system-qps.md

@@ -0,0 +1,42 @@
+
+很常问，很多人回来跟我说，老师，我不知道我们系统每秒钟请求有多少，每天请求量有多大，我都没任何的概念，因为系统开发好直接部署，根本不管这些东西，有没有什么比较好的工具可以看到服务的访问量，qps
+
+
+
+
+
+每个服务每天多少请求量，高峰期每秒钟多少请求量，你完全可以在代码里，稍微加一些metrics的代码，如果你看过很多的开源项目的话，开源的分布式系统，eureka、hadoop、spark、hbase、kafka，metrics机制
+
+
+任何一个开源系统都需要对自己运行过程中各种请求量、每秒的请求量、成功次数、失败次数，在内存里直接做一些计数，他会给你开放一些端口号，比如http端口号，你只要请求他这个端口号，他就会把这些metrics统计返回给你
+
+
+
+
+在你负责的核心服务里，核心接口，开发一个简单的metric统计机制，AtomicLong，原子性，并发下数据统计准确，不会错误，每个接口被调用的时候，一个是可以对每个接口每分钟都做一个Metric统计
+
+对每个接口每天的请求使用一个AtomicLong做一个计数，统计出来每天的请求次数
+
+计算一下每个接口从请求到执行完毕，需要耗费多长时间，算一下每个接口平均的请求延时，TP99，TP95，TP90，TP50，TP99，99%的请求耗费的时间在100ms以内，但是1%的请求可能耗费的时间在100ms以上
+
+**TP99 = 100ms**
+**TP95 = 50ms，95%的请求耗费的时间多在50ms以内，但是5%的请求耗费的时间在50ms以上**
+
+平均响应延时
+
+你可以计算出来这个接口平均响应延时，把每次调用的耗时跟历史总耗时加起来，除以当前的请求次数，不就是最新的接口响应平均延时
+
+
+
+
+你完全可以通过log4j，logback，日志组件，把每分钟每个接口被访问的次数直接打印到日志文件里去，除以60，不就知道高峰期每秒钟系统被访问的次数了吗，每天每个接口访问的总次数打印到日志里去
+
+
+
+压测工具，百度一下：java压测工具，开源的可以用的，模拟出来同时有多少用户发起多少请求，每秒发起1000请求能抗住吗？每秒钟发起2000请求能抗住吗？
+
+假设你的系统每秒钟最多抗800请求，如果你的压测工具每秒发起了1000个请求，此时他会发现最多只有800个请求同时可以被处理，剩余200个请求需要进行排队被阻塞住了，告诉你，你的这个系统每秒钟最多抗800个请求
+
+
+
+

docs/distributed-system/work-system-dilatation.md

@@ -0,0 +1,2 @@
+
+部署，机器配置，大概能抗多少并发；流量、QPS、性能，metrics；压测，借助一些小工具；扩容方案，横向加机器，还是说纵向提升机器的配置