BJ1123-Summary/第1阶段-项目架构.md

1 项目架构图

画图三次

1. 公司申请域名完成备案： api.atguigu.com 39.52.61.10 DNS域名解析服务器（114.114.114.114,8.8.8.8,....其他DNS服务器）

2. 将Nginx/Ingress部署到公网服务器39.52.61.10，域名监听api.atguigu.com将域名下请求转发到service（Gateway网关）>service(业务模块)

整个项目的技术栈是基于springboot+springcloud分布式架构

2 项目技术栈

• SpringBoot：简化Spring应用的初始搭建以及开发过程
• SpringCloud：基于Spring Boot实现的云原生应用开发工具，SpringCloud使用的技术：（Spring Cloud Gateway、Spring Cloud Task和Spring Cloud Feign等）
• SpringBoot+SpringCloudAlibaba(Nacos，Sentinel)+Cloud OpenFeign
• MyBatis-Plus：持久层框架，也依赖mybatis
• Redis：内存做缓存
  • 缓存业务数据
  • 各种分类数据、专辑、用户：采用String类型
  • ：采用String
  • 分布式锁：采用Hash Key:锁名称 field：线程标识 value：重入次数
  • 布隆过滤器：
  • Hash 存储布隆过滤器配置：1.期望数据规模 2.误判率3.hash个数 4.bitmap长度
  • bitmap:位图
  • 延迟队列：
  • 采用List：阻塞队列
  • 采用Zset：存储需要投递消息过期时间，消息
  • 发布订阅（消息队列）
  • pub/sub
• Redisson：基于redis的Java驻内存数据网格 - 框架；操作redis的框架
• MongoDB: 分布式文件存储的数据库：存放声音播放进度、评论、收藏声音、点赞、订阅专辑等
  • 数据量大
  • 数据价值低
  • 业务相对独立
  • 需求变动频繁，需要增加减少字段
  • 不需要强事务支持
• Kafka：消息中间件；大型分布式项目是标配；分布式事务最终一致性
  • 用户注册隐式初始化账户
  • 专辑数据上下架同步（MySQL跟ES数据同步）
  • 更新专辑/声音相同统计信息
• ElasticSearch+Kibana+Logstash/Filebeat 全文检索服务器+可视化数据监控：检索
• ThreadPoolExecutor/ThreadPoolTaskExecutor+CompletableFuture：线程池来实现异步操作，提高效率
• xxl-Job: 分布式定时任务调用中心
• Knife4J/YAPI：Api接口文档工具
• MinIO（私有化对象存储集群）：分布式文件存储 类似于OSS（公有）
• 微信支付：
• MySQL：关系型数据库 {shardingSphere-jdbc 进行读写分离; 分库，分表}
• Lombok: 实体类的中get/set 生成的jar包
• natapp：内网穿透
• Docker：容器化技术; 生产环境Redis（运维人员）；快速搭建环境Docker run
• Git：代码管理工具；git使用，拉代码、提交、推送、合并、冲突解决
• jenkins

前端技术栈

• UniApp
• Vue3全家桶
• TypeScript
• GraceUI
• UniUI
• uniapp-axios-adapter

3 项目功能模块

模块名称	模块描述
分类管理	实现专辑分类
专辑模块	实现专辑模块基本功能
声音管理	实现声音管理、声音详情
搜索模块	首页搜索、关键字补全、批量上架、下架等功能
详情模块	实现专辑详情
直播模块	实现主播直播互动等功能
登录模块	实现微信登录
充值管理	实现用户充值，余额支付等功能
支付模块	实现小程序支付、余额支付
客服模块	实现售后服务等

4 架构常见问题

1.服务器数量

影响服务器数量的因素有哪些?

需求量

性能层面-(服务器基础配置)

负载均衡: 模块数*2

可扩展性和弹性

成本预算

监控

思路: 回答这个问题主要是展示出你在服务器数量决策方面的专业知识 而不是说一个具体的服务器数量

2.介绍功能模块

这块面试官的问法不同，有的会让你从你负责的模块中，挑选一个你认为做的最好的或者有亮点的模块去说，有的面试官是把你负责的模块问个遍，所以只要你简历上写了是你负责的模块，一定要去弄的非常熟练，如果你自己做的东西，你都不知道，那对于整个项目来说也就没必要再问了，所以这块是重点。在介绍自己负责的功能模块时。

可以准备哪些模块：

专辑模块、声音模块、认证模块（微信小程序登录）、订单模块、支付模块（微信支付、余额支付）、搜索模块、账户管理

如何选择模块：熟练的、技术涉及多的（redis、kafka）4个模块

回答问题标准：

1、背景

2、面临问题：业务&技术实际问题&解决方案

3、结果（项目、自我（复盘））

3.上线后QPS，用户量、同时在线人数 并发数等问题

并发量: 通常指的是一个系统或应用在任何给定时刻能够同时处理的用户请求或事务的数量

• QPS：每秒查询数量
• TPS：每秒事务数量

