淺談架構是爲了什麼 (下)

時間 2019-11-06

標籤淺談架構爲了什麼欄目系統架構简体版

原文原文鏈接

前言

上一章對架構進行了通俗的解釋，本章以圖文並茂的形式對架構的演變作詳細的闡述php

架構並不是因高併發、大數據而生,如下的架構方式是根據業務演變而變動。

從如今開始，假設咱們本身是一個創業的小團隊。沒資金沒人脈，靠技術打天下。如今要開發一套電商系統。開始本身的表演。mysql

1.0

沒錢沒人，只能買得起一臺阿里雲學生機。這時咱們只能選擇使用下面的架構nginx

單機部署整個LNMP環境是惟一選擇，這時咱們還能夠對1.0版本作一些優化的地方，在主從數據庫這裏，要注意了。單機跑主從簡直是畫蛇添足。單機流量自己就有效。主與從的承受是一致的。因此主從在單機跑?(相信你不是在開玩笑)，但若是視數據與聲明的話，主從仍是有必要的(當備份了唄)。優化後的架構圖以下程序員

雖然依舊很勉強，但咱們將文件存儲轉移到了其餘雲，比較少於n個g流量是免費的😄，對php進行了優化，改修改的都改了，主從也作了。這個1.0的版本勉強的撐過了創業初期。而後災難再一次降臨...redis

1.*

這時候手頭已經有點錢了。公司準備再購入一臺服務器。這時架構以下所示sql

新購入的機器與老機作了一個負載均衡，將流量分發。這時候主從數據庫就派上了很大的用場。這裏先將主數據庫做爲增刪改數據庫，而從數據庫而是查數據庫。接下來能夠安逸一段時間了。但在生產環境上，咱們須要預知問題，檢測bug，因此無奈下又改善架構數據庫

將日誌，包括mysql慢日誌，查詢日誌，nginx的請求日誌，錯誤日誌，php的錯誤日誌，慢日誌都暫時存入redis內，至少我存起來了。有問題我能有處可查。隨後將大表切分，例如文章表，用戶表的。1.x的版本再不斷迭代中愈來愈完善。但一旦出現併發就掛掉。這事看來須要認真的去對待了。segmentfault

2.0

談及併發，我瞭解的並不深刻，僅僅知道是一瞬間對服務器的衝擊數，解決併發的辦法也很簡單，將請求分流，分的越細越好（這也並非越多越好，具體界限，我也不清楚），架構圖以下服務器

將用戶請求(固然我指的是部分的)，例如搶紅包，限時搶購等業務，加入到隊列中，掛爲待處理形態，處理結束後將處理結果存儲到redis而後通知用戶，定時某個時段將redis數據存儲到mysql，結束戰鬥。我想象的咱們的公司已經比較牛x了。購入了不少臺服務器。時候對現有的架構作出一些改變了。但並非天翻地覆的變化。架構

固然這僅僅是物理架構，真實的業務要複雜一些。接下來經過不斷的努力，咱們開啓了2.x時代。

2.*

應該具有的設備及其環境都準備好了。如今咱們須要作的是將業務需求補齊，固然也沒有想象的那麼誇張。

咱們負載均衡做爲分發調節器，將請求平均到指定服務器，經過開發語言去查詢數據庫數據而後返回，這一系列的操做都在監控系統與日誌系統的監控中，固然說是系統，實際就是一個後臺，一套程序，去監控數據時作篩選。如遇緊急狀況則報警。數據正常並非直接存儲到數據庫而是扔到隊列，任由它翱翔。當業務不斷壯大。其缺點或者漏洞並非某種架構方案能夠去解決，要就事論事，瞧病就醫。這纔是架構師的精髓所在。以上描述的這些套路。很差意思的說已經差很少吸光了個人架構知識庫。下面的東西是正在研究的架構。

3.0

咱們預計上線的3.0版本引用了服務治理的架構思想。將業務分割，在本地經過tcp直接請求，並不是經過http。這塊我寫過幾篇文章，@周夢康康神也有不錯的直播講解。如下爲連接。我就不過多講解了。

PHP程序員如何簡單的開展服務治理架構(一) https://segmentfault.com/a/11...

PHP程序員如何簡單的開展服務治理架構(二) https://segmentfault.com/a/11...

PHP程序員如何簡單的開展服務治理架構(三) https://segmentfault.com/a/11...

PHP 進階之路 - 零基礎構建本身的服務治理框架（上） https://segmentfault.com/l/15...

PHP 進階之路 - 零基礎構建本身的服務治理框架（下）https://segmentfault.com/l/15...

3.*

3.x是一個學習參考，自我檢討，自我反省的過程。參考大廠的架構設計，結合本身公司的架構設計，取其精華、去其糟粕。貼一張大廠的架構圖我感受毫無心義。這裏就很少講了。

老一套

如今回到文章的中心思想上。到底爲了什麼作架構？個人答案是「活」，爲了讓產品活下去而作架構。何時能夠作架構？任意時間均可以作。但要看精力、財力、人力。

可擴展

可擴展性上篇文章我說過，是一把束縛個人刀，這把刀是什麼？是「災難」，在設計架構，包括在業務，物理或者是說部署上。這把刀一直在我脖頸處，若是這時爲了省事，躲開了，那將來的某個時間，這把刀就會斷頭。作了五年的程序員。實際困難需求、複雜需求還有部分BUG的產品，我的認爲與擴展脫不了關係。不管在任何的架構設計上，要考慮向前擴展、向後迭代。