概述

本人在使用藍鯨過程有些許心得，所以專門寫一個學習筆記供大家參考和學習，當然也為了我日後可以隨意參閱。

騰訊藍鯨智雲，簡稱藍鯨，是騰訊互動娛樂事業群（Interactive Entertainment Group，簡稱 IEG）自研自用的一套用於構建企業研發運營一體化體系的 PaaS 開發框架，提供了 aPaaS（DevOps 流水線、執行環境託管、前後臺框架）和 iPaaS（持續整合、CMDB、作業平臺、容器管理、資料平臺、AI 等原子平臺）等模組，幫助企業技術人員快速構建基礎運營 PaaS。

傳統的 Linux 等單機作業系統已發展數十年，隨著雲時代的到來，企業所需資源數暴增，操作節點（物理或虛擬伺服器及容器）數量普遍達到數千個，大型網際網路公司甚至達到百萬級別，混合雲模式成為常態，雖然 IaaS 供應商的出現從一定程度上解決了資源切割排程問題，但並未很好的解決資源與應用的融合，企業需要一種介於 IaaS 與應用（SaaS）之間的層級，用於遮蔽及控制 IaaS，快速開發及託管 SaaS，我們將其稱之為基礎 PaaS 層，並著重發展用於研發及託管企業內技術運營類 SaaS 的基礎運營 PaaS，並將其作為區別於傳統 OS 的下一代企業級分散式運營作業系統。

企業 IT 應用的全生命週期可劃分為研發、運維、運營三段，在各行業進行網際網路化轉型的過程中，融入敏捷思維，即形成持續整合、持續部署、持續運營的概念（CI-CD-CO）。

為降低轉型成本，不以增加人力數量為轉型前提，騰訊 IEG 以運維團隊作為轉型起點，充分利用這一群體低價值重複性工作量佔比高的特點，從 CD 領域切入，以 PaaS 技術進行運維自動化領域的煙囪治理，形成運維 PaaS 體系。將自動化所釋放的人力資源，轉型為運維開發團隊，利用 PaaS 的自增長屬性，將運維 PaaS 逐步向 CI 及 CO 拓展，最終完成企業級研發 - 運維 - 運營基礎 PaaS 構建，落地企業研發運營一體化。

在這裡我給大家普及一下IaaS，SaaS，PaaS的知識：

如果你是一個網站站長，想要建立一個網站。不採用雲服務，你所需要的投入大概是：買伺服器，安裝伺服器軟體，編寫網站程式。
現在你追隨潮流，採用流行的雲端計算，
如果你採用IaaS服務，那麼意味著你就不用自己買伺服器了，隨便在哪家購買虛擬機器，但是還是需要自己裝伺服器軟體
而如果你採用PaaS的服務，那麼意味著你既不需要買伺服器，也不需要自己裝伺服器軟體，只需要自己開發網站程式
如果你再進一步，購買某些線上論壇或者線上網店的服務,這意味著你也不用自己開發網站程式，只需要使用它們開發好的程式，而且他們會負責程式的升級、維護、增加伺服器等，而你只需要專心運營即可，此即為SaaS。

藍鯨體系架構

騰訊藍鯨智雲體系由原子平臺和通用的一級 SaaS 服務組成，平臺包括管控平臺、配置平臺、作業平臺、資料平臺、容器管理、PaaS 平臺、移動平臺等，通用 SaaS 包括節點管理、標準運維、日誌檢索、藍鯨監控、故障自愈等，為各種雲（公有云、私有云、混合雲）的使用者提供不同場景、不同需求的一站式技術運營解決方案。

在藍鯨體系架構中，配置平臺位於原子平臺層，通過藍鯨 PaaS 的 ESB 為上層 SaaS 提供覆蓋研發運營 CI（持續整合）、CD（持續交付和持續部署）、CO（持續運營）領域的配置管理能力。

