App和服务器之间的架构是什么？ (app和服务器属于什么架构)
在现代软件开发中，App和服务器之间的架构是非常重要的一环。这种架构决定了应用程序如何访问、处理和存储数据，以及如何保证数据的安全性和可用性。
一般而言，App和服务器之间的架构可以划分成两种类型：客户端/服务端（C/S）架构和WEB架构。
客户端/服务端（C/S）架构
C/S架构是一种最早的App和服务器之间的架构，它的原理是将应用程序分成两部分：客户端和服务端。客户端是指运行在移动设备上的App，它负责与用户交互并向服务器申请数据，而服务端则是指运行在服务器上的应用程序，它负责处理请求并向客户端返回数据。
C/S架构的优点是可以快速响应客户端的请求，因为所有数据都保存在服务器上，并且可以共享。此外，C/S架构也提高了应用程序的安全性，因为客户端只需要访问服务器上的数据，而不需要保存任何数据。
然而，C/S架构也有一些缺点。它需要安装多个应用程序才能实现各种功能；它对服务器的负载要求很高，因为所有的数据都保存在服务器上，而且需要快速响应大量的客户端请求。
WEB架构
WEB架构是一种最新的App和服务器之间的架构，它的原理是将应用程序分成三部分：客户端、服务器和数据库。客户端是指运行在移动设备上的浏览器，它负责向服务器请求数据，并将结果呈现给用户；服务器则是指运行在服务器上的应用程序，它负责处理请求、执行业务逻辑和访问数据库；数据库则是指存储数据的地方。
WEB架构的优点是非常灵活，可以根据需要部署多个服务器来实现负载均衡。此外，WEB架构可以有效地利用客户端的计算资源，因为每个客户端都可以将部分数据保存在本地缓存中，从而减少对服务器的请求。
然而，WEB架构的缺点也很明显。与C/S架构相比，它需要更多的技术和资源才能实现；由于网络延迟等原因，客户端在Web应用程序中的响应速度可能比较慢。
基于以上分析，使用哪种架构取决于应用程序的需求和系统要求。尽管WEB架构的应用范围更广泛，但在特定的应用场景中，C/S架构仍然是一个不错的选择。
无论是C/S架构还是WEB架构，都需要考虑如何保证服务器的可靠性、安全性和可伸缩性。如果您正在开发一个App和服务器之间的应用程序，那么请考虑您需要的架构，确保您的体系结构满足您的需求，同时也可提高您的应用程序的性能、可靠性和安全性。
相关问题拓展阅读：
图解几种常见的软件架构模式
本篇经验将和大家介绍几种常见的软件架构模式，希望对大家的工作和学习有所帮助！
方法/步骤
分层模式
这种模式也称为多层体系架构模式。它可以用来构造可以分解为子任务组的程序，每个子任务都处于一个特定的抽象级别。每个层都为下一个提供更高层次服务。
一般信息系统中最常见的是如下所列的4层。
表示层(也称为UI层)
应用层(也称为服务层)
业务逻辑层(也称为领域层)
数据访问层(也称为持久化层)
使用场景：
一般的桌面应用程序
电子商务Web应用程序
客户端-服务器模式
这种模式由两部分组成：一个服务器和多个客户端。服务器组件将为多个客户端组件提供服务。客户端从服务器请求服务，服务器为这些客户端提供相关服务。此外，服务器持续侦听客户机请求。
使用场景：
电子邮件，文件共享和银行等在线应用程序
主从设备模式
这种模式由两方组成;主设备和从设备。主设备组件在相同的从设备组件中分配工作，并计算最终结果，这些结果是由从设备返回的结果。
使用场景：
在数据库复制中，主数据库被认为是权威的来源，并且要与之同步
在计算机系统中与总线连接的外围设备(主和从驱动器)
管道-过滤器模式
此模式可用于构造生成和处理数据流的系统。每个处理步骤都封装在一个过滤器组件内。要处理的数据是通过管道传递的。这些管道可以用于缓冲或用于同步。
使用场景：
编译器。连续的过滤器执行词法分析、解析、语义分析和代码生成
生物信息学的工作流裂昌
代理模式
此模式用于构造具有解耦组件的分布式系统。这些组件可以通过远程服务调用彼此交互。代理组件负责组件之间的通信协调。
服务器将其功能(服务和特征)发布给代理。客户端从代理请求服务，然后代理将客户端重定向到其注册中心的适当服务。
使用场景：
消息代理软件，如Apache ActiveMQ，Apache Kafka，RabbitMQ和JBoss Messaging
点对点模式
在这种模式中，单个组件被称为对等点。对等点可以作为客户端，从其他对等点请求服务，作为服务器，为其他对等点提供服务。对等点可以充当客户端或服务器或两者的角色，并且可以随时间动态地更改其角色。
使用场景：
像Gnutella和G2这样的文件共享网络
多媒体协议，如P2PTV和PDTP
像Spotify这样的专有多媒体应用程序
事件总线模式
这种模式主要是处理事件，包括4个主要组件：事件源、事件监听器、通道和事件总线。消息源将消息发布到事件总线上的特定通道上。侦听器订阅特定的通道。侦听器会被通知消息，这些消息被发布到它们之前订阅的一个通道上。
使用场景：
安卓开发
通知服务
模型-视图-控制器模式
这种模式，也称为MVC模式，把一个交互式应用程序划分为3个部分，
模型：包含核心功能和数据
视图：将信息显示给用户(可以定义多个视图)
控制器：处理用户输入的信息
这样做是为了将信息的内部表示与信息的呈现方式分离开来，并接受用户的请求。它分离了组件，并允许有效的代码重用。
使用场景：
在主要编程语言中互联网应用程序的体系架构
像Django和Rails这样的Web框架
黑板模式
这种模式对于没有确定解决方案策略的问题是有用的。黑板模式由3个主要组成部分组成。
黑板——包含来自解决方案空间的对象的肆春扒结构化全局内存
知识源——专门的模块和它们自己的表示
控制组件——选择、配置和执行模块
所有的组件都可以访问黑板。组件可以生成添加森握到黑板上的新数据对象。组件在黑板上查找特定类型的数据，并通过与现有知识源的模式匹配来查找这些数据。
使用场景：
语音识别
车辆识别和跟踪
蛋白质结构识别
声纳信号的解释
解释器模式
这个模式用于设计一个解释用专用语言编写的程序的组件。它主要指定如何评估程序的行数，即以特定的语言编写的句子或表达式。其基本思想是为每种语言的符号都有一个分类。
使用场景：
数据库查询语言，比如SQL
用于描述通信协议的语言
app架构思考
整个APP架构上从上到下分为三层，独立于APP的
通用层，通用业务层，业务层
。业务层用来处理上层业务，业务层可以依赖通用业务层和独立于APP的通用层，而且这种依赖消耐是单向的，由上到下的，不能下层依赖上层。
1.首先客户端整体架构的更底层有一个独立于APP的通用层，在这一层里有崩溃的统计，网络的第三方，分享的第三方库等。也就是说这一层的框架或者说架构放在任何一个宴旅APP当中，都可以起到一个底层的支撑作用，它是独立于APP之上的。
2.在独立于APP的通用层之上，有一个通用的业务层。比如说针对当下公司，他有一些通用的基础组件，比如说第三方库的二次封装，toast，刷新控件等，这些往往是和当下公司的业务相关的。但是对于APP来说，各个业务线，对于这些通用控件都有需求，那么我们可以将这些内容沉降到通用的业务层。
3.最上层就是我们的业务模块了，业务层的模块应该按照模块化的设计思想，尽量做到高度的“高内聚，低耦合”。
这么做的好处是为以后可能的组件化做准备，目前APP业务规模较小，等以后APP业务规模增大，需要进行重构做组件化的时候，在业务层加入中间层，进行业务模块之间的解耦，将会方便很多。
目标：单独拎出一个业务，不用做过多修改，然后就能生成一个新的APP。这个就是我们做整体的一个客户端的架构的目的或者说它的意义。
所有模块的开发，包括独立于APP的通用层，通用业务层，业务层，都应该遵循模块化的思想，做到高度的“高内聚，低耦合”。
实现模块化需要注意的点：
关于设计模式晌桥凳的选择，借鉴MVVM设计模式，将业务模块划分为 Controller+View+Model+ViewModel+Service+Constant 六个部分。
关于app和服务器属于什么架构的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。
