思考
微服务是一种架构风格
微服务就是把一个项目拆分成多个独立的不封
而且多个服务都是可以运行的 每个服务都会占用线程
传统的IT行业软件都是独立系统的堆砌 这些系统总结来说就是可拓展性不高 可靠性不高 维护成本广告
微服务的每个模块都是独立的 而且可以用有多重存储方式 数据库也是每个模块对应自己的数据库
单体架构所有的模块开发所使用的开发技术可以不同 开发模式更加灵活
从业务出发 想一下哪些功能/职责是在一起的
好比自己是公司老板 想想怎么给员工分工
业务功能
1.用户模块 8102端口
a.注册 后端已经实现 前端已经实现
b.登录 后端已经实现 前端已经实现
2.题目模块 8103端口
a.创建题目 管理员
b.删除题目 管理员
c.修改题目 管理员
d.搜索题目 用户
e.在线做题 题目详细页
3.判题模块 8104端口
a.提交判题 结果是否正确与错误
b.错误处理 内存溢出 安全性 超时
c.自主实现 代码沙箱 安全沙箱
d.开发接口 提供一个独立的新服务
公共的服务：
1.common 公共模块
全局异常处理器 请求响应封装类 公共的工具类
2.model 模型模块
很多服务公用的实体类
3.service client公用接口模块
只存放接口不存放实现 多个服务之间要共享
代码沙箱服务可以不用纳入微服务的管理
本身就是独立的
依赖服务
1.网关汇总所有的接口 微服务网关Geteway
2.注册中心 Nacos
路由划分
用springboot的context-path统一修改个项目的接口前缀
比如 用户服务
/api/user
/api/user/inner(内部调用 网关层面要做限制)
比如 题目服务
/api/question(也包含题目提交信息)
/api/question/inner(内部调用 网关层面要做限制)
比如 判题服务
/api/judge
/api/judge/inner(内部调用 网关层面要做限制)
