<5人公司極簡研發方案

萊布尼茨發表於2021-07-05

人過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的工作流程設計

相關文章