《可不可以不變老?》:為了瞭解老化如何發生,我們必須進入次細胞的奈米世界

《可不可以不變老?》:為了瞭解老化如何發生,我們必須進入次細胞的奈米世界
Photo Credit: Shutterstock / 達志影像

我們想讓你知道的是

既然知道了生命運作的方式,而且擁有從遺傳和表觀遺傳上改變生命的工具,便能在古老智慧的基礎上更上一層樓。要延長人類的健康壽命,最簡單的辦法就是利用目前已知有助於減緩人類老化的各種藥物。

文:辛克萊(David A. Sinclair)、拉普蘭提(Matthew D. LaPlante)

不得不吞的良藥

延長人類生命的夢想並非始於二十一世紀初,就像人類飛行的夢想也不是二十世紀初才開始。科學並非開端,故事才是一切的濫觴。

從蘇美國王吉爾伽美什(Gilgamesh)開始,據說他統治烏魯克(Uruk)王國長達一百二十六年,到希伯來聖經裡的族長麥修撒拉(Methuselah),傳聞他活到九百六十九歲高壽,這些人類的神聖故事都證實了我們對長壽的深切渴慕。然而,除了神話和寓言以外,我們並無科學證明任何人可成功延壽超過一世紀。

假使無法深入瞭解生命的運作方式,延長壽命可說是希望渺茫。我和同事相信我們終於掌握了此方面的知識,儘管仍不甚完美。

1665年,「英國的達文西」,也就是虎克(Robert Hooke), 出版《微物圖誌》(Micrographia),書中記錄他發現軟木樹皮裡的細胞。虎克的發現帶領人類進入了生物學的新時代。

但是,幾世紀過去了,細胞在分子層次上究竟如何運作,我們依然毫無線索。這方面的知識,得等到顯微鏡、化學、物理學、遺傳學、奈米工程,和演算能力等科學與技術皆大幅開展之時,才油然而生。

為了瞭解老化如何發生,我們必須往下進入次細胞的奈米世界,向下前往細胞,穿過外膜,進入細胞核。從那裡,我們繼續向下探索胺基酸和DNA,從這個尺度來看,人為何無法長生不死便一目瞭然了。

在我們從奈米的規模瞭解生命之前,即便人為何活著都是一個謎。就算是傑出的奧地利理論物理學家、量子物理的先驅薛丁格(Erwin Schrödinger)(沒錯,就是他提出了那隻既死又活的貓有關的想像實驗),在他試圖瞭解生命的運作時,也被弄得困惑不堪。1944年,他一籌莫展地宣稱生命物質「可能涉及迄今未知的『其他物理定律』」。這是他在當時所能得出最好的結論。

薛丁格1944年出版了《生命是什麼?》(What Is Life?),然而,接下來數十年裡,世界快速發展。時至今日,對於他的提問,我們即便尚未完整解答,但也已相當接近了。

解釋生命的運作並不需要新的物理定律。從奈米規模來看,生命的運作僅是一連串有序的化學反應,濃縮與組合通常不會組合的原子,或分解原本不會分解的分子。生命運用酵素這種蛋白質做為電玩小精靈(Pac-Man)來完成這些活動,而酵素則是由不同胺基酸結合形成環狀及層疊片狀的肽鏈所組成。

酵素透過偶然的分子運動使生命得以運作。你活著的每一秒,體內數兆個細胞中,每個細胞裡就有成千上萬個葡萄糖分子被葡萄糖激酶(glucokinase)捕捉,此種酵素可將葡萄糖分子結合至磷酸根上,進一步加以分解,藉此產生能量。而產生的能量多半為核糖體所用,核糖體是RNA和蛋白質形成的複合物,其主要工作就是讓胺基酸依特定的排列順序結合,生成新鮮的蛋白質。

這種說明是不是讓你有點昏昏欲睡?你並非唯一如此的人,而且這也不是你的問題。我們科學家身為老師,把酷炫的科學變得枯燥乏味,順勢幫了社會一個大倒忙。教科書和科學論文把生物學描繪成靜態、平面的二維世界,化學物質被畫成棒狀,化學反應途徑以箭頭表示,DNA是線條,基因是矩形,酵素是橢圓形,細胞被繪製得比實際大數千倍。

然而,一旦瞭解細胞實際運作的原理,便知道它們是世上最神奇的事物。在教室裡傳達此種奇蹟的難度在於,細胞存在於四維世界,且以人類無法感知或難以想像的速度與規模四處移動。秒和毫米之於人類,是時間和空間的極小單位;但是,對於直徑約十奈米、每千萬億分之一秒震動一次的酵素而言,一毫米相當於一座大陸,一秒等於一年以上。

混亂的必要

