首页 文章 精选 留言 我的

精选列表

搜索[API增强],共10008篇文章
优秀的个人博客,低调大师

Torna Swagger 插件 1.2.3 发布,Swagger 增强利器

Torna Swagger插件 1.2.3 发布,本次更新内容如下: 修复ResponseEntity无泛型参数报NPE问题 支持枚举参数 最新版maven依赖: <!-- torna swagger 插件 --> <dependency> <groupId>cn.torna</groupId> <artifactId>swagger-plugin</artifactId> <version>1.2.3</version> <scope>test</scope> </dependency> → 演示地址 关于Torna Swagger插件 Torna配套的文档生成插件,可以把本地swagger文档信息推送到Torna平台,让平台统一管理。 让Torna管理文档的好处有: 项目不需要集成swagger-ui等组件,只需要依赖swagger注解即可 Torna提供了调试、Mock等功能,并且可以区分多环境调试(开发、测试、生产) 调试界面更友好,比swagger自带的UI更容易使用 可以自由组合文档,将不同项目的文档聚合在一起,然后分享出去 插件使用说明

优秀的个人博客,低调大师

撸了一个 Feign 增强包

前言 最近准备将公司的一个核心业务系统用 Java 进行重构,大半年没写 Java ,JDK 都更新到 14 了,考虑到稳定性等问题最终还是选择的 JDK11。 在整体架构选型时,由于是一个全新的系统,所以没有历史包袱,同时团队中也有多位大牛坐镇,因此我们的选项便大胆起来。 最终结果就是直接一把梭,直接上未来的大趋势:Service Mesh,直接把什么 SpringCloud、Dubbo 这类分布式框架全部干掉。 本次的重点不是讨论 Service Mesh 是什么、能解决什么问题、为什么选择它,毕竟我也在学习阶段,啥时候整明白线上也稳定了再和大家来交流。 问题 既然方向定了就开始实际撸码了,不过刚一开始就验证了”理想很丰满、现实很骨感“; 由于我们去掉了 SpringCloud 和 Dubbo 这类框架,服务的注册、发现、负载均衡等需求全部都下沉到 Service Mesh 中提供了。 但对于开发来说依然希望可以调用本地方法的方式来调用远程服务,这在 SpringCloud 这类框架中是很容易实现的,框架本身就有很好的支持。 回到我们这个场景,需求其实很简单,就是想达到 SpringCloud 中的 Feign 这样的声明式+注解的方式调用。 @Autowired private StoreClient client ; Store store = client.update(1, store) 使用 spring-cloud-openfeign 这个包其实就能实现上述的需求了,但这样会引入一些我们根本不会使用的 SpringCloud 的相关依赖,让人感觉”不干净了“;同时也和 Service Mesh 的理念相反,其中的一大目的就是要降低这类框架的侵入性。 其实 spring-cloud-openfeign 的核心就是 Feign,本身它也是可以开箱即用的,所以便尝试看 Feign 自己是否支持这样的用法。 通过官方文档可以得知:是可以定义接口的形式来调用远程接口的,但它本质上是不依赖其他库便可以使用,所以它本身是没有和 Spring 整合也是合情合理,但也就造成了没有现成库可供我们使用。 我们自然是不想写上图红框处的代码的,希望所有接口直接注入就可以使用。 使用 因此结合以上的需求便有了这个库 feign-plus 它的使用流程其实就是翻版的 spring-cloud-openfeign: @FeignPlusClient(name = "github", url = "${github.url}") public interface Github { @RequestLine("GET /repos/{owner}/{repo}/contributors") List<GitHubRes> contributors(@Param("owner") String owner, @Param("repo") String repo); } 在 SpringBoot 入口进行扫描: @SpringBootApplication @EnableFeignPlusClients(basePackages = "top.crossoverjie.feign.test") public class DemoApplication { public static void main(String[] args) { SpringApplication.run(DemoApplication.class, args); } } 在 Spring 上下文中直接注入使用: @Autowired private Github github ; List<GitHubRes> contributors = github.contributors("crossoverJie", "feign-plus"); logger.info("contributors={}", new Gson().toJson(contributors)); 所以当我们需要调用一些外部第三方接口时(比如支付宝、外部 OpenAPI)便可类似于这样定义一个接口,把所有 HTTP 请求的细节屏蔽掉。 当然也适合公司内部之间的服务调用,和咱们以前写 SpringCloud 或 Dubbo 时类似;服务提供方提供一个 Client 包,消费方直接依赖便可以调用。其他的负载均衡、容错之类的由 Service Mesh 替我们完成。 对于内部接口,也可以加上 @RequestMapping("/path") 注解: 在请求时便会在 url 后拼接上 /order,这样在配置 feign.order.service.url 时只需要填入服务提供方的域名或 IP 即可。 feign-plus 也支持切换具体的 httpclient,默认是 okhttp3,通过以下配置便可更改。 # default(okhttp3) feign.httpclient=http2Client 当然也有其他相关配置: feign.plus.max-idle-connections = 520 feign.plus.connect-timeout = 11000 feign.plus.read-timeout = 12000 实现 最后简单聊聊是如何完成的吧,其实本质上就是 spring-cloud-openfeign 的浓缩版。 其中最为核心的便是 top.crossoverjie.feign.plus.factory.FeignPlusBeanFactory 类。 该类实现了 org.springframework.beans.factory.FactoryBean接口,并重写了 getObject() 方法返回一个对象。 这段代码是不是似曾相识,其实就是 Feign 的官方 demo。 这里所返回的对象其实就是我们定义的接口的代理对象,而这个对象本身则是 Feign ,所以再往里说:我们的 http 请求编解码、发起请求等逻辑又被这个 feign 对象所代理了。 这个 HardCodedTarget 则是 Feign 内部用于代理最终请求的对象。 有一个小难受的地方:这样的自己定义 Bean 然后注入对象 Idea 是识别不了的,认为当前上下文没有该 Bean,但是 spring-cloud-openfeign 却可以识别。 由于 Feign 支持多个客户端,所以这里的客户端可以通过配置文件动态指定。 利用 SpringBoot 提供的 @ConditionalOnExpression 注解可以根据配置动态的选择使用哪个 httpclient,也就是动态选择生成哪个 Bean。 总结 这个库的逻辑非常简单,本质上就是封装了 Feign 并提供了 SpringBoot 的支持,欢迎有类似需求的朋友下载使用。 feign-plus源码:https://github.com/crossoverJie/feign-plus 你的点赞与分享是对我最大的支持