騰訊藍鯨智雲體系依託企業級 SOA、 整合等理念，運用 Docker 等最先進的雲技術構建起了全新的運維模式， 致力於以“原子服務整合”和“低成本工具構建”的方式落地 DevOps，幫助運維快速實現“基礎服務無人值守”及“增值服務”，並進一步通過 DevOps 的落地實現企業更全面和可持續的效率提升。

藍鯨部署

對於藍鯨部署所需的硬體配置選型，並無規定。

藍鯨由眾多開源元件和自研元件構成。

開源元件的硬體選型可以參考相應的官方文件。

藍鯨產品本身的建議配置如下：

資源規劃是一個複雜的、動態的過程，更像是一門藝術而不是科學。如果硬體資源富餘，可以一開始拆分搭建部署。若硬體資源不足，一開始可以混合搭建，注意觀測資源消耗情況，可以適時增加機器，遷移模組的方式來保證整體的可用性。

這裡給出的一個比較合理的初始配置，基於以下考慮：

1. 分散式模組達到高可用至少三個節點，所以至少需要三個 OS (物理機或虛擬機器均可)。

2. BKDATA 是耗費資源最多的藍鯨元件。請分配到 4 核 16G 以上的機器。

3. 若日誌檢索，藍鯨監控是主要使用場景，請給 influxdb 和 elasticsearch 模組更多的記憶體，更好磁碟效能。如 SSD。

4. Nginx 模組所在的機器需要有對外提供服務，可訪問的 IP。這是藍鯨平臺的總入口。

5. 如果需要有跨雲管理需求，GSE 部署的機器需要有跨雲的網路條件。

根據以上考慮，安裝藍鯨初始配置，請滿足：

• 1臺 4核 16G
• 2臺 4核 8G

藍鯨元件

開源元件

開源元件的實際配置均在/data/bkce/etc目錄下，而這些配置檔案其實是通過變數替換/data/src/service/support-files/templates/(模板目錄路徑隨使用者解壓至的目錄而不同) 下的預設模板檔案生成的，所以要從源頭修改配置應該修改/data/src下的，然後通過以下命令同步，並渲染模板檔案：

• ./bkcec sync 模組
• ./bkcec render 模組

渲染模板時，bkcec 指令碼通過呼叫 templates_render.rc 裡定義的函式render_cfg_templates來實現

舉例說明，假設/data/src/service/support-files/templates/目錄下有如下檔案：

• #etc#nginx#job.conf

那麼當模板渲染時，它裡面的佔位符諸如__BK_HOME__會被對應的$BK_HOME變數的值替換掉然後生成/data/bkce/etc/nginx/job.conf這個檔案。 可以發現，指令碼將檔名中的#替換成/，然後放到$INSTALL_PATH目錄下，也就是預設的/data/bkce

• kafka#config#server.properties

這個形式的模板檔案和上述的不同之處時沒有以#開頭，那麼它表示一個相對模組安裝路徑的配置，也就是 對於/data/src/service/來說，它會被安裝到/data/bkce/service，那麼kafka#config#server.properties就會生成到/data/bkce/service/kafka/config/server.properties

• #etc#my.cnf.tpl

這類檔名和第一個不同之處在於多了.tpl的字尾名，生成時 tpl 字尾會被去掉。

其他模組檔案，以此類推。

以下列舉當前所有的開源元件配置檔案路徑：

Consul

Consul 的配置檔案比較特殊，因為它是全域性依賴， Consul 的配置檔案會存放在/data/bkce/etc/consul.conf，它沒有對應的模板檔案，是由/data/install/parse_config這個指令碼來生成。

不過 Consul 啟動的 supervisor 配置檔案模板在：

• #etc#supervisor-consul.conf

MySQL

• #etc#my.cnf.tpl

Redis

• #etc#redis.conf

Nginx

• #etc#nginx.conf

