死亡門檻:是什麼決定了老鼠只能活3年,而鴿子卻可以活到30年?

死亡門檻:是什麼決定了老鼠只能活3年,而鴿子卻可以活到30年?
Photo Credit: Laura Suarez @ Flickr CC By SA 2.0

我們想讓你知道的是

假設真有所謂的死亡門檻,跨過這道門檻之後,細胞(連帶著整個生物個體)就會死於細胞凋亡。在門檻之下,細胞跟個體都可以存活。顯然,不同物種之間的閾值,一定不一樣高。

文:尼克・連恩(Nick Lane)

分布在不同地理區域的人,線粒體DNA的形式也不太一樣,這種差異性顯然並非隨機,而這也暗示我們,特殊環境對線粒體DNA,確實有篩選的效果,但是,這也就僅止於暗示而已。但是如同前面提過,鳥類的線粒體DNA很少變異,因為DNA序列已經是最適合飛行的了,大部分後來出現的突變,都會被天擇消滅;這也就是說,因為線粒體DNA的變異性很小,也就沒有留給天擇什麼機會,去篩選出碰巧適合寒帶氣候、或是適合多油飲食的變種線粒體。

從這個角度來看,鳥類必須經常遷移,而非停在一處忍受季節變化,就變成一件很有趣的事。是否是因為牠們的線粒體,比較適合應付遷徙時的消耗,而比較不適合應付留下來所要面對的嚴酷環境呢?反過來說,大鼠的線粒體差異就很大,根據第一原理的預測,這可以讓牠們有較多本錢,適應力就好很多。事實果真如此嗎?老實說,我不知道。但是老鼠確實是適應力極佳的小動物,這點無需辯駁。

變異的代價

但是當然,追求線粒體的變異性,也要付出代價,這代價就是疾病。就某種程度上,這缺點可以藉著選擇生殖細胞來避免,也就是帶有突變線粒體的卵子,會在成熟以前就被剔除。有一些證據顯示,這樣的篩選機制確實存在:在大鼠跟小鼠體內,嚴重突變的線粒體在經過幾代繁殖後,就會被剔除,而比較不嚴重的突變則會被留下。不過回頭想想這個結果,要數代後才會被剔除呢!這個天擇作用可真弱。如果你生下來,就受盡嚴重的線粒體疾病之苦,那麼當想到你的孫子(如果你夠幸運能有一個的話),可能不會有一樣的疾病,是不是感到很安慰呢?

即使天擇確實可以作用在生殖細胞上,去剔除突變的線粒體,但這並不保證也會剔除線粒體疾病。尚未成熟的卵細胞,還沒有完整的細胞核基因體,不只是因為它們在減數分裂半途就會停下來,被關在無人知曉的角落好多年;同時也是因為此時父系的基因尚未加入戰局。對核線粒體互相適應的篩選,只有當卵細胞受精之後,當一顆全新、擁有獨一無二細胞核基因體的受精卵誕生後,才算開始。

雜種衰退,並不是因為線粒體突變的關係,雜種衰退來自線粒體跟細胞核基因體的不相容性,而這兩套基因體,當各自處於另外一種情境下時,搞不好是完美的。我們也介紹過,對核線粒體不相容性的篩選變嚴的話,必定也會增加不孕的機率。如果我們不想變成不孕,那就必須付出一些代價,也就是有可能生病。而要在繁殖與疾病之間取捨,也是複雜生物因為需要兩套基因體,而出現完全可預測的後果。

假設的死亡門檻

假設真有所謂的死亡門檻(見圖)。跨過這道門檻之後,細胞(連帶著整個生物個體)就會死於細胞凋亡。在門檻之下,細胞跟個體都可以存活。顯然,不同物種之間的閾值,一定不一樣高。對於蝙蝠、鳥類以及其他對氧氣需求極大的生物來說,這門檻必定很低:只要線粒體跟細胞核的基因體稍有不合,線粒體稍微運作不良,又引起輕微的自由基外漏,就會放出細胞凋亡的訊號,然後終止胚胎發育。對大鼠、樹懶以及其他「懶惰的」動物而言,因為對氧氣需求比較低,等於把門檻提高:輕微的自由基外漏沒什麼關係,線粒體運作不太順利,也可以接受,胚胎就可以發育。

