面向服务的架构(service-oriented architecture)是Gartner于2O世纪9O年代中期提出的面向服务架构的概念。2002年的l2月,Gartner提出“面向服务的架构(SOA)”是“现代应用开发领域最重要的课题”之后。国内外计算机专家、学者掀起了对SOA的积极研究与探索。
在分布式的环境中,将各种功能都以服务的形式提供给最终用户或者其他服务。如今,企业级应用的开发都采用面向服务的体系架构来满足灵活多变,可重用性高的需求。
随着互联网技术迅速发展和演变,不断改变的商业化应用系统越来越复杂,由单一的应用架构到垂直的应用架构,但还是面临的扩容的问题。流量分散在各个系统中,虽然体积可控,但对开发人员和维护人员带来极麻烦。此时,将核心的业务单独提炼出来作为单独的系统对外提供服务。达成业务之间复用,系统也将演变成分布式系统架构。分布式架构是各组件分布在网络计算机上、组件之间仅仅通过消息传递来通信并协调行动。
RPC(Remote Procedure Call Protocol)——远程过程调用协议,它是一种通过网络从远程计算机程序上请求服务,而不需要了解底层网络技术的协议。RPC协议假定某些传输协议的存在,如TCP或UDP,为通信程序之间携带信息数据。在OSI网络通信模型中,RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。
Memcache 高性能对象缓存系统,在内存中维护一个巨大的基于key-value的hashtable。可以用来缓存任何数据。(对象通过序列化后,转换成二进制缓存)当空间不够用的时候采用LRU算法淘汰数据。网络连接处理采用libevent,高效低耗。memcache采用的是基于tcp连接的memcache协议,协议可以承载文本行和结构化数据,文本行主要用来传输指令,结构化数据主要用来传输数据。 另外一种做法是讲session缓存在一个集群上面,例如memcache集群。这样系统的吞吐量高,而且有利于对session的刷新(session都是有有效期的,需要定期刷新),但是缺点也显而易见: 一旦cache集群重启,所有内存里面的session将全部丢失。
Redis是一个高性能的key-value数据库,也可以做缓存,redis丰富的数据结构,其hash,list,set以及丰富的数据结构和超高的性能以及简单的协议,让Redis能够很好的作为数据库的上游缓存层。但是我们会比较担心Redis的单点问题,单点Redis容量大小总受限于内存,在业务对性能要求比较高的情况下,理想情况下我们希望所有的数据都能在内存里面,不要打到数据库上,所以很自然的就会寻求其他方案。 比如,SSD将内存换成了磁盘,以换取更大的容量。
Hbase、MySQL、Redis传统的IOE方案: IBM小型机Oracle数据库 EMC持久储存成本很高。传统的数据库提供完整地acid功能,并且提供丰富的内连接外连接关联查询等功能。但是,对于高并发应用来说,有的时候会牺牲关联查询事务数据一致性(降级为最终一致性)。
Hbase有更好地伸缩能力,更适合海量数据储存。并发写入十分出色,能够支持多regionserver同时写入。但是其本身对于查询的支持力度有限,比如group by order by join等。
Redis是一个key-value类型的数据库,能够支持更高的并发量,而且支持的数据类型也比其他的key-value数据库的数据类型多。
JMS即Java消息服务(Java Message Service)应用程序接口,是一个Java平台中关于面向消息中间件(MOM)的API,用于在两个应用程序之间,或分布式系统中发送消息,进行异步通信。Java消息服务是一个与具体平台无关的API,绝大多数MOM提供商都对JMS提供支持。
比如开源的ActiveMQ 是Apache出品,最流行的,能力强劲的开源消息总线。
在分布式系统应用中,上面说的系统外,还有搜索引擎系统、文件系统、日志系统、数据仓库等等。
描述:为了应对日益复杂的业务场景,通常使用分而治之的手段将整个系统业务分成不同的产品线,应用之间通过超链接建立关系,也可以通过消息队列进行数据分发,当然更多的还是通过访问同一个数据存储系统来构成一个关联的完整系统。
纵向拆分: 将一个大应用拆分为多个小应用,如果新业务较为独立,那么就直接将其设计部署为一个独立的web应用系统、纵向拆分相对较为简单,通过梳理业务,将较少相关的业务剥离即可。 横向拆分: 将复用的业务拆分出来,独立部署为分布式服务,新增业务只需要调用这些分布式服务、横向拆分需要识别可复用的业务,设计服务接口,规范服务依赖关系。request/response模式(同步模式):客户端发起请求一直阻塞到服务端返回请求为止。
Callback(异步模式):客户端发送一个RPC请求给服务器,服务端处理后再发送一个消息给消息发送端提供的
callback端点,此类情况非常合适以下场景:A组件发送RPC请求给B,B处理完成后,需要通知A组件做后续处理。
Future模式:客户端发送完请求后,继续做自己的事情,返回一个包含消息结果的Future对象。客户端需要使用返回结果时,使用Future对象的.get(),如果此时没有结果返回的话,会一直阻塞到有结果返回为止。
Oneway模式:客户端调用完继续执行,不管接收端是否成功。
Reliable模式:为保证通信可靠,将借助于消息中心来实现消息的可靠送达,请求将做持久化存储,在接收方在线时做送达,并由消息中心保证异常重试。来源: http://blog.csdn.net/javawebrookie/article/details/61419785