Nginx 主配置檔案，安裝時會ln -s /data/bkce/etc/nginx.conf /etc/nginx/nginx.conf

• #etc#nginx#paas.conf

PaaS 平臺的 Nginx server 配置

• #etc#nginx#cmdb.conf

配置平臺的 Nginx server 配置，主配置會 include/data/bkce/etc/nginx/下的配置檔案

• #etc#nginx#job.conf

作業平臺的 Nginx server 配置

• #etc#nginx#miniweb.conf

存放 Agent 安裝時所需要下載的指令碼和依賴軟體包

MongoDB

• #etc#mongodb.yaml

ZooKeeper

• #etc#zoo.cfg

RabbitMQ

• #etc#rabbitmq#rabbitmq-env.conf
• #etc#rabbitmq#rabbitmq.config
• #etc#rabbitmq#enabled_plugins

Elasticsearch

• es#config#elasticsearch.yml.tpl

Kafka

• kafka#config#server.properties

Beanstalk

• #etc#beanstalkd

InfluxDB

• #etc#influxdb.conf

藍鯨元件

藍鯨元件除了作業平臺和管控平臺，其他均用 supervisor 來做程序啟停，所以都會存在一個對應的 supervisor 程序配置檔案

它的標準規範是：#etc#supervisor-模組名-工程名.conf，如果沒有子工程，則工程名等於模組名。

例如 bkdata 存在三個子工程，所以各自的 supervisor 配置為：

• #etc#supervisor-bkdata-dataapi.conf
• #etc#supervisor-bkdata-databus.conf
• #etc#supervisor-bkdata-dataapi.conf

故障自愈模組，因為沒有子工程，所以它的 supervisor 配置檔案為：

• #etc#supervisor-fta-fta.conf

因為 supervisor 配置具有一致性，下面不再具體列舉 supervisor 相關配置檔案。

配置平臺 CMDB

CMDB 的後臺是微服務化架構，每個程序對應一個配置檔案，所以配置檔案模板也有很多，

• server#conf#模組名.conf

模組名對應程序名，比如程序名叫cmdb_webserver那它對應的配置檔名叫 webserver.conf

• #etc#nginx#cmdb.conf

CMDB 程序對應的 Nginx 配置，裡面會通過 url rewrite 相容 v2 的介面。cmdb_webserver 提供的 Web 頁面 也是經過這層 Nginx 反向代理。

作業平臺 JOB

作業平臺的配置檔案比較簡單。一個配置檔案，一個啟動指令碼：

• #etc#job.conf

主配置檔案，裡面的中文註釋非常詳盡，這裡不再贅述。

• job#bin#job.sh

Job 程序的啟停指令碼，裡面可以設定一些除錯引數，Java 虛擬機器記憶體分配大小等

PaaS

PaaS 平臺 在 src 目錄下叫 open_paas 它實際上由 appengine login esb paas 四個子工程組成。

• #etc#uwsgi-open_paas-工程名.ini

這裡工程名用上面四個工程分別替換可得到，是這四個 Python 工程 uwsgi 的配置檔案

以下四個分別是對應工程的 配置檔案

• paas#conf#settings_production.py.tpl
• login#conf#settings_production.py.tpl
• esb#configs#default.py.tpl
• appengine#controller#settings.py.tpl

其中 ESB 的配置中，配置了訪問其他周邊模組的介面域名和埠。

GSE

GSE 目錄下的模板檔案分為 agent、plugins、proxy、後臺。

GSE 後臺的配置模板，需要留意的是生成後的配置中監聽的 IP 地址是否符合預期：

• #etc#gse#api.conf
• #etc#gse#btsvr.conf
• #etc#gse#data.conf
• #etc#gse#dba.conf
• #etc#gse#task.conf

GSE Proxy 後臺的配置模板:

• proxy#etc#btsvr.conf
• proxy#etc#proxy.conf
• proxy#etc#transit.conf

