更新数据

README.md

@@ -194,6 +194,14 @@
 - [18、画图阐述一下你们的服务注册中心部署架构，生产环境下怎么保证高可用？](/docs/distributed-system/register-high-availability.md)
 - [19、你们系统遇到过服务发现过慢的问题吗？怎么优化和解决的？](/docs/distributed-system/service-register-discovery.md)
 - [20、作业：说一下自己公司的服务注册中心怎么技术选型的？生产环境中应该怎么优化？](/docs/distributed-system/register-production-optimize.md)
+- [21、你们对网关的技术选型是怎么考虑的？能对比一下各种网关技术的优劣吗？](/docs/distributed-system/gateway-model-selection.md)
+- [22、说说生产环境下，你们是怎么实现网关对服务的动态路由的？](/docs/distributed-system/dynamic-route.md)[代码下载点击这里哦!](https://github.com/shishan100/Java-Interview-Advanced/raw/master/docs/distributed-system/code/code2.zip)
+- [23、如果网关需要抗每秒10万的高并发访问，你应该怎么对网关进行生产优化？](/docs/distributed-system/gateway-high-concurrency.md)
+- [24、作业：你们公司的网关是怎么技术选型的，假设有高并发场景怎么优化？](/docs/distributed-system/gateway-technical.md)
+- [25、如果需要部署上万服务实例，现有的服务注册中心能否抗住？如何优化？](/docs/distributed-system/registration-center-optimize.md)
+- [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)
 
 
 ### 第二季-高并发

docs/distributed-system/dynamic-route.md

@@ -0,0 +1,22 @@
+```
+CREATE TABLE `gateway_api_route` (
+   `id` varchar(50) NOT NULL,
+   `path` varchar(255) NOT NULL,
+   `service_id` varchar(50) DEFAULT NULL,
+   `url` varchar(255) DEFAULT NULL,
+   `retryable` tinyint(1) DEFAULT NULL,
+   `enabled` tinyint(1) NOT NULL,
+   `strip_prefix` int(11) DEFAULT NULL,
+   `api_name` varchar(255) DEFAULT NULL,
+   PRIMARY KEY (`id`)
+ ) ENGINE=InnoDB DEFAULT CHARSET=utf8
+
+INSERT INTO gateway_api_route (id, path, service_id, retryable, strip_prefix, url, enabled) VALUES ('order-service', '/order/**', 'order-service',0,1, NULL, 1);
+
+   ```
+
+你可以自己用简单的spring mvc+前端页面封装一个可视化的网关管理工作台，如果新开发了一个服务之后，就可以在这个界面上配置一下，说某个服务对应某个url路径，修改，增删改查
+
+http://localhost:9000/order/order/create?productId=1&userId=1&count=2&totalPrice=50
+
+生产级，企业级的功能，网关的动态路由

docs/distributed-system/gateway-high-concurrency.md

@@ -0,0 +1,23 @@
+
+第一个是高并发，第二个是如何优化
+
+![高性能网关Zuul](/docs/distributed-system/images/gateway-high-concurrency.png)
+**Zuul**网关部署的是什么配置的机器，**部署32核64G，对网关路由转发的请求**，**每秒抗个小几万请求是不成问题的，几台Zuul网关机器**
+
+**每秒是1万请求，8核16G的机器部署Zuul网关，5台机器就够了**
+
+### 生产级的网关，应该具备我刚才说的几个特点和功能：
+
+#### (1)动态路由：新开发某个服务，动态把请求路径和服务的映射关系热加载到网关里去；服务增减机器，网关自动热感知
+#### (2)灰度发布：基于现成的开源插件来做
+#### (3)授权认证
+#### (4)限流熔断
+#### (5)性能监控：每个API接口的耗时、成功率、QPS
+#### (6)系统日志
+#### (7)数据缓存
+
+
+
+
+
+

docs/distributed-system/gateway-model-selection.md

@@ -0,0 +1,40 @@
+
+### 网关的核心功能
+
+#### (1)动态路由：新开发某个服务，动态把请求路径和服务的映射关系热加载到网关里去；服务增减机器，网关自动热感知
+#### (2)灰度发布
+#### (3)授权认证
+#### (4)性能监控：每个API接口的耗时、成功率、QPS
+#### (5)系统日志
+#### (6)数据缓存
+#### (7)限流熔断
+
+
+### 几种技术选型
+
+#### Kong、Zuul、Nginx+Lua（OpenResty）、自研网关
+
+**Kong：Nginx里面的一个基于lua写的模块，实现了网关的功能**
+**Zuul：Spring Cloud来玩儿微服务技术架构，Zuul**
+
+**Nginx+Lua（OpenResty）：课程目录里面，有一个文档，课程免费学习，亿级流量系统架构的课程，详细讲解了Nginx+Lua的开发**，基于lua自己写类似Kong的网关
+**自研网关：自己来写类似Zuul的网关，基于Servlet、Netty来做网关，实现上述所有的功能**
+
+
+大厂：BAT、京东、美团、滴滴之类的，自研网关，都是基于Netty等技术自研网关；Nginx + Lua（Tengine）来做，封装网关的功能
+
+中小型公司：Spring Cloud技术栈主要是用Zuul，Gateway；如果是Dubbo等技术栈，有的采用Kong等网关，也可以直接不用网关，很多公司压根儿就没用网关，直接Nginx反向代理+负载均衡；
+
+Zuul：基于Java开发，核心网关功能都比较简单，但是比如灰度发布、限流、动态路由之类的，很多都要自己做二次开发
+
+Kong：依托于Nginx实现，OpenResty，lua实现的模块，现成的一些插件，可以直接使用
+
+
+
+Zuul（Servlet、Java）：高并发能力不强，部署到一些机器上去，还要基于Tomcat来部署，Spring Boot用Tomcat把网关系统跑起来；Java语言开发，可以直接把控源码，可以做二次开发封装各种需要的功能
+
+Nginx（Kong、Nginx+Lua）：Nginx抗高并发的能力很强，少数几台机器部署一下，就可以抗很高的并发，精通Nginx源码，很难，c语言，很难说从Nginx内核层面去做一些二次开发和源码定制
+
+
+Java技术栈为主的大厂，很多其实用Java、Servlet、Netty来开发高并发、高性能的网关系统，自己可以把控一切
+

docs/distributed-system/gateway-technical.md

@@ -0,0 +1,6 @@
+
+服务框架的原理和技术选型，你们公司到底是怎么选，为什么？
+
+服务注册中心，思考，你们公司到底是怎么选的，生产环境有没有做一些优化，如果没有，哪些地方是有优化空间的？
+
+网关系统，思考，你们公司是怎么选型的，为什么？生产环境是否对类似动态路由的功能做过优化，如果没有是否有优化空间？

docs/distributed-system/gray-environment.md

@@ -0,0 +1,76 @@
+
+#### 准备一个数据库和一个表（也可以用Apollo配置中心、Redis、ZooKeeper，其实都可以），放一个灰度发布启用表
+
+```
+id service_id path enable_gray_release
+
+CREATE TABLE `gray_release_config` (
+   `id` int(11) NOT NULL AUTO_INCREMENT,
+   `service_id` varchar(255) DEFAULT NULL,
+   `path` varchar(255) DEFAULT NULL,
+   `enable_gray_release` int(11) DEFAULT NULL,
+   PRIMARY KEY (`id`)
+ ) ENGINE=InnoDB DEFAULT CHARSET=utf8
+
+
+
+在zuul里面加入下面的filter，可以在zuul的filter里定制ribbon的负载均衡策略
+
+<dependency>
+			<groupId>io.jmnarloch</groupId>
+			<artifactId>ribbon-discovery-filter-spring-cloud-starter</artifactId>
+			<version>2.1.0</version>
+		</dependency>
+
+写一个zuul的filter，对每个请求，zuul都会调用这个filter
+
+@Configuration
+public class GrayReleaseFilter extends ZuulFilter {
+
+@Autowired
+private JdbcTemplate jdbcTemplate;
+
+    @Override
+    public int filterOrder() {
+        return PRE_DECORATION_FILTER_ORDER - 1;
+    }
+
+    @Override
+    public String filterType() {
+        return PRE_TYPE;
+    }
+
+    @Override
+    public boolean shouldFilter() {
+
+    }
+
+    @Override
+    public Object run() {
+        RequestContext ctx = RequestContext.getCurrentContext();
+        HttpServletRequest request = ctx.getRequest();
+
+Random random = new Random();
+int seed = random.getInt() * 100;
+
+        if (seed = 50) {
+            // put the serviceId in `RequestContext`
+            RibbonFilterContextHolder.getCurrentContext()
+                    .add("version", "new");
+        }  else {
+            RibbonFilterContextHolder.getCurrentContext()
+                    .add("version", "old");
+        }
+
+        return null;
+    }
+}
+ ```
+
+eureka:
+instance:
+metadata-map:
+version: new
+
+
+

docs/distributed-system/registration-center-optimize.md

@@ -0,0 +1,6 @@
+
+![分布式注册中心](/docs/distributed-system/images/registration-center-optimize.png)
+#### eureka：peer-to-peer，每台机器都是高并发请求，有瓶颈
+#### zookeeper：服务上下线，全量通知其他服务，网络带宽被打满，有瓶颈
+
+#### 分布式服务注册中心，分片存储服务注册表，横向扩容，每台机器均摊高并发请求，各个服务主动拉取，避免反向通知网卡被打满

docs/distributed-system/service-register-gateway-router.md

@@ -0,0 +1,12 @@
+
+#### 生产环境，微服务生产实践
+
+开发了一个新的服务，线上部署，配合网关动态路由的功能，在网关里配置一下路径和新服务的映射关系，此时请求过来直接就可以走到新的服务里去
+
+对已有服务进行迭代和开发，新版本，灰度发布，新版本部署少数几台机器，通过一个界面，开启这个服务的灰度发布，**此时zuul filter启用，按照你的规则，把少量的流量打入到新版本部署的机器上去**
+
+观察一下少量流量在新版本的机器上运行是否正常
+
+版本改成current，全量机器部署，关闭灰度发布功能，网关就会把流量均匀分发给那个服务了
+
+

docs/distributed-system/work-register.md

@@ -0,0 +1,13 @@
+
+#### Dubbo框架原理
+#### Spring Cloud框架原理
+#### 服务框架的技术选型
+
+#### 服务注册中心技术选型和核心原理
+#### 生产优化
+#### 架构优化
+
+#### 网关系统技术选型和核心原理
+#### 生产优化（灰度发布、动态路由）
+
+#### 生产级的分布式系统里，新服务开发如何做，老服务迭代如何做