文章目錄
序言
架構是用來喚醒智慧的，期望喚醒和您心中的架構共鳴，今年您在觀察什麼，希望我們英雄所見略同，有不同的看法歡迎評論留言，如果只是單單因爲觀點不同就被罵的狗血噴頭，這可真是太過幼稚，現在的人太過浮躁，何必呢，有什麼事是不能坐下來好好談談的？來，給您倒一杯卡布奇諾，咱們慢慢品。
01 互聯網發展三階段
互聯網發展的三個階段的特點依次是靜態化、動態化、萬物連接，容易理解，在其發展過程中，互動形式也發生了三個階段的演進。
微信和facebook最主要的發明就是羣組和朋友圈，但實際上朋友圈不算微信的發明，微博在2.0階段的feed流就已經做出了朋友圈的雛形。微信最厲害的地方就是羣組，把關注的一對一關係，變成了多對多關係，互聯網在發展過程中，也形成了以下特點：
- 業務功能越來越多、越來越複雜
- 萬物互聯、數據量越來越大
- 請求量越來越大、更高的用戶體驗要求
- 業務快速迭代、持續交付的能力
做架構的目的不是爲了炫技，爲了讓我們的產品快速迭代，持續交付，降低人力成本，機器成本，提升開發效率，提升運營效率。互聯網架構爲什麼要演進？很顯然，需求驅動架構演進。
02 互聯網架構演進之路
03 單體架構設計與實踐
單體架構適用場景：
- 業務簡單，功能不復雜，研發人員較少
- 創業公司初期
- 性能要求極其苛刻
單體架構的優點：
- 容易開發
- 容易測試
- 容易部署
- 容易擴展
單體架構的缺點：
- 系統耦合性高
- 技術選型單一
- 開發效率越來越低下
架構破局：
- 垂直方向拆分（業務維度）例如用戶模塊，訂單模塊，商品模塊。
- 水平方向拆分（功能維度）垂直拆分後，用戶模塊依然是一個單體，在功能上繼續拆分，網關層，業務邏輯層，數據訪問層，數據庫怎麼拆，架構就怎麼拆。
04 水平分層架構設計與實踐
水平方向物理分爲多個進程，每層邏輯解耦
- 網關層
- 業務邏輯層
- 數據訪問層
- 數據存儲層
任意兩層之間加入消息隊列都可以從同步變爲異步，每層和消息隊列都是同步的。消息隊列的高效來源於本身的順序寫入。
業界主流的網關開源組件，沒有最好，只有更合適。
同步架構
異步架構
- 異步目的：提升吞吐量
- 異步方式：消息隊列
- 適用場景一：請求類型（讀請求不可以，寫請求可以）
- 適用場景二：業務類型（充值場景低併發用同步，社交場景高併發用異步）
不是所有的請求都可以用MQ,讀請求不能用MQ， 因爲讀請求是想要拿到這次請求的結果，比如說要查詢一個用戶的信息，瞬時要拿到用戶的結果，這個請求通過網關到MQ,返回ok，難道這個用戶就叫ok嗎？寫請求是可以用MQ的，所有的寫請求都能用MQ嗎？那又回到哲學本質了，所有的所有的一切都是不成立的。不是所有的寫請求都可以用MQ的。寫請求分兩種，一種是對數據一致性強，比如充值場景。這個時候就不能用異步了，用同步架構就好了，一種是對數據一致性弱，比如社交場景可以寫異步。也可以從業務的併發量來考慮，併發量低的用同步，併發量高的用異步。
但是異步架構發生在寫入請求後，我在讀請求的時候MQ的消息還沒有到DB,但是在寫入的時候，已經告訴用戶已經成功了，這個問題我們回到具體的業務場景。
在我們發朋友圈的時候，很顯然自己對馬上要發的朋友圈最感興趣，你絕對不會說，在發朋友圈之前，在羣裏去@大家說：我要發朋友圈了，你們來看一下，我相信你一定不會幹這個事情，既然你不會幹這個事情，你的朋友晚點看到朋友圈也是ok的，那這個時候只要解決自己看的問題就好了，這個時候只需要把本地發送的消息（朋友圈）客戶端緩存一下，等到你下次再請求的時候，已經是很多秒以後的事情了，下次再請求的時候，寫入的消息已經到DB了，用這種方式來解決用戶看到有延遲的問題。但是這樣也存在問題，雖然說這次可以騙過用戶，但是消息是寫到MQ裏面的，最終是要把它寫入到DB裏面去的，但是從MQ到DB過程中，會出現網絡異常，消息不合法等，最終消息是沒法寫入到DB裏面去的。
微信是這樣做的，當微信消息（朋友圈）發成功以後，過一段時間如果沒有發成功，會在最頂端提示您有一條消息未發送成功，讓你重試一下 ，這是依靠微信app和網關的Socket長鏈接來實現的，一旦業務邏輯層處理失敗後，會直接推給客戶端，如果http沒辦法處理，那必須是長輪詢來處理。
異步架構會有一些負面的影響：
- 請求路徑邊長
- 平均響應延遲變高
- 定位問題變的複雜化
- 運維成本增加
最終我們在實際應用中，同步架構分爲四層，異步架構分爲五層最合適，MVC這種架構已經逐漸的被淘汰了，在水平分層上選擇四層或者5層架構。
以上兩種架構也存在嚴重的問題：部分層粒度過粗，如業務邏輯層包含了所有的業務邏輯。
同步水平分層全貌
真正的APP請求第一步是經過DNS的，DNS通過域名獲IP，去請求靜態接口和動態接口的數據。靜態的資源如CSS、圖片是放在CDN上的，通過阿里、騰訊、百度的CDN獲取靜態圖片，如果請求的靜態資源在CDN上沒有命中，CDN會請求Nginx，Nginx會把靜態資源返回給CDN，CDN會把靜態資源緩存起來再返回給APP，Object Store（對象存儲）同理，常用的對象存儲是阿里的Fastdfs和Ceph，規模比較小的話建議用Fastdfs，規模比較大的話，建議用Ceph，但是Ceph會給運維團隊增加很大的壓力，
05 面向服務架構設計與實踐
58同城的簡化模型圖：
爲什麼SOA不是微服務架構，因爲它僅僅做了一個垂直拆分。所以缺點也很明顯：
- 每個服務還是單體架構
- 對ESB嚴重依賴
06 微服務架構設計與實踐
微服務架構即按照水平方向去拆分，又按照垂直方向去拆分