內容來自阿里雲大學：《阿里專家帶你玩轉DevOps企業最佳實踐》
一、DevOps、微服務與阿里雲容器服務
1、DevOps概念入門
DevOps（Development和Operations的組合詞）
要完成DevOps倡導的理念，不止是一個技術問題，更多的是一個流程、管理、乃至公司架構的問題。
DevOps：“時間”與“質量”
流程化、標准化減少脫節環節時間浪費
節約時間人人有責
自動化降低人工時間消耗
質量的提升可以避免返工
DevOps是為了解決“時間”和“質量”而產生的一種交付文化、流程、交付方式等等的統稱。
DevOps期望通過消除“等待”與“浪費”的方式實現更快速、更高質量的交付。
2、微服務
微服務是由以單一應用程序構成的小服務，微服務之間相互解耦，以全自動的方式部署，與其他服務使用http API通訊。同時服務會使用最小的規模的集中管理（例如docker）能力，服務可以用不同的編程語言與數據庫等元件。
微服務的特性：
服務組件化
按照業務組織團隊
做產品的態度
智能短點與啞管道：服務之間調用的短點可以動態獲取以服務發現的方式提供，對於出錯的場景提供熔斷器。
去中心化治理
去中心化管理數據
基礎設施自動化：自動化部署、自動化交付
容錯設計：組件是不可行的，對於失敗的狀態需要有降級的處理
演進式設計：設計組件的時候需要明確和規划組件的邊界。
微服務的缺點：
將一個大型的系統拆分成微服務設計系統的分布式改造，帶來了技術成本。
更清晰的邊界划分也使得標准化變得困難，微服務依賴上層的框架進行規約。
單體應用內部的通信成本遠低於微服務組件間通信。
管理多個組件或者組件拓撲成為微服務系統的頭等要務。
數據庫的設計與業務規划成為為服務中的難點，對開發者提出更多的要求。
容器如何解決微服務的缺點：
Dockerfile將微服務中語言、框架等的復雜性進行了封裝。
Docker Image將交付最小單元進行了定義，降低了交付復雜性。
Docker的API以及上層的編排系統實現了拓撲的管理。
越來越豐富的容器生態使得微服務不止從交付，更從框架級別進行了支持。
https://github.com/AliyunContainerService/DevOps
二、如何快速高質量的應用容器化遷移
1、容器交付流程
（1）本地開發階段
代碼編寫、測試編寫、容器化測試、Dockerfile編寫、編排模板編寫
（2）持續集成與持續交付
構建代碼、打包構建產物、構建Docker鏡像、推送Docker鏡像、部署編排模板
（3）環境部署
調整應用拓撲、調整接入層配置、調整擴縮容配置
（4）監控、運維與調優
基礎監控資源設置告警、APM監控應用內部指標、安裝調優工具進行調優
2、Dockerfile與Docker Image
Dockerfile的目標是將應用進行抽象打包，通過構建產出的docker image實現標准化交付。
Cloud Foundry將運行的應用分成了OS Image Layer、Runtime Layer、Application Layer三層，認為任何運行時的應用都可以通過這三個維度的抽象進行表達。
Dockerfile語法
ENTRYPOINT是/bin/sh –c來執行的，不是PID1的進程，無法收到SIGTERM。
Docker Image底層實現
聯合文件系統（Union Filesystem）
寫時復制（Copy On Write）
常見的存儲驅動：
AUFS、OverlayFS：基於文件、啟動快、效率稍差
Device Mapper：基於塊設備、啟動慢、效率高
3、高質量的Docker Image構建
（1）減少鏡像的層數，盡量把一些功能上面統一的命令合到一起來做；
（2）助理清理鏡像構建的中間產品，比如一些安裝包在裝完之后就把它刪除；
（3）注意優化網絡請求，應當用一些網絡比較好的開源站點，可以節約時間，減少失敗率；
（4）盡量用構建緩存，盡量把一些不變的東西，或者變得比較少的東西放在前面，因為不變的東西都是可以被緩存的。
（5）多階段進行鏡像構建，明確鏡像制作的目的，將構建與真正的產物做分離，構建就用構建的鏡像去做，最終產物就打最終產物的鏡像。
4、容器編排系統
從設計思路來看kubernetes
面向資源簡化模型（go-restful）：所有在kubernetes中操作的實體都可以用資源進行抽象，所有的資源都有RESTful的API與之對應。
異步動作保證性能（informers）：所有依賴資源的組件都通過異步進行監聽（watch），具體的執行由各自的消費者決定頻度。
狀態機提供狀態基線（etcd）：所有的信息流都通過期望、實施、反饋的機制存儲在etcd中，數據即狀態。
反饋機制保證狀態：informers中可以實現定期的sync，可以通過sync來處理中間狀態。
組件松耦合可插拔：組件之間通信要么是通過APIServer進行中轉，要么是通過APIGroup進行解耦，組件之間沒有強依賴關系，部分組件自帶熔斷器。
Tips：
Kompose：http://kompose.io，swarm向k8s遷移的一個工具。
Podman：Podman 是一個開源的容器運行時項目，可在大多數 Linux 平台上使用。Podman 提供與 Docker 非常相似的功能。正如前面提到的那樣，它不需要在你的系統上運行任何守護進程，並且它也可以在沒有 root 權限的情況下運行。Podman 可以管理和運行任何符合 OCI（Open Container Initiative）規范的容器和容器鏡像。Podman 提供了一個與 Docker 兼容的命令行前端來管理 Docker 鏡像。
容器遷移工具：Derrick
三、從零搭建CICD系統標准化交付流程
1、CICD基本概念
持續集成（Continuous Integration，CI）：是一種軟件項目管理方法，依據資產庫（源碼、類庫等）的變更自動完成編譯、測試、部署和反饋。要求：自動構建，自動檢測變更，反饋機制，純凈的構建環境等。
持續交付（Continuous Delivery，CD）：頻繁的將軟件的新版本，交付給質量團隊或者用戶，以供評審盡早發現生產環境中存在的問題。
持續部署（Continuous Deployment，CD）：是代碼盡快向可運行的開發/測試交付，以便盡早測試；是持續交付的下一步，指的是代碼通過評審以后，自動部署到生產環境。
Jenkins：
Master提供web讓用戶來管理job和slave，job可以運行在master本機或者被分配到slave上運行。一個master可以關聯多個slave用來為不同的job或相同的job的不同配置來服務。
搭建Jenkins系統：
docker環境准備 –> 啟動Jenkins Master容器 –> 安裝插件 –> 配置構建節點 –> 運行第一個項目
# docker run -d -it -p 8080:8080 -p 50000:50000 –v /var/jenkins_home:/var/jenkins_home -v /var/run/docker.sock:/var/run/docker.sock -name jenkins-master jenkinsci/blueocean
配置構建節點：
運行構建節點，ssh端口映射
系統管理 – 管理節點 - 新建節點（通過ssh連接jenkins master）
插件的安裝是要Jenkins master重啟之后才會生效。
CICD系統：
Jenkins master容災
Jenkins slave節點規划和鏡像制作
插件管理
訪問權限配置
源碼管理、觸發器、構建結果通知等
日常運維：數據清理、備份
組件更新升級
安全漏洞修補
阿里雲CodePipeline是兼容Jenkins標准的、提供快速可靠的持續集成與持續交付服務。基於容器技術和阿里雲基礎服務架構，提供穩定和安全的代碼/Docker編譯構建，測試，掃描和部署的工具服務，並提供Pipeline As Code的編碼級配置模式，滿足應用程序和基礎設施快速可靠的交付和更新。
四、雲原生容器應用交付的設計與實踐
雲原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和聲明式API。
五、多種發布模式實現容器化交付
容器的網絡模型：單機網絡模型、跨主機網絡模型、
vpc網絡：L3 Flat，指各個host中所有的容器都在virtual+physical網絡中可路由，且路由以/32位的形式存在，使得容器在host間遷移時不需要改變ip地址。性能優於overlay網絡，不需要ARP廣播尋址，不需要封解包。
經典網絡：overlay網絡，需要通過ARP廣播尋址。
常見的發布策略有藍綠發布、金絲雀發布（灰度發布）、ABTest。
藍綠發布：在發布的過程中用戶無感知服務的重啟，通常情況下是通過新舊版本並存的方式實現，也就是說在發布的流程中，新的版本和舊的版本是相互熱備的，是通過切換路由權重的方式（非0即100）實現不同應用的上線或者下線。藍綠發布適合絕大多數的應用場景的發布，能夠零宕機更新，缺點是發布時資源消耗大。
金絲雀發布：通過在線上運行的服務中，新加入少量的新版本的服務，然后從這少量的新版中快速獲得反饋，根據反饋決定最后的交付形態。金絲雀發布主要面向的場景是功能兼容的新版本驗證，可以用最小的代價實現功能驗證，且保證主體流量不受影響，缺思安是面向場景比較單一，對於開發者要求較高。
灰度發布：是通過切換線上並存版本之間的路由權重，逐步從一個版本切換為另一個版本的過程。
A/BTest：和灰度發布非常像，ABTest側重的是從A版本或者B版本之間的差異，並根據這個結果進行決策，最終選擇一個版本進行部署。因此和灰度發布相比，ABTest更傾向於去決策，和金絲雀發布相比，ABTest在權重和流量的切換上更靈活。
六、開源框架與阿里雲容器服務集成
工具鏈：
Derrick：構建Dockerfile的自動化工具
Kompose：docker swarm資源轉換為kubernetes資源
helm：kubernetes的包管理器，相當於centos的yum。
微服務示例：
eureka-server：incubator/ack-springcloud-eureka
demo：https://github.com/AliyunContainerService/spring-cloud-k8s-sample
服務發現的一個問題：集群內的一個應用將自己注冊到集群外的一個注冊中心（注冊的IP是Pod IP），集群外的另一個應用從注冊中心獲取到這個應用的IP，但實際上集群外的應用是訪問不到pod IP的。
解決方案：
網絡配置：
Host Network
設置容器地址段到主機地址段
把外部的ECS納入kubernetes管理，不運行Pod
https://developer.aliyun.com/article/603633
框架層面解決：
dubbo（在k8s中的應用：設置注冊的ip和端口為對應service的外網訪問ip和端口）、
Spring Cloud（注冊hostname為service url）
Service Mesh：sidecar模式，不是簡單的sidecar去接管單個的容器，而是容器服務之間的通信形成的網絡的管理架構，上面加上control plane，形成一個控制平面，下面的服務通信形成數據平面。通過控制平面來控制數據平面之間的服務相互的連接關系，可以做服務路由之類的管理工作。
Istio：
七、容器化應用性能測試與調優
1、性能測試的常用方法
負載測試：負載測試時用戶觀點的測試行為。負載測試就是讓系統在一定的負載壓力下進行正常的工作，觀察系統的表現是否滿足用戶的需求。
壓力測試：通過對系統的極端加壓，從而觀察系統的所表現出來的性能問題。
並發測試：驗證系統的並發能力。通過一定的並發量管擦系統在該並發量的情況下所表現出來的行為特征，確定系統是否滿足設計的並發需要。並發測試是系統觀點的測試行為。
基准測試：基准測試要有一個基准點。當軟件系統中增加一個新的模塊的時候，需要做基准測試，以判斷新模塊對整個軟件系統的性能影響。
穩定性測試：長時間的負載測試，確定系統的穩定性。
可恢復性測試：測試系統能否快速地從錯誤狀態中恢復到正常狀態。
全鏈路測試：包含系統上下游的全鏈路壓力測試與穩定性測試方式，通過模擬近似真實的用戶流量和用戶行為來仿真線上流量。
2、性能測試與調優的主要對象
程序瓶頸：
使用的I/O模型、是否能夠使用多核處理器、部署的方式與資源分配
網絡瓶頸：
網絡模型與協議、網絡防火牆設置、內核態與用戶態切換
內核瓶頸：
內核參數調優、內核模塊開啟與加載、內核版本與性能
系統瓶頸：
不同操作系統對特定場景存在先天缺欠。
硬件瓶頸：
磁盤、網絡設備、CPU
3、容器性能測試與調優的步驟
（1） 收集信息整理架構
收集的信息：應用的拓撲關系、使用的框架語言以及相應的版本、接入層的配置與鏈路、使用的網絡模型、容器的分布、出現問題時的現象與場景，每一個鏈路的流量情況，先排查各種泄漏的問題
目標：通過信息的手機，能夠在白板上重構出應用的拓撲關系、預估流量的量級以及目前來看異常的問題鏈路。
（2） 提出懷疑點指定測試方案
（3） 選擇測試方法與工具集合
（4） 完整進行執行測試方案
（5） 結果比對修正方案
4、工具
壓測工具：wrk、PTS
資源概覽工具：Ctop（容器層級間監控進程，實時監控的指標）、Htop
CPU Memory性能工具：Perf、strace根據syscall的跟蹤來統計的。
磁盤性能：iotop、iosnoop
網絡性能：sar、netstat（ss）
網絡診斷：tcpdump、wireshark
sysdig = strace + tcpdump + lsof + htop + iftop等工具的合集
snout：主動的性能調優診斷工具
八、容器化應用問題診斷、監控與運維
節點相關的問題：master宕機、worker節點宕機
etcd穩定性問題：
網絡鏈路：
pod問題：