GSE Agent 的配置模板，*表示匹配所有的，這裡 Agent 按系統和 CPU 架構區分了不同的目錄

• agent_*#etc#agent.conf
• agent_*#etc#iagent.conf
• agent_*#etc#procinfo.conf

GSE agent plugins 的配置模板

• plugins_*#etc#basereport.conf
• plugins_*#etc#alarm.json

paas_agent

paas_agent 是 appo、和 appt 模組對應的後臺程式碼目錄，它的配置檔案由兩部分構成：

• #etc#nginx.conf #etc#nginx#paasagent.conf

paas_agent 依賴一個 Nginx 做路由轉發，這裡是它的 Nginx 配置

• #etc#paas_agent_config.yaml.tpl

paas_agent 的主配置，需要特別注意的是，這裡的sid和token是啟用 paas_agent 成功後，獲取返回的字串自動填充的，裡面的配置應該和開發者中心，伺服器資訊頁面看到的一致

BKDATA

BKDATA 分為dataapi、databus、monitor三個工程，

dataapi 是 Python 工程，databus 是 Java 工程，monitor 是 Python 工程。

dataapi 的配置：

• dataapi#conf#dataapi_settings.py
• dataapi#pizza#settings_default.py
• dataapi#tool#settings.py

databus 的配置：

• databus#conf#es.cluster.properties
• databus#conf#jdbc.cluster.properties
• databus#conf#tsdb.cluster.properties
• databus#conf#etl.cluster.properties
• databus#conf#redis.cluster.properties

monitor 的配置：

• monitor#bin#environ.sh
• monitor#conf#worker#production#community.py

故障自愈 FTA

故障自愈後臺的配置

• fta#project#settings_env.py

PaaS平臺

藍鯨 PaaS 平臺是一個開放的平臺，又稱藍鯨 PaaS。該產品在藍鯨體系中有 3 個重要的作用：

一、面向普通使用者，它是進入藍鯨體系的第一個產品，提供了通用的基礎服務，如登入認證、訊息通知、其他產品的快捷入口（工作臺）、獲取更多產品的應用市場等；

二、面向開發人員，它提供了很多的 “SaaS 開發者服務”，讓開發者可以簡單、快速地建立、部署和管理應用，它提供了完善的前後臺開發框架、API 閘道器（ESB）、排程引擎、公共元件等模組，幫助開發者快速、低成本、免運維地構建支撐工具和運營系統。PaaS 平臺為一個應用從建立到部署，再到後續的維護管理提供了完善的自助化和自動化服務，如日誌查詢、監控告警、運營資料等，從而使開發者可以將全部精力投入到應用的開發之中。主要功能有：支援多語言的開發框架 / 樣例、免運維託管、SaaS 運營資料視覺化、企業服務匯流排（API 閘道器）、可拖拽的前端服務（MagicBox）等。

三、面向系統維護人員（系統管理員），它提供了使用者管理（含角色管理）、伺服器基本資訊維護、第三方服務視覺化管理、API 許可權控制等功能，更好地維護和管理平臺的可用性。

目前，藍鯨 PaaS 平臺已正式對外開源，GitHub 地址：https://github.com/Tencent/bk-PaaS

配置平臺

藍鯨配置平臺是一款面向應用的 CMDB，在 ITIL 體系裡，CMDB 是構建其它流程的基石，而在藍鯨智雲體系裡，配置平臺就扮演著基石的角色，為應用提供了各種運維場景的配置資料服務。它是企業 IT 管理體系的核心，通過提供配置管理服務，以資料和模型相結合對映應用間的關係，保證資料的準確和一致性；並以整合的思路推進，最終面向應用消費，發揮配置服務的價值。

目前，藍鯨配置平臺已正式對外開源，GitHub 地址：https://github.com/Tencent/bk-cmdb

作業平臺