對這兩種選擇而言,都有各自的利弊。死亡門檻低,生物有氧運動能力高,不容易有線粒體疾病,但是代價就是生育力低以及適應力低。生育力、適應力、有氧運動力、疾病,這些都是關鍵字彙。沒有什麼比這些更適合作為天擇的種子了。我再強調一次,所有這些利弊取捨,都是因為需要有兩套基因體,而不可避免的結果。

死亡的門檻

圖說:死亡的門檻

自由基分子外漏,到什麼程度才能引起細胞死亡(細胞凋亡)?在不同物種之間結果應該不一樣,而這要看他們的有氧能力而定。對於有氧需求極高的生物,需要線粒體與細胞核的基因體完美匹配。如果相容性不佳,自由基從運作不良的呼吸鏈中外漏的速率,就會非常高。如果它們對相容性的需求很高,那也會對自由基外漏很敏感,即使只漏出一點點,也會放出適應不良的警報,就會開啟細胞凋亡的開關(低門檻)。

相反的,對有氧需求不大的細胞來講,自殺並沒有什麼好處。這樣的生物就可以忍受較多自由基外漏,而不會啟動細胞凋亡程序(高門檻)。對於死亡閾值高或低的預測,列在圖的兩側。我們預測鴿子有很低的門檻,大鼠則有很高的門檻。這兩種動物的體型跟基礎代謝率都差不多,但是鴿子自由基的外漏速率低多了。這些預測到底有多真?我們並不知道,不過讓人驚訝的是,老鼠只能活三四年,而鴿子卻可以活到三十年。

我純然稱它為一個「假設的死亡門檻」,它確實只是個假設。這道門檻真的存在嗎?它很重要嗎?以人類來說,大約有百分之四十的懷孕,最後會以「早期潛藏性流產」告終。這裡所謂的早期,是非常非常早,大概發生在懷孕前幾周之內,通常都還沒有出現任何懷孕症狀,妳甚至根本不知道妳懷孕了。而「潛藏性」的意思,就是說藏起來,所以也沒有臨床症狀。通常我們都不知道為什麼會流產,它也不是來自一些常見的原因,像是染色體分離失敗,結果造成「三染色體」(trisomy)之類的疾病。

那它有可能肇因於生物能量上的問題嗎?這很難證明。不過,今天科學家已經有了快速掃描基因體的能力,我們倒是有點希望可以知道。我們對於不孕症的焦慮,讓科學家甚至去進行一些不太健康的實驗,來研究可以促進胚胎發育的因子。有些嚇人的實驗,像是笨拙地把ATP(三磷酸腺苷)送入虛弱的胚胎中,而這樣做竟然可以延長胚胎的壽命!所以很明顯地,生物能量確實很重要。

同理,或許這些流產,是為了「追求最佳」所造成的結果;或許這些胚胎,有線粒體核不相容的毛病,所以進入細胞凋亡程序了。對於演化,沒有什麼道德批評可言。我只能說,我不會忘記自己也曾經為此苦惱不已(幸好現在都過去了)。而我,跟大部分人一樣,都想知道為何如此。我相信,大部分的早期潛藏性流產,應該都是源於線粒體核不相容。

鴿子跟大鼠

此外,還有另外一個理由,支持死亡門檻的存在,以及它的重要性。高死亡門檻,會帶來一個間接的終極代價,那就是老得快,以及必需忍受各種老化相關疾病。這個論點可能會引起某些人的不快。高死亡門檻,代表生物可以忍受比較多的自由基外洩,而不會引起細胞凋亡。這意思也就是說,像大鼠這種低有氧能力的動物,會有比較多的自由基外漏;相反的,像鴿子這種高有氧能力的動物,則會有比較少的自由基外漏。


猜你喜歡


挖掘雲端開放架構優勢!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。

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


猜你喜歡