手机网站
手机网站
|流行云计算在刘超
作者|宸妃< br>
编者|卡罗尔
产品| CSDN云计算(标识:CSDN云)
现在越来越多的企业开始全面拥抱云计算，开始关注云的本土技术
从管理物理数据中心到使用云主机，我们不再关心基本操作从云主机到Kubernetes容器，我们不再关心机器的管理。云的抽象级别越高，人们关心底层问题的需求就越少，企业可以节省大量人力成本和资源投资。云原生技术是更高层次的抽象。CNCF将云原生技术定义为
，这有助于组织在新的动态环境(如公共云、私有云和混合云)中构建和运行可弹性扩展的应用程序。通过容器、服务网格、微服务、不可变基础设施、声明性API等技术，构建了一个具有良好容错性、易管理性和易观察性的松耦合系统。
(如FaaS体系结构)允许开发人员在根本不考虑服务的情况下构建和运行应用程序和服务。开源架构也有云本地技术，类似于MySQL、Redis云服务，它们提供基于开源微服务架构的应用管理服务，如Spring Cloud、Dubbo和HSF。开发人员不需要考虑部署、监控以及操作和维护问题。
如新浪微博，新浪微博一直在推广基础云原型。他们围绕Kubernetes构建了面向容器的云原型基础设施，形成了物理数据中心和多个公共云的混合云Kubernetes平台，提供了二级可扩展性构建开箱即用的配置项/光盘系统，依靠云的本机可扩展性，确保大型作业的稳定运行，并使开发人员摆脱代码发布沼泽接下来，我将介绍这些方面的实践经验。面向
物理数据中心的Kubernetes
单机基础架构无法再充分利用云容器根据服务粒度进行管理，每个服务对应一组虚拟机。尽管通过IaaS层抽象大大简化了基本的操作和维护，但是服务的操作和维护成本仍然非常高。服务SRE需要维护复杂的设备配置脚本，管理与服务设备配置的差异，并且需要7*24小时来干预故障设备
不仅资源利用率无法最大化，服务池被设备分割，新设备加入服务池后只能被该服务使用，其冗余计算也可以被其他服务使用。此外，当同一业务托管在不同的机器上时，容器网络体系结构更关心性能而不是隔离，并且通常采用主机模式，这也增加了混合部署服务的操作和维护成本。只有形成集群，
基础设施才能充分发挥好容器隔离、资源配置和布局管理的优势。Kubernetes已经拥有容器编排系统的事实上的标准，提供面向应用的集群部署和管理系统，以消除物理(虚拟)机器、网络和存储基础设施的负担。与此同时，CNCF推出了一致性认证，以促进公共云供应商提供标准的Kubernetes服务，确保通过Kubernetes部署的应用程序可以在不同的云供应商之间迁移，以避免被供应商锁定。
之前提到，微博容器将独占物理机的网络协议栈。尽管它可以最大化网络效率，但它会导致多容器部署中的端口冲突，并且不能满足Kubernetes的动态调度要求。为了解决端口冲突问题，新浪微博首先测试了了vxlan网络架构，因为其数据平面需要封装和解封装操作，网络性能损失超过5%，不符合微博后端服务的网络性能要求最后，经过评估，有两种可能的网络方案:互连互连互连互连互连互连互连互连互连互连
，其中MacVlan成熟稳定，通过连接到机房的交换机改变Vlan中继模式，在物理机上创建MacVlan网卡子接口，通过CNI插件将虚拟网卡插入暂停容量，从而实现容器网络与物理网络的连接容器的网络通信直接通过MacVlan的物理子接口，发出的消息在网卡上用VlanTag标记，因此数据平面基本上没有性能损失。因为控制平面需要将所有上行链路交换机转换成行Vlan中继线，所以工作量相对较大，所以该方案仅适用于高分配物理机所在的网络。
Calico BGP是一种集装箱网络解决方案，可以同时实现数据平面零损耗和控制平面自动化与MacVlan实现的平面两层网络不同，Calico在每个节点上部署BGP客户端和反射器来实现平面三层网络，每个节点发布的状态由Felix维护然而，费利克斯使用iptables来实现路由ACL功能，这对性能有一定的影响。因为物理数据中心不对外部用户开放，所以可以从微博中删除ACLs功能。我们优化了Calico以消除iptables依赖性。
微博也积极反馈给库本内特斯社区，包括对库本内特斯代码库的贡献，如修复多租户下网络隔离的TC资源泄漏问题。在
之前，操作和维护面向物理机器，因此物理机器上有许多操作和维护工具，如日志推送、域名解析、时钟同步、定时任务等。在业务由Kubernetes安排后，上述功能需要转化为能力。例如，在容器中使用systemd将涉及授权问题。在实践中，人们发现，如果当局受到控制，使用systemd会导致集装箱死亡。因此，微博独立开发了与linux crontab语法兼容的定时任务工具gorun，将该工具集成到操作和维护容器中。
，因为业务容量将生成大量日志。由于输入/输出性能考虑和快速定位，日志将存储在本地的永久虚电路中，以支持配额管理并防止一个容量填满磁盘。操作和维护基础设施可以通过监听文件来压缩和清除旧日志，性能配置文件日志将通过本地统计计算后的UDP协议推送到石墨或普罗米修斯。对于关键日志，将通过Flume将其推送到Kafka集群，并支持故障重传，以确保日志的一致性。
通过运维能力，所有业务Pod都具有相同的运维能力，形成了标准化的监控报警、运维决策、流量切换、服务降级、异常阻塞、日志查询等服务保障体系，服务可操作性大大提高
容器布局
Kubernetes部署支持Pod自我修复、滚动升级和回滚、扩展和收缩，所有这些都是基于云的基础架构所必需的然而，Kubernetes的设计原则保持集群管理的“无损”升级，尤其是在服务升级期间。部署的滚动升级将创建一个新的POD来替换Pod，以确保部署中Pod的副本数量。在滚动升级之前，原始面的IP地址将与IP地址不同。
，如果群集足够大，一次滚动发布将导致负载平衡更改(群集副本数量/滚动发布步骤大小)次数。对于微博服务，频繁的变化会导致负载均衡管辖下的后端真实界面的不稳定。
微博实现了常规Pod的就地滚动更新功能，根据业务冗余和业务实际需求调整在线步长，保持在线时容器的IP变化，减少在线时业务抖动
由于业务的启动需要一定的时间，并且可以根据容量启动的步长进行控制，我们使用Kubernetes容器生命周期管理的活性/就绪性探针来实现容器的服务状态，从而避免了在线过程中大规模重启的容量问题。同时，对了kubernetes poststar的本地实现进行了优化，因为本地表面只被调用一次，不管成功与否都会终止内容，并且会根据指定的次数或时间重试成功。知识产权的静态分配是由CNI卡利科公司实现的:
库本内特斯的安排策略相对灵活，分为三个阶段。初始筛选阶段用于筛选出满足基本要求的物理机器节点，优选阶段用于获得初始筛选的节点表面，以根据策略完成最优节点的选择。优化完成后，还有一个绑定过程，用于将Pod与物理机器绑定，以锁定机器上的资源。在三个步骤
完成后，位于节点上的kubelet开始创建Pod在实际情况下，要将物理机器的容量转移到Kubernetes，必须尽可能保持容量的部署结构一致。例如，服务池中的每台物理机器都被分配和部署了wb_service_a和wb_service_b两个容器。混合服务部件的安排可以通过podAffinity:
完成，一些更复杂的集群具有复杂的操作和维护，而集装箱的安排是通过Kubernetes运营商进行的操作器由CoreOS开发，用于扩展Kubernetes应用程序接口(一种特定的应用程序控制器)，用于创建、配置和管理复杂的有状态应用程序，如数据库、缓存和监控系统。运算符建立在Kubernetes的资源和控制概念之上，但它也包含特定于应用程序的领域知识。
操作员可以编写操作和维护人员的软件操作知识，同时使用Kubernetes强大的抽象来管理大规模软件应用。例如，缓存服务的操作和维护相对复杂，需要资源调度、数据同步、高可用性结构调度、备份和恢复、故障恢复等。通过实现缓存服务操作符，开发人员可以通过声明性的Yaml文件创建、配置和管理复杂的缓存集群。缓存服务操作员支持:
创建/销毁:通过Yaml声明缓存服务规范，您可以通过Kubernetes一键部署进行部署，删除扩展:您可以修改Yaml中声明的副本数量，操作员可以扩展容量，配置主从结构，挂载域名和其他备份操作:操作员根据Yaml中声明的备份机制实现自动备份功能，如定期备份、峰峰值备份和其他升级:实现关闭版本的升级。 支持回滚故障恢复:当单台机器出现故障时，自动切换高可用性，同时恢复副本数量，并自动恢复主从结构。 复杂的应用程序部署在Kubernetes上，有许多服务。服务之间的依赖关系也很复杂。每个服务都有自己的资源文件，可以独立部署和扩展。这给使用Kubernes的应用程序编排带来了许多挑战:
管理、编辑和新的大量Yaml配置文件。部署一个具有大量配置文件的复杂的Kubernes应用程序，例如上面提到的缓存服务操作符参数化配置模板，可以支持多种环境Helm可以解决这些问题赫尔姆包库本内特资源(如吊舱、部署、服务等。)转换成图表。可配置发布是通过模板和配置文件动态生成资源列表文件来实现的。
弹性
弹性已经成为云时代的新常态此外，微博拥有能够提前预测意外高峰的社交媒体属性是很常见的。因此，基础设施需要具有灵活性，能够在短时间内提供足够的资源。Kubernetes在基于容量技术的启动时间上比虚拟机有更多的优势，省略了许多环节，如虚拟机创建、环境初始化、配置管理等。，直接拉起服务舱，扩展时间可以从几分钟缩短到几秒钟。
和高峰流量突发，运行维护，开发学生可能正在吃饭、睡觉、休假，这一次通过人为干预肯定是要来的，所以系统需要自动做出扩展决策对于复杂的分布式系统，实现自动决策需要解决两个问题，一个是容量决策，另一个是依赖关系Kubernetes HPA(水平吊舱自动缩放)可以根据度量自动缩放部署中的吊舱数量。HPA由一个控制周期实现，周期由水平-pod-自动缩放-r-同步-周期标志指定(默认值为30秒)在每个周期中，查询HPA中定义的资源利用率在扩展之前将有一个冷却期，通常为5分钟(由水平pod自动缩放r-down scale-stabilization参数设置)，然后容量将按照以下公式进行扩展和缩减:
，但此容量决策有两个问题由于突发峰值流量的快速上升，上述扩容机制第一次未能达到其容量，多次触发连续扩容，导致流量上升过程中业务始终处于过载状态，影响业务服务水平协议。另一个问题是冷却期。如果冷却时间过长，峰值流量无法及时扩大。如果冷却周期太短，抖动将被误认为峰值，导致必要的成本浪费。
的第三个问题是复杂业务系统的依赖性很复杂。每项服务都根据自己的索引进行扩展。由于上述未缩放的流量在上游受阻，下游此时无法感知准确的流量趋势。从整体应用的角度来看，上游泄洪下游很有可能被淹没。
微博整体灵活可扩展架构基于混合云架构、内部网络私有云、公共云虚拟机、云Kubernetes和集成Kubernetes灵活集群，实现了快速自动资源调度，解决了跨IDC调度、定制调度算法和策略、容量评估、服务间容量扩展依赖等问题。，并构造全链路、压力测量、索引、报警等。干扰多维能力:
全链接是建立一个应用范围的能力决策系统。每项服务独立确定容量。相反，基于全链路容量指标的一致容量扩展决策压力度量有助于了解当前部署的冗余情况，合理设置容量扩展公式，避免容量扩展指标体系重复。将容量扩展指标体系从数万个指标中抽象出来作为决策的依据，并通过负载均衡、网络服务、数据库资源等多维指标及时报警和多路径到达，避免单点干预但支持快速伸缩，还支持快速优雅的降级。争取时间进行服务扩展CI/CD
云计算技术普及，研发过程也发生了变化，越来越多的组织和团队开始接受devops概念持续集成和持续交付是开发平台的基石。然而，CI/CD在实际着陆过程中存在许多困难，导致实际效果不理想。
基于配置项。发展学生应该熟悉“如果一切顺利，将会有大约100次考试失败”的情况由于许多因素，如开发环境和测试环境之间的不一致，配置项经常遭受相关的偶然故障。从长远来看，同学会的发展默认为忽视CI链接的错误警告，这最终导致CI/CD成为一个口号
利用云的本地声明性基础设施将应用程序系统和应用程序存储在Git的版本控制库中。每个开发人员都可以提交请求代码，并轻松地在Kubernetes上部署应用程序以及操作和维护任务。开发人员可以更有效地专注于创建新功能，而不是与操作和维护相关的任务基于Git的连续交付管道有许多优点和特性:
版本控制的声明性容器布局，Kubermetes，作为一个云本地工具，可以将其“声明性”视为“代码”。声明意味着配置由一组事实而不是一组指令组成，例如，“有十个redis服务器”而不是“启动十个redis服务”告诉我它是否有效”Git是事实的唯一真正来源。任何可以描述的东西都必须存储在Git库中，包括与系统相关的策略、代码、配置，甚至与其他工具相结合的监控事件。例如，监控系统可以以方形方式监控集群，并检查实际环境的状态是否与代码库上的状态一致。目前，大多数配置项/光盘工具使用基于推的模型。基于推送的流水线意味着代码从配置项系统开始，最终通过一系列构建测试生成一个镜像，并最终使用“kubectl”手动部署到Kubernetes集群程序员不喜欢开发过程的中断。在多个系统之间切换将极大地影响程序员的开发效率。因此，通过配置项和集成开发环境的结合，我们将配置项过程集成到开发自测过程中，这样程序员就可以进入面向配置项的测试驱动开发，并提高他们对代码交付质量的信心。
配置项/光盘管道围绕GitLab构建，这是程序员经常使用的。程序员可以将合并请求的配置项结果视为理所当然，避免在多个系统之间来回切换。每次代码提交都必须执行基于分支的完整配置项流程。借助云固有的弹性能量和共享存储，解决了大型并发任务的计算资源瓶颈，同时缓解了任务间共享数据的带宽压力和网络传输延迟。
连续部署比连续集成更复杂部署过程中有许多依赖于人力的环节。例如，灰度级是从操作和维护部署到生产环境中的一些机器上的。验证需要依靠开发和运行维护同学的经验来检查新版本的各项指标是否正常。滚动发布和回滚还需要操作和维护同学的全面干预。丝雀部署可以有效地规避风险，并在生产环境的基础设施中的小范围内部署新的应用程序代码。如果没有错误，新版本将逐渐扩展到整个服务，而不是一次从一个版本切换到一个新版本。
，但是，要验证没有错误是相当困难的。微服务是最容易出错和最耗时的链接，因为它们具有复杂的依赖性、广泛的部署范围和许多索引维度。为了解决这个问题，我们开发了一个智能时间序列数据异常识别服务，它覆盖了操作系统、JVM、资源服务协议和服务服务协议的数千个维度索引。它不仅可以自动、准确地识别人类经验可以发现的问题，如异常识别和性能下降，还可以识别人类难以发现的问题，如对资源的不当访问。当前的光盘流程包括部署、集成测试、线雀验证、滚动发布和回滚自动化
微博网格
服务网格不是新技术。它对高性能、高可用性、服务发现和治理的关注已经持续了一天，社区中也不乏最佳实践。然而，以前主要有两种方式。一个是微服务RPC框架，如Motan、gRPC、节俭、Dubbo等传统的微服务框架有很多缺点:
很难升级，框架和SDK强烈地绑定到多种语言的业务代码，各种语言的服务治理能力差异很大，服务质量系统很难统一。还有一个集中的代理形式，如引擎代理、Twemproxy代理、SQL代理等。虽然代理表单在一定程度上解决了胖客户端的问题，但是没有升级问题，并且可以统一多语言访问。但是，对于长时间的请求，性能损失是可以接受的，但是当在服务之间调用这种毫秒级请求时，性能是可以容忍的。此外，随着微服务的扩展，服务的拆分将不可避免地导致整个系统的时间消耗急剧增加，代理本身很容易成为整个系统的瓶颈。因此，经常可以看到后端服务同时使用代理和RPC。
和云原生将催生如此热门的服务网格。最重要的因素是库本内特斯的基础设施标准化。人们发现，以前这些沉重的RPC框架可以彼此分离。最初，维护中需要增加的复杂性由Kubernetes解决，并且强调了跨语言和服务治理的好处。此外，与代理相比，网格的边卡形式在请求的时间消耗上也有明显的优势。
微博将Motan RPC胖客户端实现的治理功能汇聚到代理。服务注册和发现依靠微博来自主研究Vintage命名和配置服务，订阅和发现服务来建立服务依赖的逻辑网络。该服务符合的通信协议。代理支持HTTP和RPC调用。该服务只需要将原始呼叫指向代理，不需要修改服务代码。
在跨语言通信协议设计方面，谷歌的协议缓冲区(pb)序列化可以提供出色的跨语言序列化能力，但是将旧的HTTP转换为pb协议太昂贵，并且一些语言(如PHP)在序列化复杂的pb对象方面性能很差，甚至比json序列化慢三倍。微博实现了一个新的语言无关的通讯协议Motan2和一个跨语言友好的数据序列化协议Simple来处理跨语言
除了代理服务，网格系统还提供服务生成，如缓存、队列等。服务提供者可以从相关的缓存和队列资源中分离出来它可以大大提高治理能力相对较弱的业务和语言的结构级别。
随着云本地技术的改进，越来越多的基础设施将从原始的SDK中抽象出来。将来，数据库访问将以数据库网格的形式提供，包括数据碎片封装、读写分离、库负载平衡、融合和链接获取。例如，谷歌云SQL提供了一个本地代理。业务方可以安全地访问云SQL，而无需将IP地址列入白名单或配置SSL。