作業平臺（JOB）是一套基於藍鯨智雲管控平臺 Agent 管道之上的基礎操作平臺，具備萬級併發處理能力。除了支援指令碼執行、檔案拉取 / 分發、定時任務等一系列可實現的基礎運維場景以外，還運用流程化的理念很好的將零碎的單個任務組裝成一個作業流程。而每個任務都可做為一個原子節點，提供給其它系統和平臺排程，實現排程自動化。

除了批量執行的萬級高併發效能優勢，作業平臺還支援複雜的運維操作場景，定製作業功能將一個操作流程製作成完整的作業任務，豐富的 API 開放介面使得作業任務原子化，提供給其它系統或平臺進行排程，進一步擴大了業務使用場景。

作業平臺分為 Web 層和後臺任務排程層，並通過訊息佇列來消費任務，任務執行依賴底層的管控平臺，管控平臺採用 C/S 架構，使用者只需要在目標機上安裝藍鯨 Agent，即可通過作業平臺實現指令碼執行或檔案分發。

管控平臺

藍鯨管控平臺，是整個藍鯨平臺的底層管控系統，是藍鯨所有其他服務的基礎，是藍鯨服務體系與使用者機器的聯結器。

在整個藍鯨體系中，藍鯨管控平臺作為藍鯨的底層管控通道，沒有提供獨立的介面供使用者直接訪問呼叫，而是通過藍鯨 esb 能力向上提供服務，供上層平臺或者 SaaS 去實現場景賦能，藍鯨管控平臺主要提供了三種類型的服務能力：檔案傳輸能力、實時任務執行能力、資料採集與傳輸的能力。

從網路框架層面來看，藍鯨管控平臺分為兩層網路架構，分別為服務層和業務代理層，服務層由三種不同型別的服務叢集構成：控制任務執行的 TaskServer 叢集、負責資料採集傳輸服務的 DataServer 叢集以及提供檔案高速傳輸服務的 FileServer 叢集，業務代理層則是部署在業務伺服器上的藍鯨Agent，承載了服務層提供的三種服務。

Agent：藍鯨智慧 Agent，可以安裝在業務需要管控的實體機、虛擬機器或者容器裡面，BK Agent 是藍鯨管控平臺提供三大服務能力的實際執行者。

PA：藍鯨管控平臺跨雲代理節點，為雲區域 BK Agent 提供代理轉發服務，提供跨雲區域機器管控能力。

TaskServer：藍鯨管控平臺任務及控制服務端程式，該程式提供對叢集內 Agent 的管理能力，並支援對 Agent 批量下發和執行發命令或指令碼。

FileServer：藍鯨管控平臺檔案傳輸控制服務端程式，該程式對指定範圍內 Agent 節點提供 BT 種子服務，保證對傳輸的安全性、不同區域及業務模組間的隔離性，並控制 BT 傳輸在有限的貪婪特性範圍內。

DataServer：藍鯨管控平臺數據傳輸服務端程式，該服務端主要提供對 Agent 採集的資料進行匯聚、分類、流轉能力。對於普通的千兆網絡卡機器，BK DataServer 能夠提供百兆級別的資料處理能力。

Redis：Redis 在本系統中提供工作區資料快取作用。

Zookeeper：Zookeeper 主要提供對叢集的管理能力，包括叢集中不同節點間的相互發現，有效性探測等。

容器管理平臺

藍鯨容器服務（BCS，Blueking Container Service）是高度可擴充套件、靈活易用的容器管理服務。

藍鯨容器服務支援兩種不同的叢集模式，分別為原生Kubernetes模式和基於Mesos自研的模式。

使用者無需關注基礎設施的安裝、運維和管理，只需要呼叫簡單的 API，或者在頁面上進行簡單的配置，便可對容器進行啟動、停止等操作，檢視叢集、容器及服務的狀態，以及使用各種元件服務。

使用者可以依據自身的需要選擇容器編排的方式，以滿足業務的特定要求。

