微服务项目-＞在线oj系统(Java-Spring)

需求种类	需求内容
业务需求	题目列表 刷题 竞赛列表 竞赛用户排名 比赛 自动判题 题目管理 竞赛管理
用户需求	我的竞赛 我的消息 , 获取比赛结果 查看历史竞赛排名
系统需求	用户登录 , 注册 用户登录 安全防护(身份认证 , 身份认证 . 防sql注入 . 防xxs攻击)

 C/S架构与B/S架构

C/S架构（Client/Server，客户端/服务器架构）

特点：

• 客户端：需要安装专用的客户端软件（如QQ、微信、游戏客户端）。

• 服务器：负责数据处理和业务逻辑，客户端负责用户交互和部分计算。

• 通信：通过自定义协议（如TCP/UDP）直接与服务器交互。

优点：

• 性能高：客户端可以分担计算任务，响应速度快（适合图形渲染、实时交互等场景）。

• 离线能力：部分功能可离线使用，同步数据时再连接服务器。

• 安全性：通信协议可定制，数据加密更灵活。

缺点：

• 部署维护成本高：需为不同操作系统开发客户端，升级时需要用户手动更新。

• 跨平台性差：不同系统（Windows/macOS/Linux）可能需要单独开发。

• 用户门槛：用户需主动安装客户端，推广成本高。

典型应用：

• 大型游戏（如《英雄联盟》）、即时通讯工具（如微信）、企业ERP系统。

B/S架构（Browser/Server，浏览器/服务器架构）

特点：

• 浏览器：用户通过浏览器（Chrome/Firefox等）访问，无需安装额外软件。

• 服务器：承担主要业务逻辑和数据处理，浏览器仅负责展示和简单交互。

• 通信：基于HTTP/HTTPS协议，通常通过Web服务（如RESTful API）交互。

优点：

• 跨平台性：只需兼容浏览器，支持Windows/macOS/Linux甚至移动端。

• 无需安装：用户通过URL即可访问，使用门槛低。

• 维护方便：服务端更新后，所有用户自动获取最新版本。

缺点：

• 性能受限：依赖浏览器和网络，复杂计算或图形处理能力较弱。

• 离线能力差：通常需联网使用（可通过PWA等技术部分缓解）。

• 安全性挑战：易受Web攻击（如XSS、CSRF），需额外防护。

典型应用：

• 网页邮箱（如Gmail）、在线办公（如Google Docs）、电商平台（如淘宝）

核心对比 

对比维度	C/S架构	B/S架构
安装部署	需安装客户端	无需安装，浏览器即可访问
跨平台性	差（需多版本适配）	强（浏览器通用）
性能	高（本地计算）	依赖网络和浏览器性能
维护成本	高（需更新客户端）	低（服务端统一更新）
离线支持	支持	有限支持（需特殊技术）
典型场景	实时游戏、高频交互工具	信息查询、在线服务

发展趋势 

混合架构：现代应用常结合两者优势，如客户端应用内嵌Web页面（Electron、Flutter），或PWA（渐进式Web应用）提供类原生体验。

云原生趋势：B/S架构因云计算的普及更受青睐，但C/S仍在对性能要求高的领域不可替代。

根据需求选择架构：

• 需要高性能、复杂交互 → C/S

• 追求便捷性、跨平台 → B/S

微服务划分

单体架构:

可跨展现差,技术栈受限,可靠性问题

集群架构:

资源利用率低,容错与隔离性不足,部署与升级复杂

分布式架构:

较高耦合度,容错与隔离性不足

微服务架构的优势:

易于开发和维护:每个微服务负责的业务比较清晰,体量小,开发和维护成本降低

容错性高:一个服务发生故障,可以使故障隔离在单个服务中,不影响整体服务故障

扩展性好:每个服务都是独立运行的,我们可以结合项目实际情况进行扩展,按需伸缩

技术选型灵活:每个微服务都是单独的团队来运维,可以根据业务特点和团队特点,选择适合的技术栈

微服务带来的挑战

服务依赖:随着服务的数量增多,服务之间的关系也会变得复杂,一个服务的更改,需要考虑对其它服务的影响

运维成本: 一个业务流程会涉及多个微服务共同完成,有更多的服务需要编译,部署,运行,甚至可能是不同的编程语言,不同的运行环境,当然也需要集群来处理故障转移等

开发和测试:一个业务流程可能涉及多个微服务共同完成,服务调用引入网络延迟,不可靠的网络,如何进行容错处理等问题

服务监控:在一个单体结果中,很容易实现服务的监控,因为所有功能都在一个服务中,微服务架构下,不仅需要对整个链路进行监控,还需要对每一个服务进行监控

负载均衡:微服务架构中的服务实例数量肯能非常庞大,因此需要有效的服务发现和负载均衡机制来管理请求流量和保证高可用性

微服务划分的核心目标

1. 高内聚低耦合:每个服务专注于单一业务能力，内部功能紧密相关，服务间依赖最小化。
2. 独立部署与扩展:服务可单独部署、升级和扩缩容，不影响其他服务。
3. 团队自治:每个服务由独立团队全权负责（开发、运维），减少跨团队协调成本。
4. 技术异构性:不同服务可根据需求选择合适的技术栈（如数据库、编程语言）。

