分布式部署

无人久伴 提交于 2020-11-08 13:10:25

分布式部署

目录

什么是分布式系统... 1

为何需要分布式... 1

分布式系统的特点... 1

分布式系统的缺点... 2

什么是分布式部署... 2

什么是分布式架构... 2

架构师需要懂部署吗... 2

架构分布式系统的常见关注点... 2

分布式架构部署的演变... 3

分布式部署给开发带来的问题... 4

模块间的相互调用... 4

统一会话管理... 6

单点登录... 7

一致性更新... 7

分布式事务... 8

高可用性(HA)... 9

 

什么是分布式系统

通俗点说:就是能把系统进行拆分并部署到多台服务器上的系统。(注意区分 分层和集群)

专业点说:分布式软件系统(Distributed Software Systems)是支持分布式处理的软件系统,是在由网络互联的多处理机体系结构上执行任务的系统。常见的有:分布式操作系统、分布式程序设计语言及其编译(解释)系统、分布式文件系统、分布式数据库系统、分布式应用系统等。

为何需要分布式

单台服务器已经无法承受访问压力、大数据处理、高并发访问、高可用性,自动容错、并行、高性能应用……

分布式系统的特点

1:面对高并发、大数据量的处理要求

2:高可扩展性(可伸缩)

3:高性能

4:异构:操作系统、硬件、程序语言等

5:同步、异步操作混杂

6:安全性:授权认证、SSO单点登录、0auth等

7:透明性,如:访问透明、位置透明、并发透明、故障透明、伸缩透明等

分布式系统的缺点

相互调用不便、网络通信的可靠性、网络传输数据的安全问题、系统开发更复杂、测试困难……

什么是分布式部署

简单点说:就是把程序或数据,分散部署到多台物理服务器上,但他们组

合起来,形成一个整体对外提供服务。

什么是分布式架构

简单点说:就是系统的架构和设计,要能支持和满足系统进行分布式部署的需要

架构师需要懂部署吗

必须要懂,不但要懂,还要会规划。程序的架构、设计和实现都要考虑部署。

架构分布式系统的常见关注点

常见的有:可用性、性能、可靠性、可扩展、易管理、成本等。

实际设计中,要根据具体应用,对这些点进行综合考虑和权衡。

分布式架构部署的演变

■1台服务器的最简部署

■分离Web服务器和数据库服务器

■水平增加Web服务器,加入Varnish

■加入分布式的文件系统

■加入缓存服务

■MySq1数据库的主从集群、读写分离

■继续水平增加Web服务器,加入Nginx

■按业务进行缓存分离,缓存集群

■数据库分区、分库、分表

■加入NoSQL数据库

■加入消息系统,进行异步处理

■集群:Web服务器、缓存服务器、文件系统、消息处理系统、数据库、NoSQL等

■对应用进行拆分部署,比如:分层拆分、甚至是功能级的细粒度拆分

■加入F5等硬件设备,加入CDN

■对重要的节点进行HA集群,或者是双机热备,以保障可用性

 

分布式部署给开发带来的问题

■分布式部署会带来很多问题,有很多在开发期间就要考虑到,比如:

1:各个拆分开的模块间如何相互调用

2:单点登录

3:会话的统一管理

4:一致性更新

5:分布式事务

6:关键服务的可用性保障

模块间的相互调用

■Java中常见的远程调用方式:

Socket、Http、TCP、UDP、RPC、RMI、JMS、WebService……

■常见的框架介绍

1:Hessian:类似于RMI,使用二进制消息来进行远程调用。与RMI不同的是,它的二进制消息可以在非Java中使用,它实现了一种跨编程语言的对象序列化方法

2:Burlap:是一种基于XL的远程调用技术,但和其他基于XML的远程技术(如SOAP

或XML-RPC)不同,Burlap的消息结构是尽可能的简单,不需要额外的外部定义

语言(如WSDL)

3:Dubbo:阿里开源的分布式服务框架,通过高性能的RPC实现远程服务的调用,可以和Spring框架无缝集成,其架构类似于ESB。

4:Sprinlg的HttpInvoker:类似于RMI,基于HTTP协议来进行远程调用,使用java的序列化机制,要求客户端和服务端都是基于Java的

5:WebService

■方案的选择

一:如果系统全部为内部可控的

1:量级不太大,可以考虑使用Hessian/Burlap

2:量级较大,且交互要求较高,那么dubbo是一个现成、成熟的选择

缺点:需要很多额外的成本,比如学习成本,按需改进的成本等

3:交互要求并不高,主要是相互调用的需求,可以考虑自己实现

优点:完全按需定制,完全可控,升级、改进和完善都方便

