2021年，分散式雲成為雲計算領域關注的熱點。經過一年時間的探索與沉澱，分散式雲開始從理論走向實踐，諸多雲計算頭部企業夯實分散式基礎設施建設、最佳化分散式資源排程、開發分散式應用，為構建分散式雲打下了堅實的基礎。
12月15日，以“引領分散式雲變革 助力灣區數字經濟”為主題的全球分散式雲大會在深圳隆重召開，本屆大會由全球分散式雲聯盟、深圳科技交流服務中心、深圳市通訊學會、眾視Tech聯合主辦。組委會攜手阿里雲、騰訊雲、Google Cloud、華為雲、螞蟻集團、浪潮雲、金山雲等海內外頂尖雲計算團隊和分散式雲先鋒企業，為粵港澳大灣區數字經濟發展注入分散式雲動力，更將中國分散式雲計算發展推上全新高度！
在15日下午舉辦的分散式算力論壇上，Google Cloud 雲架構師陳子升先生髮表了題為《Google Cloud 應用現代化技術助力分散式計算》的精彩演講。
容量管理
傳統的應用管理相對簡單，作為單體應用，架構簡單，節點相對較少；分散式應用涉及很多環節，要精確評估每個環節所需要資源，管理難度大大提升，同時也要求相應適配的網路與安全能力。對有明顯應用波峰波谷的應用很難平衡容量與成本，最理想是依據波峰來評估容量，但這樣在業務處於波谷的時候就會造成成本的浪費。
最好的容量管理是無須做容量管理，而實現“無須做容量管理”需要使用全面彈性伸縮。在實現彈性伸縮方面，Google Cloud的獨到之處主要有三點：
一 計算：針對計算型別的資源（虛擬機器、容器等）提供多維度的伸縮閾值，除了CPU、記憶體、網路指標等指標，也包括自定義監控指標，比如業務維度的指標。以上均可成為觸發彈性伸縮的條件。
二 網路：Google Cloud 是全球一張網，提供全球一個VPC，各區域互聯互通的能力。想象一下傳統環境，如果要把分散式應用部署在全球各個資料中心，各個資料中心可能會有專門的網際網路出入口，網路和安全能力要依據每個資料中心進行規劃，相對繁瑣。而Google Cloud的全球網路能力，可以讓部署在全球各個區域的業務，只需要一個負載均衡，一個VIP，就可以提供給全球各地客戶端就近接入，並且具備無上限的安全能力。全球網際網路30%的流量都在谷歌中，有史以來最大規模的DDOS攻擊——2.54TB，也發生在谷歌，而谷歌對這次攻擊幾乎無感。
三 底座， 傳統環境，如果要使用Kubernetes服務，控制、資料、運維平面等等都需要使用者自己處理。谷歌提供兩種託管Kubenetes服務，第一種是Standard GKE，屬於半托管模式，客戶可以定義節點、網路與安全的配置，Google Cloud負責控制與運維平面；對於一些不想管理這些節點，甚至不想感覺到這些節點存在的客戶， Google Cloud也提供Autopilot模式，無需人手干預的全託管Kubernetes服務，資源彈性伸縮，根據所佔用資源計費。使用者只需使用Kubernetes的介面即可部署應用。
多環境管理
單區域、單叢集上執行的分散式應用其實並不是真正意義上的分散式應用，真正意義上的分散式應用應該是跨區域、跨資料中心、跨雲的。於是，就引出了多雲和混合雲環境如何統一管理，虛擬機器、容器和雲服務如何統一編排等問題。Google Cloud有兩個思路來解決這些問題，第一個思路是把所有非容器的資源，如虛擬機器和其他雲服務都抽象成Kubernetes的資源進行管理；其次是用Anthos對多環境的叢集進行統一納管。
統一納管不單單指為所有叢集提供統一檢視，如看到叢集上所有節點的狀態、應用狀態，這只是統一納管的一小部分；真正統一納管的內容是配置管理，Kubernetes所有資源都是配置。
傳統的配置管理是命令式運維，用kubectl連線不同叢集執行相應的操作，這樣的方式會帶來一系列的問題，第一個問題是命令難以重用，在一個叢集下的命令，在另外一個叢集又得執行一遍；所執行命令也難以審計和追溯；另外命令式運維安全度相對較低，生產環境中絕大多數的故障都是人為誤操作，並且故障難以回滾，因為很多時候無法得知哪條命令導致了叢集的故障。谷歌的SRE運維理論裡有一個詞來形容這種人工重複低效操作叫Toll。
谷歌建議用Git配置倉庫思想做運維，先把操作定義成配置檔案，再把檔案儲存到Git倉庫，這些配置會下發到所有叢集或者特定叢集上生效，可以利用Git生態一系列的元件，比如分支、驗證、審查、合併、部署等等，Git倉庫也支援透過已有的配置進行編排。
GitOps的優勢體現在以下幾個方面，首先是操作是可審計的，操作都是配置檔案，可以清晰地回溯流程，配合版本管理，可以輕鬆回滾；另外，由於事務性，要麼配置更新全部執行成功，要麼回滾；具備自動修復功能，配置了GitOps的環境，操作者即使用人工命令方式在叢集上進行操作，GitOps元件會自動把Git配置拉到叢集，同步到一致性狀態。
Google Cloud有提供基於GitOps的統一配置管理服務—— Anthos Config Manager，幫助使用者輕鬆實現多叢集配置管理。
微服務治理
微服務化會帶來很多好處，但也會帶來額外的開銷。傳統應用環境的治理可能用APM去做，但微服務和容器環境，容器例項是暫存的，沒有固定IP的，傳統的APM就無能為力了。實現微服務治理的最好的方式是找sidecar幫忙。沒有sidecar的話，微服務治理需要一系列元件來完成，不但提高了開發人員的工作量，還有程式碼侵入性。藉助sidecar的幫忙，可以把微服務治理相關工作，解除安裝到sidecar來完成，實現非程式碼侵入，語言無關的微服務治理。所有叢集內的sidecar，就組成了服務網格。服務網格是一個很好的理念，但目前在企業生產環境很少有大規模應用，主要原因是效能所限。
谷歌用Cilium開源技術，基於eBPF核心技術，可以在核心程式設計，讓你的應用和sidecar之間通訊流量直接在Socket層面完成轉發，沒有經過額外的核心網路協議棧，這樣會大大降低sidecar所帶來的網路開銷。
谷歌提供全託管的服務網格服務——Anthos Service Mesh，來幫忙使用者快速實現微服務治理。ASM是基於並完全相容Istio的託管服務。相對於Istio，它還有額外的優勢：
開源的Istio在叢集的內部安裝控制平面和資料平面，對多叢集的的服務治理會帶來額外的配置工作。谷歌把整個控制平面獨立出來做全託管的服務，可以輕鬆實現多叢集的服務治理。另外ASM也藉助Cilium最佳化sidecar帶來的網路損耗；ASM還是基於SRE核心SLO實現的可見性，可以在技術上承載SRE理論的落地。
很多企業對SRE有誤解，覺得運維人員可以寫些指令碼，或者做一些簡單的程式設計，就是SRE了。其實SRE的核心是SLO，SLO讓監控面向服務，不是面向實體。ASM可以讓使用者很容易地在介面上定義監控服務水平的指標SLI、服務水平目標SLI和持續的監控狀態計算錯誤預算。
有些對網路延遲苛刻的應用，無法接受sidecar帶來的額外網路延遲，即使此延遲已被Cilium最佳化。谷歌推薦使用gRPC實現無代理的Service mesh。gRPC是谷歌開源的RPC框架，直接在協議層構建了 Service Mesh，無需sidecar或代理，沒有額外的網路損耗；另外gRPC是基於HTTP/S的，效能比起HTTP1.x優異很多；同時gRPC也是支援標準的xDS的API。
目前的gRPC已全面應用在Google Cloud的底層服務呼叫。
支援xDS的API還有一個好處，可以把Service Mesh的控制平面和資料平面解耦，用不同的產品實現控制平面和資料平面的能力。比如說控制平面，可以使用谷歌提供的託管服務Traffic Director，也可以用開源的方式做；資料平面非常靈活，可以是本地環境或雲上環境，可以是虛擬機器或容器環境，可以是有代理有sidecar的環境或無代理的gRPC環境，可以是計算的資源，也可以是網路的資源；比如 Google Cloud 內部和下一代的基於Envoy的負載均衡。有了對於xDS API的支援，gRPC與sidecar，可以組成一個跨環境跨雲的 Service Mesh。
解決了微服務的內部問題，陳子升就微服務要對外服務的問題進行了講解。
微服務如何對外輸出實現有效運營，Google Cloud 建議可以用 API 市場來做。首先把後臺的服務抽象成API產品放到API市場上展示。API管理平臺同時實現API授權、安全、API轉化、分析、運維的功能。客戶就可以透過API平臺提供的服務目錄去呼叫服務。
Google Cloud提供企業級的API管理平臺——Apigee。Apigee除了上述功能外，還有三個特點：一 共同協作，很多企業可能把API平臺定位成一個團隊級或者專案級的平臺，這個定位沒有發揮API平面的真正作用，陳子升認為應該定位成企業級平臺，他舉例說，要做一個電商平臺，如果在電商平臺上只有一家商店在賣產品，客戶不會很多的，最好的方式是開放平臺給不同的商家進駐，提供不同的商品，這樣電商平臺的客流量才會多。Apigee就是提供了開發者門戶，可以讓企業內外部包括合作伙伴，第三方開發者來開發與釋出API。
二 陳子升同時舉例，如果進駐電商平臺的流程繁瑣，門檻很高，也不會有很多商家願意進駐。Apigee提供低程式碼開箱即用的方式，透過拖拉拽就可以完成API產品的開發、迭代和控制能力。
三 業務驅動。很多時候企業做API市場經常有一個誤區，也就是後臺有什麼樣的微服務，就把這些微服務做成API展示出來，這經常導致一個局面：API平臺上面的API很多，但用的人很少。這裡需要思維的轉變，從技術驅動轉向業務驅動。應該是使用者需要什麼樣的能力和服務，開發者把後臺微服務組裝成相應的API產品或者開發相應的API產品，去滿足使用者的需求，使用者的需求也會反向推動服務的迭代，這樣才有利於API市場的繁榮。
陳子升最後總結與回顧所介紹的內容：企業要部署分散式應用時，可能會部署在不同的環境，這涉及到多環境統一管理的問題，Anthos可以連線不同的區域、雲和環境，可以遮蔽叢集之間的差異性。在此之上需要對不同的叢集進行配置和策略管理，Anthos Config Manager以GitOps的思想幫忙使用者高效進行配置管理；在此底座之上部署微服務應用，會涉及到微服務治理問題，Anthos Service Mesh可以幫助客戶更方便地進行微服務治理，同時解決服務網格的sidecar導致的效能問題；當部署完服務之後，如果需要將服務釋出出去給第三方使用，就涉及到服務運營的問題，Apigee API管理平臺就是服務於此，可以遮蔽對外介面的差異性，幫助客戶做更好的服務運營。
