广州睿东网络科技有限公司是国内最专业的香港空间,云主机,香港VPS,香港服务器租用提供商,专注为国内站长提供高速且稳定的香港空间,云主机,香港VPS,香港服务器租用,欢迎您的选购!
当前位置:首页 -> 香港主机 -> 云服务器

架构演化:云原生时代开启之系列三:CNCF篇

云服务器 34℃ 1882评论

云原生与CNCF 

在2015年,由Google牵头创立的CNCF(Cloud Native Computing Foundation)正式成立,并且发布其标志性作品Kubernetes 1.0。由此,围绕着CNCF产生了不少有价值的云原生项目。CNCF独立维护了一个全景图项目,发布周期非常频繁,截止到本书写作时,最新版本是0.9.9。该项目的github地址是:https://github.com/cncf/landscape。


CNCF将云原生的生态圈横向划分为五层,并且针对它们又纵向规划出两部分,作为横向五层的共用层。横向划分的五层分别是:应用定义与开发、编排与治理、运行时、供应保障和云设施。纵向划分的两部分是:观察与分析和平台。将这些功能整合起来即是一个完善的云平台服务产品。


                  图中所含信息量太过巨大,从全景图上无法看清细节。

我们层层递进的仔细看一下

首先看看横向分层的每层涵盖内容。

应用定义与开发


这一层出现的内容,对于稍有经验的技术人员来说是比较熟悉的。无论是或不是基于云原生的应用,它们都是开发和运维的基础所在,与传统开发模式并无二致。

这一层包括数据库与数据分析、流式处理、软件配置管理、应用定义以及持续集成持续交付。分别看一下每个部分的具体内容:


01

数据类

数据类包括数据库与大数据分析工具,按照类型分为关系型数据库、NoSQL、NewSQL、数据库中间层以及大数据处理相关。


基于SQL操作的关系型数据库,主要包括Oracle、SQLServer、MySQL、PostgreSQL、DB2、MariaDB等。虽然各种新型数据库层出不穷,但关系型数据库的存储引擎毕竟经历了数十年的时间的打磨,又有经典的ACID事务模型作为支撑,因此,它对于核心数据存储选型的首选地位不可撼动。针对关键业务,大部分企业依然倾向于采用关系型数据库存储,如交易数据、订单信息等。除了数据库本身的稳定性之外,SQL查询的灵活度、开发工程师的熟悉程度以及数据库管理员的专业度等,共同形成了一个强大的生态圈。它使得关系型数据库依然是格式化数据存储行业最优先的选择。


作为关系型数据库有有效补充,NoSQL数据库在数据存储领域也占有重要比重。如mongoDB、Couchbase、Redis、Cassandra、HBase、Neo4j等。面向文档、面向列簇、面向Key-Value、面向图等NoSQL数据库,在数据的分布式处理方面更加优秀,编程模型也更加贴近面向对象原有的使用方式。虽然查询的灵活度却远不如SQL,但在特定场景的性能、对面向对象的原生存储能力、无Schema模式等方面都很不错。因此在适合的业务场景,NoSQL数据库也大有用武之地。


NewSQL数据库目前是新一代数据库的焦点,是颠覆关系型数据库统治地位的有力竞争者。它在兼容SQL的同时,更加擅长分布式处理。优秀的代表作是国人开源的TiDB。TiDB采用Key-Value存储引擎,采用不同于ACID的方式强一致的分布式事务,可动态平滑的数据迁移,自动的水平伸缩,也可以在线修改Schema和索引变更等操作,是完整的数据存储结果方案。但新的存储引擎的成熟度毕竟还需要时间来检验,而且无需专业数据库管理员运维的理念也需要时间来让更多的企业接受。因此,愿意尝试的公司仍然是采用关系型数据库和NewSQL数据库共用这种较为谨慎的态度。随着时间的沉淀,相信NewSQL的前景会越来越光明。


用于离线或准实时的计算大数据的技术栈,如Hadoop、Spark、Druid等。


