總體思考

總結這些年經驗，進行構架演進的方向選擇時，大致要做到下面的目標：

• 可快速開發部署 （五分鐘寫出來一個經過測試的hello world并可訪問/調用，并可在公網訪問）
• 天然可擴展（業務層無狀態，盡可能全部放到***）
• 自動化（內存不足了，除了報警，應該自動加點機器進去; 新的項目，基礎代碼應該都不用寫，自動生成即可）
• 框架化（公共層面的東西盡可能框架化，一層類似日志、counter、trace，應該不需要開發再寫一行代碼即默認打開）
• 量化（所有的調用都應該有percentile與rps，透明反饋服務質量，跟蹤系統更是可以模擬用戶進行系統內部）
• 同構化（因為搞兩套的成本巨大，整體應該越來越趨同于同一種語言）
• 硬件虛擬化（整個平臺應該對進程透明下面的硬件情況）
• 版本化、灰度化（所有的軟件都應該在線上有明確的版本，且上線過程是一點點灰度上）

上圖純手繪花了些時間，本文以此圖從上到下的順序進行描述。

用戶

在移動互聯網環境下，用戶會被分為好網絡的用戶和壞網絡的用戶，我們要為壞網絡的用戶盡一切可能提供合適的鏈路和可靠的DNS。

接入層

在接入層的代碼層面，需要準備client-server套件，這意味著，需要一個同時了解android\ios..等客戶端和服務器端開發的團隊，專門打造網絡套件。

• 這一層的目標是，讓客戶端開發人員不再關心網絡協議的問題。

業務接入層

這一層的目標是靈通機動調配流量，往往大家的方案都是LVS，或者是F5等。更高大上一點，再上一些流量分析設備，在有突增的時候好用來找問題。

業務層

在統一的業務框架下，去完成各個靈活組織的BIZ邏輯，這里就涉及到異構系統對一個大型公司的影響。

• 如果80％的人都在使用java的活，還是趁早全用java，因為意味著剩下20％用其他語言的同學，有可能要把這80％的同學做的基礎全部實現一遍。
• 異構必然會導致某些模塊不能***工作，比如后續的RPC、配置管理、監控報警、跟蹤系統等等。

RPC框架與隊列

二者一起完成數據在IDC的傳遞，不同在于，一個是同步，一個是異步。

• 統一的RPC框架好處不必言說。

配置管理

zookeeper當選***角色，上點規模的服務里基本都會有zk的身影。

日志系統

統一的日志系統，對未來發展中所需要的各種數據更加容易得到。日志系統的特點要求：快，容網絡錯誤，部署簡單，進程穩定，可水平擴展。

• scribe與kafka都是不錯的選擇。
• 這里最終的日志，可能會需要放到hdfs或者是hbase里進行hive查詢，否則數據量大了之后要想把日志用起來很不容易。

監控報警系統

ganglia與nagios仍舊是***用的開源管理軟件。

• 需要考慮的是，要將在業務框架里默認記錄的公共的perfcounter進行監控與報警。

跟蹤系統

當系統出現bug的時候，用來快速debug，當服務越來越多的時候，跟蹤系統是個必不可少的工具。

• twitter的zipkin是個不錯的開源的實現，不過要使用到自家的代碼里來，可能要加工一下。

PAAS Agent Daemon

整體統一的運維平臺的客戶端程序，此程序負責:向監控系統匯報硬件及網絡數據，啟動和停止應用程序，向監控系統和PAAS平臺傳遞應用程序的運行狀態。

存儲平臺

此層包括所有重狀態的hosting service。

• memcached cluster，使用統一的一致性hash客戶端，所有的緩存服務器進行統一管理，計算命中率、使用率，實時添加內存。
• DBMS cluster，使用統一的數據庫分庫分表層，動態地感知和切換故障。常見的項目如mysqlproxy，變形蟲。
• HBase cluster，獨立的存儲可用性保障，本身也是設計為高可用性的集群。

PAAS 資源控制層

目標是實時反饋整個或多個IDC內部的內存還有多少、CPU是否夠用、下次采購還需要多少機器。

• 虛擬化是個重點難題。常見開源軟件：docker、warden、LXC。
• 資源控制CPU可用cgroups，磁盤可用aufs等，一般的虛擬化方案中都已經包括這幾項解決辦法。

PAAS用戶界面層

這一層主要面向運維和開發人員，比如用來上線服務、添加刪除機器。

• 除了web界面，還應該有cli模式的支持。

自動部署層

一般都以hudson的CI（持續構建）完成之后進行，但可自動化的部署一定需要測試框架非常靠譜，以及測試代碼靠譜，否則就是個悲劇。

測試框架

借用一些高級框架，讓代碼寫少一點，比如jmockit、spring-test等等。

編譯工具

java的maven為不二選擇。編譯好的包倉庫，推薦nexus。

代碼生成

開發人員不需要重復進行操作，只要框架是固定的，所有的代碼應該都是可以生成的。只需要花精力去修改核心邏輯。

• 這里比較抽象，可以用的辦法比如做一個maven-plugin，讓全部工程師都會用。
• 不斷地去升級這個工具，使其包括更多的可能的代碼方式。

代碼質量

在工程師的代碼完成之后，跑一遍靜態分析，可以提前發現一些問題，可以做成定期的模式，與持續集成放在一起。

• 推薦hudson + maven + sonar三劍合一。

代碼及常規系統

• 代碼托管：gitlab是一個不錯的類似github（越來越像了）的工具。
• codereview：可直接使用gitlab的merge request，也可以使用開源的reviewboard。
• 知識管理：沒什么好說的，mediawiki。
• 需求與bug：jira。
• 故障管理：這個沒有開源項目，post-mortem system，是一種記錄故障原因的系統，下一次故障來臨的時候，來這個系統里進行問卷式的調查和反思。

PAAS for DEV & TEST

• 開發階段需要之前提到的cli可發布到自己的開發機（這里還需要PAAS可很容易地開一個新的開發機）的工具。
• 測試階段需要比開發階段更加高可用性的環境，而且要時刻提升基礎工具的可靠性，不應該讓開發環境在發展中消失，反而用測試環境來當作開發環境，現實中發生此類事件的原因，都是部署沒有做到***。

原文鏈接：http://2014.54chen.com/