云原生技术和架构概述

640?wx_fmt=jpeg


640?wx_fmt=gif

2014年,谷歌开源了一个主要用于容器编排的Borg内部项目。由于没有机构来管理这个项目,谷歌就与Linux基金会联合创建了旨在鼓励Kubernetes和其他云原生解决方案的开发和协作的云原生计算基金会(CNCF)。而后来Borg项目就更名为Kubernetes,并用Go语言重写了实现部分,成为了CNCF的启动捐赠项目。毫无疑问地讲,Kubernetes只是开始,后续有大批的新项目先后加入到CNCF,围绕着Kubernetes不断地扩展功能。


1. 云原生(Cloud Native)


在讲云原生之前,我们先了解一下CNCF,即云原生计算基金会,2015年由谷歌牵头成立,基金会成员目前已有一百多企业与机构,包括亚马逊、微软。思科等巨头。


CNCF在云端的自我使命是通过提供多种选项的开发软件社区,帮助最终用户构建云原生应用。从而培育云原生开源项目的生态体系。CNCF鼓励项目之间的相互协作,希望实现完全由CNCF成员项目演化出来的成熟技术栈。


1.1 CNCF组织


目前共有25个项目已经被CNCF接受,在跟进Kubernetes生态发展。希望加入到CNCF的项目,必须是由技术监督委员会(TOC)选定并通过投票评比,取得绝大多数的投票认同才可以加入。投票过程由TOC贡献者组成的一个优秀社区来辅助进行,而TOC贡献者是来自CNCF成员公司的代表。


评选通过的项目就叫CNCF成员项目,CNCF将根据成员项目代码成熟度级别分别定义为沙箱、孵化或毕业阶段。下图为其公布的Cloud Native Landscape,给出了云原生生态的参考体系。


640?wx_fmt=jpeg

Cloud Native Landscape


CNCF成员项目包括12个类别:编排、应用程序开发、监控、日志记录、跟踪、容器注册、存储和数据库、运行时间、服务发现、服务网格、服务代理、安全以及数据流和消息流,下面内容重点介绍前几个类别。


编排:Kubernetes这个单词在古希腊语是舵手的意思。强调自动化和声明性配置,可自动化完成容器化应用的部署、伸缩和管理。Kubernetes进行容器编排,而所编排的容器是可移植和模块化的微服务包。它为应用添加了一个抽象层,将容器分组运行在Pod中,从而实现容器的编排。

应用程序开发:Helm是程序包管理器,以chart的形式让用户轻松地查找、共享、安装和升级Kubernetes应用。帮助终端用户使用KubeApps Hub部署已有应用(包括MySQL、Jenkins、Artifactory等)


监控:Prometheus是第二个加入到CNCF的项目,也是第二个毕业的项目。它是一个适合动态云环境和容器环境的监视解决方案,灵感来自于谷歌的Borgman监控系统。OpenMetrics其实是基于Prometheus的指标格式,而后者又是采用Borgmon的运营经验,Borgmon实现了“白盒监控”和低开销的海量数据收集,有着超过300家的服务输出商。

日志和跟踪:Fluentd采用统一的方法,对应用程序的日志进行收集、解析和传输。使用户可以更好地理解和利用这些日志信息。另外,还有Jaeger是一个开源的分布式跟踪系统解决方案,它与OpenTracing日志跟踪软件兼容。


容器注册:Harbor最初是由VMWare作为开源解决方案开发的,是一个开源可信任的容器注册器,用于存储、标记和扫描Docker镜像,提供了免费的、增强的Docker注册特性和功能。


1.2 云原生介绍


CNCF给出了云原生应用的三大特征:


  • 容器化封装:以容器为基础,提高整体开发水平,形成代码和组件重用,简化云原生应用程序的维护。在容器中运行应用程序和进程,并作为应用程序部署的独立单元,实现高水平资源隔离。

  • 动态管理:通过集中式的编排调度系统来动态的管理和调度。

  • 面向微服务:明确服务间的依赖,互相解耦。


云原生包含了一组应用的模式,用于帮助企业快速,持续,可靠,规模化地交付业务软件。云原生由微服务架构,DevOps 和以容器为代表的敏捷基础架构组成。


这边引用网上关于云原生所需要的能力和特征总结,如下图。

640?wx_fmt=jpeg

云原生所需要的能力和特征


1.3 The Twelve Factors


12-Factors经常被直译为12要素,也被称为12原则,12原则由公有云PaaS的先驱Heroku于2012年提出,目的是告诉开发者如何利用云平台提供的便利来开发更具可靠性和扩展性、更加易于维护的云原生应用。具体如下:


  • 基准代码

  • 显式声明依赖关系

  • 在环境中存储配置

  • 把后端服务当作附加资源

  • 严格分离构建、发布和运行

  • 无状态进程

  • 通过端口绑定提供服务

  • 通过进程模型进行扩展

  • 快速启动和优雅终止

  • 开发环境与线上环境等价

  • 日志作为事件流

  • 管理进程


另外,除了上述的12要素外,还有补充的三点跟API、认证授权和监控告警相关的要素。


  • API声明管理

  • 认证和授权

  • 监控与告警


距离12原则的提出已有五年多,12原则的有些细节可能已经不那么跟得上时代,也有人批评12原则的提出从一开始就有过于依赖Heroku自身特性的倾向。不过不管怎么说,12原则依旧是业界最为系统的云原生应用开发指南。