优秀的个人博客,低调大师

机器人影响力日益增强

在美国宇航局的insight着陆器机器人太空船令人印象深刻的成功火星着陆之后,机器人引起了更多的关注,其实机器人在我们生活中带来的影响已经不能忽略,我们生活的许多方面都能感受到它们的存在。不仅在太空探索和科学方面,其实在工业和商业中机器人的存在也起到重要的作用。 无论是国内的双十一还是国外的黑五,在这个需要许多产品的工厂的幕后,对于存放和运输产品的仓库来说,机器人已经在很长一段时间内产生了重大影响。近期,Nvidia和亚马逊发布了有关机器人相关产品的公告,旨在进一步推动工业机器人的发展。 Nvidia宣布中国电子商务巨头京东和美团都选择使用该公司的Jetson AGX Xavier机器人平台开发下一代自动送货机器人。而亚马逊也推出了一款名为AWS RoboMaker的基于云的机器人测试和开发平台,该平台通过其亚马逊网络服务云计算产品提供。RoboMaker是一款开源工具,可以利用并扩展流行的机器人操作系统(ROS),专为参加FIRST比赛的机器人学生和大型企业的机器人专业人士而设计。RoboMaker旨在简化机器人编程过程,以执行利用计算机视觉,语音识别和其他AI驱动技术的复杂操作。就RoboMaker而言,这些服务是通过与亚马逊云计算服务的连接提供的。RoboMaker还提供管理大型机器人队伍的能力,这些机器人在工业环境或大型仓库等场所一起工作。 在消费者市场中,机器人影响力增长的迹象已经持续了一段时间。例如,Roomba机器人真空吸尘器的成功被广泛宣称为家庭机器人革命的第一步。此外,随着语音识别,计算机视觉,人工智能和传感器等关键技术的改进,我们显然正处于2019年可能成为一些主要的以消费者为中心的机器人技术引入的尖端。 机器人技术也是STEM教育计划复兴的关键部分,因为它允许许多年龄的孩子看到他们的科学,数学和工程相关技能带来的有趣,切实的努力。从高中级别的FIRST机器人竞赛,到初中级课程,未来的机器人工程师每天都在世界各地的学校通过这些类型的活动进行培训。这些机器人程序和相关制造商运动发展的影响也已成为主流。 在消费者或商业世界中,机器人的影响当然并不新鲜。然而,除少数情况外,与大多数人的现实世界互动仍然有限。显然,即将发生变化,人们和公司将不得不做好适应的准备。像许多最新机器人技术发展的人工智能技术一样,有一些很好的机会,但也有一些严重的问题,特别是在工作更换方面,更先进的机器人技术会带来这些问题。未来的挑战将是确定如何以可以改善人类体验的方式最好地使用机器人和机器人技术。

