2、架构的演变过程

      随着互联网技术迅速发展和演变,不断改变的商业化应用系统越来越复杂,由单一的应用架构到垂直的应用架构,但还是面临的扩容的问题。流量分散在各个系统中,虽然体积可控,但对开发人员和维护人员带来极麻烦。此时,将核心的业务单独提炼出来作为单独的系统对外提供服务。达成业务之间复用,系统也将演变成分布式系统架构。分布式架构是各组件分布在网络计算机上、组件之间仅仅通过消息传递来通信并协调行动。

面向服务的体系架构(SOA)—架构篇-LMLPHP



3、RPC简介

      RPC(Remote Procedure Call Protocol)——远程过程调用协议,它是一种通过网络从远程计算机程序上请求服务,而不需要了解底层网络技术的协议。RPC协议假定某些传输协议的存在,如TCP或UDP,为通信程序之间携带信息数据。在OSI网络通信模型中,RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。

面向服务的体系架构(SOA)—架构篇-LMLPHP


4、分布系统的基础设施

4.1、分布式缓存

        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将内存换成了磁盘,以换取更大的容量。




4.2、持久化储存

        HbaseMySQL、Redis传统的IOE方案: IBM小型机Oracle数据库 EMC持久储存成本很高。传统的数据库提供完整地acid功能,并且提供丰富的内连接外连接关联查询等功能。但是,对于高并发应用来说,有的时候会牺牲关联查询事务数据一致性(降级为最终一致性)。   

       Hbase有更好地伸缩能力,更适合海量数据储存。并发写入十分出色,能够支持多regionserver同时写入。但是其本身对于查询的支持力度有限,比如group by order by join等。   

       Redis是一个key-value类型的数据库,能够支持更高的并发量,而且支持的数据类型也比其他的key-value数据库的数据类型多。



5、消息系统

       JMS即Java消息服务(Java Message Service)应用程序接口,是一个Java平台中关于面向消息中间件(MOM)的API,用于在两个应用程序之间,或分布式系统中发送消息,进行异步通信。Java消息服务是一个与具体平台无关的API,绝大多数MOM提供商都对JMS提供支持。

       比如开源的ActiveMQ 是Apache出品,最流行的,能力强劲的开源消息总线。




6、其他基础设施

      在分布式系统应用中,上面说的系统外,还有搜索引擎系统、文件系统、日志系统、数据仓库等等。




7、系统架构演化历程

7.1、系统架构演化历程-数据库读写分离

       数据库写入、更新的这些操作的部分数据库连接的资源竞争非常激烈,导致了系统变慢。
读写分离,是把对数据库读和写的操作分开对应不同的数据库服务器。主数据库提供写操作,从数据库提供读操作。当主数据库进行写操作时,数据要同步到从的数据库,有效保证数据库完整性。
       Quest SharePlex就是比较牛的同步数据工具,听说比oracle本身的流复制还好,MySQL也有自己的同步数据技术。
       mysql只要是通过二进制日志来复制数据。通过日志在从数据库重复主数据库的操作达到复制数据目的。这个复制比较好的就是通过异步方法,把数据同步到从数据库,读的操作怎么样分配到从数据库上?应该根据服务器的压力把读的操作分配到服务器,而不是简单的随机分配。mysql提供了MySQL-Proxy实现读写分离操作。不过MySQL-Proxy好像很久不更新了。oracle可以通过F5有效分配读从数据库的压力。
      解决方案:mysql有Mysql Proxy、Amoeba、Atlas;




7.2、系统架构演化历程-反向代理和CDN加速

       为了应付复杂的网络环境和不同地区用户的访问,通过CDN和反向代理加快用户访问的速度,同时减轻后端服务器的负载压力。CDN与反向代理的基本原理都是缓存。
       解决方案:Nginx,apache




7.3、系统架构演化历程-分布式文件系统和分布式数据库

       发现分库后查询仍然会有些慢,于是按照分库的思想开始做分表的工作数据库采用分布式数据库(所有节点的数据加起来才算是整体数据),文件系统采用分布式文件系统任何强大的单一服务器都满足不了大型系统持续增长的业务需求,数据库读写分离随着业务的发展最终也将无法满足需求,需要使用分布式数据库及分布式文件系统来支撑。
       分布式数据库是系统数据库拆分的最后方法,只有在单表数据规模非常庞大的时候才使用,更常用的数据库拆分手段是业务分库,将不同的业务数据库部署在不同的物理服务器上。
      解决方案:mysql有mysql cluster 和 Mysql Proxy;mongodb(是一个基于分布式文件存储的数据库);分布式文件系统方案:CEPH、glusterfs、fastDFS、mogilefs 、moosefs,Hadoop实现了一个分布式文件系统(Hadoop Distributed File System)




7.4、系统架构演化历程-使用NoSQL和搜索引擎

 



7.5、系统架构演化历程-业务拆分




7.6、系统架构演化历程-分布式服务

 


8、分布式服务应用会面临哪些问题?




9、分布式架构下系统间交互的5种通信模式


 
 








10-07 14:14