以Map/Reduce成名的Hadoop体系,将计算任务抽象成为Mapper和Reducer的编程模型,能够将成百上千台PC服务器组成的不完全可靠的集群,在集群中通过分布式的手段并发的处理大量的数据集,并且将分布式和故障恢复等实现细节隐藏起来。它将数据处理过程分解为由多个包含Mapper和Reducer的作业放至集群中执行并最终得出计算结果。但由于Map/Reduce任务将中间结果存入HDFS文件系统中,因此延时较高,只合适大批量数据库处理,无法满足交互式数据处理的需要。


以RDD(Resilient Distributed Dataset)作为计算模型的Spark,提供了一个供集群使用的分布式内存。在Spark中,RDD的转换操作会生成新的RDD,而新的RDD的数据仍然依赖于原来的RDD。因此,程序构造了个相互依赖的多个RDD组成的DAG(有向无环图)并将其作为一个作业交由Spark执行。由于每次迭代的数据并不需要写入磁盘,而是可以保存在内存中,因此Spark的性能比Hadoop有很大提升。


02

流处理

流式处理包括消息中间件以及流式实时计算框架。


消息中间件用于异步化和解耦系统依赖,如RabbitMQ和Kafka、未上榜的还有老牌消息中间件ActiveMQ,以及国产的优秀作品RocketMQ等。由于存储引擎不同,ActiveMQ、RabbitMQ这种可以基于消息索引查询的消息中间件,功能虽然完善,但分布式和性能不尽人意。


Kafka以及早期的RocketMQ采用日志追加的存储引擎,分布式和性能大幅提升,但自身对于消息的控制能力有限。新一代的RocketMQ以及阿里随之孵化的OpenMessaging,正在努力平衡和兼容两种流派的消息中间件。


流式的实时计算框架,如Strom、Flink等。相较于Hadoop这样的离线计算,实时性是这类框架更加关注的方面。Storm与Flink类型,都是将输入流进行转换和计算,并将结果作为输出流传输至下一个计算节点。对于实时统计PV、UV等需求,流式的实时计算框架是不错的选择。


03

软件配置管理

软件配置管理即SCM(Software ConfigurationManagement),它通过执行版本控制来保证所有代码和配置项变更的完整性和可跟踪性。在源代码版本控制工具领域,老牌的SVN已是昨日黄花,将会逐渐的退出历史舞台,取而代之的是Git,它已是当前的行业标准。Git的出现,使得源代码版本控制工具升级为分布式而愈加受到青睐。


GitLab使用Git作为其源代码版本控制工具,在管理源码的同时提供便捷的WEB服务,在成为代码托管服务平台的同时,还可以通过各种插件的安装配置完成代码评审、代码质量检查等工作。企业一般都使用其搭建自己的软件配置管理系统。


个人开发者、开源项目或企业付费用户推荐采用Github来管理源代码,世界顶级公司的顶级开源项目大多将源码托管在Github上。

由开源中国搭建的码云,同样采用Git作为其源代码管理工具。它在国内的访问速度优于Github,也更加符合国人的使用习惯,也是非常优秀源码管理平台。


04

应用定义


对于熟悉Java技术栈的同学,图中没有特别熟悉的产品。Java中的Maven就属于该范畴。它由于功能稳定、周边生态多样,是业界的主流也是Java的首选。


Maven使用项目对象模型 (Project Object Model)声明和管理项目的生命周期和应用依赖,并且可以自定制插件开发,大量的Maven第三方插件,使得它的应用场景被无限的扩大,比如代码静态检查、代码风格评审、测试覆盖率计算等。


05

持续集成持续交付


持续集成是指自动且持续不断的构建和测试软件项目,并监控其结果是否正确。有了持续集成工具的支持,项目可以频繁地将代码集成到主干,进而使得错误能够快速的被发现。它的目的是让产品可以快速迭代的同时还能保持高质量。持续集成并不能消除Bug,但是它能让Bug被快速发现并且容易改正。


持续交付是指频繁的将应用的新迭代版本交付给测试团队或者最终用户以供评审,如果评审通过,则自动部署至生产环境。它的中心思想是是无论应用如何更新,它都可以随时随地的交付并自动化部署。


常见的持续集成持续交付的工具有Jenkins、Bamboo、CircleCI、Travis等。


