背景 隨著容器化、雲原生等的流行，DevOps團隊也在不斷鼓吹「以無狀態為榮，以有狀態為恥」。因為有狀態的服務難以部署、難以擴展。下麵我舉幾個自己工作中實際的例子。 實例1-依賴系統目錄結構 剛轉來基礎架構的時候，接手了一個服務，原來是個應屆生寫的。所以可以理解，也就是基本能完成功能，反正也不是核心 ...
背景
隨著容器化、雲原生等的流行，DevOps團隊也在不斷鼓吹「以無狀態為榮，以有狀態為恥」。因為有狀態的服務難以部署、難以擴展。下麵我舉幾個自己工作中實際的例子。
實例1-依賴系統目錄結構
剛轉來基礎架構的時候，接手了一個服務，原來是個應屆生寫的。所以可以理解，也就是基本能完成功能，反正也不是核心服務。
剛拿到的時候下載下來本地運行沒成功，報錯是說對某個目錄下沒有某個文件。讀了一下代碼發現是啟動時需要載入一個本地認證的證書。從發佈腳本目錄下找到了那個證書文件，放到指定目錄下後運行成功。
後來把這個證書的內容放到了公司的秘鑰統一管理服務上，就實現了更加安全的無狀態化了。
無狀態是指服務內部變數值的存儲，這裡證書文件是存儲在伺服器上的，那就是這個變數值，是一個狀態。
實例2-依賴伺服器上腳本
之前在金融那邊有個兄弟是從「去哪兒」過來的。當時我們聊起日誌的定時歸檔。一般java日誌組件都帶有這個功能。但是在「去哪兒」的時候他們採用的cron腳本來實現。原因是更省資源更高效。
後來我自己想了想，在一般的項目中還是更建議用自帶的日誌組件。因為便於統一管理，可移植性好。
仔細分一下領域：日誌和業務邏輯分開，沒有問題。但是日誌需要和服務分開嗎？服務性質、列印日誌的級別、服務的量級直接決定了日誌文件的大小以及歸檔策略。如果需要調整時要找另一個地方就不太合適的。
如果這個東西真的和業務邏輯一點關係都沒有。那就會有一個專門的服務比如在linux系統層自己去處理這件事情，我們就不需要感知了。
無狀態是指服務內部變數值的存儲，這裡伺服器上的腳本就是那個狀態。
實例3-zookeeper和DB
zookeeper、分散式共識、分散式協調、leader選舉、master-slave五個概念都不知道的可以跳過這個例子。不影響理解本文的核心。
zookeeper和目前經典資料庫部署既然有master和非master之分。那麼就是有狀態的，是否為master就是一個狀態。
這個狀態會引起什麼問題呢？
不容易水平擴展：經典的線上mysql部署方式是1主2從或者1主3從。只有主節點負責寫。壓力扛不住了，可以縱向升級，就是提高機器配置。或者垂直拆分，業務自己去拆庫拆表。
節點多反而引起性能下降：zookeeper也好、mysql也好，之間要通信，節點越多開銷越大。zookeeper用Paxos來解決拜占庭將軍問題的時候，節點越多，可用性是越差的。這個不解釋了。知道有狀態不好就OK啦。著實，像資料庫、圖片存儲服務這樣的，本質就是磁碟存儲的，是做不到無狀態的。這會增加一些部署上的困難，但是是可以接受的。但是對於外側業務來說，如果是有狀態的，就需要問自己一下：是否可以通過引入中間件等策略來消除狀態？
內推
最近陸續收到一些朋友讓幫忙美團內推的的消息，非常歡迎！內推請自助。填寫完材料我會收到消息，然後我會幫忙一起物色合適的職位。
校招
社招
相關閱讀