​ 话术:

​ 在高峰时段，我们的系统能够处理每秒1000多个并发请求（部署3~5个实例）

​ 在低峰时段, 我们的系统能够处理每秒200-300多个并发请求（部署1~2个实例）

​ 如何检测:

​ 通常涉及一系列性能测试和监控策略 （压力负载测试工具）JMeter Arthas（阿里巴巴监控JVM工具）

用户量:

​ 1,user表中有多少数据 20-50W

​ 2,用户并发量:指同时在线或活跃的用户数量

​ 一般来说，如果我们假设每个用户平均每秒发起一个请求，那么在峰值并发量为1000的情况下，理论上可以支

持1000个并发用户。然而，实际情况可能会有所不同，因为不是所有用户都会恰好在同一秒内发起请求，且用户

请求的复杂度和资源需求可能会有所不同

峰值QPS计算原理：每天80%的访问集中在20%的时间里，这20%的时间叫做峰值时间 峰值QPS计算公式：（总PV数*80%）/（每天秒数*20%）=峰值时间每秒请求数（QPS） 并发数 = QPS * 响应时间 运营提供6.13-6.20 PV(Page View)最大值为6.15(一天)：33099

按照20倍PV计算： QPS=（33099*20*80%）/（86400*20%）= 30（平均QPS）

​ 如何统计实时在线用户:

​ 使用如Google Analytics（收集用户互动数据）等第三方服务，可以帮助跟踪网站的实时用户数

数据库有几张表?

​ 100-200张表

团队有多少人?

​ 7人(5个java 1前端 1测试)

项目开发了多久?

​ 分类:

​ 0-1 时间大概是在3~6个月

​ 1--> 在职期间

​ 对于具体模块:

​ 一般来说，一个中等复杂度的订单模块，如果由一个经验丰富的小团队开发，可能需要几周到几个月的时 间。例如，对于一个简单到中等复杂度的模块，可能需要4-8周的时间。然而，对于更复杂的系统，这个时间 可能会延长到数个月

平常除了写代码,java开发工程师还有哪些工作需要完成?

​ 1,编写接口文档（YAPI）和用户手册（功能使用步骤）等

​ 2,学习新技术

​ 3,辅助团队成员

​ 4,测试和质量保证

​ 5,参加技术研讨会

​ 6,需求评审

​ 7,其他团队（产品、前端、测试、运维）对接，沟通配合

4.Feign与OpenFeign的区别

（旧版本）他们底层都是内置了Ribbon，去调用注册中心的服务。

（新版本）OpenFeign内置的负载均衡器：NacosLoadBalancer，默认负载均衡器算法：轮询

Feign是Netflix公司写的，是SpringCloud组件中的一个轻量级RESTful的HTTP服务客户端，是SpringCloud中的第一代负载均衡客户端。

OpenFeign是SpringCloud自己研发的，在Feign的基础上支持了Spring MVC的注解，如@RequestMapping等等。是SpringCloud中的第二代负载均衡客户端。

Feign本身不支持Spring MVC的注解，使用Feign的注解定义接口，调用这个接口，就可以调用服务注册中心的服务

OpenFeign的@FeignClient可以解析SpringMVC的@RequestMapping注解下的接口，并通过动态代理的方式产生实现类，实现类中做负载均衡并调用其他服务。

feign已不在维护，openfeign维护频繁。

5.Eureka，Zookeeper/Consul，Nacos区别

他们的区别要从分布式系统的CAP原理开始说起 CAP定理:

• C:数据一致性。
• A:服务可用性。
• P:分区容错性(服务对网络分区故障的容错性)。

1. Zookeeper取CAP的CP注重一致性，在可用性方面不太好，假如master节点故障，剩余节点会重新leader选举，选举leader的时间太长30~120s，选举期间整个集群都不可用，这就导致在选举期间注册服务瘫痪，漫长选举导致注册不可用，不能容忍。

2. Eureka看明白了这一点，因此在设计时就优先保证可用性。取CAP的AP，注重可用性。Eureka各个节点都是平等的，只要有一台Eureka还在就能保证注册服务可用(保证可用性)，只不过可能查询到的不是最新的。

3. eureka的自我保护机制，会导致一个结果就是不会再从注册列表移除因长时间没收到心跳而过期的服务。依然能接受新服务的注册和查询请求，但不会被同步到其他节点(保证当前节点可用)，当网络稳定时，当前实例新的注册信息会被同步到其它节点中。也就是，不容易瘫痪。

4. Zookeeper有Leader和follower角色，Eureka各个节点平等。

5. Zookeeper采用过半数存活原则，Eureka采用自我保护机制解决分区问题。

6. eureka本质是一个工程，Zookeeper只是一个进程。

-----------------------------nacos------------------------------------

nacos相较于zk与eureka来说,他会根据网络的实时状态动态切换CP还是AP

如果网络流畅,会注重一致性原则 选择CP

