凹凸技術揭祕 · 基礎服務體系 · 構築服務端技術中樞

凹凸實驗室發表於2021-01-15

服務端

前言

凹凸實驗室從最初的前端團隊成長為如今的全端團隊，意味著我們不僅關注前端的技術能力，也重視全端及全棧的能力。在這一篇，我們從前端團隊角度出發，闡述我們最初搭建服務端體系遇到的一些困難，已構建的服務體系架構，以及如何更好地助力業務增長。

些許似曾相識

首先，我們來看下日常工作中存在的一些場景。

場景A：在某些業務中，底層資料團隊提供的資料介面並沒有提供 HTTP 呼叫，需要去尋找其他服務端團隊來封裝，這時候需要等待其他團隊排期，可能造成業務無法正常上線；
場景B：前端頁面效能卡頓，由於呼叫介面過多，需要等待其他服務端團隊聚合資料；
場景C：我們在一些專案需要SSR，前後端需要複用統一套模板；
場景D：我們內部孵化了一些專案，需要介面服務，需要等待其他服務端團隊支援。

這些場景的背後，我們急需組建一個服務端研發團隊來承擔部分的業務服務開發以及更好地幫助團隊未來發展。

成型

在團隊組建上，主要採用「內部選拔」 + 「外部招聘」2 種方式。在團隊發展上，我們主要經歷了 3 個階段。

雛形

在最初的階段，選擇以 NodeJS 作為服務端程式語言，主要以下有 2 點考慮：

團隊大部分同學熟悉 Javascript，能夠快速學習 NodeJS，上手成本較低；
在 SSR 方面有天然的優勢，前後端能夠共用部分程式碼。

在這個階段，我們快速孵化了一系列的系統和平臺，比如 Mock 平臺、前端監控平臺、兜底平臺等等，主要目標豐富前端研發體系，提升前後端的開發及協作效率，同時也沉澱了一些 NodeJS 中介軟體。

成長

在服務開發效率、效能、穩定、安全等方面有了一定的沉澱之後，我們開始思考如何更加規範服務開發，更加高效地支撐業務增長。

在這個階段，我們不僅輸出了「研發規範」、「研發流程」、「開發框架」等一系列的知識體系，也搭建了「部署平臺」、「通用管理平臺」等相關研發平臺。在業務開發上，我們用 NodeJS 實現了「天狗」遊戲服務、用 OpenResty 實現了「資料聚合服務」、在某些頻道上採用了 SSR 等等。

賦能

在設計中臺中，我們沉澱了大量的通用服務，比如「頁面」、「圖片」、「編譯」相關的服務，部分服務賦能給了其他團隊，比如說我們將頁面智慧設計相關的服務賦能給了「江湖平臺」、「智鋪」等產品。

在公司內部，大部分的服務端團隊技術棧主要是 Java，在服務間呼叫採用了集團內部自研的 JSF 協議。而我們團隊主要技術棧依然以 NodeJS 為主，給其他團隊提供 HTTP 呼叫，與 Java 在接入方式、限流、程式碼提醒等方面存在較大差異，也無法很好利用集團內大量的中介軟體。

在這個階段，我們引入了 Java 技術棧，形成了以「NodeJS + Java」為主要服務端語言的技術體系。針對部分領域服務，我們提供了 Java 版本的 JSF 服務實現，方便第三方團隊溝通合作。

體系結構

經過幾年的沉澱，我們團隊在服務端領域構建出了初步的體系結構。

服務端研發體系的建設，主要目標是為了提升團隊程式碼的下限，提升開發效率，提高服務交付質量，促使團隊共同成長。

system

構建一套服務端研發體系，主要圍繞 8 個方面展開，包含研發規範、研發平臺、研發流程、文件建設、團隊管理、監控告警、中介軟體管理以及基礎設施。

platform

在整體服務架構上，我們日常的開發採用分層結構的模式，儘可能去抽離出通用的服務邏輯，輸出更多的積木，降低我們的開發和維護成本。

以下從「業務支撐」和「技術建設」方面去簡單闡述我們近幾年在服務端領域的一些探索和實踐。

業務支撐

業務是團隊的立命之本，只有在業務的快速增長中才能不斷去驗證和優化我們整個服務體系，保證整體服務的可靠性。

羚瓏服務

羚瓏全稱羚瓏智慧設計平臺，提供一站式線上設計服務：一鍵摳圖、免費摳圖、商品打腰帶、改尺寸、商品主圖設計、線上廣告banner設計、店鋪首頁設計、活動頁設計、頁面設計、互動營銷設計、小程式設計、動圖視訊設計、視訊廣告設計、商品主圖視訊設計、海報設計、公眾號配圖設計、二維碼名片設計、DM傳單設計、物流面貼設計、易拉寶設計、張貼海報設計等等。提供海量精美模板和免費素材，免費設計，另設有企業專區，是致力於成為商家經營的設計合作伙伴的平臺。