缺点:需要投入开发成本,且完善成熟有一个过程

二:系统包含很多外部的应用,不能全部可控,且很多异构的系统

1:如果要求不是很复杂的话,WebService是不错的选择

2:如果要求非常复杂,且涉及很多业务流,那就选择一个ESB平台

■更多需要考虑的问题

1:长连接,连接池,可以考虑HttpClient

2:高并发,多线程池,可以考虑使用apache的common-pool

3:快速的网络传输,可以考虑使用NI0,比如:Mina框架,Netty框架等

4:大数据量,数据压缩传输,可以考虑Java的GZip

5:可用性、稳定性、容错

6:分布式的事务

7:访问安全、数据安全等

8:服务的集群,服务的注册和管理等

统一会话管理

■解决方案

1:根据IP或者Cookie来映射访问同一服务器,如:Nginx的IP_Hash,nginx-

upstream-jvm-route等

2:采用统一的会话管理,可以把会话数据存放在公共的地方,比如Memcached

(1)自行实现

(2)结合框架去实现,比如使用Shiro

3:把会话序列化后,存放到客户端Cookie里面

■更多的问题
1:如果用户关闭了Cookie
2:Cookie数据的安全性
3:跨域访问Cookie
4:公共缓存的规划、集群和数据维护

单点登录

跟EAI中的SSO相比,这里所说的单点登录是很简单的,算不上是“真正”的SSO

1:本身就是一个系统,只有一套用户和权限系统

2:对用户的验证方式是统一的

3:都是内部系统,相互信任,所以也就不用验证是否可访问系统了

■解决方案

1:简单的:使用Shiro的统一会话管理,实现单点登录

2:稍麻烦些的:使用Shiro+CAS来实现

3:更麻烦的:使用专业的SSO框架或产品

一致性更新

■分布式的一致性介绍

对于一致性,可以分为从客户端和服务端两个不同的视角。从客户端来看,一致性指的是并发访问时更新过的数据如何获取的问题;从服务端来看,则是更新的数据如何复制分布到整个系统,以保证数据最终一致。一致性是有并发读写才有的问题,因此在理解一致性的问题时,一定要注意结合考虑并发读写的场景。

■CAP的最终一致性

从客户端角度,并发访问时,更新过的数据在不同进程如何获取的不同策略,决定了不同的一致性。

对于关系型数据库,要求更新过的数据能被后续的访问都能看到,这是强一致性;如果能容忍后续的部分或者全部访问不到,则是弱一致性;如果经过一段时间后要求能访问到更新后的数据,则是最终一致性。

■常见的解决方案

一:有一个公共的数据库

1:单点部署,也就是整个系统中只有一个地方能修改这个数据

2:采用版本控制

二:分散到多个数据库

1:可以把问题简化成为只有一个数据库的情况

2:采用预分配数据,动态进行逻辑调整

分布式事务

■解决方案

1:同一个Web服务器,多个数据库,可以使用Atomikos

2:跨越多个Web服务器的事务,如果远程调用支持事务传播,那么使用JTA就可以;如果不支持事务传播,就尽量转化为一个web服务器的情况

3:自行开发事务逻辑事务管理器

4:采用业务补偿回滚的方式

5:重新设计和规划

高可用性(HA)

■解决方案

可以使用Keepalived/Heartbeat等类似的软件

■什么是HA

HA(High Available),高可用性群集,指的是通过一组计算机系统提供透明的冗余处理能力,从而保证系统服务高度的连续可用。

■几点说明

1:HA通常是软件和硬件相结合的集群方案,是自动且透明的

2:只有硬件的方案不是HA,那是热备,通常是人工的切换备用机

3:HA通常由软件检测故障,一旦故障发生立即切换服务到集群中正常的服务上,通过提供故障恢复,实现最大化系统和应用的可用性

4:HA在故障恢复的切换过程中,会有短暂的服务暂停的过程,因为选举新的服务器,以及资源转移都需要一定的时间,当然这个时间很短

5:HA的衡量指标通常有:平均无故障时间(MTTF),平均维修时间(MTTR),可用性=MTTF/(MTTF+MTTR)

■HA的几种常见部署模式

1:主从方式:两台服务器,一台为主,另外一台为备份服务器

2:对称方式:两台服务器,互为备份

3:多机方式:多台服务器,故障时切换至其中一台

■HA的基本实现原理

1:提供虚拟IP给外部访问

2:节点之间通过心跳或信息报文来确定健康状态

3:节点之间通讯通常会加密,以防止非法主机加入

4:当前提供服务的机器出现问题后,需要按照一定的规则,投票选举出新的提供服务的机器,并接管服务

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!