我谈分布式微服务

最近软件开发流行 微服务，很多开源框架不断涌出，其核心用的是阿里的DUBBO框架，网上各类开源框架，很多都没说明白，对有些刚入门的同学 比较模糊，具体开发搭建环境，困难重重

这里我 根据我的网上学习，实践梳理下该框架, 在我以后文章或者视频中 宗旨是把问题或者内容描述的简单易懂，做到看完就能实际操作

首先 这框架是开发理念 不是技术的创新，以前一个项目 放在一个中间件或者 TOMCAT上运行，这就叫一个应用系统

如果有了速度的瓶颈 或者服务器灾难问题，处理起来相当困难，那这里就有人问，不是可以用集群吗，多个相同的应用部署在 不同服务器上面。对，集群只是部分解决这问题，他只能一个应用 一个应用的扩展

而微服务 是可以实现网状的 拓展。，将一个系统 拆分多个 子系统来处理，比如一个进销存系统 有用户注册，用户登录，仓库管理，销售管理

那么微服务根据 业务特性 把 用户注册登录 作为一个项目开发，把仓库管理 作为一个项目开发，把销售管理作为一个项目开发。 这样能解决 注册登录模块出故障，不会影响其他 模块，但问题来了，业务逻辑上 这些应用怎么通信，怎么做事务处理，如果当个模块 还是并发很高 比如1000个人 同时登录这样的 高并发 该怎么处理。

处理这样的问题 就有一套框架存在了，也就是目前流行的 dubbo+zookeeper+acitvemq

zookeeper: 主要功能有负载，服务之间的注册对接

Zookeeper的作用： zookeeper用来注册服务和进行负载均衡，哪一个服务由哪一个机器来提供必需让调用者知道，简单来说就是ip地址和服务名称的对应关系。当然也可以通过硬编码的方式把这种对应关系在调用方业务代码中实现，但是如果提供服务的机器挂掉调用者无法知晓，如果不更改代码会继续请求挂掉的机器提供服务。zookeeper通过心跳机制可以检测挂掉的机器并将挂掉机器的ip和服务对应关系从列表中删除。至于支持高并发，简单来说就是横向扩展，在不更改代码的情况通过添加机器来提高运算能力。通过添加新的机器向zookeeper注册服务，服务的提供者多了能服务的客户就多了

主要功能可以实现横向扩展 ,该服务有开源的后台管理，我也收集了很多

dubbo：是管理中间层的工具,是阿里的核心框架

在业务层到数据仓库间有非常多服务的接入和服务提供者需要调度，dubbo提供一个框架解决这个问题。

注意这里的dubbo只是一个框架，至于你架子上放什么是完全取决于你的，就像一个汽车骨架，你需要配你的轮子引擎。这个框架中要完成调度必须要有一个分布式的注册中心 ,简单的说zookpeer实现对接规则，dubbo实现具体怎么调用

zookeeper和dubbo的关系：Dubbo的将注册中心进行抽象，是得它可以外接不同的存储媒介给注册中心提供服务，有ZooKeeper，Memcached，Redis等。

引入了ZooKeeper作为存储媒介，也就把ZooKeeper的特性引进来。首先是负载均衡，单注册中心的承载能力是有限的，在流量达到一定程度的时候就需要分流，负载均衡就是为了分流而存在的，一个ZooKeeper群配合相应的Web应用就可以很容易达到负载均衡；资源同步，单单有负载均衡还不够，节点之间的数据和资源需要同步，ZooKeeper集群就天然具备有这样的功能；命名服务，将树状结构用于维护全局的服务地址列表，服务提供者在启动的时候，向ZK上的指定节点/dubbo/${serviceName}/providers目录下写入自己的URL地址，这个操作就完成了服务的发布。其他特性还有Mast选举，分布式锁等。

activemq 是apache的产品，主要用于微服务之间的数据通讯，事务处理，有人问题 为什么不用其他的比如HTTP请求，问得好

他们都是有通信的功能，但activemq 更强，速度更快，更安全，就是为事务处理，消息来设计的,所以用activemq, 要感受，具体做个项目就知道了, 但个人钻牛角尖 的话，我认为这种activemq 模式或者所有模式其他数据库事务，都难以实现事务，有大神的话，想具体说下我的想法

dubbo有个缺点，也是优点  测试api时，不能像平常样写个java客户端直接调研，但这样能防止api入侵

如上所述 这套框架比较重，适合互联网应用，商城应用，大并发大流量的应用，要求可用性极高的系统 来使用

如上写的不完善，后续待完善

本人也收集了大量的 微服务开源框架,有需要联系我