人過35，被年輕人卷走了一大半，還停留在這個行業的，不是在創業，就是在創業的路上。
創業很難，剛開始沒錢沒人，啥都要自己干，一個字累。好處是地基是自己搭的，心里有底。不過博主最近健忘的毛病愈發嚴重了，趁還清醒紀錄點滴。
PaaS
博主做的是物聯網項目，目前涉及到的通信協議有lora、4G/Cat1、BLE，傳輸協議有MQTT、HTTP、TCP私有協議。大致草圖如下：
一般來說，MQTT能滿足大部分業務需求，但在某些場景比如文件下發/自定義分包拼包時處理起來比較復雜，這時使用HTTP更合適，但對於設備並不友好（MQTT與HTTP誰最適合物聯網？），所以有時自定義協議也不可避免。另外如果覺得MQTT實現或對接起來太麻煩，很多特性又用不到，那其它協議或自定義協議是更好的選擇。
MQTT雖然通用，但不是萬能的，不是非它不可的，說到底，它也只是一套誕生於具體場景，為了解決某些問題，一步步發展起來的協議罷了。
MQTT是長連接。
系統拓撲
然后買服務器，走阿里雲，買多少呢？主要是ECS，有以下幾點要求：
- 前台、后台、PaaS網關分開部署；
- 還有各類中間件，前期就把它們一塊放一台機子上得了；
- 一個私有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的工作流程設計