【architecture】低价云服务能给普通开发者带来哪些便利?

一降再降云服务器

年初阿里云宣布核心产品价格全线下调,新一轮激烈的降价,在云服务领域引发价格战。99元就能买到2核2G,3M固定带宽40G ESSD一年的服务,这个价格对于开发者太具有诱惑了!

回想入住阿里云已经10年之久,当前的云服务器创建于 2015年8月29日 16:21:00 到此次续费已经10年有余。

在之前也进行很多摸索。 例如:最早使用博客空间(WordPress空间,通过域名隔开)经常被黑,相互影响。 购买过境外服务器搭梯子。 使用过服务器做爬虫,被云服务厂商以中毒为由关停。 使用树莓派搭建服务,通过服务内网穿透对外服务,等等。

关于服务用途,如果有半点儿不正经想法,一定会发现。 如果想使用云服务器保存一些很敏感信息, 不可以!!!,敏感信息最好办法就是备份一个不常用的U盘。

作为普通开发者,云服务器用于学习和生活。下面给大家分享一些云服务器给我带来的便利。

云服务器服务基本配置信息说明

服务基本配置信息:2核(vCPU)2GiB, 公网带宽:2M, 磁盘I/O:80MB/s

关于这个配置说明:

  • 关于2G内存,看到的只有1870M?

free 命令查看内存大小往往会发现比所购买配置的标称内存要小很多,2G 内存查出来也只有 1.8G 左右。 使用命令 dmidecode 查看底层硬件信息,可以看到我的 2G 内存的服务器是分配足了 2048M 内存的。

原因是:free 命令看到的是伙伴系统管理的内存,这部分内存是不包括 OS 内核一些基本数据结构消耗以及内核预留内存的。

dmesg | grep -i memory
[    0.000000] Base memory trampoline at [ffff8fd580099000] 99000 size 24576
[    0.000000] Reserving 161MB of memory at 688MB for crashkernel (System RAM: 2047MB)

阿里云系统镜像默认开启了 kdump 服务,当 Linux 内核出现了故障时 kdump 会协助产生一个 dump 文件,记录下此时的内存运行参数等信息,便于用户后续对内核问题的定位分析。

解决方法:卸载掉他,重启生效,还我内存。

  • 2M带宽,看到不够呢?

2M带宽的下载速度应该在256kb/s左右。实际的下载这个速度虽然不算特别快,但也可以满足一般用户的日常需求。 很多时候我们使用scp 等上传,下载文件时,或者是浏览器下载时看到的不满2M,原因就是流量单位不一致。

其他说明:

  • 2M限定。说的是上行和下行的带宽都是2M。对于正常的服务来说一定是 下行(下载) > 上行(上传) ,可能处于这个原因早期服务器并没有限制上行。 如果用做爬虫服务,就会出现上行大于下行的相反情况(就会触发阿里云的规则,然后主动联系你给你科普一些知识)。

  • 流量付费方式。2M带宽速度并不快的,就256kb/s而已,个人建议选择带宽付费,流量计费如果刷流量攻击等导致可能欠费。也可以通过CDN加速实现访问提速的。亲测过按照流量计费要比固定的方式省钱。

服务安全配置

服务安全,被黑的次数自己都记不清了,遇到服务中毒,不断重启,挖矿,付费后文件解密。

这里只能说几条我常用措施:

  1. 不建议使用Windows Server。 尽管有图形化页面,看上对初学者来说很友好,部署服务更加可视化。事实上各种安全补丁,以及漏洞 ,性能问题会让你后期运行很头疼。 再加上经常中毒,给你换桌面,文件加密,挖矿,让你防不胜防。 此外从价格上比Linux更贵。

  2. 打开防火墙,打开禁ping,仅仅开放自己需要的端口。 在阿里云的控制面板有个云盾会推一些安全漏洞,如果有需要就安装(不过我不是全部安装更新)

  3. 安装 denyhosts服务。防止服务被暴力密码攻击。

  4. 多留心服务异常,例如内存,cpu,多看异常日志等, 有些时候中毒了自己尚未察觉到。

  5. 这一条是最重要的。 我时刻牢记服务是不安全的,对服务安全保持敬畏。因此不会上传很隐私内容,并且经常性将重要内容,从服务端进行备份到本地。

补充: 如果部署服务,遇到了一些非阿里云问题,也可以使用阿里云的在线支持。

