资讯专栏INFORMATION COLUMN

Vert.x入坑须知(2)

xialong / 2473人阅读

摘要:这一点其实是非常不妥的,有潜在的安全问题。这次,在项目中终于采用了以它为基础的集群方案。相反,使用一个周期,但针对每个生成一个一次性的,模拟随机发送。同时,要记得用完之后立即释放。

当初创建简书账号的时候曾立下宏愿,希望保持周更,无奈现实残酷,整个5月都处于忙忙碌碌的状态,居然令这个本来并不算太宏伟的目标难以为继,最终导致5月份交了白卷!【好吧,我承认,是我意志不够坚定,太懒了,;)】

最终的负罪感导致了本文的诞生,同时也意味着一个新坑的开启。作为Vert.x的使用者,我会定期更新获得的经验,希望为同好提供一些小小的帮助,扫除前进的障碍。同时,作为一个懒人和见异思迁者,事先声明,我没有办法保证我的兴趣不会发生转移,所以,我也不知道这个坑能开多久,望大家注意。

那么,让我们进入主题。

HTTPS请求

这是在跟某运营商的NB-IOT平台对接时解决的问题,其实最终的整个代码并不复杂,类似下面(采用双向认证方式):

httpClient = vertx.createHttpClient(new HttpClientOptions()
        .setSsl(true)
        .setPfxKeyCertOptions(new PfxOptions().setPath("xxx.pkcs12").setPassword("xxx"))
        .setTrustStoreOptions(new JksOptions().setPath("xx.jks").setPassword("xxx"))
        .setVerifyHost(false));

基本上跟文档上的例子差不多,值得注意的地方就是最后一行代码:setVerifyHost(false),当时这个运营商的平台也处于测试状态,并没有域名,是自签证书,设置为false,客户端不验证服务端证书的合法性,则可规避这一点,让整个开发可以不受影响继续下去。

JWT的密钥

随着微服务的流行,JWT也变得流行起来,但有一点开发经常忽视的是直接将生成JWT要用到的证书包含在源代码中。这一点其实是非常不妥的,有潜在的安全问题。

一个常识是:开发测试用的证书和产品环境的证书要分开,由不同的人来负责管理!

比如,在dgate中,产品环境的证书由运维通过下面的环境变量指定(例子):

export dgate_key_store=./test1.jceks
export dgate_key_type=jceks
export dgate_key_password=test123

在生成JWT对象时,从环境变量里直接拿这些值,供未来使用。

HTTP Form/Upload请求

这是在实现dgate遇到的需求,小伙伴们强烈要求支持Form提交和文件上传,于是就有了RelayHandler的诞生。它的实际作用就是请求的透传,即将请求内容原封不动的搬到后端服务那里去。

实现很简单,看代码就知道,但在编写测试代码时就遇到了需要发起Form和Upload的问题。这个需求要是放在现在很简单,因为Vert.x从3.4开始提供了WebClient模块,用它可以很轻易的实现这样的需求。

可在当时,这个模块还没有出来咧!那就只能自己动手了,因为并没有那么麻烦,本质上就是按照HTTP协议的要求,向Request写入对应格式的内容就行了。这一点可以从RequestUtils的form和upload方法实现里看出来。

UDP的Socket

这是在另一个项目中遇到趣事,其实既不是需求也不是问题,而是锦上添花,方便调试。在这个项目中,我们用Vert.x实现了一个UDP Server,用户的设备会直接向这个Server发包。在一定的条件下,如时钟不对,Server会向设备发起一个校时命令。

作为负责任的开发,我们当然不会依赖用户的硬件设备来进行调试啦!也就是说,我们自己是实现了一个MockClient的,它完全实现了设备和服务器的通信协议。内测没问题之后就到了联调阶段了,可偏偏我们已经发出了校时命令(终端有输出),但硬件却说没有收到!

要命的是,通过Linux的tcpdump来抓包,居然在UDP Server的地址和端口上没有抓到对应的包!这真是浑身是嘴也说不清啊!而且,自己写的Mock与Server总是能够顺畅的通信!

遇到这么个怪问题那就不得不上网络调试的终极大杀器Wireshark了,看看到底发生了什么。很快,问题定位出来了,下发命令确实已经发出,只不过是从另一个端口发出去的。这是因为写代码时,觉得UDP反正就没有连接的概念,只要有对方的地址信息那就直接发送过去就好了。于是,在发送前重新创建了一个DatagramSocket实例,通过它直接发出去了。

实际的修改也很简单,用UDP Server对应的那个DatagramSocket实例发送就好了。最后的结果当然是皆大欢喜。

与Ignite的集成

我之前不止一次的表达出对于Ignite的喜爱,觉得它比Redis要好(注:最近有所改变,因为Redis提供了对于HpyerLogLog开箱即用的支持,而Ignite则貌似没有。)。这次,在项目中终于采用了以它为基础的Vert.x集群方案。

整个集成和使用并不复杂,这是我们做过的事情:

引入依赖和ignite.xml

在Launcher中强制设置为Cluster模式,简化命令行启动:

@Override
public void beforeStartingVertx(VertxOptions options) {
    //Force to use cluster mode
    options.setClustered(true);
}

为了方便后续获得配置里的缓存,需要对ignite在启动时进行初始化,于是我们写了一个工具类,其主要用处就是在启动前从Vert.x中获得Ignite并保存起来,方便后续按名字获取缓存时直接使用。初始化代码如下(同样是在Laucher里面,但由于要获得Vertx实例,故放在afterStartingVertx里):