以觸酶(catalase)為例。觸酶是一種普遍存在、大小一般的酵素,每秒可分解超過十萬個過氧化氫分子。大腸桿菌內可容納一百萬個觸酶,而一百萬個大腸桿菌又相當於針頭大小。這些數字不只難以想像,簡直難以置信。

每個細胞裡,共有七萬五千種像觸酶一樣的酵素,全都放在一個微鹼的細胞液海裡摩肩接踵。以奈米尺度來看,細胞液海為黏膠狀,分子間的活動可說比五級颶風更劇烈,分子以相當於每小時約一千六百公里的速度彼此碰撞。其中只有千分之一的碰撞可以產生酵素反應,在奈米尺度下,這樣的反應每秒也可以發生數千次,足以維持生命。

這似乎聽來混亂不堪,情況也確實如此,但我們需要這種混亂,秩序才能浮現。少了這種混亂,必須互動才能維持生命的分子無法找到彼此,發揮作用。人類的去乙醯酶酵素SIRT1便是最佳範例。

SIRT1上精準的震動槽會緊緊結合NAD分子與它想從其剝除乙醯基的蛋白質,如組蛋白或FOXO3,此二個被捕捉在一起的分子會立刻發生反應,之後SIRT1將去乙醯基的蛋白釋放,同時放出維生素B3和乙醯化腺嘌呤核糖(acetylated adenine ribose),這些會再被回收成為製造NAD的原科。

更重要的是,現在標靶蛋白已經移除了牽制它的乙醯基標記,組蛋白因而可以更密實地包裹DNA,使基因沉寂;而FOXO3在脫離束縛之後,可轉而啟動保護型基因的防禦機制。


猜你喜歡


挖掘雲端開放架構優勢!Amazon EKS高可用性叢集快速部署容器

挖掘雲端開放架構優勢!Amazon EKS高可用性叢集快速部署容器

我們想讓你知道的是

企業如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署,減輕人力負擔,提升專案服務運作效率?

所謂現代化智慧 IT,所有工程師最希望的境界,莫過於只要輕鬆點幾下設定,系統就會自動跑起來,管理者再也不用隨時待命在機台旁邊,從此工作悠哉又快樂!儘管這樣情境還沒到來,但隨著敏捷式開發的流行,除了 DevOps 人員,有越來越多開發者將 CI/CD 概念融入到工作流程當中,例如從 build code、執行 unit test、到部署應用程式。

透過 AWS 增加雲端技能 在組織發揮影響力

上述種種反覆步驟自動化執行,也就能提昇服務品質、主動通知開發人員以減輕人力負擔,讓專案服務能持續運作。

其中,GitLab 是執行 CI/CD 常用的工具之一,也是開發者使用程式碼儲存庫的地方。為了讓 GitLab Runner 在雲端快速實踐 CI/CD,《AWS 開發者系列》透過影片分享,如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署。

以下節錄工作坊影音內容,幫助開發者快速理解如何運用 Amazon EKS 的高可用性且安全的叢集,將修補、部署節點、更新等關鍵任務,全部做到自動化設定。同時影片也會示範 Amazon EKS 搭配 GitLab 如何展開自動部署,幫助工程團隊實踐 CI/CD 價值。

Amazon EKS 對容器管理輕鬆簡單、維運省時省力

容器化服務越來越興盛,當容器(Container)越來越多,在複雜的微服務(Microservice)系統環境之下,運維團隊的管理成本可能相對會增加不少,為了有效調度容器部署, 導入Kubernetes 無疑是近年企業熱門的話題之一。

建構 Kubernetes Cluster 流主要可區分兩大塊,一是安排容器調度的Control Plane、另一則是容器運行時需要用到的 Worker Node。

Control Plane 裡面涵蓋有儲存狀態的 ETCD、CoController manager 、Scheduler 的調度管理、甚至是操作時進行互動的 APIServer,若是自己創建 的 Kubernetes Cluster ,需要自己安裝這些元件,後續仍需要對 Control Plane 進行相關管理、維護、升級工作。為了減少上述 Components 的繁複維護,在透過 AWS EKS 代管的 Kubernete Control Plane 部可以獲得以下三大好處。

Amazon EKS 一鍵式部署,展現三大優勢

第一,Amazon EKS代管的 Control Plane實踐了跨AZ的高可用部署,使用者不需要擔心單一節點故障的風險。

第二,Amazon EKS 支持至少四個 Kubernetes版本,持續跟進每季 CNCF 的發佈,同時 EKS 也完全符合上游 CNCF 規範。

第三,部署 Amazon EKS 之後,可直接使用 AWS 平台上現成的服務工具,在安全性管理、網路設定方面,可以做到無縫整合。