例如:I/O速度达到最大值导致服务夯死,或者服务被攻击不可用。 可以直接提服务不可用,然后他会协助你定位问题,最后可以提问这个有什么好的办法解决? 他除了建议你升级服务外,也会给你提供很多排查问题的方法,以及解决问题的少许方案。 阿里云在服务支持这块还是很专业,很及时。 同时这也是我获取运维经验的一种很好的方式。

服务环境搭建

前置工作:为服务器添加交换分区内存,大小一般是内存的2倍。

使用 docker 进行环境部署。

Docker优势有很多,这里选择其中两个比较重要的:

  1. 隔离性:Docker可以实现应用程序与主机资源是隔离开,带来的好处是:不同应用之间依赖的基础库版本不一致,升级麻烦。 软件删除不干净。 还能确保每个应用程序只使用分配给它的资源(包括CPU、内存和磁盘空间)

  2. 安全性:运行在容器中的应用程序和其他容器中的应用程序是完全分隔与隔离的,在通信流量和管理上赋予你完全的控制权。其中一个服务出现问题能减少。

下图是使用Docker完成服务部署。

服务部署结构图

服务部署结构图

  • 网桥:这里我使用Docker创建了个网桥,就Docker而言,网桥网络使用软件网桥,该软件网桥允许连接到同一网桥网络的容器进行通信,同时提供与未连接到该网桥网络的容器的隔离。

  • nginx:用于网关,代理到api,以及 静态资源。

部署主意事项:

时刻提醒自己,这个模块的服务将要24h后挂掉,数据丢失,我需要最小化的备份哪些文件,能保证服务恢复正常运行?

  • 部署一个服务,服务所使用的配置文件和数据文件,规划好目录。 并且周期性的将目录备份到本地。
  • 重启整个主机,服务应该是自动恢复,并且是运行OK的。(为服务指定IP,并且指定失败重启)

云服务器能给我们带来什么好处?

GitBlit 关键数据备份

  • 关键文档。 日常在学习工作中,经常会遇到电脑突然黑瓶,尤其是Windows电脑。 关键文档经常性进行备份很关键。 虽然可以选择放在U盘上相对也很安全,但是经常插入一些电脑,就容易中病毒(尤其是在学校多媒体)。 如果文件极其隐私请不要上传云盘。

  • 方便开发。 可以用它存储代码、跟踪修订历史记录、合并代码更改,并在需要时恢复为较早的代码版本。git 给我们带来的方便就不多讲了。 尤其是做毕业设计时,总有些同学会因为电脑故障等原因导致代码丢失。

有个属于自己的Git服务会给日常学习带来很大便利。

搭建中小型站点Web服务

使用技术Next.js + Node.js + Nginx

中小企业站点,主要的两个特征 良好的SEO 和 较强的页面性能。 我这里经常使用的解决方案是 Next.js框架,如下是评分。

网站性能评分

Next.js 优点有很多,这里选4条我们比较关注的:

  1. 服务端渲染能力: 需要服务端渲染或静态生成,如果你的应用程序需要在服务器端生成动态内容,并将其直接发送给客户端,以提高性能和搜索引擎优化,那么 Next.js 是一个很好的选择。它提供了强大的服务端渲染和静态生成能力,使得构建高性能的应用变得更加简单。

  2. 开发效率: 需要快速开发和部署,Next.js 提供了简化的开发流程和快速部署的解决方案。它具有自动化的路由管理、数据获取和构建工具,可以提高开发效率。 软件交付效率也是我们做应用需要考虑的重要点。

  3. 熟悉的技术栈: 基于 React 的应用程序,如果你已经熟悉 React,并且正在构建一个基于 React 的应用程序,那么选择 Next.js 是自然而然的。Next.js 是建立在 React 生态系统之上的,提供了与 React 紧密集成的功能和工具。

  4. 极强的性能:需要良好的 SEO 和页面性能:如果你的应用程序对搜索引擎优化和良好的页面性能有较高的要求,Next.js 可以帮助你实现这些目标。通过服务端渲染和静态生成,Next.js 可以在初始加载时提供完整的 HTML 内容,有利于搜索引擎索引和页面的快速呈现。

