1、集群架構(gòu)
操作部署前請仔細(xì)閱讀 03 Temporal 詳細(xì)介紹 篇
2、Temporal Server 部署流程
原理是：啟動(dòng)前先用 dockerize 生成一遍實(shí)際使用的配置，然后再啟動(dòng)Server本體
Self-hosted Temporal Cluster guide | Temporal Documentation
新建應(yīng)用
app：編輯temporal-eco - 云效應(yīng)用 - temporal-eco
數(shù)據(jù)庫：temporal_eco 和 temporal_eco_vis
數(shù)據(jù)庫 Schema 創(chuàng)建及數(shù)據(jù)初始化
涉及系統(tǒng)環(huán)境變量
TEMPORAL_STORE_DB_NAME
TEMPORAL_STORE_DB_HOST
TEMPORAL_STORE_DB_PORT
TEMPORAL_STORE_DB_USER
TEMPORAL_STORE_DB_PWD
TEMPORAL_VISIBILITY_STORE_DB_NAME
TEMPORAL_VISIBILITY_STORE_DB_HOST
TEMPORAL_VISIBILITY_STORE_DB_PORT
TEMPORAL_VISIBILITY_STORE_DB_USER
TEMPORAL_VISIBILITY_STORE_DB_PWD
參考 鏈接 和 v1.12.0 Makefile
|
集群部署
frontend history matching 在創(chuàng)建服務(wù)時(shí)選 GRPC 服務(wù)，worker 選擇其他 (它在某個(gè)版本后不會(huì)暴露 GRPC 端口)，然后客戶端服務(wù)用 GRPC + 公司的服務(wù)發(fā)現(xiàn)連到 frontend 即可
Shards 數(shù)量
參考鏈接，確定數(shù)量為 4k = 4096。Shards 數(shù)量一旦確定，后續(xù)無法改變（唯一無法改變的配置）。Shards are very lightweight. There are no real implications on the cost of clusters. We (Temporal) have tested the system up to 16k shards.
組件數(shù)量及資源量
推薦值（v）參考鏈接
組件 | 數(shù)量 | 推薦 CPU 資源量 | 推薦內(nèi)存資源量 |
|---|---|---|---|
| frontend | 3 | 4 | 4Gi |
| history | 5 | 8 | 8Gi |
| matching | 3 | 4 | 4Gi |
| worker | 2 | 4 | 4Gi |
測試環(huán)境數(shù)量及資源量
組件 | 數(shù)量 = floor(v/2) | 推薦 CPU 資源量 = floor(v/4) | 推薦內(nèi)存資源量 = floor(v/4) |
|---|---|---|---|
| frontend | 1 | 1 | 1Gi |
| history | 2 | 2 | 2Gi |
| matching | 1 | 1 | 1Gi |
| worker | 1 | 1 | 1Gi |
生產(chǎn)環(huán)境數(shù)量及資源量
組件 | 數(shù)量 = floor(v/2) | 推薦 CPU 資源量 = floor(v/2) | 推薦內(nèi)存資源量 = floor(v/2) |
|---|---|---|---|
| frontend | 1 | 2 | 2Gi |
| history | 2 | 4 | 4Gi |
| matching | 1 | 2 | 2Gi |
| worker | 1 | 2 | 2Gi |
對接外部應(yīng)用的 Mesh 地址
update_at | ${unit}--master.app.svc |
|---|---|
| 2023.05.04 | temporal-frontend--master.temporal-eco.svc.cluster.local:80 |
3、部署細(xì)節(jié)
生產(chǎn)環(huán)境如何部署：Temporal Platform production deployments | Temporal Documentation
支持 Cassandra、MySQL 和 PostgreSQL（版本見鏈接），需要確定與 TiDB 的兼容性
數(shù)據(jù)庫 Schema 升級
通過指標(biāo)來進(jìn)行系統(tǒng)性能監(jiān)控與調(diào)優(yōu)
Server 拓?fù)渲械牟煌?wù)特性不同，最好獨(dú)立部署
the Frontend service is more CPU bound
the History and Matching services require more memory
Server 的一些數(shù)據(jù)大小限制
what-is-the-recommended-setup-for-running-cadence-temporal-with-cassandra-on-production
Frontend: Responsible for hosting all service api. All client interaction goes through frontend and mostly scales with rps for the cluster. Start with 3 instances of 4 cores and 4GB memory.
History: This hosts the workflow state transition logic. Each history host is running a shard controller which is responsible for activating and passivating shards on that host. If you provision a cluster with 4k shards then they are distributed across all available history hosts within the cluster through shard controller. If history hosts are scalability bottleneck, you just add more history hosts to the cluster. All history hosts form its own membership ring and shards are distributed among available nodes in the hash ring. They are quite memory intensive as they host mutable state and event caches. Start with 5 history instances with 8 cores and 8 GB memory.
Matching: They are responsible for hosting TaskQueues within the system. Each TaskQueue partition is placed separately on all available matching hosts. They usually scale with the number of workers connecting for workflow or activity task, throughput of workflow/activity/query task, and number of total active TaskQueues in the system. Start with 3 matching instances each with 4 cores and 4 GB memory.
Worker: This is needed for various background logic for ElasticSearch kafka processor, CrossDC consumers, and some system workflows (archival, batch processing, etc). You can just start with 2 instances each with 4 cores and 4 GB memory.
Number of history shards is a setting which cannot be updated after the cluster is provisioned. For all other parameters you could start small and scale your cluster based on need with time but this one you have to think upfront about your maximum load
Temporal server consists of 4 roles. Although you can run all roles within same process but we highly recommend running them separately as they have completely different concerns and scale characteristics. It also makes it operationally much simpler to isolate problems in production. All of the roles are completely stateless and system scales horizontally as you spin up more instances of role once you identify any bottleneck. Here are some recommendations to use as a starting point:
接入 SSO
打指標(biāo)到 Prometheus
如何配置 Grafana Dashboard
是否部署至 K8s 的討論
4、Temporal UI 部署流程
https://temporal-eco-ui.pek01.in.zhihu.com/namespaces/default/workflows
| 步驟 | 詳細(xì) | 遇到問題 | |
|---|---|---|---|
| 本地部署 | 基礎(chǔ)環(huán)境 |
| |
安裝依賴 （會(huì)產(chǎn)出temporal web 所需要的前端環(huán)境及代碼） | 安裝最新的 temporal server
構(gòu)建 ui-server
| 前端環(huán)境問題：nodejs、npm、pnpm
pnpm build:server 生成 assets 文件，否則報(bào) ui/assets 的 all:assets 找不到 Temporal UI requires Temporal v1.16.0 or later | |
第三方依賴 （產(chǎn)出通信所需的 proto 文件） |
| grpc 依賴 protobuf 協(xié)議（指定了依賴的代碼路徑）
| |
| 嘗試啟動(dòng) |
| 然后切到自建的 temporal server 上，再次啟動(dòng) | |
| 需關(guān)注文件 |
| 目前 temporal server 地址 是寫死在 temporal ui 代碼庫里的（但一般應(yīng)該不會(huì)變） 已做了動(dòng)態(tài)配置生成 | |
| 線上部署 | git clone git@git.in.zhihu.com:xujialong01/temporal-eco-server.git 配置 ui-server 服務(wù)地址 | 外部包導(dǎo)入個(gè)人倉庫，加快下載 與 UI 版本對齊（temporal server upgrade）文章來源：http://www.zghlxwxcb.cn/news/detail-759070.html |
參考資料
Temporal Platform production deployments | Temporal Documentation文章來源地址http://www.zghlxwxcb.cn/news/detail-759070.html
到了這里，關(guān)于Temporal部署指南：集群架構(gòu)、服務(wù)器部署流程、部署細(xì)節(jié)及Temporal UI配置的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
