基于CloudFoundry的私有云平臺內容背景與目標實踐與改造（Part

1、2）流程與標準改變運維未來計劃1.背景與目標運維與PaaSStorageServersNetworkingO/SMiddlewareVirtualizationDataApplicationsRuntimeOP(SRE)，運維PaaS

(and

IaaS)目標自動化業務的生命周期管理，如變更、監控、故障處理等資源利用率、彈性標準化流程實例標準系統環境、runtime、framework一體化集成第三方服務，如DB、Cache、log、FS等與其他系統平臺聯動WhyCloudFoundry？自動化標準化一體化機器管理（下游部門）自動化一體化標準化WhyCF？自動化一體化標準化2.實踐與改造（Part1）Java，base

on

cf

1.0Java

Apps產品種類>100APP

>200實例>2000平均單實例10G（內存）日均總pv>

10億APP的開發及測試人員>

700人Tomcat5/6/7、jdk1.5/1.6、Standalone

開始實施，準備工作基于CentOS的相關改造獨立部署各個CF組件拆解BOSH、chef，基于物理機實施OS環境初始化apt-get改為yumUbuntu-cmdtoCentOSDEA(v1.0)，agent.rb、secure.rbyuminstall-ymakegccgcc-c++kernel-devel.x86_64openssl-devel.x86_64libxml2.x86_64libxml2-devel.x86_64libxslt.x86_64libxslt-devel.x86_64git.x86_64sqlite.x86_64ruby-sqlite3.x86_64sqlite-devel.x86_64unzip.x86_64zip.x86_64ruby-devel.x86_64ruby-mysql.x86_64mysql-devel.x86_64curl-devel.x86_64postgresql-libs.x86_64postgresql-devel.x86_64zlib-devel.x86_64readline-devel.x86_64ImageMagick.x86_64ImageMagick-devel.x86_64php-magickwand.x86_64集群容量評估實例數量，NATS容量評估單臺DEA承載的實例數（<100），對NATS-Server壓力影響不大單NATS-Server，保守估計可承受330臺DEA，單臺實例數5~30個多NATS-Server，可擴展延時（ms）DEA臺數（10

~

340臺）單DEA實例數（5

~

30個）臨界線330臺DEA集群內，組件冗余、LB設計NATS使用cluster版，多NATS，心跳同步Client端緩存信息，如果網絡中斷，則不斷reconnect多NATS負載均衡（Client>

0.5.beta.6）NATS-Server1NATS-Server2NATS-Client(cachingmessage)NATS-Server1/2,Randomlist多集群冗余設計多個獨立的集群，邏輯互不影響第一層切換，修改DNS

A記錄，對多個域名（CNAME到此A記錄），統一切到不同的集群第二層切換，修改“接入層”（其應用層的功能，可簡單理解為nginx的反向代理）保證好APP（無狀態）的容量，或快速擴容的預案，以防止流量切過來以后，出現過載Baidu

GateWayFront

EndRouterA記錄Baidu

GateWayFront

EndRouterapp1app1CNAME（正式域名）CNAME（正式域名）

CNAME

.

www.

CNAME

.

.

A

7

.

A

6核心組件，分布Router_1NATS_1RouterNATSCCHMStagerDEAPG_DBRedis整體結構（cf1.0）DEALoggingName

ServiceMonitoringjvmStagerFilePersistenceHMRouterCCBaidu

GateWay/Front

EndjvmjvmAPI

BridgeUAAjvmjvmjvmjvmjvmRouter（Cluster02）NATSDB新增功能支持RPC、單實例多端口單實例開啟多個端口，并提供API實時查詢IP、端口號與“名稱服務”聯動，同步動態ip端口與名稱的對應關系RPC調用方，根據名稱直連實例DEA

server支持RPC、單實例多端口Instance01:portInstance02:portAPI

Bridge

NS

serverTXT記錄ip:portip:portRPC調用方NS

clientDomain

ip:port

ip:portip_local_port_range10000~

60000Port池（分配后，有凍結期）61000~

65000新增功能支持JMXAPI實時查詢ip與Jconsole端口號，實現JMX數據實時采集DEA支持JMX

Instance01:

Jconsole端口Instance02:

