当前位置: 萬仟网 > IT编程>软件设计>架构 > <5人公司极简研发构架

<5人公司极简研发构架

2021年07月07日 架构 我要评论
人过35,被年轻人卷走了一大半,还停留在这个行业的,不是在创业,就是在创业的路上。 创业很难,刚开始没钱没人,啥都要自己干,一个字累。好处是地基是自己搭的,心里有底。不过博主最近健忘的毛病愈发严重了,趁还清醒纪录点滴。 PaaS 博主做的是物联网项目,目前涉及到的通信协议有lora、4G/Cat1、 ...

人过35,被年轻人卷走了一大半,还停留在这个行业的,不是在创业,就是在创业的路上。
创业很难,刚开始没钱没人,啥都要自己干,一个字累。好处是地基是自己搭的,心里有底。不过博主最近健忘的毛病愈发严重了,趁还清醒纪录点滴。

paas

博主做的是物联网项目,目前涉及到的通信协议有lora4g/cat1ble,传输协议有mqtthttptcp私有协议。大致草图如下:

一般来说,mqtt能满足大部分业务需求,但在某些场景比如文件下发/自定义分包拼包时处理起来比较复杂,这时使用http更合适,但对于设备并不友好(mqtt与http谁最适合物联网?),所以有时自定义协议也不可避免。另外如果觉得mqtt实现或对接起来太麻烦,很多特性又用不到,那其它协议或自定义协议是更好的选择。
mqtt虽然通用,但不是万能的,不是非它不可的,说到底,它也只是一套诞生于具体场景,为了解决某些问题,一步步发展起来的协议罢了。

系统拓扑

然后买服务器,走阿里云,买多少呢?主要是ecs,有以下几点要求:

  1. 前台、后台、paas网关分开部署;
  2. 还有各类中间件,前期就把它们一块放一台机子上得了;
  3. 一个私有docker镜像仓库用于ci/cd,与业务无关,独立部署,带宽也独立(上行为主,几乎不下行,所以开个最小1m带宽即可)。

这么看来至少5台ecs,网络架构如下:

麻雀虽小,五脏俱全。横向和纵向都有较好划分,界限清晰,方便以后扩展。
考虑到便于运维/ci/cd/微服务/日后引入k8s,所有服务都以docker容器形式部署。
为了省钱&安全计,只给必要的两台ecs开了公网(eip),除docker镜像仓库外,挂载nginx的那台也要开通公网对外提供服务,对内转发请求。需要注意的是,ecs若没有公网ip,则自身也无法访问外网(记得以前可不是这样的)。那如果内网ecs要调用外部第三方接口怎么办呢?同样可经由nginx转发。在此场景下,nginx兼具反向和正向代理的职责。
内网ecs获取公网docker镜像也存在无法拉取的问题,可以在私有仓库的那台机子上先拉取下来,然后打个tag,再push到本地仓库,如此其它ecs就能在私有仓库里pull到该镜像了。示例如下:

# 私有仓库基于registry,端口6500

# 以nacos为例,在部署了仓库的ecs上执行
docker pull nacos/nacos-server
docker tag nacos/nacos-server:latest localhost:6500/nacos-server
# 重新发布到私有仓库
docker push localhost:6500/nacos-server

# 内网ecs拉取镜像
docker pull 仓库ecs内网地址:6500/nacos-server

阿里云ecs.s6-c1m2.xlarge 4m带宽(固定)比ecs.t5-lc1m4.large (无性能约束实例) 5m带宽 (固定)下行速率更快更稳定,后者卡的一笔,经常断连(可能受其它共享主机影响?),直接升级到15m后可正常使用。
反向代理,除了nginx,我们还使用了haproxy。前者处理http转发(l7),后者处理tcp转发(l4)。虽然nginx从1.9.0版本开始,新增了ngx_stream_core_module模块,使nginx支持四层负载均衡。然而其默认编译的时候该模块并未编译进去,需要编译的时候添加--with-stream,使其支持stream代理。目前官方也没有提供默认有该功能的docker镜像,需要自己打包,稍显麻烦。

自动发布

自动发布是ci/cd的基础。本人使用的是gitlab-ci,相比jenkins,gitlab-ci资料并不多,不过其官方文档已经挺全面了,遇到问题基本上也有前人踩过坑,可参看博主以前写的一篇随笔gitlab-ci/cd入门实操
以后端应用为例,流程大致如下:

有几点图中未表明:

  • 代码提交/merge到不同分支,将触发各自分支的发布流程。比如dev分支将发布到内网测试环境,master分支将发布到线上生产环境。
  • 对于前面说的生产服务器没有公网地址的情况,公司内网的gitlab-runner无法直接登录,就需要拥有公网地址的服务器作为跳板机登录。

如果在发布流程中加入代码规范check、code review、通知机制、及手动干预功能(如提供管理界面,测试人员点击测试通过或不通过按钮控制流程走向)等,那ci/cd就初具雏形了。

git分支管理

顺便再说说代码分支。一直都存在的有master和dev分支。master对应线上生产版本代码,dev对应本地开发版本代码。生产部署都走master分支,当线上有bug或紧急需求时,从master分支切一个hotfix分支出来,开发测试完毕之后并回master并删除该hotfix分支。而产品迭代需要处理的bug和需求,从dev切分支,一次迭代一般起一个feature分支,开发测试完毕后并回dev分支(或并回后做测试,视情况而定),然后dev再merge到master,上线。流程大致如下:

注意hotfix和feature分支可能同时会有多个,完成之后即删除。

其它资料

为什么用mqtt而不用tcp长连接透传
互联网推送服务原理:长连接+心跳机制(mqtt协议)
lorawan介绍 - lora从业者读这篇就够了
基于gitlab的工作流程设计

(1)
打赏 微信扫一扫 微信扫一扫

版权声明:本文内容由互联网用户贡献,该文观点仅代表作者本人。本站仅提供信息存储服务,不拥有所有权,不承担相关法律责任。

发表评论

验证码:
Copyright © 2017-2022  萬仟网 保留所有权利. 粤ICP备17035492号