精华内容
下载资源
问答
  • 终于抽时间总结一下对云原生的理解。云原生是过去一年里云计算最火的用词之一。几乎每一个云计算的产品厂商都会把自己的产品与云原生联系在一起。但是到底这个词是什么意思,它的具体含义是什么,其实却是非常含糊的...

    终于抽时间总结一下对云原生的理解。

    云原生是过去一年里云计算最火的用词之一。几乎每一个云计算的产品厂商都会把自己的产品与云原生联系在一起。但是到底这个词是什么意思,它的具体含义是什么,其实却是非常含糊的。

    云原生这个词最早在2014年左右起源于Pivotal。Pivotal是一家做PaaS服务的公司。之后在2015年夏天,Linux基金会创建了云原生基金会CNCF。CNCF在宣布成立时也没有一个关于云原生的具体定义。只是提到了一些相关的技术,包括开源,容器,微服务,编排工具。但是并没有明确地描述怎样使用这些工具开发出来的应用才可以被称作云原生的应用。时至今日CNCF也还没有提出过这个明确的定义。

    于是很多公司按照自己的理解去使用这个概念。这导致在很多时候,大家是在说不同的事情。很多公司的理解是只要是涉及云的应用就是云原生。或者是可以给云服务用的工具或者产品就是云原生的。

    下面讨论一下云原生的含义,云原生的应用都有哪些特性,以及一个技术团队要成功开发和运维真正的云原生的应用所需要的4大支柱。

    究竟什么是云原生?

    云原生是云计算时代的新的团队文化,新的技术架构,和新的工程方式。

    云原生指的是一个灵活的工程团队,遵循敏捷的研发原则,使用高度自动化的研发工具,开发专门基于并部署在云基础设施上的应用,以满足快速变化的客户需求。这些应用采用自动化的,可扩展的,和高可用的架构。这个工程团队通过高效的云计算现网的运维来提供这一应用服务,并且根据线上反馈对服务进行不断地改进。

    我这里强调了几个关键字。一个是云基础设施。云原生的应用一定是会利用云计算,云存储等云资源创建的应用。这个应用也是一定会部署在云的基础设施上的。好的云设施都会提供自动化的,可扩展的,和高可用的架构以满足云原生应用的需求。

    另外一个就是灵活的工程团队。云原生的应用一定会是由灵活的工程团队开发的,以快速上线在云设施上,快速满足客户的需求。这个工程团队会使用大量的高度自动化的研发工具,才有可能快速的完成新功能的开发,测试和上线。

    最后,云原生的应用在上线到云上之后,工程团队会不断关注应用的运行情况。对这些应用进行运维管理,实时监测,解决随时出现的各种线上问题。云原生的研发团队还会收集应用的线上数据作为反馈,不断地进行分析并且基于这些反馈对应用进行持续的改进。

    云原生应用的特征

    一般的云原生的应用都会具有以下这些特征:普遍可访问 (Universal Availability)

    云原生的应用可以在任何地方从多前端访问。不需要特殊访问设备。没有网络或者地域的限制。高可用性(High Availability)

    云原生的应用可以充分利用云技术保持随时在线(24x7)。由于云服务多由计算集群提供,集群中一个节点的单点失败对服务影响小。节点失败也会触发自动恢复机制。新的服务节点会被启动,补充失去的资源。服务的升级和变更会采用灰度部署。在这个过程里,会对计算集群中的节点逐渐升级。现网流量会通过负载均衡器(LBS)在新旧版本的节点间分配流量。从而保证升级过程中,服务无中断。服务所涉及的数据会进行实时在线备份。在数据丢失的情况下可以使用数据备份进行数据恢复。对于更为严重的灾难性事件,云厂商大都会提供异地多活与同城双活的架构以保证服务的持续性。高扩展性(Scalability)

    云原生应用可以被在线用户随时访问。各种原因都有可能导致应用的流量在短时间内激增。云原生的应用可以随业务的需要随时迅捷地线性伸缩资源以应对流量在短时间内的大幅波动。可监控(Observability)

    云原生的应用在现网的运行一定不会是一个黑盒子。运维人员可以通过运维工具实时收集应用服务的健康信息。基于这些现网信息,运维人员可以及时察觉和解决现网出现的各种问题。安全性 (Security)

    云原生的应用通过对服务部署的网络(VPC)的设计,利用对网关和防火墙的设计和配置,对应用服务提供多层的安全保护。可抵御众多常规安全威胁。可迁移性 (Deployable to Different Cloud Providers)

    云原生的应用一定会具有很强的可迁移性。云原生的应用会与底层的云计算基础设施分离。整个应用易于迁移到不同的云计算供应商。甚至应用的不同服务可以部署到不同的云计算供应商。整个应用仍然可以正常且有效地运行。演进式设计与快速迭代 (Evolutionary Design and Fast Iteration)

    云原生的应用由于使用微服务架构,微服务之间相互解耦,导致它们可以独立开发,测试,部署和运维。这样每个服务可以独立创新。只要保持接口稳定,不会对应用的其他部分产生影响。而且云原生的工程团队会使用高度自动化的研发测试和运维工具。这使得云原生的应用的更新可以更加快速频繁。达成创新速度提高的最终目的。

    上面总结了云原生的应用应该具备的一些主要特征。可以用来辨别一个应用是不是真正的云原生的应用。

    云原生的4大支柱

    云原生作为一个云时代的企业组织文化,它有4大支柱。我把它们总结成TATO,即:Team & Process 团队与流程

    Architecture 架构

    Tools 工具

    Operations 运维

    这4大支柱从四个维度具体描述了云原生的本质含义。4大支柱里提及的每一点都可以进行大幅度地具体的技术展开。由于时间原因,我在这里只是提出提纲,以及一些少量的具体讨论。以后有机会再完成对每一点的更深入的展开。

    云原生的团队与流程小团队开发 (2-pizza Team)

    云原生的应用一般由多个小团队共同开发。各个团队负责应用的不同部分,即不同的微服务。这样才能使得团队具有灵活性,对客户要求进行快速反应。团队的具体大小没有固定的定义。一个参照是在午餐时,两个比萨饼可以把团队喂饱。全栈团队 (Full Stack Team)

    云原生的团队成员的工作性质会随着不同的项目而变化。每个工程师既负责开发,也负责测试。按照项目需要,可能前端和后端的开发工作都有。研发与运维的结合(DevOps)

    云原生团队的成员对微服务有端到端的责任(End to End Ownership)。他们既负责服务的开发,也负责服务的运维。这样工程师在做服务开发时就会考虑服务的可运维性。如何更好的部署?如何方便地排错?如何快速地回滚?如何在服务失败后尽快地恢复?而且这样做还使得工程师更贴近客户,了解应用是如何被客户使用的,从而更有效地对服务进行持续改进。去中心化(Decentralization)

    云原生团队对服务的开发和运维有充分的技术决策权。使用什么技术栈,什么工具,什么数据库都可以由团队在整体大方向下自主地根据具体项目需要来做最佳的选取。敏捷的研发流程 (Agile Development)

    云原生的团队由于更加贴近客户,所以对客户的需求有更好的了解。团队可以根据这种了解对工作内容和优先级做及时的调整。而不会被自上而下的统筹安排所束缚。从而得以极快的速度来满足客户的诉求。

    云原生的架构

    系统框架是云原生的另外一个基石。系统架构在任何计算机系统里都是至关重要的。系统的架构对系统的性能,可靠性,可扩展性,长期可维护性,和可运维性等等都起着决定性的作用。对于云原生系统也不例外。微服务化架构(Micro Service Architecture)

    云原生的应用一般不是单体架构,而是由一些功能专一的微服务组成。这些微服务高度解耦。相互之间沟通是通过接口调用。这些服务可以独立开发,测试,部署,和运维。基于云基础设施(Based on Cloud Infrastructure)

    云原生的应用都会搭建在基于云的基础设施上。应用会按需自动获取或释放云基础设施提供的计算,网络,存储等云服务。分布式云化部署 (Distributed Deployment)

    组成云原生应用的微服务大都部署在虚拟IP地址(VIP)后面的虚机集群的多个节点上。通过负载均衡器(ELB)来管理服务请求的分发。这样可以避免单机失败对服务的影响,提高服务的韧性。同时也方便调整资源的容量。这些服务还可以部署到不同地理区域的数据中心。这样可以获得更加坚固的冗余性。对全球客户的支持也会有更佳的性能。分布式部署的去中心化的服务可以使用自己独立的数据库存储,以满足服务的需要。无状态(Stateless)

    为了提高服务的处理效率和有效地支持服务的横向扩展,需要保证对服务的调用请求可以由任意一个节点处理。所以云原生应用会采取无状态的服务架构,服务请求中已包括处理此请求所需的足够信息。这样也会保证单点失败对服务功能无影响。无本地依赖 (Localless)

    分布式的多节点部署带来的一个问题是这些单个节点可以由于硬盘,网络等各种原因导致其失败。当一个节点失败时,节点上的数据也会丢失。因此,云原生的应用会尽量使用云资源而避免使用本地资源。比如使用云存储,云数据库,基于云的缓存,消息队列等等云服务。可水平自动弹性伸缩(Horizontal Auto Scaling)

    为了应对服务的流量变化,云原生的应用会利用无状态无本地依赖等架构设计使得应用的性能可以随着调整节点数量而得到线性调整。从而提高应用性能和资源利用率。应用可以通过自动伸缩引擎定义弹性伸缩的规则,使得在流量负载达到特定指标时在不经手工干预的情况下完成对资源的调整。在资源调整过程中,现有服务连接会被优雅地管理,做到前端无感知。服务注册与发现 (Service Registration and Discovery)

    像前面已经讨论的,分布式的多节点部署带来的一个问题是这些单个节点可以由于硬盘,网络等各种原因导致其失败。新的节点会补上来。另外计算节点在做自动伸缩时,节点地址也会发生动态变化。服务注册与发现可以体现服务的最新的可用节点。负载均衡器可以基于这个信息安排调用请求的导流。

    云原生的工具

    工欲善其事必先利其器。云原生的应用由很多微服务组成。云原生应用的特点就是能够快速更新以满足市场和用户的需要。应用的更新是通过微服务的快速更新迭代来实现的。行业顶尖公司的应用在现网更新是以秒级来计算的。也就是每天的更新可以达到近万次。为了支持如此高频的现网更新,同时还要保证更新的质量,有效的高度自动化的研发工具是能否成功地持续开发云原生应用的关键。自助环境获取(Self Serviced Environment Acquisition)

    无论是开发新功能,或者复现一个问题,工程师最大的抱怨就是建立相应的开发环境。装操作系统,装工具,下代码,做配置。要折腾好几天才可以开始看具体问题。切换成本非常大。所以有预制的开发资源(虚机或者容器),上面预装了相应的开发环境和配置,并且这些资源可以自助获取,可以大幅提高研发人员的工作效率。统一标准的服务开发框架或基础设施 (Standardized Service Framework or infrastructure)

    开发一个高质量的微服务,需要考虑的因素很多。除了服务本身的商业逻辑,还需要关注每个服务都需要处理的公共功能,例如身份验证与授权,限流,缓存,日志,监控与度量,等等。这样使得开发人员不能专注于自己的商业逻辑,降低了开发效率。而且对开发人员的要求也更高。公共功能的实现也不能达到一致的质量和行为。所以使用统一标准的服务开发框架有助于云原生应用的开发。Spring Boot是一个这样的开源的服务框架。亚马逊使用Coral服务框架。不过这些源代码级的服务框架会对编程语言有限制。最近兴起的服务网格(Service Mesh)从网络层面解决这个问题,应该是一个长期的发展方向。贴近现网环境的模拟开发环境 (Production Environment Simulation for Local Development)

    开发的一大痛点就是程序在开发机上运行正常,但是到现网环境不工作。简单的环境可以提供通过基础设施即代码(Infrastructure as Code)的方式自动建立。谷歌的Cloud Code工具就是采用这种做法。亚马逊的AWS CDK也提供了类似功能。

    依赖复杂环境和相关数据的程序调试则相对困难。同一服务的多个版本的存在更需要借助API网关进行管理。即使这样仍需要把开发机的最新代码打包部署到测试环境,无法直接在开发人员本地的开发机上进行代码调试,降低开发效率。目前最佳的解决办法是使用开源的Telepresence用双向代理把本地开发机接入到测试环境里。这样本地机被虚拟成在测试环境里的一个节点。开发者就可以直接在本机上做调试了。分布式跟踪(Distributed Tracing)

    一个用户服务请求很有可能需要提供调用多个服务完成,即A服务调用B服务,B服务调用C服务的方式。于是用于跨服务的调用链的跟踪就变得非常重要。像Zipkin,Jaeger这样的分布式跟踪工具可以提供这种的能力。这样在做端到端的调试和调用链分析的时候就非常有用了。测试自动化 (Test Automation)

    应用的质量至关重要。对要上线的功能执行相应测试用例才能确认软件包的质量。快速上线的要求需要测试用例的高度自动化来保障。首先是自动化尽量多的单元测试。功能测试中的API测试由于不涉及UI,所以测试用例的自动化也比较好维护。因此在设计功能的测试用例时,尽量使用API测试。对于UI测试,由于UI可能的变化,UI在测试运行时所处状态和时间问题,导致UI的自动化测试用例的运行不够稳定。所以在设计UI测试用例时要着重注意提高测试稳定性。需要考虑的策略包括:使用类似辅助功能模型(accessibility model)的功能来驱动UI,初始状态的检验和重设,用智能等待(smart wait)解决时间问题(timing issue),简化或者隔离测试环境以降低环境噪音。最后就是有足够的测试日志和截屏信息。这样当有测试用例失败时,可以迅速找到失败的原因。场景模拟 (Scenario Simulation)

    当你调试应用的一些时候,你需要调用到其他服务。并且需要这些接口返回特定的数据。有时候这些接口还没有准备好,或者设置那个接口返回你所需要的数据比较困难。这时可以采用接口模拟工具(mock)去模拟你需要的场景。A/B测试 (A/B Testing)

    云原生的应用应该利用云应用的实时反馈优势,理解客户的诉求。像开源软件Convert就是一个不错的A/B测试的选择。开发者工具网站 (Simple developer web portal)

    这个比较容易理解。所有研发工具最好有一个公共入口。这样可以提高工具的可发现性。持续集成 (Continuous Integration)

    一个应用一般会有很多服务组成。这些服务都在由不同的研发团队并行开发。持续集成系统会定期把不同开发人员提交的新代码集成在一起,进行编译和自动化测试。以时刻保证应用的质量。持续交付流水线 (CD Pipeline)

    与持续集成相关的是持续交付流水线。持续交付流水线的目的是确认应用发布包的质量并最终将发布包部署到现网环境。持续交付流水线一般会包含几个阶段。每一个阶段会对应一个部署环境。每一个阶段会定义此阶段需要执行的测试内容。流水线会负责这些环境的管理并根据每个阶段的测试执行结果决定是否把新的发布包沿着流水线继续向前推动。Jenkins是目前极为流行的CI/CD的执行工具。灰度发布和回滚自动化 (Gray Release and Automated Rollback)

    研发的最后一步就是把发布包部署到现网。云原生的应用在新版本更新时要保证服务的持续性。如果一个应用仍然需要定期地下线进行维护,在此时间段不能使用,那这个应用还没有完成云原生的征程。云原生的应用经常会通过灰度发布等方式达到服务的持续性。灰度发布过程中,灰度发布引擎会先把部分节点下线,进行服务的版本更新和测试。版本更新过程一般不会覆盖旧的版本,这样在需要的时候方便版本回滚。新版本测试成功后,会把更新后的节点上线,把现网的正常流量部分导流到新版本的节点上。如此循环操作,直到所有节点都转到新版本上。在这个发布的过程里,如果发生新版本更新失败,灰度发布引擎会触发回滚机制,把已更新的版本节点回退到更新前的版本。当然在这个过程里会涉及到具体的升级和回滚的策略,比如每次升级的节点数量,现网导流到新节点的流量,如何定义更新失败,回滚的次序和节点数量等等,都可以在灰度发布引擎中定义。依赖与版本管理 (Dependency and Version Management)

    云原生的应用使用微服务的架构。微服务的功能相对独立。微服务需要与其他微服务合作去完成某项任务。不同版本的服务功能会有所不同。有时某个服务需要另外一个服务的某个特定版本里的功能。这就产生了服务的版本依赖。在服务众多的情况下,这个依赖关系会比较复杂。依赖和版本的有效管理对服务编译和上线的运维都有重要的影响。亚马逊的VersionSet和LinkedIn的Dependency Service从不同角度去解决这个问题。

    如果你看到了这里,希望上面的内容对你有帮助。

    上面讨论了云原生的具体含义是什么,云原生应用具备哪些特征,以及云原生的4大支柱TATO里面的3个,即团队与流程,架构,和工具。下面有时间我会再加上关于第4大支柱,即云原生的运维的讨论。如果有需要切磋,可以下面微信联系我。

    展开全文
  • 终于抽时间总结一下对云原生的理解。云原生是过去一年里云计算最火的用词之一。几乎每一个云计算的产品厂商都会把自己的产品与云原生联系在一起。但是到底这个词是什么意思,它的具体含义是什么,其实却是非常含糊的...

    3b5e8ec33e8ed260e4edb957ebaf45b8.png

    终于抽时间总结一下对云原生的理解。

    云原生是过去一年里云计算最火的用词之一。几乎每一个云计算的产品厂商都会把自己的产品与云原生联系在一起。但是到底这个词是什么意思,它的具体含义是什么,其实却是非常含糊的。

    云原生这个词最早在2014年左右起源于Pivotal。Pivotal是一家做PaaS服务的公司。之后在2015年夏天,Linux基金会创建了云原生基金会CNCF。CNCF在宣布成立时也没有一个关于云原生的具体定义。只是提到了一些相关的技术,包括开源,容器,微服务,编排工具。但是并没有明确地描述怎样使用这些工具开发出来的应用才可以被称作云原生的应用。时至今日CNCF也还没有提出过这个明确的定义。

    于是很多公司按照自己的理解去使用这个概念。这导致在很多时候,大家是在说不同的事情。很多公司的理解是只要是涉及云的应用就是云原生。或者是可以给云服务用的工具或者产品就是云原生的。

    下面讨论一下云原生的含义,云原生的应用都有哪些特性,以及一个技术团队要成功开发和运维真正的云原生的应用所需要的4大支柱。

    究竟什么是云原生?

    云原生是云计算时代的新的团队文化,新的技术架构,和新的工程方式。

    云原生指的是一个灵活的工程团队,遵循敏捷的研发原则,使用高度自动化的研发工具,开发专门基于并部署在云基础设施上的应用,以满足快速变化的客户需求。这些应用采用自动化的,可扩展的,和高可用的架构。这个工程团队通过高效的云计算现网的运维来提供这一应用服务,并且根据线上反馈对服务进行不断地改进。

    我这里强调了几个关键字。一个是云基础设施。云原生的应用一定是会利用云计算,云存储等云资源创建的应用。这个应用也是一定会部署在云的基础设施上的。好的云设施都会提供自动化的,可扩展的,和高可用的架构以满足云原生应用的需求。

    另外一个就是灵活的工程团队。云原生的应用一定会是由灵活的工程团队开发的,以快速上线在云设施上,快速满足客户的需求。这个工程团队会使用大量的高度自动化的研发工具,才有可能快速的完成新功能的开发,测试和上线。

    最后,云原生的应用在上线到云上之后,工程团队会不断关注应用的运行情况。对这些应用进行运维管理,实时监测,解决随时出现的各种线上问题。云原生的研发团队还会收集应用的线上数据作为反馈,不断地进行分析并且基于这些反馈对应用进行持续的改进。

    云原生应用的特征

    一般的云原生的应用都会具有以下这些特征:

    • 普遍可访问 (Universal Availability)

    云原生的应用可以在任何地方从多前端访问。不需要特殊访问设备。没有网络或者地域的限制。

    • 高可用性(High Availability)

    云原生的应用可以充分利用云技术保持随时在线(24x7)。由于云服务多由计算集群提供,集群中一个节点的单点失败对服务影响小。节点失败也会触发自动恢复机制。新的服务节点会被启动,补充失去的资源。服务的升级和变更会采用灰度部署。在这个过程里,会对计算集群中的节点逐渐升级。现网流量会通过负载均衡器(LBS)在新旧版本的节点间分配流量。从而保证升级过程中,服务无中断。服务所涉及的数据会进行实时在线备份。在数据丢失的情况下可以使用数据备份进行数据恢复。对于更为严重的灾难性事件,云厂商大都会提供异地多活与同城双活的架构以保证服务的持续性。

    • 高扩展性(Scalability)

    云原生应用可以被在线用户随时访问。各种原因都有可能导致应用的流量在短时间内激增。云原生的应用可以随业务的需要随时迅捷地线性伸缩资源以应对流量在短时间内的大幅波动。

    • 可监控(Observability)

    云原生的应用在现网的运行一定不会是一个黑盒子。运维人员可以通过运维工具实时收集应用服务的健康信息。基于这些现网信息,运维人员可以及时察觉和解决现网出现的各种问题。

    • 安全性 (Security)

    云原生的应用通过对服务部署的网络(VPC)的设计,利用对网关和防火墙的设计和配置,对应用服务提供多层的安全保护。可抵御众多常规安全威胁。

    • 可迁移性 (Deployable to Different Cloud Providers)

    云原生的应用一定会具有很强的可迁移性。云原生的应用会与底层的云计算基础设施分离。整个应用易于迁移到不同的云计算供应商。甚至应用的不同服务可以部署到不同的云计算供应商。整个应用仍然可以正常且有效地运行。

    • 演进式设计与快速迭代 (Evolutionary Design and Fast Iteration)

    云原生的应用由于使用微服务架构,微服务之间相互解耦,导致它们可以独立开发,测试,部署和运维。这样每个服务可以独立创新。只要保持接口稳定,不会对应用的其他部分产生影响。而且云原生的工程团队会使用高度自动化的研发测试和运维工具。这使得云原生的应用的更新可以更加快速频繁。达成创新速度提高的最终目的。

    上面总结了云原生的应用应该具备的一些主要特征。可以用来辨别一个应用是不是真正的云原生的应用。

    云原生的4大支柱

    云原生作为一个云时代的企业组织文化,它有4大支柱。我把它们总结成TATO,即:

    • Team & Process 团队与流程
    • Architecture 架构
    • Tools 工具
    • Operations 运维

    06369d0f9f929289d8b27000bffd9f00.png

    这4大支柱从四个维度具体描述了云原生的本质含义。4大支柱里提及的每一点都可以进行大幅度地具体的技术展开。由于时间原因,我在这里只是提出提纲,以及一些少量的具体讨论。以后有机会再完成对每一点的更深入的展开。

    云原生的团队与流程

    • 小团队开发 (2-pizza Team)

    云原生的应用一般由多个小团队共同开发。各个团队负责应用的不同部分,即不同的微服务。这样才能使得团队具有灵活性,对客户要求进行快速反应。团队的具体大小没有固定的定义。一个参照是在午餐时,两个比萨饼可以把团队喂饱。

    • 全栈团队 (Full Stack Team)

    云原生的团队成员的工作性质会随着不同的项目而变化。每个工程师既负责开发,也负责测试。按照项目需要,可能前端和后端的开发工作都有。

    • 研发与运维的结合(DevOps)

    云原生团队的成员对微服务有端到端的责任(End to End Ownership)。他们既负责服务的开发,也负责服务的运维。这样工程师在做服务开发时就会考虑服务的可运维性。如何更好的部署?如何方便地排错?如何快速地回滚?如何在服务失败后尽快地恢复?而且这样做还使得工程师更贴近客户,了解应用是如何被客户使用的,从而更有效地对服务进行持续改进。

    • 去中心化(Decentralization)

    云原生团队对服务的开发和运维有充分的技术决策权。使用什么技术栈,什么工具,什么数据库都可以由团队在整体大方向下自主地根据具体项目需要来做最佳的选取。

    • 敏捷的研发流程 (Agile Development)

    云原生的团队由于更加贴近客户,所以对客户的需求有更好的了解。团队可以根据这种了解对工作内容和优先级做及时的调整。而不会被自上而下的统筹安排所束缚。从而得以极快的速度来满足客户的诉求。

    云原生的架构

    系统框架是云原生的另外一个基石。系统架构在任何计算机系统里都是至关重要的。系统的架构对系统的性能,可靠性,可扩展性,长期可维护性,和可运维性等等都起着决定性的作用。对于云原生系统也不例外。

    • 微服务化架构(Micro Service Architecture)

    云原生的应用一般不是单体架构,而是由一些功能专一的微服务组成。这些微服务高度解耦。相互之间沟通是通过接口调用。这些服务可以独立开发,测试,部署,和运维。

    • 基于云基础设施(Based on Cloud Infrastructure)

    云原生的应用都会搭建在基于云的基础设施上。应用会按需自动获取或释放云基础设施提供的计算,网络,存储等云服务。

    • 分布式云化部署 (Distributed Deployment)

    组成云原生应用的微服务大都部署在虚拟IP地址(VIP)后面的虚机集群的多个节点上。通过负载均衡器(ELB)来管理服务请求的分发。这样可以避免单机失败对服务的影响,提高服务的韧性。同时也方便调整资源的容量。这些服务还可以部署到不同地理区域的数据中心。这样可以获得更加坚固的冗余性。对全球客户的支持也会有更佳的性能。分布式部署的去中心化的服务可以使用自己独立的数据库存储,以满足服务的需要。

    • 无状态(Stateless)

    为了提高服务的处理效率和有效地支持服务的横向扩展,需要保证对服务的调用请求可以由任意一个节点处理。所以云原生应用会采取无状态的服务架构,服务请求中已包括处理此请求所需的足够信息。这样也会保证单点失败对服务功能无影响。

    • 无本地依赖 (Localless)

    分布式的多节点部署带来的一个问题是这些单个节点可以由于硬盘,网络等各种原因导致其失败。当一个节点失败时,节点上的数据也会丢失。因此,云原生的应用会尽量使用云资源而避免使用本地资源。比如使用云存储,云数据库,基于云的缓存,消息队列等等云服务。

    • 可水平自动弹性伸缩(Horizontal Auto Scaling)

    为了应对服务的流量变化,云原生的应用会利用无状态无本地依赖等架构设计使得应用的性能可以随着调整节点数量而得到线性调整。从而提高应用性能和资源利用率。应用可以通过自动伸缩引擎定义弹性伸缩的规则,使得在流量负载达到特定指标时在不经手工干预的情况下完成对资源的调整。在资源调整过程中,现有服务连接会被优雅地管理,做到前端无感知。

    • 服务注册与发现 (Service Registration and Discovery)

    像前面已经讨论的,分布式的多节点部署带来的一个问题是这些单个节点可以由于硬盘,网络等各种原因导致其失败。新的节点会补上来。另外计算节点在做自动伸缩时,节点地址也会发生动态变化。服务注册与发现可以体现服务的最新的可用节点。负载均衡器可以基于这个信息安排调用请求的导流。

    云原生的工具

    工欲善其事必先利其器。云原生的应用由很多微服务组成。云原生应用的特点就是能够快速更新以满足市场和用户的需要。应用的更新是通过微服务的快速更新迭代来实现的。行业顶尖公司的应用在现网更新是以秒级来计算的。也就是每天的更新可以达到近万次。为了支持如此高频的现网更新,同时还要保证更新的质量,有效的高度自动化的研发工具是能否成功地持续开发云原生应用的关键。

    • 自助环境获取(Self Serviced Environment Acquisition)

    无论是开发新功能,或者复现一个问题,工程师最大的抱怨就是建立相应的开发环境。装操作系统,装工具,下代码,做配置。要折腾好几天才可以开始看具体问题。切换成本非常大。所以有预制的开发资源(虚机或者容器),上面预装了相应的开发环境和配置,并且这些资源可以自助获取,可以大幅提高研发人员的工作效率。

    • 统一标准的服务开发框架或基础设施 (Standardized Service Framework or infrastructure)

    开发一个高质量的微服务,需要考虑的因素很多。除了服务本身的商业逻辑,还需要关注每个服务都需要处理的公共功能,例如身份验证与授权,限流,缓存,日志,监控与度量,等等。这样使得开发人员不能专注于自己的商业逻辑,降低了开发效率。而且对开发人员的要求也更高。公共功能的实现也不能达到一致的质量和行为。所以使用统一标准的服务开发框架有助于云原生应用的开发。Spring Boot是一个这样的开源的服务框架。亚马逊使用Coral服务框架。不过这些源代码级的服务框架会对编程语言有限制。最近兴起的服务网格(Service Mesh)从网络层面解决这个问题,应该是一个长期的发展方向。

    • 贴近现网环境的模拟开发环境 (Production Environment Simulation for Local Development)

    开发的一大痛点就是程序在开发机上运行正常,但是到现网环境不工作。简单的环境可以提供通过基础设施即代码(Infrastructure as Code)的方式自动建立。谷歌的Cloud Code工具就是采用这种做法。亚马逊的AWS CDK也提供了类似功能。

    依赖复杂环境和相关数据的程序调试则相对困难。同一服务的多个版本的存在更需要借助API网关进行管理。即使这样仍需要把开发机的最新代码打包部署到测试环境,无法直接在开发人员本地的开发机上进行代码调试,降低开发效率。目前最佳的解决办法是使用开源的Telepresence用双向代理把本地开发机接入到测试环境里。这样本地机被虚拟成在测试环境里的一个节点。开发者就可以直接在本机上做调试了。

    • 分布式跟踪(Distributed Tracing)

    一个用户服务请求很有可能需要提供调用多个服务完成,即A服务调用B服务,B服务调用C服务的方式。于是用于跨服务的调用链的跟踪就变得非常重要。像Zipkin,Jaeger这样的分布式跟踪工具可以提供这种的能力。这样在做端到端的调试和调用链分析的时候就非常有用了。

    • 测试自动化 (Test Automation)

    应用的质量至关重要。对要上线的功能执行相应测试用例才能确认软件包的质量。快速上线的要求需要测试用例的高度自动化来保障。首先是自动化尽量多的单元测试。功能测试中的API测试由于不涉及UI,所以测试用例的自动化也比较好维护。因此在设计功能的测试用例时,尽量使用API测试。对于UI测试,由于UI可能的变化,UI在测试运行时所处状态和时间问题,导致UI的自动化测试用例的运行不够稳定。所以在设计UI测试用例时要着重注意提高测试稳定性。需要考虑的策略包括:使用类似辅助功能模型(accessibility model)的功能来驱动UI,初始状态的检验和重设,用智能等待(smart wait)解决时间问题(timing issue),简化或者隔离测试环境以降低环境噪音。最后就是有足够的测试日志和截屏信息。这样当有测试用例失败时,可以迅速找到失败的原因。

    • 场景模拟 (Scenario Simulation)

    当你调试应用的一些时候,你需要调用到其他服务。并且需要这些接口返回特定的数据。有时候这些接口还没有准备好,或者设置那个接口返回你所需要的数据比较困难。这时可以采用接口模拟工具(mock)去模拟你需要的场景。

    • A/B测试 (A/B Testing)

    云原生的应用应该利用云应用的实时反馈优势,理解客户的诉求。像开源软件Convert就是一个不错的A/B测试的选择。

    • 开发者工具网站 (Simple developer web portal)

    这个比较容易理解。所有研发工具最好有一个公共入口。这样可以提高工具的可发现性。

    • 持续集成 (Continuous Integration)

    一个应用一般会有很多服务组成。这些服务都在由不同的研发团队并行开发。持续集成系统会定期把不同开发人员提交的新代码集成在一起,进行编译和自动化测试。以时刻保证应用的质量。

    • 持续交付流水线 (CD Pipeline)

    与持续集成相关的是持续交付流水线。持续交付流水线的目的是确认应用发布包的质量并最终将发布包部署到现网环境。持续交付流水线一般会包含几个阶段。每一个阶段会对应一个部署环境。每一个阶段会定义此阶段需要执行的测试内容。流水线会负责这些环境的管理并根据每个阶段的测试执行结果决定是否把新的发布包沿着流水线继续向前推动。Jenkins是目前极为流行的CI/CD的执行工具。

    • 灰度发布和回滚自动化 (Gray Release and Automated Rollback)

    研发的最后一步就是把发布包部署到现网。云原生的应用在新版本更新时要保证服务的持续性。如果一个应用仍然需要定期地下线进行维护,在此时间段不能使用,那这个应用还没有完成云原生的征程。云原生的应用经常会通过灰度发布等方式达到服务的持续性。灰度发布过程中,灰度发布引擎会先把部分节点下线,进行服务的版本更新和测试。版本更新过程一般不会覆盖旧的版本,这样在需要的时候方便版本回滚。新版本测试成功后,会把更新后的节点上线,把现网的正常流量部分导流到新版本的节点上。如此循环操作,直到所有节点都转到新版本上。在这个发布的过程里,如果发生新版本更新失败,灰度发布引擎会触发回滚机制,把已更新的版本节点回退到更新前的版本。当然在这个过程里会涉及到具体的升级和回滚的策略,比如每次升级的节点数量,现网导流到新节点的流量,如何定义更新失败,回滚的次序和节点数量等等,都可以在灰度发布引擎中定义。

    • 依赖与版本管理 (Dependency and Version Management)

    云原生的应用使用微服务的架构。微服务的功能相对独立。微服务需要与其他微服务合作去完成某项任务。不同版本的服务功能会有所不同。有时某个服务需要另外一个服务的某个特定版本里的功能。这就产生了服务的版本依赖。在服务众多的情况下,这个依赖关系会比较复杂。依赖和版本的有效管理对服务编译和上线的运维都有重要的影响。亚马逊的VersionSet和LinkedIn的Dependency Service从不同角度去解决这个问题。

    如果你看到了这里,希望上面的内容对你有帮助。

    上面讨论了云原生的具体含义是什么,云原生应用具备哪些特征,以及云原生的4大支柱TATO里面的3个,即团队与流程,架构,和工具。下面有时间我会再加上关于第4大支柱,即云原生的运维的讨论。如果有需要切磋,可以下面微信联系我。

    db4bce1da6259fe261836048ef1ca954.png
    展开全文
  • 原生的不同解释及正确含义

    千次阅读 2019-12-12 19:28:00
    原生的解释可以说五花八门,本文从不同角度探讨云原生的内涵以及如何从不同维度准确理解它的含义。 云原生起源 网上有些文章提到云原生是“Pivotal公司的Matt Stine于2013年首次提出云原生(CloudNative)的概念”...

    云原生的解释可以说五花八门,本文从不同角度探讨云原生的内涵以及如何从不同维度准确理解它的含义。

    云原生起源

    网上有些文章提到云原生是“Pivotal公司的Matt Stine于2013年首次提出云原生(CloudNative)的概念”。我搜索了英文“CloudNative”,阅读了首页的所有文章,里面没有一篇提到“Matt Stine首次提出云原生”,但它们每一篇都提到了“云原生计算基金会”的定义。“Matt Stine”确实写了一本书,叫《迁移到云原生架构》,他以前确实在Pivotal公司工作,但说他“首次提出云原生(CloudNative)的概念”应该是不准确的, 而且他的定义和云原生的含义是有一定偏差的。

    我觉得比较接近的说法是Netflix公司首创了云原生,详见Going Cloud Native: 6 essential things you need to know

    虽然那篇文章主要是讲的Netflix如何开创了微服务,但Netflix的微服务是部署在亚马逊云上的。而当时亚马逊云也才刚起步,各方面都不成熟,Netflix是它的最大客户。是Netflix的层出不穷的需求帮助亚马逊云不断完善它的功能和性能,最终登顶云服务商。因此Netflix的微服务演进是和云计算交织在一起,共同推进的。Netflix在微服务领域的开创和领先地位是大家公认的,它的“Netflix OOS”系列工具至今仍被广泛使用,特别是Java社区,并被移植到其他语言。在这个过程中,也同时开创了云计算的先河,它的起点是2009年。详情请见Goto Berlin - Migrating to Microservices (Fast Delivery)

    但我想说的是云计算(Cloud)和云原生(Cloud Native)还是有很大区别的。Netflix是云计算的开拓者,但并不是云原生的创造者。云原生的基石是k8s,没有k8s就没有云原生, 而k8s的1.0版诞生于2015年。云原生计算基金会(CNCF)也诞生于2015年并致力于推动云原生的发展。云原生的概念是在2017才开始被广泛接受和流行,因此云原生和云计算是由本质区别的。云原生的诞生是和云原生计算基金会密切相关的。

    云原生计算基金会(CNCF)的定义:

    下面就让我们看一下CNCF给出的云原生的定义:

    “云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中,构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段,云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。
    云原生计算基金会(CNCF)致力于培育和维护一个厂商中立的开源生态系统,来推广云原生技术。我们通过将最前沿的模式民主化,让这些创新为大众所用。”

    摘要来源:CNCF Cloud Native Definition v1.0

    这个定义还是比较靠谱的,尽管它并不严谨,也并没有挖掘出云原生的本质。但考虑到每个组织的目的和立场不同,看问题的角度不同,CNCF的主要目的是培育云原生工具市场,因此它的定义带有很重的实用色彩,偏重工具方面。若是从这个角度看,这个定义还是比较贴切的。我觉得唯一不严谨的地方是把微服务列了进去,其他的都没什么问题。

    让我们来分析一下定义中提到的工具。其中k8s是整个云原生的基石,也是CNCF的第一个项目。云原生的整个生态体系都是依靠k8s建立起来的。因此在k8s之前是不可能有云原生的。定义里还提到了容器(Container)、服务网格(Service Mesh)、微服务(Microservice)、不可变基础设施(immutable infrastructure)和声明式API(declarative APIs)。其中容器(Container)是k8s的底层引擎,服务网格(Service Mesh)是建立在k8s上的针对请求的扩展功能,不可变基础设施(immutable infrastructure)是现代运维的基石,声明式API(declarative APIs)是k8s的编码方式,这些无一不是和k8s紧密相关的。但微服务(Microservice)就不同了,它其实跟云原生没什么关系,它们是两个完全不同的东西并沿着各自的轨道独立向前发展。但由于认容器技术和微服务是天生的良配,它们现在的演进轨道交织在一起密不可分。

    但实际上没有容器技术,微服务也可以部署在虚机上,只不过资源的利用率可能不够高。没有微服务,容器技术虽然不能大展宏图,但也能在分布式应用里找到一席之地。当然把它们放在一起确实能如虎添翼,但把微服务划归到云原生里实在是有点扩大外延,跑马圈地的意味。因为云原生的重点还是在基础设施,运维和运行环境以及软件的开发环境,而微服务是一个软件的架构,两者之间有明显的不同。

    云原生的表层含义

    那么到底什么是“云原生(Cloud Native)”呢?它分表层含义和深层含义。表层含义从字面上理解就比较容易了,我们管母语叫“Native Language”,也就是你一生下来就说的语言。“Cloud Native”就是一开始开发的时候就是为了最终部署到云环境上的。而在云计算初创时,大部分的程序都是从本地环境移植到云上的,它们在设计是就根本没考虑云环境的问题。

    云环境与本地环境的差异

    那么部署到云环境和部署到本地服务器有什么不同?这个才是问题的本质。

    你可能会说“是容器技术”,这个是现代云计算的不可或缺的支撑,但云计算开始的时候是基于虚拟化的,并没有容器技术,是在发展的过程中才有了容器技术。
    是“自动伸缩(auto-scaling)”吗?这是云环境的一个主要优点和特性,但它只是结果,不是本质。

    云技术的三大基石:

    基础设施即代码 (Infrastructure As Code)

    基础设施即代码是指把创建基础设施(包括服务器和网络环境)的命令像应用程序一样储存在源码库中,并进行版本管理。这样创建基础设施的过程就变成了部署软件的过程。它的最大的好处就是可重复性。以前的方法是用人工敲入命令来创建运行环境,出了问题就在原来的基础之上进行修修补补,一旦需要把整个环境重新建立,很难保证与原来的一样。 当使用基础设施即代码之后,再也没有了这个担心。

    详情请见 InfrastructureAsCode

    不可变基础设施(immutable infrastructure)

    说道这里,我们不得不提“不可变基础设施(immutable infrastructure)“,它是基础设施即代码的升级版。有了基础设施即代码之后,随时都可以通过运行软件再构建出一个一模一样的服务器和其他需要的设备,并且还能预装应用程序,创建的时间还是秒级的。这时当服务器出现问题时,就没有必要去花时间查找原因了并修复了,而是直接把服务器销毁重新创建一个新的。因此这时的基础设施是不可变的,只有创建和删除,而没有修改操作。这彻底改变了运维的方式。

    详情请见 What is “Immutable Infrastructure”?

    声明式API(declarative APIs)

    声明式API也是基础设施即代码的升级版。最开始时,当用软件定义基础设施时是用的过程式描述,也就是通过运行一系列的命令来创建运行环境。后来发现更好的办法是描述最终运行环境的状态,而由系统来决定如何来创建这个环境。例如,你的描述就变成“创建一个有三个Nginx的集群”,而不是把创建Nginx的命令运行三次组成一个集群。这样的好处是当运行环境与描述不符合时,系统能检测到差异,并自动修复,这样系统就有了自动容错的功能。

    上面讲了云计算环境和传统基础设施的不同,其实随着云计算的发展,传统基础设施也在不断地采纳云计算的先进技术和理念,例如虚拟化和容器技术,而各个云计算厂商也提供了本地私有云的版本。只不过在公有云上的管理功能更强大,而通常本地私有云的版本是公有云的一个简化版。

    云原生应用程序的不同

    上面讲到了,只有一开始就是按照部署到云环境的要求来设计的应用程序才是云原生的。那么部署到云环境需要做哪些特殊设计呢?

    它主要有两个部分:
    第一部分是服务调用。不论是微服务之间的调用,还是微服务调用数据库或前端调用后端,调用的方式都是一样的。都需要知道IP地址,端口和协议,例如“http://127.0.0.1:80”, 其中“http”是协议,“127.0.0.1”是IP地址,“80”是端口。由于程序是部署在k8s上的,k8s会负责程序之间的寻址和调用。由于k8s会自动销毁出错的服务器,并创建新的服务器,IP地址就变成了动态的,而不是静态的。这时就只能通过服务名而不是IP地址来进行调用。也就是说k8s会给每个服务一个服务名,并通过k8s内部的DNS对服务名进行寻址。服务名是写在k8s的配置文件里的,软件设计的关键让应用程序和k8s配置文件都共享相同的调用地址。

    第二部分是数据的持久存储。在程序运行时,经常要访问持久存储(硬盘)上的数据,例如日志,配置文件或临时共享数据。程序在容器中运行,一旦出现问题,容器会被摧毁,k8s会自动重新生成一个与原来一模一样的容器,并在上面重新部署应用程序。在集群环境下,用户感觉不到容器故障,因为系统已经自动修复了。但当容器被摧毁时,容器上的数据也一起被摧毁了,因此要保证程序运行的连续性,就要让持久存储不受容器故障的影响。

    如果你对它的具体设计感兴趣,请参见把应用程序迁移到k8s需要修改什么?

    云原生的深层含义

    不过云原生还有一层引申含义。当你的最终生产环境是云环境时,你的本地开发环境最好也是云环境,这虽然不是必须的,但它能保证本地环境和生产环境的一致性,减少部署时的意外,是一个很自然的选择。而要在本地使用云环境来进行开发,你需要一系列的工具来保证开发的顺利和高效。要想了解云原生的开发环境及工具,请继续阅读下一篇“ 云原生开发环境初探"。

    索引:

    1. Going Cloud Native: 6 essential things you need to know
    2. Goto Berlin - Migrating to Microservices (Fast Delivery)
    3. CNCF Cloud Native Definition v1.0
    4. InfrastructureAsCode
    5. What is “Immutable Infrastructure”?
    6. 把应用程序迁移到k8s需要修改什么?
    7. 云原生开发环境初探

    不堆砌术语,不罗列架构,不迷信权威,不盲从流行,坚持独立思考

    展开全文
  • xmlhttp.readyState值及解释: 0:请求未初始化(还没有调用 open())。 1:请求已经建立,但是还没有发送(还没有调用 send())。 2:请求已发送,正在处理中(通常现在可以从响应中获取内容头)。 3:请求在...

    xmlhttp.readyState的值及解释:

    0:请求未初始化(还没有调用 open())。

    1:请求已经建立,但是还没有发送(还没有调用 send())。

    2:请求已发送,正在处理中(通常现在可以从响应中获取内容头)。

    3:请求在处理中;通常响应中已有部分数据可用了,但是服务器还没有完成响应的生成。

    4:响应已完成;您可以获取并使用服务器的响应了。

    xmlhttp.status的值及解释:

    100——客户必须继续发出请求

    101——客户要求服务器根据请求转换HTTP协议版本

    200——交易成功

    201——提示知道新文件的URL

    202——接受和处理、但处理未完成

    203——返回信息不确定或不完整

    204——请求收到,但返回信息为空

    205——服务器完成了请求,用户代理必须复位当前已经浏览过的文件

    206——服务器已经完成了部分用户的GET请求

    300——请求的资源可在多处得到

    301——删除请求数据

    302——在其他地址发现了请求数据

    303——建议客户访问其他URL或访问方式

    304——客户端已经执行了GET,但文件未变化

    305——请求的资源必须从服务器指定的地址得到

    306——前一版本HTTP中使用的代码,现行版本中不再使用

    307——申明请求的资源临时性删除

    400——错误请求,如语法错误

    401——请求授权失败

    402——保留有效ChargeTo头响应

    403——请求不允许

    404——没有发现文件、查询或URl

    405——用户在Request-Line字段定义的方法不允许

    406——根据用户发送的Accept拖,请求资源不可访问

    407——类似401,用户必须首先在代理服务器上得到授权

    408——客户端没有在用户指定的饿时间内完成请求

    409——对当前资源状态,请求不能完成

    410——服务器上不再有此资源且无进一步的参考地址

    411——服务器拒绝用户定义的Content-Length属性请求

    412——一个或多个请求头字段在当前请求中错误

    413——请求的资源大于服务器允许的大小

    414——请求的资源URL长于服务器允许的长度

    415——请求资源不支持请求项目格式

    416——请求中包含Range请求头字段,在当前请求资源范围内没有range指示值,请求也不包含If-Range请求头字段

    417——服务器不满足请求Expect头字段指定的期望值,如果是代理服务器,可能是下一级服务器不能满足请求

    合起来

    500——服务器产生内部错误

    501——服务器不支持请求的函数

    502——服务器暂时不可用,有时是为了防止发生系统过载

    503——服务器过载或暂停维修

    504——关口过载,服务器使用另一个关口或服务来响应用户,等待时间设定值较长

    505——服务器不支持或拒绝支请求头中指定的HTTP版本

    1xx:信息响应类,表示接收到请求并且继续处理

    2xx:处理成功响应类,表示动作被成功接收、理解和接受

    3xx:重定向响应类,为了完成指定的动作,必须接受进一步处理

    4xx:客户端错误,客户请求包含语法错误或者是不能正确执行

    5xx:服务端错误,服务器不能正确执行一个正确的请求

    xmlhttp.readyState==4 && xmlhttp.status==200的解释:请求完成并且成功返回

    转载于:https://www.cnblogs.com/danruoyanyun/p/11089160.html

    展开全文
  • “云原生”(Cloud Native)一词在 2019 年被技术界广泛使用,但是却没有关于这个词一个特别明确定义。主要困惑在于,“云原生”与您应用程序部署到环境几乎没有关系,该术语同样适用于私有云和公共云。该术语...
  • 但是到底这个词是什么意思,它具体含义是什么,其实却是非常含糊。云原生是一个灵活工程团队,遵循敏捷研发原则,使用高度自动化研发工具,开发专门基于并部署在云基础设施上应用,以满足快速变化...
  • 云计算的滚滚浪潮始于2006年,AWS的成立让公有云成为了整个云行业的标杆,也形成了云原生的技术洪流,推动了企业上云和全行业数字化转型的开启。作为云时代的技术基础,...时至今日,云原生这个词已经有了新的含义。...
  • 但到底原生的含义是什么呢? 目前开发移动应用程序时,现存的平台数量众多是一个真正的问题。 只要移动应用程序开发人员开发的应用运行在超过一个平台,他们就会面临一系列的挑战。对终端用户来说能使用...
  • es6 Promise 的含义

    2018-01-27 22:24:12
    Promise 的含义 Promise 是异步编程的一种解决方案,比传统的解决方案——回调函数和事件——更合理和更强大。它由社区最早提出和实现,ES6 将其写进了语言标准,统一了用法,原生提供了Promise对象。 所谓...
  • 这些方法参数,都需要传入一个匿名函数,匿名函数中有三个参数,分别含义是:数组中项、该项索引、以及数组本身。 1、filter方法:对数组每一项执行匿名函数,并返回符合条件数组项。 1 var testArr=...
  • 原生JSAjax操作

    2017-05-01 07:22:34
    HTML中,已经规定了只能出现哪些标签,规定了每一个标签的含义如:p是段落、b加粗、a超链接 XML中,没有规定,所以可以出现任意的标记 Ajax用来做什么? 主要用来在前段页面中向服务器后端请求数据。
  • Promise 的含义

    2019-07-17 19:17:03
    Promise 的含义 Promise 是异步编程的一种解决方案,比传统的解决方案–回调函数和事件--更合理和更强大。它由社区最早提出和实现,ES6将其写进了语言标准,统一了语法,原生提供了Promise 所谓Promise ,简单说...
  • 原生有很多不同的含义。十年前,它是由Netflix这样的公司创造的,他们利用云技术,从一家邮购公司发展成为世界上最大的消费者点播内容交付网络之一。Netflix开创了我们所说的云原生,重塑、改造和扩展了我们都想做...
  • 在 Vue.js、React.js、Koa、Echarts 等框架风靡一时的背景下,原生的 JavaScript 就可以被抛弃了吗?答案是否定的。typeof 10n;这个正确的直接结果是:bigint。那么 bigint 是用来解决什么问题的呢?从字面意思就能...
  • 本文实例讲述了原生JS检测CSS3动画是否结束的...下面我们通过一个简单的例子来理解一下我这句话的含义: 代码如下: <!DOCTYPE html> <html lang=en> <head> <meta charset=UTF-8> <meta
  • 在 Vue.js、React.js、Koa、Echarts 等框架风靡一时的背景下,原生的 JavaScript 就可以被抛弃了吗?答案是否定的。 typeof 10n; 这个正确的直接结果是:bigint。 那么 bigint 是用来解决什么问题的呢?从字面意思...
  • 在前一篇文章中,我们讨论了云原生的实际含义,并且指出,要从云原生方法中获益,就需要从多个角度来审视它。这不仅与你使用的技术和基础设施所在的位置有关,还与你如何构建解决方案有关。但最重要的...
  • ##IOC容器理解和原生代码实现简单容器 IOC是什么 IOC :Inversion of Control,中文含义就是控制反转,IOC不是一种技术,而是一种思想,通过这种思想,我们可以设计出低耦合,灵活性高,扩展性高程序。 1.控制正...
  • 原生这么火,你再不了解就out了

    千次阅读 2021-02-05 10:11:08
    但是到底这个词是什么意思,它具体含义是什么,其实却是非常含糊。 云原生这个词最早在2014年左右起源于Pivotal。Pivotal是一家做PaaS服务公司。之后在2015年夏天,Linux基金会创建了云原生基金会CNCF。CNCF在...
  • 原生开发环境初探

    千次阅读 2019-12-12 19:38:33
    在上一篇“云原生的不同解释及正确含义”里,我们讲到了云原生的引申含义,就是开发环境也是云环境,这样就能保证开发环境和生产环境的一致性,使最终的部署顺利进行。本文就通过具体的例子来探讨云原生的开发环境。...
  • 您是否听说过GitOps,并想知道它全部含义?在此页面中,我们将描述GitOps工作流程原理和模式,以及如何实现它们以在生产中和大规模运行Kubernetes。我们还将描述GitOps与基础架构代码(IAC)配置管理工具之间...
  • 数组和对象有哪些原生方法,列举一下,分别是什么含义,比如连接两个数组用哪个方法,删除数组指定项和重新组装数组(操作数据重点)。
  • Promise 的含义 Promise 是异步编程的一种解决方案,比传统的解决方案–回调函数和事件--更合理和更强大。它由社区最早提出和实现,ES6将其写进了语言标准,统一了语法,原生提供了Promise 所谓Promise ,简单说...
  • MIUIv4是小米修改后的4.0系统,一个是用数据线刷,一个是sd卡刷,下面的是原生的Android系统,建议线刷,Android原生的系统比较流畅,速度比较快。 2、刷机过程中,提示遇到未知异常或者进度条没有变化,原因是...
  • .native修饰符 的含义

    2020-11-02 17:11:59
    .native修饰符 自定义组件上注册的事件触发的是组件自定义的事件。。而不是原生的dom事件。所以不会触发。

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 510
精华内容 204
关键字:

原生的含义