基于路由机制设计的app架构思路

最新推荐文章于 2023-10-14 20:18:15 发布
原创 最新推荐文章于 2023-10-14 20:18:15 发布 · 4.6k 阅读 · 4 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#架构 #设计 #app #android #react-native

本文探讨了软件架构设计的重要性，分析了传统MVC等模式在现代应用中的局限性，并提出了一种基于路由的新型架构设计思路，旨在提高软件的可维护性和扩展性。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

转载请注明出处:王亟亟的大牛之路

有差不多接近一个多月没发文了，最近事情比较多。各种会，写各种计划，解决各种问题，以及团队内部扩招那些事(每天邮箱各种简历眼花缭乱)

先安利:我的Git 之后会把内容都往git book等地方迁移，所以对我写的东西感兴趣的小伙们可以follow我的git,以获取最新内容！

对架构的理解

最近聊了许多小伙报价从高到低的各式各样的都有(这里只是举个例子，没有任何贬低的意思)
一提架构张嘴就来 MVC MVP MVVM等等等，如果简历写有大项目的架构经验并且要价偏高的我一般默认这样的小伙不是太可用(先看，别急后面有解释),或者说你之前的项目”不够大”。

如果要价不是很高，经验不是写的很丰富的话那我还可以理解。

为什么这么”默认”？

  1. 太笼统
    MVC那套从写Web时期就一直使用至今，你抓个写java web的也能给你说的头头是道,纸上谈兵没有实际意义
  2. 实用性不足
    每个”重量级”的项目都有不同的实现方式，简单的拿几个英文单词硬套是否真的合理,真的适合自己的应用场景
  3. 知识点滞后
    从国内android/iOS热更(组件化)大潮(15年)出现后各式各样基于分包,插件化等等的内容层出不穷，还指望一套架构吃死那是不可能了。

简易组件化设计

把共同属性的代码提取出来制作成各种基础库,把单独的功能封装成Library包，不同业务通过分包结构分到不同module下，组内每人开发自己的module。

这里写图片描述

把纯业务模块和非业务模块以及一些”刚需”的代码做了简易的分包，库与库之间的关系看似很完美
写各个模块的小伙伴们可以各做各的，没有任何交集

于是有一天，来了个不可描述的场景
(只是举例子)
直到有一天产品说，我们要集成 TalkingData，我们要Ui库的各个控件必须做埋点！

那怎么办？

ui库的小伙伴去依赖 第三方统计库，去写里面的埋点业务

还有,ui组件的细节我要计算(你别管合理不合理，产品就说要算,我们就模拟这是个必做的业务)

ui库还得去依赖工具库，然后这个架构图成了这样
这里写图片描述

这只是一轮迭代，后面还有各种不可描述的复杂姿势，导致最后你的项目又一团糟，可维护性又像所有代码在一个包里那样差了

基于”路由的架构设计”

经过重新设计后大致长这样

这里写图片描述

因为基础功能库确实是一个被依赖可能性极大的库所以我们让他依赖着”路由”库
所有的子包，包括主项目都去依赖这个库，而基础功能库依赖于工具库和”路由”库
工具库放进去的意义就不说了，贯穿整个app过程都有大概率调用工具类，无论是主项目还是子工程包

着重说一下这个”路由”体系对于各个包/内容的意义

