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

時間 2021-01-16

標籤前端正則表達式數據庫編程小程序後端 api 瀏覽器緩存安全欄目正則表達式简体版

原文原文鏈接

前言

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

些許似曾相識

首先，咱們來看下平常工做中存在的一些場景。正則表達式

場景A：在某些業務中，底層數據團隊提供的數據接口並無提供 HTTP 調用，須要去尋找其餘服務端團隊來封裝，這時候須要等待其餘團隊排期，可能形成業務沒法正常上線；
場景B：前端頁面性能卡頓，因爲調用接口過多，須要等待其餘服務端團隊聚合數據；
場景C：咱們在一些項目須要SSR，先後端須要複用統一套模板；
場景D：咱們內部孵化了一些項目，須要接口服務，須要等待其餘服務端團隊支持。

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

成型

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

雛形

在最初的階段，選擇以 NodeJS 做爲服務端編程語言，主要如下有 2 點考慮：小程序

團隊大部分同窗熟悉 Javascript，可以快速學習 NodeJS，上手成本較低；
在 SSR 方面有自然的優點，先後端可以共用部分代碼。

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

成長

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

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

賦能

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

在公司內部，大部分的服務端團隊技術棧主要是 Java，在服務間調用採用了集團內部自研的 JSF 協議。而咱們團隊主要技術棧依然以 NodeJS 爲主，給其餘團隊提供 HTTP 調用，與 Java 在接入方式、限流、代碼提醒等方面存在較大差別，也沒法很好利用集團內大量的中間件。安全

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

體系結構

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

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

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

在總體服務架構上，咱們平常的開發採用分層結構的模式，儘量去抽離出通用的服務邏輯，輸出更多的積木，下降咱們的開發和維護成本。

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

業務支撐

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

羚瓏服務

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

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

總體架構分爲 Web 應用層、接口層、服務層和數據層四部分，這樣拆分能作到入口統一，在部署上單點部署讓發佈更加便捷，獨立部署則下降模塊更新對總體服務的影響：

Web 應用層：包括羚瓏及其餘的平臺應用；
接口層：提供網關服務，應用層的請求經由網關，經過權限校驗，轉發到各個模塊去；
服務層：主要分爲下面四部分：
- 服務通訊：異步通訊使用 MQ，RPC 通訊採用 HTTP 調用的方式；
- 業務模塊：也即服務的核心邏輯，它們被按照功能邏輯劃分紅不一樣的模塊，模塊內獨立地處理大部分功能，達到高內聚低耦合的效果；
- 基礎服務：支撐業務模塊的基礎功能，統一把控用戶與權限；
- 服務管理：用於服務輔助，提高服務的穩定性、健壯性和靈活性。
數據層：服務主要使用到了 MongoDB 和 Redis，前者爲主要存儲，後者用於數據緩存。

項目使用 Typescript 開發，遵循統一的接口規範，保證出入參的風格統一，模塊化的設計讓服務運維和迭代輕鬆，在功能上，支持專區和場景的插拔式拓展，讓業務變得無限可能。

數據聚合服務

在電商的業務中，好比頻道、大促活動這種類型的業務會常用到商品組、廣告組的數據，在通用的接口裏面會出現較多冗餘的字段，特別在批量查詢服務的時候，整個響應包會比較大。

咱們採用 OpenResty 實現了 GraphQL 服務，數據按需加載，可以有效減小數據包大小；數據自動兜底，可以保障服務可用性，尤爲在大促期間底層服務出現響應慢的狀況下。

技術建設

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

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

Talos 部署平臺

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

主要架構圖以下：

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

資源管理

項目分組功能，可方便開發者管理以及查看分組下應用、流量、資源佔用等狀況。

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

除此以外，還有其餘的一些功能：

提供 Talos 網關，方便服務轉發及掛載；
提供 MongoDB 可視化面板功能，方便開發同窗查看線上數據庫，提供只讀、讀寫等權限；
提供全流程監控功能，包括應用建立、部署、容器調整等，運行過程當中 cpu、磁盤、負載等超過閾值也會告警；
其餘還有容器數量調整、大促時上線限制、通知等功能。

應用部署

支持多環境部署，可設置測試、預發、生產等環境，每一個環境下有各自單獨的配置文件、配置屬性字段等，支持一鍵部署、回滾、下線等操做，部署界面以下圖：

支持不一樣項目類型部署，如 NodeJS、靜態站點、自定義部署等。

支持不中斷部署，利用 JDOS 的滾動更新接口，控制流程切換，將應用容器分爲先後兩批滾動更新，確保更新過程當中應用不會中斷。

通用管理平臺

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

通用管理平臺提供了表單、數據建立，知足了大部分配置管理功能；同時提供了權限管理功能，能夠供產品/運營同事更新數據，擺脫讓開發同窗修改數據/版本發佈的煩惱。