網站建設中如何做好可用的架構設計是關于網站建設中如何做好可用的架構設計的文章，同信長春網站公司幫您了解網站建設中如何做好可用的架構設計的方面的知識.

     一個架構要設計的好，和對需求的理解是分不開的。因此在現實中，我們發現業務領域專家憑借著他對業務領域的了解，能夠幫助開發人員設計出優秀的架構來。架構是需要抽象的，它是現實社會活動的一個基本模型，而業務領域的模型僅僅憑開發人員是很難設計出來的。在ERP的發展史上，我們看到MRP發展為MRPII，在發展到閉環MRP，直到發展成為現在的ERP，主要的因素是管理思想的演化，也就是說，對業務領域的理解進步了，架構才有可能進步。

第一、 支持快速定位故障

     從實際工程的角度看，不出故障的服務是不存在的，所以出了故障要能夠快速發現和定位，在外部用戶發現前，通過報警機制，能準確定位故障原因，幫助工程師盡快處理問題，防止進一步影響業務。 

第二、 支持快速恢復業務

     這一點需要多說兩句，有關“恢復業務”和“解決問題”之間的區別，這兩個詞也正好說明了線上出現故障后，我們解決問題的兩種不同思路。簡單的說，“恢復業務”的意思是線上故障是什么原因可以先暫時放在一邊，我們先找到快速的臨時方案，讓業務跑起來。很多同學在處理生產故障的時候有一個思維慣性：先努力找到問題的起因，然后改代碼解決問題，測試，發布上線，最后業務功能才能正常工作。實際上，一個流程走下來，時間成本是很高的，業務因為本次故障受到較大的影響。比如說某臺機器上的服務響應很慢，導致請求超時，可能的原因有：網絡帶寬出現問題、機器磁盤有問題、機器的CPU或者Memory不夠用了、應用程序有死循環、jvm垃圾回收時間變長......要在短短幾分鐘內排查這么多可能的原因是很難的，但我們不知道真正的原因也可以恢復業務，比如說最簡單的方法就是直接把這臺機器立刻下線，讓流量分配到其它的機器或者新添加的機器上。

第三、 保持業務高穩定性

     系統穩定性是高可用的根本目的，通俗的說，系統能持續可用，不會無故宕機，在高壓下仍然能正常工作。既然我們的目標是做到高可用，那么我們就有必要先明確清楚高可用的含義，并通過拆解目標，讓目標可以被量化。

     在敏捷方法論中，需求最好是迭代進行的，也就是說一點一點的作需求。這種做法在那些需求變化快的項目中尤其適用。由于我們采用的流程是一種迭代式的流程，這里我們將會面臨著如何對待上一次迭代的中間產物的問題。如果我們每一次迭代都需要修改已存在的中間產物，那么這種維護的成本未免過大。

網站建設中如何做好可用的架構設計由同信長春網站建設公司為您提供，同信長春網站制作公司為您提供長春網站制作更多內容：轉載網站建設中如何做好可用的架構設計請注明出處。http://www.fdus.com.cn