創業公司的架子
設想一下，如果幾個人搞創業，起初有少許的啟動資金，該怎麼樣将産品原型落地？
答案基本是先以最小的成本，将産品跑起來，畢竟使用者量起初也是非常小的。
此時可能沒有複雜的負載均衡接入，沒有伺服器叢集，但也沒有大廠擁有的任何自建設施，看似架子簡單，但假如沒有開源世界的幫助，所有的事情不得不從零搞起來，刀耕火種、茹毛飲血，想想都頭大。
起初的基本配置大概是這樣：
即便如此簡單，各個子產品也需要依賴衆多開源世界的幫助，比如APP子產品需要引入各個端的開發架構、通訊架構等甚至跨端架構，邏輯服務需要引入服務架構、通路存儲的驅動層架構等，存儲更是需要完全引入開源的MySQL等。
更何況，上述配置屬于demo階段，示範給投資人看看還行，如果産品上線營運，至少需要滿足下面的配置：
任何一個子產品的從零開發，都會耗費巨大，而創業公司更是希望就耗費集中在自身的産品創意的落地上，好鋼用在刀刃上。
這裡要感謝開源社群所有無私奉獻的貢獻者，以及為大家提供開源社群平台的Linus，向大家緻敬。
通過github，使得創業公司可以借助相關的開源系統和架構順利搭建公司架構，并專注在自己的業務核心上。
高可用架構
随着業務的發展，公司往往會面臨使用者的爆發式增長，生産系統故障頻頻。公司層面下重手處罰，責令上線需選擇在業務低峰期進行，一線同學戰戰兢兢如履薄冰四處救火疲于奔命。究其根本原因在于基礎設施、系統架構需要更新。
這是一項龐大的工程，這裡隻針生産系統的高可用架構展開。
計算機系統服務對外提供服務集中在網絡、計算、存儲三個層面，所謂的伺服器千萬網卡、萬兆網卡指的就是網絡層面單台服務能達到的吞吐上限，所謂的8核、16核CPU指的就是伺服器的計算能力，所謂的伺服器dd指令裡的200M/s指的是存儲次元磁盤的讀寫能力上限。
當QPS（每秒的請求量）達到一定量時，系統的瓶頸可能出現在三個層面的任何一處，好消息是設計良好的架構一般通過水準擴容（即額外增加些伺服器）就可以解決網絡、計算的瓶頸問題。然而由于存儲的中心化體系，使得最後的系統瓶頸往往都出現在存儲層面。
通過将生産服務設計成無狀态的、幂等的，或者再往上一層将一批服務打包成功能子產品無狀态、幂等的，就可以實作業務水準擴充的能力，業界叫法不一，有的說是set化、有的說是單元化，總之意思差不多。
存儲層面的高可用相對困難一些，因為存儲涉及到讀和寫，涉及到資料一緻性，有些金融場景要求更為嚴格。對此，近期國内的網際網路巨頭騰訊、阿裡分别開源了PhxSQL和OceanBase，非常友善。
如果覺得PhxSQL和OceanBase類産品比較重，難以切入掌控，比如要針對自身業務特點定制一些特性，則需要更輕量更靈活的方案。
MySQL主從同步原理：
阿裡有個有意思的開源方案是otter + canal，其中canal僞裝成Slave接收來自所屬主庫的Binary log，otter做資料的邏輯處理，進而實作資料的單雙向同步。
整體方案單向資料流原理圖：
可視化界面大緻如下：
如何做定時任務
做完存儲層的高可用，建立多資料中心，接下來需要定時檢測多中心的資料一緻性。對于熟悉Linux的同學可能首先想到crontab，然而crontab存在局限性，比如單點問題、執行粒度問題等。
github裡有很多開源的定時任務系統，如Java語言實作的quartz、Go語言的gocron等，當時我們選用quartz實作的一套相對簡單的定時任務系統，根據庫表配置多項定時任務實作整體業務的完整性。
破繭成蝶
随着公司更進一步的發展，此時面臨着上市，技術層面也需要營造自己的影響力。
結合自身業務的高并發大流量的場景，以及長期的特性疊代與技術沉澱，大家對之前使用的開源技術有了更加深刻的了解，也在細節上有了獨特的認識。更重要的是，此時人才濟濟，我們有能力有精力也有驅動力來重構這一套技術體系，形成更加完善的解決方案。
至此，誕生了更具穩定性更先進的技術架構，最終會回饋到開源社群，良性循環。
總結
前人栽樹後人乘涼，乘涼後感謝前人的同時，希望大家能一起保護好這片林子。