应用定义与开发这一层的变动非常剧烈,之前CNCF将开发语言、开发框架等都纳入这里,但从0.9.6版本的全景图却将这些内容全部删除了。原因大概是CNCF认为他们属于业务开发范畴,云原生无需关注。因此,无论是选择Java还是PHP进行开发,使用Spring还是Play搭建架构,都可以开发出适合或者不适合云原生的应用。


编排与治理


它将应用框架的分布式治理与云原生所需的调度、编排等功能抽象出来,形成独立的一层。这种划分方式更加清晰的将云原生应用管理起来,即业务开发工程师完全对是否云原生透明化,而云原生中间件工程师也无需过多关注业务。相对来说,CNCF的产品更多的集中在这一层。这是云原生产品比较容易发力的部分。


这一层包括调度与编排、分布式协调与服务发现和服务管理。我们来具体看一下每个部分涉及的内容:


01

调度与编排


调度与编排提供面向应用的容器集群部署和管理。目的是解耦CPU、GPU、内存、网络以及存储等基础设施与应用程序间的依赖,使应用开发人员将重点完全放在核心业务应用的开发而不必操心资源管理的问题,也使运维人员将重点放在硬件基础设施以及操作系统和网络本身而不必操心资源利用率最大化的问题。它负责按照预定的策略将承载着应用的容器调度到拥有相应运行资源的执行服务器中。除了CNCF的核心成员Kubernetes之外,Mesos、Docker Swarm也属于此范畴。


虽然调度与编排同属一部分,但它们负责的范围并不相同,调度是合理的将分布式系统中的闲置资源分配给需要运行的进程,并采用容器进行封装;编排是对系统中的容器进行健康检查、自动扩缩容、自动重启、滚动发布等。


Mesos采用的两级调度架构,将调度和编排分离的比较彻底。由Mesos自身负责资源的调度,由运行在Mesos系统中的framework——Marathon进行容器的编排。



02

分布式协调与服务发现


分布式场景由于网络的延迟以及不确定性,因而复杂度非常高。分布式系统一般都是通过一个可靠性非常高的注册中心对分布式服务进行协调与发现的。注册中心需要确保数据在分布式场景下的一致性,以及需要能够及时的通知到每个分布式节点关于分布式集群的状态变化。


在很多分布式系统中都可以看到它们的身影,如Zookeeper之于Hadoop、Kafka和Dubbo;Eureka之于Spring Cloud;Consul之于Docker Swarm,其他常见的产品还有CNCF的项目CoreDNS以及负责Kubernetes元数据存储的etcd。虽然etcd并未在Kubernetes中扮演服务发现和分布式协调的角色,但它可以作为注册中心提供这方面的能力。



03

服务管理


与编排与调度是云原生的基础需求类似,服务管理是云原生的另一个重要的基础,也是CNCF重点的关注点之一。服务管理的产品主要集中在三个方面:远程通信、反向代理以及服务治理。


服务间的远程调用,需要高性能和跨语言的通信框架。gRPC、Thrift、Avro跨语言框架,集序列化和通信于一身,是分布式系统的重要基石。


反向代理的产品目前已经非常成熟,有硬件的F5,以及软件类的HAProxy、Nginx等。它们负责承载入口流量,并将请求按照规则配置分发给相关的系统。

服务治理的框架,也已经有很多成熟的项目可以使用,如Netfix OSS的负责网关的Zuul、负责客户端负载均衡的Ribbon、负责熔断的Hystrix等,它们也是Spring Cloud开发套件的重要组成部分。由Twitter开源的用Scala语言开发的Finagle、以及国内非常流行的Dubbo也属于此范畴。


目前在服务治理这块,一个在业界新兴的概念Service Mesh渐渐的被更多人认同,它的中文翻译为服务网格。Linkerd和Istio是这方面的代表,由于技术实在太新,目前还属于快速发展期。其中Linkerd和Istio的通信底层组件Envoy都是已加入CNCF。Istio是英文sail的希腊文,中文则是航行的意思。它与Kubernetes一脉相承,Kubernetes同为希腊文,是舵手的意思。Istio作为Service Mesh的总控制台,除了Envoy,Linkerd也实现了它的接口并提供底层通信能力。


