從歷史上看，北京軟件公司認為，梳理其軟件項目的所有開發細節過度的。由于軟件開發人員對可變技術和系統需求的復雜解釋，軟件開發公司認為這一過程非常乏味。因此，在系統可擴展性方面，企業代表希望與軟件開發人員進行一般業務需求討論，同時不討論所有的技術上的細節。如果企業主開始使用開發人員的語言，系統的質量會倍增。特別是，這將有助于避免許多問題，而開發人員創建復雜的基于服務器的解決方案。
企業如何與軟件開發人員保持密切聯系，了解系統可擴展性的細節？
讓我們考慮一個開發新系統的項目開始的情況。我們設計了5個問題，有助于簡化談判并將其引導到正確的軌道上。
5個主要系統的可擴展性問題，從我們的經驗來看，開發人員在談論系統可擴展性時通常會提出5個主要問題：
1.做企業了解計劃的系統的特點是什么？
2.系統用戶的典型操作是什么？
3.系統是否有什么瓶頸？系統的哪一部分負載較重？
4.系統更重要的是：容錯還是高性能？
5.可擴展性的需求在哪里出現？
我們想仔細看看五個問題中的每一個，并找出業務代表綜合答案的好處。

業務是否了解計劃系統的功能？
幕后：
可擴展性是系統通過升級現有硬件或添加額外的新資源來應對日益增長的負載的能力。系統必須保持適當的架構以允許后者。換句話說，當后端開發人員開始系統開發時，他們需要了解是否有可能將來擴展系統，這意味著其操作功能的增加。因此，他們需要知道企業主對系統特征和進一步發展的計劃。例：
讓我們想象一下，購買機票的在線服務的所有者會制定計劃的網站流量的時間表。時間表可以是一天，一周，一個月，四分之一或一年。它可以覆蓋用戶和用戶活動的類型，作為系統回答所需的時間。使用這個計劃，開發人員可以揭示網站上的負載變得更加密集的時代。例如，它可能會更接近一個周末。此外，業務代表可以在時間表中包括峰值負荷的點，如假期，學校假期和促銷活動。
架構中的峰值負載不應影響系統的性能，所以重要的是規劃它們。較好的方法之一是系統負載的圖形顯示。
小貼士：
制定明確的項目目標，制定預測網站流量的計劃或圖表。還要指出時間間隔。開發人員詢問有關系統能力的問題，而不是因為它們只是好奇。他們必須預見服務器增長的機會。如果一個企業計劃贏得世界，那就有必要明確說明目標。假設當10,000位獨特訪問者訪問了一個平均每天300名用戶的網站時，系統必須生存下去。
系統用戶的典型動作是什么？
幕后：
預測典型的操作允許開發人員分析系統上的負載。這也是一個機會，看看系統用戶是否會上傳大文件，或者需要實時聊天支持和其他功能。Web服務器之間的功能如何傳播取決于用戶操作的典型流程。
例：
我們可以參考推出移動應用的例子。用于安排會議的基于網絡的移動應用程序包括上傳照片的選項。開發人員使用中型用戶照片加載測試。然而，只要應用程序啟動，用戶開始以原始大小上傳圖片。當用戶和圖片的數量超過了Web服務器的數據存儲和處理能力時，系統無法承受負載并開始崩潰。

小貼士：
如果您想防止系統不穩定的不利影響，請詳細描述典型操作的場景。特別要考慮兩點：
您希望用戶如何與系統進行交互
它將如何實現
系統有什么瓶頸？系統的哪一部分負載較重？
幕后：
任何復雜的信息系統都可能包含至少兩個瓶頸。瓶頸是一個壓力點，在特定時刻經歷系統中較高的負載。當開發人員知道系統中可能存在的瓶頸時，如果服務器崩潰，他/她可以調整系統的工作。這有助于避免高峰負載時潛在用戶的損失。

找到瓶頸的問題與系統可擴展性無關。不過，較好不要忘記。如果一個開發人員沒有定義瓶頸在哪里，那么它可以在任何可擴展性方面取得進展。即使在系統可擴展性方面一切順利，有必要分析架構，以防止出現瓶頸
例：
入口點可能是瓶頸。例如，如果大量用戶同時打開網站，則無法承受高負載，沒有人繼續使用該網站。

