diff --git a/README.md b/README.md index 3ff0552..03dcd9e 100644 --- a/README.md +++ b/README.md @@ -151,6 +151,7 @@ ### 分布式事务 - [分布式事务了解吗？你们如何解决分布式事务问题的？TCC 如果出现网络连不通怎么办？XA 的一致性如何保证？](/docs/distributed-system/distributed-transaction.md) +- [关于如何实现一个TCC分布式事务框架的一点思考](http://www.bytesoft.org) ### 分布式会话 - [集群部署时的分布式 Session 如何实现？](/docs/distributed-system/distributed-session.md) @@ -177,6 +178,46 @@ - [02、Java工程师面试突击第一季总结：你离一次成功的面试还差多少？](/docs/distributed-system/java-interview-season-1-summary.md) - [03、《21天互联网Java进阶面试训练营》的课程说明](/docs/distributed-system/21-day-course-instructions.md) - [04、作业：系统分析一下，自己距离大厂offer差在哪里？](/docs/distributed-system/homework.md) +- [05、感受一下BAT面试官对分布式技术的十几个面试连环炮!](/docs/distributed-system/BAT-interview-fire.md) +- [06、你们公司用的Dubbo？那你再额外说说Spring Cloud的核心架构原理？](/docs/distributed-system/core-architecture-principle%20.md) +- [07、基于Dubbo和Spring Cloud分别搭建一个电商系统来快速体验一下！](/docs/distributed-system/Dubbo-SpringCloud-experience.md)[代码下载点击这里哦!](https://github.com/shishan100/Java-Interview-Advanced/raw/master/docs/distributed-system/code/code.zip) +- [08、作业：你们的系统使用了哪种服务框架？为什么要这样技术选型？](/docs/distributed-system/distributed-framework-selection.md) +- [09、看过Dubbo源码吗？说说Dubbo的底层架构原理？](/docs/distributed-system/dubbo-framework-principle.md) +- [10、咱们来聊点深入的，说说Dubbo底层的网络通信机制原理！](/docs/distributed-system/dubbo-rock-bottom.md) +- [11、Dubbo框架从架构设计角度，是怎么保证极高的可扩展性的？](/docs/distributed-system/dubbo-augmentability.md) +- [12、作业：自己独立画出Dubbo的底层架构原理图](/docs/distributed-system/dubbo-independent-framework.md) +- [13、如果让你设计一个RPC框架，网络通信、代理机制、负载均衡等该如何设](/docs/distributed-system/rpc-design.md) +- [14、平时除了使用外，有研究过Spring Cloud的底层架构原理么？](/docs/distributed-system/springCloud-study-theory.md) +- [15、从底层实现原理的角度，对比一下Dubbo和Spring Cloud的优劣！](/docs/distributed-system/dubbo-vs-springCloud.md) +- [16、作业：自己独立画出Spring Cloud的架构原理图，RPC框架架构设计图！](/docs/distributed-system/springCloud-and-rpc-framework.md) +- [17、面试官：你们的服务注册中心进行过选型调研吗？对比一下各种服务注册中心！](/docs/distributed-system/registration-center-%20guide.md) +- [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) +- [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) +- [33、你们生产环境的服务是怎么配置超时和重试参数的？为什么要这样配置？](/docs/distributed-system/service-request-time-out.md)[代码下载点击这里哦!](https://github.com/shishan100/Java-Interview-Advanced/raw/master/docs/distributed-system/code/code4.zip) +- [34、如果出现服务请求重试，会不会出现类似重复下单的问题？](/docs/distributed-system/request-retry.md) +- [35、对于核心接口的防重幂等性，你们是怎么设计的？怎么防止重复下单问题？](/docs/distributed-system/interface-idempotence.md) +- [36、作业：看看自己系统的核心接口有没有设计幂等性方案？如果没有，应该怎么设计？](/docs/distributed-system/work-interface-idempotence.md) +- [37、画一下你们电商系统的核心交易链路图，说说分布式架构下存在什么问题？](/docs/distributed-system/deal-line.md) +- [38、针对电商核心交易链路，你们是怎么设计分布式事务技术方案的？](/docs/distributed-system/work-distributed-transaction.md) +- [39、对于TCC事务、最终一致性事务的技术选型，你们是怎么做的？如何调研的？](/docs/distributed-system/distributed-transaction-tcc.md) +- [40、作业：你们公司的核心链路是否有事务问题？分布式事务方案怎么调研选型？](/docs/distributed-system/work-distributed-transaction.md) +- [41、在搭建好的电商系统里，落地开发对交易链路的TCC分布式事务方案](/docs/distributed-system/tcc-landing-scheme.md) +- [42、你能说说一个TCC分布式事务框架的核心架构原理吗？](/docs/distributed-system/tcc-framework-principle.md) +- [43、现有的TCC事务方案的性能瓶颈在哪里？能支撑高并发交易场景吗？如何优化？](/docs/distributed-system/tcc-high-concurrence.md) +- [44、作业：如果对自己的系统核心链路落地TCC事务，应该如何落地实现？](/docs/distributed-system/work-tcc-landing-scheme.md) ### 第二季-高并发 diff --git a/docs/distributed-system/BAT-interview-fire.md b/docs/distributed-system/BAT-interview-fire.md new file mode 100644 index 0000000..be006dc --- /dev/null +++ b/docs/distributed-system/BAT-interview-fire.md @@ -0,0 +1,61 @@ +针对面试突击第一季关于分布式这块的内容，相对应的做一个回顾和总结 + +面试突击第一季总共四五十讲，每个技术专题大概也是有十来讲 + +#### (1)为什么要把系统拆分成分布式的？为啥要用dubbo？ +#### (2)dubbo的工作原理是啥？注册中心挂了可以继续通信吗？ +#### (3)dubbo都支持哪些通信协议以及序列化协议？ +#### (4)dubbo支持哪些负载均衡、高可用以及动态代理的策略？ +#### (5)SPI是啥思想？dubbo的SPI机制是怎么玩儿的？ +#### (6)基于dubbo如何做服务治理、服务降级以及重试？ + +这些问题在面试突击第一季里，我们都讲解过了，都是非常高简单的一些问题，作为一个合格的工程师，如果你是用了分布式系统架构，也就是把大的系统拆分为了多个子系统，或者是 多个服务 + +你肯定会用到一种服务框架，Dubbo、Spring Cloud、gRPC、Thrift + +你必须 对这些服务框架的核心的架构原理，有一个认识和了解，服务注册和发现，通信和序列化，负载均衡，扩展机制，请求重试，请求超时 + +#### (7)分布式系统中接口的幂等性该如何保证？比如不能重复扣款？ +#### (8)分布式系统中的接口调用如何保证顺序性？ + +接口幂等性，分布式系统，如果不保证，是否会发生类似重复下单，重复扣款之类的问题 + +#### (9)如何设计一个类似dubbo的rpc框架？架构上该如何考虑？ + +自己看过一些dubbo、spring cloud的源码，对一款服务框架底层的实现原理，有一定的了解和认识，此时如果说他希望能够深入的考察你一下，看看你的水平，这个时候就有可能会问你这个问题 + +#### (10)说说zookeeper一般都有哪些使用场景？ +#### (11)分布式锁是啥？对比下redis和zk两种分布式锁的优劣？ + +拆分成了分布式系统，就说明有很多子系统在同时的运作，如果说两个子系统都需要对某个数据资源进行一系列复杂的操作，在复杂操作期间，不能让数据被其他任何人来改变。分布式锁，技术实现原理 + +#### (13)说说你们的分布式session方案是啥？怎么做的？ + +前后端分离之后，一般是前端那边来care session之类的问题，对于后端来说，玩儿分布式session玩儿的很少了 + +#### (14)了解分布式事务方案吗？你们都咋做的？有啥坑？ + + +**我们的课程每天都会有一个作业，引导大家把学习到的项目经验、技术方案和生产优化落地到自己负责的项目中去，让大家出去面试的时候，可以把各种技术结合自己的项目来回答面试官的各种深度拷问** + +**大家不要小看这个，根据我多年的面试经验来看，拥有这个技能的人凤毛麟角，这种人出去绝对是各大公司争抢的对象。** + +**所以希望大家好好完成每天的作业，我布置的大量作业，就是为了帮你锻造出这种能力** + +**学习课程以及完成作业的过程中，大家一定会有很多的问题，可以到专栏的评论区去提问** + +**每天我都会和之前带出来的一批阿里、蚂蚁金服、滴滴的优秀同学给大家进行答疑，并且我们还有专门的付费用户的微信群，大家可以在微信群里跟我们一起进行技术交流** + +**如果你能坚持下来，学满6季，还可以获取私人定制的面试一条龙VIP服务** + +**如果是连续6季面试训练营都购买的同学，还可以获取面试一条龙VIP服务** + +**具体信息大家看“狸猫技术窝”公众号的知识店铺内的训练营详情即可** + +**具体可参见训练营目录下的《训练营专属服务》文档。简单来说，这个私人定制的面试VIP服务，会为你的跳槽面试全程保驾护航** + +**“狸猫技术窝”**，找到我们的训练营的详情页面 + + + + diff --git a/docs/distributed-system/Dubbo-SpringCloud-experience.md b/docs/distributed-system/Dubbo-SpringCloud-experience.md new file mode 100644 index 0000000..3111668 --- /dev/null +++ b/docs/distributed-system/Dubbo-SpringCloud-experience.md @@ -0,0 +1,9 @@ +Spring Cloud来搭建了一套 + +http://localhost:9000/order/order/create?productId=1&userId=1&count=3&totalPrice=300 + +刚开始几次请求会出现请求超时的问题，这个问题大家别纠结，后续要给大家讲spring cloud生产系统的优化 + +小小的小作业，参考一下dubbo的官方文档，搭建一个电商系统的dubbo版本的案例出来，我后面会搭建好的 + +[代码下载点击这里哦!](https://github.com/shishan100/Java-Interview-Advanced/raw/master/docs/distributed-system/code/code.zip) diff --git a/docs/distributed-system/code/code.zip b/docs/distributed-system/code/code.zip new file mode 100755 index 0000000..330db00 Binary files /dev/null and b/docs/distributed-system/code/code.zip differ diff --git a/docs/distributed-system/code/code2.zip b/docs/distributed-system/code/code2.zip new file mode 100755 index 0000000..655526a Binary files /dev/null and b/docs/distributed-system/code/code2.zip differ diff --git a/docs/distributed-system/code/code3.zip b/docs/distributed-system/code/code3.zip new file mode 100644 index 0000000..e69de29 diff --git a/docs/distributed-system/code/code4.zip b/docs/distributed-system/code/code4.zip new file mode 100755 index 0000000..4862a03 Binary files /dev/null and b/docs/distributed-system/code/code4.zip differ diff --git a/docs/distributed-system/core-architecture-principle .md b/docs/distributed-system/core-architecture-principle .md new file mode 100644 index 0000000..12990cc --- /dev/null +++ b/docs/distributed-system/core-architecture-principle .md @@ -0,0 +1,44 @@ +如果聊分布式这块的技术，围绕**Dubbo来拷问**的，但是呢，现在其实非常流行的是**Spring Cloud，Dubbo和Spring Cloud以及阿里系的一些技术**，现在正在融合，**Spring Cloud Alibaba，只不过现在用的公司暂时还没那么多而已** + +作为合格的工程师，行业里主流的**分布式服务技术栈**，**Dubbo**和**Spring Cloud**两种，有的公司他是用**Dubbo**的，不用**Spring Cloud**的，有的公司是用**Spring Cloud**的，不用**Dubbo**的，他们是代表了两种主流技术栈 + +Java工程师，Dubbo和Spring Cloud起码是基本原理，都有一定的了解 + +**大白话 + 现场画图** + +上网看一些博客资料，或者是买一些Spring Cloud的书，可能没考虑过一个事儿，第一篇必须是用非常通俗的语言，把一个系统如果用Spring Cloud来做分布式架构的话，那么他需要用到Spring Cloud哪些组件，为什么 + +跟着书或者博客，直接上手开始搭建demo，开始做起来了 + +**分别用Dubbo和Spring Cloud做两个最基本的Demo工程**，用电商背景来搭建几个服务 + +比如说，现在我们有一个电商系统 + +用户现在需要下单购买一些东西这样子，订单系统、库存系统、仓储系统、积分系统 + +不太可能说用单块的架构，电商系统你想支撑多少用户量？10万注册用户，日活1000用户来你这里来购买？ + +百万级用户，十万级日活，单块系统就不太合适了，背后有几十个人的团队在协作开发，此时单块系统是绝对不合适的 + +梳理和明确一个概念：电商系统，拆分为了多个子系统，一次下订单的请求需要多个子系统协作完成，每个子系统都完成一部分的功能，多个子系统分别完成自己负责的事情，最终这个请求就处理完毕 + +我们不会让每个视频太长，按照我们大纲来讲，说是60讲，粗略的大纲，其实最终会拆分成可能上百讲，Spring Cloud架构原理，我们就要分为上下两讲来说 +![Spring Cloud核心架构原理](/docs/distributed-system/images/SpringCloud-core-architecture.png) + +### Spring Cloud + +#### Eureka：服务注册中心 +#### Feign：服务调用 +#### Ribbon：负载均衡 +#### Zuul/Spring Cloud Gatway:网关 + +这么多的系统，电商系统包含了20个子系统，每个子系统有20个核心接口，一共电商系统有400个接口，这么多的接口，直接对外暴露，前后端分离的架构，难道你让前端的同学必须记住你的20个系统的部署的机器，他们去做负载均衡，记住400个接口 + + +微服务那块，**网关** + +**灰度发布**、**统一熔断**、**统一降级**、**统一缓存**、**统一限流**、**统一授权认证** + + + +**Hystrix**、**链路追踪**、**stream**、很多组件，Hystrix这块东西，其实是会放在高可用的环节去说的，并不是说一个普通系统刚开始就必须得用的，没有用好的话，反而会出问题，**Hystrix线路熔断的框架**，必须得设计对应的一整套的限流方案、熔断方案、资源隔离、降级机制，配合降级机制来做 diff --git a/docs/distributed-system/deal-line.md b/docs/distributed-system/deal-line.md new file mode 100644 index 0000000..cb77258 --- /dev/null +++ b/docs/distributed-system/deal-line.md @@ -0,0 +1,37 @@ + +分布式系统核心的问题，服务框架、注册中心、网关系统、部署架构、超时重试、幂等防重，生产相关的问题，都搞定了，还是针对面试这块，人家到时候问你很多的生产问题，你必须回答的很好，你可以自己主动聊，说我们在生产环境里做了哪些优化 + +分布式事务，分布式锁 + +核心交易链路，核心数据链路，核心计算链路，核心业务链路，都建议要上分布式事务，保证核心链路的数据一致性 + +面试突击第一季，如果你没看过，务必去看一下，分布式事务这块，几种技术方案，我当时都讲解过了，离落地还有一段距离 + +分布式锁，在分布式系统中用的是非常多的，单块系统，不需要分布式事务，一个系统对应一个数据库，事务都是本地数据库的事务就可以了；锁，很多地方多线程并发修改一些共享资源，在单块系统内部用synchronized锁就可以搞定了 + + + +分布式系统，事务 -> 分布式事务，锁 -> 分布式锁 + + + + + 订单服务 -> 创建订单 + -> 库存服务 -> 扣减库存 + -> 积分服务 -> 增加积分 + -> 仓储服务 -> 通知发货 + + + +微服务架构里，哪怕你就部署了一个MySQL在一台高配物理机上，但是在这个MySQL实例中会创建不同的database，db_order，db_inventory，db_credit，db_wms，订单服务涉及到5张表，db_order中就会有5张表 + + + +已经在自己本地插入了一条订单数据了，调用库存服务扣减库存，在db_inventory里执行sql扣减库存，此时库存服务执行失败了，但是对于订单服务，他可能是没有感知到，他的订单还是创建成功了，调用积分服务和仓储服务，积分增加了，还打算对商品进行发货 + + +订单服务 -> 创建了订单，库存服务 -> 扣减了库存，积分服务 -> 增加积分失败，一旦回滚了之后，就会导致创建的订单被取消了，没了，create语句，放在本地事务里，一旦发现失败了，此时就会回滚，就会导致 + + + + diff --git a/docs/distributed-system/distributed-design.md b/docs/distributed-system/distributed-design.md index 4af29d4..793cd81 100644 --- a/docs/distributed-system/distributed-design.md +++ b/docs/distributed-system/distributed-design.md @@ -8,7 +8,7 @@ 最最起码的，你应该去从哪个角度来考察这个获选人呢？职位JD要求是工作经验在3年~5年，有一定的社会工作经验的 -###（1）技术广度来考察 +### (1)技术广度来考察 招聘过来一个有几年经验的人，就不要再去培养他了，候选人的整个技术栈是比较匹配我们团队的技术栈的 @@ -34,7 +34,7 @@ JVM，数据库和并发，都是必考的 薪资在20k左右，差不多 -###（2）项目经验 +### (2)项目经验 你平时用的各种技术在你的项目中如何结合业务来进行落地，然后你在项目的生产环境中落地一个技术之后，对他进行的生产优化、架构优化、生产实践是怎么来做的 @@ -50,7 +50,7 @@ JVM，数据库和并发，都是必考的 出去面试的时候，往往被 面试官一通追问项目的各种细节，然后就直接死了 -###（3）生产经验 +### (3)生产经验 分布式、微服务这块，你说用过网关，网关调研了哪几种技术？对比一下他们的优缺点？最后你们是怎么进行技术选型的？你们这个系统每天的访问量多高？高峰期QPS多高？你们网关要抗多高的QPS？网关是如何部署的？部署了几台机器？每台机器的配置如何，几个核CPU，几个GB内存？ @@ -74,7 +74,7 @@ JVM，数据库和并发，都是必考的 如果是很多的大厂，哪怕是三五年经验，或者二三年经验，也会来考察这块项目经验和生产经验，越是大厂，对你的能力里要求就越高，希望你进来以后越能独当一面，所以就希望你不光只是有技术广度 -###（4）技术深度 +### (4)技术深度 你有没有读过哪些开源项目的源码，RocketMQ，RocketMQ的源码，Dubbo的源码，如果你精通一些技术的源码的话，为什么会特别的有价值，有竞争力，让面试官更加的倾向于用你呢？ @@ -86,7 +86,7 @@ Dubbo、RocketMQ、Kafka、ES，随时可能有问题，比如说Dubbo随时可 大厂，很可能会考察你的技术深度，如果发现你没有什么技术深度，那么可能你就没有太大的竞争优势 -###（5）系统设计 +### (5)系统设计 往简单了说，就是会考察一些问题，比如说让你来设计秒杀系统，设计一个12306火车票购票系统，支撑几亿用户买火车票，你会如何来设计，让你设计一个微信红包系统，你会如何来考虑 diff --git a/docs/distributed-system/distributed-framework-selection.md b/docs/distributed-system/distributed-framework-selection.md new file mode 100644 index 0000000..422fd5b --- /dev/null +++ b/docs/distributed-system/distributed-framework-selection.md @@ -0,0 +1,3 @@ +**Spring Cloud**入门和使用级别的资料，建议大家自行百度，面试训练营，不是说针对每个技术详细给大家讲解的一个课程，我们会针对每个技术推出重磅的项目实战课程 + +**自己公司如果是分布式的架构，你们当前选用的是Spring Cloud？Dubbo？自己研发的服务框架？对比一下各种服务框架的优点和缺点，技术选型，为什么？** diff --git a/docs/distributed-system/distributed-transaction-tcc.md b/docs/distributed-system/distributed-transaction-tcc.md new file mode 100644 index 0000000..7accfba --- /dev/null +++ b/docs/distributed-system/distributed-transaction-tcc.md @@ -0,0 +1,22 @@ + +类似TCC事务的，开源框架，ByteTCC，Himly，个人技术高手自己写的，star也不少，也有一些中小型公司生产环境用了类似的分布式事务框架，知名度和普及型不高；很多公司，对类似的分布式事务，是自己写一些类似的框架 + + + +阿里开源了分布式事务框架，fescar，技术体系上有很多地方都是有自己的东西，seata，阿里开源的分布式事务框架，类似TCC事务，seata来做，这个框架是经历过阿里生产环境大量的考验的一个框架 + +支持dubbo、spring cloud两种服务框架，都是可以的 + + + + +可靠消息最终一致性方案，面试突击第一季里都说过，ActiveMQ封装一个可靠消息服务，基于RabbitMQ封装，自己开发一个可靠消息服务，收到一个消息之后，会尝试投递到MQ上去，投递失败，重试投递 + +人家消费成功了以后必须回调他一个接口，通知他消息处理成功，如果一段时间后发现消息还是没有处理成功，此时会再次投递消息到MQ上去，在本地数据库里存放一些消息，基于ActiveMQ / RabbitMQ来实现消息的异步投递和消费 + + + +RocketMQ，作为MQ中间件，提供了分布式事务支持，他把可靠消息服务需要实现的功能逻辑都做好了 + + + diff --git a/docs/distributed-system/dubbo-augmentability.md b/docs/distributed-system/dubbo-augmentability.md new file mode 100644 index 0000000..253b47f --- /dev/null +++ b/docs/distributed-system/dubbo-augmentability.md @@ -0,0 +1,25 @@ +两点，第一点，是核心的组件全部接口化，组件和组件之间的调用，必须全部是依托于接口，去动态找配置的实现类，如果没有配置就用他自己默认的 + +第二点，提供一种自己实现的组件的配置的方式，比如说你要是自己实现了某个组件，配置一下，人家到时候运行的时候直接找你配置的那个组件即可，作为实现类，不用自己默认的组件了 + + + + +**我们的课程每天都会有一个作业，引导大家把学习到的项目经验、技术方案和生产优化落地到自己负责的项目中去，让大家出去面试的时候，可以把各种技术结合自己的项目来回答面试官的各种深度拷问** + +**大家不要小看这个，根据我多年的面试经验来看，拥有这个技能的人凤毛麟角，这种人出去绝对是各大公司争抢的对象。** + +**所以希望大家好好完成每天的作业，我布置的大量作业，就是为了帮你锻造出这种能力** + +**学习课程以及完成作业的过程中，大家一定会有很多的问题，可以到专栏的评论区去提问** + +**每天我都会和之前带出来的一批阿里、蚂蚁金服、滴滴的优秀同学给大家进行答疑，并且我们还有专门的付费用户的微信群，大家可以在微信群里跟我们一起进行技术交流** + +**如果你能坚持下来，学满6季，还可以获取私人定制的面试一条龙VIP服务** + +**如果是连续6季面试训练营都购买的同学，还可以获取面试一条龙VIP服务** + +**具体信息大家看“狸猫技术窝”公众号的知识店铺内的训练营详情即可** + +**具体可参见训练营目录下的《训练营专属服务》文档。简单来说，这个私人定制的面试VIP服务，会为你的跳槽面试全程保驾护航** + diff --git a/docs/distributed-system/dubbo-framework-principle.md b/docs/distributed-system/dubbo-framework-principle.md new file mode 100644 index 0000000..cf5918b --- /dev/null +++ b/docs/distributed-system/dubbo-framework-principle.md @@ -0,0 +1,73 @@ +聊**分布式**这块，**Dubbo相关的原理**，**Spring Cloud相关的原理**，有的面试官可能会这样问，你有没有看过**Dubbo或者Spring Cloud的源码呢**？**技术广度**、**技术深度**、**项目经验**、**系统设计**、**基本功** + +平时看你简历主要是用一些技术来开发一些系统，就会问问你了，对于一些你平时常用的技术，有没有关注过底层的原理，或者是看过源码，你要是说，90%的人，一般都会在这个时候支支吾吾的说 + +源码看过一点点，但是没怎么看过 + +在我们面试训练营里，能给你来分析源码吗？不太现实的，任何一个开源项目，**源码**少则几万行，多则几十万行，**Hadoop、Spark**，**面试训练营**，几讲的时间来讲透任何一个**开源项目**的**源码**，不现实 + +看源码技巧是有，但是，需要**技术功底** + +就是说提炼一些**Dubbo、Spring Cloud**相关的一些底层的运行的原理，给大家来用大白话+现场画图的方式，说清楚，你就可以结合我们视频讲解的内容，去现场画图给面试官画一画一些技术底层的运行的一些原理 + + +我们的课程每天都会有一个作业，引导大家把学习到的项目经验、技术方案和生产优化落地到自己负责的项目中去，让大家出去面试的时候，可以把各种技术结合自己的项目来回答面试官的各种深度拷问 + +大家不要小看这个，根据我多年的面试经验来看，拥有这个技能的人凤毛麟角，这种人出去绝对是各大公司争抢的对象。 + +所以希望大家好好完成每天的作业，我布置的大量作业，就是为了帮你锻造出这种能力 + +学习课程以及完成作业的过程中，大家一定会有很多的问题，可以到专栏的评论区去提问 + +每天我都会和之前带出来的一批阿里、蚂蚁金服、滴滴的优秀同学给大家进行答疑，并且我们还有专门的付费用户的微信群，大家可以在微信群里跟我们一起进行技术交流 + +如果你能坚持下来，学满6季，还可以获取私人定制的面试一条龙VIP服务 + +如果是连续6季面试训练营都购买的同学，还可以获取面试一条龙VIP服务 + +具体信息大家看“狸猫技术窝”公众号的知识店铺内的训练营详情即可， + +具体可参见训练营目录下的《训练营专属服务》文档。简单来说，这个私人定制的面试VIP服务，会为你的跳槽面试全程保驾护航 + + + + +分布式系统 + +拆分为了多个子系统之后，各个系统之间如何通过Spring Cloud服务框架来进行调用，Dubbo框架来进行调用 + +![Dubbo核心架构原理](/docs/distributed-system/images/dubbo-framework-principle.png) +提供接口 + +服务注册中心： + +###消费者 + +#### 动态代理：Proxy +#### 负载均衡：Cluster，负载均衡，故障转移 +#### 注册中心：Registry +#### 通信协议：Protocol，filter机制，http、rmi、dubbo等协议 + +#### http、rmi、dubbo + +比如说，我现在其实想要调用的是，DemoService里的sayHello接口 + +你的请求用什么样的方式来组织发送过去呢？以一个什么样的格式来发送你的请求？ + +http，/demoService/sayHello?name=leo +rmi，另外一种样子 +dubbo，另外一种样子，interface=demoService|method=sayHello|params=name:leo + +信息交换：Exchange，Request和Response + +对于你的协议的格式组织好的请求数据，需要进行一个封装，Request + +##### 网络通信：Transport，netty、mina +##### 序列化：封装好的请求如何序列化成二进制数组，通过netty/mina发送出去 + +提供者 + +#### 网络通信：Transport，基于netty/mina实现的Server +#### 信息交换：Exchange，Response +#### 通信协议：Protocol，filter机制 +#### 动态代理：Proxy diff --git a/docs/distributed-system/dubbo-independent-framework.md b/docs/distributed-system/dubbo-independent-framework.md new file mode 100644 index 0000000..764ed05 --- /dev/null +++ b/docs/distributed-system/dubbo-independent-framework.md @@ -0,0 +1,10 @@ + +对**Dubbo**稍微做了一点进一步深入的讲解，但是远远是达不到精通源码的程度，只能说是相对于面试突击第一季要深入了一些，**Dubbo**一次服务请求调用，牵扯到了哪些组件，**负载均衡组件**、**注册中心**、**协议层**、**转换层**、**网络层（netty开发）**、**动态代理**，服务提供者也是类似的 + +网络通信的一些东西，是如何通过**NIO**的方式，**多线程**的方式，让一个服务提供者被多个服务消费者去并发的调用和请求 + +从整体架构原理的角度，说了一下如何进行扩展的 + +能说比普通的人稍微好一些，**技术深度**，那必须得是学其他的课程深入的理解他里面的源码，才能在面试的时候说，我精通一个技术的源码 + +**Dubbo底层架构原理的图**，自己手画出来，画的足够的熟练，如果有一些什么问题的话，可以提问 diff --git a/docs/distributed-system/dubbo-rock-bottom.md b/docs/distributed-system/dubbo-rock-bottom.md new file mode 100644 index 0000000..5121ba9 --- /dev/null +++ b/docs/distributed-system/dubbo-rock-bottom.md @@ -0,0 +1,27 @@ + +![Dubbo底层通信原理](/docs/distributed-system/images/dubbo-rock-bottom.png) +如果问到Dubbo底层原理，肯定除了上一讲的底层架构，你能说出来之外，还很可能会追问几个问题，网络通信这块原理的话 + +netty来举例，NIO来实现的，一台机器同时抗高并发的请求 + + + +**所以希望大家好好完成每天的作业，我布置的大量作业，就是为了帮你锻造出这种能力** + +**学习课程以及完成作业的过程中，大家一定会有很多的问题，可以到专栏的评论区去提问** + +**每天我都会和之前带出来的一批阿里、蚂蚁金服、滴滴的优秀同学给大家进行答疑，并且我们还有专门的付费用户的微信群，大家可以在微信群里跟我们一起进行技术交流** + +**如果你能坚持下来，学满6季，还可以获取私人定制的面试一条龙VIP服务** + +**如果是连续6季面试训练营都购买的同学，还可以获取面试一条龙VIP服务** + +**具体信息大家看“狸猫技术窝”公众号的知识店铺内的训练营详情即可** + +**具体可参见训练营目录下的《训练营专属服务》文档。简单来说，这个私人定制的面试VIP服务，会为你的跳槽面试全程保驾护航** + + + + + + diff --git a/docs/distributed-system/dubbo-vs-springCloud.md b/docs/distributed-system/dubbo-vs-springCloud.md new file mode 100644 index 0000000..d0d9477 --- /dev/null +++ b/docs/distributed-system/dubbo-vs-springCloud.md @@ -0,0 +1,46 @@ +底层架构原理是类似的 + +**Dubbo，RPC的性能比HTTP的性能更好，并发能力更强，经过深度优化的RPC服务框架，性能和并发能力是更好一些** + +很多中小型公司而言，其实稍微好一点的性能，**Dubbo一次请求10ms，Spring Cloud耗费20ms**，对很多中小型公司而言，性能、并发，并不是最主要的因素 + +**Spring Cloud这套架构原理，走HTTP接口和HTTP请求，就足够满足性能和并发的需要了，没必要使用高度优化的RPC服务框架** + + + +Dubbo之前的一个定位，就是一个单纯的服务框架而已，不提供任何其他的功能，配合的网关还得选择其他的一些技术 + +**Spring Cloud**，中小型公司用的特别多，老系统从**Dubbo迁移到Spring Cloud**，新系统都是用**Spring Cloud来进行开发，全家桶，主打的是微服务架构里，组件齐全，功能齐全。网关直接提供了，分布式配置中心，授权认证，服务调用链路追踪，Hystrix可以做服务的资源隔离、熔断降级、服务请求QPS监控、契约测试、消息中间件封装、ZK封装** + + +剩是剩在功能齐全，中小型公司开箱即用，直接满足系统的开发需求 + + +**Spring Cloud**原来支持的一些技术慢慢的未来会演变为，跟阿里技术体系进行融合，**Spring Cloud Alibaba**，阿里技术会融入**Spring Cloud**里面去 + + + + +**我们的课程每天都会有一个作业，引导大家把学习到的项目经验、技术方案和生产优化落地到自己负责的项目中去，让大家出去面试的时候，可以把各种技术结合自己的项目来回答面试官的各种深度拷问** + +**大家不要小看这个，根据我多年的面试经验来看，拥有这个技能的人凤毛麟角，这种人出去绝对是各大公司争抢的对象。** + +**我们的课程每天都会有一个作业，引导大家把学习到的项目经验、技术方案和生产优化落地到自己负责的项目中去，让大家出去面试的时候，可以把各种技术结合自己的项目来回答面试官的各种深度拷问** + +**大家不要小看这个，根据我多年的面试经验来看，拥有这个技能的人凤毛麟角，这种人出去绝对是各大公司争抢的对象。** + +**所以希望大家好好完成每天的作业，我布置的大量作业，就是为了帮你锻造出这种能力** + +**学习课程以及完成作业的过程中，大家一定会有很多的问题，可以到专栏的评论区去提问** + +**每天我都会和之前带出来的一批阿里、蚂蚁金服、滴滴的优秀同学给大家进行答疑，并且我们还有专门的付费用户的微信群，大家可以在微信群里跟我们一起进行技术交流** + +**如果你能坚持下来，学满6季，还可以获取私人定制的面试一条龙VIP服务** + +**如果是连续6季面试训练营都购买的同学，还可以获取面试一条龙VIP服务** + +**具体信息大家看“狸猫技术窝”公众号的知识店铺内的训练营详情即可** + +**具体可参见训练营目录下的《训练营专属服务》文档。简单来说，这个私人定制的面试VIP服务，会为你的跳槽面试全程保驾护航** + +**“狸猫技术窝”**，找到我们的训练营的详情页面 diff --git a/docs/distributed-system/dynamic-route.md b/docs/distributed-system/dynamic-route.md new file mode 100644 index 0000000..f416b29 --- /dev/null +++ b/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 + +生产级，企业级的功能，网关的动态路由 diff --git a/docs/distributed-system/gateway-high-concurrency.md b/docs/distributed-system/gateway-high-concurrency.md new file mode 100644 index 0000000..d401883 --- /dev/null +++ b/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)数据缓存 + + + + + + diff --git a/docs/distributed-system/gateway-model-selection.md b/docs/distributed-system/gateway-model-selection.md new file mode 100644 index 0000000..d24b052 --- /dev/null +++ b/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来开发高并发、高性能的网关系统，自己可以把控一切 + diff --git a/docs/distributed-system/gateway-technical.md b/docs/distributed-system/gateway-technical.md new file mode 100644 index 0000000..fda1b1e --- /dev/null +++ b/docs/distributed-system/gateway-technical.md @@ -0,0 +1,6 @@ + +服务框架的原理和技术选型，你们公司到底是怎么选，为什么？ + +服务注册中心，思考，你们公司到底是怎么选的，生产环境有没有做一些优化，如果没有，哪些地方是有优化空间的？ + +网关系统，思考，你们公司是怎么选型的，为什么？生产环境是否对类似动态路由的功能做过优化，如果没有是否有优化空间？ diff --git a/docs/distributed-system/gray-environment.md b/docs/distributed-system/gray-environment.md new file mode 100644 index 0000000..5f047ec --- /dev/null +++ b/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的负载均衡策略 + + + io.jmnarloch + ribbon-discovery-filter-spring-cloud-starter + 2.1.0 + + +写一个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 + + + diff --git a/docs/distributed-system/images/SpringCloud-core-architecture.png b/docs/distributed-system/images/SpringCloud-core-architecture.png new file mode 100755 index 0000000..035871a Binary files /dev/null and b/docs/distributed-system/images/SpringCloud-core-architecture.png differ diff --git a/docs/distributed-system/images/dubbo-framework-principle.png b/docs/distributed-system/images/dubbo-framework-principle.png new file mode 100755 index 0000000..951b300 Binary files /dev/null and b/docs/distributed-system/images/dubbo-framework-principle.png differ diff --git a/docs/distributed-system/images/dubbo-rock-bottom.png b/docs/distributed-system/images/dubbo-rock-bottom.png new file mode 100755 index 0000000..8260d2f Binary files /dev/null and b/docs/distributed-system/images/dubbo-rock-bottom.png differ diff --git a/docs/distributed-system/images/eureka-register.png b/docs/distributed-system/images/eureka-register.png new file mode 100755 index 0000000..1fd7f75 Binary files /dev/null and b/docs/distributed-system/images/eureka-register.png differ diff --git a/docs/distributed-system/images/gateway-high-concurrency.png b/docs/distributed-system/images/gateway-high-concurrency.png new file mode 100755 index 0000000..9bcabb0 Binary files /dev/null and b/docs/distributed-system/images/gateway-high-concurrency.png differ diff --git a/docs/distributed-system/images/registration-center-optimize.png b/docs/distributed-system/images/registration-center-optimize.png new file mode 100755 index 0000000..3fec6a5 Binary files /dev/null and b/docs/distributed-system/images/registration-center-optimize.png differ diff --git a/docs/distributed-system/images/springCloud-study-theory.png b/docs/distributed-system/images/springCloud-study-theory.png new file mode 100755 index 0000000..35fc87b Binary files /dev/null and b/docs/distributed-system/images/springCloud-study-theory.png differ diff --git a/docs/distributed-system/images/zookeeper-register.png b/docs/distributed-system/images/zookeeper-register.png new file mode 100755 index 0000000..b9a8018 Binary files /dev/null and b/docs/distributed-system/images/zookeeper-register.png differ diff --git a/docs/distributed-system/interface-idempotence.md b/docs/distributed-system/interface-idempotence.md new file mode 100644 index 0000000..8062013 --- /dev/null +++ b/docs/distributed-system/interface-idempotence.md @@ -0,0 +1,84 @@ + +接口幂等性实现起来非常的简单，不打算带着大家手写代码 + +（1）数据库唯一索引 +（2）基于Redis实现一套幂等性防重框架 + + + +对于插入类的操作，一般都是建议大家要在数据库表中设计一些唯一索引 + + +你如果有一个订单被支付了，此时就要通知wms创建一个对应发货单，也是数据库里的一个表，仓库里的人会看到这个发货单，此时他就会根据发货单的信息从仓库里进行拣货，打包，封装，交给物流公司 + + + +发货单 + +id order_id 订单金额 发货地址 xxxx + +对order_id就可以建立一个唯一索引，你插入发货单的时候，同一个order_id最多只能对应一个发货单，不可能说同样的一个order_id对应了多个发货单 + + +订单服务 -> wms服务，出现了重试，导致第二次请求再次让人家创建这个订单的发货单，create语句，order_id触发了唯一索引约束 + + + + + +扣减库存、累加积分，更新，很难通过数据库唯一索引来保证 + + +基于Redis实现一套接口的防重框架 + +你得做一个类似spring mvc里的拦截器这样的东西，在这个拦截器里，他会拦截所有的请求，对所有的请求都会提取请求对应的参数，GET请求、POST请求、PUT请求，有些参数是跟在URL地址里的，?xx=xx&xx=xx + +POST、PUT，可能是请求体里的，可能是一个JSON格式 + +把参数拼接在一起，作为key去redis中判断一下，是否存在这个key，之前附加这些参数的请求是否发起过，如果没有的话，此时就可以把这些参数+接口名称，作为一个key，存储到redis中去 + +然后呢，把请求放行，去执行这个请求 + +如果说人家重试再次发起一个这个请求，此时就可以判断出来，参数组成的key在redis中已经存在了，此时就不让执行这个请求了，认为是重复调用了 + + + + + +考虑很多问题，幂等不幂等，通用框架，需要一个公司所有的接口都按照指定的参数来传递，还有很多业务语义的问题 + +第一次发起一个请求，直接把请求key放入redis，但是他执行的过程中失败了，而且还阻塞了一段时间，此时人家再次重试发起第二次请求，这个时候按照上述的框架逻辑，就会把请求拦截下来了 + + +到底是不是要对所有接口都开启这么一个东西呢？ + + +每个接口如果执行成功了之后，我可以设置一个每个接口调用的时候执行成功之后，做一个后拦截器，如果成功了，就把请求对应的参数拼接为key放入redis中 + +有没有可能是第一次请求发送过来，在执行过程中，时间长了，比如需要1.3秒才执行完毕；此时人家发现超过1s了，直接重试，第二次请求过来了，也在正常的执行 + +第一次请求1.3秒之后执行成功了，第二次请求也执行成功了 + +只要一个服务希望对自己的接口开启幂等性防重功能，就把你开发好的拦截器对应的jar包，通过maven引入一个依赖就可以了 + + + +中大型互联网公司里也没做一个统一的防重幂等框架，其实一般都是各个服务对自己核心的接口，如果要保证幂等性的话，每个服务根据自己的业务逻辑来实现，而且仅仅是对少数核心接口做幂等性保障 + + +核心接口，库存服务，扣减库存接口 + +定制化的去针对接口开发幂等性的机制，比如说一旦库存扣减成功之后，就立马要写一条数据到redis里去，order_id_11356_stock_deduct，写入redis中，如果写入成功，就说明之前这个订单的库存扣减，没人执行过 + +但是如果此时有一些重试的请求过来了，调用了你的库存扣减接口，他同时也进行了库存的扣减，但是他用同样的一个key，order_id_11356_stock_deduct，写入redis中，此时会发现已经有人写过key，key已经存在了 + +此时你就应该直接对刚才的库存扣减逻辑做一个反向的回滚逻辑，update product_stock set stock = stock - 100，update product_stock set stock = stock + 100，反向逻辑，回滚掉，自己避免说重复扣减库存 + + + + + + +核心接口，幂等性都是自己保证的，人家可能会重试调用你的接口，对于create类的操作，用唯一索引来保证；对update类的操作，建议在核心接口里基于自己的业务逻辑，配合上redis，来保证幂等性 + + diff --git a/docs/distributed-system/register-high-availability.md b/docs/distributed-system/register-high-availability.md new file mode 100644 index 0000000..e69de29 diff --git a/docs/distributed-system/register-production-optimize.md b/docs/distributed-system/register-production-optimize.md new file mode 100644 index 0000000..5872fec --- /dev/null +++ b/docs/distributed-system/register-production-optimize.md @@ -0,0 +1,34 @@ + +#### 分布式系统架构的 + +**服务注册中心，eureka、zk、consul，原理画图画清楚** + +**数据一致性，CP、AP** + +服务注册、故障 和发现的时效性是多长时间 + +注册中心最大能支撑多少服务实例 + +如何部署的，几台机器，每台机器的配置如何，会用比较高配置的机器来做，8核16G，16核32G的高配置机器来搞，基本上可以做到每台机器每秒钟的请求支撑几千绝对没问题 + +可用性如何来保证 + +**有没有做过一些优化，服务注册、故障以及发现的时效性，是否可以优化一下，用eureka的话，可以尝试一下，配合我们讲解的那些参数，优化一下时效性，服务上线、故障到发现是几秒钟的时效性** + +**zk，一旦服务挂掉，zk感知到以及通知其他服务的时效性，服务注册到zk之后通知到其他服务的时效性，leader挂掉之后可用性是否会出现短暂的问题，为了去换取一致性** + + +**所以希望大家好好完成每天的作业，我布置的大量作业，就是为了帮你锻造出这种能力** + +**学习课程以及完成作业的过程中，大家一定会有很多的问题，可以到专栏的评论区去提问** + +**每天我都会和之前带出来的一批阿里、蚂蚁金服、滴滴的优秀同学给大家进行答疑，并且我们还有专门的付费用户的微信群，大家可以在微信群里跟我们一起进行技术交流** + +**如果你能坚持下来，学满6季，还可以获取私人定制的面试一条龙VIP服务** + +**如果是连续6季面试训练营都购买的同学，还可以获取面试一条龙VIP服务** + +**具体信息大家看“狸猫技术窝”公众号的知识店铺内的训练营详情即可** + +**具体可参见训练营目录下的《训练营专属服务》文档。简单来说，这个私人定制的面试VIP服务，会为你的跳槽面试全程保驾护航** + diff --git a/docs/distributed-system/registration-center- guide.md b/docs/distributed-system/registration-center- guide.md new file mode 100644 index 0000000..bc1559a --- /dev/null +++ b/docs/distributed-system/registration-center- guide.md @@ -0,0 +1,54 @@ + +非常常见的一个技术面试题，但凡只要是聊到分布式这块，一定会问问你，**Dubbo，Spring Cloud，服务注册中心**，你们当时是怎么选型和调研的，你们最终是选择了哪块技术呢？你选择这块技术的原因和理由是什么呢？ + +**Eureka、ZooKeeper** + +**Dubbo**作为服务框架的，一般注册中心会选择zk + +**Spring Cloud**作为服务框架的，**一般服务注册中心会选择Eureka** + +**Consul、Nacos，**普及型还没那么广泛，我会在面试训练营课程里增加对应的内容，给大家去进行补充 + +#### (1)服务注册发现的原理 + +集群模式 +![ZooKeeper](/docs/distributed-system/images/eureka-register.png) + +**Eureka，peer-to-pee**r，部署一个集群，**但是集群里每个机器的地位是对等的，各个服务可以向任何一个Eureka实例服务注册和服务发现，集群里任何一个Euerka实例接收到写请求之后，会自动同步给其他所有的Eureka实例** +![ZooKeeper](/docs/distributed-system/images/zookeeper-register.png) + +**ZooKeeper，服务注册和发现的原理，Leader + Follower两种角色，只有Leader可以负责写也就是服务注册，他可以把数据同步给Follower，读的时候leader/follower都可以读** + +#### (2)一致性保障：CP or AP + +**CAP，C是一致性，A是可用性，P是分区容错性** + +**CP，AP** + +**ZooKeeper是有一个leader节点会接收数据， 然后同步写其他节点，一旦leader挂了，要重新选举leader，这个过程里为了保证C，就牺牲了A，不可用一段时间，但是一个leader选举好了，那么就可以继续写数据了，保证一致性** + +Eureka是peer模式，可能还没同步数据过去，结果自己就死了，此时还是可以继续从别的机器上拉取注册表，但是看到的就不是最新的数据了，但是保证了可用性，强一致，最终一致性 + +（3）服务注册发现的时效性 + +zk，时效性更好，注册或者是挂了，一般秒级就能感知到 + +eureka，默认配置非常糟糕，服务发现感知要到几十秒，甚至分钟级别，上线一个新的服务实例，到其他人可以发现他，极端情况下，可能要1分钟的时间，ribbon去获取每个服务上缓存的eureka的注册表进行负载均衡 + +服务故障，隔60秒才去检查心跳，发现这个服务上一次心跳是在60秒之前，隔60秒去检查心跳，超过90秒没有心跳，才会认为他死了，2分钟都过去 + +30秒，才会更新缓存，30秒，其他服务才会来拉取最新的注册表 + +三分钟都过去了，如果你的服务实例挂掉了，此时别人感知到，可能要两三分钟的时间，一两分钟的时间，很漫长 + +#### (4)容量 + +zk，不适合大规模的服务实例，因为服务上下线的时候，需要瞬间推送数据通知到所有的其他服务实例，所以一旦服务规模太大，到了几千个服务实例的时候，会导致网络带宽被大量占用 + +eureka，也很难支撑大规模的服务实例，因为每个eureka实例都要接受所有的请求，实例多了压力太大，扛不住，也很难到几千服务实例 + +之前dubbo技术体系都是用zk当注册中心，spring cloud技术体系都是用eureka当注册中心这两种是运用最广泛的，但是现在很多中小型公司以spring cloud居多，所以后面基于eureka说一下服务注册中心的生产优化 + +（5）多机房、多数据中心、健康检查 + + diff --git a/docs/distributed-system/registration-center-optimize.md b/docs/distributed-system/registration-center-optimize.md new file mode 100644 index 0000000..ffe41c5 --- /dev/null +++ b/docs/distributed-system/registration-center-optimize.md @@ -0,0 +1,6 @@ + +![分布式注册中心](/docs/distributed-system/images/registration-center-optimize.png) +#### eureka：peer-to-peer，每台机器都是高并发请求，有瓶颈 +#### zookeeper：服务上下线，全量通知其他服务，网络带宽被打满，有瓶颈 + +#### 分布式服务注册中心，分片存储服务注册表，横向扩容，每台机器均摊高并发请求，各个服务主动拉取，避免反向通知网卡被打满 diff --git a/docs/distributed-system/request-retry.md b/docs/distributed-system/request-retry.md new file mode 100644 index 0000000..7ae9e59 --- /dev/null +++ b/docs/distributed-system/request-retry.md @@ -0,0 +1,16 @@ + +订单服务 -> 创建订单 + + -> 库存服务 -> 扣减库存 + -> wms服务 -> 通知发货 + -> 积分服务 -> 增加积分 + +订单服务调用库存服务的时候，因为网络抖动，请求超时了，超过了秒钟，此时订单服务会重试，再次调用一下库存服务，发送一模一样的请求过去 + + + +比如说，订单服务第一次请求库存服务，库存服务其实是把扣减库存的业务逻辑执行成功了，只不过网络问题，导致响应迟迟没有返回给订单服务，可能在1.2s之后返回了响应给订单服务 + +订单服务就认为请求超时了，他就再次发送了一个一模一样的请求给库存服务，库存服务可能会再次对库存进行扣减 + + diff --git a/docs/distributed-system/rpc-design.md b/docs/distributed-system/rpc-design.md new file mode 100644 index 0000000..d2294f4 --- /dev/null +++ b/docs/distributed-system/rpc-design.md @@ -0,0 +1,59 @@ +这个面试题还是挺常见的，在面试突击第一季里，基本上带了一下，当时但是没有细讲，是因为当时面试突击第一季里对服务框架的原理没有做一个相对深入一点点的分析，当时主要就是讲了一些最基本的概念 + +人家并不是要你手撸一个**RPC框架**，资料，现场手撸一个**RPC框架**，撸的特别的简单，人家也不是要你手撸，也不是说让你进来了以后就是让你来研发RPC框架的 + +系统设计的问题，就是让你站在系统设计的角度，来考虑一下，到底如果要设计一个RPC框架，你会如何来考虑 + +动态代理：比如消费者和提供者，其实都是需要一个实现某个接口的动态代理的，RPC框架的一切的逻辑细节，都是在这个动态代理中实现的，动态代理里面的代码逻辑就是你的RPC框架核心的逻辑 + +JDK提供了API，去创建针对某个接口的动态代理 + +调用动态代理对象的方法之后，此时就应该先干一个事情，通过Cluster层的一些组件，服务注册中心，是用什么技术来进行实现呢？往简单了说，服务注册中心也可以是你自己手撸一个，也不难 + +自己手撸一个，服务去注册，其他服务去拉取注册表进行发现 + +**ZooKeeper**，稍微自己上网百度搜索一下，**ZooKeeper**入门使用教程，基本概念和原理，还有基本的使用，了解一下 + +**Cluster层**，从本地缓存的服务注册表里获取到要调用的服务的机器列表 + +**负载均衡**，**面试突击第一季**里，我们分析过**Dubbo的负载均衡策略**，此时你就可以把那些策略说一说，我要设计多少种策略，从服务的机器列表中采用负载均衡算法从里面选择出来一台机器 + +选择好了机器，知道了对方的端口号，而且知道你的请求调用，调用哪个Interface的哪个方法，把这些信息交给协议层 + +把数据组织一下，**协议**，**序列化机制**，**底层用什么网络通信框架**，比如**netty，mina**现在用的比较少，序列化和反序列化有没有概念，**Java基础概念，一个复杂的请求数据序列化成二进制的字节数组** + +**反序列化就是从字节数组变成请求数据结构** + +按照那个协议的规范对请求数据进行组织，不同的协议，组织出来的数据看起来是不一样的 + +**netty基本的原理** + +解析完毕了之后，就知道，应该调用自己本地哪个Interface的实现类的哪个方法 + + + +**我们的课程每天都会有一个作业，引导大家把学习到的项目经验、技术方案和生产优化落地到自己负责的项目中去，让大家出去面试的时候，可以把各种技术结合自己的项目来回答面试官的各种深度拷问** + +**大家不要小看这个，根据我多年的面试经验来看，拥有这个技能的人凤毛麟角，这种人出去绝对是各大公司争抢的对象。** + +**我们的课程每天都会有一个作业，引导大家把学习到的项目经验、技术方案和生产优化落地到自己负责的项目中去，让大家出去面试的时候，可以把各种技术结合自己的项目来回答面试官的各种深度拷问** + +**大家不要小看这个，根据我多年的面试经验来看，拥有这个技能的人凤毛麟角，这种人出去绝对是各大公司争抢的对象。** + +**所以希望大家好好完成每天的作业，我布置的大量作业，就是为了帮你锻造出这种能力** + +**学习课程以及完成作业的过程中，大家一定会有很多的问题，可以到专栏的评论区去提问** + +**每天我都会和之前带出来的一批阿里、蚂蚁金服、滴滴的优秀同学给大家进行答疑，并且我们还有专门的付费用户的微信群，大家可以在微信群里跟我们一起进行技术交流** + +**如果你能坚持下来，学满6季，还可以获取私人定制的面试一条龙VIP服务** + +**如果是连续6季面试训练营都购买的同学，还可以获取面试一条龙VIP服务** + +**具体信息大家看“狸猫技术窝”公众号的知识店铺内的训练营详情即可** + +**具体可参见训练营目录下的《训练营专属服务》文档。简单来说，这个私人定制的面试VIP服务，会为你的跳槽面试全程保驾护航** + +**“狸猫技术窝”**，找到我们的训练营的详情页面 + + diff --git a/docs/distributed-system/service-register-discovery.md b/docs/distributed-system/service-register-discovery.md new file mode 100644 index 0000000..d9ca3fe --- /dev/null +++ b/docs/distributed-system/service-register-discovery.md @@ -0,0 +1,14 @@ + +**zk，一般来说还好，服务注册和发现，都是很快的** + +**eureka，必须优化参数** + +**eureka.server.responseCacheUpdateIntervalMs = 3000** +**eureka.client.registryFetchIntervalSeconds = 30000** + +**eureka.client.leaseRenewalIntervalInSeconds = 30** +**eureka.server.evictionIntervalTimerInMs = 60000** +**eureka.instance.leaseExpirationDurationInSeconds = 90** + +**服务发现的时效性变成秒级，几秒钟可以感知服务的上线和下线** + diff --git a/docs/distributed-system/service-register-gateway-router.md b/docs/distributed-system/service-register-gateway-router.md new file mode 100644 index 0000000..a65167b --- /dev/null +++ b/docs/distributed-system/service-register-gateway-router.md @@ -0,0 +1,12 @@ + +#### 生产环境，微服务生产实践 + +开发了一个新的服务，线上部署，配合网关动态路由的功能，在网关里配置一下路径和新服务的映射关系，此时请求过来直接就可以走到新的服务里去 + +对已有服务进行迭代和开发，新版本，灰度发布，新版本部署少数几台机器，通过一个界面，开启这个服务的灰度发布，**此时zuul filter启用，按照你的规则，把少量的流量打入到新版本部署的机器上去** + +观察一下少量流量在新版本的机器上运行是否正常 + +版本改成current，全量机器部署，关闭灰度发布功能，网关就会把流量均匀分发给那个服务了 + + diff --git a/docs/distributed-system/service-request-time-out.md b/docs/distributed-system/service-request-time-out.md new file mode 100644 index 0000000..4a14374 --- /dev/null +++ b/docs/distributed-system/service-request-time-out.md @@ -0,0 +1,76 @@ + +分布式系统，拆分为很多个服务之后，他们互相之间要进行调用，平时服务内要优化的一些参数其实不多，服务与服务之间的调用，会不会出现调用的超时，每个服务超时的时间是多长，超时之后是否要进行重试，重试几次 + +高可用，hystrix进行资源隔离、熔断、降级，zuul网关层直接进行限流 + + +网关 ->（卡住） 订单服务 ->（卡住） wms服务 + +网关收到的一个http响应，可能就是一个500，internal error + + + + + +Spring Cloud生产优化，系统第一次启动的时候，人家调用你经常会出现timeout + +每个服务第一次被请求的时候，他会去初始化一个Ribbon的组件，初始化这些组件需要耗费一定的时间，所以很容易会导致。让每个服务启动的时候就直接初始化Ribbon相关的组件，避免第一次请求的时候初始化 + +``` +ribbon: + eager-load: + enabled: true + + +zuul: + ribbon: + eager-load: + enabled: true + +feign: + hystrix: +enabled: false + +``` + +我们刚才启动了wms服务之后，其实订单服务和积分服务、wms服务、库存服务之间的请求都是没问题的，日志全部都打印出来了，不会说第一次请求因为ribbon加载过慢导致请求失败的问题 + +但是zuul网关层面去请求订单服务的时候，他还是可能会认为自己超时了，windows电脑上跑这样的一套系统，网络请求都是比较慢的，因为你有很多服务与服务之间的调用，order和另外3个服务一套交互下来，比如超过了1秒钟 + +zuul而言感觉耗时太久了，还是会认为是超时的 + +windows电脑走的都是家用网络，我家里的网络情况不是太好，网卡，网速慢，信号弱 + + + + +线上的服务，每个服务部署上线的时候，一般来说都需要配置相关的超时时间还有重试次数 + +订单服务 -> 积分服务、库存服务、仓促服务 + +订单服务对于其他服务的调用，一般来说限制在多长时间就必须认为是超时了，如果超时之后如何进行重试 + +积分服务部署了两台机器，机器1和机器2 + +订单服务在一次请求积分服务的机器1的时候，超过1秒钟，超时了；此时需要进行重试，对积分服务当前的这台机器1重试几次？如果说机器1不行，是否可以重试一下积分服务的机器2？ + + +``` +ribbon: + ConnectTimeout: 3000 + ReadTimeout: 3000 + OkToRetryOnAllOperations: true + MaxAutoRetries: 1 + MaxAutoRetriesNextServer: 1 + +中小型的系统，没必要直接开启hystrix，资源隔离、熔断、降级，如果你没有设计好一整套系统高可用的方案 + +zuul请求一个订单服务，超过1秒就认为超时了，此时会先重试一下订单服务这台机器，如果还是不行就重试一下订单服务的其他机器 + + +org.springframework.retry +spring-retry + + +hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=10000 +``` \ No newline at end of file diff --git a/docs/distributed-system/springCloud-and-rpc-framework.md b/docs/distributed-system/springCloud-and-rpc-framework.md new file mode 100644 index 0000000..92eb4b6 --- /dev/null +++ b/docs/distributed-system/springCloud-and-rpc-framework.md @@ -0,0 +1,10 @@ + +### 1、作业1 + +**把RPC框架如何设计，这个问题，你把整体思路去屡一下，对应的一些细节，很多可以参考之前面试突击第一季的，还有一些网络通信框架，netty，找一些资料，补充了解一些细节，包括动态代理** + +序列化协议 + +### 2、作业2 + +**不看资料，手画Spring Cloud底层原理，Eureka** diff --git a/docs/distributed-system/springCloud-study-theory.md b/docs/distributed-system/springCloud-study-theory.md new file mode 100644 index 0000000..6735eb3 --- /dev/null +++ b/docs/distributed-system/springCloud-study-theory.md @@ -0,0 +1,41 @@ +问你**Dubbo底层架构原理**是一样的，不求你说能看过**Spring Cloud的源码**，单单就是说搞明白他的一些底层架构原理，也是不错的 + +![Eureka服务注册中心的原理](/docs/distributed-system/images/springCloud-study-theory.png) +**Eureka、Ribbon、Feign、Zuul** + +就是优化并发冲突 + +如果你基于**Spring Cloud**对外发布一个接口，实际上就是支持**http协议**的，对外发布的就是一个最最普通的**Spring MVC的http接口** + +**feign**，他是对一个接口打了一个注解，他一定会针对这个注解标注的接口生成动态代理，然后你针对feign的动态代理去调用他的方法的时候，此时会在底层生成http协议格式的请求，/order/create?productId=1 + +底层的话，使用HTTP通信的框架组件，**HttpClient**，**先得使用Ribbon去从本地的Eureka注册表的缓存里获取出来对方机器的列表，然后进行负载均衡，选择一台机器出来，接着针对那台机器发送Http请求过去即可** + +配置一下不同的请求路径和服务的对应关系，你的请求到了网关，他直接查找到匹配的服务，然后就直接把请求转发给那个服务的某台机器，**Ribbon从Eureka本地的缓存列表里获取一台机器，负载均衡，把请求直接用HTTP通信框架发送到指定机器上去** + + + +**我们的课程每天都会有一个作业，引导大家把学习到的项目经验、技术方案和生产优化落地到自己负责的项目中去，让大家出去面试的时候，可以把各种技术结合自己的项目来回答面试官的各种深度拷问** + +**大家不要小看这个，根据我多年的面试经验来看，拥有这个技能的人凤毛麟角，这种人出去绝对是各大公司争抢的对象。** + +**我们的课程每天都会有一个作业，引导大家把学习到的项目经验、技术方案和生产优化落地到自己负责的项目中去，让大家出去面试的时候，可以把各种技术结合自己的项目来回答面试官的各种深度拷问** + +**大家不要小看这个，根据我多年的面试经验来看，拥有这个技能的人凤毛麟角，这种人出去绝对是各大公司争抢的对象。** + +**所以希望大家好好完成每天的作业，我布置的大量作业，就是为了帮你锻造出这种能力** + +**学习课程以及完成作业的过程中，大家一定会有很多的问题，可以到专栏的评论区去提问** + +**每天我都会和之前带出来的一批阿里、蚂蚁金服、滴滴的优秀同学给大家进行答疑，并且我们还有专门的付费用户的微信群，大家可以在微信群里跟我们一起进行技术交流** + +**如果你能坚持下来，学满6季，还可以获取私人定制的面试一条龙VIP服务** + +**如果是连续6季面试训练营都购买的同学，还可以获取面试一条龙VIP服务** + +**具体信息大家看“狸猫技术窝”公众号的知识店铺内的训练营详情即可** + +**具体可参见训练营目录下的《训练营专属服务》文档。简单来说，这个私人定制的面试VIP服务，会为你的跳槽面试全程保驾护航** + +**“狸猫技术窝”**，找到我们的训练营的详情页面 + diff --git a/docs/distributed-system/system-dilatation.md b/docs/distributed-system/system-dilatation.md new file mode 100644 index 0000000..cbfbd00 --- /dev/null +++ b/docs/distributed-system/system-dilatation.md @@ -0,0 +1,12 @@ + +如果访问量扩大10倍，如何扩容？ + +网关直接多部署10倍的机器即可，前面的Nginx做会负载均衡，把流量均匀分发给各个网关机器 + +服务扩容，都很简单的，多加机器，部署启动，自动注册到注册中心里去，此时其他服务会自动感知到你的服务多加了一些机器 + +服务实例变多了10倍，此时几十个服务实例，几百个服务实例，对eureka机器会造成每秒几百请求，没问题，eureka机器，8核16G的配置，单机抗上千请求，很轻松 + +数据库本来是每秒几百请求，10倍，每秒高峰期是三四千请求，横向扩容很麻烦，此时可以考虑给单个数据库部署的机器提高配置，32核128G高配物理机，每秒钟抗几千请求问题不大 + + diff --git a/docs/distributed-system/system-framework.md b/docs/distributed-system/system-framework.md new file mode 100644 index 0000000..66a1f5f --- /dev/null +++ b/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负载很高，网络负载很高 + + + + + + + + + + diff --git a/docs/distributed-system/system-qps.md b/docs/distributed-system/system-qps.md new file mode 100644 index 0000000..eb4b910 --- /dev/null +++ b/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个请求 + + + + diff --git a/docs/distributed-system/tcc-framework-principle.md b/docs/distributed-system/tcc-framework-principle.md new file mode 100644 index 0000000..3fef3f9 --- /dev/null +++ b/docs/distributed-system/tcc-framework-principle.md @@ -0,0 +1,4 @@ + +面试突击第一季里仅仅是说了一下核心的一些思想 + +基于seata去跑分布式事务的，必须先独立去部署seata-server，TC diff --git a/docs/distributed-system/tcc-high-concurrence.md b/docs/distributed-system/tcc-high-concurrence.md new file mode 100644 index 0000000..7812420 --- /dev/null +++ b/docs/distributed-system/tcc-high-concurrence.md @@ -0,0 +1,23 @@ + +TCC框架，bytetcc，seata + +seata-server + +bytetcc，大家就是基于mysql里面创建一些表，基于表中的数据进行状态的更新 + + +核心链路中的各个服务都需要跟TC这个角色进行频繁的网络通信，频繁的网络通信其实就会带来性能的开销，本来一次请求不引入分布式事务只需要100ms，此时引入了分布式事务之后可能需要耗费200ms + + + +网络请求可能还挺耗时的，上报一些分支事务的状态给TC，seata-server，选择基于哪种存储来放这些分布式事务日志或者状态的，file，磁盘文件，MySQL，数据库来存放对应的一些状态 + + + + +高并发场景下，会不会有问题，seata-server，你也需要支持扩容，也需要部署多台机器，用一个数据库来存放分布式事务的日志和状态的话，假设并发量每秒上万，分库分表，对TC背后的数据库也会有同样的压力 + +这个时候对TC背后的db也得进行分库分表，抗更高的并发压力 + + + diff --git a/docs/distributed-system/tcc-landing-scheme.md b/docs/distributed-system/tcc-landing-scheme.md new file mode 100644 index 0000000..343657b --- /dev/null +++ b/docs/distributed-system/tcc-landing-scheme.md @@ -0,0 +1,81 @@ + + +训练营的课程目录里，有我之前的一些课程，在网上大家都可以去看 + +亿级流量电商详情页系统 +elasticsearch从入门到精通 + +针对某个技术领域手把手的教学，课程内容量非常的大，代码都是一行一行的写 + + +https://github.com/seata/seata + + +自己安装一个git bash，百度一下如何安装即可，在win上可以执行linux类的命令 + +然后自己建一个目录 + +git clone https://github.com/seata/seata-samples.git + +也可以直接在github页面上下载：https://github.com/seata/seata-samples，建议这种方式，比较快一点，git clone速度太慢了 + +就可以把seata所有的示例代码拷贝下来，里面提供的例子就是跟我们说的电商的核心例子是类似的，然后导入到Eclipse中去，这个过程会eclipse会通过maven下载很多的依赖，需要耐心等待 + +使用脚本初始化数据库 + +``` +CREATE TABLE `account_tbl` ( + `id` int(11) NOT NULL AUTO_INCREMENT, + `user_id` varchar(255) DEFAULT NULL, + `money` int(11) DEFAULT '0', + PRIMARY KEY (`id`) +) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8; + +CREATE TABLE `storage_tbl` ( + `id` int(11) NOT NULL AUTO_INCREMENT, + `commodity_code` varchar(255) DEFAULT NULL, + `count` int(11) DEFAULT '0', + PRIMARY KEY (`id`), + UNIQUE KEY `commodity_code` (`commodity_code`) +) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8; + +CREATE TABLE `order_tbl` ( + `id` int(11) NOT NULL AUTO_INCREMENT, + `user_id` varchar(255) DEFAULT NULL, + `commodity_code` varchar(255) DEFAULT NULL, + `count` int(11) DEFAULT '0', + `money` int(11) DEFAULT '0', + PRIMARY KEY (`id`) +) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8; + +CREATE TABLE `undo_log` ( + `id` bigint(20) NOT NULL AUTO_INCREMENT, + `branch_id` bigint(20) NOT NULL, + `xid` varchar(100) NOT NULL, + `context` varchar(128) NOT NULL, + `rollback_info` longblob NOT NULL, + `log_status` int(11) NOT NULL, + `log_created` datetime NOT NULL, + `log_modified` datetime NOT NULL, + `ext` varchar(100) DEFAULT NULL, + PRIMARY KEY (`id`), + UNIQUE KEY `ux_undo_log` (`xid`,`branch_id`) +) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8; +``` +然后先要下载一个seata-server到本地，在这里下载：https://github.com/seata/seata/releases，然后启动起来，这是分布式事务管理中心，负责维护每一个分布式事务的状态，触发分布式事务的提交和回滚 + +seata-server.bat -h 127.0.0.1 -p 8091 -m file + +直接把Spring Cloud版本的例子运行起来，观察一下依赖、配置和代码，以后自己在系统里使用直接仿照即可，eureka、account、order、storage、business，依次运行起来，修改一些配置，比如说数据库连接配置 + + +但是任何一个服务报错之后，seata这个分布式事务的框架会感知到，自动触发所有服务之前做的数据库操作全部进行回滚 + + +纯正的tcc框架，很麻烦，需要你手动把各种接口实现出来3个接口，try，confirm，cancel，bytetcc，纯的tcc框架，star + + + + + + diff --git a/docs/distributed-system/work-distributed-transaction.md b/docs/distributed-system/work-distributed-transaction.md new file mode 100644 index 0000000..e4d9d87 --- /dev/null +++ b/docs/distributed-system/work-distributed-transaction.md @@ -0,0 +1,7 @@ + + +你自己的系统，核心链路，是否存在数据不一致的问题，如果要设计分布式事务方案，如何设计，对分布式事务的技术如何选型，好好做一下，然后提交到狸猫技术窝，知识店铺，训练营里有作业本 + +完成作业的时候有任何疑问，可以提出来，我们每天会进行答疑 + +微信群，训练营的课程目录里有一个文档 diff --git a/docs/distributed-system/work-interface-idempotence.md b/docs/distributed-system/work-interface-idempotence.md new file mode 100644 index 0000000..7fc72cd --- /dev/null +++ b/docs/distributed-system/work-interface-idempotence.md @@ -0,0 +1,17 @@ + +分布式系统，考察生产实践细节，常问的面试问题 + +服务框架、注册中心、网关系统、部署架构、超时重试、幂等性 + + +跟你自己的业务系统有关系了，你们的系统服务之间的调用，有没有超时和重试的配置，如果没有，如何优化配置，如果有，核心接口有没有幂等性机制，重复插入数据，重复跟新数据 + +如果有问题，结合你的业务，如何基于唯一索引、redis定制化防重机制 + + +可以在评论区提问，我们会给大家答疑，狸猫技术窝，知识店铺，训练营页面里，有评论区，提问，答疑 + +好好的完成作业，在作业里设计自己的系统业务逻辑对应的一套幂等性机制，每天的作业，都是可以提交，你可以把作业提交到店铺里去，每天我们都会给你们提交的作业进行点评，对你们作业里的问题进行答疑 + + +付费微信交流群，课程目录里有一个文档，入群步骤 diff --git a/docs/distributed-system/work-register.md b/docs/distributed-system/work-register.md new file mode 100644 index 0000000..5afd505 --- /dev/null +++ b/docs/distributed-system/work-register.md @@ -0,0 +1,13 @@ + +#### Dubbo框架原理 +#### Spring Cloud框架原理 +#### 服务框架的技术选型 + +#### 服务注册中心技术选型和核心原理 +#### 生产优化 +#### 架构优化 + +#### 网关系统技术选型和核心原理 +#### 生产优化（灰度发布、动态路由） + +#### 生产级的分布式系统里，新服务开发如何做，老服务迭代如何做 diff --git a/docs/distributed-system/work-system-dilatation.md b/docs/distributed-system/work-system-dilatation.md new file mode 100644 index 0000000..de45a64 --- /dev/null +++ b/docs/distributed-system/work-system-dilatation.md @@ -0,0 +1,2 @@ + +部署，机器配置，大概能抗多少并发；流量、QPS、性能，metrics；压测，借助一些小工具；扩容方案，横向加机器，还是说纵向提升机器的配置 diff --git a/docs/distributed-system/work-tcc-landing-scheme.md b/docs/distributed-system/work-tcc-landing-scheme.md new file mode 100644 index 0000000..acd4acd --- /dev/null +++ b/docs/distributed-system/work-tcc-landing-scheme.md @@ -0,0 +1,2 @@ + +大家按照我提示的思路，参考人家的sample，尝试把seata分布式事务框架整合到spring cloud技术架构里去，把这个东西跑出来，如果遇到了问题之后，可以上seata github提issue，问人家怎么回事