Api-gateway服务网关gravitee.io的探索之路（一）

       没有具体场景的技术都是耍流氓。

       先说下公司场景，公司是一家金融公司，各种应用也有十几个，都是这些年积累下来的，团队也是五花八门，本土的，外包的，互相之间经常要对接，调用，每次大家都感觉特别麻烦。说实话来了我就想给它改成微服务式的，一统江湖，不过大家也知道这个难度，团队，资源，太难了。所以干脆，就来个内部的api网关就挺好。很多人吧，都以为api网关是对公司外的，其实则不然，结合具体的场景才是王道。

        那么我们用api网关在内部调用有什么好处？

         一，统一远程调用，不管什么语言什么应用都能支持http吧这年头，不用rest还好意思和人打招呼？应用之间的接口对接是多么的清晰和方便，加上合理的命名，还没用呢就快高chao了。 有人说你们咋不用rpc，效率多高，可是我们不需要啊，因为我们的场景没那么严苛，http也很快。

         二，远程调用的管理，很多人都说原始社会好，什么原始社会可以随便干点啥，那是因为你总把自己想象成优势那方，你想想，要是你每次摘下来一个苹果就让一大个给抢走了，你乐意么。所以，我觉得还是法制社会好，我们的应用也一样啊，你调我接口可以，给钱了么？所以我们要干嘛？权限控制，流量控制。控制到你不得不给钱为止。

          还有就是api的组合，多个合成一个多好。

         三，统计，看看各个应用之间到底调用了多少，速度怎么样，一番统计之后来年的业绩提升有保障了，是节省资源还是提升效率，肯定是都有啊。

         四，排错，最讨厌那些出了问题互相推诿的人，有了api网关，妈妈再也不用担心不知道是谁的问题了，还得用技术解决，谁敢推诿，分分钟拿日志让他明白，小样。

          下来就选型吧，就是Kong，zuul，以及gravitee，一看kong是基于nginx和lua开发的，心里一喜，效率必定牛逼，再看git的star数量也ok，就知道kong肯定不错，为啥我没选，现在的应用都非常讲究可视化，可视化操作非常重要，但是kong的可视化还是差点事，而且我们公司也不要求极致效率，也不是为了对外卖我们的api，再加上对lua的心虚，好吧我最后还是暴露了。

           再说zuul，springcloud家族的东西好不好，好，易用性，文档都不错，可是您那些组件之间绑定的也太死了，我得引入euraka，还有hystrics，关键团队没有熟悉这个的，我倒是研究过，可是没人跟我一起玩啊。

            再然后就看到了gravitee，技术纯java，这个我喜欢，页面逼格一流，纯鼠标操作，正适合我们，终于tm啰嗦完了，可以进入技术的天地，oh my love。

            首先去官网下载zip包，当然也可以git下载，用ide打包，下面放上链接

            https://gravitee.io/

            最新的是1.15，下载下来之后解压完了共有三个文件夹

             1.服务网关本身

              2.服务网关管理web

              3.服务网关ui，跟2前后端分离

              还需要准备什么？当然是数据库了，一个是Mongo，一个是elasticsearch。Mongo用来存储，elasticsearch用来分析，数据库的好处不再多说，去网上查查就可以。

             Mongo和elasticsearch的安装将在下篇开始。