BCS 是統一的容器部署管理解決方案，為了適應不同業務場景的需要，BCS 內部同時支援基於 Mesos 和基於 K8S 的兩種不同的實現。

BCS 由BCS SaaS和BCS 後臺組成，以下為對應的架構圖。

BCS SaaS 架構圖

BCS SaaS 功能結構圖

BCS SaaS 作為 BCS 的上層產品，包含已開源的專案管理系統（bcs-projmgr）、容器服務產品層主體功能模組（bcs-app）、底層的配置中心模組（bcs-cc）以及未開源的監控中心，同時它依賴藍鯨體系下的其他產品服務（如 PaaS、CMDB 等）。

SaaS 依賴的服務介紹：

• bk-PaaS: 為 BCS SaaS 提供了 4 大服務(統一登入、開發者中心、ESB 和應用引擎)，其中 bcs-app 由應用引擎託管

• bk-bcs-services: BCS 底層服務。作為後臺服務，bk-bcs-services 給 bcs-app 提供了叢集搭建，應用編排等豐富的底層介面，更多詳見下BCS 後臺架構圖。

• bk-cmdb: 藍鯨配置平臺。bcs-app 的叢集管理功能涉及的業務和主機資訊來源於配置平臺

• bk-iam: 藍鯨許可權中心，BCS SaaS 基於 bk-iam，實現了使用者與平臺資源之間的許可權控制

• bk-Habor: 藍鯨容器管理平臺映象倉庫服務。bcs-app 使用 bk-Habor 提供的 API，實現了業務映象的查詢與配置功能

BCS SaaS 部署拓撲圖

SaaS 包含 bcs-projmgr, bcs-app, bcs-cc 三個模組。

SaaS 依賴的後端服務 bk-bcs-services 也已開源，bk-iam 等灰色標註的系統暫未開源，需要依託藍鯨獨立部署版本進行搭建。

BCS 後臺架構圖

下圖為 BCS 以及 Mesos 叢集的整體架構圖：BCS Client 或者業務 SaaS 服務通過 API 接入，API 根據訪問的叢集將請求路由到 BCS 下的 Mesos 叢集或者 K8S 叢集。

Kubenetes 容器編排的說明：

• BCS 支援原生 K8S 的使用方式。
• K8S 叢集執行的 Agent（bcs-k8s-agent） 向 BCS API 服務進行叢集註冊。
• K8S 叢集執行的 Data Watch 負責將該叢集的資料同步到 BCS Storage。

Mesos 編排的具體說明：

• Mesos 自身包括 Mesos Master 和 Mesos Slave 兩大部分，其中 Master 為中心管理節點，負責叢集資源排程管理和任務管理；Slave 執行在業務主機上，負責宿主機資源和任務管理。
• Mesos 為二級排程機制，Mesos 本身只負責資源的排程，業務服務的排程需要通過實現排程器（圖中 Scheduler）來支援，同時需實現執行器 Executor（Mesos 自身也自帶有 Executor）來負責容器或者程序的起停和狀態檢測上報等工作。
• Mesos（Master 和 Slave）將叢集當前可以的資源以 offer（包括可用 CPU、MEMORY、DISK、埠以及定義的屬性鍵值對）的方式上報給 Scheduler，Scheduler 根據當前部署任務來決定是否接受 Offer，如果接受 Offer，則下發指令給 Mesos，Mesos 呼叫 Executor 來執行容器。
• Mesos 叢集資料儲存在 ZooKeeper，通過 Datawatch 負責將叢集動態資料同步到 BCS 資料中心。
• Mesos Driver 負責叢集介面轉換。
• 所有中心服務多例項部署實現高可用：Mesos driver 為 Master-Master 執行模式，其他模組為 Master-Slave 執行模式。服務通過 ZooKeeper 實現狀態同步和服務發現。

總結

本人本著學習和選擇比較重要的部分進行摘抄和總結官網，詳細見官方文件：