devops之gcp core infrastructure fundamental, 概念

devops之gcp core infrastructure fundamental, 概念

最后更新2022/02/01

参加了一个google的课程，不知道能不能坚持下来，今天第一讲：google cloud platform core infrastructure fundamental

什么是cloud computing云计算

云计算（更进一步说，其实是谷歌的云计算）有几个主要特征：

按需求计量，自助服务。这里有两个关键点，第一是根据需求（或者叫做使用，用多少，算多少）；另一个是自助完成，把原材料都准备好了，你自己用多少，拿多少，最后统一结账。期间看不到直接的人工干预，全过程都是你自己完成了，提供方只提供资源本身，而加工服务都隐藏起来（不是没有，有的，但都自动化、隐藏、打包了），差不多就是自助点餐，自组组合，然后点按钮，biu。。。汉堡包、大盘鸡就显现了，吃完钱包被扣掉对应的花销，而且应该和你点餐时的各项要求对应的收费一分不差。宽带接入，可以从任何地方提供服务；资源池化，就是用户所用的资源是共享的，具体好坏特性，有好多点，但对于用户来说，最重要的是便宜。。。快速的，d性的，就是可以根据你的需求，快速变换资源和结果，你可以只要一小杯可乐，也可以100个全家桶，完全一念之间：要求，收到，付钱，就这么简单。最后一条已经隐含说了多次了：按使用计量和付费。当然这个使用的概念很多时候是你下了定单，而并不是狭义的“使用”。否则你定了1000个全家桶，然后不提货，这也不好吧？

怎么能实现以上特点、功能？最终目标是什么？

这是一个逐步发展的过程，最早我们都是用的物理设备（存储、计算、内存、网络），每部分都是单独的、实实在在的“铁疙瘩”，用户自己配置、管理、维护，但有一些已经采用了托管的方案，就是把这些设备和运行维护等等整体上独立出来，统一计量、管理，虽然还在用户自己手中，但已经有了明确的归属划分，这样才容易核算成本、考核KPI；再此之后，我们引入了虚拟化技术，虽然还是用户配置，但管理和维护功能都“外包”出去，由供应商完成；最后，我们要达到的就是所谓无服务器状态，用户看不到真正的服务器，所有以上配置、管理和维护都是自动实现，只需要你biu。。。付费

以上过程是企业IT发展的过程，但谷歌自己也是这么做的，而且做得很好，好到领先了其它公司很远，很早就能实现全自动，可以biu了。谷歌看别的公司老牛拉慢车着急啊，于是把这套技术公开出来（开源），大家共享吧，当然，要是你觉得光有菜谱还是不会做菜，那不打紧，正合哥意，你就买俺家gcp呗，还看啥菜谱啊，直接到我这这点菜，不香么？

每个公司都是数据公司

哥不仅仅有技术，哥还有忽悠。哥认为，以后技术都是以软件方式落地的，公司无论大小，它都要有技术，以技术驱动，也就是要用软件实现，而软件本质上是围绕数据完成的运行逻辑，因此，所有公司，早晚都会成为数据公司。这样一来，由于哥玩的就是云，这云的设计中心思想是围绕着数据，而且是海量的数据，提供各种各样的服务，所以，你们跟着哥走，没错了。

现在gcp的架构提供啥

如果从完全用户管理的基础设施到完全哥玩的动态基础设施分成不同阶段，那么具体可提供：

计算引擎，这是IaaS服务，就是对外租机器、机房、网络，与传统的租物理机器不同的是这些都是虚拟的，不会真的需要物理机器搬来搬去，线缆连来连去（虽然实际上还是有这些要求的，但你但不到，也不需要你去干）；kubenetes引擎，这是混合IaaS和PaaS之间的服务，差不多是租容器服务，至于容器么，那就是比虚拟机再小一点的、再简化一点的虚拟机啦，够用就行了，别管它是三蹦子还是滑板，能跑，能拉货就行呗，还咬啥自行车；App引擎，这是PaaS服务，真的按照应用平台特点提供虚拟资源了。由于和具体App有关，那App都是啥就必须有个列表，此处暂不展开，但大部分用户应用的平台类App也无非是web server, java虚拟机等；无服务器的cloud function。这个也好理解，App再虚一点，我都不需要完整的一个应用类型功能啦，我只要某个具体功能，例如保存个文件，传送个数据，拿到某个统计参数，只要云能提供对应的API，我去调用一下就可以了，管它云到底是在哪台服务器上跑，用什么应用提供的？！管理服务。尽管是自助式，但还不是自动式，至少你要想，然后还是要按一个按钮。这就需要助，这个助其实和第4点cloud function也差不多，只是某些特别的cloud function而已。