信息系統的瓶頸
另一個瓶頸示例是通道寬度不足。想象一下，照片存儲中的照片之一迅速普及。數以千計的用戶打開這個流行的照片，但是Web服務器的容量不是為了這個數量。因此，上傳的照片停滯并對用戶產生負面影響。
小貼士：
只有有目的的測試可以詳細解答瓶頸在哪里的問題。然而，這并不意味著不可能評估潛在的瓶頸。
列出系統的基本部分。根據您的經驗，突出顯示較脆弱的地方。
與開發團隊討論清單。技術人員的經驗很有可能幫助您提供新的想法。
對系統更重要的是：
容錯還是高性能？
幕后：
不同系統需要不同的方法。開發人員需要知道主要任務是：容錯或高性能，或者兩者都是必需的。容錯問題非常嚴重，沒有一個獨特的解決方案。它涉及系統在服務器遭受故障時每次響應的能力。換句話說，用戶沒有達到理想的結果。例如，他或她不能訪問網站的其他頁面或通過應用程序支付服務費用。如果不清楚發生了什么，用戶將很可能拒絕再次使用該服務。為了避免用戶丟失，較好保護系統。例如，如果網站沒有對用戶請求做出反應或會話被中斷，那么可能會向用戶發送有關該事件的簡要信息的消息以及有關該做什么的一些建議。高性能涉及系統承受數千用戶并同時顯示良好響應時間的能力。換句話說，系統速度很重要。如果用戶花費大量時間填寫表單，并且每次等待頁面加載緩慢，都會對其對公司的態度產生負面影響。
例：
我們假設一家銀行經營者為接收貸款而運行客戶查詢，并填寫系統中的數據。會話崩潰，系統同時停止對操作員的應答。數據丟失，操作員沒有其他方式訪問系統。因此，操作員要求客戶等待系統恢復或第二天回來。客戶花了很多時間，現在對這種情況不滿意。這意味著系統中出現故障。而客戶忠誠度取決于系統對類似故障的抵制。
容錯
如果預見到容錯，可以以不同的方式解決可能故障的問題。例如，數據可以保存在系統的重復服務器上。然后銀行操作員可以簡單地連接到備份服務器并繼續工作。另一種方式是數據未被保存，但是有機會開始一個新的會話。因此，銀行經營者提供客戶再次填寫信息。這些情況有數十億種解決方案。確定會話期間的數據丟失是重要的還是系統需要哪些任務要容易得多。
小貼士：
確定什么問題更重要，因為它有助于開發人員事先知道應該首先考慮什么。當開發人員明確目的時，他們可以列出客戶的建議。

可擴展性的需求在哪里出現？
幕后：
企業主希望開發人員能夠很好地了解他們的業務利基，從一開始就明白他們的信息系統是否需要可擴展性。通常這些期望是假的。實際上，開發人員將重點放在軟件項目的具體目標上。他們想定義出現系統可擴展性需求的位置。它可以是大量的數據，應該在某個地方進行保存和處理，或者在特定時刻需要的復雜計算過程和多階段操作。
例：
假設社交網絡計劃增加用戶數量，并開始在互聯網上進行營銷活動。社交網絡代表看到，他們需要考慮到同時訪問網絡的次數，并在活動期間增加了負載。訪客數量的大幅增加可能會影響系統性能。當需求的來源變得清晰時，開發人員可以轉向具體任務的解決方案。
小貼士：回答當前軟件項目中系統可擴展性的含義是什么？區分意義：
基地有10,000名用戶，您需要擴展服務器的數據存儲能力
大約10,000名用戶同時訪問您的網站，服務器需要擴展信息資源
需要可擴展性

您可以根據您的答案選擇哪種方法更適合系統集群。換句話說，軟件開發人員可以根據業務需要在不同的服務器之間分配負載。系統可擴展性是業務增長時增加負載問題的必要解決方案。這種具體能力使用新的信息資源提供了系統功能的擴展。事實上，可擴展性允許支持反應速度以及越來越多的操作，事務或用戶的系統的一般性能。
對可擴展性的需求激勵北京軟件開發公司和開發人員找到有效討論的方法。如果第一和第二語言是一種語言，他們對發展戰略，功能增長和系統技術特性的增加有一個共同的認識。