过程:电脑将数据封装上一定的头部,转换成0,1等二进制信号在线路上传播给路由器,路由器根据路由表转发数据,直达目的主机,再拆去头部信息,将纯的数据交给应用程序。
c/s(客户机/服务器)有三个主要部件:数据库服务器、客户应用程序和网络。服务器负责有效地管理系统的资源,其任务集中于:
1数据库安全性的要求
2数据库访问并发性的控制
3数据库前端的客户应用程序的全局数据完整性规则
4数据库的备份与恢复
客户端应用程序的的主要任务是:
1提供用户与数据库交互的界面
2向数据库服务器提交用户请求并接收来自数据库服务器的信息
3利用客户应用程序对存在于客户端的数据执行应用逻辑要求
4网络通信软件的主要作用是,完成数据库服务器和客户应用程序之间的数据传输。
三层C/S结构是将应用功能分成表示层、功能层和数据层三部分。
解决方案是:对这三层进行明确分割,并在逻辑上使其独立。
在三层C/S中,表示层是应用的用户接口部分,它担负着用户与应用间的对话功能。它用于检查用户从键盘等输入的数据,显示应用输出的数据。为使用户能直观地进行 *** 作,一般要使用图形用户接口(GUI), *** 作简单、易学易用。在变更用户接口时,只需改写显示控制和数据检查程序,而不影响其他两层。检查的内容也只限于数据的形式和值的范围,不包括有关业务本身的处理逻辑。
功能层相当于应用的本体,它是将具体的业务处理逻辑地编入程序中。表示层和功能层之间的数据交往要尽可能简洁。
数据层就是DBMS,负责管理对数据库数据的读写。DBMS必须能迅速执行大量数据的更新和检索。现在的主流是关系数据库管理系统(RDBMS)。因此一般从功能层传送到数据层的要求大都使用SQL语言。
在三层或N层C/S结构中,中间件(Middleware)是最重要的部件。所谓中间件是一个用API定义的软件层,是具有强大通信能力和良好可扩展性的分布式软件管理框架。它的功能是在客户机和服务器或者服务器和服务器之间传送数据,实现客户机群和服务器群之间的通信。其工作流程是:在客户机里的应用程序需要驻留网络上某个服务器的数据或服务时,搜索此数据的C/S应用程序需访问中间件系统。该系统将查找数据源或服务,并在发送应用程序请求后重新打包响应,将其传送回应用程序。随着网络计算模式的发展,中间件日益成为软件领域的新的热点。中间件在整个分布式系统中起数据总线的作用,各种异构系统通过中间件有机地结合成一个整体。每个C/S环境,从最小的LAN环境到超级网络环境,都使用某种形式的中间件。无论客户机何时给服务器发送请求,也无论它何时应用存取数据库文件,都有某种形式的中间件传递C/S链路,用以消除通信协议、数据库查询语言、应用逻辑与 *** 作系统之间潜在的不兼容问题。
三层C/S结构的优势主要表现在以下几个方面:
1利用单一的访问点,可以在任何地方访问站点的数据库;
2对于各种信息源,不论是文本还是图形都采用相同的界面;
3所有的信息,不论其基于的平台,都可以用相同的界面访问;
4可跨平台 *** 作;
5减少整个系统的成本;
6维护升级十分方便;
7具有良好的开放性;
8系统的可扩充性良好;
9进行严密的安全管理;
10系统管理简单,可支持异种数据库,有很高的可用性。
服务器集群:服务器集群就是指将很多服务器集中起来一起进行同一种服务,在客户端看来就像是只有一个服务器。集群可以利用多个计算机进行并行计算从而获得很高的计算速度,也可以用多个计算机做备份,从而使得任何一个机器坏了整个系统还是能正常运行。
服务器负载均衡:
负载均衡
(Load
Balancing)
建立在现有网络结构之上,它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。
分布式服务器:
所谓分布式资源共享服务器就是指数据和程序可以不位于一个服务器上,而是分散到多个服务器,以网络上分散分布的地理信息数据及受其影响的数据库 *** 作为研究对象的一种理论计算模型服务器形式。分布式有利于任务在整个计算机系统上进行分配与优化,克服了传统集中式系统会导致中心主机资源紧张与响应瓶颈的缺陷,解决了网络GIS
中存在的数据异构、数据共享、运算复杂等问题,是地理信息系统技术的一大进步。
这个三种架构都是常见的服务器架构,集群的主要是IT公司在做,可以保障重要数据安全;负载均衡主要是为了分担访问量,避免临时的网络堵塞,主要用于电子商务类型的网站;分布式服务器主要是解决跨区域,多个单个节点达到高速访问的目前,一般是类似CDN的用途的话,会采用分布式服务器。
纯手工打字,希望可以帮的到你!
Android App开发中的IPC(进程间通信)无处不在。比如我们使用的 AlarmManager 、 InputMethodService 都是系统为我们提供的服务,处于单独的进程中。如果需要在自己的App进程中使用这些服务就需要进行IPC通信。
除此之外,我们自己的程序中也会存在进程通信的可能(特别是在一些大型APP中)
QQ:未登陆
微信:使用一段时间后:
场景:在Service中开启定位服务,Service处于单独的进程,需要在App主进程或者其他APP中获得定位结果。
服务中提供暴露给其他进程使用的方法并提供一个 ServiceId 注解标记,而服务实现中必须给到相同的 ServiceId 与方法实现,不强制要求 LocationManager 一定需要继承 ILocationManager j接口,但是为了保证方法签名统一建议继承。(不然一个是getLocation,另一个是getLocation2就不好玩了)
在Service进行定位,定位结果在 LocationManager 中记录。在这个Service中使用框架注册 LocationManager 。
不需要返回 Binder 对象,这意味着使用者不需要编写繁琐没任何提示的AIDL文件。
框架内部会提供 comenjoyipcIPCService$IPCServiceX 多个预留Service,用于与其他进程通信,如果一个App存在多个进程都需要提供各自进程的服务,可以使用不同的Service。所以本质上依然是借助的Service+Binder通信,但框架将细节封装隐藏,使用更加简单。
获得结果对象后就能像调用本地方法一样调用远程方法(RPC调用)。
在使用中简化了:
1、不需要自己定义AIDL接口,使用的JavaBean也不要求实现 Parcelable 接口;
2、在客户端不需要直接使用 bindService 获得 Binder 对象;
服务端需要定义暴露服务的接口(ILocationManager),客户端如果是其他APP,则需要将接口类放到自己的源码中(不需要接口实现)。接口中定义的方法就是服务端提供给其他进程使用的方法。
整个框架包含了服务端与客户端两端接口。
在服务进程中会缓存 ServiceId 与对应的服务实现Class对象: 服务表 ,同时服务实现中的所有方法列表也需要进行记录: 方法表 。由于一个服务中可能存在多个方法,所以其数据结构为 Map<Class,Map<String,Method>> ,外层 Map 的key为服务Class,内层 Map 的key则为方法标记。
当客户端需要调用服务时,将 ServiceId 、MethodName以及执行方法需要的参数传递给服务端,服务端查表利用反射 Method#invoke 即可执行服务中的方法。
其中客户端的请求被封装为 Request 对象,服务端响应则封装为 Response 对象
服务端只需要暴露服务接口给其他进程使用,所以服务端只需要调用框架的注册接口 regiest 对服务实现进行注册。( 注册的是服务实现,而不是服务接口 )
注册时,通过反射获得Class上的 ServiceId 即可记录 服务表 。同时利用反射获得Class中所有的public Method即可记录 方法表 。
由于框架本质还是利用Binder来完成通信,为了与其他进程通信,框架内部提供了多个预留的Service。
通信Service会返回一个AIDL生成的Binder类对象
客户端使用 send 方法向服务端发起请求。
服务端接收到请求后的实现:
客户端需要先与服务端建立连接,因此框架中提供了 connect 方法,内部封装 bindService 实现与服务端通信Service( IPCService )的绑定。
唯一需要注意的是:
当完成绑定后,客户端就可以获得服务端通信Service提供的 IIPCService 对象,客户端调用 IIPCService#send 发起请求。
当我们需要获得 Location 。则应该调用 LocationManagergetDefault()getLocation() 。这句调用会需要执行 LocationManager 的两个方法: getDefault 与 getLocation 。
然而这个对象存在服务端,客户端如何获得?
我们可以利用动态代理,在客户端创建一个 "假的" 服务接口对象(代理)。
当我们执行这个代理对象的方法( getLocation )时,会回调 IPCInvocationHandler#invoke 方法,在这个方法中框架会向服务端发起请求: IIPCService#send
而 getLocation 会返回一个 Location 记录定位信息的对象,这个对象会被服务端json序列化发送过来,因此,客户端只需要在此处获得 Method 的返回类型并反序列化即可。
RPC指的是:从客户端上通过参数传递的方式调用服务器上的一个函数并得到返回的结果,隐藏底层的通讯细节。在使用形式上像调用本地函数一样去调用远程的函数。
比如我们使用Ok>
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)