分布式远程调用服务框架技术学习
注：本篇所有架构图，服务框架理论知识均来源于互联网。
知识点：远程调用服务的技术原型就是SOA（Service-Oriented Architecture）
网站架构总图
远程调用架构图：
远程调用管理组件是一个独立的服务系统，为了保证该系统的稳定性，它也一定是一个分布式的系统，但是这个分布式系统和Web的分布式系统是完全不同的分布式系统，传统Web应用集群是基于HTTP协议的无状态的特点设计的，因为每个HTTP请求都是一个独立的事务，不同请求之间是没有任何关系的，所以我们可以将Web应用部署到不同服务器上，请求不管到了那台服务器，都能正常的给用户提供相应的服务，但是Web应用的session机制是有状态的，所以传统Web集群都是要有session同步的操作，大型网站往往会把session功能抽象为独立的缓存系统，但是这里的远程调用管理组件的集群原理或者说分布式原理是有别于Web应用集群分布式原理的，远程调用管理组件可以当做一个注册中心，它会记录下服务提供者和服务调用者的相关信息，并将这些信息推送给服务提供者或者服务调用者，为了保证系统的执行效率，这些注册信息都是记录在内存里，我们试想下，如果这些注册信息丢失，整个系统将会不可用，因此远程调用管理组件的集群是一种保证数据可靠性和服务提供健壮性的集群，而不是建立在HTTP无状态特性基础上的集群。我们这里假想下远程调用服务的集群运行场景，我们假如有5台服务器作为远程调用服务运行的服务器，那么每台服务器都必须有注册信息的冗余备份，当服务运行时候其中一台服务器发生了故障，这台故障的服务器上的数据不会丢失，此外集群应该还要有一个检查故障的机制，当发现有台服务器不可用的时候，能及时剔除该服务器，而zookeeper就是解决这种问题的技术框架。此外除了保证系统的稳定性和可用性外，集群的数据存储方式也是很重要的，前面我讲到集群的数据存储要有一个冗余机制，除了冗余机制还要有一个很适合快速访问和读写的数据模型，而zookeeper正好包含这种数据模型，所以这个远程调用服务是一个很适合zookeeper应用的场景
远程调用管理组件还有一个心跳机制，心跳机制的作用是检测服务提供者的健康性及服务提供者是否可用，服务提供者启动时候会将自己的注册信息发送给远程调用管理组件，这个注册信息里包含服务端的ip地址和端口号，远程调用管理组件会启动一个线程，根据定时对这个ip地址和端口号去ping这个ip和端口号对应的应用是否可用，如果不可用远程调用管理组件会反复尝试几次，这个次数和多久检测心跳都是可以配置的，如果反复几次还是不通，那么就认定该服务不可用了。
远程调用服务还需要一个重要的技术就是通讯技术，这里的通讯技术我推荐netty，netty是个非常好的选择，讲到通讯是个复杂的课题，如果以后有空我再做详细介绍，通讯层的东西是封装到服务提供者和服务调用者引入的jar包里，但是通讯的ip地址和端口号则是需要远程调用管理组件推送过来的。
淘宝HSF远程调用服务的架构设计
设计的知识点有：负载均衡(failover,随机规则，第七层路由，路由规则，权重规则，TP限流)
软负载体系(负载均衡算法(随机，权重) )
淘宝可伸缩高性能互联网架构
设计到的知识点：
1, 淘宝session框架
集群，不仅有负载均衡，更重要的是要有失效恢复failover,比如tomcat采 用的集群节点广播复制，jboss采 用的配对复制等session状 态复制策略，
淘宝的session框架采用的是client cookie实现，主要将状态 保存到了cookie里 面，这样就使得应用节点本身不需要保存任何状态信息，这样在系统用户变多的时候，就可以通过增加更多的应用节点来达到水平扩展的目的.
2, 淘宝系统拆分
系统对整个系统进行了水平和垂直两个方向的拆分，水平方向上，按照功能分为交易，评价，用户，商品等系统，同样垂直方向上，划分为业务系统，核心业务 系统以及以及基础服务，这样以来，各个系统都可以独立维护和独立的进行水平伸缩，比如交易系统可以在不影响其它系统的情况下独立的进行水平伸缩以及功能扩展。
3，数据库拆分（TDDL）
一个大型的互联网 应用必然会经过一个从单一DB server,到Master/salve,再到垂直分区（分 库），然后再到水平分区（分表，sharding）的过程，而在这个过程中，Master/salve 以 及垂直分区相对比较容易，对应用的影响也不是很大，但是分表会引起一些棘手的问题，比如不能跨越多个分区join查 询数据，如何平衡各个shards的 负载等等，这个时候就需要一个通用的DAL框架来屏蔽底层数据存储对应用逻辑的影响，使得底层数据的访问对应用透明化。
淘宝根据自己的业务特点也开发了自己的TDDL框架，此框架主要解决了分库分表对应用的透明化以及异构数据库之间的数据复制。
4，异步通信（Notify）
统之间异步通信以后可以大大提高系统的响应时间，使得每个请求的响应时间变短，从而提高用户体验，因此异步在 提高了系统的伸缩性以及可用性的同时，也大大的增强了请求的响应时间
5，非结构化数据存储 (NOSQL)
NOSQL。我们都知道根据CAP理论，一致性，可用性和分区容错性3者 传统的关系数据采用了ACID的事务策略，而ACID的 事务策略更加讲究的是一种高一致性而降低了可用性的需求，但是互联网应用往往对可用性的要求要略高于一致性的需求，这个时候我们就需要避免采用数据的ACID事 务策略，转而采用BASE事 务策略，BASE事 务策略是基本可用性，事务软状态以及最终一致性的缩写，通过BASE事务策略，我们可以通过最终一致性来提 升系统的可用性，这也是目前很多NOSQL产品所采用的策略，包括facebook 的cassandra,apache hbase,google bigtable等，这些产品非常适合一些非结构化的数据，比如key-value形 式的数据存储，并且这些产品有个很好的优点就是水平伸缩性。
Dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。
其核心部分包含:
1,远程通讯: 提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。
2,集群容错: 提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。
3,自动发现: 基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。
Dubbo能做什么？
1,透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。
2,软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。
3,服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。
Dubbo涉及的知识点：
1，服务注册：
对于服务提供方，它需要发布服务，而且由于应用系统的复杂性，服务的数量、类型也不断膨胀；对于服务消费方，它最关心如何获取到它所需要的服务，而面对复杂的应用系统，需要管理大量的服务调用。而且，对于服务提供方和服务消费方来说，他们还有可能兼具这两种角色，即既需要提供服务，有需要消费服务。
通过将服务统一管理起来，可以有效地优化内部应用对服务发布/使用的流程和管理。服务注册中心可以通过特定协议来完成服务对外的统一。Dubbo提供的注册中心有如下几种类型可供选择：
a，Multicast注册中心 b，Zookeeper注册中心 c，Redis注册中心 d，Simple注册中心
2, 远程通信与信息交换
远程通信需要指定通信双方所约定的协议，在保证通信双方理解协议语义的基础上，还要保证高效、稳定的消息传输。Dubbo继承了当前主流的网络通信框架，主要包括如下几个：
a:Mina b:Netty c:Grizzly
3,Dubbo支持多种协议
Dubbo协议
Hessian协议
HTTP协议
RMI协议
WebService协议
Thrift协议
Memcached协议
Redis协议
A,最底部的为dubbo服务的集群（服务者）,即对外界暴露服务，dubbo本身就
是支持集群模式，而且支持多种通信协议(dubbo,rmi,http...)。主要部署核心的业务代码。
B,右边的注册中心，dubbo提供了也是提供了多种注册中心， zookeeper注册中心是其中一
种同样无单点故障问题，dubbo服务依赖于注册中心，在dubbo服务启动时，回向注册中心
去进行一个服务的注册（发布服务）。对服务进行管理。
C,接下来看tomcat集群,主流的tomcat集群搭配(nginx+tomcat+redis/memcache)都是非常
的简单的，所有控制器都放到其中，控制器中依赖的服
务实现是来之后端dubbo集群的，而dubbo服务是注册到zookeeper上的，只需要连上注册
中心就获取到了我们所需要的服务，并且进行调用。主要是对控制器层做一个集群，提高
可用性和性能。
D,tomcat左下角是一个NOSQL集群，主要是处理一个session的共享/分布式缓存。
E,最上层是nginx的集群主要是把静态页面全都放到nginx中即可，注意，如果使用restful风
格，并且使用JS MVC框架的话！完全不需要把页面部署到tomcat中，让tomcat只跑控制代
码即可。restful架构的话页面时全静态，数据全都走json的方式即可。
F,上诉扩展瓶颈在nginx上，解决的方式就算使用在nginx之前套LVS吧，或者硬件做一个负载。