如果网路波动,会注重可用性原则,自动切换为AP

6.项目开发流程能说一下吗

一、项目立项（产品、甲方）

二、需求分析（产品经理）

• 产出需求文档
• 产生页面原型

三、设计

• 数据库设计（数据库建模工具：powerDesigner、PDMan-ER图（逻辑关系），生成DDL）
• 接口设计（YAPI-开发接口文档）

四、编码/修复BUG

• 确保熟悉业务（产品经理、项目经理、测试、前端）
• 业务对应数据表关系（通过ER图梳理关系）
• 参照接口文档编写代码（按照公司开发规范）
• 接口测试（单元测试、接口测试）

五、测试/回归

• 编写测试用户
• 进行功能，性能测试
• 测试报告

六、上线运维

• Jenkins
• K8S/Docker

7.项目刚开始上线的原始(运营)数据是如何来的?比如专辑信息 和 声音信息

1. 音频内容提供商： 项目可能会合作或购买音频内容，比如与有声书出版商、独立制作者或音频内容平台合作，从中获取专辑信息和声音信息（由运营人员发布）。
2. （内容创作者）用户上传： 如果你的平台支持用户上传自己的音频内容，那么初始数据中的一部分可能来自用户上传的音频文件。这需要有一套上传、审核和管理系统来确保内容的质量和合法性。
3. 公共领域： 有些项目可能会包含一些公共领域的音频内容，这些内容可能是经典文学作品、历史记录等。
4. 网络爬虫： 有时候，项目可能会使用网络爬虫从一些公开的资源中获取音频信息，不过这需要小心确保遵循法律和伦理规定。也可以使用采集器
5. API： 与第三方服务集成，使用其 API 获取音频内容信息。例如，你可能与一些在线音频数据库（如豆瓣FM、喜马拉雅等）集成，通过他们的 API 获取专辑信息和声音信息。

8.你们所在的项目组分支是如何管理

分支名称	分支含义
主分支 master	通常包含生产环境中运行的代码
开发分支Develop	用于日常开发的主要分支 通常每人一个开发分支
功能分支Feature	针对新功能或改进创建的分支
修复分支Hotfix	用于快速修复生产环境中的紧急问题
测试分支QA	特别用于测试环境的分支
发布分支release	用于准备发布的新版本 从开发分支分离出来，允许进行最后的调整和测试
支持分支support	对于需要长期维护的老版本，可能会创建支持分支

9.测试的基本流程

测试用例是什么?

测试用例是指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。简单的可以认为，

测试用例是为某个特殊目标而编制的，实际结果与预期相符

SAT环境:系统验收测试（交付演示）

UAT环境: 用户验收测试（模拟真实环境）

回归测试: 也叫冒烟测试 用相同的测试用例在bug修复前后进行测试 指的就是回归测试

灰度发布: 灰度发布（也称为渐进式发布、金丝雀发布或部分发布）是一种软件发布策略，它允许你将新版本的软

件逐渐推送给一部分用户，而不是一次性对所有用户发布

灰度发布特别适用于大型和复杂的应用，尤其是那些具有大量用户的在线服务和云应用

10.java开发一般前后端怎么联调的 java前后端分离开发流程

1、评审阶段：产品召集前后端进行需求评审，前后端各自捋清楚自己的业务量以及联调之间工作量，从而进行开发时间评估。

2、开发准备阶段：前后端一起商量需求中需要联调的部分，进行接口的口头协议交流。

3、接口定义阶段：前后端中的一方根据之前的口头协议拟定出一份详细的接口，并书写API文档，完成后由另一方确认。有疑问的地方重新商量直至双方都没有问题。

注意：第一份确认并书写好API的接口基本不会大改。

4、开发阶段：双方根据协商出来的接口为基础进行开发，如在开发过程中发现需要新增或删除一些字段，重复步骤3。

注意：前端在开发过程中记得跟进接口，mock数据进行本地测试。

4、开发阶段：双方根据协商出来的接口为基础进行开发，如在开发过程中发现需要新增或删除一些字段，重复步骤3。

注意：前端在开发过程中记得跟进接口，mock数据进行本地测试。

5、联调阶段：双方独自的工作完成，开始前后端联调，如在联调过程发现有疑问，重复步骤3，直至联调完成。

6、产品体验阶段：将完成的需求交给产品，让其体验，直至产品这边没有问题

7、提测阶段：将完成的需求提给测试人员，让其对该需求进行测试，如发现问题，及时通知开发并让其修改，直至需求没有bug。

8、评审单发布阶段：前后端中的一人进行评审单的拟定，发送给对应的领导，表明需求发布的程序，包括影响到的页面及业务，发布的流程，发布的回滚方案等。

9、发布阶段：前后端双方在保证步骤1-8都没有问题了，进行各自的代码发布，完成后由测试人员在线上进行相应的测试，如果有bug，重复步骤7和9，直至需求成功上线。

11. java实际开发过程中后端与测试如何沟通协作

禅道