伺服器 ubuntu/centos/windows

web伺服器 nginx/apache

php，php擴充套件

資料庫

快取

redis

訊息佇列

...

專案部署

伺服器日誌收集、分析

1.業務檢視，是簡單的單體應用還是伸縮性好的服務化。

2.資料庫檢視，單庫或分表分庫。

3.技術開發平臺或架構

4.運維檢視，單機，均衡負載，叢集。

說的比較籠統。

我多次全程參加從策劃到運維的系統開發，在這裡分享一些乾貨。架構設計過程大致可分成需求分析和系統設計兩個階段。

這個階段的目的是進行需求分析制定系統的邏輯模型。需求可分為功能性需求和非功能性需求。功能性需求主要是業務邏輯，非功能性需求則是業務以外的需求，如執行環境，資訊保安，故障診斷等等。功能需求可使用用例圖等視覺化的工具來完成。非功能需求涉及到的技術較多，沒有通用的結構化的方法，一般需要參考類似系統的經驗。這部分的設計結果可以用配置圖進行視覺化。完成了功能性需求和非功能性需求之後，可將兩部分需求進行統合，具體就是，結合系統配置為每一個用例設計邏輯流程。

這個階段的目標是把需求分析階段建立的邏輯模型轉換成物理架構。首先，要根據邏輯配置選擇網路，伺服器，作業系統，資料庫，各類服務程式執行環境，並拆分出子系統。確定了子系統之後，可以為各個子系統選擇程式語言和架構模組(如，Struts)。確定了子系統的架構之後，就可以進行程式結構的設計了。程式結構設計要從用例圖中抽出事務，從邏輯時序圖中抽出邏輯類，將各邏輯類部署到各物理配置上，確定物理類，設計物理時序。最後，可從時序圖上，抽出物理類，根據類的功能整理，並選擇設計模式，補足實裝所需的各種類的定義，做類圖。至此，架構設計完成。

我是一個假的架構師，真的程式設計師。

現在所在的專案，是去年八九月份啟動的，雖然不是一個網站，但是大部分工作都是類似的，那麼我給大家介紹一下這半年我做了哪些工作。

一般新建一個專案有兩種背景：

一種是沒有系統，需要重新建立；

一種是有老系統，但是因為種種原因，需要新建一個系統把老系統替換掉（或替換部分功能）；

我們算是後者，老系統已經執行多年，主要工作是對外提供介面服務，現在服務的效率和抗壓性都無法滿足業務需求。

需求，在開發之前一定要明確需求。因為是對老系統的改造，所以需求相對來說比較明確。

梳理老系統有多少介面，壓力比較大的介面有哪些，確定介面遷移的優先順序。

確定第一批遷移的介面之後，需要對介面的處理邏輯進行梳理，包括出參入參都是什麼，對引數有哪些校驗，出參的是從什麼表的什麼欄位取得，查詢條件是什麼，是否對資料進行了加工、轉移等處理。

主要是透過“扒程式碼”的手段，這一步很痛苦（程式設計師們都懂的）。

因為是老改新，壓力容易預估出來，我們主要關注的幾個點：

現有系統的資料量有多少，年增長的資料量是多少。

多少系統在呼叫，大概伺服器的數量是多少。

平均每天的呼叫量，如果業務幾種在某些時間段內，比如工作時間，那麼就要估計出每小時的量大概是多少。

業務高峰期的時候，量有多少。

其實我也是野路子出身，我在做這一步所做的工作有這些：

整理專案的功能點，比如我們這個專案主要功能有：資料抽取、資料儲存、資料加工、服務提供；這一步形成整體的功能架構。

對每個大的功能點，評估需要使用的資源，拿資料加工為例：資料加工主要就是批處理，需要Tomcat部署Java程式，需要Redis做分散式鎖和快取，需要MongoDB做加工後的資料儲存；這一步形成整體的方案規劃。

繼續詳細的評估，根據前期統計的資料量，對MongoDB的部署進行評估：是否需要分片，如果分片的話，前期部署幾個分片，容量申請多少；當這些評估都做完之後，就可以把一個一個的點彙總起來，就形成了物理部署架構。

到了這一步，基本上技術架構圖也就出來了。

在設計過程中，還要和很多人進行溝通，比如DBA、比如領導。

到了開發階段，我依然在。

這時候，一邊招人（招人有些晚了），一邊搭框架；一邊面試，一邊寫程式碼。

最後開發人員招的差不多的時候，我從無到有，第一個介面基本上開發完成了...

現在嘛，我依然在專案裡面，溝通需求、設計、任務分配、寫寫程式碼、看看開發人員寫的程式碼再給他們提提意見，如果別的專案組有設計或開發方面的問題，我也會幫忙處處主意；

我總覺得我是個假的架構，真的程式設計師。