- 博客(23)
- 收藏
- 关注
RSS订阅原创 解决PyTorch无法调用GPU，torch.cuda.is_available()显示False的问题
解决PyTorch无法调用GPU，torch.cuda.is_available()显示False的问题`Can not execute `setup.py` since setuptools is not available in the build environment``ModuleNotFoundError: No module named '_ctypes'`'soundfile' backend is not available.
2023-02-15 09:53:26
4569
原创 在阿里云ACK部署Milvus生产集群的坑
在阿里云ACK部署Milvus生产集群，但依照官方文档安装的时候，遇到几个坑。如何在阿里云ACK部署Milvus
2023-01-16 09:49:55
1673
原创 极简Prometheus监控实战
本文着重在于介绍如何利用Prometheus搭建监控系统，涵盖探针，指标设定，可视化，告警设定，容器监控等。这是一篇入门级教程，暂不涵盖gateway，K8S集群等的相关内容。关于Prometheus的基本知识与概念，自行google之，本文重点描述实战过程。.........
2022-08-04 21:05:20
1191
原创 个人虚拟化集群搭建教程
本文重点向读者阐述，如何基于非企业级设备，低成本建设个人私有化虚拟化集群。开发人员与运维人员基于该平台可更快速的验证技术方案，快速搭建开发环境。
2022-08-01 17:46:11
3320
原创 goframe与gin对比(四) 数据返回、Cookie、session、HTTPClient
数据返回JSON/XML支持两者均支持序列化对象，输出json和xml格式数据重定向两者均支持重定向，goframe还支持通过RedirectBack返回到上一个页面goframe Redirect中断控制goframe提供Exit，ExitAll,ExitHook用于中断当前执行的逻辑方法，其底层使用的是 panic，recover 机制实现。gin目前没有原生提供该功能。goframe Exit控制文件下载goframe 提供 ServeFileDownload 方法用于文件流式下载
2021-10-28 18:46:45
683
原创 goframe与gin对比(三) 请求输入
请求输入复杂参数同名参数同名参数提交格式形如：k=v1&k=v2, goframe是后续的变量值将会覆盖前面的变量值，而gin因为用的标准库net/http, 提交的同名参数将会被转换为字符串数组。package mainimport ( "github.com/gogf/gf/frame/g" "github.com/gogf/gf/net/ghttp")func main() { s := g.Server() s.BindHandler("/", func(r *gh
2021-10-28 18:46:10
1035
原创 goframe与gin对比(二) 路由管理
路由管理路由规则goframe 的动态路由的底层数据结构是由层级哈希表和双向链表构建的路由树。gin 路由算法是前缀树(Trie), 时间复杂度是 O(n)。可参考 gin的路由算法当gin出现路由规则重复时，会报错。而goframe则是按照深度优先策略进行优先级控制。主要规则如下：层级越深的规则优先级越高；同一层级下，精准匹配优先级高于模糊匹配；同一层级下，模糊匹配优先级：字段匹配 > 命名匹配 > 模糊匹配gin和goframe都支持命名匹配规则、模糊匹配规则，不建议使用
2021-10-28 18:45:20
1369
原创 goframe与gin对比(一) 综述
整体优缺点可以把goframe比作 windows，整体性强，结合都高，开箱即用。而gin，则类似于linux，各组件小而独立，通过融合各个组件，完全可以组成一个比goframe更好的二开平台，但技术要求高，时间跨度长。goframe 优点整体全面，基本覆盖建设企业级系统所需的组件文档全面具体，基本上可以在文档中找到答案。goframe 缺点目前事实上基本只有一个作者，停止维护的风险较大。较封闭，类似微软DotNet，平台涉及各个方面，一旦出现bug，无法整体替换，第三方组件兼容性尚不明
2021-10-28 18:44:38
9357
原创 使用触发器记录表内数据变更日志
使用触发器记录表内数据变更日志一、遇到的问题因为系统升级改造，遇到的问题是，新老两个数据库的两张表需要做数据同步，这两张表的表结构不完全相同，同步时会用类似nifi这种etl工具做转换。由于是线上系统，不可随意对原有的表结构进行变更。由于是老旧系统，业务繁杂，短时间内无法理清代码逻辑，也就不能从代码层做处理。用nifi做数据同步时，发现特别是数据删除这种场景，会需要全表扫描做对比，得到被删掉的项，而后在另外一张表中做删除动作，这种方法性能极差。于是，想到在数据库层面利用触发器记录变化的数据的id，同
2021-10-26 14:31:24
1476
原创 解决执行“go build“时报“Host key verification failed.“的错误
解决执行"go build"时报"Host key verification failed."的错误go版本 1.16+，项目存在引用私有库的情况，在执行"go build"时，总是报如下错误：go: xx.xxx.com/xxx/[email protected]: reading xx.xxx.com/xxx/xxx/go.mod at revision v0.1.0: git ls-remote -q origin in /Users/xxx/go/pkg/mod/cache/vcs/xxxxx: exit
2021-10-21 19:10:03
1334
原创 通过SSH隧道安全建立RDP远程桌面连接(RDP over SSH tunnel)
我有一台windows的虚拟机, 已经在路由器中对RDP的端口做了端口映射, 如此我便能在任何地方连接上这台虚拟机, 但问题也随之而来, 如何在保证易用的同时也适当的保障安全性？为什么要通过ssh隧道来建立远程桌面连接RDP服务本身存在诸多风险, 不仅仅用户的弱口令问题, 还包括其本身也有诸多漏洞, 相比之下, 还是更相信SSH一些。很多公司为了规避风险, 会在防火墙中限制3389端口的访问。但对SSH, 会宽容许多。当然, 即使安全策略没有彻底限制RDP, 这里也不建议在没有得到公司允许的情况下,
2021-05-07 23:33:23
7595
原创 《深入浅出通信原理》一句话短评
这本书其实是由某论坛系列连载的内容集结而成，总体来说，两个特点，一是简单易懂，简明扼要；二是需要一定的高等数学基础，公式略多。我并没有想要完全理解这本书的所有内容，而是仅做了解知晓即可。这本书更多的是帮助我理解网络通信层面的一些东西，诸如物理层信号衰减等的原因。这本书我只给评了7分，更多是因为我并非通讯行业的行业人，而我加入了这本书对于自己的实用性指标，但这本书依然是一本好书。评分：7 （满分为10分）作者: 陈爱军出版社: 清华大学出版社出版年: 2018年2月第1版页数: 351定价
2021-03-04 00:16:14
705
1
原创 《持续交付2.0 业务引领的DevOps精要》 要点摘录与总结（四） 基础设施
《持续交付2.0 业务引领的DevOps精要》 要点摘录与总结（四） 基础设施前面3篇文章介绍了持续交付的概念，实施持续交付三大板块中的组织机制和软件架构，而最后一个板块则是基础设施。基础设施部分是产品研发过程中最基础的工作。这部分涵盖持续交付部署流水线及其工具设计原则，以及建立该流水线和优化所需关注的五大领域，分别是，业务需求协作流程、分支与配置管理、构建与环境管理、自动化测试管理，以及部署发布与监控管理。这部分内容相当细节，我并不想在此展开。此外，此部分和目前流行的DevOps有大量共同的内容。部
2021-02-23 13:38:41
403
原创 《持续交付2.0 业务引领的DevOps精要》 要点摘录与总结（三） 软件架构
《持续交付2.0 业务引领的DevOps精要》 要点摘录与总结（三） 软件架构持续交付架构的要求为了提升交互速度，获得持续交付能力，我们会需要对系统架构做一些调整。书中对系统架构做了一些要求，要求如下：为测试而设计（design for test）。如果我们每次写好代码以后，需要花费很大的精力，做很多的准备工作才能对它进行测试的话，那么从写好代码到完成质量验证就需要很长周期，当然无法快速发布。为部署而设计（design for deployment）如果我们开发完新功能，当部署发布时，需要花费很
2021-02-23 13:32:34
740
1
原创 《持续交付2.0 业务引领的DevOps精要》 要点摘录与总结（二） 组织机制
《持续交付2.0 业务引领的DevOps精要》 要点摘录与总结（二） 组织机制组织机制是一个复杂课题，书中仅仅讨论持续交付所需的文化，以及建立文化的四步法。关于组织架构、人才结构、激励机制等内容被略去，不得不说是一个遗憾，当然我想更多的是篇幅所限，不得已而为之。组织文化塑造四步法书中列举了几个企业组织的四步法，但大同小异，这里我以谷歌工程师的质量文化为例，第一步:定义想要做的事情提高代码质量，减少生产问题，减少手工测试工作量，快速发布软件。第二步:定义期望的做事方法开发团队编写自
2021-02-23 11:19:27
362
原创 《持续交付2.0 业务引领的DevOps精要》 要点摘录与总结（一） 概念篇
《持续交付2.0 业务引领的DevOps精要》 要点摘录与总结（一） 概念篇为什么要持续交付？当前互联网变化非常迅速，在这个背景下，提升产品研发运营效率，快速发现新的机会并快速试错，降低试错成本已经变得非常重要。由此，带来几个问题：如何平衡软件的质量与交付速度？如何让产品创新快速交付部署，并让团队得到反馈？我们都知道，要快速发现新机会并快速试错，就必须加快产品迭代速度，而加快迭代速度必然使得一些常规事务性占比增大，诸如测试成本，发布成本等。持续交互，即是这些问题的解决之道。软件工程的发展历史
2021-02-23 10:56:54
1457
原创 《持续交付2.0 业务引领的DevOps精要》 一句话短评
这本书带给鄙人诸多启发，DevOps，持续交付，都是近些年的热词，而本书作者分别从概念与原则，组织架构，软件架构，基础设施，案例剖析等几个方面很好的诠释了这两个热词，难得的是，这不仅仅只是概念，更有大量的具体操作方法和实践案例，很适合技术管理者和研发经理阅读。评分：5 （满分为5分）作者: 乔梁出版社: 人民邮电出版社出品方: 异步图书副标题: 业务引领的DevOps精要原作名: 持续交付2.0出版年: 2019年1月第1版页数: 327定价: 89.00元装帧: 平装ISBN: 97
2021-02-23 09:54:08
160
原创 写在开始本博客开始之前
本博客主要用于自己做总结沉淀。本博客佛系经营，不刻意推广，不定期更新，一切随缘。内容上，一是不追求全面完整，如只是教程，网上到处都是，无必要重写一遍。可能更多的是我提一些要点，放参考链接的形式。二是，想发一些自己曾经研究过，自己喜欢的知识和技能。...
2021-01-21 13:46:53
85
原创 2021新年寄语
过往的2020年真是令人终身难忘的大年，一场突如其来的疫情打乱了所有人的节奏，以前总觉得亲历历史是非常幸运的，现在回想自己还是太天真幼稚了，亲历历史更多带来的是苦难。辗转来到了2021年，终于，在2020年开个属于自己的博客的小愿望还是没能实现，虽然这已经是在2019年就计划了的，但总有诸多现实且世俗的因素使自己有借口原谅自己的拖沓。如果只用单个词作为2020年的年度词，那就是虚拟化，这是2020年我的最大的收获，它直接为我打开了一扇大门，一扇能让我极度方便的实践各个技术路线的大门。在此之前，遇到的最大痛
2021-01-21 13:45:28
160
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人