Next.js 提供了轻松部署和扩展应用程序的工具和解决方案。借助 Vercel、Netlify 等平台,我们可以快速将应用程序部署到生产环境,并享受高性能、弹性扩展的好处。 Next.js 本质上是为平台服务的工具, 可以说极大降低了web应用单个细分场景的开发成本。 基本上是这种场景下的唯一完美解决方案。

如何在 2G2C2M 服务上运行起来?

  1. 【打包部署】使用Next.js提供的next build 命令就可以完成服务的构建。 使用standalone 模式。 因为遇到服务器磁盘的IO 只有80M/S,执行命令后会直接将服务给夯死(打包过程需要的IO较多),所以我这里选择的是本地打包,将打包的产物发送到服务端。

下面是打包部署脚本,方便大家参考:

#!/bin/sh
start=$(date +%s)
CurDir=$(pwd)

rm -rf node_modules/
rm -rf .pnpm-store/
rm -rf .next/
rm -rf dist/

echo "-------------------------------------本地打包"
yarn install
yarn run build

echo "-------------------------------------上传文件打包结果到服务端"
rsync -av -e ssh --exclude='/node_modules/' $CurDir/dist/standalone/* name@server:/extend/data/nextjs/swift
rsync -av -e ssh --exclude='/node_modules/' $CurDir/package.json name@server:/extend/data/nextjs/swift
rsync -av -e ssh --exclude='/node_modules/' $CurDir/yarn.lock name@server:/extend/data/nextjs/swift

rsync -av $CurDir/public/* name@server:/extend/data/nextjs/swift/public
scp -r $CurDir/dist/static/* name@server:/extend/data/nginx/www/nextjs-static

echo "-------------------------------------服务端安装服务" # 上一步上传没有将node_modules上传
ssh name@server 'cd /extend/data/nextjs/swift;yarn install;'

echo "-------------------------------------服务端重启服务" # 重启服务运行环境
ssh name@server "docker restart nextjs_swift && docker restart nginx"

echo "-------------------------------------清理本地打包结果(pnpm环境)"
rm -rf node_modules/
pnpm install # 本地开发使用pnpm进行包管理,恢复本地环境


echo "-------------------------------------文章写入到ES中" # 文章搜索用的ES,这里将文章更新到ES中,方便搜索

rsync -av -e ssh --exclude='/node_modules/' $CurDir/_posts/* name@server:/extend/data/nextjs/doc2es/_posts
rsync -av -e ssh --exclude='/node_modules/' $CurDir/scripts/docs/addToES.js name@server:/extend/data/nextjs/doc2es
rsync -av -e ssh --exclude='/node_modules/' $CurDir/scripts/docs/package.json name@server:/extend/data/nextjs/doc2es
rsync -av -e ssh --exclude='/node_modules/' $CurDir/scripts/docs/docHelper.js name@server:/extend/data/nextjs/doc2es
ssh rname@server 'cd /extend/data/nextjs/doc2es;yarn install;node ./addToES.js'

end=$(date +%s)
take=$(( end - start ))
echo Time taken to execute commands is ${take} seconds.
  1. 【Nginx配置】我这里使用的Nginx作为静态服务,他的性能会比Next.js更好。 Nginx进行的主要配置如下
# 设置服务前端缓存
location /_next/static/ {
  alias /www/nextjs-static/;
  expires 7d;
  add_header Cache-Control "public";
  gzip on;
  gzip_types text/plain text/css image/svg+xml image/png application/javascript text/xml application/xml application/xml+rss text/javascript;
}

# 服务限流(简单防范下)
limit_req_zone $binary_remote_addr zone=ipRateLimit:10m rate=1r/s;

# 图片防盗链
 valid_referers none blocked a.cn b.com c.cn localhost;
if ($invalid_referer) {
    return 301 https://new-coder.cn;
}

# 服务端缓存
proxy_cache cache_name; # 使用自定义的缓存名称
proxy_no_cache 1;    # 允许Nginx缓存请求结果
proxy_cache_revalidate 1; # 使用协商缓存策略

在线编辑器

使用技术 Svelte + Vite

主要用于:随时随地无需安装软件写文档。更关键的是自己做的,能促进自己使用欲望,进而提高自己写作欲望。

  1. 个人习惯用MarkDown编辑器来写博客,原因是,产出的文档格式清晰,方便转化为其他格式。

  2. 开发在线编辑器原因是,web端开放了文件系统 API(File System API),可以对本地文件进行修改。同期各种在线编辑器也崭露头角。为了尝鲜,并且文档更容易存储与使用。

  3. 使用Svelte 框架开发的原因是:在线编辑器是基于基于 bytemd 编辑器进行改版的在线编辑器。

关于Svelte
Svelte 是一个构建 web 应用程序的工具。但是有一个关键的区别:Svelte 在 构建/编译阶段 将你的应用程序转换为理想的 JavaScript 应用,而不是在 运行阶段 解释应用程序的代码。这意味着你不需要为框架所消耗的性能付出成本,并且在应用程序首次加载时没有额外损失。(创新点是把 React 和 Vue 客户端运行时干没了)

网盘功能

使用技术 Nginx + Vue + Golang + MySql

网盘是必须功能,承载应用所需图片使用诉求(包括对图片进行压缩,格式转化,加水印,防盗链,基本CRUD等)。

最有用的大型文件分享

例如有个6G得高清电影,需要给好朋友分享,怎么分享呢? 一般采用方式百度网盘(百度网盘不开会员不过百,盗版不让你下载)。 当然我也只有2M,并且6G你也传不完,我的方法是:

生成脚本本地给拆分多个上传,然后好友下载的时候合并脚本和文件已并下载,执行脚本后再合并在一起。

# 上传拆一下 upload.sh
tar -zcvf filename.gz filename | split -b 2000M -d -a 1 - filename.tar.gz.

# 下载按照片段创建多任务,并下载自动生成的 merge.sh
cat filename.tar.gz.* | tar -zxv

图片压缩管理

现在web站点的图片基本上要求压缩的,甚至更高性能的webp格式。 自然网盘也提供了对应对应能力。 这里实现方式借助于 tinypng 提供的免费API来实现。

技术能力提升

使用技术栈 Nginx + Vue + Golang

快速掌握一门新语音,我是这么做的?

  • 快速阅读官方提供的语法,然后刷LeetCode上题目。 好处是:快速掌握语法,并可以提升专注力。
  • 写足够多的代码,或者修改开源项目。 这里通常采用的方法是把如下的常用功能自己手写一遍,基本上满足日常工作需求。
  1. 用户登录,权限(角色,资源,用户)分配,水印,OTP 等基础的管理功能。
  2. 机器管理的相关功能,例如:任务计划,服务相关运行参数,运维能力,邮件告警 等。
  3. RDS:关系型数据库操作API,这里模仿在线的数据管理系统写的管理界面。类似于web版 NavCat
  4. Redis:内存管理数据库,实现一个在线管理功能,类似于web版RDM
  5. MongoDB:文档型数据库,实现同样实现一个在线管理界面。
  6. NetDisk:网盘功能,文件管理功能。类似于百度网盘功能。
  7. ElasticSearch:【正在进行中】全文搜索引擎,目前文章检索需要用到。在没有很高级的推荐算法时,可以通过他来提供搜索能力。
  • 看足够的文章,有条件一定要实现一下,最差也要自己总结一下,写出来, 否则就是看完就忘了。

管理端功能对mayfly-go开源代码进行修改,并添加了很多功能,作者从java版本写到go版本,并尝试使用DDD架构来实现。(关于DDD架构应用后面有机会再介绍)

功能截图

小结

分享给大家如何低成本使用云服务器,给我工作和生活中带来的便利,以及给我带来的技术成长。 总结下来就是

除了技术外还有几点软实力也很重要。

  • 相信自己。 要相信普通的程序员日常遇到的开发问题,一定是有解决方案,我们做的不是创造性的,耐心去搜索,去筛选知识。 很多情况下没解决是内耗在对问题的恐惧上。

  • 不给自己设限制。 工作中越久在自己的技术小圈内越是舒适,技术也在不断的更新。 喜欢就需要去尝试,某个技术永远看不会的,需要去写,去实践,去踩坑成长,才能理解。(遇到很多时候,谈论到某个技术时高屋建瓴,细到具体解决方案模棱两可)

  • 成长是拓宽度还是拓展深度好。 我觉得都好!看个人发展,拓深度在某个垂直领域,要深入了解场景,公司瓶颈期需要这样的人才。 拖宽度,在初创公司很喜欢,能在初期给出较优解决方案。

最后: 喜欢的小伙伴点个关注。
也欢迎关注个人主人:https://new-coder.com

关于我
loading