分布式部署
目录
什么是分布式系统... 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：当前提供服务的机器出现问题后，需要按照一定的规则，投票选举出新的提供服务的机器，并接管服务
来源：oschina
链接：https://my.oschina.net/u/4269622/blog/3647434