在現代雲端運算架構中,分散式計算框架已經成為處理大規模資料與複雜任務的核心技術。Ray 作為新世代的分散式計算框架,憑藉其簡潔的 API 設計、強大的 Actor 模型支援,以及優秀的容器化整合能力,快速從學術研究領域進入企業生產環境。然而將 Ray 成功導入企業級應用並非僅是技術選型的問題,更涉及架構設計、資源管理、容錯機制、監控維運等多個面向的綜合考量。本文將從實務角度出發,深入探討 Ray 在企業環境中的應用策略,涵蓋容器化部署、Actor 模型設計模式、資源池管理最佳化、優雅關閉機制實作,以及與 Kubernetes 的深度整合。透過 Space Beaver 專案的真實案例分析,展示如何設計可靠的分散式訊息處理系統,協助開發團隊建立可擴展且維護性良好的分散式應用架構。
Ray 框架核心概念與企業價值
Ray 的設計理念源自對現有分散式框架限制的突破,試圖提供更簡潔直觀的程式設計模型,同時保持高效能與可擴展性。傳統的分散式計算框架往往需要開發者處理複雜的叢集管理、任務排程、故障恢復等底層細節,這不僅增加開發複雜度,也提高維護成本。Ray 透過統一的程式設計抽象,讓開發者能專注於業務邏輯實作,框架自動處理分散式執行的各種複雜性。
統一的分散式程式設計抽象
Ray 提供兩個核心抽象概念,遠端函式與 Actor 模型。遠端函式透過裝飾器將普通的 Python 函式轉換為可以非同步執行的分散式任務,這個設計讓開發者能以最小的程式碼修改實現函式的分散式執行。遠端函式特別適合無狀態的計算任務,如資料處理、模型訓練、批次運算等場景。
Actor 模型則提供有狀態的分散式物件抽象,每個 Actor 維護自己的狀態,透過訊息傳遞進行通訊。這個模型特別適合需要維護長期狀態的場景,如會話管理、快取服務、訊息佇列等。Actor 的狀態封裝在物件內部,避免共享狀態帶來的並行問題,同時提供自然的錯誤隔離機制。
兩種抽象的結合讓 Ray 能處理各種複雜的分散式計算模式。無狀態的資料處理可以使用遠端函式快速並行,有狀態的服務邏輯可以使用 Actor 模型優雅實作。這種靈活性讓 Ray 能適應從批次資料處理到即時服務,從機器學習訓練到線上推論等各種應用場景。
企業導入的關鍵考量
將 Ray 導入企業環境需要考慮多個面向的問題,單純的技術優勢不足以確保成功導入。首要考量是與現有技術堆疊的整合能力,企業通常已經建立完整的基礎設施與工具鏈,新框架必須能無縫融入而非取代整個體系。Ray 對容器化技術的良好支援,讓其能輕鬆整合到基於 Docker 與 Kubernetes 的雲端原生架構中。
安全性與多租戶隔離是企業環境的基本要求。Ray 需要在多個團隊或專案共用叢集資源的情況下,確保適當的資源隔離與存取控制。這涉及認證機制、授權管理、網路隔離等多個層面。雖然 Ray 本身提供基礎的安全功能,但企業級的完整安全架構往往需要額外的整合與客製化。
可觀測性與監控是生產環境運作的關鍵。分散式系統的除錯與效能分析比單機應用複雜許多,需要完整的日誌收集、指標監控、分散式追蹤等能力。Ray 提供基礎的儀表板與指標,但與企業既有的監控系統如 Prometheus、Grafana、ELK Stack 的整合需要額外的工作。
運維模式的選擇也是重要決策,是建立長期運行的永久叢集,還是按需建立的臨時叢集。永久叢集能提供穩定的資源與快速的任務啟動,但需要持續的資源投入與維護成本。臨時叢集能更有效利用資源,但任務啟動時間較長且需要額外的叢集生命週期管理。選擇取決於應用特性、成本考量、團隊能力等因素。
Docker 容器化整合策略
容器化已經成為現代應用部署的標準方式,Ray 對 Docker 的深度整合讓其能充分利用容器化帶來的各種優勢。透過容器,可以精確控制執行環境,確保開發、測試、生產環境的一致性。容器也提供輕量級的隔離機制,讓不同的任務或服務能在相同的叢集中安全運行而不互相干擾。
Ray 與 Docker 的整合模式
Ray 支援將遠端函式或 Actor 在 Docker 容器中執行,這個能力解決許多實務問題。最直接的應用是多語言環境支援,雖然 Ray 本身是 Python 框架,但透過容器可以執行任何語言的應用程式。只需要準備包含目標語言執行環境的容器映像,就能在 Ray 叢集中呼叫這些異質的計算資源。
相依套件管理是另一個重要應用場景。不同的專案或任務可能需要不同版本的函式庫,在同一個 Python 環境中管理這些相依關係容易產生衝突。透過容器,每個任務可以使用專屬的映像,包含特定版本的相依套件,避免版本衝突問題。這種隔離也提升安全性,惡意或有問題的程式碼被限制在容器內,影響範圍受到控制。
預建映像的重用能大幅加速部署流程。團隊可以建立標準化的基礎映像,包含常用的工具與函式庫,新專案基於這些映像進行客製化。映像可以在開發階段建立並在 CI/CD 流程中驗證,確保到達生產環境的映像品質。映像倉儲如 Docker Hub 或私有 Registry 提供版本管理與快速分發能力。
import ray
ray.init()
@ray.remote(
runtime_env={
"container": {
"image": "rayproject/ray-ml:latest-gpu",
"worker_path": "/root/anaconda3/bin/python"
}
}
)
def gpu_training_task(data):
import tensorflow as tf
model = tf.keras.Sequential([
tf.keras.layers.Dense(128, activation='relu'),
tf.keras.layers.Dense(10, activation='softmax')
])
model.compile(optimizer='adam', loss='sparse_categorical_crossentropy')
model.fit(data['x'], data['y'], epochs=10)
return model.get_weights()
result = ray.get(gpu_training_task.remote(training_data))
上述範例展示如何指定遠端函式使用特定的容器映像執行。runtime_env 參數定義執行環境,container 區塊指定映像名稱與 Python 直譯器路徑。這個機制讓函式能在包含 GPU 支援的 TensorFlow 環境中執行,而不需要在每個 Ray 節點上安裝相同的環境。
容器映像的最佳實務
建立高品質的容器映像需要遵循一些最佳實務。映像應該盡可能精簡,只包含必要的元件與函式庫,減小映像大小能加快拉取與啟動速度。多階段建置是實現精簡映像的有效技術,在建置階段使用完整的開發工具,在最終映像中只保留執行時需要的檔案。
安全性是容器映像的重要考量。基礎映像應該選擇官方維護且持續更新的版本,及時修補已知漏洞。避免在映像中包含敏感資訊如密碼或 API 金鑰,這些應該透過環境變數或秘密管理系統注入。定期掃描映像的安全漏洞,使用工具如 Trivy 或 Clair 自動化檢查。
版本管理與標籤策略影響部署的可靠性。避免使用 latest 標籤在生產環境,應該使用明確的版本號確保部署的一致性。語意化版本控制提供清楚的版本演進資訊,方便追蹤變更與回退。建立映像時記錄建置資訊如提交雜湊、建置時間等,協助追溯問題來源。
Space Beaver 專案架構分析
Space Beaver 是展示 Ray 企業應用的典型案例,這個專案提供離線訊息傳遞服務,整合衛星通訊、電子郵件、簡訊等多種通訊管道。系統最初使用 Scala 與 Akka 框架建構,後來遷移到 Ray 與 Python 生態系統。這個遷移決策基於幾個考量,Python 生態系統提供更豐富的資料處理與機器學習函式庫,簡化部署與維護流程,以及能重用既有的 Web 應用程式碼。
系統架構與設計原則
Space Beaver 的核心功能是作為不同通訊協定之間的橋接,使用者透過電子郵件或簡訊發送訊息,系統將訊息轉換並透過衛星網路傳送,反向的訊息流程也同樣支援。這個看似簡單的功能背後涉及複雜的狀態管理、協定轉換、可靠性保證等問題。
系統採用 Actor 模型組織核心邏輯,不同的通訊管道對應不同類型的 Actor。使用者 Actor 維護使用者的狀態與偏好設定,處理進出訊息的路由邏輯。電子郵件 Actor 負責 SMTP 伺服器的運作,接收外部郵件並轉發給使用者。簡訊 Actor 透過第三方 API 如 Twilio 發送與接收簡訊。衛星 Actor 與衛星服務供應商的 API 互動,處理衛星訊息的傳送與接收。
@startuml
!define DISABLE_LINK
!define PLANTUML_FORMAT svg
!theme _none_
skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100
package "Space Beaver 系統架構" {
actor "外部使用者" as user
component "訊息入口" as gateway {
[SMTP 伺服器]
[簡訊接收器]
[Web API]
}
component "訊息處理層" as processing {
[使用者 Actor Pool]
[路由邏輯]
[協定轉換]
}
component "訊息出口" as outlet {
[郵件傳送客戶端]
[簡訊傳送客戶端]
[衛星通訊客戶端]
}
database "使用者資料" as userdb
database "訊息佇列" as queue
}
cloud "外部服務" as external {
[Twilio API]
[衛星服務 API]
[SMTP 伺服器]
}
user --> gateway : 發送訊息
gateway --> processing : 訊息轉發
processing --> userdb : 查詢使用者資訊
processing --> queue : 暫存訊息
processing --> outlet : 傳送訊息
outlet --> external : API 呼叫
@enduml設計原則強調無狀態與有狀態元件的適當分離。郵件傳送等無狀態操作使用遠端函式實作,能根據負載自動擴展。SMTP 伺服器等有狀態服務使用 Actor 實作,維持長期連線與會話狀態。這種混合設計讓系統能在保持簡潔性的同時,充分利用 Ray 的各種能力。
出站郵件客戶端實作
出站郵件客戶端是系統中典型的無狀態元件,每次郵件傳送都建立新的 SMTP 連線,完成傳送後釋放連線。這種模式不需要維護連線池或會話狀態,實作簡單且容易擴展。使用遠端函式而非 Actor 實作這個元件,讓 Ray 能根據待傳送郵件的數量動態調整執行的任務數量。
import ray
from email.mime.multipart import MIMEMultipart
from email.mime.text import MIMEText
import smtplib
import logging
from dataclasses import dataclass
@dataclass
class MailSettings:
mail_server: str
mail_port: int
mail_username: str = None
mail_password: str = None
use_tls: bool = True
@ray.remote(num_cpus=0.1, retry_exceptions=True, max_retries=3)
def send_email(settings: MailSettings, msg_from: str, msg_to: str,
subject: str, body: str):
message = MIMEMultipart("alternative")
message["From"] = msg_from
message["To"] = msg_to
message["Subject"] = subject
part = MIMEText(body, "plain", "utf-8")
message.attach(part)
try:
with smtplib.SMTP(settings.mail_server, port=settings.mail_port,
timeout=30) as smtp:
if settings.use_tls:
smtp.starttls()
if settings.mail_username:
smtp.login(settings.mail_username, settings.mail_password)
logging.info(f"Sending email from {msg_from} to {msg_to}")
result = smtp.send_message(message)
if result:
logging.warning(f"Email partially failed: {result}")
return {"status": "partial", "failed": result}
return {"status": "success"}
except smtplib.SMTPException as e:
logging.error(f"SMTP error: {e}")
raise
except Exception as e:
logging.error(f"Unexpected error: {e}")
raise
settings = MailSettings(
mail_server="smtp.example.com",
mail_port=587,
mail_username="user@example.com",
mail_password="password"
)
future = send_email.remote(
settings,
"sender@example.com",
"recipient@example.com",
"Test Subject",
"Test Body"
)
result = ray.get(future)
這個實作展示幾個重要的設計考量。資源配置透過 num_cpus=0.1 參數指定,因為郵件傳送主要是 I/O 密集而非 CPU 密集的任務,不需要佔用完整的 CPU 核心。重試機制透過 retry_exceptions=True 與 max_retries=3 啟用,自動處理暫時性的網路錯誤或伺服器問題。
錯誤處理區分不同類型的例外,SMTP 相關的錯誤與其他未預期的錯誤分別處理。詳細的日誌記錄協助問題追蹤,記錄郵件傳送的關鍵資訊與任何錯誤。回傳值的結構化設計讓呼叫者能理解郵件傳送的結果,包含成功、部分失敗、完全失敗等不同情況。
懶惰命名 Actor 池設計模式
Actor 池是分散式系統中常見的資源管理模式,透過維護一組預先建立的 Actor,避免每次請求都建立新 Actor 的開銷。然而傳統的 Actor 池設計存在一些限制,如需要預先決定池的大小,無法根據實際負載動態調整。懶惰命名 Actor 池結合命名 Actor 與懶惰初始化的概念,提供更靈活的資源管理策略。
懶惰初始化的設計理念
懶惰初始化的核心思想是按需建立資源,而非預先建立所有可能需要的資源。這種策略在資源需求不確定或隨時間變化的場景特別有價值。對於 Actor 池,懶惰初始化意味著 Actor 可以在不同時間點建立,池的實際大小會隨著系統運作逐漸達到預設的上限。
命名 Actor 提供持久性與可發現性。透過為 Actor 指定名稱,可以在叢集中任何地方透過名稱取得 Actor 的參考。這個特性讓 Actor 能在系統重啟或節點故障後被重新發現,也讓不同的元件能協調使用相同的 Actor 池。命名 Actor 的生命週期獨立於建立它的程式,即使建立者結束,Actor 仍然繼續存在。
結合這兩個概念的懶惰命名 Actor 池,能根據實際需求逐步建立 Actor,同時提供命名帶來的可靠性與協調能力。這種設計特別適合動態擴展的場景,如自動擴展的處理服務、按需載入的快取層、動態調整的工作者池等。
import ray
import time
from typing import List, Optional
from itertools import chain
class LazyNamedActorPool:
def __init__(self, actor_class, name_prefix: str, max_size: int,
min_size: int = 1, actor_kwargs: dict = None):
self._actor_class = actor_class
self._name_prefix = name_prefix
self._max_size = max_size
self._min_size = min_size
self._actor_kwargs = actor_kwargs or {}
self._actors: List[ray.actor.ActorHandle] = []
self._pool: Optional[ray.util.ActorPool] = None
def _get_actor_name(self, index: int) -> str:
return f"{self._name_prefix}_{index}"
def _try_get_actor(self, index: int) -> Optional[ray.actor.ActorHandle]:
actor_name = self._get_actor_name(index)
try:
return ray.get_actor(actor_name)
except ValueError:
return None
def _discover_actors(self) -> List[ray.actor.ActorHandle]:
discovered = []
for i in range(self._max_size):
actor = self._try_get_actor(i)
if actor is not None:
discovered.append(actor)
return discovered
def _ensure_min_actors(self, timeout: float = 60) -> List[ray.actor.ActorHandle]:
start_time = time.time()
actors = self._discover_actors()
while len(actors) < self._min_size:
if time.time() - start_time > timeout:
raise TimeoutError(
f"Timeout waiting for minimum {self._min_size} actors. "
f"Found {len(actors)} actors."
)
time.sleep(2)
actors = self._discover_actors()
return actors
def get_pool(self) -> ray.util.ActorPool:
new_actors = self._discover_actors()
new_actors = self._ensure_min_actors()
if len(new_actors) > len(self._actors):
self._actors = new_actors
self._pool = ray.util.ActorPool(new_actors)
return self._pool
def create_actor(self, index: int) -> ray.actor.ActorHandle:
actor_name = self._get_actor_name(index)
actor = self._actor_class.options(
name=actor_name,
lifetime="detached",
**self._actor_kwargs
).remote()
return actor
這個實作提供完整的懶惰命名 Actor 池功能。建構時指定 Actor 類別、名稱前綴、池的大小限制等參數。_discover_actors 方法掃描所有可能的 Actor 名稱,嘗試取得已存在的 Actor。_ensure_min_actors 方法確保池中至少有最小數量的 Actor,透過輪詢等待直到滿足條件或逾時。
get_pool 方法是主要的對外介面,回傳可用的 Actor 池。每次呼叫時重新掃描 Actor,如果發現新的 Actor 就更新內部快取。這種設計讓池能自動適應 Actor 的動態建立,無論 Actor 是由這個池管理類別建立,或是由外部程序建立。
使用場景與最佳實務
懶惰命名 Actor 池適合多種應用場景。訊息處理服務可以使用這個模式管理工作者 Actor,系統啟動時只建立最小數量的工作者,隨著負載增加逐步建立更多工作者。快取服務可以使用這個模式管理快取分片,每個分片是一個命名 Actor,按需建立與發現。
使用這個模式時需要注意幾個要點。Actor 的建立與發現需要時間,不適合延遲敏感的場景。最小 Actor 數量的設定應該基於系統的基礎負載,確保系統隨時能處理預期的請求量。最大 Actor 數量則基於資源限制與效能考量,避免建立過多 Actor 導致資源耗盡。
監控與警報機制很重要,追蹤實際運行的 Actor 數量與請求的處理情況。若發現 Actor 數量長期低於最小值,可能表示 Actor 建立機制有問題。若發現請求處理緩慢但 Actor 數量未達上限,可能需要調整擴展策略。定期檢視這些指標,根據實際運作情況調整參數設定。
優雅關閉機制實作
優雅關閉是系統可靠性的重要保證,確保系統在停機維護、版本升級、故障恢復等情況下,能正確處理進行中的請求,避免資料遺失或不一致。在分散式系統中,優雅關閉特別重要也特別困難,因為需要協調多個節點的狀態,確保所有元件都完成清理工作。
優雅關閉的設計原則
優雅關閉的核心原則是停止接受新請求,完成處理中的請求,釋放佔用的資源。這個過程需要分階段進行,每個階段有明確的目標與逾時限制。第一階段是停止接受新請求,將服務從負載平衡器中移除,或是停止監聽網路埠。這個階段應該快速完成,通常只需要幾秒鐘。
第二階段是等待進行中的請求完成,這個階段的時間取決於請求的處理時間。需要設定合理的逾時限制,避免某個長時間執行的請求阻礙整個關閉流程。對於超過逾時的請求,可以強制中斷或是記錄警告,視應用的特性決定策略。
第三階段是資源清理,關閉資料庫連線、釋放檔案控制代碼、持久化暫存資料等。這個階段同樣需要逾時限制,確保關閉流程不會無限期等待。完成所有階段後,程序才真正退出,作業系統回收資源。
import asyncio
import signal
import logging
from typing import Optional
from datetime import datetime, timedelta
class GracefulShutdownMixin:
def __init__(self):
self._shutdown_event = asyncio.Event()
self._shutdown_timeout = 120
self._active_requests = 0
self._is_accepting_requests = True
signal.signal(signal.SIGTERM, self._handle_shutdown_signal)
signal.signal(signal.SIGINT, self._handle_shutdown_signal)
def _handle_shutdown_signal(self, signum, frame):
logging.info(f"Received shutdown signal: {signum}")
asyncio.create_task(self.prepare_for_shutdown())
async def prepare_for_shutdown(self):
logging.info("Starting graceful shutdown")
self._is_accepting_requests = False
await self._remove_from_load_balancer()
await asyncio.sleep(10)
deadline = datetime.now() + timedelta(seconds=self._shutdown_timeout)
while self._active_requests > 0:
if datetime.now() > deadline:
logging.warning(
f"Shutdown timeout reached with {self._active_requests} "
f"active requests remaining"
)
break
logging.info(f"Waiting for {self._active_requests} requests to complete")
await asyncio.sleep(5)
await self._cleanup_resources()
self._shutdown_event.set()
logging.info("Graceful shutdown completed")
async def _remove_from_load_balancer(self):
pass
async def _cleanup_resources(self):
pass
def _track_request(self):
return RequestContext(self)
class RequestContext:
def __init__(self, handler):
self._handler = handler
def __enter__(self):
if not self._handler._is_accepting_requests:
raise RuntimeError("Service is shutting down")
self._handler._active_requests += 1
return self
def __exit__(self, exc_type, exc_val, exc_tb):
self._handler._active_requests -= 1
這個混入類別提供完整的優雅關閉功能。建構時註冊訊號處理器,當收到 SIGTERM 或 SIGINT 訊號時啟動關閉流程。prepare_for_shutdown 方法實作分階段的關閉邏輯,首先停止接受新請求,然後等待進行中的請求,最後清理資源。
請求追蹤透過上下文管理器實作,每個請求處理時使用 with self._track_request() 包裹,自動增減活躍請求計數。這個機制確保關閉流程能準確知道還有多少請求在處理中。若在關閉過程中有新請求進入,會立即拒絕避免延長關閉時間。
Kubernetes 環境的優雅關閉
在 Kubernetes 環境中,優雅關閉需要與平台的生命週期管理整合。Kubernetes 透過標籤與 Service 物件實作服務發現與負載平衡,Pod 關閉時需要從 Service 的端點清單中移除,避免新請求被路由到即將關閉的 Pod。
標籤更新是實作這個機制的關鍵。透過移除特定標籤,Pod 不再匹配 Service 的選擇器,Kubernetes 會自動從端點清單中移除這個 Pod。標籤的更新透過 Kubernetes API 進行,需要適當的權限設定。在 Pod 中執行的應用程式可以透過 ServiceAccount 取得必要的權限。
import os
import requests
import logging
from typing import Literal
class KubernetesLabelManager:
def __init__(self):
self._kube_host = os.getenv("KUBERNETES_SERVICE_HOST")
self._kube_port = os.getenv("KUBERNETES_SERVICE_PORT_HTTPS", "443")
self._namespace = os.getenv("POD_NAMESPACE")
self._pod_name = os.getenv("POD_NAME")
self._token_path = "/var/run/secrets/kubernetes.io/serviceaccount/token"
self._ca_cert_path = "/var/run/secrets/kubernetes.io/serviceaccount/ca.crt"
if os.path.exists(self._token_path):
with open(self._token_path) as f:
self._token = f.read()
else:
self._token = None
logging.warning("ServiceAccount token not found")
def update_label(self, label_key: str, operation: Literal["add", "remove"],
label_value: str = "true"):
if not all([self._kube_host, self._namespace, self._pod_name, self._token]):
logging.error("Missing Kubernetes environment information")
return False
url = (
f"https://{self._kube_host}:{self._kube_port}/api/v1/"
f"namespaces/{self._namespace}/pods/{self._pod_name}"
)
patch = [{
"op": operation,
"path": f"/metadata/labels/{label_key}",
"value": label_value if operation == "add" else None
}]
if operation == "remove":
del patch[0]["value"]
headers = {
"Authorization": f"Bearer {self._token}",
"Content-Type": "application/json-patch+json"
}
try:
response = requests.patch(
url,
json=patch,
headers=headers,
verify=self._ca_cert_path,
timeout=10
)
if response.status_code == 200:
logging.info(f"Successfully updated label {label_key}")
return True
else:
logging.error(
f"Label update failed: {response.status_code} - {response.text}"
)
return False
except Exception as e:
logging.error(f"Exception during label update: {e}")
return False
這個類別封裝 Kubernetes 標籤管理功能。建構時從環境變數讀取必要的資訊,包含 API 伺服器位址、Pod 命名空間與名稱。ServiceAccount 的令牌從檔案系統讀取,這個令牌由 Kubernetes 自動掛載到 Pod 中。
update_label 方法實作標籤的新增或移除。使用 JSON Patch 格式構建更新請求,這是 Kubernetes API 支援的標準格式。請求包含認證令牌與適當的標頭,透過 HTTPS 與 API 伺服器通訊。CA 憑證用於驗證 API 伺服器的身份,確保通訊安全。
錯誤處理涵蓋多種情況,包含環境資訊缺失、網路錯誤、認證失敗、權限不足等。詳細的日誌記錄協助問題診斷。方法回傳布林值表示操作成功與否,呼叫者可以根據回傳值決定後續行動。
結語
Ray 分散式計算框架為企業提供強大且靈活的分散式計算能力,從簡單的並行任務到複雜的有狀態服務都能優雅實作。然而成功導入 Ray 需要深入理解其程式設計模型,仔細設計系統架構,妥善處理容錯與資源管理等各種細節。本文透過 Space Beaver 專案的真實案例,展示如何設計可靠的分散式訊息處理系統。
容器化整合讓 Ray 能無縫融入現代雲端原生架構,懶惰命名 Actor 池提供靈活的資源管理策略,優雅關閉機制確保系統的可靠性。這些設計模式與最佳實務都源自真實的生產環境經驗,經過實戰驗證。希望這些經驗分享能協助更多團隊成功導入 Ray,建立高效可靠的分散式應用。
隨著 Ray 生態系統的持續發展,更多企業級功能如多租戶隔離、細粒度的資源管理、完整的可觀測性支援會逐步成熟。同時社群的活躍發展也會帶來更多最佳實務與應用案例。持續關注 Ray 的發展,結合自身業務特性進行創新應用,將能充分發揮這個強大框架的價值。