优秀的个人博客,低调大师

增强加密是把双刃剑

无处不在的加密也对企业安全造成了困扰——因为加密技术的存在,发现敏感数据流出或者检测恶意软件与其命令和控制服务器的通信变得更加困难。 云邮件服务、在线存储网站,以及其他云应用提供商已经开始加密流量了。甚至社交网站都在加密他们的通信数据。最近,火狐也在实验将加密扩展到网页的各个部分。 戴尔最近的一份报告指出,进出企业防火墙的加密数据流量在去年里翻了一番,目前已经占据全部通信流量的60%。但是,并不是所有的企业都对流经企业网络的流量全部进行加密做好了准备。 幸运的是,尽管美国国防部门和情报机构无力阻止加密的迅速扩张,企业依然可以采取一些措施来保证加密是利于企业发展而非相反。比如,最新型智能防火墙能够解密并监控进出防火墙的数据,帮助公司进行资料外泄防护和恶意软件监控。 该升级的防火墙 受无处不在的加密影响最大的,应该是使用旧式防火墙和数据外泄防护解决方案的那些企业。 一旦浏览器开始加密所有东西,识别恶意流量将变得更加困难。安全分析员需要切实看到进出的流量才能判断敏感数据是否正在流出或者恶意软件有没有被下载。加密在保护数据不被窥探的同时,也妨碍保护机制对恶意活动的检测。 据一份调查报告,传统的网络设备对60%的流量完全视若无睹。问题非常严重。不过,解决方案早已推出市场,以网页代理和其他能够提供解密方法的安全设备的形式。有了这些解决方案,就能使安全设施能够检查加密流量。 在过去,对流量进行解密和分析的系统往往会影响通信性能。因此必须购买专用设备来进行安全套接层(SSL)的卸载。另一个选择是基于云的网页应用防火墙——尽管这让企业不得不将自己的SSL密钥交付给外部厂商。 流氓加密危害大 问题是外部代理并不总能够解密所有进出公司系统的流量。 比如,使用未经公司批准的自有加密程序仍然可以加密文档,再将文档发送至云存储、文件共享网站、个人电子邮件账户,或者不可信的第三方。而采用加密来隐藏恶意流量的恶意程序可不会与公司防火墙分享他们的密钥。 不过也可这样来想,即使不能解密这些数据流量,未经批准的加密流量本身就已经是警报信号了。另外,恶意软件有可能根本不知道它得经过代理服务器才能连接上目标主机。如果在网络环境中发现始终有持续不断的网络监控,就能够分辨出是客户发起的合法SSL连接还是恶意软件的未授权连接。 当然,恶意软件作者们也会适应环境的改变。 监控流量目的地址和源地址 处理加密流量的另一种方法,是查找可疑目的地址。 攻击者仍然需要将数据偷运出公司,而且他们通常使用已知的恶意基础设施作为目的地。即使安全团队查不到加密流量内部的真实数据,依然可以通过观察流量目的地来判断是否发生了数据泄露。 除了已知恶意站点,公司还可以找寻其他标明流量非法的信号。举个例子,如果流量奔向Tor匿名网络,那就可以直接阻止这一通信请求。然后流量源头也是可以观察的地方,并非所有的企业系统都需要与外界通信。 有时候问题不在于流量是否加密,而是应不应该出现流量。传向陌生IP地址的大量数据就是潜在威胁的指示器。” 小心隐私问题 当员工对隐私权有所保留,比如说工作间隙用互联网处理点私事儿,那么IT部门发出的“此行为违反了公司通信守则”的警告会引起什么样的反感? 建议企业最好让员工明确知道当自己登录公司系统时自己的通信是被监控的。这种做法可以显示出公司是坦率的,而且还有减少公司设备和带宽被滥用的额外好处。 或者,公司也可以选择不检查特定目的地址的流量,比如与个人财务状况有关的网站。设置一个白名单,不解密到与社交网络或金融等涉及个人事务的网站的流量。 作者:nana 来源:51CTO

