35歲那年，我做了一個面臨失業的決定

2022-12-05 18:17:06

35歲 CTO 的一句話給我的感觸實在是太深了，回想起我剛入職使用的技術和現在使用的技術，簡直是千差萬別，需求在不斷的變難，而我們也在不斷進步。

前言

最近和老板以及 CTO 商議，最終是決定了轉向??云原生數據庫??，在會議結束后，我們的 CTO 攬著我的肩膀，和我說了一句意味深長的話：我35歲了，轉向云原生數據庫這個決定可能會影響我的職業生涯，要么晉升迎娶白富美，要么搞得一團糟最終失業。我聽了這句話有點意味深長，雖然我們公司沒有全面擁抱云原生，但是目前公司大部分產品已經是轉向了云原生數據庫的懷抱了。我目前接觸數據庫工作接近10年了，前5年接觸的是傳統的數據庫，后5年隨著技術的變革開始接觸云數據庫，隨后就在這家公司開始接觸云原生數據庫，感觸還是很多的。

前5年，傳統數據庫的痛

我剛出來工作那會是12年，那時候移動互聯網開始興起，越來越多的互聯網公司開始興起，數據逐漸有了一定的規模，我去找了一份后臺開發的工作，除了每天寫 CRUD 的代碼以外，還需要去維護和管理公司的機房，沒錯你沒有聽錯就是機房，那時候數據庫基本上是自己搭建的，用交換機和服務器，在一個’陰森’的房間，我穿著厚厚的防凍服，在冰涼的黑窗口獨自敲著命令，幸虧還有一絲燈光，不至于顯得太過于凄涼。

作為一個業余的機房管理者，要頭疼的東西實在是太多了，首先設備采購就是一個很大的問題，資本家都青睞于用一份錢買兩份商品，所以前期的服務器的配置、交換機的敲定就很頭疼，如果選擇配置低的，后期我需要花很大的功夫去優化去配置，都想提桶了，我是 CRUD 程序員，不是 Linux 程序員。如果選擇配置高的，我肯定會輕松很多，可以專注于業務的編寫以及整體架構的優化，但是把，成本太高了，直接被 pass 了。

其次就是機房的各種軟件的安裝和維護，因為我們公司沒有請專門的運維，那個時候運維這個工作還不是很成熟，沒有專門的運維，都是由程序員兼職去做的，那時候公司有一個機房值班表，好家伙，我一看，全部是后臺開發程序員。軟件安裝和各種虛擬化以及后期的維護都是我們來做的，痛！太痛了。我畫了一張示意圖，大概我一個人一天要去管理和維護那么多臺機器。

還有一個很重要的點，那就是資費的問題，因為我們公司是房地產中間商的網站，當時的業務是有季節性的，大概在6-12月是旺季，那時候購房者的需求是比較大的，由于流量的增大，對于服務器的要求也是比較大的，這個時候上半年采購的服務器完全是不夠用的，這半年我們團隊基本上是不會去寫業務的，基本上就是各種優化，降低服務器的負載，我當時就在想，如果有服務器可以靈活一點該多好。

后3年，云數據庫的輕

后面實在是不堪重負，我選擇了提桶。時間眨眼間過了五年多，那時候的數據庫已經日趨成熟，MySQL 成為了霸主，市面上百分之80的公司都在用，而且出現了非關系型數據庫，像 redis、ElasticSearch 等這種數據庫，由于數據量的增大，數據庫在整個業務中顯得越來越重要了。

這個時候出現了云數據庫，我們公司由于是快速發展中的小企業，使用的是亞馬遜云原生數據庫，我第一次使用就被這種使用模式所驚艷了。真的是很方便，完全不需要我去擔心數據庫方面的東西，因為他們都幫我配置好了，我只需要專注于我的 sql 編寫即可，一旦有大量的要求，我走審批加錢去升級容量就可以了，一旦到了淡季我可以降低容量，甚至還體驗了一把無服務器版本的 Aurora，不用都無需花什么錢，簡直省了不少錢。

