1. B/S 架构 和 C/S 架构:
在移动互联网出现之前,有这两种架构:Browser/Server 和 Client/Server,后者需要安装客户端,相对更麻烦;前者只需要有浏览器就可以,所以一度认为 B/S 架构是更好的替代者。
前后端的分离为了更好的分担工作量,让两边可以同时进行工作
2. 网页开发和客户端开发的区别
网页开发迭代非常容易,但是客户端开发需要打包成新的安装包覆盖;
客户端编译语言,很多错误编译期就可以发现;网页是脚本语言
比较是否需要将backend从app中分离:
方案一:ios直接调用Firebase (不分离)
方案二:通过nodejs服务器调用Firebase(分离)
描述:
百万级流量,从安全 / 并发性能 / 成本 / 可扩展 等角度分析
方案一(不分离)
优点:
性能更优:
- 数据直接从 Firebase 到客户端,减少了网络中间环节(如服务器转发)。
- Firebase 的实时数据库和 Firestore具备高扩展性,能够自动处理高并发。
开发效率高:
- 省去了中间服务器的开发、部署和维护。
- Firebase SDK 提供了丰富的功能,便于快速开发。
成本低:
- 无需额外支付中间服务器的运行和维护费用。
- Firebase 提供一定免费额度,可以降低初始运营成本。
缺点:
安全性依赖规则:
- 需要非常严谨地配置 Firebase 安全规则,否则可能导致数据泄漏或滥用。
复杂逻辑难以处理:
- 客户端只能进行简单的业务逻辑,复杂操作需要额外实现。
客户端压力较大:
- 如果需要处理大量数据,客户端可能需要下载较多数据,导致性能瓶颈。
方案二(分离)
优点:
更高的安全性:
- 客户端不直接访问 Firebase,数据库的访问完全受服务器控制。
- 更容易隐藏敏感数据或业务逻辑。
适合复杂逻辑:
- 可以在服务器端实现复杂的业务规则、数据聚合和跨服务操作。
- 方便与第三方服务(如支付、机器学习模型)集成。
更好的数据流量控制:
- 服务器可以缓存常用数据,减少直接对 Firebase 的请求频率。
- 可以对客户端的请求进行限流或过滤,保护数据库。
缺点:
增加延迟:
- 数据流需要经过中间服务器转发,增加了一定网络延迟。
开发和运维成本更高:
- 需要开发、部署和维护中间服务器。
- 对服务器的可用性和扩展性有更高要求。
服务器成本:
- 高并发情况下,服务器的运行费用可能较高。
No comments:
Post a Comment