2. 容器化封装


最近几年Docker容器化技术很火,经常在各种场合能够听到关于Docker的分享。Docker让开发工程师可以将他们的应用和依赖封装到一个可移植的容器中。Docker背后的想法是创建软件程序可移植的轻量容器,让其可以在任何安装了Docker的机器上运行,而不用关心底层操作系统。


Docker可以解决虚拟机能够解决的问题,同时也能够解决虚拟机由于资源要求过高而无法解决的问题。其优势包括:


  • 隔离应用依赖

  • 创建应用镜像并进行复制

  • 创建容易分发的即启即用的应用

  • 允许实例简单、快速地扩展

  • 测试应用并随后销毁它们


自动化运维工具可以降低环境搭建的复杂度,但仍然不能从根本上解决环境的问题。在看似稳定而成熟的场景下,使用Docker的好处越来越多。


3. 服务编排


笔者看到Jimmy Song对云原生架构中运用服务编排的总结是:Kubernetes——让容器应用进入大规模工业生产。这个总结确实很贴切。编排调度的开源组件还有Kubernetes、Mesos和Docker Swarm


Kubernetes是目前世界上关注度最高的开源项目,它是一个出色的容器编排系统。Kubernetes出身于互联网行业的巨头Google公司,它借鉴了由上百位工程师花费十多年时间打造Borg系统的理念,通过极其简易的安装,以及灵活的网络层对接方式,提供一站式的服务。


Mesos则更善于构建一个可靠的平台,用以运行多任务关键工作负载,包括Docker容器、遗留应用程序(例如Java)和分布式数据服务(例如Spark、Kafka、Cassandra、Elastic)。Mesos采用两级调度的架构,开发人员可以很方便的结合公司业务场景自定制MesosFramework。


他们为云原生应用提供的强有力的编排和调度能力,它们是云平台上的分布式操作系统。在单机上运行容器,无法发挥它的最大效能,只有形成集群,才能最大程度发挥容器的良好隔离、资源分配与编排管理的优势,而对于容器的编排管理,Swarm、Mesos和Kubernetes的大战已经基本宣告结束,Kubernetes成为了无可争议的赢家。


4. 微服务架构


传统的Web开发方式,一般被称为单体架构(Monolithic)所有的功能打包在一个WAR包里,基本没有外部依赖(除了容器),部署在一个JEE容器(Tomcat,JBoss,WebLogic)里,包含了DO/DAO,Service,UI等所有逻辑。其架构如下图所示。


640?wx_fmt=jpeg

传统的单体架构


单体架构进行演化升级之后,过渡到SOA架构,即面向服务架构。近几年微服务架构(Micro-Service Archeticture)是最流行的架构风格,旨在通过将功能模块分解到各个独立的子系统中以实现解耦,它并没有一成不变的规定,而是需要根据业务来做设计。微服务架构是对SOA的传承,是SOA的具体实践方法。微服务架构中,每个微服务模块只是对简单、独立、明确的任务进行处理,通过REST API返回处理结果给外部。


在微服务推广实践角度来看,微服务将整个系统进行拆分,拆分成更小的粒度,保持这些服务独立运行,应用容器化技术将微服务独立运行在容器中。过去设计架构时,是在内存中以参数或对象的方式实现粒度细化。微服务使用各个子服务控制模块的思想代替总线。不同的业务要求,服务控制模块至少包含服务的发布、注册、路由、代理功能。


容器化的出现,一定程度上带动了微服务架构。架构演化从单体式应用到分布式,再从分布式架构到云原生架构,微服务在其中有着不可或缺的角色。微服务带给我们很多开发和部署上的灵活性和技术多样性,但是也增加了服务调用的开销、分布式系事务、调试与服务治理方面的难题。


640?wx_fmt=png

Spring Cloud整体架构图


从上图Spring Cloud组件的架构可以看出在微服务架构中所必须的组件,包括:服务发现与注册、熔断机制、路由、全局锁、中心配置管理、控制总线、决策竞选、分布式会话和集群状态管理等基础组件


640?wx_fmt=png

Spring Cloud VS Kubernetes


Spring Cloud和Kubernetes有很大的不同,Spring Cloud和Kubernetes处理了不同范围的微服务架构技术点,而且是用了不同的方法。Spring Cloud方法是试图解决在JVM中的微服务架构要点,而Kubernetes方法是试图让问题消失,为开发者在平台层解决。Spring Cloud在JVM中非常强大,Kubernetes管理那些JVM很强大。看起来各取所长,充分利用这两者的优势是自然而然的趋势了。


5. 总结


技术架构的演变非常快,各种新的名词也是层出不穷。本文主要是对云原生的概述。云原生应用的三大特征:容器化封装、动态管理、面向微服务。首先由CNCF组织介绍了云原生的概念,然后分别对这三个特征进行详述。云原生架构是当下很火的讨论话题,是不同思想的集合,集目前各种热门技术之大成。


参考链接:http://dockone.io/article/2991


推荐阅读:


温馨提示:

请识别二维码关注公众号,点击原文链接获取更多容器、云和微服务等技术资料和总结

640?wx_fmt=jpeg

640?wx_fmt=gif

  • 1
    点赞
  • 14
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值