最後 AWS 台灣解決方案架構師也提到,若想在容器環境進行 CI/CD 及應用程式的管理,可以進一步透過 IaC 整合部署 Amazon EKS 叢集,透過使用 Console、把 EKS 變成 Cloudformation 的模板、使用 AWS 所開發出來的 eksctl.io、或指令是採用 AWS CDK 可以讓開發者用自身熟悉的語言,在 AWS 平台整合 CI/CD 工具進行維運及部署 EKS。

打造第一個在 AWS 上的應用程式

了解 Amazon EKS 整合 GitLab ,獲得三面向價值

對開發者而言,想把 Amazon EKS 整合到 CI/CD 工具之一的 GitLab 平台上,可以看到那些實際的優勢?

在 DevOps 開發者示範工作坊當中,GitLab 資深解決方案架構師指出,GitLab 使用到 Kubernetes 技術,主要有三種搭配方法,包含 GitLab Server、GitLab Runner、以及創建 Deployment Environment。

本次示範教學會主要聚焦在 GitLab Runner 如何採取 Auto-scaled 方式進行 Build、Test、Package Apps;以及在 Deployment Environment 運用 Kubernetes 技術,做到 Auto Deploy、Review App。

正因為 Amazon EKS 能夠在 DevOps 過程提供所需要的彈性計算資源,幫助開發者在 GitLab 平台上面獲得以下三個層次的優勢:

  • 在 GitLab 內建的部署工作流程當中,自動生成整套 CI/CD 最佳實踐腳本。
  • Review App 過程,從 Merge Request 中可直接訪問應用程式 /App 的 UI 介面,並且根據 Git branch 名稱、專案名稱,自動生成 Review App 的 URL,以及在 Merge 前的最後防線進行 Approval 檢查。
  • 加速 CI/CD 流水線,GitLab Runner 運行時候還可藉由 Amazon EKS Cluster 進行 Auto-scaled 的支援。

Amazon EKS 整合 GitLab ,需要兩大流程

影片最後,GitLab 資深解決方案架構師示範如何把 Amazon EKS 整合至 GitLab 執行 Auto Deploy,主要可分為兩大區塊流程,第一部分聚焦在 Amazon EKS cluster 的設置,第二部分則執行 Auto Deploy 設置。

第一塊可拆分為四個階段,首先教學怎麼創建 EC2 節點的 EKS cluster,第二階段示範把 EKS Cluster 連接到開發者的 GitLab Instance、Group 或 Project,下一步則使用 Cluster Management Project Template 創建一個 Cluster Management Project,以及最後一階段透過 Cluster Management Project 自帶的 Helm Chart,安裝在 Cluster 所需要的內建 App。

第二塊執行 Auto Deploy 設置,針對需要部署的 App 創建一個 GitLab Project,接著再把 gitlab-ci.yml 添加到 Project,並從 Web IDE 選擇及導入 Auto Deploy 的 CI 模版,讓 GitLab 自動生成最佳實踐的整套流水線。

幫助開發者更了解 Amazon EKS 整合 GitLab 的 QA 系列

Q:使用 Amazon EKS 之後,如何更有效率或優化資源去配置 Worker Node 的機器數量,以及如何有效空管開發維運的成本?

A:Kubernetes 除了本身有 HPA(Horizontal Pod Autoscaling)可根據使用程度自動調整資源流量,另外也能延伸使用 AWS Auto Scaling 方案,針對可擴展資源去設定自動擴展管理。另外在成本管控,雖然 Amazon EKS 會收取額外管理費用,但可透過 AWS 平台的 Calculato r計算每個 EKS 的價格,你會發現自動化部署及管理的費用,相對工程師人力的成本更加便宜。

Q:越來越多客戶考慮把現有 Application 變成容器部署,大多是爲了加快部署的效率,那麼變成容器模式之後,對 CI/CD 的工作流程有什麽影響嗎?

A:運用容器技術最直接的效果,可以讓應用程式的環境更一致化,例如 testing 環節、stage production,讓容器避開一些差異問題。至於 CD 部分要 delivery 一些 usage 不太一樣的時候,容器會幫忙做配置,所以 CI/CD 對容器的效益是相輔相成的。

Q: 客戶在開發流程漸漸會把 Infrastructure 變成代碼或文檔,是不是可以把程式碼跟現有的應用程式的 CI/CD 流水線整合在一起,達到一套完整的 CI/CD 部署流程?

A:觀察目前市場作法,主要分成兩個階段去做整體部署。如果規模比較小的團隊,會把 Infrastructure 代碼跟 App 代碼分開,在管理上會比較靈活;如果企業規模比較大,會有另外一個 Infrastructure 團隊來控制部署事情,這種情况之下,APP 的項目會生成一個 APP package,主要做到 delivery 這個階段爲止。而 Infrastructure 的項目會指定把需要版本的文檔,部署到他們的 Kubernetes Cluster。

填寫表單 找到適合的快速上雲服務與工具!


猜你喜歡