分布式部署

分布式部署

目录

什么是分布式系统... 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：当前提供服务的机器出现问题后，需要按照一定的规则，投票选举出新的提供服务的机器，并接管服务