閱讀《大型網站技術架構》

       本次重點閱讀了第5、6、七章。

       系統的可用性是十分重要的，第五章介紹了網站的高可用性架構，甚至用上了萬無一失這樣的字眼。可用性體現了系統故障的多少以及出現故障後恢復的速度，一個的不可用時間越短，網站的可用性就越高。網站的可用性能夠用多少個9來度量。雖然一個網站不多是徹底可用的，但咱們能夠盡力去作一些事情去完善。於是，高可用架構的主要目的就是保證服務器硬件故障時服務依然可用，數據依然能被訪問。實現高可用架構的主要目的就是數據和服務的冗餘備份及失效轉移，也就是服務器的切換以及讀取備份磁盤的數據。網站設計基本上遵循應用層、服務層、數據層這樣的三層架構，各層之間具備相對獨立性，保證了網站的可維護性。隨着網站的複雜性的提升，可能粒度會愈來愈細，可是大致上都離不開這三層結構。不一樣層次結構的服務器具備不一樣的可用性特色，於是解決方案也不一樣。

       位於應用層的服務器狀況和應用層的服務器，會經過負載均衡設備將一組服務器組成一個集羣共同對外提供服務，當某個服務器不可用時，將其剔除並將請求分發給其餘可用的服務器上，使整個集羣可用（由於無狀態性）。位於服務層的服務器也是經過集羣方式，可是經過分佈式服務調用框架訪問。還有幾項策略，如：分級管理，超時設置，異步調用，服務降級，冪等性設計等。位於數據層的服務器須要在數據寫入時進行數據同步複製，將數據寫入多臺服務器上，實現數據冗餘備份。經過閱讀了解到了原來每一次網站的升級都是要關閉服務從新部署的，此時的服務器宕機，所以可用性架構設計還要考慮到這一點。

       可是爲了保證數據的高可用，網站一般會犧牲另外一個也很重要的指標：數據一致性。CAP原理是說一個提供數據服務的存儲系統沒法同時知足數據一致性、數據可用性和分區耐受性。須要進行補償和糾錯，避免出現應用系統數據不正確。網站可用性在發佈、監控上也有本身的一些策略。

       網站的伸縮性，每每是和可用性、正確性、性能等耦合在一塊兒。早期是經過物理分離實現，後期在各個層次結構上有不一樣的處理方法要實現網站的可伸縮性，關鍵技術就在於如何構建良好的服務器集羣。要達到良好的目標，就要求每次擴容和減小服務器時，對整個網站的影響是最小的。一個具備良好伸縮性的網站，其設計老是走在業務發展的前面，在業務須要處理更多訪問和處理以前，就已經作好了充分的準備，當業務須要時，只須要增長服務器並簡單部署就能夠了，技術團隊即可輕鬆應對了。

       接下來可擴展架構，一開始在閱讀伸縮性的時候我就把伸縮性理解成了擴展性。不過接下來書中解釋了概念。擴展的一個關鍵就是系統要低耦合，低耦合的模塊更容易複用。如何分解成一個個低耦合的獨立模塊對於架構師來講十分重要。擴展性是隨着需求的變化而變化的。能夠利用分佈式消息隊列下降系統耦合性，如事件驅動架構等。還要有可擴展的數據結構，傳統的關係型數據庫設計不利用擴展，而NoSQL數據庫使用的列族設計便可以作到可擴展的數據結構設計。能夠在數據寫入時再指定，使數據結構能夠隨意擴展。

       針對咱們上學期作的系統，首先咱們系統的易用性就不是很好，界面不夠友好，操做不夠便利。於是要儘可能提升系統的易用性，給用戶良好的人際交互體驗。一部分流程尚未很科學。在可用性方面，因爲目前是本機同時作客戶機和服務器，用戶只有咱們本身而且只有簡單的幾條測試數據，並不會出現故障，但隨着併發度的提升必定會出現許多故障。既然咱們如今不能使用租用服務器等措施，咱們能夠儘可能減輕tomcat服務器的負擔，加快它的響應速度。在數據層，對數據庫進行備份。寫腳本文件時也要儘量優化算法，使算法效率更高。