聲明：本文作者爲edwin1986，上汽通用汽車 系統架構師。本文已獲得授權轉載。
一. 前言
眼下大部分車企都承擔着自主品牌汽車的研發、製造與銷售，在“電動化、網聯化、智能化、共享化”的“新四化”趨勢下，車企IT平臺積極向互聯網架構轉型，推出了IaaS、PaaS、SaaS服務，適應多元的系統架構以及微服務的開發方式。其中，基於Docker容器技術的PaaS雲平臺，其建設目標是給企業內部以及合作供應商的開發人員提供一套服務快速開發、部署、運維管理、持續集成、持續部署的平臺。平臺提供應用運行時、中間件、數據庫、信息安全及人工智能等PaaS資源，以及創新性地將公有云PaaS服務資源通過封裝API實現私有云快速調用。讓開發人員在構建應用過程中，真正實現秒級接入，彈性擴縮，一鍵部署，資源最大化利用。 車聯網TSP平臺承載了車輛數據收集和車輛指令下發的重要功能，通過PaaS平臺可以解決車輛數據的穩定併發問題，保證車輛數據不堵塞，不丟失。
車企PaaS平臺，承載了企業協同平臺、B2B、B2C、智能製造等多領域應用，在PaaS平臺構建與應用落地推廣時，我們發現，對於傳統車企數字化轉型的的過程中，面對從傳統巨石到模塊化到微服務的各種架構的應用接入需求，對平臺的穩定性、靈活性提出很高要求。因此，在平臺構建時，不僅需要滿足新框架的快速對接，在暫時無法重構的情況下，老框架的應用也可以通過適當改造接入PaaS服務，以適應業務快速的發展需求。並且，我們還在積極探索kubernetes技術，以及貫徹DevOps理念，提高開發效率，解放運維雙手。在此需要和同行多進行溝通，吸取這方面的經驗。
爲了幫助大家瞭解如何基於車聯網應用場景架構設計PaaS平臺以實現DevOps同行技術探討，社區特別組織了本次交流活動，請大家一起交流探討。活動中，大家踊躍發言和積極答疑，提出了許多真知灼見。爲了更好、更方便的讓大家瞭解到本次交流活動的乾貨，更好地進行PaaS項目建設，在此我將本次活動的問題和解答進行了總結，如有不妥之處，還請諒解。
二. 基於車聯網應用場景架構設計PaaS平臺以實現DevOps同行技術探討在線答疑
1. PaaS技術
Q：PaaS中如何實現服務註冊和服務發現？
ASIS： 目前主流開源的服務發現框架包括spring cloud相關、dubbo等。K8S平臺運行在其之下，若整合需要定製開發。PCF源生支持Spring Cloud體系。 對於服務發現本身而言k8s使用了服務器端的HA和服務發現而非spring等通過客戶端實現的服務發現，這是兩種模型。前者通過應用層實現：如springcloud。springcloud中的eureka組件可以向各個微服務提供註冊和服務發現的功能。後者在系統層實現：K8S/OpenShift本身自帶服務發現機制，其通過DNS域名解析來實現。 TOBE： istio等service mesh是一個方向
Q：如何基於PaaS平臺構建上層服務？
用戶可以根據需求，可以自行定製構建特定的上層服務。除了上面提到的兩種途徑外，用戶還可以通過使用RedHat開源的Operator Framework項目進行快速定製化開發。
1.CRD (CustomResourceDefinitions) 用戶通過使用CRD將定製資源添加的K8S/OpenShift集羣中，擴展K8S/OpenShift API。CRD僅定義了某種類型的資源對象，而該資源對象的控制器，則需要用戶自行定製開發。 CRD用法可參考：https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/ CRD開發工具框架：https://github.com/kubernetes-sigs/kubebuilder
2.Service Catalog openshift目前支持兩種service broker： - template service broker - ansible service broker 用戶也可以根據需要定製自己的service broker，目前社區提供Open Service Broker API：https://github.com/openservicebrokerapi/servicebroker
3.Operator Framework Operator利用K8S/OpenShift的擴展性來進一步增強雲服務的運維自動化能力，如創建、伸縮、備份與恢復等。根據OpenShift Roadmap中的規劃，18年下半年將會推出etcd/prometheus/Vault Operator. https://github.com/operator-framework/operator-sdk
Q：paas如何實現自動擴容？
不同paas會有不同的實現方式，k8s的實現可以參考 水平擴展參考：https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/ 垂直擴展參考：https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#known-limitations-of-the-alpha-version Cluster Auto Scaling 需要依賴下層基礎IaaS實現，可參考： https://cloud.google.com/kubernetes-engine/docs/concepts/cluster-autoscaler
Q：gfs和ceph或者其它的， 哪種比較適合容器的數據落地？
如果建設初期，建議使用主機儲存和NFS之類的傳統網絡儲存：前者滿足高IO需求，後者滿足低IO需求 K8S持久化卷的支持情況可以參考K8S官網：https://kubernetes.io/docs/concepts/storage/persistent-volumes/ 多種持久存儲使用示例，可以參考OpenShift的官方使用教程： https://docs.openshift.com/container-platform/3.10/install_config/persistent_storage/index.html
從存儲選型角度來看，建議用戶結合具體的使用場景進行測試，以驗證是否滿足自身的應用場景需求。 RedHat也推出CNS(Container Native Storage, 容器原生存儲)方案,詳細內容可以參考：https://access.redhat.com/documentation/en-us/red_hat_gluster_storage/3.3/html/container-native_storage_for_openshift_container_platform/index
Q：在雲架構中 OLAP和OLTP的架構如何建立？
OLAP 能很好的契合雲平臺，因爲 AP 是計算密集性場景，例如使用 Spark 及一些其它 SQL 引擎去做一些 SQL 計算，這類場景特別適合雲，特別容器雲，對計算資源的更細粒度化，能靈活的彈性擴展，這都是 OLAP 場景所需。 雲架構處理 TP，這中 IO 密集型的場景，我建議從以下兩個層面去考量： 1) 採用新的持久化產品或架構，例如文件數據庫，例如 Couchbase, MongoDB，及一些 In-memory 的方案，例如 Redis 等 2) 採用互聯網一些技術，例如使用消息中間件，去保證數據原子性等。
Q：車聯網通訊協議的選擇？MQTT與HTTPS的優劣勢？從未來發展，哪種協議更適合車聯網構建？
MQTT 和物聯網 (IoT) 聯繫在一起，MQTT（消息隊列遙測傳輸） 是基於 TCP/IP 協議棧而構建的，已成爲 IoT 通信的標準。車聯網也是類似的場景，也是選 MQTT 偏多。 MQTT 和 HTTPS 最主要區別在於，MQTT 是異步消息通性機制，HTTPS 是同步請求響應式的機制。車聯網這種應用場景，需要處理大量事件消息，MQTT 後端一般都是高性能消息中間件，消息中間件可以有效處理這些消息。如果採用 HTTPS 會有一定的侷限性。根據 [1] 鏈接中描述，這些侷限體現在： 1) HTTP 是一種同步協議。客戶端需要等待服務器響應。Web 瀏覽器具有這樣的要求，但它的代價是犧牲了可伸縮性。在 IoT 領域，大量設備以及很可能不可靠或高延遲的網絡使得同步通信成爲問題。異步消息協議更適合 IoT 應用程序。傳感器發送讀數，讓網絡確定將其傳送到目標設備和服務的最佳路線和時間。 2) HTTP 是單向的。客戶端必須發起連接。在 IoT 應用程序中，設備或傳感器通常是客戶端，這意味着它們無法被動地接收來自網絡的命令。 3) HTTP 是一種 1-1 協議。客戶端發出請求，服務器進行響應。將消息傳送到網絡上的所有設備上，不但很困難，而且成本很高，而這是 IoT 應用程序中的一種常見使用情況。 4) HTTP 是一種有許多標頭和規則的重量級協議。它不適合受限的網絡。 從現在來看建議選擇 MQTT。另外 [2] 鏈接，紅帽的 MQ 很好的支持 MQTT，事件流，也可以和容器雲集合，是車聯網很好的一個選擇。 [1] https://www.ibm.com/developerworks/cn/iot/iot-mqtt-why-good-for-iot/index.html [2] https://www.redhat.com/en/technologies/jboss-middleware/amq
Q：PaaS雲平臺架構設計？如何搭建好微服務架構、Docker容器技術、DevOps，設計和實施時需要注意哪些要點？
微服務、DevOps、Docker相關PaaS三者邏輯可以分開建設 1) 微服務：首先考慮必要性，靈活度需求和開發團隊成熟度需求真是否到了需要微服務化的地步。始終覺得，無狀態服務是必要的，但微服務不是必要的。 2) DevOps：同樣存在成熟度陷阱。首先CI/CD做好了麼？CD部分生產切換灰度等方案完善了麼？傳統針對VM同樣可以通過定義模型和腳本進行與容器類似的自動化批量部署。 3) Docker：與2有點類似，只是通過更加方便的手段來構建黑盒。與1中的無狀態性比較相關（有狀態應用你可以通過Stateful相關容器實現，但是我始終覺得這違背了容器的初衷）。但需要注意平臺構建對於下層計算資源和網絡的要求。 另外，要做好日誌收集和監控。因爲PaaS上的應用都是基於容器來運行的，而且都是多個節點運行，這就造成了獲取日誌文件的難度。很多情況下，如果系統有報錯，需要調閱日誌文件的時候，不知道取哪個容器裏面的日誌。目前我們是基於fluentd+elasticsearch(hdfs)+kibana的方式來進行日誌收集。fluentd負責收集容器日誌並上送到elasticsearch以及hdfs裏面（HDFS主要是做日誌持久化存儲便於後續審計），elasticsearch裏面的日誌只保留7天。Kibana用於日誌的檢索和可視化。 對於監控平臺，我們使用了heapster+influxdb+grafana的技術棧。heapster用於收集節點cAdvisor上的監控指標，上送到influxdb，由Grafana查詢influxdb做可視化展現和監控預警。
Q：在雲環境下，如何將openstack和openshift進行整合，並統一管理，分配資源？
推薦紅帽和 Intel 聯合推出的開源雲解決方案，主要圍繞的是 OpenShift on OpenStack, 可以參照如下鏈接：http://ksoong.org/cloud-labs/content/ 進行統一整合、管理、資源分配是有方法的，首先 OpenShift 和 OpenStack 都是紅帽主導的產品，在紅帽內部，這兩各產品都屬於雲設施 BU。
存儲，網絡等可以很好的整合，另外，CloudForms 是一款全面的 IaaS 雲和 PaaS雲的混合雲管理平臺，提供適用於虛擬環境和雲基礎架構的自助服務，同時保持安全及合規性。可以去做一些集中管理的方案。
Q：如何降低PaaS的學習和使用成本？
PaaS是一個企業級平臺，K8S是平臺中的一個核心組件。 從學習和使用角度來看，用戶不僅要理解K8S的原理與機制，還需要深入學習存儲、網絡、日誌、監控等多種組件，成本相對較高。如果PaaS平臺產品的供應商能夠提供詳細的培訓/知識轉移計劃，相對來說，效果會好很多。
以OpenShift這樣的PaaS平臺爲例，從前期規劃開始，RedHat就會提供詳細的技術培訓計劃，隨着項目交付的推進，相應的培訓課程也會一併開展，最終實現用戶可以自行維護使用PaaS平臺，並且有能力向其它業務部門提供技術培訓。
2. DevOps與敏捷組織
Q：基於openshift的容器方案，如何將CICD落地以及應用場景主要有哪些？基於openshift的容器解決方案，如何將CICD落地？openshift的容器方案現在哪些車企有落地？應用的場景主要是在車聯網麼？應用的效果如何？ 關於CICD落地，包含以下兩個部分:
- 工具 OpenShift自帶CICD功能，具體實現由jenkins來完成，其中RedHat開發了一些Jenkins插件進行輔助集成，OpenShift也可以直接集成用戶現有環境中Jenkins工具。
- 針對應用的CICD流程落地 通常，RedHat會和運維開發團隊討論某個具體應用的CICD流程，確定最終的方案，然後開發相應流水線的腳本(groovy/shell)，接着進行測試驗證。 應用上PaaS平臺的流程可以參考下面的框圖
CICD具體流程可參考下圖:
CICD的效果圖:
Q：微服務和soa架構在企業應用實踐及未來趨勢？微服務和soa架構適合哪些企業應用場景？將來微服務會代替soa嗎？
微服務和 SOA 是有一定聯繫的，他們的核心思想是相通的，例如微服務和 SOA目的都是：
- 鬆散耦合能力
- 分佈式能力
- 服務重用的能力
微服務跟強調的是服務，通過一系列鬆散耦合的服務去實現滿足業務需求的應用，目的是將大的、複雜的應用通過CI/CD、DevOps 等方式去管理維護，極大的縮短了複雜應用從開發到部署的時間（數量級）。
SOA 理論層面也講面向服務架構，但在實踐中都進行的是面向系統的整合，或集成的方向，所以可以說 SOA 強調的系統。
關於未來，新的架構會成爲必然，根據某諮詢公司的調研結果，目前以及有 50% 的應用採用新的，輕量級、互聯網化、微服務化的架構，如下圖：
Q：不是微服架構的應用採用容器部署的方式有那些實際意義？
可以獲得以下3點好處：
1、提高資源的使用效率。例如傳統安裝了WebSphere的4C8G配置的Linux虛擬機，在生產環境下，最多也就部署4、5個應用。但是同樣配置的虛擬機，可以跑10個左右的容器。這樣就大大提高了資源使用效率。
2、環境的隔離。在Docker容器內跑的應用，我們會將中間件和應用版本構建到一個鏡像裏面去，這樣就將應用與外界環境 做了隔離，可以做到應用之間互不影響。例如，假設一個安裝在傳統虛擬機和WebShere中間件上的應用，如果需要JVM虛擬機的字符集是GBK的話，那麼這個WebSphere上運行的其他應用也需要以GBK作爲字符集，這樣就導致應用之間強耦合。如果採用容器方式部署的話，就不存在這個問題。
3、對應用而言容器定義了一種新的黑盒交付模式。
Q：現有的應用不是微服架構有必要做改造嗎？
微服務，在互聯網企業甚至傳統行業移動端業務得到大規模採用，已然成爲主流的應用架構。
微服務旨在幫助組織實現兩個基本目標 - 敏捷性和規模 - 因此首先要評估組織的需求。
1) 敏捷性：笨重單一的應用程序或ESB基礎架構可能需要長達數個月的部署時間，從而導致冗長的發佈週期，阻礙組織跟上市場需求的能力。在構建、部署、擴展和管理各個服務時，微服務可以使您轉向更靈活的持續交付環境。
2) 規模：對於希望更有效地利用現有硬件資源的組織，微服務可通過容器化提高計算密度。另一個可擴展性要求可能是快速彈性以適應峯值負載並在非高峯時刻減少資源 - 例如，亞馬遜能夠處理各種促銷活動的購買量或Netflix在新節目發佈時處理流量的能力。隨着組織的擴展，一致的性能是另一個特別關鍵的需求。如果您需要更新應用程序的某些部分，微服務架構可實現獨立部署和擴展，而不會影響應用程序的其餘部分。 如果有敏捷性或者業務規模擴展的需求，建議對現有應用進行微服務化改造。同時隨着微服務架構的落地，DevOps將會成爲加速業務價值流動的重要一環。
Q：車聯網paas一定要採用devops嗎？優勢是什麼？
沒有必然聯繫。
paas是彌補傳統開發到中間件平臺的gap，並一定意義上提升組織的能效。其一個技術架構，狹義地講就是容器雲。因爲如果應用是通過容器鏡像來發布的話，就是將中間件和應用程序一起打成鏡像來發布，這就意味這開發人員在構建鏡像的過程中其實就是做了運維人員的一些工作。另外容器雲還提供對容器行編排調度，動態擴容等等功能。這兩個容器雲的特性在一定程度上大大減少了運維人員的工作量。所以說基於PaaS雲平臺的組織，很容易搞DevOps。
devops解決的是敏捷組織持續開發持續交付的演進過程，解決的是業務交付效率和開發團隊成熟度問題。其是組織內部解決開發人員和運維人員之間鴻溝的一種方法，所倡導的是開發人員向後走一步，多往運維方向考慮一下，運維人員向前走一步，多往開發方向想一下，最終目的是實現開發和運維水乳交融，提高組織的效率。
Q：如何基於paas雲實現持續交付？
持續交付之所以困難，不僅僅是在技術上，更主要在制度上。特別是我們這種金融企業，對變更非常謹慎，審覈非常嚴格。並且我們的開發測試環境跟生產環境在網絡上是隔離的，這就進一步增加了版本從開發測試環境交付到生產環境的難度。因爲這些原因，我們必須設計一套完整、成熟、經得住推敲的持續交付流程，才能夠說服質量監督和生產安全部門在企業內部推行持續交付。
基於PaaS的持續交付，其實就是兩樣東西在三套環境之間的同步。三套環境很好理解，就是開發環境、測試環境、生產環境。有些公司可能還有預投產環境。兩樣東西指的是鏡像倉庫裏的鏡像，策略倉庫裏的容器編排策略。我們企業內部的鏡像倉庫使用的是VMware提供的開源企業級鏡像倉庫Harbor。Harbor提供了鏡像的同步策略配置，可以很好地幫助我們實現鏡像倉庫之間的同步。對於容器編排策略的同步，我們使用自研的PaaS雲管理控制檯來完成不同環境之間的策略同步。當開發環境發起策略同步申請到測試環境時，開發環境的管理控制檯會將編排策略導出一個zip包，以FTP的形式上傳到測試環境管理控制檯，並給相應的測試人員發送通知郵件。測試人員登錄測試環境管理控制檯後，首先將策略包導入，之後進行審覈以及修改參數等等，審覈通過後，就可以一鍵在測試環境部署這個容器編排策略。如果這個策略之前在測試環境已經存在，本次只是對原有策略的更新，那麼管理控制檯會比較本次提交的策略和已有策略的不同，並將不同之處提示給測試人員。並且在這種情況下，運行這個策略的時候，在K8S集羣裏面就不是創建一個Deployment，而是基於原有的Deployment進行Rolling Update。
對於生產環境，根據制度的需要，我們採用了雙人複覈的機制。當策略包由測試環境提交到生產環境的管理控制檯以後，首先由QA人員審覈，QA審覈通過後，就意味着發佈版本，之後再由運維人員複覈，並修改相應的生產參數，審覈通過後，就可以部署運行。同樣如果提交部署的策略已經存在，爲了保證生產上運行的應用服務不間斷，在K8S集羣裏面就不是創建一個Deployment，而是基於原有的Deployment進行Rolling Update。
3. 平臺管理
Q：應用上openshift容器雲平臺後，開發和運維的工作模式會發生改變，當前的人員組織架構是否要同步進行調整？
應用上OpenShift容器雲平臺後，在 DevOps 流程自動化程度上有一定的提高，確實會帶來組織形式的變化。常見的有兩種形式： - 構建虛擬化團隊，由運維、開發、業務等團隊的成員參與組建。 - 組建實體運維團隊，專門負責PaaS平臺的事務，對企業內部業務開發團隊提供統一的支持服務。 細節可參考：http://v1.uncontained.io/playbooks/fundamentals/openshift_roles_responsibilities.html
Q：私有云平臺建設中，平臺主機的生命週期是如何評判的？是否有標準？標準參考的對象是什麼？
服務器生命週期管理涵蓋了計算能力的規劃，交付，運營和淘汰四個階段。 由於服務器generation更新導致計算力有較大提升，故對早期generation的MA總會平衡其計算力和成本。 一般根據generation進行定義和淘汰，一般結合實際情況，生命週期在5-7年左右。當然，無論是VM還是Docker的虛擬化，通過自動化的運維手段定義，使得底層計算資源更新已經對應用幾乎透明。
Q：雲平臺和物理機哪個性價比好，方便管理？包括費用對比、後期管理費用對比、管理難度、故障率、操作難度
可以探討下裸金屬和VM構建的差異點： • 性能損失。我記得早期測試過，容器化本身性能基本無損失，hypervisor好像在20%左右。 • 場景。考慮到大部分java應用使用jdk8以下版本，容器化是高內存低CPU佔用。如何提高宿主機資源使用率？ • 管理複雜度：本質上是VM和bare metal的差異。但需要注意2點：1.容器的無狀態性導致和主機基本無關聯性。2.集羣主節點可用性和快速恢復。
Q：車聯網應用場景下，雲架構如何設計？傳統IDC應用中容易以下問題：
1.服務器擴展性差，假如新增車聯網用戶200萬，服務器擴展週期長。 2. 運維不靈活。 3. 信息安全無法保障，管理人員數目增多，潛在人爲因素增大。 4.車輛行駛的場景對動態網絡要求較高，傳統 IDC 無法實時支持對網絡的動態調整。 車聯網應用場景下，雲架構如何構建，能否解決上述問題。
不管是傳統的“雲”還是現在所謂的cloud native，本質上是將傳統軟件開發和基礎平臺的gap通過新的技術手段給彌補起來，但對於本身的體量問題，比如inbound/outbound流量，架構只能解決更好的利用率問題，但如果利用率達到極限，還是需要通過外部擴展/公有云等方式解決。 因此對於問題1，現在的思路是通過無狀態應用提升橫向擴展水平；通過資源利用率的提升，節省一部分成本。 問題2，可以通過自動化運維手段配合CI/CD持續改善。 問題3，在組織內部，需要有專業的安全小組定義high level要求和綱要。在服務設計階段，需要有安全層面需求和要求定義。服務運營階段，需要有自動化的安全掃描工具和手工化的外部安全審計等方式確保目標不偏離。 問題4，規模效應的問題。建議區分場景，哪些數據可以從公有云走，再異步回主機廠；哪些不能走公有云。
Q：幾種容器編排工具中Kubernetes，Swarm和Mesos，哪個較好，如何選擇？國內有什麼好的容器調度引擎？有推薦的定製化解決方案？
Kubernetes 現在成爲事實上的標準，現在市場關注的焦點在於，誰能提供跟好的 Kubernetes 企業級支持，誰能幫助企業跟好的落地 Kubernetes 平臺。 關於 Kubernetes 和 Mesos 的各方面的對比，可以參照下圖：
