分布式学习（一）初识分布式

分布式学习（一）初识分布式架构

1. 网站应用的演进

自互联网发展以来，网站应用的规模在不断的扩大，为了让网站应用的处理能力增强，单机的应用部署已经不能满足高并发、高可用的要求。

同时，业务的拓展性也使得我们急需一个治理系统确保我们的架构有条不紊的进行。

上图是互联网网站应用的演进，分为如下过程：

单一应用架构

在我们学习初期，往往只考虑整个系统的可用性，通常之开发单个应用，将所有的功能部署在一起，同时不需要太多成本，我们只需要关注数据的增删改查。

垂直应用架构

当访问量逐渐增大，同时为了整个系统的拓展性，我们往往将应用拆分成互不相干的几个应用以提高效率。如MVC框架。

分布式服务框架

当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式服务框架(RPC)是关键。

流动计算架构

当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和治理中心(SOA)是关键。

2. Dubbo 架构初探

dubbo是阿里开源的一个SOA服务治理框架，目前已经托管给了apache，其实质上主要专注RPC远程调用功能。

其架构如上图所示，包含如下组件：

Container 容器

用于不断产生provider

provider 提供者

提供服务供消费者使用，需要在注册中心注册（发送本机IP、端口、应用信息）

Registry 注册工厂

接收提供者的注册，并根据消费者的订阅来选择服务列表发送给消费者应用缓存

Consumer 消费者

向注册中心订阅得到需要的服务，然后执行该服务

Monitor 监视器

监控整个流程的正常执行

那么为什么要这么做呢？为什么不直接让provider和Conumer直接通信，然后出发调用呢？

优点1：

Consumer和Provider解耦，没有了依赖关系，双发都不需要关注对方的状态，全由注册中心管理

优点2：

注册中心可以很方便的进行负载均衡，并且注册中心也可以有多个，保证高可用

3. zookeeper 初探

ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。 —百度百科

好吧，作为初学者我一脸蒙蔽，只能一个词一个词的继续查。。。

分布式应用程序协调服务

作为一个coder，有时候我们并不想去关注一个分布式系统之间的运作，我们只关注我们的业务实现，最理想的，我们希望能把复杂的分布式系统当作一个单机的系统来看待，而分布式应用程序协调服务就是充当了一个协调者的作用，让我们可以尽量将复杂的分布式系统用起来像单机一样。

继续看zookeeper能提供的功能

1. 统一命名服务

zookeeper为每一个应用/服务器都进行了统一命名，便于识别

2. 统一配置管理

为一个集群中的配置文件保持一致性，配置文件修改后能快速同步到各个节点

3. 统一集群管理

zookeeper能实时掌握每个节点的状态并快速做出反应 （观察者模式）

4. 软负载均衡

可以根据节点下服务器的状态进行一定的复杂均衡

看到这里，我们已经大概弄懂了zookeeper能用来干嘛了，实际上，很多的常见中间件都是直接使用zookeeper来进行分布式管理的（Hadoop、Hbase、kafka），关于更为详细的解读，我将在接下来的博客中给出。