BearyChat 技術棧是什麼？

BearyChat 技術棧是什麼

@Loddit 萌少年用比較粗獷的方式介紹了一下技術概括，那我也從另外一些角度和細節來介紹一下 BearyChat 的技術棧吧。

利益相關：BearyChat 後端工程師

## 工程部門概括，or: BearyChat 碼仔的摸魚日常

BearyChat 工程部門可以按照不同方法來劃分（當然人還是那麼多的人）。

傳統方法就是按照不同的職責來區分：

- 前端天團
- iOS/Android 客戶端天團
- 後端天團

顧名思義，不同天團的同事會負責對應方向的工作。例如我大部分時間都是作為後端天團的代碼仔來上（摸）班（魚）的，所以主要會關注後端開發的事宜（下面也會介紹一下我們的後端架構的情況）。

但又因為目前的 BearyChat 技術團隊還不算十分龐大，所以不一定會強制各位工程師只能做某個方向的事情。所以還可以按照以下方式劃分：

- 公有雲 SaaS 開發天團
- 私有部署開發天團
- 基礎架構天團

也就是說，在 BearyChat 做碼仔，很大程度上都要身兼多個方向的研發任務（我們有萌系前端工程師速成 Clojure 的「奇蹟」，也有後端工程師輪番上陣用 Angular/React 寫搜索輸入框的慘痛故事）

因為 BearyChat 產品功能比較多，所以日常開發任務都會按照功能模塊來劃分、以小組方式來組織開發（當然會帶上稀缺資源設計師 XD）。典型的日常會是如下：

1. BearyChat 的研發在與一生的敵人產品錦鯉討論新功能的產品需求（包括用戶故事、功能設定、邊界條件等&雜七雜八的&東西）後會產出一份基本的產品文檔；
2. 工程師會在一生的敵人的幫助下根據產品文檔把任務分拆到自己喜歡的整理工具中去；
3. （前後端）工程師、設計師會根據拆分好的需求儘可能地並行做開發、設計的事情；
4. 工程師在領取一個任務之後，會通過 GitHub Pull Request Flow 的形式來提交自己的實現給相關同事進行 review （原則上不少於兩個）, 同時 pull request 會有專門的 CI 流程進行測試；
5. Review 同事在 CI 測試通過後會進行 code review, 這部分主要就是在 tracker/BearyChat 上吵架了
6. Code review 完成後，最後一位 review 的同事會 merge 代碼到主幹，並把相關任務標記為已完成；
7. 代碼自動部署到 stage 環境，相關同事會在 stage 環境上進行集成的測試；
8. 每周二、周四對主幹代碼進行 release, 上線

Take away:

通常一個簡單的需求從確認到開發再到上線周期一般在半個星期到一個星期左右。這套流程的基本概念從 BearyChat 創建伊始就開始使用，改動不大，主要有幾個重點：

1. 堅持 code review: code review 能幫助工程師找到很多盲點，盲點可以是代碼上的，也可以是產品上的。同時 review 的過程也有利於不同的同事熟悉整個業務。
2. 完整的 CI/CD 發布流程非常重要：因為 BearyChat 本身是一個涉及多個大功能模塊的複雜系統，所以單獨的測試不一定能把所有問題都暴露出來，因此一個完整的持續集成流程和測試環境能幫助工程師儘可能快地看到功能在完整環境上的運行效果，大大縮短了問題發現、重現周期。

## 後端架構

TL;DR:

- Clojure + Erlang

- MySQL + Redis + RabbitMQ + Elasticsearch

- Thrift + HTTP

- Ansible + Docker + Jenkins

### 最初的架構設計

最初的架構設計可以參考 CTO 唐曉敏在15 年一次訪談 https://www.v2ex.com/t/209823 提到的草圖：

這套架構的特點就是：簡單 + 可擴展。

### 目前的架構設計

BearyChat 後端可以劃分成幾個部分：

- 核心數據儲存
- API 服務
- 即時通信 RTM 服務
- 私有部署服務

核心數據儲存主要使用了 MySQL https://www.mysql.com / Redis https://redis.io / Elasticsearch https://www.elastic.co/products/elasticsearch . MySQL 儲存了大部分業務數據（最大的消息數據表已經接近過億條記錄，所以不久之前我們也對該表進行了一次橫向切分遷移，下次再給大家介紹相關細節）。 Redis 作為萬金油既保存了部分非結構化的業務數據，也作為緩存用途保存了使用中產生的臨時數據。 Elasticsearch 則索引了 BearyChat 的消息、文件等可搜索的實體。

