1、项目描述

（1）

谷粒学院，是一个在线教育系统，分为前台网站系统和后台运营平台。

前台用户系统包括课程、问答、文章三大部分，使用了微服务技术架构，前后端分离开发。

后端的主要技术架构是：SpringBoot + SpringCloud + MyBatis-Plus + HttpClient + MySQL + Docker + Maven，

前端的架构是：Node.js + Vue.js

其他涉及到的中间件包括Redis、ActiveMQ、阿里云OSS、视频点播

业务中使用了ECharts做图表展示，使用POI完成用户信息批量上传、注册

分布式单点登录使用了JWT、三方支付使用的支付宝

（2）

项目前后端分离开发，后端采用SpringCloud微服务架构，持久层用的是MyBatis-Plus，微服务分库设计，使用Swagger生成接口文档

接入了阿里云视频点播、阿里云OSS。

系统分为前台用户系统和后台管理系统两部分。

前台用户系统包括课程、问答、文章。

后台管理系统包括：系统管理、内容管理、社群问答、课程管理、消息中心、用户中心、统计分析、系统配置等功能。

2、这是一个项目还是一个产品

这是一个产品

1.0版本是单体应用：SSM

2.0版本加入了SpringCloud，将一些关键业务和访问量比较大的部分分离了出去

目前独立出来的服务有用户中心服务、单点登录服务、教学服务、点播服务、订单服务、支付服务

3、测试要求

首页和视频详情页qps单机qps要求 2000+

经常用每秒查询率来衡量域名系统服务器的机器的性能，其即为QPS

QPS = 并发量 / 平均响应时间

4、企业中的项目（产品）开发流程

一个中大型项目的开发流程

1、需求调研（产品经理）

2、需求评审（产品/设计/前端/后端/测试/运营）

3、立项（项目经理、品管）

4、UI设计

5、开发

• 架构、数据库设计、API文档、MOCK数据、开发、单元测试
• 前端
• 后端

6、前端后端联调

7、项目提测：黑盒白盒、压力测试（qps）

8、bug修改

9、回归测试

10、运维和部署上线

11、灰度发布

12、全量发布

13、维护和运营

5、系统中都有那些角色？数据库是怎么设计的？

前台：会员（学员）

后台：系统管理员、运营人员

后台分库，每个微服务一个独立的数据库，使用了分布式id生成器

6、视频点播是怎么实现的（流媒体你们是怎么实现的）

我们直接接入了阿里云的云视频点播。云平台上的功能包括视频上传、转码、加密、智能审核、监控统计等。

还包括视频播放功能，阿里云还提供了一个视频播放器。

阿里云视频点播计费案例

https://help.aliyun.com/document_detail/64032.html?spm=a2c4g.11186623.6.551.5bf52b1dIu8mPe

7、前后端联调经常遇到的问题：

1、请求方式post、get

2、json、x-wwww-form-urlencoded混乱的错误

3、后台必要的参数，前端省略了

4、数据类型不匹配

5、空指针异常

6、分布式系统中分布式id生成器生成的id 长度过大（19个字符长度的整数），js无法解析（js智能解析16个长度：2的53次幂）

​ id策略改成 ID_WORKER_STR

8、前后端分离项目中的跨域问题是如何解决的

后端服务器配置：我们的项目中是通过Spring注解解决跨域的 @CrossOrigin

也可以使用nginx反向代理

9、说说你做了哪个部分、遇到了什么问题、怎么解决的

问题1：

分布式id生成器在前端无法处理，总是在后三位进行四舍五入。

分布式id生成器生成的id是19个字符的长度，前端javascript脚本对整数的处理能力只有2的53次方，也就是最多只能处理16个字符

解决的方案是把id在程序中设置成了字符串的性质

问题2：

项目迁移到Spring-Cloud的时候，经过网关时，前端传递的cookie后端一只获取不了，看了cloud中zuul的源码，发现向下游传递数据的时候，zull默认过滤了敏感信息，将cookie过滤掉了

解决的方案是在配置文件中将请求头的过滤清除掉，使cookie可以向下游传递

问题3：

数据库中数据量超过10000跳的时候，分页检索的速度特别慢，使用了mysql的深度分页

10、分布式系统的id生成策略

https://www.cnblogs.com/haoxinyue/p/5208136.html

#

11、MySQL深度分页

https://www.cnblogs.com/lpfuture/p/5772055.html

https://blog.csdn.net/li772030428/article/details/52839987

12、分布式系统的CAP原理

CAP定理：

指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可同时获得。

一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（所有节点在同一时间的数据完全一致，越多节点，数据同步越耗时）

可用性（A）：负载过大后，集群整体是否还能响应客户端的读写请求。（服务一直可用，而且是正常响应时间）

分区容错性（P）：分区容错性，就是高可用性，一个节点崩了，并不影响其它的节点（100个节点，挂了几个，不影响服务，越多机器越好）

CA 满足的情况下，P不能满足的原因：

数据同步(C)需要时间，也要正常的时间内响应(A)，那么机器数量就要少，所以P就不满足

CP 满足的情况下，A不能满足的原因：

数据同步(C)需要时间, 机器数量也多(P)，但是同步数据需要时间，所以不能再正常时间内响应，所以A就不满足

AP 满足的情况下，C不能满足的原因：

机器数量也多(P)，正常的时间内响应(A)，那么数据就不能及时同步到其他节点，所以C不满足

注册中心选择的原则：

Zookeeper：CP设计，保证了一致性，集群搭建的时候，某个节点失效，则会进行选举行的leader，或者半数以上节点不可用，则无法提供服务，因此可用性没法满足

Eureka：AP原则，无主从节点，一个节点挂了，自动切换其他节点可以使用，去中心化

结论：

分布式系统中P,肯定要满足，所以我们只能在一致性和可用性之间进行权衡

如果要求一致性，则选择zookeeper，如金融行业

如果要求可用性，则Eureka，如教育、电商系统

没有最好的选择，最好的选择是根据业务场景来进行架构设计

13、前端渲染和后端渲染有什么区别

前端渲染是返回json给前端，通过javascript将数据绑定到页面上

后端渲染是在服务器端将页面生成直接发送给服务器，有利于SEO的优化

14、能画一下系统架构图吗

项目业务功能参考

1、edusoho

http://www.edusoho.com/

http://demo.edusoho.com/

项目文档：道客巴巴，微信登录

2、德客

http://www.decerp.cn/solution/hotel.html

3、jeecms

http://www.jeecms.com/