其下的羚瓏智慧頁面設計是集結業內各色資深電商行業設計師，提供一站式專業智慧頁面和小程式設計服務的平臺。整個架構服務輕量化、模組化，更便捷擴充專區業務場景。服務架構如下：

服務架構圖

整體架構分為 Web 應用層、介面層、服務層和資料層四部分，這樣拆分能做到入口統一，在部署上單點部署讓釋出更加便捷，獨立部署則降低模組更新對整體服務的影響：

Web 應用層：包括羚瓏及其他的平臺應用；
介面層：提供閘道器服務，應用層的請求經由閘道器，通過許可權校驗，轉發到各個模組去；
服務層：主要分為下面四部分：
- 服務通訊：非同步通訊使用 MQ，RPC 通訊採用 HTTP 呼叫的方式；
- 業務模組：也即服務的核心邏輯，它們被按照功能邏輯劃分成不同的模組，模組內獨立地處理大部分功能，達到高內聚低耦合的效果；
- 基礎服務：支撐業務模組的基礎功能，統一把控使用者與許可權；
- 服務管理：用於服務輔助，提升服務的穩定性、健壯性和靈活性。
資料層：服務主要使用到了 MongoDB 和 Redis，前者為主要儲存，後者用於資料快取。

專案使用 Typescript 開發，遵循統一的介面規範，保證出入參的風格統一，模組化的設計讓服務運維和迭代輕鬆，在功能上，支援專區和場景的插拔式擴充，讓業務變得無限可能。

資料聚合服務

在電商的業務中，比如頻道、大促活動這種型別的業務會經常使用到商品組、廣告組的資料，在通用的介面裡面會出現較多冗餘的欄位，特別在批量查詢服務的時候，整個響應包會比較大。

我們採用 OpenResty 實現了 GraphQL 服務，資料按需載入，能夠有效減少資料包大小；資料自動兜底，能夠保障服務可用性，尤其在大促期間底層服務出現響應慢的情況下。

o2api

技術建設

必要的基礎建設和技術探索，是為了更好地幫助業務和團隊面向未來。

以下圍繞「Talos部署平臺」和「通用管理平臺」來闡述我們在服務端方面的一些基礎建設。

Talos 部署平臺

Talos 部署平臺基於內部的 JDOS 平臺開發而來，主要是提供應用資源管理和部署功能，解決部署難、開發效率低、服務運維成本高等問題，使研發同學更專注於開發。

主要架構圖如下：
Talos 框架圖

我們從「資源管理」、「應用部署」這兩個方面來簡單介紹下該平臺。

資源管理

Talos 專案分組

專案分組功能，可方便開發者管理以及檢視分組下應用、流量、資源佔用等情況。

Talos 靜態網站部署方式

靜態網站部署支援將靜態網站應用部署至同一後端應用中，瀏覽器訪問時根據域名或者前置路由匹配對應檔案，達到節省資源，提高資源利用率的目。

除此之外，還有其他的一些功能：

提供 Talos 閘道器，方便服務轉發及掛載；
提供 MongoDB 視覺化皮膚功能，方便開發同學檢視線上資料庫，提供只讀、讀寫等許可權；
提供全流程監控功能，包括應用建立、部署、容器調整等，執行過程中 cpu、磁碟、負載等超過閾值也會告警；
其他還有容器數量調整、大促時上線限制、通知等功能。

應用部署

支援多環境部署，可設定測試、預發、生產等環境，每個環境下有各自單獨的配置檔案、配置屬性欄位等，支援一鍵部署、回滾、下線等操作，部署介面如下圖：

Talos 應用部署

支援不同專案型別部署，如 NodeJS、靜態站點、自定義部署等。

Talos 不中斷部署

支援不中斷部署，利用 JDOS 的滾動更新介面，控制流程切換，將應用容器分為前後兩批滾動更新，確保更新過程中應用不會中斷。

通用管理平臺

在開發過程中，往往需要硬編碼一些資料，而大多數的資料在以後的維護、運營中時不時需要更新。過去我們經常被這些瑣碎的修改資料給佔用了些時間，降低了編碼效率。解決這個問題有兩種方式，第一種在資料庫中儲存變更資料，開發對應服務端介面進行 CRUD。這種方式我們需要的資源有資料庫、服務端開發、閘道器域名，這麼看來得不償失了。而第二種就是在平臺中動態配置表單，定義資料結構，再錄入資料，同時平臺提供統一的 CRUD 閘道器 API。在上述的背景下，通用內容管理平臺應運而生。下面來看看提供了哪些實用的功能！

通用管理平臺提供了表單、資料建立，滿足了大部分配置管理功能；同時提供了許可權管理功能，可以供產品/運營同事更新資料，擺脫讓開發同學修改資料/版本釋出的煩惱。

通用管理平臺大綱