Take away: 核心數據部分，BearyChat 採用了成熟的開源技術，好處就是大部分坑都被人踩過填過了，工程師不需要浪費太多時間就能得到很好的成效。

API 服務和即時通信 RTM 服務可以放到一起講。這兩個模塊一「靜」一「動」。API 模塊是沒有狀態的服務，對外通過 HTTP 協議暴露介面。API 服務主要用了 Clojure https://clojure.org 來實現，跑在 JVM + Ubuntu 上。RTM 模塊則是一個大型的連接狀態機，所以用了 Erlang https://www.erlang.org 來實現，同時也是部署在 Ubuntu 上。對外可以通過 WebSocket / TCP 進行連接。

動靜兩個大模塊之間使用了兩種方式來進行跨服務通訊：

- RPC (Thrift https://thrift.apache.org)：服務間通過 RPC 調用來獲取狀態、信息
- RabbitMQ https://www.rabbitmq.com ：目前主要作為任務隊列來使用，會把用戶消息處理、搜索索引、推送等非同步任務放到這上面來進行消費

Take away:

這兩個模塊從最開始設計就堅持以下要求：

- 橫向擴展（x 軸）要方便：API 服務無狀態自然是簡單的。而 RTM 服務因為採用了 Erlang, 所以在進行橫向切分的時候也非常簡單。
- 縱向擴展（y 軸）要靈活：除了可以很方面加大機器性能來提升以外，還要在模塊內儘可能地應用服務狀態監控（目前使用了 ELK + Grafana stack. zipkin 等一大波 opentrace 工具正在路上）和進行業務解耦（API 模塊正在做從 monolithic app 遷移成 micro service 的相關重構）。
- 業務擴展（z 軸）要無痛：目前 BearyChat 產品是圍繞團隊這個概念來進行設計的，所以根據團隊切分（公有雲）、遷移到私有部署成本都會非常低。

私有部署服務 主要用於 BearyChat 的私有部署實現、發布、交付。BearyChat 的私有部署https://enterprise.bearychat.com 版本和公有雲版本產品功能基本相似，但會有其他針對大型組織體系實現的功能。同時因為私有部署環境不完全屬於工程師可以直接控制的範圍，所以目前搭配使用了以下技術：

- Docker https://www.docker.com: 私有部署實例會通過 docker 鏡像發布，同一個 docker 鏡像可以單獨作為完整服務啟動，也支持作為集群服務的節點啟動；
- Ansible https://www.ansible.com + Packer https://www.packer.io : 因為 dockerfile / docker composefile 本身表達語義和操作存在很大的局限性，所以私有部署鏡像使用了 ansible 作為 provision 腳本、packer 作為 repreduceable/identical 鏡像的構建器；
- Jenkins https://jenkins.io : 目前私有部署的打包發布會涉及 BearyChat 所有模塊，因此鏡像的打包會通過 若干個 Jenkins pipeline task 來完成串聯、自動化

Take away:

1. &docker 不保證兼容是 feature 不是 bug&
2. 構建複雜的工程需要關注變與不變的地方，通過把不變抽離出來能減少很多重複的步驟。在私有部署中，變的主要是核心模塊的代碼，不變（相對來說）的則是核心模塊的底層依賴

## 展望

除了要為更多的用戶提供更加高效的工作方法，BearyChat 的工程師也在以下幾個領域不斷推進：

- 更加快速的產品迭代、交付
- 微服務化 GraphQL
- 更加開放的機器人集成生態環境（機器人市場 OpenAPI https://github.com/bearyinnovative/OpenAPI ）
- 適應更加多組織企業的私有部署版本

最後打個小廣告：假如你認同 BearyChat 對高效工作的理念，也有興趣做一些不那麼 SoLoMo 但依舊很酷的東西，歡迎隨時跟我們聯繫

後端在使用 Clojure + Erlang
前端之前 AngularJs 現在轉成了 React
移動端 iOS 在用 swift

更多的特色在於自己使用 BearyChat 中不斷實踐 ChatOps ，大量使用第三方集成( GitHub Jenkins Sentry Trello ....)，以及自己定製的機器人來協助工作，比如 Hubot 用來列出上線內容的，執行構建，畫監控圖表等 。

代碼分布
後端 API 服務:

後端長連接服務：

前端聊天主界面：

前端其它頁面：