而且連傳統的機房的錢也省了，據說這家企業全部產品轉向云原生數據庫了以后，把公司的原來的機房改造成了一個健身房。

剛好這幾年，終端工具也逐漸多了起來，像 XSehll、MobaXterm 等工具，可以直接通過這種工具去連接到云端，我甚至有點懷念我以前在小黑空調房里面調試數據庫的日子了。

方便不說，而且種類是真的齊全，如果想要關系型數據庫，可以選擇 Amazon RDS、Amazon Aurora，如果想選擇緩存，可以選擇 Amazon Elasticache、Amazon MemoryDB for Redis，想用文檔型數據庫，有Amazon DocumentDB，想嘗試圖數據庫，可以選擇 Amazon Neptune，甚至是非關系型數據庫，有 Amazon DynamoDB，可以說是只有你用不到，沒有亞馬遜云科技做不到。

這2年，云原生數據庫的卷

這兩年，我也逐漸邁入云原生的步伐，不僅僅是因為各大廠商都開始發布自己的云原生的產品，越來越卷了，更重要的是，隨著人工智能和大數據的普及，云原生才是真正的未來。我們之前使用的云數據庫其實本質上是屬于云計算領域，云計算應用程序通常是在內部使用傳統基礎設施開發的，并且經過調整后可以在云中遠程訪問，簡單理解就是我在地面上通過遠程軟件去鏈接大氣層的云軟件，實質上還是部分在云上。接下來我來講講為啥我要完全上云？

首先從是使用角度，云計算應用程序通常需要手動升級，比如說我要升級數據庫的或者是服務器的，通常是需要先關閉再升級再打開這么幾個步驟，從而會導致應用程序中斷和關閉，而我在使用云原生數據庫的時候是感受到了云原生數據庫的友好，他是具備高度可擴展性，可以對集群規模進行實時調整，而不會對整個應用程序造成干擾。意味著我可以無感升級或者降配。

接著我感觸更深的就是價格，畢竟我們上云就是為了降低成本，從以前的自建機房到后面的云數據庫，都在進一步降低成本，或者說是把成本轉嫁到其他廠商身上，我們把機房搭建、服務器運行、服務器維護、軟件安裝等一系列成本轉嫁到了亞馬遜云科技等一眾廠商身上，我們只需要付小部分錢就可以享受到了更優越的服務。

亞馬遜云科技的云原生應用程序不需要任何硬件或軟件上的投資，因為它們是在云上進行的，可以靈活的利用云的彈性優勢，因此使用起來相對便宜，這對于中小型企業來說簡直是福音。

私貨：Amazon DocumentDB 的使用體驗

順帶說一下最近公司轉型云原生數據庫使用最頻繁的一款產品吧，那就是Amazon DocumentDB。他是一款兼容 MongoDB 的數據庫產品，由于公司在轉型期間所做的一些業務拓展，對于海量的 json 數據的處理有性能與成本方面的考量。

我們 MongoDB 是一款文檔型數據庫，他使用的是 json 格式的數據，與傳統的關系型數據庫不同。在以前，如果想要支持高并發的請求，通常我需要搭建多臺服務器組成一個集群，而 Amazon DocumentDB 通過獨立擴展計算和存儲，支持每秒數以百萬計文檔的讀取請求，就問各位老鐵，這個功能六不六。

我們公司的評論是使用 MongoDB 來存儲的，按照以前方式的部署，一旦服務器出現了問題，不僅僅會導致評論這個功能出現問題，一不小心還會導致整個系統宕機，而 Amazon DocumentDB 的一個功能給了我很大幫助，那就是自動化硬件預置、修補，我至此就再也沒有擔心過穩定性的問題了，而且他還可以通過自動復制、連續備份和嚴格的網絡隔離實現 99.999999999% 的持久性，數據的穩定性保障讓我很放心。

從 MongoDB 遷移到 Amazon DocumentDB也很簡單，借助另一個服務Amazon DMS 就可以啦。