对于页面:
提供统一的跳转规则,更可控的跳转拦截，更大的延展性等等等(这部分可以看我之前写的一篇关于ARouter的文章:http://blog.csdn.net/ddwhan0123/article/details/54409574)

对于子包:
所有的包之间的相互调用关系就不存在了，耦合性降低，所有的通信统一都交给路由来处理分发(并且持有规则)，而注册工作则交由主工程去进行初始化。无论子包怎么变化(数量与内容)，只要在统一的路由规则下都可以畅通无阻地运行，而不是改一处则动全身！

在子包的概念里，路由是规则，是关系链。

这么做的目的很简单

  • 可测试性增强–只测自己想测的包就行，根本不用管其他包的关系链
  • 复用性增强–类似的基础组件可以在不同的事业群下使用
  • 支持并行开发–你写你的我写我的
  • 耦合降低–除了基础库外，其他库没有了依赖关系

该设计不考虑多进程场景，庞大集群项目需另外考虑考虑

更多架构选择/知识点:
https://github.com/googlesamples/android-architecture
http://www.infoq.com/cn/articles/ctrip-android-dynamic-loading
http://www.open-open.com/lib/view/open1436316754208.html
http://keeganlee.me/post/architecture/20160222

有问题可以联系我：
这里写图片描述

软件架构设计与模式之：模块化设计与组件化架构
AI天才研究院
10-20 914
模块化、组件化、微服务架构已经成为云计算的主流架构模式，软件架构设计如何满足需求并持续优化性能是一个非常重要的课题。本文将阐述模块化、组件化、微服务架构的概念及优缺点，并从面向对象的角度阐述模块化设计与组件化架构的过程。同时介绍一些基于Java语言的开源框架（如Spring）所实现的模块化、组件化、微服务架构，并深入到源码分析其实现机制和原理。本文的主要读者群体为软件工程师、架构师等相关人员。
前端领域路由管理的模块化设计思路
最新发布
AI架构全栈开发实战笔记
04-24 884
随着单页应用（SPA）和微前端架构的普及，前端路由管理面临前所未有的复杂度挑战。传统集中式路由配置在项目规模扩大后，会出现配置冗余、职责不清、组件耦合等问题。如何避免路由配置文件过度膨胀？如何实现路由与业务组件的解耦？如何统一管理全局与局部路由守卫？如何支持微前端场景下的路由隔离与合并？本文覆盖主流前端框架（React/Vue/Angular）通用设计原则，提供语言无关的架构思路，同时包含基于Vue Router的实战案例。核心概念：解析前端路由原理与模块化设计的映射关系算法与模型。
 IEEE 802.15.4轻量级网络层路由设计及实现
01-30
 IEEE 802.15.4是低速率、低功耗的无线个人区域网络协议标准。分析了IEEE 802.15.4 的特点，在其上设计了轻量级网络层路由协议并在ZigBit 900平台上实现。路由协议对AODV进行了简化，利用MAC层的应答机制检测链路是否连通。最后对路由协议进行了测试，结果表明本路由设计具有良好的性能和扩展性。
APP系统架构方面的设计
duck_arrow的专栏
05-04 2万+
APP系统架构方面的设计        APP分析过程在项目管理体系PMBOK中归属于项目范围定义（DefineScope）过程。从PMBOK的角度来看，在完成需求收集（CollectRequirements）后，需要对项目和产品的详细范围进行描述，清晰完整的项目/产品范围说明书有利于制定出具有良好执行性的WBS（WorkBreakdown Structure），但其更为重要的意义在于科学的
有关APP架构设计的思路
qq_28551705的博客
07-24 2625
涉及到组件化,模块化,里面有一个就是路由router来实现模块间的通信.
移动端路由层设计
qq_19697705的专栏
12-23 455
http://www.jianshu.com/p/be7da3ed4100 什么是移动端路由层： 路由层的概念在服务端是指url请求的分层解析，将一个请求分发到对应的应用处理程序。移动端的路由层指的是将诸如App内页面访问、H5与App访问的访问请求和App间的访问请求，进行分发处理的逻辑层。 移动端路由层需要解决的问题： 对外部提供远程访问的功能，实现跨应用调用响应，包括H5应用
对于做App架构设计的一些思考
Promise Sun special column
03-12 498
文 |Promise Sun （注：本文是个人经过学习之后，所做的一篇简单的笔记，并不涉及理论分析，仅供参考。） 一、如何理解架构？ 架构分为三个阶段：规划、设计、构建。 在规划阶段，考虑的是产品的需求、质量的需求，技术的可行性分析以及预研。 在设计阶段，考虑的如何将一个复杂的系统拆分，并设计如何进行组织这些拆分的模块。 在构建阶段，考虑的就是具体的实施问题，并且要保证一定的伸缩扩展性，因为架构是不断演进的。 架构的设计可以从两个维度来考虑，一是架构思维，二是架构原则。 思维...
单体到微服务：电商平台架构的演变与可扩展性探索
热门推荐
张彦峰的博客
10-14 10万+
可扩展性是软件架构中至关重要的特性，它确保系统能够在需求增长和规模扩大的情况下保持高效运行。为实现可扩展性，首要考虑模块化设计，将系统分解为独立、低耦合的模块，使得扩展时能够有针对性地进行修改而不影响整体。同时，水平扩展和垂直扩展是两种常见的扩展策略，前者通过增加节点或服务器来分担负载，后者则通过提升单节点性能来处理更多请求。弹性设计是实现可扩展性的关键，系统需要能够动态地分配和释放资源，以适应负载的波动。采用服务化架构，将系统拆解成小型服务单元，有助于独立开发和扩展。
得物多活架构设计之路由服务设计
w915209092的博客
07-25 1335
这种降级会安排在用户不活跃的时段，往往不会对用户的体验造成太大的影响。如图所示，状态A是变更之前的状态，状态C是变更后的目标状态，状态A与状态C是不能同时出现的，但是状态A变更为状态B，在等待直到所有机房的所有相关机器全部都变更为状态B，那么再从B到状态C，这样就不会出现状态A和状态C同时出现的情况。这里特殊提一下归属的默认优化，我们将某一个机房作为默认机房，所有归属到此机房的用户无需加入路由表，当调用路由服务查询此用户路由时，路由表返回空值，路由服务直接返回默认机房，从而大大降低路由表的大小。...
智能客服平台的架构设计：实现高效、安全、可靠的服务运行
AI天才研究院
07-13 4433
在当今数字化时代,客户服务已成为企业与客户之间沟通的关键纽带。随着人工智能技术的快速发展,智能客服平台应运而生,为企业提供了一种高效、经济且全天候的客户服务解决方案。智能客服平台不仅能够大幅提升客户服务质量,还能降低企业运营成本,实现客户满意度与企业效益的双赢。然而,要建立一个真正高效、安全、可靠的智能客服平台,需要精心的架构设计和全面的技术考量。本文将深入探讨智能客服平台的架构设计原则、关键技术以及实现方法,为读者提供一个全面而深入的理解。
APP架构构思基本思路初稿
a1961613299的专栏
01-10 2940
如果维护多个项目（尤其是处于一个外包公司的话），那么自然而然要避免每次都是开发新的项目，避免掉着没有必要的重复劳动力。 于是，鉴于此，我在app架构的设计上抽取出一个类库（MDLib）“妈蛋类库”。 先上图（MDLib）：由图可知，Android和iOS的类库在这里采取了相同的架构。 第三方库集成引用虽然iOS有pods，Android有gradle，但是有时涉及源代码的时候有些人还是习惯将他们作为
app 设计思路 - 服务端
Simael的专栏
06-22 1845
app 设计思路 - 服务端 开始你的app 设计之旅吧。
ASP.NET MVC3 学习心得------路由机制
xuemoyao的专栏
12-03 3656
9.1 理解URL URL满足的要求： l 域名易于记忆和拼写 l 简短、易输入 l 可以反应出站点的结构 l 可破解，用户可以通过移除URL的末尾，进而达到更高层次的信息体系结构 l 持久、不能变化 9.2路由机制的概述 ASP.NET MVC中路由机制的两种用途： l 匹配传入的请求，并映射到控制器的操作 l 构造传出的URL，用来相应控制器的操
路由机制
aq8008的博客
06-12 518
VC框架中路由具有重要作用，本文主要介绍路由的一些知识。目录如下： 1、引言 2、什么是路由 3、特性路由 4、传统路由 5、MVC区域 6、路由调试 7、路由的其它一些信息 8、选择特性路由还是传统路由 9、asp.net处理http请求的大致过程 1、引言 MVC的理解： View是界面，Model是功能模型，Controller是View和Model的...
支付系统路由系统设计
h123xd4的博客
04-10 3786
路由系统，即智能选择最优‘‘线路’’，对于支付结算系统而言，就是要智能选择入款、出款渠道，那如何体现其智能呢？我们先看几个例子： 例子1： 现有2个渠道，渠道A的收费规则是1‰，渠道B的收费规则是2元1笔。毫无疑问，在其他条件相同的情况下，我们更愿意使用更便宜的渠道，而手续费到底哪家便宜，会根据交易金额有所不同。 路由，就是要实现节约成本！ 例子2： 现有2个出款渠道，收费都是2
【iOS开发】移动端路由层设计
Hanrovey Blog
07-13 482
http://www.jianshu.com/p/be7da3ed4100http://www.jianshu.com/p/3a902f274a3d
【网络】TCP/IP协议网络层 - 路由机制详解（含路由表详解、重定向机制）
C/C++菜鸟养成记
08-04 3385
一、IP路由 1、路由机制 1、路由表：在Linux环境下，我们可以通过 route 来查看路由表 Destination：表示网络或主机 Gateway：网关地址； Genmask：网络掩码； Flags：路由项标志，常见的有5种：U（活动的）、H（目标是一台主机）、G（目标是网关）、D（由重定向生成的）、M（被重定向修改过）； Metric：路由距离，即到达指定网络所需的中...
路由机制和重定向
冯浩月
01-18 3620
前言     关于路由重定向的知识，自己模模糊糊地听到过几次，之前技术分享时一次，牛腩新闻发布系统验收时，师傅提到过，自己结合牛腩新闻发布系统和百度百科等一些资源，来具体总结一下这个知识点。什么是路由机制 一、百度百科解释     路由重定向：表示将你原来在转发列表中法相一台路由的路径改成另外一条路径，相当于让数据走另外一条路到服务器。从它的作用影响来看，（1）当一个路由出现问题的时候，会自动重定
路由原理
yandaqijian的专栏
03-18 883
第 一 章 ： 路 由 选 择 原 理  1.1路由选择基础知识  路由是将对象从一个地方转达发到另一个地方的一个中继过程  学习和维持网络拓朴结构知识的机制被认为是路由功能。渡越数据流经路由器进入接口  穿过路由器被移送到外出接口的过程，是另一项单独的功能，被认为是交换/转发功能。路由设备必须同时具有路由和交换的功能才可以作为一台有效的中继设备。  为了进行路由，路由器必须知道下面三项
基于django的在线音乐网站设计
02-21
<think>好的，我现在需要帮用户介绍一个基于Django的在线音乐网站设计。首先，我得回忆一下Django的基本结构和常用组件，确保覆盖到主要的技术点。用户可能想了解整体架构、功能模块、技术实现细节，还有可能对数据库设计或者前后端交互感兴趣。 首先，我应该从项目概述开始，说明Django作为后端框架的优势，比如MTV模式、ORM、Admin后台等。然后分模块介绍，比如用户系统、音乐管理、播放功能、社交互动等。每个模块需要详细一点，但不要太深入代码，毕竟用户可能是在寻找设计思路而不是具体代码。 接下来是技术要点，这里需要提到Django的模型设计、视图和路由、模板或者前后端分离的选择。现在很多项目用REST框架，所以可能得提到DRF（Django REST Framework）和前端框架如Vue或React的结合。另外，文件存储部分，用户上传的音乐文件如何存储，可能用本地存储或者云存储如AWS S3、阿里云OSS等。 数据库设计方面，需要设计用户、音乐、歌单、评论等模型，以及它们之间的关系，比如多对多、外键关联。这部分可能需要画出ER图，但文字描述的话要简洁明了。 安全性也是需要考虑的，比如用户认证、权限管理、XSS和CSRF防护，Django自带的中间件和安全机制可以提一下。还有文件上传的安全性，防止恶意文件上传。 性能优化方面，缓存机制，比如使用Redis缓存热门歌曲或页面片段，数据库查询优化，比如使用select_related或prefetch_related减少查询次数，异步任务处理比如Celery处理文件上传后的处理任务，比如生成缩略图或转码。 部署部分可能需要简单带过，比如用Nginx和Gunicorn部署，或者Docker容器化，但用户可能更关注设计而不是部署，所以这部分可以简略。 最后，扩展方向可以提一下未来可能增加的功能，比如推荐算法、直播、音乐商城等，让用户知道项目的可扩展性。 需要注意用户的身份可能是学生或者刚入门的开发者，所以语言要通俗易懂，避免太多专业术语，必要时举例说明。同时，用户可能希望了解从设计到实现的全流程，所以结构要清晰，分点分模块讲解，确保信息条理化。 可能还需要考虑是否涉及版权问题，但用户的问题主要是技术设计，这部分可以暂时不提。另外，是否需要前后端分离的设计，还是传统的Django模板方式，可能需要根据当前趋势建议前后端分离，但也要提到两种方式的优缺点。 总结下来，回答的结构应该是：概述、功能模块、技术实现、数据库设计、安全与性能、扩展方向。这样逻辑清晰，覆盖主要方面，帮助用户全面了解基于Django的在线音乐网站的设计要点。</think>是一个基于 Django 的在线音乐网站设计的核心要点介绍，内容涵盖技术架构、功能模块和关键实现思路： --- ### **1. 项目概述** **技术栈**： - **后端框架**：Django（MTV模式、自带Admin后台、ORM等） - **数据库**：MySQL/PostgreSQL（存储结构化数据）、Redis（缓存/会话管理） - **前端**：HTML/CSS/JavaScript + Bootstrap/Vue.js/React（可选前后端分离） - **存储**：本地存储或云服务（如阿里云OSS、AWS S3存放音频文件） - **其他工具**：Celery（异步任务）、FFmpeg（音频处理） --- ### **2. 核心功能模块** #### **(1) 用户系统** - **注册/登录**：Django内置`django.contrib.auth`实现认证，支持邮箱验证、第三方登录（OAuth2）。 - **个人中心**：用户信息管理、播放历史记录、收藏歌单、上传音乐（需权限控制）。 #### **(2) 音乐管理** - **音频上传**：通过 Django 表单或 API 上传，限制文件格式（MP3/WAV等），使用`FFmpeg`转码统一格式。 - **音乐分类**：标签化分类（如流行、摇滚），支持多级分类或智能推荐标签。 - **搜索功能**：Django ORM 实现关键词搜索（标题、歌手），或集成 Elasticsearch 提升性能。 #### **(3) 播放与交互** - **在线播放**：HTML5 Audio 标签或第三方播放器（如 `howler.js`），实现播放、暂停、进度条、音量控制。 - **歌词同步**：解析 LRC 文件并与音频时间轴匹配，动态滚动显示。 - **收藏/评论**：用户可收藏歌曲、创建歌单，发表评论（防 XSS 过滤）。 #### **(4) 社交功能** - **分享功能**：生成带二维码的歌单链接，支持社交媒体分享。 - **关注系统**：用户间互相关注，动态消息推送（如新歌通知）。 --- ### **3. 关键技术实现** #### **(1) 数据库设计** - **核心表结构**： - **用户表**：`User`（扩展 Django 原生用户模型） - **音乐表**：`Music`（标题、歌手、时长、文件路径、封面图等） - **歌单表**：`Playlist`（多对多关联用户和音乐） - **评论表**：`Comment`（外键关联用户和音乐） #### **(2) 文件存储优化** - **分片上传**：大文件断点续传（如使用 `django- **CDN加速**：音频文件通过 CDN 分发，减少加载延迟。 #### **(3) 权限控制** - **基于角色的访问控制（RBAC）**：区分普通用户、上传者、管理员。 - **Django中间件**：限制未登录用户访问敏感页面。 #### **(4) 性能优化** - **缓存机制**：Redis 缓存热门歌曲列表、首页推荐。 - **异步任务**：Celery 处理音频转码、发送通知邮件。 --- ### **4. 安全设计** - **CSRF/XSS防护**：Django 内置中间件自动防护，评论内容使用 `bleach` 库过滤。 - **SQL注入防御**：ORM 参数化查询避免手动拼接 SQL。 - **文件上传安全**：限制文件类型、扫描恶意内容。 -- ### **5. 扩展方向** - **推荐系统**：基于用户行为（协同过滤）或音频特征（机器学习）推荐歌曲。 - **直播功能**：集成 WebRTC 实现音乐人实时演出。 - **移动端适配**：开发配套 App（Flutter/React Native），通过 Django REST Framework 提供 API。 --- ### **6. 开发流程建议** 1. **需求分析**：明确目标用户（如普通听众/原创音乐人）。 2. **原型设计**：用 Figma 绘制界面原型，定义 API 接口。 3. **模块拆分**：按功能分模块开发（用户、音乐、社交等）。 4. **测试部署**：使用 Docker 容器化部署，Nginx + Gunicorn 作为生产环境服务器。 -- 通过以上设计，可构建一个高性能、易扩展的在线音乐平台。Django 的高开发效率和丰富的第三方库（如 Django REST Framework、Django Channels）能显著降低开发复杂度。
评论 6
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值