PaaS 平台重構原因及架構
一、背景
目前在用的PaaS平台是之前購買的一個商業産品，但沒有源碼，運維期也早就結束了，是以在後期使用過程中會遇到一些各種各樣的問題，對于使用、運維都造成一定的困擾。
老PaaS的架構及基本功能如下：
二、重構
為什麼選擇重構PaaS平台而不是全部遷移kubernates叢集？
kubernates叢集的确提供了很多優秀的特性，比如：RC、滾動更新或復原、資源監控和日志記錄、負載均衡等等。
但在目前我們這邊的環境來看，遷移kubernates叢集有如下幾個問題：
- 無法無感覺遷移，即遷移到kubernates叢集的過程中及遷移到kubernates叢集後，不增加使用者的使用、學習成本，但應用引入kubernates叢集之後，很難保證這一點。因為我們這邊的使用者大多是我們公司的供應商，供應商其實不太關心，你平台所提供的各種新特性、功能，更不想因為這些新特性、功能增加他們的使用、學習成本。
- 我們這邊很多項目本身是有硬負載的，比如F5，是以kubernates提供的負載均衡功能，也就顯的不那麼重要。
- 日志部分，我們已經打通各個平台的日志、監控，不再需其他的元件。具體參見：《基于日志的收集、檢索、監控、告警平台》
- 滾動更新或復原，老PaaS平台木有，重構後新版中準備加入（二期）。
- RC類似功能，目前不打算支援。
1、架構及用到元件梳理
2、新PaaS功能點梳理
三、遷移
通過無縫遷移，在使用者無感覺的情況下實作遷移。
為什麼要做到無感覺遷移？
老PaaS中目前的項目數量是：193個，應用數量是：673個
總執行個體數：1485，其中生産環境的執行個體數：894
如果這些項目、應用，因為你的重構都需要改動的話，那麼推廣難度是很大的，是以需要盡量做到，對于使用者來說無感覺遷移。
以下遷移部分，都需要在新PaaS上線前完成并在上線一段時間準實時同步過來。
PaaS平台日志的收集可以參考：《ELK+Prometheus 建構實時日志 檢索 監控 告警平台》
類似産品：https://www.terminus.io/product_paas
個人微信公衆号：