樂添：很高興有這個機會跟大家交流阿里巴巴在云計算的探索，部署的過程中跟服務器、軟硬件相關的嘗試摸索。介紹一下服務器開發、驗證、軟硬件優化過程中我們遇到的一些事情。先做個廣告，最近一個里程碑事件，對于阿里云來說，付費的用戶數量首次超過100萬，對阿里是個比較大的事情，這是亞洲首家超過100萬用戶的云計算公司。

簡單回顧一下云計算業務的發展以及這些發展對于基礎設施服務器、網絡、存儲的新要求，技術方面大家比較熟悉了，這里舉的一個例子是網站的業務發展的過程，最開始如果我們要做一個網站的話，簡單來說需要有一臺或者幾臺服務器的主機。隨著我業務規模的擴大，我需要把我的數據庫獨立出來，同時如果服務器數量越來越多，可能要考慮負載均衡，如果數據庫的業務獨立出來之后還要考慮緩存的事情，要考慮數據庫的安全性、可靠性。如果我的業務數據繼續增加，對于數據的存儲有新的要求，需要有獨立的存儲技術，包括分布式存儲、針對某些特定應用的結構化的存儲。隨著我的業務的規模越來越大，我可能要擴展到全國對于全球，對網絡會提出一些新的要求，比如為了更好的客戶體驗，降低成本，需要內容分發網絡。隨著數據進一步增加，最后還需要有處理大數據的專用的業務。

在業務發展的過程中，不同的應用對于基礎設施服務器來說會提出不同的要求，比如有些對成本特別敏感的業務，對于數據庫的業務，對于性能要求是多少，彈性存儲的各種業務，對于可靠性要求是多少，海量的服務器在數據中心運維的要求是什么樣的。都在我們設計服務器開發驗證流程中提出各式各樣的要求。對于服務器的實現來說，在具體的配置上我們會有不同的具體配置，偏重主頻的、大IO的、大容量存儲的、高內存的，這幾年又發展出很多新的異構計算的加速計算的。

舉一個例子，以計算和存儲來說，IT技術發展過程中計算和存儲一直是分分合合的，2007、2008年左右做云計算的時候一個比較主要的共識或者當時主流的做法就是需要本地化，計算的資源和存儲的資源盡可能靠近，盡可能減少獲取數據的成本，很多時候會把計算和存儲做在一個物理上本地化的資源池或者盒子里，同時盡可能的把計算和存儲的能力同時都往最大的方向做。當時很多業務的架構，用單一的集群大容量存儲加上高性能計算可以滿足很多當時業務的需求，隨著接下來幾年行業的發展，特別是北美互聯網行業的發展下面，因為計算技術的發展、存儲技術的發展，NVMe，網絡技術的發展，數據獲取的成本大幅度降低，現在比較主流的是計算和存儲分離的架構。傳統的集中式的存儲都是在主機里面，通過共享的交換機連到其他遠端的服務器上去，大部分數據的處理和備份都在同一個交換機下面完成。計算資源在物理上集中的放在某些機架位上，通過特定的交換機連到遠端的存儲資源上。在這些架構變化方面我們會遇到各種各樣的問題，各種各樣的挑戰，其中有一個印象比較深的是在最早嘗試這樣架構的時候，我們在不同的物理機架位上我們放的是計算資源比較集中，我們典型的業務部署上去的時候發現存儲節點的交換機的帶寬很容易被打滿，丟包率和重傳率都非常高，因為我們的業務對于同一份數據會有多份副本拷貝的設計，在新的架構下面，在副本拷貝的過程中會發生比以往多的多的拷貝的失敗，會重新發起副本的重傳，這樣會進一步加劇網絡上帶寬的浪費，因為有更多的包會倍發出來，又有更多的包被丟掉。

遇到這樣問題的時候，我們現在有幾個不同嘗試的解決方法，比如我在交換機這一側可以選用我的端口的buffer，更大的交換機直接換硬件。這個會帶來硬件上的變化和成本上的變化。還有一個嘗試，我們嘗試把一定比例的存儲節點和計算節點在同一個機架位上混合部署，臺灣代理服務器 韓國服務器，通過和實際的應用業務做聯合的調試，比如以四個計算節點配一個存儲節點的比例來部署的時候，以八個計算節點配一個存儲節點的比例，在不同的比例加上業務實際的部署情況下，可以逐步降低重傳率提高業務的效率，這是優化前和優化后的重傳率的數據的對比。另外一個遇到的問題是配置分布式存儲之后，在磁盤的吞吐率上面我們發現進行大文件大壓力寫的時候磁盤吞吐率達不到預期，大量內存回收操作，cgroup內存策略，鄭州電信服務器 服務器托管，夠用就行，內存策略調整，釋放性能，優化成本。存儲節點里因為可以調整內存上限，可以得到在系統架構下面最大的需要內存的物理空間的值，針對具體的存儲節點做內存的優化，比如最早我們給某個節點做系統架構的時候選了512G的內存，優化下來發現源源不需要這么多內存就能讓它達到原來預定的磁盤的性能，這樣可以節省一大筆內存的成本。