不同行業開始招募架構技術人員，架構師就誕生了。。

架構師，我想很多人都知道，其實這個職稱在最早的IT領域是不存在的。是近幾年互聯網發展引起的需求，由于當前的數據量和高并發的活躍度和活躍度，讓很多傳統技術人員無能為力。企業越來越重視系統架構的重要性。于是，不同的行業開始招聘架構技術人員，架構師應運而生。

建筑設計條件

以下三種情況不適合建筑設計

對架構不感興趣，但受需求驅動；

以不到 4 年的經驗進入 IT 行業；

主觀能動性弱，安于現狀；

建筑設計的優勢

更好的梳理業務架構體系；

更好的擴展、維護和性能優化；

更好地適應企業業務的靈活推廣；

更好地適應大數據的刷新和響應；

穩定性好，成本低，迭代快；

架構設計要注意什么

架構設計需要注意的不是如何搭建架構，而是要根據業務需求進行嚴格的分析，需要哪些技術來實現需求才會更好更長遠的發展考慮;

另外，構建的架構雖然可以運行，但性能需要遵循，否則架構設計會適得其反，增加不必要的工作量，那么下面將詳細介紹架構設計策略。

平臺要求

客戶需求

網上購物、網上支付或貨到付款；

客戶購買產品后，可與客服溝通；

采購商品的流程、物流管理和跟蹤；

收到貨后，對貨物和物流進行評估打分；

客戶的需求是最高的，也是企業的核心需求。當然，企業需求還包括許多其他非功能性需求。具體請參考需求排序部分。

平臺的業務架構

子系統模塊按業務需求劃分，可分為商品子系統、購物子系統、支付子系統、物流子系統、客服子系統、評論子系統；非核心需求可分為客服子系統、評論子系統和界面子系統。另外，根據每個子系統的核心級別，可以拆分出核心子系統和非核心子系統。前者包括商品子系統、購物子系統、支付子系統和物流子系統；后者包括評論子系統、客戶服務子系統和界面子系統。需要說明的是，一般大型電商平臺的物流系統是一個獨立的系統（倉儲、出庫、庫存管理、配送管理和貨物管理），劃分子系統的主要目的是為了展示核心架構。在該架構中，物流子系統一般用作對接模塊，用于對接和管理獨立子系統。

1、業務拆分目的

為了解決各個模塊子系統的耦合、維護和擴展；

方便子系統單獨部署，避免集中部署出現問題，全部無法使用；

指派專門團隊負責特定子系統，最大限度地提高工作效率安排；

應對大數據，保障高壓下核心子系統的正常使用；

2、業務架構

在上面的業務架構圖中，核心和非核心業務是分開的，每個系統都要獨立部署和實現，這樣在大數據量的壓力下，每個系統獨立運行，提高可用性，并且可以必要時使用。暫停非核心系統的資源開銷，保證核心服務能夠正常為用戶服務。

平臺的技術架構

在上面的業務架構圖的基礎上，我們需要一個技術架構的演進過程。一切只在滿足用戶體驗和支持的前提下。因此，技術架構的構建不是一蹴而就的，而是隨著業務的不斷演進。系統架構將逐步完善和更新，以應對業務數據量的影響。

1、基礎架構設計

記得早期很多中小企業采用的架構設計很簡單，基本上是用一臺服務器來滿足部署的所有需求，比如：一臺服務器用于應用部署、數據庫同時存儲和圖像存儲。問題是當用戶數據達到50萬以上時，系統會出現很多性能問題。雖然對數據庫和程序進行了各種性能優化，但效果仍然沒有明顯改善。結構如下：

后來，IT程序員發現圖片的讀寫嚴重影響系統性能，將圖片存儲在單獨的服務器中，并在架構中引入了Cache中間件，如：這種方式是可取的，并與原有性能，性能提升1-2個性能等級。架構設計如下：

2、基礎架構設計

幾年前，電子商務網站的普遍做法是使用三臺服務器，一臺部署應用程序系統架構師是p6嗎，一臺部署數據庫系統架構師是p6嗎，一臺部署NFS文件系統，從而將規模和性能分開-消耗零件。對不同的服務器設備，再配備必要的緩存中間件，基本可以滿足近千萬的數據量。具體架構圖如下：

但是，目前主流的網站架構有所不同。他們中的大多數使用集群來實現負載平衡和高可用性。架構可以如下：

注意：

如果涉及多個網站服務器，就會出現如何同步的問題。一般來說，最常用的方法是使用Cache中間件來存儲和管理信息。

3、優化的架構設計

為解決高并發、高可用的大型電子商務網站架構設計方案，主要采用分布式、集群、負載均衡、反向代理、消息隊列和多級緩存等技術。這個架構設計方案是當今比較流程的大型電商網站所采用的架構模型，比如淘寶、京東等，可能會有細微的差別，但是大同小異！具體架構圖如下：

平臺架構總結

這里的主要總結是優化的架構。該體系結構以分層結構組織，分為四層。層次分工明確、高擴展、低耦合，采用負載均衡、集群、分布式和緩存等技術。架構如下：

好，電商平臺的架構設計就介紹到這里。本文主要介紹建筑設計的思想和應用的核心技術，供建筑設計學子參考！想了解更多可以關注我