优秀的个人博客,低调大师

EMC对ScaleIO虚拟SAN软件进行增强

EMC将ScaleIO定位为一款虚拟化SAN软件,面向比VMware VSAN软件更高端的数据中心,同时也面向采用(VSAN不支持的)Hyper-V服务器虚拟化的客户。据我们了解,ScaleIO的横向扩展可支持比VSAN更多个节点。 ScaleIO v2.0支持Ubuntu(Ubuntu OS 14.04 LTS)以及CoreOS(支持Docker和容器),更好地兼容OpenStack(Cinder驱动程序),支持Liberty发行版,未来还会支持VMware Photon。 在安全方面,新集成了Active Directory和LDAP,支持IPv6地址。这个季度末还会增加静态数据加密功能,目前已经支持动态数据检验以改进数据对崩溃的抵抗力。 EMC已经增加了扩展支持选项和读取缓存能力,外加一个5节点的MDM(Meta Data Management)集群。EMC融合系统总裁Chad Sakac告诉我们这意味着:"3个存储库+2个断路器,可以在多个MDM节点发生故障之后还可以持续运行。"同时ScaleIO V2.0拥有Mirantis Fuel插件以及丰富且成熟的vCenter插件,并且在做日常维护的时候维持集群性能,提高冗余性。"。 ScaleIO V2.0软件现在还没有开始供货,作为纯软件或者是VxRack Node以及VxRack System 1000 FLEX HW+SW产品。ScaleIO 1.3x和2.x版本到v2.0之间是非中断的升级过程,CoreOS支持仅通过Request for Product Qualification (RPQ)提供。原文发布时间为:2016年04月06日 本文来自云栖社区合作伙伴至顶网,了解相关信息可以关注至顶网。

资源下载

更多资源
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题,腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构,目前腾讯云软件源站支持公网访问和内网访问。

Rocky Linux

Rocky Linux

Rocky Linux(中文名:洛基)是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版,作为CentOS稳定版停止维护后与RHEL(Red Hat Enterprise Linux)完全兼容的开源替代方案,由社区拥有并管理,支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性,采用模块化包装和SELinux安全架构,默认包含GNOME桌面环境及XFS文件系统,支持十年生命周期更新。

Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能,例如代码缩略图,Python的插件,代码段等。还可自定义键绑定,菜单和工具栏。Sublime Text 的主要功能包括:拼写检查,书签,完整的 Python API , Goto 功能,即时项目切换,多选择,多窗口等等。Sublime Text 是一个跨平台的编辑器,同时支持Windows、Linux、Mac OS X等操作系统。

WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源,继承了IntelliJ IDEA强大的JS部分的功能。

用户登录
用户注册