想做一篇微服务框架的学习
zookeeper是hadoop框架的一部分，用于提供命名空间和分布式协调服务。但它的运行不依赖于hadoop或者其他组件。因此，在微服务框架中使用的也比较频繁。
比如在当前公司实习遇到的大数据项目，本质上也是一种微服务框架。
---什么是微服务框架？
回答转自知乎
微服务框架强调的第一个重点就是业务系统需要彻底地组件化和服务化，原有的单个业务系统会拆分成多个可以独立开发、设计、运行和运维的小应用。这些应用之间通过服务完成交互和集成。且每个小应用从前端web ui，到控制层，逻辑层，数据库访问，数据库都是完全独立的一套。每个小应用除了完成自身本身的业务以外，重点是还需要消费外部其他应用暴露的服务，同时也将自身的能力向外发布服务。
如果用一句话来谈SOA和微服务的区别，就是微服务不再强调传统SOA架构里面比较重的ESB企业服务总线，同时SOA的思想进入到单个业务系统内部实现真正的组件
------------微服务框架优点与不足
单体应用带来的困难有哪些？
1）系统复杂：内部多个模块紧耦合，关联依赖复杂，牵一发而动全身
2）运行困难：变更升级的影响分析困难，任何一个小小的修改都可能导致单体应用整体出现故障
3）无法扩展：无法拆分部署，出现性能瓶颈后往往只能增加服务器或者增加集群节点，但DB问题难解决
而微服务框架正好对这样一些问题有很好的解决办法。
微服务框架记住下面一些重点：1.足以构成一个小应用；2. 服务之间仅仅通过service api进行访问 3. 运行在云虚拟机或者更轻的Docker容器【一个开源的应用容器引擎，目前不是特别懂这个东西】上
API--这是微服务框架中需要考虑的一个重要问题，用更加轻量和高性能的方式来解决微服务的管控和治理问题。对于负载均衡，缓存，路由，访问控制，服务代理，监控，日志等都是需要重点考虑的。
-----------API构建微服务
下面有举个栗子说明
引入场景，一个亚马逊网址的手机APP订单查看页面，如果是一个单体应用，那么所有的页面都通过单体应用统一的地址提供多个service API获取。如果是转换为微服务架构后可以看到对于会员管理，商品管理，订单管理，财务结算等，拆分到了不同的模块当中，需要从不同的地址调用不同的微服务。
在这里我们对于客户端和微服务端点对点的通信提出了如下三个问题:
1. 问题一：客户端暴露的需求和每个微服务暴露的细粒度API不匹配
2. 问题二：部分服务使得协议对web并不友好，如二进制RPC或AMQP消息等
3. 问题三：微服务架构难以重构，比如服务拆分和服务组合的场景
API网关为客户端提供了接入服务器的统一入口，很容易想到设计模式中的Faccade模式。它可能还具备负载均衡等等一系列能力。客户端的所有请求都必须通过API网关，再转发到对应的微服务上，API网关经常会通过协调多个微服务并合并结果来处理一个请求，它可以在web协议和内部协议之间进行转换
API网关还能为用户定制API，比如API网关可以提供一个端点[/productdetails?productid=xxx]
对于API网关的优点，其实是类似传统ESB企业服务总线的优点，即实现服务透明，同时对于服务运行中的日志，安全，路由，缓存等问题进行统一的配置和处理，而不需要每个API实现时都去考虑，如ALI开源的Dubbo服务总线即可以看做一个API网关的实现。
API网关和ESB的一些重要区别在于API网关更加地轻量和高性能，它不需要去考虑太多遗留系统和诸多协议的适配，其次也不需要考虑服务集成过程中大量数据的转换和映射。同时为了提升网关的性能，一般API网关在实现过程中不会去记录详细的数据传输日志，或者类似于Dubbo架构数据传输根本就不会经过API网关。