Jconsole端口{"instances":[{"index":0,"state":"RUNNING","since":438249600,"jconsole_ip":"","jconsole_port":61111},{"index":1,"state":"RUNNING","since":438249600,"jconsole_ip":"","jconsole_port":62222}MonitoringMetricsCpuUseRateDaemonThreadCountMemPool_OldGen_UseRateNonHeapMemoryUsage_usedTotalCompilationTimeTotalPeakThreadCountTotalStartedThreadCountUnloadedClassCountGC_Major_FrequencyGC_Major_Time……Stager：java

\-Dcom.sun.management.jmxremote.port={VCAP_JCONSOLE_PORT}-Dcom.sun.management.jmxremote.authenticate=false-Dcom.sun.management.jmxremote.ssl=false新增功能加強健康檢查七層檢測文件句柄數檢測DEA

ServerDEA

agent.rbHealthMangerinstancehttp可用性instanceCPUMEMDISK……report加強健康檢查

句柄DEA(v1.0)，邏輯改進端口管理問題描述單DEA多實例，并行的端口分配與啟動，沒有臨界區，有端口競爭的問題解決方案借鑒了DEA(v2.0)的邏輯（注：即DEA_NG，與CF1.0不兼容）設定ip_local_port_range為10000~61000，作為動態端口的范圍將61001~65000，作為DEA的調度分配端口對分配的端口，增加“[釋放時間、端口號]”的數據結構通過延時釋放端口，解決了端口競爭的問題備注CF2.0中，已解決此問題，方法同上DEA(v1.0)，邏輯改進實例資源信息管理問題描述du命令算實例磁盤空間，時間較長，隨后執行其他計算命令，信息已不一致CPU計算的方法，沒有考慮主機核數解決方案調整相關命令的順序CPU利用率計算時，除以核數備注CF2.0中，已解決此問題新增功能（與外圍系統聯動）文件持久化使用MFS（MooseFileSystem）DEA部署MFS-Client，并mount

/mfs/path，供實例使用MFS服務端提供HTTP接口，獲取數據基于URI的路由，區分APPf/app1

app1.foo./app2

app2.監控聯動APP的生命周期，與外部監控系統的API交互，實現監控項的自動增刪改開發者工具包自動化發布（封裝vmc）文件查看主要改造點匯總（cf

v1.0）基于CentOS的相關改造使用NATS-Cluster、NATS-Client重試與緩存支持RPC、單實例多端口支持動態JMX、Jconsole加強健康檢查端口管理實例資源信息管理外圍組件：文件持久化、監控聯動、URI路由、開發者工具包2.實踐與改造（Part2）C/C++，base

on

cf

2.0C/C++

Apps，幾大核心問題Container的運行環境與資源隔離Kernel/GNU資源隔離快照，Core

Dump單實例多進程健康檢查進程運行順序實例內，進程間通信多端口多實例的同構性C/C++

Apps，幾大核心問題大實例實例個數多（10萬）數據量大（單實例，2TB）內存占用高（單實例，100G）啟動時間長（30分鐘）流量大（單實例，日總PV2億）漂移時，防止資源不足APP通信網絡層通信，權限、流量控制輸出文件，需要外部抓取輸入文件，需要外部推送RPC，非HTTP協議，不包含PATH信息，無法路由實例的OS-Level環境準備Container的運行環境Kernel與宿主機一致訂制Container的文件環境warden/warden/root/linux/rootfs/setup.shifgrep-q-icentos/etc/issuethen

exec$(dirname$0)/centos.sh$@fiContainer與宿主機的關系WardenNetworking，Bridge/NAT/Firewall/FlowControlDEAinit─┬─xxx├─xxx─xxx├─xxxmountrusr/lib/etc/mountrwxxx/networkinterface（subnet）Cgroup–CPU/MEMNamespaceinit─┬─xxx├─xxx─xxx├─xxxmountrusr/lib/etc/mountrwxxx/networkinterface（subnet）Cgroup–CPU/MEMNamespace包管理BuildpackAPIdetect

，檢查complie，環境準備目錄結構程序文件，及相關配套程序啟動腳本，保證進程的啟動順序，等等監控腳本，可以周期性執行，檢測整個實例的健康程度release，發布信息Procfile，參數傳遞（如端口號）.profile.d，環境變量健康檢查，改造點自定義監控腳本自定義監控腳本，隨實例一起發布，周期性改寫stat_file文件內容DEA定期檢查stat_file文件實例stat_filemonitor.shprocess-1process-2DEAHMAPP的改造針對RPC，支持NS

Client動態配置文件，代替路由端口管理，凍結時間輸入輸出文件輸入文件，主動抓取輸出文件，推到中轉處（如云存儲），或基于NS服務多進程的管理，啟動腳本多進程，啟動順序控制進程控制文件持久化遠程日志使用云存儲整體結構（CF2.0）DEALoggingName

ServiceMonitoringFilePersistenceHMgorouter（RPC，不適用）CCBaidu

GateWay/Front

EndAPI

BridgeUAA（Cluster02）NATSContainerprocess-1process-2WardenNSClientContainerprocess-1process-2Containerprocess-1process-2DB主要改造點匯總（cf

v2.0）基于CentOS的相關改造Container環境的訂制Buildpack的訂制支持RPC、單實例多端口加強健康檢查外圍組件：文件持久化、監控聯動、URI路由、開發者工具包3.流程與標準工作流程，簡述評審標準容量SLA接入組織關系名稱信息運維信息流程審批權限申請名稱申請發布操作發布更新預發布灰度回滾故障處理可用性安全問題管理標準與容量，舉例標準信息采集App相關名稱、相關接口人（R&D、QA、運維、相關經理，等）Runtime與容器版本無狀態、RPC、URI路由動靜態文件分離文件持久化容量信息采集PV、QPS單實例CPU、內存、磁盤、帶寬、重啟時間實例數量SLA，舉例服務對象Java應用（以下簡稱“APP”）符合標準的APP服務時間24×365全年無休溝通方式Mail、Tel、接口人信息穩定性相關指標核心組件，可用性>99.99%（每月），MTTR<20分鐘，MTBF>5天控制服務，可用性>99.95%（全年）APP自身SLA，不因平臺本身，造成負面影響

注：APP自身問題，不在此SLA范圍內，如：

程序bug、容量預估錯誤、外部系統故障（如DB、Cache）等組織關系，層級產品線（Org）模塊（Space）分組（APP）版本（APP-*）

產品線-2產品線-1

（Org）模塊-2模塊-1（Space）分組-1（A）分組-2（B）實例，版本-1（APP-1-1）實例，版本-2（APP-1-2）實例，版本-1（APP-2-1）實例，版本-2（APP-2-2）實例，版本-1（A-1）實例，版本-2（A-2）實例，版本-1（B-1）實例，版本-2（B-2）虛線內，相當于一個APP，且有多個實例對CC進一步封裝產品線(Org) OrgName 模塊(Space) OrgName_SpaceName模塊分組

OrgName_SpaceName_GroupTag模塊版本

OrgName_SpaceName_GroupTag_VersionTag實例（id唯一）

OrgName_SpaceName_GroupTag_VersionTag_IndexGroupTag、VersionTagGroupTag可以區分：配置文件、機房、機架等維度的不同VersionTag可以區分：程序、數據、配置文件等包含：四位版本號、時間戳實例完整名稱，例子Org_Space_GroupA_1-1-1-1-438249600_1Org_Space_GroupB_1-1-1-1-438249600_1審批與發布發審批單APP信息（程序版本、容量信息、相關說明，等等）審批人（相關經理、需知曉的人）操作者、操作時間監控信息（監控策略、接口人等）開始發布操作，并添加監控發布前，對應審批流必須通過操作人、程序版本、MD5、時間等信息，必須與審批流一致都一致，且流程通過，則可以開始發布發布成功后，添加監控發單審批發布APP監控添加預發布、發布、回滾app_v1instance01app_v1.app_v1instance02app_v2instance01app_v2instance02app_v3instance01app_v3instance02app_v3.app.泛域名、map/unmap、app的多版本并存前進，發布后退，回滾預發布，線下內網觀察基本的灰度發布app_v1instance01app_v1.app_v1instance02app_v2instance01app_v2instance02app_v3instance01app_v3instance02app.1、將一個正式域名，同時指向多個app2、調整多個app的實例數比例，即調整了流量的比例app.app_v2instance03通過調整app實例的數量，灰度流量的分配比例“布道之道”，平臺的推廣軍功章，有誰的一半？APP的支持新服務，需遵守PaaS的相關標準、思想老服務，需R&D改造，QA需回歸測試外圍的支持DB、Cache、存儲、接入、安全、監控，等等明確收益，建立共贏的生態圈交付更快、資源更省、事情變得簡單一站式的一體化服務，攜手推廣一些方法給用戶（APP開發人員），尊貴的帝王般的享受對重點的APP，有針對性的重點服務對重要