因此,Kubernetes掌控编排、Istio掌控服务治理,云原生的未来秩序已逐渐清晰。

值得一提的是,Kubernetes也内置了服务管理的功能,它们并未从Kubernetes的核心中抽离出来。Kubernetes使用Service和Ingress处理服务发现和负载均衡。未来的Service Mesh是否能够从Kubernetes中将服务管理完全接管过来将是一个值得关注的重点。



运行时


云原生的应用并不直接运行在物理服务器或传统的虚拟机之上,而是在它们之上再构建一层,用于轻量和灵活的运行更多的实例。


云原生应用的运行时环境与传统应用的运行时环境有很大不同,但是它们的抽象层级是类似的,与传统应用的文件系统、进程以及网络环境相对应的是云原生存储、容器和云原生网络。


这一层包括云原生存储、容器和云原生网络。我们来具体看一下每个部分涉及的内容:


01

云原生存储


适合云服务的分布式文件存储系统。它能将运行在云平台的应用所需要或产生的数据放入一个可以不依赖本地磁盘且可以平滑扩容的高可靠文件系统中。典型的产品有HDFS、Ceph、ClusterFS等。云原生存储与专门用于存储业务数据的数据库并不是一个概念,目前很少有将数据库安装在云原生存储的成熟方案。云原生存储目前最广泛的应用,是存放日志、图片、文档等文件。



02

容器


容器是过去几年的热门话题。云原生应用选择容器这种更加轻量级的方案当做运行应用的载体。采用容器为最小单元对应用进行资源隔离以保证云平台的隔离性,并且采用容器打包环境加应用的方式提供更易复制的部署方式。不过需要注意的是,Kubernetes采用Pod最为应用最小单元,一个Pod可以包含多个容器。Docker是目前使用最广泛的容器,业界也有rkt等替代方案。



03

云原生网络


为每个容器(Pod)分配一个独立的IP地址,是云原生网络需要解决的问题。若采用和宿主机一样的IP地址,运行在同一个宿主机中容器的IP地址则会发生冲突。虽然可以通过改造应用程序来屏蔽对IP的依赖,但为了透明化应用,每个容器都拥有一个独立的IP地址才是上策。最佳实践是使用软件定义网络(SDN)的方式。云原生网络比较复杂,各种网络方案也层出不穷。因此产生了CNI(Container Network Interface)这样的容器网络接口标准,它的主要实现有Flannel、Calico、OVS、weave等。



供应保障


这一层提供对宿主机和容器本身的供应和保障,它的关注点更加偏向于运维工程师。


这一层包括宿主机管理工具、基础设施自动化工具、容器仓库、镜像安全和密钥管理。我们来具体看一下每个部分涉及的内容:


01

宿主机管理工具


虽然云原生应用运行在一个相互隔离的由调度系统掌控的容器环境中,但它们最终仍然是运行在真正的物理服务器或虚拟机之上的。因此,需要管理工具能够将Docker、Kubernetes 、Mesos、etcd、Zookeeper、Flannel等众多运行时所需环境和工具自动的安装和配置在应用运行的宿主机上。原有的自动化运维工具在这里仍然有用武之地,它们无需再安装复杂的软件应用环境,而是搭建容器运行环境和编排调度平台即可。此类工具仍然是之前章节提到过自动化运维工具,它们包括Ansible、Puppet、chef等。自动化运维工具的目标不在是安装应用及其相关环境,而是安装云原生应用所需环境。


02

基础设施自动化


对于云原生的系统来说,调度编排平台即为基础设施。基础设施自动化工具的用途是更加容易的为调度编排平台安装插件。常见的相关工具有Docker的包管理工具Infrakit以及简化Kubernetes应用的部署工具Helm。Helm可以看做是Kubernetes的apt-get或yum。它通过Helm Charts帮助使用者安装和更新复杂的Kubernetes应用,支持发布的版本管理和控制,很大程度上简化了Kubernetes应用部署和管理的复杂性。



03

容器注册


