<5人公司极简研发构架

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

paas

博主做的是物联网项目，目前涉及到的通信协议有lora、4g/cat1、ble，传输协议有mqtt、http、tcp私有协议。大致草图如下：

一般来说，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的工作流程设计