<5人公司極簡研發方案
人過35，被年輕人捲走了一大半，還停留在這個行業的，不是在創業，就是在創業的路上。
創業很難，剛開始沒錢沒人，啥都要自己干，一個字累。好處是地基是自己搭的，心裡有底。不過部落客最近健忘的毛病癒發嚴重了，趁還清醒紀錄點滴。
PaaS
部落客做的是物聯網項目，目前涉及到的通訊協議有lora、4G/Cat1、BLE，傳輸協議有MQTT、HTTP、TCP私有協議。大致草圖如下：
一般來說，MQTT能滿足大部分業務需求，但在某些場景比如文件下發/自定義分包拼包時處理起來比較複雜，這時使用HTTP更合適，但對於設備並不友好（MQTT與HTTP誰最適合物聯網？），所以有時自定義協議也不可避免。另外如果覺得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的工作流程設計