负责容器镜像内容的存储与分发。Docker Registry是Docker 的核心组件之一,客户端的 docker pull 以及 push 命令都与它交互。Harbor是一个比较知名的项目,它的目标是帮助用户迅速搭建一个企业级的Docker Registry服务。


04

镜像安全


安全漏洞一直存在与程序的世界。升级为容器之后,此类安全威胁仍然存在,因此需要能够发现容器中可能存在的安全问题的工具。如Clair、Twistlock等工具均可以检查容器中应用的漏洞。

 

还有一个秘钥管理的部分,是比较新进加入CNCF的部分,笔者并不熟悉,故就不介绍了。




用于提供物理服务器的云厂商。分为公有云和私有云。常见的公有云有AWS、Azure、阿里云、腾讯云、华为云等,常见的私有云有openstack、vmware等。这一层并不在CNCF的涉及范畴,它们仅用于提供服务所需资源。


下面再介绍一下纵向分层的涵盖的内容。纵向分层以另一个维度描述云原生应用,观察与分析是每一层都需要的功能,平台则是将每一层功能组合起来的整体解决方案。


观察与分析


01

监控


监控包括对物理服务器指标进行采集与报警的工具,如Nagios、Zabbix等;对容器指标进行采集的工具,如CAdvisor等;以及存储海量采集信息的时间序列数据库,如Prometheus、influxdb等。


通过采集 –> 存储 -> 分析 -> 报警(展现)的流程自动的将系统状态通知系统责任人处理或定期分析。一般可以采用Grafana等专门用于监控分析的图形工具来展现数据。



02

日志


由于云原生应用是无状态的,因此不应将日志写入本地磁盘,而是应该写入日志中心。将标准输出采集并输入至其他流的工具主要有Fluentd 、Flume、FileBeat、Logstash等。再由这些工具将其通过各种缓冲的管道处理写入日志中心,日志中心的存储介质可以是Elasticsearch、HBase等。Elastic公司提供的由Elasticsearch、Logstash和图形界面Kibana日志中心套件(简称ELK),是一站式的开源解决方案,也有Splunk这样的一体化商业日志解决方案。


03

追踪


云原生应用运行实例多,应用调用复杂,因此一旦系统响应变慢,难于定位问题。因此需要提供一套服务之间的调用链以及服务内部的调用栈梳理和分析的解决方案。OpenTracing是调用链的一个标准协议,遵循其协议的开源解决方案主要有ZipKin、JAEGER、以及国产的优秀开源项目SkyWalking等。也有一些开源解决方案并未遵循此协议,如PinPoint、Open-falcon、CAT等。



平台


基于云的整合平台是目前各个云公司所着力打造的产品,比较知名的有Mesosphere公司围绕Mesos打造的DC/OS、以及Rancher公司打造的可以整合Mesos和Kubernetes的Rancher平台等。

 

上面提到的技术只是整个云原生技术的冰山一角,无论是开源还是商业产品,优秀的解决方案非常多。云原生可以有不同实现方式,但它的本质是可以弹性的利用云平台的资源。无论是在应用程序 + 分布式中间件 + 自动化运维的方式,还是通过应用程序 + 调度编排平台 + 容器 + 服务治理的方式实现健壮的系统都是可以的。


以上内容节选自《云原生分布式架构》一书

 内容简介

【互联网架构不断演化,经历了从集中式架构到分布式架构,再到云原生架构的过程。云原生因能解决传统应用升级缓慢、架构臃肿、不能快速迭代等问题而成为未来云端应用的目标。本书首先介绍了架构演化及云原生的概念,让读者对基础概念有一个准确的了解。接着阐述容器调度、服务化、分布式等体系的原理,讲解分布式中间件设计方法。最后辅以实战,以中心化和平台化角度切入,深度揭秘两大开源项目Elastic-Job和Sharding-JDBC的实现】

尽请期待

《云原生分布式架构》2018年  将与您见面

书名未完全确定 欢迎您宝贵建议

感谢大家关注“点亮架构”,欢迎对公众号文章的内容批评指正,如果有其他想要了解的技术问题,也可以留言提出。

转发分享快乐     

 
投诉
喜欢 (1882)

评论

帐  号: 密码: (新用户注册)
验 证 码:
表  情:
内  容: