最近我们研发的开发测试机器需要更新换代，采购了一批机器，机器选型主要在国产中选择，比如浪潮、新华三、华为等。 最终我们选择了新华三R4900G3型号。 对于新华三服务器以前确实是没用过，用过之后，感觉还是非常符合咱们国人习惯的。非常人性化的标签设计以及hdm管理功能，这里给个好评。 由于之前的服务器一般都是供应商把raid、基础系统都弄好，这次需要我们自己来做，简单记录一下，其实还是蛮简单。 系统启动类型 默认的系统启动是UEFI模式，若要切换为传统的legacy模式也可以，不过raid配置方式就是传统的方式，在启动时按ctrl +r 去配置就行。 这里我们就按最新的，系统默认的UEFI模式进行配置。 配置raid5 机器配置统一配置为：银牌4210R十核*2/32G*4/4TSAS*3/P460-M2/双电/导轨，所以做的raid的话，就选择raid5。 做完raid每台服务器8T容量。 为了方便说明，这里将bios默认统一设置为中文 配置好raid信息之后，我们就可以登录到hdm管理端口去安装底层基础系统了，非常方便。
Archive for the ‘技术’ Category
新华三 R4900G3 Raid配置
Tuesday, January 25th, 2022升级debian11正式版之后的python问题
Sunday, August 15th, 2021升级debian11正式版之后的python问题 默认升级到debian11之后，系统自带的python为3.9版本，若之前系统使用的软件有较老的版本，则有一定概率会有问题。 比如之前经常使用的glances软件，在升级到debian11之后会报错： 或者类似的其他API调用错误，根本原因不在于操作系统，而是在于相关软件未及时更新或者未更新到最新的程序库导致异常，这种情况只能先卸载再说，等该软件后续更新再使用，亦或者自己编译一个版本安装使用。
debian10 升级至 debian11正式版
Sunday, August 15th, 2021debian11已正式发布，Linux 5.10 LTS内核系列提供支持，该系列将在未来五年内得到支持，直到 2026 年 12 月。像之前Proxmox VE发布的版本已经是基于debian11。 自去年以来业务新上的服务器基本都是debian10版本，看来最近可以批量升级一下了。 先拿其中一台测试了一下，升级正常无误（记录升级之前做好备份、镜像，以防万一）。 简单记录一下升级过程，debian升级系统还是非常简单方便的，比redhat系列还是简单不少。 升级之前先更新软件至最新： 首先打开 https://mirrors.bfsu.edu.cn/help/debian/ 北外的debian国内源，找到版本bullseye，替换这里的内容 /etc/apt/sources.list , 当然如果有添加其他的源需要单独替换对应的版本 正常不报错就OK，开始执行升级 期间有一些提示根据需要进行选择即可。 升级完成，验证一下版本： reboot重启验证一下是否能够正常启动。 之后，删除之前的软件包 整个升级过程大概5-10分钟左右。 PS. 机器配置一般为： 8核32G 或8核64G左右（主频2.5-3.0左右） 、固态盘。
传统系统业务云时代的场景应用之一
Monday, March 8th, 2021一、业务背景 每一个有些年头的公司，总会有一些传统的老项目，这些老项目不得不维护、也不得不继续开发、更新。当然这其中肯定也包括腾讯、阿里等公司，就像腾讯阿里的部分员工吐槽整天用着十几二十年前的老掉牙的技术，维护着老项目一样。 对于这部分系统，虽然可以推倒重来、升级改造saas模式或是持续升级更换，但巨大的成本一般是让人难以接受的，只能继续维持现状。 二、现状 类似全国连锁业务，每一个连锁中心，一台服务器，部署一套传统业务系统，这种方式其实成本相对较高，正常一台服务器一般2-3W左右，电费一年也得2000左右（商业用电按均价1元，平均功耗200W-250W左右），偶发性的系统硬件故障，由于系统遍布全国各地，维护起来也是很费劲，成本很高。 三、云部署实施方案 大家如有更好的方案可以通过 https://www.jiucool.org/contact/ 一起沟通。 1. 安全性 最重要的就是安全保障，该方案采用动态安全授权解决方案，保障安全。做到非授权中心无法访问，外网无法访问，性能是0损失，从而达到与本地部署一样的效果。 其中之前考虑最多的是VPN方案，由于VPN加密方案效率实在太低，尝试一段时间后，严重影响了业务中心的系统使用，只能放弃。 2. 部署方式 老酒换新瓶，新技术还是得有的。只有系统本身是老旧的，配套相关技术还是得跟上的。 1）构建发布时采用jenkins，自动编译、打包、docker镜像build、push、trigger。 2) 云端部署采用k8s集群方案，每个中心分配独立域名动态授权访问。 3）数据库采用阿里云polardb主从集群版。（大大减少了数据库的维护工作量，备份、安全、性能上都很不错） 3. 优势 改为云方案后几大改进 1）成本上大大降低了，最终费用折算后，平均每年每家中心成本仅2000多元，首年成本每家中心即节省了近3万元。 2）维护成本也降低非常多，这个主要是人力成本以及时间成本的节省。 3）稳定性提高。 不会因为以往硬件故障导致某一家中心动辄好几天甚至一周时间的维修。 经过一年多的实际运行，从各方面来看还是有非常好的反馈效果。
阿里云容器服务ACS升级1.18.8-aliyun.1 踩坑记录
Sunday, February 7th, 2021公司的项目的云服务提供方均为阿里云，为了减少运维成本，也基本基于阿里云的产品进行构建。 当然这样做有好处，也有不足，好处是：大大减少了相关产品运维成本更加方便。 不足就是一旦用上了阿里云的这种相关产品以后基本不太可能迁移他处，迁移成本过大。 阿里云的容器服务ACS产品（我们采用的是托管版本），一般半年期一个大版本升级，要持续跟进阿里云的升级进度，否则就会进入非维护期的产品系列了。 不过每次升级其实都是提心吊胆。最近一直提示可更新至1.18.8-aliyun.1版本，遂几个集群逐一开始升级，一般情况是没有问题的。 可今天就出现了幺蛾子。 其中一个集群在升级时死活不行（相同配置的其他集群OK）： 遇到这种情况只能寻求阿里云官方帮助解决，官方的工单服务还是不错的。最终得到的回复是其中一个Node资源不足引起的。 其实整体Node资源占用率仅为30%左右，而CPU一般在10%以下，每个node机器配置为：8核64G，上面业务Pod数10个左右，每个内存资源占用大概2G，很难理解哪块资源会不足，由于情况紧急并未深究此原因，紧急解决之。 最终的解决办法是先取消升级，排空该Node，再重新升级集群解决此问题。 当然阿里云给出的第一套建议是直接从集群中删除此node，升级完成后再添加回来，这个方法基本可以解决100%的node异常问题，但由于我们这节点上手动安装了dns等其他服务无法采用该方式，只能放弃。
某世界五百强企业的webapi设计
Thursday, February 4th, 2021年底公司某项目要与相关系统进行对接，其中有一家隶属于某世界五百强企业，了解了这家公司的webapi接口后，感觉简直让人骇人听闻。这是我从业N多年以来第一次遇到的如此“高大上”的系统，果然不愧为世界五百强企业，直是不吐不快。 下面简单聊一下： 一、系统安全性 这个安全性是完全不存在的，作为一个很重要的系统，对外提供的webapi接口不做任何权限校验，只要知道报文，就可以尽情调用，吓得一身冷汗。 二、文档准确性 前期确实提供了一份文档，结果项目组进行调试时，发现没有一个接口可以调通。后经了解：这个文档都是错的，历史上N久以前的，都无法使用，现代的系统没有文档。 而后又直接甩过来一堆测试报文，结果亦是错漏百出，很多东西需要靠猜。 三、接口的稳定、完整性 完全没有稳定性可言。 例如：某物品下单时，突然间没有库存了，正常来说应该返回一个错误码，加上一个des文字说明。 而实际上只返回一个 null，连整个报文结构都没有了，让人不知所以。 调试若有任何报错，统统只返回null ，无任何报错信息。 最夸张的是，比如进行某列表搜索时，如果返回结果为0，此时也会给你返回 null 。 在返回json 结构时，有的时候居然不是标准的json报文 ，明显是通过字符串拼接json，而在拼接过程中特殊符号没有转义，导致了json整体结构的损坏，这让人咋接收解析呢？ 感觉即使初学编程的学生，也很难堆出这样“高大上”的系统来吧？ 虽然这个世界五百强并非互联网也非软件产业，但也是有点夸张了。 相信这应该是临时工干的吧，嗯 应该是体育专业转过来的吧。