if (ignite == null) {
    vertxInstance = vertx;
    ClusterManager clusterManager = ((VertxInternal) vertx).getClusterManager();
    String uuid = clusterManager.getNodeID();
    ignite = Ignition.ignite(UUID.fromString(uuid));
    ...
}

有了Ignite实例之后,其他的功能,如Read/Write Through、Cache事件等等,就是按照Ignite文档的指示来做了。这部分的内容已经属于Ignite的领域且文档也有详细的阐述,这里就不再赘述。

压力测试

作为服务器应用,怎么能不来一把压测来对其性能摸底呢?在实际过程中,新手最容易忘记的问题就是:没有修改操作系统的最大可用句柄数,导致压力还没上来就进行不下去了。

除此之外,用Vert.x自写压测代码时也需要注意:

对于UDP服务器来讲,注意设置足够大小的接收缓存,否则会导致Client的包被丢弃,且没有任何错误提示。表象就仿佛服务器挂了或没有能力处理一样,而实际的压力其实远远没有达到服务器的极限。参见下面的代码:

vertx.createDatagramSocket(
                new DatagramSocketOptions()
                        .setReceiveBufferSize(UDP_RECEIVE_BUFFER_SIZE)
                        .setSendBufferSize(UDP_SEND_BUFFER_SIZE))
                .listen(..., "0.0.0.0", asyncResult -> { ... }

在压测发起端,避免为每个Client生成一个长时间存在的周期Timer。相反,使用一个周期Timer,但针对每个Client生成一个一次性的Timer,模拟随机发送。同时,要记得用完之后立即释放。类似的结构如下:

vertx.setPeriodic(20000, tid -> {
    mockClients.forEach((uid, socket) -> {
        vertx.setTimer(ThreadLocalRandom.current().nextInt(10, 10000)
                , id -> {
                    logger.info("...", uid);
                    send(...);
                    vertx.cancelTimer(id);
                });
    });
});

自此,这段时间积压下来,觉得有必要写写的内容已经全部倾倒完毕,敬请期待下一期(如果真有的话,;))。

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/11261.html

相关文章

  • Vert.x入坑须知(4)

    摘要:主要是避免引入太多的复杂性,并且出于灵活部署的需要。以应用为例,由于实际上是在上执行,若它被阻塞,即导致后续请求全部无法得到处理。因此,最合适的做法就是对于简单业务,采用异步库。本系列其他文章入坑须知入坑须知入坑须知 最开始觉得这个系列也就最多3篇了不起了(因为事不过三嘛),没曾想居然迎来了第四篇! Kotlin 由于最近决定投身到区块链的学习当中的缘故,出于更好的理解它的基本概念,自...

    summerpxy 评论0 收藏0
  • Vert.x入坑须知(3)

    摘要:对于集成测试,直接模拟实际的环境,再加上合适的,目前看来也还不错。这里给出两个例子集成测试单元测试都是基于写的,各位可以体验其酸爽度。好啦,本期内容就此结束,请保持关注,期待下期继续本系列其他文章入坑须知入坑须知 随着Vert.x进化到3.5.0,本系列也迎来了新篇章。 CORS的新变化 对于CORS,搞Web开发(不论你是前端,还是后端)的同志应该不陌生,尤其是如今微服务盛行的时代,...

    CollinPeng 评论0 收藏0
  • Vert.x入坑须知(1)

    摘要:轻量级,部署简单。此外,本文也不是入门文档,而是为了预防陷坑而给出的指导意见,故在阅读本文之前还请先仔细阅读的文档。可视作的一个最小部署和运行单元,简单的说,可类比为。,主,负责部署程序中其他的。严格来讲,之后,上述第一点并不完全正确。 一直以来早有将这些年用Vert.x的经验整理一下的想法,奈何天生不是勤快人,直到最近扶墙老师问起,遂成此文。 选择理由 现在想想,我们应该算是国内用V...

    Turbo 评论0 收藏0
  • 使用Vert.x构建Web服务器和消息系统

    摘要:而不是开始,将服务使用多线程的请求重量级的容器。是启动多个轻便单线程的服务器和流量路由到他们。亮点应用程序是事件驱动,异步和单线程的。通过使用事件总线传递消息通信。为了建立一个消息系统,则需要获得该事件总线。 摘要 如果你对Node.js感兴趣,Vert.x可能是你的下一个大事件:一个建立在JVM上一个类似的架构企业制度。 这一部分介绍Vert.x是通过两个动手的例子(基于Vert.x...

    DrizzleX 评论0 收藏0
  • 和我一起入坑-React-Native-加入Redux的TodoList

    摘要:之前写了一篇没有加入的的小博文。一拆分结构根据自己的习惯和固定套路,拆分目录结构和组件结构。把的导航组件集中放在纯粹是个人习惯。二代码实现入口文件是用来做的数据持久化。添加事项后要通知其他组件更新数据。 读前须知 这个项目是第一次使用Redux的实例,并不具有专业性的理论知识。纯粹分享一次开发过程与心得。之前写了一篇没有加入Redux的React Native ToDoList的小博文...

    LucasTwilight 评论0 收藏0

发表评论

0条评论

最新活动
阅读需要支付1元查看
<