建築設計條件
以下三種情況不適合建築設計。
不是對建築感興趣，而是需求所迫；
進入IT行業不到4年；
主觀能動性弱，安於現狀；
建築設計的優勢
更好的梳理業務結構體系；
更好的擴展、維護和性能優化；
更好的適應企業業務的靈活推廣；
更好的適應大數據的沖刷和響應；
穩定性更好，成本低，叠代快；
建築設計中應註意的問題
架構設計需要註意的不是架構如何搭建，而是必須根據業務需求嚴格分析，需要哪些技術更好更長遠的發展來實現這個需求；
另外，搭建的架構雖然可以運行，但是性能需要跟上，否則架構設計會適得其反，增加不必要的工作量，這裏就詳細介紹壹下架構設計策略。
平臺要求
客戶需求
網上購物、網上支付或貨到付款；
顧客購買商品後，可以與客服溝通；
貨物采購流程和物流的管理和跟蹤；
收貨後，對貨物和物流進行評估打分；
客戶的需求是最高的，這也代表了企業的核心需求。當然，企業的需求還包括許多其他非功能性需求。詳情請參見需求排序部分。
平臺的業務架構
根據業務的需要，可以分為商品子系統、購物子系統、支付子系統、物流子系統、客服子系統、評論子系統。非核心需求可以分為客服子系統、評論子系統和界面子系統。另外，根據各子系統的核心層次，又可分為核心子系統和非核心子系統。前者包括商品子系統、購物子系統、支付子系統和物流子系統。後者包括評論子系統、客服子系統和界面子系統。需要註意的是，壹般大型電商平臺的物流系統是壹個獨立的系統(倉儲、入庫、庫存管理、配送管理、貨物管理)，這裏將其劃分為子系統的主要目的是為了論證核心架構。在這種架構中，物流子系統通常用作對接模塊，用於對接和管理獨立的子系統。
1.業務拆分的目的
為了解決各模塊子系統之間的耦合性、可維護性和可擴展性；
方便單獨部署子系統，避免集中部署導致壹個問題全部不能用；
指派壹個專門的團隊負責具體的子系統，以最大限度地提高工作效率；
應對大數據和高壓力，保障核心子系統的正常使用；
2.業務的架構圖
在上面的服務架構圖中，核心和非核心服務是分開的，每個系統都要獨立部署和實現，這樣可以減少大量的數據，每個系統都可以獨立運行，提高可用性。如有必要，可以暫停非核心系統的資源開銷，以保證核心服務能夠正常服務用戶。
平臺的技術架構
在上述業務架構圖的基礎上，我們需要壹個技術架構的演進過程，這壹切都是基於滿足用戶的體驗和支持。因此，技術架構的構建不是壹蹴而就的，而是隨著業務的不斷演進，系統架構會逐步完善和更新，以應對業務數據的沖擊。
1，基礎架構設計
記得很久以前，很多中小企業采用的架構設計都很簡單。基本上，壹臺服務器用於滿足所有部署需求。例如，壹臺服務器同時用於應用程序部署、數據庫存儲和圖片存儲。沒想到，當用戶數據達到50多萬時，系統出現了很多性能問題。盡管對數據庫和程序進行了各種性能優化，但結果仍然沒有明顯改善。該架構如下所示:
後來IT程徐苑發現圖片的讀寫嚴重影響系統性能，將圖片存儲在獨立的服務器中，並在架構中引入緩存中間件，如Memcache。這是可取的，性能提高了1-2。架構設計如下:
2.初級建築設計
幾年前，電子商務網站的普遍做法是選擇三臺服務器，壹臺部署應用，壹臺部署數據庫，壹臺部署NFS文件系統，將規模大、性能消耗大的部分分離到不同的服務器設備上，再配備必要的緩存中間件，基本可以滿足近654.38+00萬的數據量。具體架構圖如下:
但是目前主流的網站架構已經不同，大多采用集群來實現負載均衡和高可用性。該架構可以如下所示:
註意:
如果涉及多個web服務器，將會出現如何同步會話的問題。通常，最常用的方法是使用緩存中間件來存儲和管理會話信息。
3.優化的架構設計
為了解決高並發、高可用的大型電子商務網站的架構設計方案，這裏主要采用了分布式、集群化、負載均衡、反向代理、消息隊列和多級緩存技術。架構設計方案是現在比較流程的大型電子商務網站采用的架構模式，比如淘寶、JD.COM等。可能略有不同，但都差不多！具體架構方案如下:
平臺架構概述
這裏主要總結的是優化的架構，是按照層次結構來組織的。* * *分為四層，層次分工明確，高擴展，低耦合，負載均衡，集群，分發，緩存。該架構如下所示:
好了，這裏介紹壹下電子商務平臺的架構設計。本文主要介紹建築設計的理念和應用的核心技術，供學生在建築設計中參考！想了解更多可以關註我。