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管理平台就是服务于此，可以屏蔽对外接口的差异性，帮助客户做更好的服务运营。
