漏桶算法 java实现-java实现旋转门算法

2017年微服务在国内火的一塌糊涂，无论是BAT企业还是初创型公司，无不在践行着微服务，就好像如果系统不是采用微服务架构就不是搞开发一样，那么到底什么样的公司和系统适合实施微服务架构，微服务架构的整体体系是什么，如何实施微服务架构，本文作为微服务系列的第一篇文章，把在项目中的一些使用的一些心得和坑整理成文分享出来。

一、微服务适合的场景

我们先来了解一下什么是微服务，微服务在《Spring Cloud微服务实战》书中有如下一段定义：

微服务是将一个原本独立的系统拆分成多个微小型服务，这些小型服务都在各自独立的进程中运行，服务之间通过基于HTTP的RESTful API进行协作。被拆分成的每一个小型服务都围绕着系统中的某一项或一些耦合度较高的业务功能进行构建，并且每个服务都维护着自身的数据存储、业务开发、自动化测试案例以及独立部署机制。由于有了轻量级的通信协作基础。

在日常项目中，我们常常会碰到项目越做越大，越做越臃肿，当项目大到一定程度就会出现以下问题：

1、有些业务模块是非常重要且常用的，有些是不常用的，但在整个系统中一旦其中一个不常用模块出现问题可能会导致整个系统不可用。

2、所有业务都在一个项目里面，不同客户对不同业务模块的需求和取舍都不同，每个业务模块也不能独立出来复用，这样就导致一个项目改来改去N多个版本，版本管理起来非常麻烦。

3、所有的业务在一个项目里面，团队所有的人在同一个项目中修改，哪怕一个小小的修改，都需要进行全量的测试，测试苦不堪然，工作效率极其低下，版本迭代越来越慢。

4、所有的业务打包在一个应用容器下运行，无法针对使用量大的业务进行合理的扩容，只能一股脑的全部扩容，极大的浪费了系统资源，一个业务挂了，所有的业务都无法继续进行。

5、多个系统面临使用同一个数据时候，由于系统的边界划分不明确，各个团队间独立作战，缺少沟通，往往会出现一份各种同步来同步去，又没有有效的机制去保证同步数据的及时性和准确性，造成了各个系统的数据不一致，其影响性是灾难性的。

当你所在的项目出现以上问题，并呈现越发放大，一发不可收拾的地步的时候，微服务架构如同病中的一剂良药，可以有效了帮助你解决和规避上述问题。

微服务把原本独立的系统按照业务进行拆分，每个业务独立成为一个个微小的服务，服务之间通过契约协议进行协作，服务与服务约定接口协议及通信方式，如果采用微服务架构，那么就可以按照业务独立安排开发团队，各开发团队互相不受影响，各服务拥有自身独立的数据库、应用、接口及运行环境，可有针对性的根据不同服务的用途、性质进行有效的扩容及容灾策略。

二、微服务整体体系

一个完整的微服务体系，个人认为需要包含以上部分，这张图来自于极客时间，拿来用用，归纳的很完整的，

注册中心：在spring cloud 体系中，注册中心选用eureka是最佳搭配了，eureka经过Netflix大规模的生产验证，已经相对成熟和完善了，当然spring 本身也提供了一个Consul也是不错的选择。

配置中心：spring cloud 自带的spring cloud config 个人认为算不上生产级，只是提供了一个简单的集中式的配置管理，很多治理的能力都是需要后续自行扩展的，在小型的微服务场景下可以试用，国内在这一块开源比较好的是携程的Apollo,它在携程的项目中经过了生产的验证，具备高可用、配置准实时生效（无需重启服务）配置审计、版本化管理，以及多环境多集群多机房支持，最重要的是它和spring boot、cloud结合的非常好。

服务网关：服务网关在微服务中是不可或缺的一块，在spring cloud 体系一般选用zuul，zuul 也是netflix开源出来的，也是经过生产级的验证，在稳定性和性能方面还是有所保障的，而是我们这篇接下来说的重点。

三、网关应具备的功能

随着微服务的兴起，API网关也成为微服务的标配，API Gateway（APIGW / API 网关），顾名思义，是出现在系统边界上的一个面向API的、串行集中式的强管控服务，这里的边界是企业IT系统的边界，主要解决统一认证、报文转换、访问统计等问题，那么一个网关到底应该具备哪些功能呢？

更细的来说，一个网关要具备以下功能特性

* 性能：API高可用，负载均衡，容错机制。

* 安全：权限身份认证、脱敏，流量清洗，后端签名（保证全链路可信调用）,黑名单（非法调用的限制）。

* 日志：日志记录（spainid,traceid）一旦涉及分布式，全链路跟踪必不可少。

* 缓存：数据缓存。

* 监控：记录请求响应数据，api耗时分析，性能监控。

* 限流：流量控制，错峰流控，目前有漏桶算法、令牌桶算法也可以定制限流规则。

* 灰度：线上灰度部署，可以减小风险。

* 路由：动态路由规则。

* 静态：静态资源代理

* 协议：多协议支持，不同协议的数据进行转换

四、微服务网关的选型

目前做网关主流的有反向代理Nginx，这个用于做微服务网关不合适漏桶算法 java实现，具体怎么不合适大家可以脑补以下。另外还有一个Kong它是基于Nginx基础开发了的，有开源版本和商用版本，有非常多的插件，在性能和功能也都还可以，可惜不是用java开发的，用Lua语言这方面的程序员应该在市面上还是比较少的把。

在java领域和spring cloud 整合的比较好的就两个 ，netflix的zuul 和spring 官方的gateway，zuul已经经过netflix的生产验证，在性能方面是没有特别突出漏桶算法 java实现，但是也能凑合着用，spring 官网的gateway 2017年才刚出来，目前应该还没有几家公司真正用在生产中把。所以如果你的微服务技术栈是spring cloud的话 ，用zuul其实是不二之选，用zuul 建议使用2.0版本，因为2.0版本支持异步调用，这样可以提高网关的吞吐量，记住是吞吐量不是响应时长。