微服务划分原则

1. 业务能力优先

• 按领域驱动设计（DDD）划分：

  • 识别业务领域的限界上下文（Bounded Context），每个上下文对应一个微服务。

  • 例如：电商系统中的「订单服务」、「库存服务」、「支付服务」。

• 避免技术维度划分：

  • 错误示例：按"数据库服务"、"缓存服务"划分（应属于技术组件而非业务服务）。

2. 单一职责原则（SRP）

• 每个服务只解决一个核心问题，例如：

  • 用户服务：仅处理用户注册、登录、权限。

  • 商品服务：仅管理商品信息、分类。

• 判断标准：如果修改一个功能的需求频繁影响多个服务，说明划分不合理。

3. 松耦合与高内聚

• 松耦合：服务间通过API通信，避免数据库直接共享。

• 高内聚：服务内部数据和行为紧密关联，例如「订单服务」应包含订单创建、查询、状态机逻辑。

4. 团队规模匹配

• 两个披萨原则：一个微服务应由一个小团队能完全维护。

• 避免服务粒度过细导致运维复杂度爆炸。

5. 演进式设计

---

在线oj系统:按照业务划分 

按照技术划分:

服务器架构:

前端运用技术

官方文档: Vue.js - 渐进式 JavaScript 框架 | Vue.js

实战教程: Vue Mastery | The best way to learn Vue.js

Vue Router:Vue Router | Vue.js 的官方路由

vue核心目录:

node_modules：支持项目运行的依赖文件

public:存放静态资源和公共资源,如如favicon.ico网站图标

src:项目开发主要文件夹

index.html:入口的html文件

package.json:项目的描述文件

vite.config.js:项目的配置文件

单⽂件组件

• 使⽤html语法，描述整个组件的结构和布局。

• 在模板中可以使⽤vue的模板语法进⾏绑定数据、处理事件以及定义组件的DOM结构等。

• 每个 *.vue ⽂件最多可以包含⼀个顶层 <template> 块。

• 这部分包含组件的JavaScript或TypeScript代码。定义了组件的⾏为逻辑。

• 每个 *.vue ⽂件最多可以包含⼀个 <script> 块。(使⽤ <script setup> 的情况除外)

• 专为组合式api设计的⼀种特殊的语法糖，它允许你在⼀个更简洁、更直观的⽅式下编写组件逻 辑。

• 每个 *.vue ⽂件最多可以包含⼀个 <script setup>。(不包括⼀般的 <script>)

• 通常使⽤CSS或CSS预处理器编写样式。 定义了组件的样式和布局，⽤于控制组件的外观和样式。

• 每个 *.vue ⽂件可以包含多个 <style> 标签。

组合式API

<script>
import { ref } from 'vue'

export default {
  setup() {
    const count = ref(0)

    // 返回值会暴露给模板和其他的选项式 API 钩子
    return {
      count
    }
  },

  mounted() {
    console.log(this.count) // 0
  }
}
</script>

<template>
  <button @click="count++">{{ count }}</button>
</template>

Vue Router

服务端路由

客⼾端路由

单⻚⾯应⽤

什么是客⼾端路由

主要应⽤在单⻚⾯应⽤（SPA）中。当⽤⼾通过客⼾端访问不同的路径时，路由的映射函数会利⽤诸如History API事件这样的浏览器API来管理应⽤当前应该渲染的视图。这种⽅式的优点在于，它可以在不重新加载整个⻚⾯的情况下，根据⽤⼾的请求动态地加载和渲染新的数据或组件，从⽽带来更为顺滑的⽤⼾体验

• ⽤⼾体验更加流畅：SPA的最⼤特点是⻚⾯⽆需重新加载即可更新视图，这为⽤⼾提供了更快速、更流畅的导航体验。⽤⼾⽆需等待整个⻚⾯刷新，只需等待相关组件或数据的更新，⼤ 减少了⻚⾯跳转时的加载时间。

• 更好的交互性和响应性：SPA允许前端应⽤更加精细地控制⽤⼾界⾯的变化。通过动态更新⻚⾯的部分内容，SPA可以实现更丰富的交互效果和更快速的响应，从⽽提升⽤⼾的使⽤体验。

• 更好的前后端分离：SPA通常与RESTful API等后端技术结合使⽤，实现前后端的完全分离。这种架 构使得前端和后端可以独⽴开发、测试和部署，提⾼了开发效率和可维护性。

• 初次加载时间⻓ ：SPA通常需要加载较多的JavaScript和CSS资源，导致初次加载⻚⾯时可能需要较⻓时间。这可能会给⽤⼾带来不便，尤其是在⽹络较慢的情况下。

• SEO挑战：传统的SPA对搜索引擎来说不够友好， 因为搜索引擎爬⾍可能⽆法很好地解析

JavaScript动态⽣成的内容 。这可能导致SPA在搜索引擎结果中的排名受到影响。不过，通过服务

器端渲染（SSR）或预渲染等技术可以部分解决这个问题。