30-30 之馬克版的一個好的系統攻略本 - 性能基礎篇

it 鐵人賽 2019

Lastmod: 2019-12-15

這漫長辛苦的 30 天總於結束囉 ~ 接下來依慣例第 30 天都是總結篇。

這 30 天的過程咱們都在追求『一個好的系統』中的其中一個重點 :

性能

性能越高的系統，可以帶給『公司』與『用戶』雙方都達到愉悅的情況。

咱們先看看第一階段最基本系統的樣子。

單機的優化方向

應用層方面性能優化重點知識

這下面 7 篇文章，應該涵蓋住了應用層性能方面所需要注意的重點，雖然有分 cpu 與 i/o 優化，但是我是覺得也不用分到那麼清楚，只要記得，你是要儘可能的以最少資源來做事情就對囉。

運算與 i/o 是重點，但總結來說就是『儘可能的以最少資源來做最多的事情』

資料庫層優化重點知識

接下來到一個系統的命脈『資料庫層』的性能優化知識。這裡的最大重點在於 :

索引

但在追求性能的路上一定會碰到的大敵『一致性難題』，要追求高性能，就要理解它的敵人，才能在兩者間抓取『平衡』。

性能大敵，一致性問題

資料庫層的應用一定會碰到貧頸因此接下來，第一個建議不是開多個資料庫，而是建立緩存服務。

資料庫的好夥伴，緩存服務

網路傳輸優化知識點

咱們每台機器裡面的東西能優化完的都優化完以後，我覺得可以往『網路傳輸』方面儘可能的優化。其中咱們這裡以『 http 』為主，因為這個傳輸協議基本上是這世界上最多人使用的應用層協議，就算不是寫網頁的系統，也都是會使用 http 來打 api 之類的，所以理解它是非常重要的。

分散式優化方向

這裡要記好，單機沒搞好前，不要有事沒事為了『性能』而建立分散式系統，會有非常多的坑等這你。

這裡簡單說一下，事實上這 30 天，我的分散式篇說的不多，因為我認為高性能的基礎在於單機，單機處理的好，我覺得才有資格往分散式前進。

應用層分散式擴展

應用層擴展基本上沒什麼毛病，只要記得每個應用都是無狀態的就好，如果是有狀態就難處理囉。

資料庫層分散式擴展

最大的坑是在這，這裡又會出現性能大敵 :

一致性難題

首先資料庫層的擴展第一個建議的架構為『讀寫分離』，這個坑會比較小一點。

30-25之資料庫層的擴展 - 讀寫分離架構

接下來的模式，除非上述架構真的已經到了貧頸，否則不建議實作，坑很多。

然後就是咱們的大敵。

30-28 之資料庫層擴展難題 - MySQL 分散式事務處理

最後這裡簡單的介紹一下資料庫的中間件。

30-29 之資料庫層擴展中間件 - MyCAT 的淺淺談

最後心得與結論

總於要結束囉，這裡總結一下心得，這 30 天寫完，我覺得要建立一個好的系統的有重點在於 :

平衡

在這 30 天雖然副主題是高性能，但是在這條路上，常常會需要損失一些性能來增加『維護性』與『可用性』，為啥 ?

因為咱們是追求『好的系統』

如果要完全的追求高性能的系統，那就會損失不少東西，可能會導致用戶不愉悅或老闆不愉悅。

但要如何儘可能的做到平衡呢 ?

儘可能做好每個地方

這應該不用多說，每一個地方都做好，基本上我就覺得這個系統有達到『一個好的系統重點』。但是要做到這件事情，就需要每個地方都深入的理解，這樣才能達到『平衡』，不然你想想你專精於高性能，但是對一致性難題一知半解，你覺得做出來的東西如何呢 ? 我會怕啊……

最後也因為上述理由，這也是為什麼這三十天的主題為 :

30天之從 0 至 1 盡可能的建立一個好的系統 ( 性能基礎篇 )

別忘了咱們追求的是『好的系統』，『性能』只是其中一部份，好系統才是根本。

最後希望這個攻略本，可以讓各位友人可以在探索一個好的系統中，找到性能方面一些根本方向 ~ 有了根你就能理解散發出去的不同系統囉 ~

希望明年可以寫性能進階篇，應該是有可能，寫完這 30 篇我的小腦袋又冒出好多條進階支線可寫。