哥的网络是庞大地

哥已经建成了跨越全球，超过10万公里的光纤骨干网，8条越洋海底光缆，40%的互联网流量都是在哥的网络中流淌，其中有超过90个数据交换节点，100多个对外接入节点（presence节点，我猜想应该叫做带缓存，能直接对外提供访问服务的节点），还有7500多个与互联网的接口节点（这个看起来应该是互联网其它部分、通信公司与谷歌互联的接口）。由于哥的管道这么粗，流量这么大，接口这么多，所以只要连到哥的网，哥能以最短的链路，最快的网速，最小的延时把你的数据送到该去的地方，绝不会有问题。

GCP是按照地区region和区域zone划分的（姑且认为中文地区比区域大吧）

GCP在全球有多个地区，每个地区又下辖好多区域。其中地区之间是独立的，存粹物理地点独立的，也就是不会同时受到单一区域性灾害影响，但区域则不能保证这一点，甚至区域是一个单点故障隔离点，也就是如果有设备损坏，运气最不好的情况下，整个区域内的资源都会死翘翘。因此，如果你想部署高可靠应用，则必须将此应用跨区部署，而如果要容灾，则要跨地区部署。同一地区但不同区域之间可以确保低网络延时，例如能做到95%的情况下，环路延时在5ms之内，这样保证跨区部署不会有严重的网络问题；

由于以上特性，所有资源也会因此挂上相应的标签：

区域性zonal资源：这是不可跨区的资源，当某个区域故障，与此区域相关联的所有资源都会不可用，例如计算引擎vm就是一种区域性资源，它只能存在于某个特定的区域；地区性regional资源：此类资源会跨区部署，因此具有高可用特性；多地区mulit-regional资源：gcp一些特定的资源能够实现跨多地区部署，绝对意义上，单纯跨地区运行不成问题，但要跨地区还能很好地运行，却是个大问题，因为跨地区的网络延时非常大，这是由于光速极限导致，不考虑其它延时因素，单单跨越6000km，一个往返的光延时就会达到40ms，如果要再加上数据一致性要求，那访问性能会一塌糊涂。因此，需要对这些需要跨地区部署的资源进行特别优化，同时也要求用户不能对这些资源有过高的延时、一致性要求，实在是臣妾做不到。这一类资源可能包括（也就是它们可以跨地区部署）：
Google App Engine
Google Cloud Datastore
Google Cloud Storage
Google BigQuery 哥的节点遍天下，环境保护哥最牛

哥在全球目前有17个地区节点，还在不断增多中。
哥从2007年开始就实现了碳中和（也不知道怎么做到的，google自己太阳能发电？）；全球最大的可再生能源购买者（看来还是拿钱去堆。。。），马上就会让所有的数据中心100%都使用可再生能源；全球第一个满足ISO14001的数据中心。

哥的价格很亲民

咱计费的单位可以小于小时，对某些资源（IaaS资源）等能按秒计费。（我觉得还是以小时为单位，不到一小时不计更实惠）多用优惠。例如compute engine使用量超过总量的25%，自动给折扣；用户自定义虚拟机，可以根据用户要求，特别优化（当然是用户自己完成。。。），也就是改改CPU内存磁盘带宽吧 开放API和开源软件

开放API：与开源服务完全兼容，例如cloud bigtable，cloud dataproc，它们使用的API与Apache Hbase，Hadoop完全兼容，也就是如果用户觉得google产品不好，可以直接换Hadoop等等；拥有丰富生态的开源软件：TensorFlow，Kubenetes，Forseti Security各个层面与其它供应商兼容的技术（多供应商友好）：Google stackdriver，Kubenetes Engine 设计框架之初就考虑到了安全

运行安全：入侵检测，降低内部安全风险；用户U2F（uniersal 2nd factor）；代码开发规范；互联安全：Google Front-End，避免DoS存储安全：数据保存加密用户安全：中心认证，支持U2F服务安全：内部通信都是加密传输硬件安全：硬件设计保障，安全启动，确保授权等等

吧啦吧啦吧啦一大堆，哥自研了加密芯片，内部RPC都是加密的，使用中心认证key对存储数据加密（不知道收不收费），有自己的防火墙技术GFE（和GFW比一比？），还有发现漏洞奖金。。。

提供的服务

计算类

compute enginekubenetes engineapp enginecloud function

存储类

BigtableCloud storageCloud SQLCloud spannerCloud datastore

BigData

BigQueryPub/SubDataflowDataprocDatalab

Machine Learning

Natural LanguageVision APIMachine LearningSpeech APITranslate API