PaaS

PaaS

详解宜信PaaS平台LAIN的功能和架构

aoxiang 发表了文章 • 0 个评论 • 222 次浏览 • 2019-05-24 07:14 • 来自相关话题

LAIN是宜信公司大数据创新中心开发的开源PaaS平台。在金融的场景下,LAIN 是为解放各个团队和业务线的生产力而设计的一个云平台。LAIN 为宜信大数据创新中心各个团队提供了统一的测试和生产环境,简化了服务的部署与上线流程,也降低了运维人员对系统管理的复杂 ...查看全部
LAIN是宜信公司大数据创新中心开发的开源PaaS平台。在金融的场景下,LAIN 是为解放各个团队和业务线的生产力而设计的一个云平台。LAIN 为宜信大数据创新中心各个团队提供了统一的测试和生产环境,简化了服务的部署与上线流程,也降低了运维人员对系统管理的复杂度。
#一、设计理念及解决问题
LAIN 规范了一个应用的开发、测试、上线工作流,提供了为应用做的容器编排、权限控制、SDN、流量管理、监控报警、备份、日志等 DevOps 问题的整体解决方案。如果你想和更多Docker技术专家交流,可以加我微信liyingjiese,备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态。

在 LAIN 上,应用是一个基本的概念,某个应用的开发者只需要定义一个 lain.yaml 即可定义应用的编译和运行方式,对应用代码侵入性很低。LAIN 基于容器技术,面向多样化的技术栈,并且天然隔离系统和应用的依赖。

当 LAIN 用户创建一个应用(服务)时,可以到 LAIN 上注册该应用,当前的用户自动成为了该应用的维护者,拥有了进一步操作该应用的权限。构建应用的环境需要 Docker 和 Lain 命令行工具,为了方便,我们创建了一个 vagrant box 即 lain-box. 在构建应用时,除了工程代码外,还需要一个 Docker 镜像作为基础镜像,即编译的环境。如果是二进制的工程,如 golang,则可以在运行时换掉一个底,否则会使用 build 镜像为 release 镜像。准备好镜像和编译/运行的脚本后,就可以编辑 lain.yaml 了。

具体来说,LAIN 解决了以下四个问题:
##1、应用开发之下的DevOps问题的整体解决方案
常见问题:

* 面对用户的应用级开发仅仅是冰山一角,在此之下有机房、网络、服务器、系统管理、运维管理、监控、告警、日志等等一系列背后的工作,而这部份的工作可能比应用级开发还要复杂
* 采用IaaS解决了服务器采购和上架问题,但是依然需要一个强大的devops团队来负责上述事务,否则基础设施很容易成为发展瓶颈,且越拖越难解决
* 上面的这些工作对于每一个产品可能都是同质化但又伴随着定制,会消耗大量的时间做这些重复的工作

Lain是怎么做的:

* 直接在几乎裸的IaaS或者服务器上即可构建lain集群,方便地进行在线的扩容缩容等集群底层资源操作
* 整合了业界沉淀下来的良好的运维整体实践,提供了冰山下的这一大块工作的整体解决方案
* 将纷繁复杂的系统管理和运维管理行为封装为更简单易用的工具包,极大简化大部分的系统工作,降低日常维护的技术门槛和人力需求
* 将同质化的工作整合在一起,避免重复劳动
* 开箱即用的各种管理组件,囊括了部署,扩容,监控,告警,日志等方方面面。还有附赠应用,包括mysql,redis的集群服务

##2、规范了应用开发的工作流程,并辅以适当的SCM支援
常见问题:

* 在个人开发者以及startup组织中,良好的工作流这件事几乎是不会被提及的,然而在日渐发展的过程中遗留的技术债务却会越来越多的影响开发部署的效率和质量
* 设计、开发和部署行为的不规范会引发各种问题

Lain是怎么做的:

* 提供本地开发环境的解决方案
* 提供本地开发过程的SDK / CLI工具链,使得开发和构建过程是嵌入在解决方案中的
* 隐性的提供了SCM支援,约束了开发者的开发和发布行为

##3、提高整体资源利用率,优化冗余资源池
常见问题:

* 传统的按照产品线规划资源池的情况下,会给各产品预留专属的资源池以及配备冗余,以便进行灾备以及服务突发流量
* 然而各产品线的资源需求类型不同,冗余类型也不同,无法共通共享,造成众多的重复冗余,资源利用率比较低
* 通过服务器资源的冗余,扩容缩容,以及资源迁移的操作比较复杂,时间消耗大,风险高

Lain是怎么做的:

* 通过容器技术的资源隔离和控制,实现多种技术栈多种应用在集群内安全的不相互影响的混合部署,通过统一的资源池进行冗余,有效提高资源利用率
* 容器技术的运用使得对下资源的使用形成完全统一的形式,扩容缩容以及迁移的成本很低,操作也更简单。

##4、TBD:架构上提供了服务治理的可能性和解决方案
#二、特征
在应用的层面上,LAIN 还有以下特征:
##1、基于配置文件定义应用

* 在现有的应用上只需要增加一个配置文件lain.yaml即可定义应用在lain集群里的编译和运行
* 对应用代码的侵入性很低

##2、SDN网络安全隔离

* 使用开源的calico项目构建SDN网络
* 高效率的应用内网络互通
* 应用间网络默认隔离
* 显式声明应用间的服务互访

##3、基于容器技术支持多样化的技术栈

* 使用开源的Docker项目构建容器云
* 扩展封装Dockerfile,使用自定义的yaml格式进行应用的集群定义
* 只需符合最简单的lain cluster runtime interface,可自由选择base image
* 容器技术天然的支持隔离系统和应用的依赖
* lain SDK / CLI以及可选的ci组件支援代码版本和镜像之间的对应关系
* 编译时和运行时镜像均可完全定制和隔离

##4、应用在线扩容缩容

* 使用开源的swarm调度应用部署
* 深度封装swarm docker API,自行开发集群控制器(deployd)以及应用控制器(console)
* 直接支持用户API调用进行容器实例数扩容,缩容
* 直接支持用户API调用进行容器单实例资源的扩容,缩容(CPU,MEM)

##5、节点在线扩容缩容

* 使用开源的Ansible开发集群管理运维工具包
* 集群的服务器节点(NODE)兼容同一个C段内的物理服务器,虚拟机,公有云服务器
* 集群管理工具包支持add NODE 和 remove NODE 指令,快速进行底层资源扩容和缩容

##6、服务自动维持和灾难恢复

* 自行开发集群控制器(deployd)
* 容器实例级别的服务巡检和维持,自动迁移和服务恢复
* 基于虚IP自动漂移的入口load balancer HA
* 高级API支持服务定制迁移

##7、内部服务依赖和发现机制

* 集群支援Service / Resource 机制
* 集群整体的服务应用
* 应用私有Service (即 Resource)服务应用
* 集群支援特别的服务应用类型和资源应用类型
* 在lain.yaml中显式声明使用的Service / Resource
* 基于DNS的服务发现机制
* 可编程的service/resource load balancer
* 默认提供可用的RoundRobin类型的load balancer

##8、统一认证

* 集群自行开发统一认证组件(sso)
* 支持oauth2的多种认证方式

##9、虚IP和负载均衡器统一管理

* 支援 virtual ip 和 应用 proc 的注册,应用可注册 virtual ip 来进行对外服务
* 基于etcd lock机制的virtual ip 漂移机制,应用 load balancer 可借此实现 HA

##10、web load balancer的自动配置

* 使用开源的Nginx和tengine封装web服务的负载均衡器
* 自研的watcher检测集群应用的整体 runtime 数据,自动为 web 服务生成配置
* 获取runtime变化的时间,判断是否需要进行配置变更
* 配置变更事件出发配置的渲染
* 触发 reload 生效

##11、集群体系化的日志收集

* 使用开源的heka配合docker的配置以及rsyslog封装集群整体日志收集
* 默认收集应用的stdout / stderr日志收集
* 支援应用显式声明需要收集的落地文件日志
* 支援应用显式声明结构化的监控数据日志
* 定制检测web服务load balancer的nginx日志收集和数据统计

##12、私有docker registry以及认证机制

* 使用开源的docker registry封装私有 registry 应用
* 集成支援集群的私有统一认证机制
* 定制支援可选的moosefs存储后端或者Ceph存储后端

##13、应用配置加密存储

* 使用开源的库封装的应用私有配置加密存储组件
* 集成sso组件实现用户管理和权限隔离
* 在应用运行时阶段将配置注入

##14、本地化开发环境

* 使用开源的vagrant,免费的centos和virtualbox组织统一的本地化开发环境
* 甚至支援本地使用上述工具链bootstrap出一个lain本地集群

##15、应用部署运维API以及相应的CLI客户端

* 应用的构建,发布,部署,运维都由集群的各组件提供API
* 使用lain SDK / CLI再次封装上述API,给用户提供良好的操作界面
* 集成集群的统一认证,进行用户管理和权限隔离

1.png

##16、集群管理CLI

* 使用开源的ansible开发集群管理运维工具包
* 再次封装ansible调用为简单的CLI使得操作更方便,包括增加节点,移除节点,迁移应用,集群健康检查等。

##17、规范化的开发workflow

* 基于上述组件,以代码 - 镜像的一一对应关系进行SCM,对镜像进行发布管理
* 使用lain SDK / CLI以及可选的ci组件进行本地开发,构建发布,会很自然的规范开发workflow
* 工作流运转的核心单位是镜像,lain cli封装了镜像的生成,更新,推送,部署,运维

2.png

##18、可选的集群体系化的备份和恢复(backupd + moosefs)

* 采用开源的moosefs作为分布式存储后端
* 支援在lain.yaml中显式声明volume备份需求和策略,以及设定备份策略的hooks
* 支援指定备份恢复

##19、可选的集群日志查询组件(Kafka + Elasticsearch + Kibana)

* 采用开源的Kakfa ,Elasticsearch,Kibana搭建外部依赖的卡夫卡集群和Elasticsearch集群,封装集群可选组件Libana
* rebellion集群日志收集组件支援发送所有日志到上述外部依赖kafka
* 在libana上支援对集群应用日志和web load balancer 日志的条件组合查询

##20、可选的系列预置应用

* MySQL的服务
* MySQL的资源
* Redis的服务-SM

#三、系统架构
##1、物理视图
从物理层面看,每一个 lain 集群是由一个或多个网络互通的节点(Node)构成的。
3.png

每个节点可以被赋予不同的 label ,供容器调度时进行节点选择使用。 目前的实现中,需要所有节点位于同一个路由器后。
##2、逻辑视图
从逻辑层面看,一个 lain 集群是由多个应用组成,应用和应用之间网络相互隔离(通过SDN技术)。
4.png

每一个应用是由多个 Docker 容器组成,每个容器都可能运行在不同的节点上。

应用开发者可以在一个应用中定义多种容器(称为 proc),每个 proc 可以指定为在集群上运行多份,每份即为一个容器,被称为 proc instance。Lain 集群会尽可能保证有指定份数的容器在运行,如果有容器 crash 或者节点 fail 的情况发生,集群会试图重启容器或者在节点间迁移容器。
##3、系统架构设计图
目标是做成一层一层可以深入的架构图。

总图:
5.png

节点:
6.png

##4、工作流程
7.png

GitHub地址:https://github.com/laincloud

白皮书:https://laincloud.gitbooks.io/white-paper/content/

原文链接:http://college.creditease.cn/detail/247

Serverless系列 | 云计算究竟如何进化出了Serverless?

灵雀云 发表了文章 • 0 个评论 • 545 次浏览 • 2019-04-10 16:14 • 来自相关话题

导读:近期灵雀云技术专家邵明岐翻译了Mike Roberts & John Chapin所著的《What is serverless》一书的部分内容,可以说是对Serverless科普与观察的上佳素材。本文为第1篇,他首先通过回溯云计算的发展史,来找出是什么原 ...查看全部

导读:近期灵雀云技术专家邵明岐翻译了Mike Roberts & John Chapin所著的《What is serverless》一书的部分内容,可以说是对Serverless科普与观察的上佳素材。本文为第1篇,他首先通过回溯云计算的发展史,来找出是什么原因导致进化出了 Serverless,然后解释 Serverless 到底为何物,最后总结为什么 Serverless 是云计算成长的必然产物,同时也是应用交付方式的巨大飞跃,非常值得一读!
原著:《What is serverless : understand the latest advances in cloud and service-based architecture》

作者:Mike Roberts & John Chapin
译文来源:深入浅出谈架构(ID:deep-easy-arch)
译者:灵雀云邵明岐

让我们回到2006年, 那时候还没有 iPhone 和移动互联网,Ruby on Rails 是一个非常热门的编程框架,Web 2.0 在当时是互联网最火热的名词。那时候大部分应用程序的后端服务,都是运行在托管或者自建的数据中心和物理服务器上。

云的诞生

2006年8月发生的事情将从根本上改变这种模式。 亚马逊新的IT部门 AWS 宣布推出Elastic Compute Cloud(EC2),EC2是众多基础架构即服务(IaaS)产品中的第一个, IaaS允许公司租用计算资源 (主要是面向互联网应用的虚拟主机),而不是购买自己的服务器, 它还允许人们在几分钟之内就可以获取到主机资源。 EC2的五个主要优势是:

1.降低人工成本
在 IaaS 出现之前,公司需要雇佣有专门技能的人来管理数据中心和里面的物理服务器,他们需要管理从电源和网络,到货架和安装,到修复机器的磁盘等物理问题,到设置操作系统(OS)。 通过IaaS,所有这些都消失了,而是都交给 IaaS 服务提供商,比如 AWS 或者阿里云。

2.降低风险
在管理自己的物理服务器时,经常会遭遇一些意外事件,比如硬件故障,从而导致系统不稳定或者长时间宕机,因为硬件问题很难预测,并且可能需要很长时间才能解决。 通过IaaS,客户虽然仍需要做一些工作来对抗硬件故障发生的风险,但不再需要知道如何修复硬件, 相反,可以简单地在几分钟内申请到新机器实例,并重新安装应用程序,从而限制了这些问题的风险。

3.降低基础设施成本
在大部分情况下,当您考虑电源、网络等成本的时候,EC2实例的成本比运行自己的硬件便宜,尤其是当您只想临时需要运行主机几天或几周而不是几个月时。

4.灵活扩展
考虑到IaaS带来的扩展优势,基础设施成本显着下降,通过IaaS,公司在扩展其运行的服务器的数量和类型方面具有更大的灵活性, 不再需要提前几个月预先购买10台高端服务器,相反,您可以从一个或两个低功耗,廉价的实例开始,然后随着时间的推移逐渐扩展您的实例数量和类型。

5.交付时间短
在托管服务器的旧时代,为新应用程序采购和配置服务器可能需要数月时间。 如果你想出新的想法,并且希望尽快尝试一下,在传统的方式下很难办到。 使用IaaS,交付时间从几个月缩短到几分钟。
基础设施外包
使用 IaaS,本质上我们可以认为是基础设施外包的技术。 当我们开发和运营软件时,我们需要做的工作大致可以分为两类:一类是针对需求需要定制的工作。另外一类是和其他公司都差不多,比较通用的工作。
基础设施就是属于第二种,其范围包括物理的设备,例如运行我们机器,电路,网络等,也包括一些通用的软件功能,比如用户认证。
基础设施外包通常可以由服务提供商(SP)提供。 例如,电力由电力供应商提供,并且网络由互联网服务提供商(ISP)提供,他们通过 2 种模式来减低成本和提高效率:规模化和技术创新。

规模化
几乎所有形式的基础设施外包都通过规模化的模式来降低成本,把大量工作打包在一起批量做,成本比单独一件一件做,效率大大提高。例如,AWS 可以以远低于小公司的价格购买相同规格的服务器,因为 AWS 一次性购买成千上万的服务器,而不是购买几十台服务器。 同样,AWS 的每台服务器运营成本远低于自建 IDC 的公司。

技术创新
基础设施外包通常也部分归因于技术创新。比如 EC2,是通过硬件虚拟化的技术来实现的。在IaaS出现之前,一些IT供应商已经开始允许公司来按月租用物理服务器。显然,EC2 的按小时租用主机的方式更具吸引力,而且,虚拟化技术可以将物理服务器细分为许多更小的,快速启动和关闭的虚拟机(VM),这样 IaaS 才变得可行。
基础设施外包与 IaaS 的五大好处完全一致:
• 降低人工成本 :减少人员,减少维护基础设施工作所需的时间;
• 降低风险 :消除了一部分对特殊技能专家的需求,并且能够获得及时的运营支持能力;
• 降低资源成本 :同样功能的成本更低;
• 提高扩展的灵活性:可以访问更多资源和不同类型的类似资源,而不会造成重大损失或浪费;
• 缩短交付周期:缩短从新想法到生产可用性的交付时间;
当然,基础设施外包也有其缺点和局限性,我们将在后面的部分介绍。

云计算的发展
云计算的发展是从IaaS开始的,比如EC2和AWS Simple Storage Service(S3), AWS是云计算早期的推动者,紧随其后的还有微软、谷歌、阿里云等。当我们谈论“云”时,我们通常指的是公共云,但是,我们也看到了私有云的市场发展的也不错,比如OpenStack。
公共云之后的另外一个潮流是PaaS,Heroku是当时最受欢迎的PaaS厂商之一, PaaS层面置于IaaS之上,将操作系统(OS)添加到外包的基础架构中,使用PaaS,您只需部署应用程序,云平台负责操作系统安装、补丁升级、系统级监控、服务发现等。
Heroku是公有云服务,Cloud Foundry是PaaS的一个私有云版本, 由于PaaS位于现有虚拟化解决方案之上,因此您可以在企业内部部署或者在IaaS公共云服务上部署“私有PaaS”,同时使用公共云和私有云通常被称为混合云, 能够在混合云环境中实现一个统一的PaaS平台对企业特别有用。
在虚拟机之上使用PaaS的最新方式是使用容器,Docker在过去几年中变得非常非常受欢迎,因为它可以从操作系统开始,更清楚地描述应用程序的系统需求,而管理/编排容器的云服务,通常称为容器服务(CaaS),比如Google的Container Engine和AWS的ECS。 一些私有云的CaaS是Kubernetes和Mesos,您也可以把它们搭建在公共IaaS或者私有IaaS之上运行。
就像IaaS一样,PaaS和CaaS都是基础设施外包的另外一种更加高级的形式,它们和IaaS的主要不同之处是,有更高级别的抽象性,允许我们将运行应用的更多技术细节交给云平台,因此,PaaS和CaaS带给我们的好处,与我们之前列出的IaaS的五个好处完全一样,所以,我们可以将所有这三个(IaaS,PaaS,CaaS)组合为计算即服务(Compute as a Service)。
**
Serverless时代到来**
前面解释了半天云计算的发展史,主要就是想引入主题——Serverless。它将会是云计算演进的下一个重要技术,也是另外一种形式的基础设施外包,它同样具有我们已经看到的云计算的五大优势,云厂商同样也是通过规模化和技术创新来提供这些优势。

Serverless 并不等于 FaaS
大部分人开始了解Serverless时,会有一个误区,以为Serverless就是FaaS,比如AWS的Lambda,Google的Cloud Function。但深入研究就会发现,Serverless实际上涵盖了一系列技术,我们将这些技术分为两类:Backend as a Service(BaaS)和Functions as a Service(FaaS),所以,简单来说Serverless=BaaS+FaaS。

BaaS
BaaS就是用现成的第三方服务替换原来自己编码实现或者自己搭建的服务器端组件,它在概念上更接近于Software as a Service(SaaS),不同之处在于SaaS通常是关于外包业务流程,比如人力资源或销售工具,或者像Github这样的服务技术工作者的产品。然而对于BaaS来说,实际上是将应用程序分解成更小的组件,并将其中一部分组件用第三方提供的服务来完成,这个第三方服务通常就叫做BaaS。
BaaS服务是通过API远程调用的组件,而不是SDK,或者Library,我们通过远程API的调用,来完成应用程序的一部分功能。这里有一个很好的例子是身份验证,许多应用程序通过自己的代码来实现注册、登录、密码管理等功能,但是这些代码在很多应用程序中非常相似,同样的事情无数的公司和团队做过了无数遍,已经非常成熟了,可以把它们抽象出来变成一个第三方公共服务再好不过,这正是Auth0和亚马逊的Cogono等产品的目标,这两种产品都允许任何人,不需要写一行代码的情况,就可以在移动应用程序和Web应用程序上实现非常完善的身份验证和用户管理功能。

BaaS最早的时候,在移动应用程序开发中特别受欢迎,一开始人们甚至把它叫做Mobile Backend as a Service(MBaaS),但是实际上,BaaS除了被用作移动应用的后端服务之外,还可以应用到非常多的场景,比如我们可以不需要自己搭建和维护Mysql实例,而是使用亚马逊的RDS服务,或者可以用Kinesis替换自己搭建和管理的Kafka消息队列,其他数据基础设施服务包括文件系统、对象存储和数据仓库、语音分析、以及我们之前提到的身份验证,这些服务都是BaaS,都可以作为一个应用的后端服务的一部分。

FaaS
Serverless的另一半是FaaS, FaaS是Compute as a Service的另一种形式,概念上容易混淆的地方在于,AWS有时候将自己的FaaS服务,Lambda,称为Serverless Compute。
FaaS是一种构建和部署服务器端软件的新方法,只不过粒度更细,能够独立的部署某一个函数,许多人认为Serverless就是FaaS,但是实际上并不完全正确。
我们通过传统方式部署服务器端软件时,从主机实例开始,通常是虚拟机(VM)实例或容器(参见下图), 然后我们在主机中部署应用程序,如果主机是VM或容器,那么应用程序是一个操作系统进程, 通常我们的应用程序中的代码实现了一些不同功能的操作,例如,Web服务提供检索和更新资源的操作。

pic2.jpg



FaaS改变了这种部署模式(如下图), 部署模型中少了主机实例和应用程序进程,我们只关注实现应用程序逻辑的各个操作和函数,将这些函数代码单独上传到云供应商提供的FaaS平台。

pic3.jpg



但是,这些函数在云服务托管的服务器进程中缺省处于空闲状态,直到需要它们运行的时候才会被激活(如下图), 通过配置FaaS平台来监听每个函数的激活事件。 当该事件发生时,FaaS平台实例化函数,然后使用触发事件调用它。

pic4.jpg



一旦该函数执行结束了,理论上FaaS平台可以销毁掉实例,不过,通常为了优化性能,会将函数实例保留一段时间,可以被下一个事件复用。
FaaS本质上是一种事件驱动的模型,除了提供托管和执行代码的平台之外,FaaS平台还集成了各种同步和异步事件源,HTTP API网关就是一种同步事件源,消息总线、对象存储或类似于(cron)的定时器就是一种异步源。
AWS在2014年就推出了Lambda,到目前为止成熟度和接受度已经获得大幅的提高,一些公司每天在使用Lambda处理数十亿的事件,到目前为止,Lambda集成了超过20种不同类型的事件源,可以支持各种不同类型的应用程序。
除了AWS Lambda之外,还有其他一些来自Microsoft,IBM,Google厂商的商业FaaS产品,正如我们之前讨论的各种其他计算即服务平台(IaaS,PaaS,CaaS)一样,也有可以运行在私有云上开源FaaS项目,私有的FaaS领域目前比较早期,没有绝对的领先者,一些比较活跃的项目有OpenWhisk、Fission、IronFuncions、Serverless、Nuclio等。

为什么FaaS和BaaS都叫Serverless?
从表面上看,BaaS和FaaS完全不同,BaaS是托管应用程序的一部分依赖组件,FaaS托管应用程序的代码,那么为什么我们把它们放在一起,都叫做Serverless呢?
这里的关键就是不需要管理自己的服务器主机或服务器进程,完全使用Serverless架构的应用程序,将不再需要考虑服务器或者进程,应用程序的所有逻辑。无论您是自己编写的,还是与第三方服务集成的部分,都运行在完全弹性的环境中,状态也采用以类似弹性的形式存储,无服务器并不意味着服务器已经消失,这只是意味着着您不再需要关心它们了。

Serverless带给云计算的重大变化
在云计算过去十年的发展中,我们已经将应用程序的运行环境和通用组件,越来越多的外包给云厂商。Serverless也同样符合这一趋势,主机管理、操作系统管理、资源分配、扩展、甚至应用逻辑的整个组件,都外包给云厂商,在成本和运营效率方面获得了显著的提升。
但是,在应用程序架构方面,Serverless有很大的变化。之前的云计算服务,并没有从根本上改变设计应用程序的方式,例如,当使用Docker这样的工具时,我们在应用程序周围放置了一个更薄的“盒子”,但它仍然是一个盒子,逻辑架构不会发生显著的变化,在云中托管MySQL实例时,我们仍然需要考虑工作负载所需的虚拟机资源,而且仍需要考虑故障切换。

这种情况随着Serverless而发生变化,并且是非常大的变化,FaaS本质上是和传统架构非常不一样的架构类型——事件驱动模型。它的部署方式更加细粒度,以及需要将状态保存到FaaS组件之外,BaaS使我们无需编写完整的逻辑组件,但需要将应用程序与云厂商提供的特定接口和模型集成。
那么,Serverless的应用程序架构到底有什么不同之处,它看起来到底长什么样子? 这是我们接下来要讨论的内容。

IaaS+PaaS+CMP在农商行的体系化建设实践

博云BoCloud 发表了文章 • 0 个评论 • 488 次浏览 • 2019-03-28 11:03 • 来自相关话题

作为全国首批由农村信用社改制的三家股份制农村商业银行之一,江苏某农商行在大力支持经济社会中,各项业务取得了快速、稳健发展,为地方经济发展作出了巨大贡献。 为适应互联网环境下计算资源弹性变化和快速部署等需求,开展云计算架 ...查看全部
作为全国首批由农村信用社改制的三家股份制农村商业银行之一,江苏某农商行在大力支持经济社会中,各项业务取得了快速、稳健发展,为地方经济发展作出了巨大贡献。


为适应互联网环境下计算资源弹性变化和快速部署等需求,开展云计算架构规划,制定云计算应用策略,该农商行携手BoCloud博云,从业务快速迭代、提升资源利用率、信息系统维护等方面,建设强有力的金融云平台。


传统IT架构制肘业务发展

伴随银行业务和服务的拓展,其传统IT环境对资源管理、应用交付、运维管理、成本控制上亟待提升,遇到的挑战如下:

  • IT资源无法统一调度管理,资源利用率较低,自身管控压力较大;
  • 传统虚拟化技术不具备应用快速发布、应用可视化编排等功能,无法快速响应业务需求;
  • 传统虚拟化技术不支持自动弹性扩容,手动扩容耗费大量时间,且闲置资源人工回收效率低;
  • 应用部署时计算、存储、网络资源需要专业人员半自动化选择,导致操作复杂、效率低;
  • 应用的开发部署各有各的开发管理流程,配置混乱,无法保证开发、测试、验证、投产的一致性。
我们的解决方案 该农商行为提升经营能力和管理水平,解决影响业务发展瓶颈,提出了建设统一云计算平台的需求。根据以上需求,博云为该农商行建设实施了基于私有云技术的基础设施服务、应用平台服务和统一云资源管理服务:
  • 搭建基于OpenStack框架的IaaS平台,通过云资源管理平台进行异构资源池纳管、配置同步、VMware管理、虚拟机运维管理等,提供计算、存储、网络的虚拟化能力和平台自动化管理能力。
  • 选择基于博云BeyondContainer容器PaaS云平台,构建以容器Docker+Kubernetes技术为核心的PaaS平台,保证多环境一致性,通过容器管理平台完善应用运行态管理功能,支持应用弹性伸缩、高可用等能力,以容器化应用的CI/CD能力,支撑DevOps落地,实现应用弹性伸缩、快速迭代发布;
  • 选用博云BeyondCMP云管理平台,建设统一云资源管理平台,对所有IT资源实现统一纳管、统一运维、统一运营,包括对现有VMware、新建OpenStack平台的多平台统一纳管,以及对x86物理机统一纳管,形成对多种异构资源的集中资源纳管的能力;BeyondCMP云管理平台也提供充资源流程自助服务功能,可快速按需获取资源,实现对云与非云资源的统一运营管理;且平台可对云平台物理机、虚拟机状态、资源进行监控以及报表生成,帮助决策和审计,实现IT资源和服务的运营管理统一化。


价值收益


1.实现快速IT资源交付

在新业务系统上线前,利用基于模板的虚拟机置备技术和自服务模式,只需数分钟即生成新业务系统的运行环境,交付能力大大提升。


2.更好的业务连续性,更高的资源利用率

通过弹性伸缩、故障自动迁移等技术手段,实现突发性业务暴增时的资源自适应供给,以及计划性业务周期运行时的资源自适应调整和偶发性IT资源故障时的资源自动化补充,实现更高的资源利用率。


3.应用容器化,弹性支撑高并发业务场景

基于Docker容器技术的PaaS平台,支持互联网类的业务的生产环境应用。目前手机银行的营销中心服务已率先运行于生产容器平台中,并且能适应高并发下自动弹性扩容、缩容,可以及时响应高并发等新型业务需求。


4.制定规范,提升速度

博云BeyondContainer容器PaaS平台提供标准化、容器化的中间件组件服务,使各个应用的开发和运行更加便捷与规范。


5.资源统一纳管、统一运营、统一运维

BeyondCMP实现了异构资源的统一,完备生命周期监测、管理与部署调度,对基于底层各类设备生成的各类业务实现统一管理;对云和非云资源的服务实现自助化管理,发挥云平台快速按需获取资源的优势,提升整体效率、减少自身的管控压力;通过平台掌握各个业务部门的云资源使用情况,实现IT资源和服务的运营管理统一化;并通过一体化平台建设实现统一的资源监控管理、自动化运维管理、流程管理等功能,帮助运维管理人员方便有效的定位系统问题,直观快速的诊断和分析问题。


在积极响应银保监关于“十三五”的发展规划监管指导意见下,博云助力该农商行成为苏南及江苏省内农商体系首家推进实施IaaS+PaaS+CMP的农商行,实现了异构资源统一纳管,提升了IT资源服务能力和效率和应用运维管理能力;以创新能力融合业务需求,助力该农商行数字化转型;也为未来该农商行整合当前IaaS、PaaS整体平台,推出面向内外部使用者及行业的SaaS服务能力,进行更多可行方案的探索。

容器环境应用一键拉起实践

大卫 发表了文章 • 0 个评论 • 931 次浏览 • 2019-01-18 20:43 • 来自相关话题

#背景 ##PaaS平台 基于唯品会Noah云平台,我们已经在内部研发环境建立了一整套PaaS基础设施,实现对开发和测试过程的支撑。通过PaaS平台上的CI/CD流水线,实现了从代码到镜像到环境部署的整体流程;通过自研的环境管理功能(P ...查看全部
#背景
##PaaS平台
基于唯品会Noah云平台,我们已经在内部研发环境建立了一整套PaaS基础设施,实现对开发和测试过程的支撑。通过PaaS平台上的CI/CD流水线,实现了从代码到镜像到环境部署的整体流程;通过自研的环境管理功能(Pandora),实现了对多种不同内部开发测试部署环境的管理,支撑业务快速创建部署环境和利用容器镜像拉起应用,提高业务开发效率。
01.jpg

如上图所示,我们的PaaS容器部署环境目前分为功能测试环境,联调测试环境和回归测试环境三大类,其中功能测试环境包含了多个有业务开发灵活实时创建的隔离环境,用于功能验证使用,而联调和回归环境部署了所有可以上云的应用,用于各类应用的集成大联调以及上线前的回归测试验证。各个环境间通过Kubernetes的namespace进行隔离,同时在微服务应用级别也通过我们微服务基础设施提供的分区功能实现逻辑上的配置和路由隔离,从而基于同一套Kubernetes集群提供面向业务的多个逻辑上独立的环境。
##功能环境与基础设施
针对功能环境的管理,PaaS平台的Pandora组件通过图形化的配置界面,对用户隔离了Kubernetes平台的各项细节,在Noah云基础上极大的简化了Kubernetes上的应用部署和管理。主要提供了以下功能:

* 逻辑隔离环境的管理;
* 应用镜像的部署,参数化配置和应用实例管理;
* 基础资源服务拉起:在Kubernetes集群中为单独环境独立拉起Memcached,Redis,MySQL等服务;
* 基础组件设施的集成和管理:为了支撑微服务应用生态,我们有配置中心,消息中间件服务,数据库中间件服务等。这些基础服务通过逻辑分区的方式可以灵活的提供独立环境支持;
* 服务路由管理:在微服务架构下,为实现一个功能链路,单独一个应用是无法独立完成的,往往是需要依赖与其它的应用服务。被依赖的服务可以在环境内部直接访问,或者通过环境依赖的配置将请求动态路由到其它预先指定的环境内的应用(这里除了功能环境,当然也包含联调和回归环境,最大层度的重用已有服务)。

2.jpg

##实际问题
尽管通过PaaS平台的Pandora图形界面极大的简化了在环境创建和应用部署管理工作,应用本身的部署依赖不是单单依靠容器的编排可以解决的问题。

通常我们部署一个容器化的应用前,需要为这个应用在配置中心创建/修改相关的配置,需要为隔离环境开通消息服务,需要准备新的数据库、Schema和初始数据或Redis容器实例为独立的应用服务,等等一系列的操作。

对于一个应用的业务测试部署人员而言,这些信息相对容易获取,但是其他人需要在一个环境中部署自己或其它开发组织开发的应用用于测试和联调时,就必须依赖阅读现有文档或者需求其他人的帮助以便正确配置依赖的基础服务,这同时也是一项比较耗时和容易出错的工作。这些准备工作往往会占用比部署应用本身更多的时间和精力。

我们希望达到的目标是能够非常快速的和可重复的一键拉起环境和应用,自动化的解决各项依赖问题,从而极大的减少人工工作,使得业务开发专注于业务的创新,从各项环境部署和管理工作中解脱出来,提高工作效率。

对于一个自动化的部署流程,我们期望是可以在分钟级别完成整套独立环境的创建,各项基础服务的开通,数据资源容器的拉起和数据初始化以及应用的启动。并且整个流程的执行是可以动态创建和监控的,从而可以同时作为一个工具服务提供给外部自动化测试以及软件工程管理系统使用。
#应用场景
对于一键拉起功能,主要有三大应用场景和阶段:

* 应用的开发和集成测试环境:通过版本化的环境定义,自动创建环境和应用以及相关数据服务和Mock服务,从而实现组件自动化测试中的全自动化部署。
* 软件项目的生命周期自动化的一部分:将实际测试环境管理创建工作从开发和测试团队工作中分离出来。开发测试只需要定义软件相关依赖和配置,各种环境完全根据配置创建出来,并且在项目结束后自动回收。作为整体项目周期,实现从项目创建开始,关联代码repo和分支,代码质量,部署配置,自动化测试,软件部署环境以及项目结束周期。
* 基于Noah云的整体CI/CD流程关键支撑:通过将版本化的环境定义作为单一数据源,实现研发测试流程中环境的创建测试验证过程中配置数据的管理标准化,进而打通测试完成发布上线步骤的配置变更自动识别生成对比,实现和推动全CI/CD流程自动化。

目前我们主要关注的是第一部分,即应用的开发和集成测试环境的快速自动化环境,用于简化开发测试阶段的环境管理。
##一键拉起与开发/集成测试环境
目前在业务团队中,开发与测试还是遵循比较传统的分工方式:开发完成代码修改,在测试环境或者本地完成简单功能验证后提交测试部署和完成测试验收。其中的自动化过程主要有单元测试,集成测试和系统测试。通常开发只负责单元测试和部分可在本地运行的集成测试自动化,其余涉及数据准备和环境部署的测试代码通常由测试团队完成和维护。

当我们需要一个敏捷团队以最快的速度来交付稳定的产品时,这种模式无法很好的帮助我们的业务开发团队在保证高质量的同时提高交付速度:

* 测试开发分离,需要更多的沟通和协调;
* 可用环境有限,提测需要排队,多个不同功能分支无法并发执行测试;
* 反馈周期长,开发阶段不能发现的问题需要等到提测合并到发布分支后才能得到反馈。

相对传统单元测试而言(更多偏向于单个类/文件本身逻辑的测试),目前更多的测试用例实际上是类似集成测试的,对于环境包括数据库、缓存以及其他服务有一定的依赖。这种模式下相应带来的好处在于我们可以更多的按照实际业务流程以BDD(Behavior-driven development)的方式来进行测试设计开发,专注于重要的业务需求。这也要求开发人员能够更多的参与到自动化集成测试用例的设计与执行过程中去,从而更快的获取测试执行结果,了解和解决出现的问题。

目前的自动化测试运行分两类:

* 类似单元测试,但是依赖数据库/缓存和简单mock服务运行:共享外部数据库资源,没有隔离,容易发生冲突,需要协调;
* AutoV集成测试,需要本地启动数据库/缓存以及依赖的服务或mock来运行:本地资源占用大,运行和调试比较费时,速度和体验不佳。

对于开发阶段,单个应用的自动化集成测试,主要需要关注的问题包括:

* 测试环境应该尽量只包含待测应用和相关基础服务依赖,如数据库、缓存等,其余需要依赖的服务尽量以mock形式配置,减少不确定性和环境复杂性;
* 测试环境可以随时可重复的创建和销毁,保证环境和测试的可重复性以及有效利用资源,更多的运行测试;
* 应用的行为可以通过参数化的方式来配置或者实时控制(例如通过配置中心下发配置改变应用行为)。

同样,对于同一产品线下面多个应用的集成测试也是需要遵循类似的原则,保证环境的可重复创建性以及通过Mock来隔离外部的依赖。

通过一键拉起方式管理环境,可以极大的简化环境的部署配置工作,让一般比较少接触应用部署的开发人员也可以方便快速的获取单独的开发/测试环境,进而推动和方便开发人员编写和运行更多的自动化测试用例,尽早发现问题,提高整体的交付效率。
#解决方案与工作流程
要解决实际使用中的困难,统一定义和维护一套适配唯品会应用基础设施实际情况的标准化应用模型是首先需要解决的问题。我们的应用模型具体会体现为应用描述的yaml文件,可以单独和自动化测试工程保存在git repo中,也可以与应用包和镜像的版本关联,保存到应用目录服务中,从而和应用一起实现版本化的同步管理。

针对我们的实际情况,应用会需要部署到不同的环境中,在不同环境需要对应用的配置按需调整,所以我们需要将应用部署描述和环境部署描述做一个分离,从而实现应用和环境描述的解耦,通过环境对应用的引用来自动化的动态组合各个应用。

对于单个应用而言,部署时除了标准的容器CPU/内存需求之外,还会有如下应用相关的配置元素:

* 应用启动需要的环境变量配置;
* 应用在配置中心的各种变量配置;
* 应用需要创建的消息队列;
* 应用需要消费的消息队列;
* 应用对于数据资源服务的要求:MC,Redis,MySQL以及通过数据中间件接入的配置;
* 应用对数据库Schema/初始数据的配置。

3.jpg

相应在部署阶段,会有对环境的描述要求,包括:

* 环境基础服务的依赖;
* 环境资源服务:是否有公用资源服务,还是需要单独拉起资源使用,资源如何分配给每个应用;
* 环境需要部署的应用,版本,系统资源分配;
* 环境依赖信息:额外的域名解析配置,对其他环境服务的依赖,Mock服务依赖。

对于一个最简单的环境部署配置而言,只需要声明需要包含的应用和版本,系统应该自动根据应用部署描述生成环境配置:

* 环境基础服务依赖:预先配置好可用的基础服务集合,部署只需要声明需要哪一组服务;
* 系统资源分配:按应用类型默认值或者使用应用最低要求;
* 资源服务的拉起:按应用描述要求收集汇总,拉起共享服务供应用使用;
* 环境依赖:需单独声明,和环境相关。

4.jpg

整体而言,我们需要实现:

* 通过流水线生成收集版本化的应用描述模板,生成应用目录;
* 基于应用目录,结合软件项目,定义每个项目的环境部署需求,生成环境部署描述;
* 基于应用描述和环境描述自动构建独立部署环境和应用配置:

* 自动关联环境依赖的各项基础服务;
* 自动创建所需数据服务资源,并且与特定应用自动绑定;
* 自动部署应用集成版本到环境,自动处理环境更新;
* 自动处理应用对环境的各项依赖。

##自动化测试的开发和运行
基于以上解决方案,对于开发人员,我们可以比较方便的通过环境描述的声明来快速的获取一个用于开发的部署环境。

在最简单的情况下,通过声明需要的应用版本即可快速创建一个环境供使用。需要依赖的服务,可以通过对Vmock的配置获取Mock服务或者直接在当前环境中拉起实例使用。由于预先提供的应用描述已经包含数据库、缓存等信息,对应的服务也会自动在这个隔离的环境中创建出来,并且初始化完成。

对于本地测试的开发,可以直接连接这个环境运行各项测试用例而不会干扰其他人的工作或者被其他正在执行的测试干扰。

对于持续集成,也可以在代码提交编译通过后自动创建单独隔离环境运行。从而快速的获取反馈,了解修改带来的影响以及是否成功完成。

同时,如果应用已经集成了Flyway的数据迁移工具,流水线可以自动打包相关迁移脚本,从而在环境创建/应用更新过程中执行迁移,保证数据库的自动同步,让数据库版本和应用版本一起管理,减少数据不一致带来额外排查负担。

更进一步,对于开发过程中的联调,我们也不再需要依赖某一个特定环境。对方应用提供一个简单的应用配置放入环境描述以后,我们就可以在隔离环境快速的获取一个用于联调的应用实例,更好的对接口功能进行验证。
#架构与实现
5.jpg

如前所述,我们在Pandora环境管理应用中实现了一键拉起的功能并且结合应用目录服务提供给脚本,项目管理工具和自动化测试使用。应用部署功能主要通过Noah提供的API实现容器镜像部署,同时也通过监控Kubernetes事件来实现应用和服务启动过程的跟踪,驱动整个环境拉起工作流。
##核心功能设计与实现
一键拉起的整体基于Pandora已经实现的环境管理功能,核心部分在于通过应用模型和环境模型的解析,根据声明和依赖动态生成环境、应用拉起工作流,进而通过对工作流任务的并发和顺序执行,完成资源准备,服务开通和应用部署等各项任务。

相对于目前公用云和各项开源软件提供的服务,一大优势在于用户无需显式的关注一个应用或者一组应用的初始化过程,仅仅需要按照标准模型来描述应用和部署环境要求,系统会自动确定各项任务的执行顺序和并发执行能力,以最快的路径来执行应用部署流程。

对于应用的版本更新,原理是一样的。用户只需要提供一个环境中应用的最终版本要求,系统会自动对比差异,确定需要重新部署或者重新启动的应用,自动完成环境更新。
6.jpg

##事件监控与分布式处理转发
工作流的执行是一个异步过程,因此我们需要一个事件管理机制来实现事件的统一处理和转发。这里的事件包含多个事件来源:

* Kubernetes Events:数据基础服务容器和应用容器的启动监控
* 服务调用完成事件:各基础服务初始化,数据初始化等事件
* 流程管理事件:比如取消流程执行等处理

我们使用Apache Kakfa作为统一的事件总线,多个Pandora流程调度器实例会订阅该事件Topic,各自实现对当前实例内管理的流程的处理。从而可以实现动态的扩容,无需担心大规模使用后流程的分布式管理问题。
7.jpg

##数据库的初始化与版本管理
数据的管理通常是比较复杂的。不同应用会采取不同的方式来管理Schema和初始数据。我们也提供了多种方式来兼容不同的数据管理机制,包括:

* SQL脚本;
* 从集中的数据Schema治理系统获取数据Schema;
* 基于Flyway的数据自动初始化和数据迁移管理工具。

从初始数据的注入来看,由于有些应用没有很好的维护数据脚本,通常需要从一个基础的测试数据库导出初始化的SQL脚本。这种情况下数据集通常会比较大。我们在初始化执行过程中进行了优化,采用批量提交执行的策略,能够快速的批量导入数据,降低数据准备时间。
#总结与使用实践
在完成核心功能开发以后,我们和一个业务小组联合对实际经常需要同时部署的一组应用做了试用和验证,总体而言比较好的满足了复杂应用部署的要求。

这一组应用的基本情况如下:

* 多个应用域(7~20个),需要在同一个环境部署实现端到端的验证;
* 资源服务配置复杂,目前维护了众多的虚拟机:

* MySQL,多达128个分库。初始数据多达18000行SQL;
* Redis:单实例/Sharding/Cluster配置并存;
* 数据库中间件:不同应用多项服务注册使用,并且有不同应用共用同一服务的情况.

* 消息队列服务众多,往常需要逐条Channel/Queue进行配置;
* 环境变量配置工作繁重:包括多个MySQL分库,Redis实例的配置信息;
* 经常需要切换各个应用配置适应不同测试场景。

我们从现有部署环境导出了应用描述以后,经过简单定义修改数据服务相关描述,快速实现了在6~7分钟内完成所有数据库实例的初始化和应用的配置和启动,并且该过程是可以重复执行的,也就是说可以非常方便的随时根据测试场景要求快速准备出测试环境,无需手工维护各项配置和应用。对于应用版本更新,由于各基础服务已经存在,我们只需要创建新增的基础服务以及重新部署应用,可以在1~2分钟内完成。

原文链接:https://mp.weixin.qq.com/s/uug7xeawWLQKXGxeXm5wkw

领域输出才是 PaaS 的核心竞争力

shaowenchen 发表了文章 • 0 个评论 • 727 次浏览 • 2019-01-13 20:57 • 来自相关话题

1. 我在思考什么 在大公司,有更多机会了解行业动态,参与行业变革。 大平台的运行,不是依靠某一个人或几个人。如果这样真的能实现,那也就不能称之为大的平台。一个萝卜一个坑,各自分工,相互协同,才是现代的管理方 ...查看全部
1. 我在思考什么

在大公司,有更多机会了解行业动态,参与行业变革。

大平台的运行,不是依靠某一个人或几个人。如果这样真的能实现,那也就不能称之为大的平台。一个萝卜一个坑,各自分工,相互协同,才是现代的管理方式。

平台做得好,有影响力,个人也会有加持。但常常会陷入一种认知误区:将平台的能力当作自己的能力。而实际上,自己只是负责其中一个小的模块。如果自己不主动学习、思考平台的框架设计,认识不到价值密集区域,那么平台的能力也就和自己无关了。

非常幸运,我有机会参与一场 ToB 的 IT 基础架构的技术变革。在平台产品取得成功、获得影响力时,我也在不断思考,平台的核心竞争力在哪里,如何继续扩张将影响输出到其他行业。下面的内容,就是我给这些问题的答案。

2. SaaS 的特点

SaaS 是通过随时可达的方式,直接对用户提供服务的互联网软件。常见的 SaaS 有在线邮箱、笔记、办公套件、CRM、ERP 等。

# 2.1 从产品侧看

多租户。SaaS 通常是一套软件,服务所有用户。多租户模式,压缩了 SaaS 提供商的运营成本。但为了保证租户数据的安全,需要对数据进行隔离。不同的租户使用不同的数据库实例,或者通过租户 ID 的外键,对数据进行过滤。

可定制。一套通用的 SaaS 不能够满足全部客户的需求。SaaS 提供商通常会提供一些配置给客户使用,甚至直接针对客户进行定制化开发。

面向企业。虽然有提供给个人使用的 SaaS ,但是 SaaS 主要是面向企业的。ToC 的 SaaS 收费困难,通常仅能通过广告获得一定收益。ToB 的 SaaS ,天生具有盈利基因,很容易就能收支平衡。这是由于,SaaS 通常提供的是工具、效能服务,企业更愿意为提升生产效率付费。

# 2.2 从开发侧看

质量要求高。ToC 产品出了问题,只能通过官方渠道投诉,然后不了了之。但是 ToB 不一样。企业会找到售后,处理不好,会直接影响合作是否继续。

无状态。为了能够平行扩展,满足租户不断增长地性能需求,SaaS 应该是无状态的。通过异地多机器部署 SaaS 实例,分担不同租户的访问请求。将缓存、持久化、消息队列等状态,全部使用集群的方式存储,对 SaaS 提供服务。

开发框架。SaaS 需要统一的开发框架。开发框架提供的公共模块,能够减少开发量、学习成本,加快定制化开发的速度。

功能性 API。通过 API 调用,SaaS 的能力边界会被扩大。发送通知、在线支付、查询地理位置等,如果让 SaaS 实现这些功能,需要消耗大量时间,同时还不能保证质量。因此 SaaS 依附的平台应该提供相应的 API。这些 API 直接影响到 SaaS 对平台的粘性。

3. 为什么要使用 PaaS

这两年多,我的主要工作就是做 SaaS 开发,也参与过少量 PaaS 的开发。我以使用方的角色描述,PaaS 能带来什么,更加合适。

开发框架。正如上面所说的,为了提升开发效率,SaaS 开发者需要开发框架。但 PaaS 提供的开发框架,实际上主要是为了解决一致性的问题。PaaS 在进行部署时,会对 SaaS 进行编译封装,SaaS 得告诉 PaaS 一些必要得信息,比如环境变量、日志格式、启动参数等。

状态服务。由于 SaaS 无状态,PaaS 需要提供 MySQL、RabbitMQ 等公共服务,不同的 SaaS 之间,这些服务又是相互隔离不可见的。

API SDK 包。PaaS 通过企业总线(ESB)或网关(API GATEWAY),提供了大量第三方服务。开发者直接通过 HTTP 请求调用 API,容易拼错参数。通过 API SDK 包的方式,将远程 API 封装成本地函数调用,对开发者更友好。

编译部署服务。提交代码之后,通过点击按钮可以完成 CI/CD 的全过程。

监控服务。PaaS 提供日志查询,进程、服务监控等监控服务。这些指标通常是开发者关心,用来定位问题、优化性能使用。

增强服务。基础的监控服务通常不具备侵入性,对 SaaS 没有影响,但功能较弱,不能满足开发需求。这时,就可以使用增强服务,比如 Sentry、APM、Ceph 等,需要进行配置,才能使用。

正是由于 PaaS 提供了这些公共服务,SaaS 开发者只需要关注代码,实现功能即可。PaaS 带来的是开发、运维、运营效率的整体提升。

4. 如何跨行业迁移 PaaS

SaaS 能对接场景,与营收、成本直接关联。但如果场景无法收敛到足够少,PaaS 会是一个不错的解决方案。



上图是,一个通用的 PaaS 解决方案。

对于 PaaS 平台,Gartner 把它们分为两类,一类是应用部署和运行平台 aPaaS(application platform as a service),另一类是集成平台 iPaaS(integration as a service)。 人们经常说的 PaaS 平台基本上是指 aPaaS,如 Force 和 Google App Engine。甚至衍生出了大量容器即服务的公司,直接提供容器部署服务。

我认为 PaaS 的核心价值在 iPaaS 层。

在我经历的 PaaS 技术变革中,最开始是通过本地目录隔离部署,之后改为 Docker + Slug 部署,现在直接使用的是 K8S + buildpack 部署。实际上,这些对 SaaS 开发者、用户来说,意义不大,反而是 PaaS 开发者获得了更多收益。平台更易维护,资源利用效率更高,对标业界标准等。

aPaaS 层同质化严重。一套好的 aPaaS 可以全行业通用。甚至,我认为 aPaaS 层可以与 DevOps 打通,aPaaS 直接执行 DevOps 流程即可。

但,iPaaS 层不一样。iPaaS 是领域知识密集型的一层。

在运维领域,配置管理,执行作业,都是运维才会接触到的概念。iPaaS 需要将其抽象产品化,通过 API 的方式对外提供服务。

在电商领域,iPaaS 提供支付、物流、商品管理等平台服务,这些细分的领域,需要专业的人员去抽象、合规,最终仅通过 API 的形式对 SaaS 层输出领域能力。

能够将需要长时间高强度训练才能掌握的能力,通过 iPaaS 传到给 SaaS、客户,才是 PaaS 的核心竞争力。

最新版本,请查看这里: https://www.chenshaowen.com/blog/domain-knowledge-is-the-key-of-paas.html

产品技术多方平衡,企业级容器 PaaS 如何满足用户的多样化需求?

tenxcloud 发表了文章 • 0 个评论 • 527 次浏览 • 2018-12-28 17:32 • 来自相关话题

容器 PaaS 从 2015 年初开始技术布道,到吸引众多企业的关注及技术追捧,再到企业的生产环境真正落地应用,经历了 3 年多的时间。这三年,企业从初期技术路线 Kubernetes、Mesos 的选择,到技术、用户需求、产品的平衡,再到面对国内云计算 to ...查看全部
容器 PaaS 从 2015 年初开始技术布道,到吸引众多企业的关注及技术追捧,再到企业的生产环境真正落地应用,经历了 3 年多的时间。这三年,企业从初期技术路线 Kubernetes、Mesos 的选择,到技术、用户需求、产品的平衡,再到面对国内云计算 toB 市场需求越来越多样化带来的挑战。这些都对容器、Kubernetes 及相关技术提出了很高的要求。

为此,TGO 鲲鹏会专访了时速云联合创始人兼 CTO 王磊,请他来分享时速云 PaaS 平台的整体架构及核心技术、遇到的问题和解决方案、以及如何搭建高效创新的技术和产品团队。

微信图片_20181228095313.jpg


时速云联合创始人兼 CTO 王磊

王磊,曾是 IBM 中国开发实验室资深软件工程师,IBM BPM 产品开发组团队负责人,现负责时速云企业级容器 PaaS、DevOps、微服务治理等多个产品、平台及相关解决方案的技术架构、设计和研发管理工作。对容器、Kubernetes 及相关生态技术有较深入理解和研究,致力于通过云计算为企业构建新一代以应用为中心的云原生技术平台。

基于 Kubernetes 打造全新企业级容器 PaaS 平台

TGO 鲲鹏会:能否详细介绍一下时速云 PaaS 平台的整体架构及核心技术?

王磊:目前时速云的产品体系包括企业级容器 PaaS 平台、DevOps 应用交付平台和微服务治理平台,而且结合平台的特点和扩展能力,快速地为合作伙伴的中间件提供云端支撑,比如 BPM、BI、分布式数据库、大数据等相关工具或者产品。

微信图片_20181228150813.jpg

产品整体功能架构

在产品、平台的核心技术或优势上,主要有以下几方面:

  • 对 Kubernetes 部署方式的改善,可以一键部署安全的 Kubernetes 集群,并最大程度保证环境的高可用,相对原生方案部署更简单,可用性更高;所有服务组件都以容器化的方式运行,便于管理、升级,可维护性更好。
  • 操作系统及 Kubernetes 的相关调优,对系统组件资源调配和节点资源预留的把控,保障节点和服务的长时间稳定运行,并经过了多个客户生产环境复杂场景下的各种考验。
  • 通过 Kubernetes 模型 控制器的友好扩展方式,实现了对数据库、缓存、消息队列以及第三方产品的完整生命周期管理,包括创建、集群维护、监控告警、健康监测、配置管理、数据备份恢复、运行指标监控等,由系统按照用户的要求维护其期望状态。
  • 基于 Kubernetes 自研 DevOps 产品体系,使 DevOps 和 PaaS 具备同样的架构背景和技术体系,任何 PaaS 层的经验积累都可以用来在 DevOps 平台上进行运用和创新;提供一致的数据视图,构建任务产生的日志、监控、告警等数据均可以由 PaaS 层统一管控。
  • 在微服务治理方面,实现对 Spring Cloud、Dubbo 等多种微服务框架的融合,减少平台和框架能力之间的冲突,简化工具本身的复杂性;对框架本身进行定制和扩展,满足服务治理层面更丰富的需求。同时,我们开发了云服务总线,用于实现 API 发布订阅、授权、监控和协议转换等能力,也包括 WebService 和 Restful 之间的转化,能够将传统 ESB 上的服务接入,进行统一管理监控,可以作为传统服务向微服务转换的过渡支撑平台。

此外,我们非常注重技术和产品之间的平衡,不断打磨产品设计和用户体验,尽量减少技术门槛的引入。

TGO 鲲鹏会:时速云 V3.0 已经发布半年有余,如何保持产品的研发和技术的创新?

王磊:目前正处于 v3.2 和 v4.0 并行紧张开发过程中,产品的研发和技术创新,简单来说有以下几个驱动力:

以市场需求为导向,同客户进行深入交流,挖掘实际场景下对产品的需求,结合新的技术来满足需求或者解决问题,这其中就会有很多的创新点。

挖掘产品层面可优化的点,努力将产品功能、体验做到极致。

不断跟进社区、生态中的相关技术发展,对产品能力进行快速的开发、迭代和转型,通过新技术推动自身产品和用户业务场景中的创新。

此外,我们还建立了完备的研发战略决策体系、高效的研发流程、人才培养机制等,也会继续加大研发投入,为企业提供更好的产品和服务,助力企业数字化转型。

TGO 鲲鹏会:时速云作为容器云计算服务提供商,其本身的管理运维也是很重要的工作之一。时速云在平台的自动化运维,或者智能化运维上面有什么经验可以分享?

王磊:在打造云原生应用平台的过程中,我们也逐步形成了自己的自动化运维产品体系,并在内部研发部门和企业中都得到了很好的应用实践。具体可以从用户服务、节点、集群、平台等多个维度展开,同时在不减少功能和服务质量的同时,对系统逐步进行简化与技术融合:

  • 服务层面包括故障自愈能力,自定义探针,灰度发布,打散热点二次调度,横向 / 纵向的伸缩,基于监控和日志的告警及行为策略等;通过模型 控制器的方式对集群模式的服务进行自动化管理,提供声明式的资源接口,并由系统维护其期望状态。
  • 节点层面涉及到驱赶策略、自动垃圾回收、故障摘除、运维升级等能力。
  • 集群层面包括日志监控数据的定期清理,平台资源的弹性伸缩,升级、迁移或者故障恢复的工具支撑。
  • 平台层面涵盖系统服务、集群系统组件的监控告警及默认行为策略,相关数据的定时备份及故障恢复;可对历史健康指标进行回溯,统计平台各个服务的 SLA。
  • 构建基于 Kubernetes 的 DevOps 服务,统一数据及管理运维方式。
  • 将微服务框架同 Kubernetes 进行融合,简化系统复杂度和降低管理运维成本。

k8s 及容器生态已经带来了很多新的理念和技术,我们也在围绕 k8s 进行很多自动化运维的相关工作,也希望新技术、新框架的管理运维工作也可以围绕 k8s 展开,既可以构建通用的自动化运维工具和方法,也可以实现各类数据指标的统一收集,为后续 ChatOps、AIOps 打下工具和数据基础。

技术、产品多方平衡,满足用户多样化需求

TGO 鲲鹏会:容器 PaaS 在落地应用过程中遇到过哪些困难,都是如何解决的?能否举一些具体的案例?

王磊:容器 PaaS 从 2015 年初开始技术布道,到吸引众多企业的关注及技术追捧,再到企业的生产环境真正落地应用,也经历了比较长的一段时间,这个过程中也碰到了各种各样的困难。这里从产品技术、市场客户两个方面简单列举一下:

产品、技术方面

初期技术路线的选择,开始一段时间并行尝试 Kubernetes、Mesos 两种方案,以 Kubernetes 为主,半年左右完全停止 Mesos 的相关工作,也让我们比其他厂家少走了很多弯路,有了更多的技术积累,期间也听到一些对 Kubernetes 质疑的声音,过程虽然有一些挑战,但最终我们还是比较幸运的。

作为一个偏技术的平台,需要在技术、用户需求、产品之间相互平衡,需要在不偏离产品方向的基础上,用最合适的技术满足企业市场的用户需求。在面对新的用户需求时,开始会是技术和产品分别进行调研设计,避免相互引导、影响,然后再经过讨论确定最终的产品形态,使研发人员逐步养成产品的思维习惯,产品也有了更多的技术背景,长期来看会减少彼此之间不必要的矛盾,更有利于产品创新。

PaaS 层相对更接近用户的业务系统,所以项目开展过程中难免会接触用户的业务系统,这里面就会涉及到用户应用的配置管理、迁移、改造、各种系统的对接、定制化等相关工作,而这部分的工作根据客户的实际情况可能会带来较高的成本。我们针对不同的场景也逐步积累了一些解决方式,比如在应用迁移时,先整体了解应用的整体架构,尽量将相关服务开发、运维人员聚在一起进行服务容器化和部署调试工作,尤其涉及到跨部门沟通时,前期要做好充分准备工作,必要时再投入研发力量,否则在效率和成本上有很大浪费;在系统对接层面,提供平台完整的 API 文档,在其他平台需要时,可以减少很多的沟通成本。

客户市场方面

新技术、新理念带来的学习成本,以及技术生态的飞速发展带来的复杂性,都给市场、客户的培养带来了很多成本,需要进行很多技术布道和客户培养工作。客户对新技术的追捧有时甚至超过技术公司的研发速度,也对如何快速运用和管理这些新技术带来了挑战。

国内云计算 2B 市场的需求越来越多,同样,进入这个领域的企业也越来越多,竞争日益激烈;而企业在云计算层面还处于初步扩张时期,成熟度还有待提高。在云平台比拼功能(实际使用的功能可能占很少一部分)、抢占市场的大环境下,产品更需要不断的打磨核心能力,在平台可用性、可靠性层面投入更多精力。

TGO 鲲鹏会:您刚才有讲到技术方面遇到的问题,那么目前技术和团队面临的挑战是什么?接下来的重点会放在哪里?

王磊:技术层面主要挑战是如何在新技术快速发展、迭代与企业所需稳定产品之间进行平衡,以及进行长远的技术、产品发展方向规划。左手是多样的、复杂的技术生态;右手是各类行业、众多企业的场景化需求,需要运用合适的技术并尽量通过产品化的方式满足特定用户的需求,有时候会比较头疼。

团队层面,构建一个高效的、快速响应市场变化的研发团队,并保持每个成员持续高涨的技术研发热情,是一件很有挑战的事情,尤其是在一个创业型公司中。后续的重点仍然是继续积累技术和行业经验,发挥团队的力量共同打造具备可靠、简单、自动化、集成扩展、协作等特点的容器 PaaS、DevOps 和微服务治理平台,让用户更快捷、安全的进行云原生应用的实践与创新。

TGO 鲲鹏会:作为 CTO ,您在技术管理上有什么心得可以分享?如何平衡技术和管理的时间?

王磊:作为一名 CTO,越来越感到这个 title 的不易,从个人履历上看比较简单,技术管理方面在外企作过技术 leader,然后就是在创业公司从 0 搭建目前的研发团队,这里跟大家分享三点:

在大公司作技术管理比在创业公司带团队要轻松很多,不同环境下的技术管理方式上会有较大差别。在创业团队,CTO 的首要任务就是招到合适的人,培养技术和产品骨干,使他们尽快成长,成为自己的左膀右臂;其次是技术和产品方向上的把控,在市场上为公司找到最合适的定位,并抢占有利位置,考虑公司业务的可扩展性;再就是研发体系、制度、流程的规范和逐步优化。

另外,CTO 的职责随着公司的发展也会有相应的变化,从开始的全栈工程师、架构师、产品经理、技术布道师,到后來的咨询、售前、解決方案,甚至销售工作,基本体验了各种角色的工作,视野越來越宽广,接触的人越來越多。此時把有限的精力花在人员培养、技术方向把控、研发流程优化、提高研发效率等管理工作上,可以带来更大价值。对于技术和管理的平衡,当企业规模和业务复杂度达到一定程度,我认为管理的重要性更大,也值得投入更多的精力,当然,CTO 一定也要拿得起技术,否则只有 CO,可能就会瞎指挥了。

花更多的精力放在公司、技术、产品的可扩展性和持续发展上,推荐阅读《架构及未来》学习更多的经验和相关案例,对技术管理者有很大帮助。IT 就是这样一个需要持续学习充电的行业,否则很快就会落伍了,我们需要保持对技术的热情,尤其是对当前或者下一个可能技术热点的学习与探索。

本文采访记者| Bella Wu 来源: TGO鲲鹏会

时速云黄启功:容器云PaaS平台将成为IT基础设施重要组成部分

tenxcloud 发表了文章 • 0 个评论 • 607 次浏览 • 2018-12-14 15:02 • 来自相关话题

近日,爱分析在京举办了 2018 爱分析·中国云计算高峰论坛,本次论坛以“云化万物,智动未来”为主题,探讨云计算行业的发展趋势。爱分析邀请了云计算领域标杆公司时速云创始人&CEO 黄启功进行主题演讲。 ...查看全部
近日,爱分析在京举办了 2018 爱分析·中国云计算高峰论坛,本次论坛以“云化万物,智动未来”为主题,探讨云计算行业的发展趋势。爱分析邀请了云计算领域标杆公司时速云创始人&CEO 黄启功进行主题演讲。

黄启功认为,企业采用基于云原生的技术和管理方法,可以更好地把业务迁移到云平台,从而享受云的高效和资源按需供给能力。容器云 PaaS 平台作为云原生在企业的主要落地形态,解决了应用完整生命周期的管理问题。未来,容器云 PaaS 将进一步深入行业应用场景,更好地支持企业数字化转型。

现将时速云创始人&CEO 黄启功的主题演讲实录与大家分享。

01演讲实录

黄启功:大家好!首先做一下自我介绍,我是时速云 CEO 黄启功,感谢爱分析的邀请,我今天分享的主题叫“云原生应用实践与未来趋势”。

云原生既包含技术(微服务,敏捷基础设施),也包含管理(DevOps,持续交付等),是一系列 Cloud 技术、企业管理方法的集合。企业采用基于云原生的技术和管理方法,可以更好的把业务迁移到云平台,从而享受云的高效和按需资源能力,而容器云 PaaS 平台则是云原生应用重要的落地形态之一。

企业在数字化转型中普遍面临IT系统架构缺乏弹性,业务交付周期长,运维效率低,高可靠性低等痛点。企业可以通过云原生的一系列技术,例如基于容器的敏捷基础设施,微服务架构等解决企业面临的这些IT痛点。

02云原生的三大特征

2.jpg


云原生应用架构包含三个特征:容器化、微服务和 DevOps。

容器其实已有10来年的历史,2013年开源的 Docker 容器引擎,被开发者所广泛熟悉,到如今发展成为包含容器云 PaaS 等一系列商业化应用实践。

3.jpg


容器技术具有占用资源少、部署快、易迁移等特点,容器可以理解为隔离环境的“运行时”,这也很好诠释了 Docker 集装箱的理念 --- Build, Ship and Run。容器看做是一个简易版的 Linux 环境(包括root用户权限、进程空间、用户空间和网络空间等)和运行在其中的应用程序。

云原生价值的最大体现之一在于对企业 DevOps 的支持,它将企业开发运维部门很好地结合起来,以前企业的开发、测试、运维是相互割裂的状态。我们所提倡的 DevOps 理念将打破开发、测试、运维部门之间的隔阂,让整体的应用交付变得更快速。从技术角度看,DevOps 涵盖了应用的开发、编译、构建、测试、打包、发布的自动化流程,并包含了很多 DevOps 工具链。

4.jpg


云原生的第三个特征是微服务,微服务是一种架构模式,它提倡将单一应用程序划分成一组小的服务,服务之间互相协调、互相配合,为用户提供最终价值。每个服务运行在其独立的进程中,服务与服务间采用轻量级的通信机制互相沟通(通常是基于HTTP的RESTful API)。以往企业应用主要是面向服务的架构(SOA),SOA 是一种粗粒度、松耦合服务架构,服务之间通过简单、精确定义接口进行通讯,不涉及底层编程接口和通讯模型。它的缺点是架构重,难以利用云的一些特点和优势。微服务倡导细粒度的轻量级应用架构,每一个服务相对独立的,具有轻量级、易迁移、更高效等特性。


03容器PaaS的特点及优势

容器云 PaaS 平台是云原生在企业重要的落地形态之一,它包含了 PaaS 本身,以及 DevOps、微服务等。

在 IDC 的时代,用户需要管机房、物理机、包括网络、业务应用。上云之后,我们简化了这种资源的交付流程,用户获取计算、存储、网络资源变的更简单。

5.jpg


发展到 PaaS 的时候,用户不需要去关心底层的基础设施,只需要专注业务应用本身,容器 PaaS 以应用为中心,标准化、自动化应用的构建(Build)、交付(Ship)、部署运行(Run)流程,支撑应用的完整生命周期管理。通过容器云 PaaS 提供的丰富基础服务及之上的 SaaS 服务,提高 IT 设施自服务能力以及新业务的交付效率。

PaaS 最早其实是跟 IaaS 同步发展的,2011年时,国内出现了很多 PaaS 平台,包括 SAE、BAE等。第一代 PaaS 侧重提供支撑应用运行的应用引擎,我们现在所说的容器云 PaaS,则是基于云原生理念,融入 DevOps、微服务,解决了应用的完整生命周期管理问题。

6.jpg


Kubernetes 是容器云 PaaS 平台的基石,它是承载整个 PaaS 的核心。Kubernetes 是 Google 开源的一个容器编排引擎,它支持自动化部署、大规模可伸缩、应用容器化管理。Kubernetes 未来将会成为企业的云基础设施的重要组成部分,它的目标是让用户快速、简单的开发适合自己的 PaaS 或者 DevOps 平台;随着容器技术的普及,将会有越来越多的企业基于 Kubernetes 作为大规模容器的调度管理引擎,并结合自身的优势打造适合企业的 PaaS 平台。

04云原生应用的趋势

关于如何实施云原生,这里简单给大家做一些参考,首先需要对企业 IT 内部有清晰的规划,结合企业自身的 IT 业务体量。很多互联网公司通过开源的 K8S 也能简单支持一些非核心业务,构建容器 PaaS 还需要考虑一些流程,包括前期的无状态服务迁移,后期有状态、重状态的服务。

7.jpg


最先得到商业验证的是 IaaS 和 SaaS,这符合市场客观规律。在云计算进入商业成熟期时,竞争将回归到效率和成本。PaaS 本质上是云计算模型中的能力层,让客户以更高的几率赢得竞争。PaaS 把构建上层应用场景的能力抽象化,降低重复造轮子的风险和成本。基于 K8S 的 PaaS 以应用为中心,容器技术大放异彩,将会成为未来 IT 基础设施的重要组成部分。

根据 Gartner 数据显示,在 IaaS 和 SaaS 逐步成熟的时候,企业越来越强调效率提升,而 PaaS 属于云计算的能力层,已迎来了一个非常好的发展时机。

8.jpg



根据 Google Trand,我们可以看到在去年7月份的时候,PaaS 和 IaaS两大代表性的开源项目的活跃度对比,Kubernetes 的活跃度已经超过了 OpenStack,目前仍处于快速发展阶段。

9.jpg



接下来,随着 DevOps 的深化、普及,将会形成更加标准化的应用交付流程。PaaS 会逐步弱化 IaaS 层的一些概念,在某些需求场景下甚至舍弃 IaaS,在物理资源上直接部署 PaaS。微服务、服务网格、APM 等应用侧工具逐步繁荣,用户的重心向业务架构及其治理方向转移。

随着云的类型增多及其复杂性的增加,多云管理、云管平台也会出现强烈需求,另外用户对“云原生”的更多理解,会带动新的开发模式、开发框架的产生,比如 Serverless 等。

文章来源:爱分析

石油巨头如何与Kubernetes, DevOps共舞?

灵雀云 发表了文章 • 0 个评论 • 727 次浏览 • 2018-12-05 11:08 • 来自相关话题

近日,中国石油自主知识产权的勘探开发梦想云(E&P Cloud)平台V1.0在京隆重发布。作为支持梦想云落地的唯一容器 PaaS 和云原生技术领域合作伙伴,灵雀云凭借强大的技术实力和卓越的服务能力,协助中油瑞飞全程深度参与了梦想云 PaaS 平台的建设。 ...查看全部
近日,中国石油自主知识产权的勘探开发梦想云(E&P Cloud)平台V1.0在京隆重发布。作为支持梦想云落地的唯一容器 PaaS 和云原生技术领域合作伙伴,灵雀云凭借强大的技术实力和卓越的服务能力,协助中油瑞飞全程深度参与了梦想云 PaaS 平台的建设。


在不久前召开的年度开源技术盛会 KubeCon+CloudNativeCon 上,灵雀云CTO 陈恺携手中油瑞飞资深架构师迟汇发表了以“Big Oil on Kubernetes and DevOps”为主题的演讲,对勘探开发梦想云平台项目进行了阐述。


演讲分为三个部分:
首先,由陈恺做项目背景介绍;其次,由迟汇介绍基于Kubernetes、微服务和DevOps等先进技术和理念的统一技术平台的设计思路和方案;最后,再回到产品和技术,由陈恺介绍灵雀云如何协助中油瑞飞将云原生技术成功落地。
以下为演讲实录:
灵雀云陈恺:


大家好,我是灵雀云的CTO陈恺,今天要为大家分享一下灵雀云为国内最大的能源企业建设企业级PaaS平台的案例。非常荣幸请到中油瑞飞负责DevOps的迟汇和我一起为大家分享,中石油如何落地 Kubernetes 和 DevOps 。

像中石油这样体量的企业,大家可以想象业务环境的复杂和规模的庞大。复杂的业务板块面临很多挑战,比如十几个油田以前没有统一的规划,各自运行自己的IT系统,那么数据就会散落在各个地方,没有办法串联和共享,因此就无法把数据真正地利用起来。从平台级别来看,每个油田也不会做统一的IT平台,难以对上面的业务做统一的支撑。


灵雀云协助中油瑞飞建设的勘探开发梦想云就是应对这些挑战的。在底层我们会建立统一的数据库,把散落在各个油田的各种各样的数据相互之间打通,集中到一起,对数据做一个治理;中间是统一的技术平台,也就是我们今天主要讲到的基于Kubernetes的PaaS平台,这当中主要涵盖三个场景:容器、DevOps和微服务治理,相当于是整个云原生的三个核心要素。


项目的最终目标是建立统一的数据湖和统一的技术中台,在上面解决整个中石油的通用的业务。


那么接下来有请中油瑞飞的迟汇介绍一下中石油项目采用的技术和整体建设思路和方案。


中油瑞飞迟汇:


中石油的DevOps平台主要包含三个模块,第一个模块是DevOps,第二个模块是微服务,第三个模块是容器平台。


我们讲DevOps分为八大体系,分别是项目管理、知识共享、持续构建与测试、持续交付、认证与改进、学习培训、运营统计、运营监控。



pic2.jpg




整个工具链支撑体系中,涉及到的工具是15个,大部分是开源的。



pic3.jpg



下面讲述一下平台建设的部分成果展示。做这个项目的过程当中,形成了14个角色,8个职责,5个权限组。右侧是所有的认证体系,这个认证体系里面我们现在已经准备了6个测试场景,4个课件,有新项目接进来之后我们会对它有一个针对性的培训,最后是一个成熟度的评估。

pic4.jpg




灵雀云陈恺:


下面就让我们回到产品和技术层面,来讨论一下怎么样通过灵雀云的平台,为中石油复杂的业务场景搭建DevOps开发体系的。


先来简单了解一下灵雀云的产品。灵雀云有两条主要的产品线。一个是Alauda Container Platform(ACP), 他是一个高度标准化的,专注于云原生应用管理场景的赋能平台,它本身覆盖了三个场景,分别为容器平台,DevOps和微服务,也是我们云原生技术的三个核心。


pic5.jpg




另外一条产品线是Alauda Cloud Enterprise(ACE),主要面对是大型企业的统一PaaS平台。刚才分享的中石油平台就非常符合这样的场景。


ACE本身包含了ACP所有的能力,在这之上,针对大型企业建设统一PaaS平台的场景的能力又有一些加强。举几个例子,比如说ACE的客户通常来说会有很复杂的基础设施的环境,一般都会有很多个数据中心。一些客户开始尝试公有云的话,不会只用一家的产品服务,最后就会是一个异构的、混合的、跨云的基础环境。我们在每一个数据中心,或者说每一个公有云厂商上面根据他的使用需要去搭建多个K8s的集群。也就是说,管理这些异构、复杂的基础设施以及对多集群的支撑是ACE的核心能力。


在集群管理方面,我们不光可以通过ACE去部署一个灵雀云提供的K8s集群(也就是ACP),我们也可以让用户去导入一个他们已经有的K8s集群,现在我们已经有了一些这方面的实践。


另外一个针对大型企业统一PaaS平台的场景,是企业内部共同的需求。一般来说,企业内部会有几大类职能用户,和我们直接合作的是企业内部的平台部门,这个Team对企业内部的业务部门来说,是云平台的提供者和服务团队。


在此基础之上,ACE典型的使用场景通常来说会有几千个开发者,甚至更多。他们之间也需要根据不同的项目或者不同的部门,去划分出不同的租户,租户内部有团队内部协作的需求,租户之间有一些权限隔离和资源隔离,这也是ACE需要解决的另外一个问题。


pic6.jpg




回到今天的主题DevOps。DevOps是ACE一个核心的模块,在我们跟企业客户了解做 DevOps 诉求的时候,每一家都已经在使用一些工具并且有自己的流程,我们需要把现有的系统进行完善,而不是提供一个封闭式的产品去替代以前用的工具。


所以ACE DevOps 的整体思路,是提供一个开放式的DevOps工具链的集成和编排平台,通过集成之前客户已经在用的,以及需要的新的工具变成一个工具链,然后通过编排把这些工具和平台变成一个整体,最后可以贯穿整个应用全生命周期的管理。ACE的核心价值是将 DevOps 的最佳实践,加以提炼形成一个自动化的平台服务,提供给用户。


DevOps工具链集成一方面需要每个工具通过API集成在我们的容器平台上,另一方面,每个工具和平台的用户权限需要打通。每一个企业级的工具都会有自己的租户模型,这些租户模型和平台本身的租户模型需要有联动和对应。这样平台上的数千个工程师,在不同的项目里面共享这些工具时,会有一定的规范。在ACE中,一些核心场景的主流工具,我们会做深度的集成。在这种情况下,80%以上的使用场景在平台本身就可以完成。


刚才有提到,使用ACE在大型企业内部搭建一个统一PaaS平台,分成两类用户:一个是平台部门,负责搭建、维护平台以及对其他业务部门提供支撑和服务,他是平台管理员;另一个是业务部门,可以理解为企业内部的一些项目,也就是平台上面的一个个租户。在使用上大致的流程是这样的:平台部门准备基础设施,需要去部署和准备一些已有的集群,然后会在平台上面创建租户,并且设置管理员,他可以把集群的资源分给租户。租户管理员获取资源后,可以在集群里面创建环境,可以主动把资源向下派分。


对于DevOps实现来说,管理员可以部署和集成一些工具,然后可以把工具发布出来让租户自行订阅。同时,他也可以给每个工具去创建一些资源,然后主动把这些资源分配给租户。从根部管理员这边获得DevOps工具的资源有三种方式,一是管理员主动分配的,二是开发者订阅了管理员发布的库,第三,开发者也可以在平台上自己部署一个工具。


由于时间关系今天就和大家分享到这里,如果想要了解更多关于灵雀云在各个行业的产品实践,可以会后交流,谢谢大家!

透视云原生热的背后

灵雀云 发表了文章 • 0 个评论 • 741 次浏览 • 2018-10-30 14:02 • 来自相关话题

PaaS热、容器热、Kubernetes热、微服务热、DevOps热,这么多的热汇聚到一起,形成了云原生应用热。云原生应用热与以往众多的技术热潮不同,因为它是由业务需求驱动的,是第一次在信息技术与业务之间产生了化学反应,也是自上层应用开始延伸至底层基础架构的自 ...查看全部
PaaS热、容器热、Kubernetes热、微服务热、DevOps热,这么多的热汇聚到一起,形成了云原生应用热。云原生应用热与以往众多的技术热潮不同,因为它是由业务需求驱动的,是第一次在信息技术与业务之间产生了化学反应,也是自上层应用开始延伸至底层基础架构的自上而下的一场具有颠覆性的变革。



自上而下的变革



“同行是冤家”,这是多少年来不变的商业规则。但是今天,颠覆往往不是来自于行业内部,而同行之间也未必是最直接的竞争对手。银行惧怕的是互联网金融,酒店业正在被Airbnb蚕食,出行不可缺少的是共享单车……



传统企业迫切希望像互联网公司那样思考,采用互联网架构实现应用的快速迭代,服务B端客户时也要像服务C端客户那样注重应用体验。传统企业与互联网企业竞争,非云原生应用与云原生应用竞争,这就是越来越多的企业用户选择云原生应用的原因。

“企业做不做云原生应用,这是由业务决定的。而如何实现云原生,则可以视企业的实际情况选择不同的技术路线。应用先上云再做架构改造,还是一步到位直接采用全新的云原生架构,企业用户要深思熟虑。”

——灵雀云CEO左玥



“云原生应用的兴起与数字化转型的节奏是一致的,是从应用层面开始的。如果不是业务在驱动,云原生应用的发展就不会像今天这么快。”灵雀云创始人兼CEO左玥如是说。


最近两三年,来自业务侧的压力推动着行业的快速发展与转变,金融科技、车联网、新零售,无一例外。生存还是死亡?这在今天看来并不是一道让人纠结的选择题。采用单体架构的企业如果不采用解耦的分布式架构,不采用新的DevOps开发流程,不能像互联网企业那样一天进行200次迭代,而是还像原来那样半年或一年进行一次应用更新,那么企业注定将无法继续生存。从物理机到虚拟化再到容器化、微服务和DevOps,更加灵活的IT架构、更加便捷高效的开发流程,这就是云原生,并不存在什么难以逾越的鸿沟。



左玥认为,云原生架构与传统IT架构之间是替代的关系,云原生架构是传统IT架构的下一步发展趋势。从传统IT架构过渡到云原生架构可能要经历很长一段时间,过渡的方式也有多种选择,既可以采用比较激进的方式,也可以采用循序渐进的方式。比如,因商业竞争所需,企业基于云原生架构重写应用程序,这就是比较激进的方式。采用这种方式,企业一定要下定决心,而且需要投入大量人力物力。这有点像壮士断腕,好处是可以一步跨越到云原生模式,便于以后的开发和应用。



然而对于大多数企业来说,他们不可能中断现有的业务,将全部精力用于打造云原生应用,因此可以采用相对保守的过渡方式,比如可以先将传统应用迁移到云上,然后再选择适合的时机转换为云原生应用。



应用上云与云原生应用,这是两个不同的概念。“企业做不做云原生应用,这是由业务决定的。而如何实现云原生,则可以视企业的实际情况选择不同的技术路线。应用先上云,再做架构改造,或者一步到位,直接采用全新的云原生架构,企业用户要深思熟虑。”左玥表示。



从技术的角度讲,采用了容器、微服务、DevOps就可以称为云原生应用,这听上去似乎很简单,但实际上已经覆盖了从研发到业务流程再到运维的企业IT的全部内容。云原生的概念从雏形到成熟,并得到整个行业的认可有一个发展过程。一开始,企业用户可能只是想通过采用容器、DevOps等加速开发流程,实现应用的快速上线和迭代。到整个行业都在谈论云原生的概念时,很多企业用户才意识到,原来他们正在做的就是云原生应用。



左玥告诉记者,在政府、石化等行业中,一些头部客户正准备在单位内部全面构建云原生应用,规模之大、应用之深有些出乎他们的意料。如今,越来越多的中国企业用户对云原生应用产生了强烈的需求,但在实际执行和实现的过程中可能还存在困惑或者障碍。这也是下一步致力于云原生应用的厂商需要突破的难关。



加速云原生应用的普及



左玥分享了他对全球云原生市场的观察:从时间上看,中国与国外几乎是同时起步,差距不大。但是从现在的普及程度上来看,中国与美国市场还是有差别的,比如两年前美国企业采用Kubernetes的也不多,但现在可能90%以上的企业都在使用。而中国各行业的头部客户虽然也在考虑云原生应用,但只是刚刚开始,还需要一个转变过程。


CNBPA.jpg



云原生技术实践联盟(CNBPA)火了



从用户的角度看,中国的云原生市场还需要教育和引导;从厂商的角度看,大家需要一个沟通和交流的平台,在理念、技术、应用的创新方面还要不断提高。由灵雀云发起的云原生技术实践联盟(CNBPA)近日正式成立,招商银行、中国石油、国家电网、树根互联、中科软、东华软件、北明软件、腾讯云、灵雀云、F5等成为首批创始成员。



左玥向记者表示:“成立联盟并不是一种商业行为,也不是为了制定规范或标准,就是单纯地希望为从事云原生应用的企业、同行打造一个跨业交流的平台。厂商与厂商、厂商与用户、用户与用户之间可以相互学习借鉴。意识和行动超前的用户可以成为学习的榜样,而在业务上各有侧重的厂商之间也可以形成互补,共同打造一个经过测试的成熟完整的云原生解决方案。”在联盟成立大会结束后,参会的很多企业用户主动找厂商索要联系方式,交流和讨论的氛围十分热烈。



在中国,云原生毕竟还是一个新生事物,在落地过程中,不仅技术上有一定门槛,管理上也存在问题。企业如果还守着原来的IT架构,也不改变原有的开发流程、组织架构,那么DevOps就是纸上谈兵。大多数国内企业已经习惯了采用外包或依赖第三方ISV。因此,在中国推动云原生应用的普及,点燃ISV、外包服务公司的热情也是非常重要的一环。CNBPA就吸纳了许多行业知名的ISV。



左玥表示,从今年开始,国内的许多ISV在云原生应用方面有了积极的转变,一方面是用户方的压力所致,另一方面ISV自身也有转型的需要。以前,ISV可以通过缩减人力来降低成本,现在则必须通过技术、流程和工具的改进来降低成本。CNBPA的首批成员——中科软、东华软件、北明软件都已经在云原生方面发力。只经过一两个月的接触,灵雀云就与北明软件达成了合作,未来双方在解决方案层面将以云原生作为首选。



数字化转型是所有企业的必由之路。所谓春江水暖鸭先知,那些站在行业前沿和“风口”、面临极大竞争压力的行业用户,比如金融、汽车、航空等行业的客户,在云原生应用方面表现得尤为积极。



云原生呼唤平台厂商



作为云原生应用的倡导者和实践者,灵雀云通过“平台+生态”的方式,助力企业用户快速实现数字化转型的同时,也在寻求自身的突破。


在CNBPA成立大会上,灵雀云发布了一站式云原生应用赋能平台Alauda Container Platform(ACP)、企业级容器PaaS平台Alauda Cloud Enterprise(ACE),以及云原生机器学习赋能平台Alauda Machine Learning (AML)。如果将企业的数字化转型分成应用现代化和数据现代化两部分,那么ACP与ACE就是应用现代化的坚实基础,而AML则是数据现代化的一种有益尝试。







左玥解释说,ACP是云原生应用的赋能工具,任何一个企业都需要这样一个工具。尤其是节点数不多的中小型企业,可以十分方便地在这样一个标准化的平台上快速建立和使用云原生应用。而ACE就是一个包罗万象的云平台,一个大型客户的所有业务都可以在这个平台上实现。它可以支持企业建立一个覆盖整个企业内部各个环节和组织结构的私有云平台,具有多租户、多集群等特性。



灵雀云的一个目标是将公有云上的各种功能都能以容器、开源的形式提供给企业客户,而机器学习就是其中的一个。AML集成了数据科学家的常用工具,可以创建分布式环境并展开实验。AML还可与ACP联动,实现从模型的开发、训练、验证、发布到再训练的流程自动化。通过AML与ACP等产品线的集成,最终可以实现模型持续训练、优化、验证的完整闭环。



“灵雀云将与合作伙伴携手,共同打造更多类似AML这样的工具,推动数据现代化的发展。”左玥表示,“未来,我们还会开发更多的产品,而这些产品的底座和核心就是ACP和ACE,以便更好地支持云原生应用和大型集团客户。”







云原生领域的参与者越来越多,大家在业务上各有侧重,有人关注垂直行业和领域,有人则着力打造通用平台。灵雀云就是后者,它一直在集中精力打造和完善云原生的私有云平台,同时也支持混合云和多云。虽然当前灵雀云的体量还不算大,但是致力于成为一家平台型企业的初心始终未曾动摇。无论从市场知名度、技术先进性还是客户基础来看,在PaaS云平台这一领域,灵雀云在私有云方面已经领先了一个身位。



灵雀云在金融、政府、石化等行业拥有许多大型客户。这些客户在选择供应商时通常非常谨慎,而最终他们没有选择所谓的大厂商,而是与灵雀云这样的成长型企业合作,一方面因为那些大厂商还没有成熟的云原生产品和服务,另一方面也因为灵雀云拥有过硬的产品和解决方案,而且自身业务快速增长、体量不断增加,还有许多具有行业影响力的大客户背书。让左玥感到自豪和有底气的是,灵雀云目前拥有一支100多人的云原生专业研发团队,这一规模在业内是首屈一指的。



今年国庆节假期的前一天,也就是9月30日,记者到灵雀云公司拜访左玥时,已经中午12点多,很多员工还在坚守岗位,公司所有的会议室都有人在开会。如果没有这种拼搏精神,灵雀云也不会有今天这样快速的成长。据记者了解,灵雀云已经在规划走向国际市场。



中国最不缺的就是App开发企业,而在企业级应用开发交付和管理领域,大型的核心平台厂商始终是空白。左玥有信心开创这一先河。具有颠覆性的云原生给了灵雀云这样一个机会。介入早、积累深、踏实肯干、愿意投入并长期坚守,虽然困难很多,但是灵雀云愿意去尝试和挑战。

企业上云不可或缺的关键环节

博云BoCloud 发表了文章 • 0 个评论 • 643 次浏览 • 2018-09-14 11:05 • 来自相关话题

云管理平台(Cloud Management Platforms,CMP)近两年来被业界广泛提及,但因为其市场较新,加之不少企业对 CMP 平台建设存在较多认知误区,此次InfoQ记者就此采访了BoCloud博云,带大家详细了解云管理平台。 ...查看全部
云管理平台(Cloud Management Platforms,CMP)近两年来被业界广泛提及,但因为其市场较新,加之不少企业对 CMP 平台建设存在较多认知误区,此次InfoQ记者就此采访了BoCloud博云,带大家详细了解云管理平台。

云管理平台发展的背景

随着云计算技术的普及,越来越多的企业都在上云。但是公有云、私有云、云原生及底层基础架构日趋复杂,企业级应用流程管理和云管理平台的诞生和发展显得迫在眉睫。

根据博云多年的企业服务经验来看,企业上云的步骤一般可分为尝试阶段和全面上云阶段两个部分。在尝试阶段,企业初始做云化,一般会从开发测试环境开始,尝试和对比不同云服务以及基础设施架构;在全面上云阶段,对基础设施进行改造,搭建云平台业务上云。

经过尝试阶段进入全面上云阶段的时候,企业会面临一些典型的问题,这些问题你可能也经历过或正在经历:

  • 在实施云战略的整个IT建设过程中,企业往往会面对不同的云平台甚至容器平台,不同的网络SDN,分布式存储和传统存储等多种异构环境。这些异构资源应该如何处理?
  • 在云服务场景下,不同部门或子公司在申请IT资源的时候,如何能够面向业务提供服务,通过资源统一配置,并在统一界面上提交申请最后获取资源?
  • 既使用私有云又使用公有云时,如何能对公有云和私有云进行统一管理和统一调度,来达到既使用公有云的弹性资源扩充,保证数据在本地?
  • 云平台搭建好业务上云以后,如何进行整体的运维管理?
  • ……
针对企业上云过程中主要面临的问题和场景,云管理平台应运而生。云管理平台(Cloud Management Platform,CMP)是由Gartner最先提出的企业云战略中一种产品形态,提供的核心能力包括以下几个方面:
  • 整合和管理多种异构基础设施和资源;
  • 跨平台调度编排,让用户高效、灵活地在不同云平台使用云资源;
  • 通过自助服务界面,统一管理资源访问和流程配置。

云管理平台在国外已经发展多年并且已经相对成熟。一开始是一些云厂商提供自带云管理平台,也就是只管理自有云平台的原厂云管;后来出现了所谓的管异构云的云管平台;然后是针对异构资源的管理平台,不仅对异构云,对物理机、数据库、传统存储等资源都要做统一管理,可以称为“大云管”。

如何建设云管理平台

云管理平台能够帮助企业管理好云资源,用好云服务,在企业云化过程中是非常重要,甚至可以说是不可或缺的。从整个行业的发展来看,最近这两年企业大规模上云之后,对云管理平台的需求非常明确,也很迫切。那么企业应该如何建设云管理平台呢?

Forrester曾在云管理平台技术报告中提供了一个参考架构,整个云管理平台主要的架构模块可以分为“Application Service Delivery(应用服务交付)”、“Infrastructure Service Delivery(基础设施服务交付)”、“Hybrid Cloud Operations(混合云运维)”和“Hybrid Cloud Goverance (混合云治理)”,并且需要对下提供多云接入API,对上提供自服务portal和管理portal。


图片1.png



在博云看来,整个IT架构底层是各种资源,资源之上为管理平台,在资源层和管理平台之间还应该有一个重点的调度层。

举例来说,每种公有云都有很多不同的资源,包括虚拟机,网络,存储以及安全设备。这些资源的操作大同小异,但是不同公有云的API不一样,应该有一层用来对公有云进行统一调度,对上提供统一的API。

此外,云管理平台的目的是统一纳管,统一运维管理,统一服务,它是由很多服务组成的,而在真正落地的时候,用户的需求又千差万别,并不是云管理平台中所有的服务都会用到。所以云管理平台的建设非常适合使用微服务架构。

以上就是博云BeyondCMP多云管理平台的设计思路。博云首先在云管理平台中增加了调度层,对存储、计算、网络等异构资源做统一模型,这里面的技术难度很大,也是博云BeyondCMP多云管理平台的突出功能。此外,从管理角度来说,因为CMP面向的对象很多,博云会把各种业务拆成微服务。


微信图片_20180912114306.png



具体而言,博云BeyondCMP多云管理平台的CMDB资产管理可以通过可视化进行流程的定制和编排,同时具有自动化和应用级别的自动部署能力。在技术上,博云BeyondCMP多云管理平台主要以自研为主,在公有云业务的纳管上,博云没用LibCloud的多云纳管的开源技术,自动化上则采用了Ansible,监控上用Zabbix来做。

博云的多云管理平台对公有云厂商开放,这是业务的需求。公有云厂商都有自己的云管理平台,但是彼此之间并不互管,一方不愿管,一方不愿被竞争对手管,自然需要有中间厂商来做跨云管理。

云管理平台的定位

我们都知道云计算一般分为三层:IaaS, PaaS 和SaaS,通常大家对于云管理平台的定位是在PaaS层之上。

在博云看来,在整个云计算技术栈中,云管理平台应该位于IaaS、PaaS和SaaS层的侧面,因为它不是提供资源的平台,而是管理资源和应用的平台。


图片2.png



很多企业都会有自己的运维管理系统,比如流程平台,监控平台等,云管理平台可以跟用户的流程平台和监控平台对接,把资源申请过程和云资源的监控都能接到用户方面。而云管理平台跟底层资源之间就是对异构资源的纳管关系。


微信图片_20180912115135.png



博云的云管理平台自己也有CMDB,可以通过CMDB准确地配置资源。如果客户有自己的CMDB,只需要跟博云的CMDB做同步就可以了。

弄清楚了云管理平台跟周边系统的关系,很多人还是会疑惑云管理平台跟PaaS和容器云的区别。一般来说,如果IaaS层挂了,整个数据中心的计算存储都没有了,如果容器层挂了,就没有来运营的运行基础,应用会出问题。但如果云管理平台出了问题,应用和业务还能正常运行,只是没法做管理了,所以云管理平台更多是做管理,它的能力是获取基础资源,而容器云,或者PaaS的能力是扩充资源。

博云也有BeyondContainer容器云平台,容器云跟云管理平台两者的区别简单来说,容器云平台管应用,利用微服务思想和DevOps理念,实现应用和服务的管理运维;云管理平台管资源,通过云管理平台管理数据中心等基础资源,给客户提供一个虚拟的可视化资源视图,客户可以在此基础上做资源编排,资源管理自动化的操作。


微信图片_20180912114832.png



云管理平台的发展趋势

目前全云化的世界已然形成,为了更好地帮助企业上云,云管理平台自身也需要不断发展演进。博云认为云管理平台在以下三个方面有长期演进的趋势:

统一运维管理上:现在很多平台已经具备了运维自动化的基础,能增强自动化部署减少手工操作。在运维自动化的基础上下一步就是运维智能化,如故障自愈,智能迁移,流量管理等方面还需要不断发展;

统一纳管上:云的统一相对简单,是PR操作,但是异构存储和分布式存储的纳管就比较难,整个网络的SDN的联动,就更是行业难点了,这也是云管理平台需要发展的方向;

运营服务上:目前博云提供了租户隔离、服务目录、计量计费统计报表等运营能力,这是一个基础。运营服务上的其他很多细节,包括SLA,计费模型,甚至多云之间的智能选择,都是要在运营分析方面长期去发展的。

总而言之,云管理平台是云时代充分发挥云计算特性优势大幅提升生产力、应对新增混合云多云资源管理问题的平台工具,而在国内企业的云战略建设过程中,普遍缺少云管理平台这一环。如今,云计算已经变成像水和电一样基础。企业如果不能及时转型,研发效率就得不到提升,导致跟不上业务,最终就会被时代抛下。使用云服务,用户无需花大精力在底层基础设施上,能将更大的精力投入到业务研发。而一旦开始上云,就需要云管理平台来帮助管理云资源用好云服务。企业上云的过程是需要规划的,那么云战略的建设规划过程中,千万不要遗漏云管理平台这一重要环节。
条新动态, 点击查看
郭蕾

郭蕾 回答了问题 • 2015-03-19 11:17 • 13 个回复 不感兴趣

PaaS的前景如何?CaaS了?

赞同来自:

这个问题非常好,我也经常思考这个问题,特别是当容器流行之后,很多人开始思考是CaaS好还是PaaS好。然后我也看到有很多的Docker创业公司开始用Docker做PaaS,所以我的倾向还是说市场其实是接受PaaS的。IaaS的大风算是过去了,如果说要从云计算层... 显示全部 »
这个问题非常好,我也经常思考这个问题,特别是当容器流行之后,很多人开始思考是CaaS好还是PaaS好。然后我也看到有很多的Docker创业公司开始用Docker做PaaS,所以我的倾向还是说市场其实是接受PaaS的。IaaS的大风算是过去了,如果说要从云计算层面去定义IaaS、PaaS、CaaS的话,我觉得很难。随着时代的发展,他们之间的界线会越来越小。我认为如果技术发展成熟,云计算发展成熟,那IaaS应该就只是大公司、有运维能力的公司去玩的东西。更多的中小型公司会转型使用PaaS,他们不需要有运维工程师,开发工程师只要使用容器(集装箱)与PaaS交互即可。他们为什么需要用那么重的IaaS?数据库调优、备份管理,PaaS完全可以做吗,这也为啥现在很多IaaS厂商都提供PaaS功能的原因。所以不是说PaaS不被接受,而是部分不被接受。 PaaS对用户限制太多,这要看白盒还是黑盒,反过来再说,不限制你,你要做什么去又? CaaS的发展还早,CaaS要成熟,起码需要Docker之类的容器的生态圈先成熟,比如调度、编排、监控、资源管理,现在都还没定论。CaaS和PaaS会是说不清的关系,会越来越像。SAE、BAE发展不好,我不敢贸然评价,只是想问个问题:你看看他们的界面,你觉得那是个互联网时代的产品吗?

容器环境应用一键拉起实践

大卫 发表了文章 • 0 个评论 • 931 次浏览 • 2019-01-18 20:43 • 来自相关话题

#背景 ##PaaS平台 基于唯品会Noah云平台,我们已经在内部研发环境建立了一整套PaaS基础设施,实现对开发和测试过程的支撑。通过PaaS平台上的CI/CD流水线,实现了从代码到镜像到环境部署的整体流程;通过自研的环境管理功能(P ...查看全部
#背景
##PaaS平台
基于唯品会Noah云平台,我们已经在内部研发环境建立了一整套PaaS基础设施,实现对开发和测试过程的支撑。通过PaaS平台上的CI/CD流水线,实现了从代码到镜像到环境部署的整体流程;通过自研的环境管理功能(Pandora),实现了对多种不同内部开发测试部署环境的管理,支撑业务快速创建部署环境和利用容器镜像拉起应用,提高业务开发效率。
01.jpg

如上图所示,我们的PaaS容器部署环境目前分为功能测试环境,联调测试环境和回归测试环境三大类,其中功能测试环境包含了多个有业务开发灵活实时创建的隔离环境,用于功能验证使用,而联调和回归环境部署了所有可以上云的应用,用于各类应用的集成大联调以及上线前的回归测试验证。各个环境间通过Kubernetes的namespace进行隔离,同时在微服务应用级别也通过我们微服务基础设施提供的分区功能实现逻辑上的配置和路由隔离,从而基于同一套Kubernetes集群提供面向业务的多个逻辑上独立的环境。
##功能环境与基础设施
针对功能环境的管理,PaaS平台的Pandora组件通过图形化的配置界面,对用户隔离了Kubernetes平台的各项细节,在Noah云基础上极大的简化了Kubernetes上的应用部署和管理。主要提供了以下功能:

* 逻辑隔离环境的管理;
* 应用镜像的部署,参数化配置和应用实例管理;
* 基础资源服务拉起:在Kubernetes集群中为单独环境独立拉起Memcached,Redis,MySQL等服务;
* 基础组件设施的集成和管理:为了支撑微服务应用生态,我们有配置中心,消息中间件服务,数据库中间件服务等。这些基础服务通过逻辑分区的方式可以灵活的提供独立环境支持;
* 服务路由管理:在微服务架构下,为实现一个功能链路,单独一个应用是无法独立完成的,往往是需要依赖与其它的应用服务。被依赖的服务可以在环境内部直接访问,或者通过环境依赖的配置将请求动态路由到其它预先指定的环境内的应用(这里除了功能环境,当然也包含联调和回归环境,最大层度的重用已有服务)。

2.jpg

##实际问题
尽管通过PaaS平台的Pandora图形界面极大的简化了在环境创建和应用部署管理工作,应用本身的部署依赖不是单单依靠容器的编排可以解决的问题。

通常我们部署一个容器化的应用前,需要为这个应用在配置中心创建/修改相关的配置,需要为隔离环境开通消息服务,需要准备新的数据库、Schema和初始数据或Redis容器实例为独立的应用服务,等等一系列的操作。

对于一个应用的业务测试部署人员而言,这些信息相对容易获取,但是其他人需要在一个环境中部署自己或其它开发组织开发的应用用于测试和联调时,就必须依赖阅读现有文档或者需求其他人的帮助以便正确配置依赖的基础服务,这同时也是一项比较耗时和容易出错的工作。这些准备工作往往会占用比部署应用本身更多的时间和精力。

我们希望达到的目标是能够非常快速的和可重复的一键拉起环境和应用,自动化的解决各项依赖问题,从而极大的减少人工工作,使得业务开发专注于业务的创新,从各项环境部署和管理工作中解脱出来,提高工作效率。

对于一个自动化的部署流程,我们期望是可以在分钟级别完成整套独立环境的创建,各项基础服务的开通,数据资源容器的拉起和数据初始化以及应用的启动。并且整个流程的执行是可以动态创建和监控的,从而可以同时作为一个工具服务提供给外部自动化测试以及软件工程管理系统使用。
#应用场景
对于一键拉起功能,主要有三大应用场景和阶段:

* 应用的开发和集成测试环境:通过版本化的环境定义,自动创建环境和应用以及相关数据服务和Mock服务,从而实现组件自动化测试中的全自动化部署。
* 软件项目的生命周期自动化的一部分:将实际测试环境管理创建工作从开发和测试团队工作中分离出来。开发测试只需要定义软件相关依赖和配置,各种环境完全根据配置创建出来,并且在项目结束后自动回收。作为整体项目周期,实现从项目创建开始,关联代码repo和分支,代码质量,部署配置,自动化测试,软件部署环境以及项目结束周期。
* 基于Noah云的整体CI/CD流程关键支撑:通过将版本化的环境定义作为单一数据源,实现研发测试流程中环境的创建测试验证过程中配置数据的管理标准化,进而打通测试完成发布上线步骤的配置变更自动识别生成对比,实现和推动全CI/CD流程自动化。

目前我们主要关注的是第一部分,即应用的开发和集成测试环境的快速自动化环境,用于简化开发测试阶段的环境管理。
##一键拉起与开发/集成测试环境
目前在业务团队中,开发与测试还是遵循比较传统的分工方式:开发完成代码修改,在测试环境或者本地完成简单功能验证后提交测试部署和完成测试验收。其中的自动化过程主要有单元测试,集成测试和系统测试。通常开发只负责单元测试和部分可在本地运行的集成测试自动化,其余涉及数据准备和环境部署的测试代码通常由测试团队完成和维护。

当我们需要一个敏捷团队以最快的速度来交付稳定的产品时,这种模式无法很好的帮助我们的业务开发团队在保证高质量的同时提高交付速度:

* 测试开发分离,需要更多的沟通和协调;
* 可用环境有限,提测需要排队,多个不同功能分支无法并发执行测试;
* 反馈周期长,开发阶段不能发现的问题需要等到提测合并到发布分支后才能得到反馈。

相对传统单元测试而言(更多偏向于单个类/文件本身逻辑的测试),目前更多的测试用例实际上是类似集成测试的,对于环境包括数据库、缓存以及其他服务有一定的依赖。这种模式下相应带来的好处在于我们可以更多的按照实际业务流程以BDD(Behavior-driven development)的方式来进行测试设计开发,专注于重要的业务需求。这也要求开发人员能够更多的参与到自动化集成测试用例的设计与执行过程中去,从而更快的获取测试执行结果,了解和解决出现的问题。

目前的自动化测试运行分两类:

* 类似单元测试,但是依赖数据库/缓存和简单mock服务运行:共享外部数据库资源,没有隔离,容易发生冲突,需要协调;
* AutoV集成测试,需要本地启动数据库/缓存以及依赖的服务或mock来运行:本地资源占用大,运行和调试比较费时,速度和体验不佳。

对于开发阶段,单个应用的自动化集成测试,主要需要关注的问题包括:

* 测试环境应该尽量只包含待测应用和相关基础服务依赖,如数据库、缓存等,其余需要依赖的服务尽量以mock形式配置,减少不确定性和环境复杂性;
* 测试环境可以随时可重复的创建和销毁,保证环境和测试的可重复性以及有效利用资源,更多的运行测试;
* 应用的行为可以通过参数化的方式来配置或者实时控制(例如通过配置中心下发配置改变应用行为)。

同样,对于同一产品线下面多个应用的集成测试也是需要遵循类似的原则,保证环境的可重复创建性以及通过Mock来隔离外部的依赖。

通过一键拉起方式管理环境,可以极大的简化环境的部署配置工作,让一般比较少接触应用部署的开发人员也可以方便快速的获取单独的开发/测试环境,进而推动和方便开发人员编写和运行更多的自动化测试用例,尽早发现问题,提高整体的交付效率。
#解决方案与工作流程
要解决实际使用中的困难,统一定义和维护一套适配唯品会应用基础设施实际情况的标准化应用模型是首先需要解决的问题。我们的应用模型具体会体现为应用描述的yaml文件,可以单独和自动化测试工程保存在git repo中,也可以与应用包和镜像的版本关联,保存到应用目录服务中,从而和应用一起实现版本化的同步管理。

针对我们的实际情况,应用会需要部署到不同的环境中,在不同环境需要对应用的配置按需调整,所以我们需要将应用部署描述和环境部署描述做一个分离,从而实现应用和环境描述的解耦,通过环境对应用的引用来自动化的动态组合各个应用。

对于单个应用而言,部署时除了标准的容器CPU/内存需求之外,还会有如下应用相关的配置元素:

* 应用启动需要的环境变量配置;
* 应用在配置中心的各种变量配置;
* 应用需要创建的消息队列;
* 应用需要消费的消息队列;
* 应用对于数据资源服务的要求:MC,Redis,MySQL以及通过数据中间件接入的配置;
* 应用对数据库Schema/初始数据的配置。

3.jpg

相应在部署阶段,会有对环境的描述要求,包括:

* 环境基础服务的依赖;
* 环境资源服务:是否有公用资源服务,还是需要单独拉起资源使用,资源如何分配给每个应用;
* 环境需要部署的应用,版本,系统资源分配;
* 环境依赖信息:额外的域名解析配置,对其他环境服务的依赖,Mock服务依赖。

对于一个最简单的环境部署配置而言,只需要声明需要包含的应用和版本,系统应该自动根据应用部署描述生成环境配置:

* 环境基础服务依赖:预先配置好可用的基础服务集合,部署只需要声明需要哪一组服务;
* 系统资源分配:按应用类型默认值或者使用应用最低要求;
* 资源服务的拉起:按应用描述要求收集汇总,拉起共享服务供应用使用;
* 环境依赖:需单独声明,和环境相关。

4.jpg

整体而言,我们需要实现:

* 通过流水线生成收集版本化的应用描述模板,生成应用目录;
* 基于应用目录,结合软件项目,定义每个项目的环境部署需求,生成环境部署描述;
* 基于应用描述和环境描述自动构建独立部署环境和应用配置:

* 自动关联环境依赖的各项基础服务;
* 自动创建所需数据服务资源,并且与特定应用自动绑定;
* 自动部署应用集成版本到环境,自动处理环境更新;
* 自动处理应用对环境的各项依赖。

##自动化测试的开发和运行
基于以上解决方案,对于开发人员,我们可以比较方便的通过环境描述的声明来快速的获取一个用于开发的部署环境。

在最简单的情况下,通过声明需要的应用版本即可快速创建一个环境供使用。需要依赖的服务,可以通过对Vmock的配置获取Mock服务或者直接在当前环境中拉起实例使用。由于预先提供的应用描述已经包含数据库、缓存等信息,对应的服务也会自动在这个隔离的环境中创建出来,并且初始化完成。

对于本地测试的开发,可以直接连接这个环境运行各项测试用例而不会干扰其他人的工作或者被其他正在执行的测试干扰。

对于持续集成,也可以在代码提交编译通过后自动创建单独隔离环境运行。从而快速的获取反馈,了解修改带来的影响以及是否成功完成。

同时,如果应用已经集成了Flyway的数据迁移工具,流水线可以自动打包相关迁移脚本,从而在环境创建/应用更新过程中执行迁移,保证数据库的自动同步,让数据库版本和应用版本一起管理,减少数据不一致带来额外排查负担。

更进一步,对于开发过程中的联调,我们也不再需要依赖某一个特定环境。对方应用提供一个简单的应用配置放入环境描述以后,我们就可以在隔离环境快速的获取一个用于联调的应用实例,更好的对接口功能进行验证。
#架构与实现
5.jpg

如前所述,我们在Pandora环境管理应用中实现了一键拉起的功能并且结合应用目录服务提供给脚本,项目管理工具和自动化测试使用。应用部署功能主要通过Noah提供的API实现容器镜像部署,同时也通过监控Kubernetes事件来实现应用和服务启动过程的跟踪,驱动整个环境拉起工作流。
##核心功能设计与实现
一键拉起的整体基于Pandora已经实现的环境管理功能,核心部分在于通过应用模型和环境模型的解析,根据声明和依赖动态生成环境、应用拉起工作流,进而通过对工作流任务的并发和顺序执行,完成资源准备,服务开通和应用部署等各项任务。

相对于目前公用云和各项开源软件提供的服务,一大优势在于用户无需显式的关注一个应用或者一组应用的初始化过程,仅仅需要按照标准模型来描述应用和部署环境要求,系统会自动确定各项任务的执行顺序和并发执行能力,以最快的路径来执行应用部署流程。

对于应用的版本更新,原理是一样的。用户只需要提供一个环境中应用的最终版本要求,系统会自动对比差异,确定需要重新部署或者重新启动的应用,自动完成环境更新。
6.jpg

##事件监控与分布式处理转发
工作流的执行是一个异步过程,因此我们需要一个事件管理机制来实现事件的统一处理和转发。这里的事件包含多个事件来源:

* Kubernetes Events:数据基础服务容器和应用容器的启动监控
* 服务调用完成事件:各基础服务初始化,数据初始化等事件
* 流程管理事件:比如取消流程执行等处理

我们使用Apache Kakfa作为统一的事件总线,多个Pandora流程调度器实例会订阅该事件Topic,各自实现对当前实例内管理的流程的处理。从而可以实现动态的扩容,无需担心大规模使用后流程的分布式管理问题。
7.jpg

##数据库的初始化与版本管理
数据的管理通常是比较复杂的。不同应用会采取不同的方式来管理Schema和初始数据。我们也提供了多种方式来兼容不同的数据管理机制,包括:

* SQL脚本;
* 从集中的数据Schema治理系统获取数据Schema;
* 基于Flyway的数据自动初始化和数据迁移管理工具。

从初始数据的注入来看,由于有些应用没有很好的维护数据脚本,通常需要从一个基础的测试数据库导出初始化的SQL脚本。这种情况下数据集通常会比较大。我们在初始化执行过程中进行了优化,采用批量提交执行的策略,能够快速的批量导入数据,降低数据准备时间。
#总结与使用实践
在完成核心功能开发以后,我们和一个业务小组联合对实际经常需要同时部署的一组应用做了试用和验证,总体而言比较好的满足了复杂应用部署的要求。

这一组应用的基本情况如下:

* 多个应用域(7~20个),需要在同一个环境部署实现端到端的验证;
* 资源服务配置复杂,目前维护了众多的虚拟机:

* MySQL,多达128个分库。初始数据多达18000行SQL;
* Redis:单实例/Sharding/Cluster配置并存;
* 数据库中间件:不同应用多项服务注册使用,并且有不同应用共用同一服务的情况.

* 消息队列服务众多,往常需要逐条Channel/Queue进行配置;
* 环境变量配置工作繁重:包括多个MySQL分库,Redis实例的配置信息;
* 经常需要切换各个应用配置适应不同测试场景。

我们从现有部署环境导出了应用描述以后,经过简单定义修改数据服务相关描述,快速实现了在6~7分钟内完成所有数据库实例的初始化和应用的配置和启动,并且该过程是可以重复执行的,也就是说可以非常方便的随时根据测试场景要求快速准备出测试环境,无需手工维护各项配置和应用。对于应用版本更新,由于各基础服务已经存在,我们只需要创建新增的基础服务以及重新部署应用,可以在1~2分钟内完成。

原文链接:https://mp.weixin.qq.com/s/uug7xeawWLQKXGxeXm5wkw

IaaS vs CaaS vs PaaS vs FaaS:选择正确的平台

justinfu 发表了文章 • 0 个评论 • 3484 次浏览 • 2017-08-21 22:44 • 来自相关话题

【译者的话】本文分析了从IaaS到PaaS,到SaaS再到FaaS各类平台的优劣,为寻求合适的平台的迷茫者提供了很好的参考,对于软件提供商也有很好的借鉴意义。 探索各类云平台,帮您找到最适合您的那一款! ...查看全部
【译者的话】本文分析了从IaaS到PaaS,到SaaS再到FaaS各类平台的优劣,为寻求合适的平台的迷茫者提供了很好的参考,对于软件提供商也有很好的借鉴意义。

探索各类云平台,帮您找到最适合您的那一款!
1024px-Circumhorizontal_Arc.jpg

无论您是购买、从零开始搭建还是采用开源技术,您可能已经在使用某种软件平台来构建,部署和扩展应用程序。

一个平台的诞生必定是经年锤炼而来,即从应用程序中提取通用的功能到更底层的抽象中。如果完成了既定的设计意图,那么您将得到一个可用的平台,反之,您将得到一个“烫手山芋”,既而您将再次寻找合适的平台,这时候您会发现别人已经构建好的平台给您带来了一线希望的曙光。

正确的平台,您将在灵活性和简单性之间达到您所需要的平衡,从而使您能够更快速地构建而不受太多限制。本文将探讨云平台的范围,以帮助您找到最适合您的那一款。

对于什么样的平台才是完美的,每个人有每个人的看法,因为每个人的使用场景有所不同。但是几乎所有人都寻求以下两个特征:

+ 提高开发速度
+ 运维操作的最佳实践自动化

这两个要求推动了大多数软件平台的投资。真的,这两项可以作为自动化任何事情的检验标准。

所以,没有一个平台对于任何用户来说是完美的,那么是否意味着我们要自己写呢?如果自己写,是否建立在一个现有的平台之上?您想要一个从上到下的紧密集成的平台,还是想要使用强大的扩展点松散连接的多层平台?

这些都是一时间难以回答的问题,并没有一个真正适合每个人的单一答案。寻找合适平台的成就感是发现,比较和权衡之一。所以我们一起来吧!
# 平台之美
云平台的“彩虹”,总有您喜欢的色彩。

每个厂商都会告诉你,他们的软件是特别的,甚至是独一无二的。他们都在努力区分产品,以提供不可替代的价值。但是,如果您仔细观察,并容忍一些粗糙的边缘,您可以根据它们提供的接口类型对这些产品进行分组。
platform-spectrum-small.png

云平台例子
## 软件平台
术语“软件即服务”一词最早可追溯到2000年左右,指的是将打包的软件产品和支持服务捆绑在托管解决方案中,以避免经常未知的执行和操作成本。一个SaaS产品本身就是一个基础上的平台。术语描述的一些原始用途取代了传统企业资源计划(ERP)和客户关系管理(CRM)平台。

像Salesforce和SAP这样的公司,对于那些没有大型工程师团队或IT部门来构建和管理这些复杂的系统客户,他们会在这些领域非常成功。即使是拥有这些资源的公司也可能认为这些事情不在其核心竞争力范围之内,不值得自己去建设或经营。如今几乎所有类别的软件都可以通过SaaS获得,从电子邮件到文字处理系统,再到内容管理系统比比皆是。

Spectrum的另一端是基础设施即服务。
IaaS.png

将应用程序配置到基础架构平台上
## 基础设施平台
基础设施平台在SaaS之后不久就出现了。VMware GSX Server(2006)和亚马逊弹性计算云(EC2,2006)提供了早期的虚拟化平台。然而,VMWare最初专注在企业内部部署,亚马逊web服务则将其托管的IaaS和SaaS产品结合,定位于更广阔的市场。后来,Rackspace和美国航天局开发了OpenStack(2010)作为VMware vSphere(2009年发布,取代GSX)和亚马逊EC2的开源竞争对手。

这些IaaS主要提供了一些具体的抽象:虚拟机计算节点,软件定义的网络和可挂载的存储。在有SaaS的情况下,托管的IaaS的主要卖点是外部资源容量配置操作的自动化,但与SaaS不同,托管的IaaS会给用户带来资源规模无限大的错觉。对于大多数对基础设施外包感兴趣的公司来说,AWS会提供比客户以往任何时候资源需求量大得多的资源,在您向AWS寻求更多节点之前,已经扩展了数据中心。对于无法或者不愿意外包的公司,像OpenStack和vSphere这样的基础设施平台可以在您选择的数据中心中托管自己的云。

然而,管理不仅仅只是涉及硬件,还包括管理一个基础设施平台,并且这需要更多的工作,这是企业公司已经在自己的平台上做过的。无论是手动管理没有虚拟化层的硬件,还是渴望使配置更加自助化。因此,X即服务模式是圆满的:托管的平台成为了打包的产品,此次增加的多租户功能,允许客户自己的内部用户群体进行操作。

随之而来的应用平台。
PaaS-IaaS.png

基础设施平台上的应用平台
## 应用平台
Fotango的Zimki(2006)和Heroku(2007)率先使用平台即服务。后来的Google App Engine(2008),CloudFoundry(2011)和其他几个加入了战斗。在当时,很明显,这些是真正的应用平台(aPaaS),专门用于加快开发人员的速度并降低运营开销。使得开发人员自己配置和管理他们开发的应用,进一步压缩了从开始到发布到反馈到迭代的周转时间,与日益普及的敏捷软件开发思想相契合,并为刚刚起步的DevOps运动播下种子。

但进步永远不会停止。容器平台出现了。
CaaS-IaaS.png

基础架构平台上的容器平台
## 容器平台
容器化已经比您想象得要深入(FreeBSD Jails自2000年以来一直在使用),但是可以肯定的是直到Docker(2013)将Linux操作系统级虚拟化与文件系统镜像结合起来,容器化才真正广泛流行起来。这使得构建和部署容器化应用更加容易,这是一种可以理解为通过构建磁盘镜像来加快基础设施平台配置的IaaS用户模式。但与VM相比,同时运行的几台驱动器足以让您的工作站超负荷运行,容器则允许您在本地部署完整的微服务堆栈,大大加快了开发周期。另外,由于降低了开销,每个微服务器都可以拥有自己的容器映像,自己的发布周期和自己的滚动升级,允许更小的团队并行开发它们。

从容器运行时到容器平台,这是一个明显的进步。像CloudFoundry这样的应用平台和像Apache Mesos这样的集群资源管理系统自成立以来就一直使用容器隔离。下一步是公开一个平台API,允许开发人员在一组机器上部署越来越受欢迎的Docker镜像。像基础设施平台一样,容器平台也是在内部开始的,后来提供托管服务。Mesosphere的Marathon(2013)是通用容器编排的首个开源平台之一,但它早期是由内部努力推动的,比如Google的Borg(〜2004)和Twitter的Aurora(2010年写成,在2013年开放为Apache Aurora)。

容器编排是容器平台的核心。与应用平台一样,容器平台需要提供基于约束的声明性调度。与应用平台不同的是,容器不限于十二要素应用程序。比如,有状态服务需要的持久卷,隔离保证机制,特定域的迁移过程及并行的备份作业等等。由于这种灵活性,容器平台可以轻松地变得比应用程序平台更复杂,以支持更多种类的工作负载。
CaaS-Metal.png

基于计算机集群的容器平台

为了增加灵活性,并且在不迁移的情况下支持传统工作负载,许多人在基础设施平台之上运行容器平台,但这并不是绝对必要的。容器与单个机器已经十分接近,几乎所有的工作负载都是兼容的。所以并不是每个人都需要这种灵活性。许多开发人员将他们所有的时间都花在单层的堆栈中。他们寻找避免重复执行任务的办法,例如为他们构建的每个新应用程序手工制作容器镜像。对于这些人来说,功能平台(也称为无服务器)就出现了。
FaaS-CaaS-IaaS.png

基础架构平台上的容器平台,容器平台上的功能平台
## 功能平台
亚马逊推出了AWS Lambda(2014),引领了无服务的“热潮”,在其虚拟基础设施平台之上提供轻量级的容器化事件处理。像其他Amazon Web Services一样,Lambda仅仅只是一种托管服务。因此,由Iron.io(2014),Apache OpenWhisk(2016),Fission(2016),Galactic Fog的Gestalt(2016),OpenLambda(2016)填补了私有化部署替代品的市场。

除了他们各自基于特定语言的框架之外,功能平台的运行方式与应用平台相同。因此,开发人员只需要开发事件处理程序,并使用平台API将触发器映射到该处理程序即可,而不是使用多个端点编写应用程序。功能平台通常与API网关配合或集成,以处理代理,负载均衡和集中式服务发现。与应用平台不同,功能平台透明地集成了基于负载的自动缩放,因为它们控制所有入口点和复用。

像容器平台一样,功能平台不一定需要基础架构平台,但与容器平台提供的灵活性不同,功能平台不是设计用于支持各种各样的工作负载。所以仅仅只运行一个功能平台可能是不明智的或不可能的。您可能还需要一个较低级别的容器或基础架构平台。一些功能平台甚至被设计成与容器平台集成,利用中间层自动化来降低较高层的复杂性。
cloud-platform-abstration.png

云平台,其接口以及抽象的规模
# 平台抽象
这些平台中的每一层都提供了自己独特的抽象和API,某些层比其他层更抽象。一些更高层级的平台要么全部采用,要么就全不用。它们具有顶部到底部的集成,但只能支持您要运行的一小部分工作负载。您可能会尝试选择最高层的抽象化来最大限度地提高开发人员的速度,但是您也必须考虑到这些平台上构建的软件将与平台最紧密耦合,当您需要重新选择平台的时候, 这将增加您的风险。另一方面,较低级别的平台可以提供最大的灵活性,可以实现最广泛的工作负载,包括Web应用程序,微服务器,过时的整体架构应用,数据管道和数据存储服务。它们使得迁移更轻松和基础设施操作更容易,但是在上面实际开发或运维应用程序,服务或作业却更难。

应用平台和基础设施平台之间的冲突是容器平台受欢迎的重要原因之一。容器平台在这两方面作出了妥协。它们允许您根据每个容器来决定您的工作负载是否需要自己的环境,或者可以作为二进制运行,支持更多种类的工作负载。但它们还像应用程序平台一样提供声明式配置,生命周期管理,复制和调度。如果您还需要更高层次的抽象,您可以轻松地在容器平台之上部署更轻量级的应用程序或功能平台,共享具有较低级别工作负载的资源和机器。如果您还需要较低级别的抽象,您可以轻松地在基础设施平台之上部署容器平台,而不是直接使用裸机。
dcos-architecture-layers.png

DC/OS架构层
# DC/OS-平台终极选择
在Mesosphere,我们的使命就是让它非常容易建立和扩展规模到足以改变世界的技术。这意味着我们不仅仅服务于开发人员,也不仅仅是运营商,而是二者皆有。帮助您实现真正的敏捷性,既需要开发人员的速度和也需要运维人员的灵活性。开发人员希望减少重复工作,自动化的弹性,并建立在强大的平台服务之上。运维人员希望可见性,避免供应商锁定,以及控制成本的能力。因此,我们构建了DC/OS,以提供基于云的服务和开放的合作伙伴生态系统,与基础设施无关的容器平台。通过DC/OS,您可以获得一个坚实的容器平台,加上更高级别服务的目录:数据库,队列,自动化测试,持续交付流水线,日志记录和指标堆栈,弹性扩容及功能平台等。

有关容器平台的更多比较,请参阅容器平台战争

原文链接:IaaS vs CaaS vs PaaS vs FaaS:选择正确的平台 (翻译:付辉)

如何理解容器技术平台的不同姿态

尼古拉斯 发表了文章 • 0 个评论 • 2587 次浏览 • 2017-08-21 17:47 • 来自相关话题

【编者的话】最近,在微软加入CNCF基金会仅一个月之后, 亚马逊也宣布加入成为白金会员,至此,全球主要公有云服务商都加入了CNCF。可以说这是以Kubernetes为代表的容器技术平台的全面胜利。Kubernetes火爆之初,有人担心它会冲击Cloud Fou ...查看全部
【编者的话】最近,在微软加入CNCF基金会仅一个月之后, 亚马逊也宣布加入成为白金会员,至此,全球主要公有云服务商都加入了CNCF。可以说这是以Kubernetes为代表的容器技术平台的全面胜利。Kubernetes火爆之初,有人担心它会冲击Cloud Foundary为代表的PaaS平台。 事实上,作为PaaS一哥,Cloud Foundary依旧有着稳定的生态和忠实的用户。而有意思的是,一度如日中天的IaaS平台却意外受伤。同时,在AWS Lamda发布后,Serverless热度暴增,各大云平台纷纷推出Serverless服务。

【3 天烧脑式基于Docker的CI/CD实战训练营 | 北京站】本次培训围绕基于Docker的CI/CD实战展开,具体内容包括:持续集成与持续交付(CI/CD)概览;持续集成系统介绍;客户端与服务端的 CI/CD 实践;开发流程中引入 CI、CD;Gitlab 和 CI、CD 工具;Gitlab CI、Drone 的使用以及实践经验分享等。

无论Kubernetes、Cloud Foundary还是Serverless,其背后驱动都是容器技术,但技术热点快速轮动,常常也给开发者/用户带来困扰,究竟什么时候该用什么平台/技术?是否契合所面临的问题?本文希望围绕Kubernetes、Cloud Foundary和Serverless做一些粗浅分析,尝试提供一个理解不同容器化技术/平台的视角。
图1.png

图 1 2014年7月至今,Kubernetes(蓝线)和Cloud Foundary(红线)的搜索趋势变化

图2.png

图 2 2015年7月至今,Kubernetes(蓝线),Cloud Foundary(红线)和Serverless(黄线)的搜索趋势变化

#开发运行一个应用,在Kubernetes、Cloud Foundary和Serverless平台上各需做哪些事情
假如一个工程师要分别在Kubernetes、Cloud Foundary和Serverless(例如,OpenWhisk)上开发/运行同一个应用,例如实现一个排序应用, 我们分析一下,大概各自要做哪些事情。

在Kubernetes上,开发人员一般需做以下几步:

1. 编写应用代码;
2. 构建应用容器镜像,并上传到相应的容器镜像中心;
3. 创建一个Kubernetes集群;
4. 把相应的容器部署到刚创建的Kubernetes集群中;
5. 测试并确认应用成功上线。

而在Cloud Foundary或Serverless 上,所需工作可简化为三步:

1. 编写应用代码;
2. 更新配置文件并把应用发布到云上;
3. 测试并确认应用成功上线

应用上线之后,考虑到应用弹性和业务可靠性,Kubernetes和Cloud Foundary应用还需再做一步,即扩展出多个实例,而Serverless则什么也不用做。

上述步骤总结如表1:
b1.png

表 1 Kubernetes、Cloud Foundary和Serverless部署运行应用步骤

从这个简化的例子看,假如用Serverless实现,用户要做的最少,只需提供编写调试好的代码就可以了;使用Cloud Foundary,用户要关注的稍微多一点,如运行时设置弹性扩张;而用Kubernetes的话,用户要做的就相对复杂些,不仅要提供应用所依赖的runtime环境,而且还要自己制作容器镜像,并发布到相应的registry,同时还要考虑构建整个部署环境的Kubernetes集群等等。
图3.png

图 3 各*aaS中用户管理和平台功能的划分

结合IaaS和SaaS,图3把三种基于容器的计算模式,从用户和平台两个角度作一个更为通用的描述。可以看到,从IaaS,CaaS(Kubernetes),PaaS(Cloud Foundary),FaaS(Serverless),最后到SaaS,平台提供的越来越多,用户要做的越来越少。下面通过理解Kubernetes,Cloud Foundary和Serverless的主要定位,再做进一步分析。
#Kubernetes、Cloud Foundary和Serverless期望解决的问题
容器很重要的特点之一是快速构建一个跨平台运行的应用及所依赖的环境。无论Serverless、Cloud Foundary还是Kubernetes,都以其作为技术平台基础,但由于想解决问题不同,所以各自侧重也不同。

Kubernetes社区发展很快,也孵化了很多新项目,而所有这些都围绕其基本定位,即容器编排,或者说scheduling,即决定什么东西(pod)跑在哪儿(node),以达到相应的可用性(serviceability)。Kubernetes极大简化了用户对容器(应用载体)的管理,大大提升了应用维护的灵活性和可控性。此外,它对底层基础架构抽象相对较少,使得用户依然可对资源有较全面的管理;

Cloud Foundary作为PaaS,希望能为用户解决除了应用开发之外的所有事情。 它提供了几乎所有语言的buildpack,也提供了service broker的机制,方便应用集成外部服务,同时还自带容器管理组件,解决应用部署问题。对于开发者来说,开发应用之后,几乎只需执行Cloud Foundary push一条命令,其余的事情都可交由平台处理完成。这使用户更加专注应用本身,并从应用管理,中间件管理和部署环境等大量而繁琐的工作中解放出来。但由于平台对整个流程/Stack的完整封装,用户在享受巨大便利的同时,一定程度上也被限制了对底层资源的灵活调度,进而影响应用的可能形态。

Serverless按照Martin Fowler的定义,可以分为两类,一是极大依赖于第三方服务的应用(通常称作BaaS "Backend as a Service"), 二是依赖于跑在非持久容器上特定代码的应用(通常称作FaaS “Function as a Service”) 。我们通常讨论的Serverless,如AWS Lambda,Apache OpenWhisk属于后者。FaaS类型Serverless的典型场景是触发-响应,即根据定义的事件执行相应的功能(一段代码)。用户只需关心事件定义和响应动作,所有其他事情交由平台处理,包括根据请求进行自动迅速地弹性扩张,响应结果保存所需的存储等。就像Serverless的名字一样,用户不需要关心任何服务器,无论是物理服务器,中间件服务器,还是数据服务器,就像它们不存在一样,甚至都不用关心应用,用户只需做好事件触发后的响应功能。

对于Kubernetes和Cloud Foundary,Ubuntun的 CEO Mark Shuttleworth曾说过,“对于我们而言,Kubernetes是引擎,是涡轮机,是PaaS平台的核心,而Cloud Foundary则是个完整的PaaS”(图4),而关于PaaS和Serverless,现在是AWS云计算战略副总的Adrian Cockcroft也曾有个同样形象的评论,“如果一个PaaS,为一个只需执行半秒的任务,可以在20毫秒之内启动许多实例,那就可称为Serverless”(图5)。
图4.png

图 4 Mark Shuttleworth关于Kubernetes和Cloud Foundary的评论

图5.png

图 5 Adrian Cockcroft关于PaaS和Serverless的评论

这两段评论可以帮助我们对Kubernetes、Cloud Foundary和Serverless之间的定位有更清晰的理解。Kubernetes只是对容器进行管理的一种技术,而非平台,Cloud Foundary则是完整PaaS平台,容器管理(Diego)是其重要组件,是平台整个技术stack里的一环,而Serverless则是某类特殊PaaS,它充分利用了容器瞬间启动和能快速弹性扩展的特性。

Mark的类比非常形象,我们不妨顺着他的思路联想一下。假如Kubernetes是个引擎,这意味着它是动力,可以构建拖拉机,也可以构建汽车,或者变成轮船的驱动;那么Cloud Foundary就是整车了,用户只能根据用户手册在适合的道路条件下使用它,换个胎是可以的,但想随时改底盘悬挂,换发动机是困难的。那Serverless呢?也许可以看作是固定线路班次的公共交通,比如飞机,高铁,按时间触发,从某地到另一地,如遇突发流量,管理部门就会增加班次或加挂车厢。
#灵活度vs易用性——一切为了创新
既然三者之间有如此清晰的定位, 为什么貌似Kubernetes一枝独秀?为什么Cloud Foundary过时了或Serverless只能用于简单功能之类的声音会不时响起呢? 根据上面讨论,可以看到,从Kubernetes,到Cloud Foundary,再到Serverless,其实是对底层stack不同程度的抽象,随着抽象程度提高,降低了对实现栈的控制,其目的就是把关注更集中于业务逻辑的实现。

抽象,用另一词来替代,就是封装。封装一般都会简化底层逻辑,屏蔽相应细节,限制对底层某些功能的访问,所以用户在获得便利性和易用性的同时,必然以失去一部分灵活性为代价,同时也影响了应用的适用范围,例如Cloud Foundry对IaaS资源的需求,由BOSH通过一个叫CPI(Cloud Platform Interface)的接口实现,这个接口把对计算,存储和网络的操作简化成十几种,一般情况下够用了,但操作粒度和灵活度的确值得商榷。
图6.png

图 6 各*aaS上开发应用灵活度 vs 易用性的对比

我们在图3上加些标注,改成如图6所示。从IaaS,CaaS(Kubernetes),PaaS(Cloud Foundary),FaaS(Serverless)到SaaS,随着抽象程度提高,用户关注度越来越集中于业务逻辑本身,而代价就是对技术实现栈的控制越来越小,对应用调整的灵活度也越来愈弱。鱼和熊掌不可兼得,如何在灵活度和易用性之间进行折中,往往需要基于实际业务场景考量。

假如我们希望构建一个能服务于不同规模,不同类型的云计算服务平台, 把Kubernetes作为核心引擎显然是一个非常有吸引力的想法。通过把核心引擎的能力暴露出来,并围绕核心引擎,丰富完善基础服务,以微服务松耦合的方式组合,就能适应各种业务场景,构建复杂应用。

对于一个企业,如果其专注点不是提供云服务,而是迅速构建创新业务应用,那一个Cloud Foundary的PaaS平台能帮到很多。企业开发人员根据业务需求,利用Cloud Foundary平台开发应用,绑定所需服务,并通过集成的CI/CD流程,让应用从开发,测试,staging到生产,一气呵成,业务迅速发布。在一个业务需求变化迅速,应用生命周期越来越短的时代,把程序员从与业务实现不相关的工作中解脱出来意义巨大。

Serverless则完全从业务场景出发。设想一个大型企业集团的财务人员,每个月末或季末都要统计大量的财务数据,一般情况下,可以用财务软件,但当财务指标,报表格式发生变化,计算公式发生调整时,提交软件变更可能是个复杂的过程,这时采用公有的Serverless服务无疑是高效的做法。另外,Serverless以功能为对象,可以在某种程度上降低对代码能力的要求,业务人员也有可能直接参与功能实现,让功能不仅as a service,而且还是自助服务。相信这也是Serverless演进目标,即无代码功能实现,变成App-less。关于这点,我们似乎可从微信小程序看到些什么。
#演进,容器技术平台还会发生什么?
以上分析讨论是基于Kubernetes、Cloud Foundary和Serverless的现状,如从演进角度看,它们之间的关系和定位也许很快会改变。

回想容器兴起之初,很多人觉得它的能力和性能还不足与虚机相比,但随着容器技术的迅速发展,尤其是容积编排技术的巨大威力,怀疑的声音已经很少了,甚至有硬件提供商宣称,今后出货的服务器不再预装虚拟化层,而改装容器管理平台。从这个意义上讲,CaaS/ Kubernetes更像是IaaS的升级,这也是为什么Kubernetes火了以后,IaaS受到一定冲击的原因。

同样,由于历史原因,Cloud Foundary虽也有优美的容器管理组件Diego,但它的能力却不能为应用开发人员充分利用。假如Cloud Foundary能开放Diego,或者能对其他容器管理技术开放,那Cloud Foundary push显然能做更多事情,服务于更复杂的应用场景,这无疑对技术人员和企业都是福音。

现在,技术越来越开源化、社区化,Kubernetes、Cloud Foundary和OpenWhisk都有各自非常活跃的社区。社区最大的优势是利于技术的迅速传播,而我们在各个社区里也看到很多相互借鉴或融合项目,无疑,这是推进技术快速演进的方法。
#后记
这篇读书体会是一年多前写的《弯道超车:容器技术究竟为云计算带来了什么?》的下篇, 也是最近读了相关资料(链接如下)后的一点感想。出发点是试图理清一个困惑,即,如何能在迅速理解技术热点的同时,也能了解其相互关系和演进的内在逻辑。我想,这也是文中大牛,如Adrian Cockcroft、Mark Shuttleworth和Martin Fowler为什么总能有一言蔽之的金句的原因 。
##参考

1. Container vs Serverless -- https://www.slideshare.net/DanielKrook/containers-vs-serverless-navigating-application-deployment-options
2. Serverless Architecture: A Gentle Overview -- https://www.slideshare.net/CodeOps/serverless-architecture-a-gentle-overview
3. Mark Shuttleworth访谈1 -- http://www.datamation.com/open-source/ubuntus-shuttleworth-explains-why-not-all-containers-are-the-same.html
4. Mark Shuttleworth访谈2 -- http://www.datamation.com/cloud-computing/kubernetes-vs-cloudfoundry-video.html


===========================
作者介绍
鄢达来,IBM云计算方案开发经理。

PaaS平台OpenShift企业部署的“脑图”

范彬 发表了文章 • 0 个评论 • 3324 次浏览 • 2017-08-17 14:33 • 来自相关话题

【编者的话】这篇文章是来自红帽,是关于OpenShift企业部署的“蓝图”,通过“脑图”帮助客户实现企业级部署OpenShift。 【烧脑式Kubernetes实战训练营】本次培训理论结合实践,主要包括:Kubernetes架构和资源 ...查看全部
【编者的话】这篇文章是来自红帽,是关于OpenShift企业部署的“蓝图”,通过“脑图”帮助客户实现企业级部署OpenShift。

【烧脑式Kubernetes实战训练营】本次培训理论结合实践,主要包括:Kubernetes架构和资源调度原理、Kubernetes DNS与服务发现、基于Kubernetes和Jenkins的持续部署方案 、Kubernetes网络部署实践、监控、日志、Kubernetes与云原生应用、在CentOS中部署Kubernetes集群、Kubernetes中的容器设计模式、开发Kubernetes原生应用步骤介绍等。

如下是构建高分布式平台的大部分依赖:

  • 战略目标 (Strategy)
  • 存储计划(Storage)
  • 业务操作(Operation)
  • 业务连续性弹性与灾难恢复 (BCR&DR)
  • 应用开发 (AppDev)
  • 安全(Security)
  • 自动化(Automation)
  • 网络(Networking)
  • 提供(Provisioning)
  • 外部依赖 (External dependencies)
其中每类都包含多个子区域。下面我们将逐一说明。即使你熟悉这个话题,你也会发现脑图的价值。如果你想要更多,点击放大图片或查看https://github.com/mangirdaz/ocp-mindmap
appcoup-pod-150-150-768x1159.png
# 策略目标(Strategy)开始采用新平台之前,你的策略应该是你想到的第一件事情。你需要知道谁将使用你建立的这个平台。利益相关者是谁,最后谁负责?确定利益相关者通常是构建策略的最简单的部分。建立实践社区(CoP)将有助于制定战略和方向。一个精心设计和维护的CoP可以帮助您利用自己组织力量推动实现“正确解决方案”的进程。封闭式解决方案往往会错过组织需求。考虑对CoP进行一些研究。其次,你需要“微服务标准化”策略。在将服务放在新平台之前,强烈建议您定义一些标准。这里的挑战是旧的标准不适用于这个新的世界。尝试“复制 粘贴”,某些功能可能无法正常工作。# 存储计划(Storage)计划构建一个成功的平台,存储或持久性是关键考虑。你不仅需要简单的存储,而且需要可以高扩展的存储空间。你将需要为平台内部组件提供存储,如:日志、度量和容器镜像仓库。当然,你可以根据将要构建的解决方案选择不同的实现方式,如:对象存储、基于消息传递的日志服务,有时可能不需要考虑存储,但你无法完全消除对存储的需求。一旦我们开始说“持久性”,就意味着存储。开始思考如何做,谁将为你提供,以及你将拥有的存储空间(SSD,Magnetic,SAN,NAS等)。# 业务操作(Operation)操作部分与本文的下一节紧密相连。业务主要由以下两个领域组成:通常和无计划的行为(BCR&DR)。我们将在下一节中介绍无计划的行为。通常业务操作包括出口(egress)路由器配置、平台维护、补丁、调度规则创建、平台管理以及对平台上发生的事件的主动反应等内容。所有这一切,你将需要一个非常好的日志和监视。没有日志和监控,你将会“失明”,在高分布式系统中变得盲目。在分布式系统中,事情可能会从坏到更坏变得非常快,与“独立服务器”的基础架构相比,系统变得更糟糕。例如,如果出现故障,你的容器将重新调度(假设你没有自动伸缩功能,即使可以自动伸缩,你也可能花费巨大的费用)。在当前配置中重新调度=高密度,将意味着会遇到滚动失败情况。因此,你需要为运营定义标准运行手册,创建仪表盘,确保你了解你的环境,这是运营中最重要的事情之一。# 业务连续性弹性与灾难恢复(BCR&DR)我将业务连续性和弹性(BCR)和灾难恢复(DR)从业务中分开,它是非常重要的。即使在提供生产流量之前,我建议你知道你的“失败域”,及如何失败恢复。你需要制定一个计划。例如:如果你在分布式、可靠的、键值存储集群(如:在OpenShift / Kubernetes的etcd)中丢失了仲裁,或者知道外部DNS或存储提供发生故障。同时,存在多种不同的场景,如:不同的环境有所不同,某些内部/外部依赖关系具有较少或更成熟的提供,这些都取决于你所在的组织。# 应用开发(AppDev)你也需要考虑开发者。一些组织忘记了平台将主要由开发人员使用。只有开发者才知道他们想要在一个平台上运行什么。尽管事实上你将有很多工具,但你可能希望对模式和蓝图进行标准化。你应该考虑如下:
  • 应用开发人员将如何监控应用程序和节点性能?
  • 他们将如何推广和部署?
  • CI / CD管道(现有和新的)将如何与平台集成。
  • 你将如何推广来自环境的镜像?
  • 如何进行配置推广?
  • 最后,开发人员将会使用哪些开发工具?
开发人员的经验非常重要。得到这个权利,你的平台将被使用。错了,没有人会想使用它。# 自动化(Automation)这个特定的领域与其他领域有许多关系。你将需要使用CI / CD工具自动化你的应用程序、进行镜像测试和推广等。此外,你的基础设施应该被视为与你的应用程序相同 - 自动化无处不在。为此,你可以使用配置管理工具或仅依赖于部署工具。但是,如果你从一开始就以自动化的思想开始构建,那么即使在开始时它看起来很慢,它会变得想要的更快。# 网络(Networking)你需要考虑如何访问应用程序、出口(egress)和入口(ingress)流量,以及如何配置负载平衡器。决定是否将运行 “主动-被动” 或 “主动-主动”,及如何负载均衡所有的堆栈。容器是“网络中的第一个公民”或依赖SDN抽象?如何处理DNS?是否需要相互SSL?你的集群在2 - 5年内有多大?一个节点上运行多少个容器?所有这些问题都将定义你的平台的网络设计。# 安全(Security)尽管平台构建要考虑是安全的,但你仍然会有很多公开的问题。例如,你如何管理你的私密凭据(密码,证书)以及如何更新它们?你将如何将你的应用程序暴露给外界?最后,最重要的是,如何验证你正在运行的镜像?运行多租户、基于微服务的应用程序,镜像扫描和生命周期是关键问题。# 提供(Provisioning)提供非常广泛,与你的组织中的如下有很高的联系:
  • 配置管理:使用哪一个配置管理,以及它如何与平台支持的工具一起使用?一旦你确定了所使用的配置管理后,需要选择使用什么工具?你是否需要什么额外的工具?你是否需要红帽的订阅和生命周期管理吗?是否需要CloudForms控制台、能力和主动管理?需要什么可视化提供商及其功能?
  • 基础设施本身:你是否使用容器化部署或基于包/ RPM?如何满足你组织的补丁策略?例如,如果你的组织是基于RPM的,你选择了基于容器化/OSTree的平台,你的运维工程师如何知道它们的生命周期?
最后,你需要为平台做什么定制(预先及后期操作),使其符合你的需求?# 外部依赖(External dependencies)你会有很多外部依赖,请确保这些外部依赖的弹性和它们提供的SLA。外部依赖将包括如下:
  • 记录和监控:日志如何归档?集成哪些外部日志和监控解决方案?提供哪些元数据?
  • 存储:你将如何使用它?是否足够快?每秒输入/输出操作(IOPS)?如何扩缩?
  • 容器镜像仓库:如果你计划运行全局分布式集群,确定你的镜像的一致性?镜像仓库是否需要外部存储?如果是,什么格式?
  • 身份验证和授权:你将如何验证你的用户和应用程序?首选的身份验证提供商?如何进行基于角色的访问控制(RBAC)?
  • ITSM / CMDB:你需要在配置管理数据库中注册你的应用程序吗?如何自动化(或自动化解决方案?)。如何考虑变化?

# 架构
最后,一旦你知道你想去哪里(策略),你需要开始考虑更广泛的架构,例如基础设施密度、数据中心和可用性区域。已经覆盖的大部分领域与平台本身的架构有关。你需要在开始时做出正确的选择,因为分布式平台(OpenShift / Kubernetes等)构建和使用数百甚至数千个应用程序,难以修改。如果你网络错误,以后再进行更改是不可能的。如果平台不适应外部依赖关系与平台扩展的能力,将遇到瓶颈。

至此,我们介绍了这个旅程,你需要考虑什么。需要明白一点:公共云不能解决所有这些问题。这些可能看起来很难、不值得。但是,最终的结果就是全云不可知、水平和垂直可扩展的自助服务基础设施 ,这些将使开发人员开心。

原文出处:Enterprise OpenShift Deployment: What do you need to know?(翻译:范彬)

===============================================================
译者介绍:范彬,从事微服务、Docker和Kubernetes容器技术等方面的工作。可以关注译者的微信公众号:范范米饭。

游戏运维的最佳实践:搜狐畅游自动化运维之旅

尼古拉斯 发表了文章 • 1 个评论 • 3022 次浏览 • 2017-07-27 10:47 • 来自相关话题

【编者的话】本文作者见证了畅游游戏自动化运维平台的从无到有,通过在其中踩过的坑、解过的结,他向大家来阐述游戏运维的进阶之路。本文主要围绕畅游游戏管理体系与运维自动化的演变历程、运维自动化的实现及未来运维四方面展开。 【3 天烧脑式 ...查看全部
【编者的话】本文作者见证了畅游游戏自动化运维平台的从无到有,通过在其中踩过的坑、解过的结,他向大家来阐述游戏运维的进阶之路。本文主要围绕畅游游戏管理体系与运维自动化的演变历程、运维自动化的实现及未来运维四方面展开。

【3 天烧脑式基于Docker的CI/CD实战训练营 | 北京站】本次培训围绕基于Docker的CI/CD实战展开,具体内容包括:持续集成与持续交付(CI/CD)概览;持续集成系统介绍;客户端与服务端的 CI/CD 实践;开发流程中引入 CI、CD;Gitlab 和 CI、CD 工具;Gitlab CI、Drone 的使用以及实践经验分享等。
#畅游运维管理体系与运维自动化的演变历程

##畅游运维管理体系演变历程

从 2008 年毕业以实习生的身份进入搜狐畅游,我同公司一起成长,经历了整个运维管理体系从小到大的过程。

整个运维管理体系是从最初石器时代(脚本化),之后的青铜时代(半自动化)、蒸汽时代(DevOPS)一路演变过来,现在处于自动化和智能化过渡阶段。
##畅游运维自动化演变历程

如下图,是畅游运维自动化的步骤,分别是数据总线统一、业务自动化、标准化统一、服务驱动和智能运维。
01.jpg

对于已发生故障进行分析发现,40% 的故障由数据不准确导致。出现这样情况,是因为自产信息或很多系统之间交互信息带来的问题。

所以首要做的是数据的系统、准确性、调用及引用接口的统一。之后对数据和文件分发研发了一系列平台,还有各个平台标准化的统一。

如下图,是畅游运维体系架构:
02.jpg

最底层采用的是混合云的模式,在这基础上,又建设了多个如海豹、集中配置管理、管理和服务相关的支撑系统,还有最重要的天使和监控告警系统。

天使系统的主要职责就是权限管理,畅游各运维人员所负责的游戏各有不同,由于游戏版本的特殊性,一旦泄露,会对整个游戏的营收造成很大影响。

所以,要严格管理每个工程师的权限。监控警报系统之所以重要,是因为涉及到所有游戏玩家的体验和收入。
#畅游游戏运维自动化实现

##游戏运维的特点和痛点

面对这样的运维体系架构,畅游都在哪些部分做了自动化呢?我们先来看看游戏运维有哪些特点和痛点。

每个游戏的构架和应用场景,乃至于所使用的数据库和开发语言完全不同。还有不同国籍开发的游戏,整个操作系统和数据库环境、版本都存在大量的不同点。这样一来,运维整个平台和环境都要面临很大挑战。

游戏运维的痛点有很多,如:

* 运维脚本及工具零散、数量多、难复用。
* 资源需求弹性大。
* 成本、效率与可用性的平衡。
* 大流量的高并发。
* 故障需要实时处理且尽快恢复。
* 多版本管理。

为克服这些痛点,近四五年,畅游运维做了很多事情,业务和工程师人数等方面都有变化。

从 2014 年到 2016 年,业务每年实现 20% 的增长,全职工程师在不断的减少,这是因为 2014 年到现在,我们做了大量的自动化工具,利用自动化平台和资源整合,每年资源成本减少 30%。

2016 年 CMDB 海豹系统上线,对所有在线资源进行整合,公共集群建设的完成,把单游戏和每一组游戏所需公共服务放在一起,使得资源成本减少 50%。

这里值得一提的有趣现象是 2014 年到 2015 年的人为故障数量基本持平,这是自动化带来的副作用,2016 年人为故障下降了 30%,此时自动化的作用开始发挥出来了。

2014 年到 2015 年的全局故障率(网络故障、硬件故障等所有的故障)减少了 20%,2016 年故障率下降了 35%。

我们为什么可以在业务增长的情况下,依然可以做到故障下降和成本节约?

分析原因如下:

* 40% 的人为故障是由于信息不准确或是人为操作失误导致的。
* 30% 的人为故障是由于跳流程操作和研发的沟通壁垒。
* 50% 以上的成本来自于空闲资源和故障资源,以及服务器性能资源未能充分使用。

针对这些原因,畅游运维做了很多事情,下面主要分享如何通过海豹系统做信息的统一化和标准化、PaaS 平台实现 Devops 自动化交付以及 Docker 容器技术和混合云架构等内容。
##游戏运维自动化平台的技术及逻辑架构

对于游戏运维自动化平台应用来说,是既定的计划,可以当做任务来执行,所有开服、关服、更新、数据回档及档案恢复等所有操作都可以定义成任务或工作流,之后把所有的设计全部按照任务系统的架构来设计即可。
03.jpg

在平台设计过程中,系统主要使用 Python 来进行开发。因为从 2015 年开始,我们发现,如果全部用 Java 来开发的话,运维人员的参与度会非常低。

假设运维人员对 Java 不了解,运维和开发之间需求沟通就不顺畅。这里的解决方案就是一线运维人员必须要懂 Python,而且要参与到开发过程中。

如下图,是自动化运维任务的系统架构:
04.jpg

自动化运维任务系统是结合开源技术与公司现有资源的运维的基础操作平台。不仅支持脚本执行、定时任务等基础运维场景外,还提供了流程式开发框架,使运维人员能开发自己需要的业务维护功能。
##海豹系统(CMDB)

海豹系统承载畅游硬件层、应用层和网络层等运维层所有信息的记录,如设备、配置、关联权限、关联拓扑、关联环境、关联流程等。基于这些信息,以应用为核心,通过业务场景进行驱动。

如下图,是海豹系统(CMDB)的功能架构:
05.jpg

整个功能架构从下至上分为数据来源、数据层和应用层部分。用以管理系统中心的服务器及相关的软硬件资产信息,是所有系统资产信息的来源。数据层对所有资产进行查询、变更及管理,通过统计报表模块图展示资产的情况。

如下图,是海豹系统(CMDB)的功能架构和技术架构:
06.jpg

这是海报系统的最初时期,由不足五人用 Java 写的核心架构。引擎部分,之所以还在用 JSP 和 Freemarker 引擎,是为了兼顾老的系统。

如下图,是海豹系统(CMDB)的界面:
07.jpg

所有的端游、手游的信息会集中到海报系统,意味着资产管理专员可以通过这个平台做所有资源初始化和分配调度。
##PaaS平台

通过业务逻辑把各个资源统筹起来,资源所见即所得,更容易的实现了持续集成,通过各项基础服务的组合,实现代码自动化发布、应用管理、环境初始化部署、线上运维一体化集成,提升项目代码编译、测试、发布效率。
08.jpg

PaaS 平台主要职责如下:

* 提供一致性环境保障。
* 提供应用多租户隔离以及资源的多租户隔离。
* 提供服务发现、可弹性伸缩、状态管理、资源分配、动态调度等能力。
* 支持预发布、一键发布、一键回滚以及自动化部署。
* 提供透明化的监控、容灾能力。
* 提供运维、开发、测试多角度业务场景。

如下图,是 PaaS 平台的主要技术选型:
09.jpg

从上图可以看出,PaaS 平台里也包含外部组件,Docker 也包含其中。因为游戏公司大量代码基本都放到 SVN,所以我们也会选在 SVN 来管理。
##Docker 容器技术

PaaS 平台的设计中,核心部分是 Docker。那搜狐畅游的 Docker 是如何设计的呢?

如下,是原 Docker 架构图:
10.jpg

如下,是最终版的 Docker 架构图:
11.jpg

从 2014 年至今,我们已经迭代过两个版本,搜狐畅游在容器监控数据共享、稳定性和镜像管理等方面进行了优化。

如下图,是技术演化对比:
12.jpg

因 Ceph 副本之间不稳定,不支持集群共享,所以改成 NFS + DRBD。因 Consul 集群 Leader 切换频繁,业务数据不同步,负载过高,改成 Etcd,来保证数据同步统一。

为应对 cAdvisor 无法汇总,无法查看历史数据的问题,我们自研了 Hunter。操作系统从 2.6 升级到 3.18,应对运行久了后 DeviceMapper 的信息无法写入导致系统异常的问题。
##混合云结构

畅游运维体系最底层采用的是混合云结构,开始考虑的方式是直接接入所有公有云,用专业的方式打通,但游戏需要 BGP(网关协议)。

这意味着必须多线接入,除电信、联通外,所有的小区宽带,第三方宽带也必须要接入,所以需要选择混合云的结构。
13.jpg

选择混合云相比畅游 IDC 降低成本在 20% 左右,并且使资源弹性,云上云下,扩缩容更快速。在可靠性方面,不仅可实现异地双活,还有抗攻击、DNS 劫持、冗余可靠等优势。
#畅游运维管理体系的下一步探索

畅游运维管理体系的下一步将把持续交付的分层能力和公共服务标准化作为探索方向。
##持续交付的分层能力

14.jpg

在畅游运维做自动化时,会利用可持续交付的理念和原则去做。工具开发过程中,一定要注意的问题是:工具越多,工具与工具之间的调用就会出现大量的问题。

所以一定要进行平台化和做成集群式服务,否则成本不会降低,反而故障依旧会很多。
##公共服务标准化

如下图,是公共服务平台整合架构:
15.jpg

畅游把 Redis、Nginx、MySQL 等集群全部接入,不需要做其他的事情。
#写在最后

畅游运维做整个自动化过程中的心得有三个:

* 简单有效,不要做特别花哨,因为对应用最实际才是有用的,对应用或开发人员来说,最有效及效率最高是最好的。
* 符合实际业务,不是脱离研发和应用。
* 高效,游戏特性决定必须高效,快上快下,快速决策。

原文链接:游戏运维的最佳实践:搜狐畅游自动化运维之旅(作者:黎志刚)

同程容器云平台网络方案演进

李颖杰 发表了文章 • 0 个评论 • 2660 次浏览 • 2017-07-26 22:53 • 来自相关话题

【编者的话】同程旅游PaaS平台是从2014年开始搭建的,到现在已经持续发展了三个年头。规模从原来的几百个容器到现在上万个容器。在容器调度上从原来的手动操作到现在的自动伸缩与扩容,在宿主机部署密度上从原来的十几个容器到现在上百个容器……我们的PaaS云平台在三 ...查看全部
【编者的话】同程旅游PaaS平台是从2014年开始搭建的,到现在已经持续发展了三个年头。规模从原来的几百个容器到现在上万个容器。在容器调度上从原来的手动操作到现在的自动伸缩与扩容,在宿主机部署密度上从原来的十几个容器到现在上百个容器……我们的PaaS云平台在三年间进行了3次大版本的迭代。本文主要介绍同程旅游PaaS云平台在持续集成和持续部署方面,基于Docker对网络方案的选型及应用,以及随着业务需求的增加而经历的网络方案变更过程。

【3 天烧脑式基于Docker的CI/CD实战训练营 | 北京站】本次培训围绕基于Docker的CI/CD实战展开,具体内容包括:持续集成与持续交付(CI/CD)概览;持续集成系统介绍;客户端与服务端的 CI/CD 实践;开发流程中引入 CI、CD;Gitlab 和 CI、CD 工具;Gitlab CI、Drone 的使用以及实践经验分享等。
#系统的初始形态
PaaS平台最初是基于Swarm搭建的,Swarm是Docker公司推出的一套容器调度平台。它的特点是简单易用,部署方便,学习成本低,因为它所有的命令和Docker命令基本上是一致的。容器有4种网络模式Bridge、Host、Container以及None ,开始我们使用的网络方案是Host模式,这种模式下,容器没有独立的IP网络栈,它共用了宿主机的IP地址。为了防止端口冲突,应用对外暴露服务的时候,需要指定端口,并且这个端口在同一宿主机上唯一(不然会冲突),然后再对接负载均衡器,这样就打通了整个网络链路。整个架构非常简洁,对于当时每天几十个容器以及无状态的应用,是能够完全满足需要的。

网络访问流程如下所示:
001.png

后来随着业务的发展,各种业务也慢慢的容器化,比如说Redis、Hadoop、Database、中间件等等。Host模式越来越显得力不从心,最严重的情况是很多应用没办法往上部署。举个例子来说,像Redis应用,它主要功能是做缓存,在高并发的情况下,一个Redis容器能把网络跑满,如果同一台宿主机上还有其它容器,这就会导致其它容器无法正常对外提供服务。像Database服务,为了做HA,需要容器拥有独立的网络,在迁移的时候保持IP不变。

但在Host模型下,容器网络依赖宿主机网络,容器对外访问需要通过宿主机IP加容器唯一端口,当容器发生迁移的时候,访问容器的方式(IP:Port)也要跟着改变,无法满足用户在平台外部需要直接使用IP访问的需求。为了解决此类问题,急需对容器进行网络隔离,让每个容器拥有独立IP。
#基于Public IP的网络订制
为了满足业务需求,开始研究如何使容器实例以Public IP方式供用户使用。首先什么是Public IP,Public IP就是让容器拥有一个独立的网络协议栈,有一个独立的IP地址。用户可以直接通过这个独立的IP地址访问应用,这样可以方便地解决端口冲突问题。有了这个目标以后,接下来就对目前现有的Docker网络方案进行调研评估。首先简单介绍下现有的容器网络方案,网上也看了很多对比,对于各方案的优缺点这里也做一个简单的总结。
##隧道方案
其典型的代表是:

* Weave,UDP广播,本机建立新的BR,通过PCAP互通。
* Open vSwitch(OVS),基于VxLAN和GRE协议,但是性能方面损失比较严重。
* Flannel,UDP广播,VxLan。

隧道方案在IaaS层的网络中应用也比较多,大家共识是随着节点规模的增长复杂度会提升,而且出了网络问题跟踪起来比较麻烦,大规模集群情况下这是需要考虑的一个点。另外,由于隧道方案性能损失比较严重,所以隧道方案暂时不考虑使用。
##路由方案
其比较典型的代表有:

* Calico,基于BGP协议的路由方案,支持很细致的ACL控制,对混合云亲和度比较高。
* Macvlan,从逻辑和Kernel层来看隔离性和性能最优的方案,基于二层隔离,所以需要二层路由器支持,大多数云服务商不支持,所以混合云上比较难以实现。

路由方案一般是从3层或者2层实现隔离和跨主机容器互通的,出了问题也很容易排查。

在这里我们说一下Calico。

首先它既支持Docker的CNM网络模型也支持像Kubernetes主推的CNI网络模型。既有着不俗的性能表现,提供了很好的隔离性,而且还有不错的ACL控制能力。通过将整个互联网的可扩展IP网络原则压缩到数据中心级别,Calico在每一个计算节点利用Linux Kernel实现了一个高效的vRouter来负责数据转发,而每个vRouter通过BGP协议负责把自己上运行的workload的路由信息像整个Calico网络内传播——小规模部署可以直接互联,大规模下可通过指定的BGP route reflector来完成。这样保证最终所有的workload之间的数据流量都是通过IP路由的方式完成互联的。

此外,Calico基于iptables还提供了丰富而灵活的网络Policy,保证通过各个节点上的ACLs来提供Workload的多租户隔离、安全组以及其他可达性限制等功能。

Calico 架构如下图所示:
002.jpg

对于Calico方案,我们也做了一些测试,首先它的网络转性能非常高,接近原生物理网卡的性能。但Calico依赖BGP协议,需要根据需要,频繁变更物理路由器的配置。对于传统物理网络有一定的侵入性,为了兼容以往的网络架构只能放弃。
##Vlan方案
其比较典型的代表有:

* Contiv netplugin
* Pipework

这里我们着重讲一下Contiv。

Contiv是Cisco开源出来的针对容器的基础架构,主要功能是提供基于Policy的网络和存储管理,是面向微服务的一种新基架,同时它又支持CNM以及CNI网络模型。Contiv能够和主流的容器编排系统整合,包括:Docker Swarm、Kubernetes、Mesos and Nomad。
003.png

如上图所示,Contiv比较“诱人”的一点就是,它的网络管理能力,既有L2(VLAN)、L3(BGP),又有 Overlay(VxLAN),而且还能对接Cisco自家的 SDN 产品 ACI。可以说有了它就可以无视底层的网络基础架构,向上层容器提供一致的虚拟网络了。

最主要的一点是,既满足了业务场景,又兼容了以往的网络架构。在转发性能上,它能达到物理网卡95%的性能。在高并发的场景下,OVS可能会消耗一部分CPU性能。对于这方面后期打算通过DPDK来做改善。另外,Contiv netmaster节点Down了以后不会造成网络中断,可以降低风险。还有一个优点是基于OVS可以灵活地做Policy/ACL/Qos监控等等,最终选择使用Contiv netplugin。

接下来我们说一下Contiv Netplugin在公司的落地情况。

首先根据实际网络访问描述下Contiv在PaaS平台整体部署结构:
004.jpg

目前我们通过Mesos + Marathon实现了容器的动态扩容以及动态负载,能够根据业务负载快速响应,做到自动伸缩,下面我们介绍一下网络模块Contiv。

Contiv主要包含3部分:

  1. netctl客户端主要用来发送命令到Contiv Netmaster;
  2. Netmaster服务端用来管理所有的Netplugin,以及提供IP地址分配IPMI功能;
  3. Netplugin插件跑在每个swarm node节点上,接收Netmaster指令控制OVS实现路由转发功能。

Contiv带来的方便是用户可以根据实例IP直接进行访问,可以借助ovs做很多策略,以及监控等,Contiv Netplugin特性主要有以下几点:

  1. 多租户网络混部在同一台主机上;
  2. 集成现有SDN方案;
  3. 能够和非容器环境兼容协作,不依赖物理网络具体细节;
  4. 即时生效的容器网络Policy/ACL/QoS规则。

可以说Contiv有很多丰富的特性,能够满足大部分业务场景,但有些场景目前Contiv还无法支持需要做二次开发,比如说应用容器IP固定,流量监控等。接下来讲一下我们是如何基于Contiv做IP持久化的。

大家都知道,Docker容器网络模型使用的是CNM(Container Network Model),这的底层是通过Libnetwork实现的,只要符合这个模型的网络接口就能被用于容器之间通信,而通信的过程和细节可以完全由网络接口来实现。
005.jpg


* Sandbox:对应一个容器中的网络环境,包括相应的网卡配置、路由表、DNS配置等。CNM很形象的将它表示为网络的『沙盒』,因为这样的网络环境是随着容器的创建而创建,又随着容器销毁而不复存在的。沙盒的实现可以是Linux Network Namespace、FreeBSD Jail之类的概念,并包含连接多个网络的Endpoint;
* Endpoint:实际上就是一个容器中的虚拟网卡,在容器中会显示为eth0、eth1依次类推。它可以是veth对,或者Open vSwitch的internal port。一个Endpoint只能属于一个沙盒;
* Network:指的是一个能够相互通信的容器网络,加入了同一个网络的容器直接可以直接通过对方的名字相互连接。它的实体本质上是主机上的虚拟网卡或网桥。

在CNM模型下,容器需要先通过IPMI获取IP,然后再创建Endpoint。我们的做法是,在启动容器之前,先调用Contiv rest API获取IP,Contiv Netmaster收到allocate ip的请求以后,将分配的IP保留起来,接下来在创建容器的时候指定所获取的IP,Netmaster收到创建Endpoint的请求将,保留的IP分配给容器,这样就做到了IP持久化。

创建容器的时序图如下:
006.png

#网络监控
在网络流量监控方面,我们通过使用OVS的sFlow来抓取宿主机上所有的网络流量,然后自开发了一个简单的sFlow Collecter,服务器收到sFlow的数据包进行解析,筛选出关键数据,丢到Redis(这里的Redis是做来做缓存的作用)。然后再通过ELK集群定时从Redis拉取数据,进行汇总分析。前端通过调用ELK的API,得到所需要的监控数据。

通过对网络进行改造,目前已经将Redis,大数据,DB等诸多复杂的业务成功的跑在了容器中,切切实实解决了业务的痛点。随着PaaS云平台的演进,由Swarm切换为Mesos + Marathon,后期也会根据需求对Contiv不断优化。

三年多的持续迭代,只为达到更高的要求。
>铭记初心,只为让更多人享受旅游的乐趣。
>
——王文建



原文链接:同程容器云平台网络方案演进&version=12020610&nettype=WIFI&fontScale=100&pass_ticket=FLwEXJsRPG3OGe5piakWkIHrzthK2rlKfn3ITRd1TSLnVhmID7y9j4z8eu7HFxt7)(作者:王文建)

DockOne微信分享(一三零):探究PaaS网络模型设计

wulonghui 发表了文章 • 0 个评论 • 3450 次浏览 • 2017-07-12 14:18 • 来自相关话题

【编者的话】PaaS的抽象逻辑使得其网络模型与IaaS有所不同,本次通过重点说明Kubernetes和Docker的网络,从而来探究PaaS的网络模型设计。 【3 天烧脑式容器存储网络训练营 | 深圳站】本次培训以容器存储和网络为主题 ...查看全部
【编者的话】PaaS的抽象逻辑使得其网络模型与IaaS有所不同,本次通过重点说明Kubernetes和Docker的网络,从而来探究PaaS的网络模型设计。

【3 天烧脑式容器存储网络训练营 | 深圳站】本次培训以容器存储和网络为主题,包括:Docker Plugin、Docker storage driver、Docker Volume Pulgin、Kubernetes Storage机制、容器网络实现原理和模型、Docker网络实现、网络插件、Calico、Contiv Netplugin、开源企业级镜像仓库Harbor原理及实现等。
# PaaS和IaaS的网络需求
概念上来说,IaaS是基础架构即服务,PaaS是平台即服务。从服务化角度来说两者对于网络的需求有共同点:

  1. 一台宿主机的网络隔离,一台宿主机要运行多个环境黑盒(VM或者容器),这时候每个环境黑盒的网络需要隔离。
  2. 环境变更后的访问一致性,比如VM或者容器迁移到其他宿主机的时候,如何保证外部访问不感知,比较通用的解决方案网络代理层来解决。

实现上来说,IaaS是VM管理,PaaS是容器编排,两者的网络也会有些不同:

  1. 容器比VM轻量级,启停更快,更方便迁移,所以PaaS的整个调度策略会更灵活,容器的迁移频率是高于VM,当容器迁移的时候,PaaS需要更加快速的解决变化后的网络访问。
  2. VM安全高于容器,IaaS这部分会更多在隔离和安全上有所考虑,当然这个可能是公有云和私有云的一个定位,个人认为IaaS比较适合公有云,PaaS比较适合私有云。

# PaaS的网络模型设计
以上部分我们讨论了PaaS网络需求,总结来说PaaS需要解决宿主机的网络隔离和环境变更后的访问一致性问题,然后在灵活性上需要更加注重,私有云的定位可以减少因为安全和隔离的代价,保证高性能。
##宿主机的网络隔离
网络隔离最基本问题就是要解决端口冲突,一种思路是容器通过端口映射访问,宿主机的端口由系统分配避免端口冲突,这种方式对使用的便利性是有意义的,但并不理想,因为需要对各种端口进行映射,这会限制宿主机的能力,在容器编排上也增加了复杂度。

端口是个稀缺资源,这就需要解决端口冲突和动态分配端口问题。这不但使调度复杂化,而且应用程序的配置也将变得复杂,具体表现为端口冲突、重用和耗尽。

NAT将地址空间分段的做法引入了额外的复杂度。比如容器中应用所见的IP并不是对外暴露的IP,因为网络隔离,容器中的应用实际上只能检测到容器的IP,但是需要对外宣称的则是宿主机的IP,这种信息的不对称将带来诸如破坏自注册机制等问题。

所以就要引入一层网络虚拟层来解决网络隔离,现在说的比较多的大二层网络,L2 over L3,比如OVS、Flannel、Calico等等。
##环境变更后的访问一致性
一个通用方案来说通过代理层提供不变的访问入口,像OpenStack的网络节点就是一个L3(IP)的访问入口,而PaaS更多的是提供L4(TCP、UDP)和L7(HTTP)的访问,L4比较流行的开源方案有LVS,L7的是Nginx和Haproxy。

因此PaaS的网络结构有:

  1. 物理网络
  2. 虚拟层网络
  3. 代理层网络

# Kubernetes和Docker的网络说明
Kubernete Docker作为目前最流行的开源PaaS实现,通过其实现细节可以更加理解PaaS的网络模型实践。
## 容器网络
Docker使用Linux桥接,在宿主机虚拟一个Docker容器网桥(docker0),Docker启动一个容器时会根据Docker网桥的网段分配给容器一个IP地址,称为Container-IP,同时Docker网桥是每个容器的默认网关。因为在同一宿主机内的容器都接入同一个网桥,这样容器之间就能够通过容器的Container-IP直接通信。
QQ截图20170712141024.png

Docker网桥是宿主机虚拟出来的,并不是真实存在的网络设备,外部网络是无法寻址到的,这也意味着外部网络无法通过直接Container-IP访问到容器。
## Pod内部容器通信
Kubernetes中Pod是容器的集合,Pod包含的容器都运行在同一个宿主机上,这些容器将拥有同样的网络空间,容器之间能够互相通信,它们能够在本地访问其他容器的端口。

实际上Pod都包含一个网络容器,它不做任何事情,只是用来接管Pod的网络,业务容器通过加入网络容器的网络从而实现网络共享。

Pod的启动方式类似于:
$ docker run -p 80:80 --name network-container -d 
$ docker run --net container:network-container -d

所以Pod的网络实际上就是Pod中网络容器的网络,所以往往就可以认为Pod网络就是容器网络,在理解Kubernetes网络的时候这是必须要需要清楚的,比如说Pod的Pod-IP就是网络容器的Container-IP。
QQ截图20170712141216.png

## Pod间通信
Kubernetes网络模型是一个扁平化网络平面,在这个网络平面内,Pod作为一个网络单元同Kubernetes Node的网络处于同一层级。
QQ截图20170712141318.png

在这个网络拓扑中满足以下条件:

* Pod间通信:Pod1和Pod2(同主机),Pod1和Pod3(跨主机)能够通信
* Node与Pod间通信:Node1和Pod1/ Pod2(同主机),Pod3(跨主机)能够通信

为此需要实现:

* Pod的Pod-IP是全局唯一的。其实做法也很简单,因为Pod的Pod-IP是Docker网桥分配的,所以将不同Kubernetes Node的Docker网桥配置成不同的IP网段即可。
* Node上的Pod/容器原生能通信,但是Node之间的Pod/容器如何通信的,这就需要对Docker进行增强,在容器集群中创建一个覆盖网络(Overlay Network),联通各个节点,目前可以通过第三方网络插件来创建覆盖网络,比如Flannel和Open vSwitch等等。

Flannel由CoreOS团队设计开发的一个覆盖网络工具,Flannel 通过在集群中创建一个覆盖网络,为主机设定一个子网,通过隧道协议封装容器之间的通信报文,实现容器的跨主机通信。Flannel将会运行在所有的Node之上,Flannel实现的网络结构如图所示:
QQ截图20170712141425.png

## 代理层
Kubernetes中的Service就是在Pod之间起到服务代理的作用,对外表现为一个单一访问接口,将请求转发给Pod,Service的网络转发是Kubernetes实现服务编排的关键一环。

Service都会生成一个虚拟IP,称为Service-IP, Kuberenetes Porxy组件负责实现Service-IP路由和转发,在容器覆盖网络之上又实现了虚拟转发网络。

Kubernetes Porxy实现了以下功能:

* 转发访问Service的Service-IP的请求到Endpoints(即Pod-IP)。
* 监控Service和Endpoints的变化,实时刷新转发规则。
* 负载均衡能力。

Kubernetes Porxy是一种分布式L3代理转发, 默认是基于Iptables实现,这从设计上很值得借鉴,但是性能部分有待验证。

Kubernetes中的Ingress提供了一个统一的对外代理入口配置,比如HTTP的访问配置,然后通过实现Ingress-Controller,Ingress-Controller的实现可以用Nginx、LVS等等,以Nginx来说,就Ingress-Controller监控Kubernetes API,生成Nginx配置,然后加载生效,而Nginx跟Pod的通信,可以走Service,但是考虑到Kubernetes Porxy的性能问题,建议直接和Pod通信。下面就是一个实现图:
QQ截图20170712141523.png

整体来看的一个网络模型如下:
QQ截图20170712141604.png

# Q&A
Q:有这么多虚拟网络,覆盖网络,会不会有网络延迟?

A:网络虚拟会带来性能损耗,比如Flannel需要将报文封装到UDP包中传输,这中间的封包解包就会带来损耗。所以网络虚拟化的部分,软件的实现还有待优化,其实更好的方式是硬件支持,比如现在提的很多的SDN网络。



Q:Pod为什么要有个网络容器?

A: 一方面这是解耦,通过网络容器来负责网络配置,这样对于业务容器来说稳定性会更高,比如在多个业务容器中,某一个业务容器断了,这样就不会导致网络中断。



Q:Calico默认全网是打通的,怎么做基于网段之间的隔离?

A:目前来说要做网段隔离,可能偏向安全性比较高的场景,我们目前是做私有云场景,对隔离的要求没那么高。所以如果要做隔离的话,可以参考OpenStack的OVS方案。



Q:在某些应用场景下,Pod的IP需要固定,而不是重启之后IP可能会变化,请问如何满足这种场景的需求?

A:Pod的IP需要固定的话,一种方式是修改Docker的代码,据我所知腾讯有实现过。另外的方案就是做L3的代理,给Pod一个浮动IP,有点像OpenStack的实现。



Q:Ingress的流量默认是先走Service然后到Pod,还是直接到Pod?

A:取决你的实现,官方的实现是先走Sevice再到Pod,我们是直接到Pod。



Q:Ingress-Controller实现除了使用LVS和Nginx外,能否采用商用负载设备来实现?实现是否取决于和Kubernetes API的对接?

A:可以,只要有接口都可以实现,通过实现Ingress-Controller,比如对接F5的硬件设备,只要F5支持相关的API。



Q:代理入口上有哪些方法解决单点失效的问题呢?

A:这个比较传统了,软件实现就Keepalived之类的。



Q:Igress-Cntroller比较好的库都有哪些,分别基于Nginx Haproxy LVS的?

A:GitHub有蛮多实现的,其实还是比较简单的,像go语言的话,直接套用官方提供的demo即可,其他语言可以对接Kubernetes的API实现。



Q:这么多层的网络,多层转发后网络性能怎么样?有没有办法实现高速数据转发解决方案?

A:代理层,虚拟层都会有损耗,这个就是要考虑管理成本和性能的权衡了。如何要实现高性能的话,就是要往SDN网络研究,通过硬件层的支持来实现虚。



以上内容根据2017年07月11日晚微信群分享内容整理。分享人吴龙辉,网宿科技云计算架构师,负责设计开发PaaS平台,《Kubernetes实战》作者。 DockOne每周都会组织定向的技术分享,欢迎感兴趣的同学加微信:liyingjiesa,进群参与,您有想听的话题或者想分享的话题都可以给我们留言。

基于微服务和Docker容器技术的PaaS云平台架构设计

李颖杰 发表了文章 • 0 个评论 • 4670 次浏览 • 2017-06-26 18:55 • 来自相关话题

【编者的话】在系统架构上,PaaS云平台主要分为微服务架构、Docker容器技术、DveOps三部分,这篇文章重点介绍微服务架构的实施。 【3 天烧脑式容器存储网络训练营 | 深圳站】本次培训以容器存储和网络为主题,包括:Docker ...查看全部
【编者的话】在系统架构上,PaaS云平台主要分为微服务架构、Docker容器技术、DveOps三部分,这篇文章重点介绍微服务架构的实施。

【3 天烧脑式容器存储网络训练营 | 深圳站】本次培训以容器存储和网络为主题,包括:Docker Plugin、Docker storage driver、Docker Volume Pulgin、Kubernetes Storage机制、容器网络实现原理和模型、Docker网络实现、网络插件、Calico、Contiv Netplugin、开源企业级镜像仓库Harbor原理及实现等。

基于微服务架构和Docker容器技术的PaaS云平台建设目标是给我们的开发人员提供一套服务快速开发、部署、运维管理、持续开发持续集成的流程。平台提供基础设施、中间件、数据服务、云服务器等资源,开发人员只需要开发业务代码并提交到平台代码库,做一些必要的配置,系统会自动构建、部署,实现应用的敏捷开发、快速迭代。在系统架构上,PaaS云平台主要分为微服务架构、Docker容器技术、DveOps三部分,这篇文章重点介绍微服务架构的实施。

实施微服务需要投入大量的技术力量来开发基础设施,这对很多公司来说显然是不现实的,别担心,业界已经有非常优秀的开源框架供我们参考使用。目前业界比较成熟的微服务框架有Netflix、Spring Cloud和阿里的Dubbo等。Spring Cloud是基于Spring Boot的一整套实现微服务的框架,它提供了开发微服务所需的组件,跟Spring Boot一起使用的话开发微服务架构的云服务会变的很方便。Spring Cloud包含很多子框架,其中Spring Cloud Netflix是其中的一套框架,在我们的微服务架构设计中,就使用了很多Spring Cloud Netflix框架的组件。Spring Cloud Netflix项目的时间还不长,相关的文档资料很少,博主当时研究这套框架啃了很多英文文档,简直痛苦不堪。对于刚开始接触这套框架的同学,要搭建一套微服务应用架构,可能会不知道如何下手,接下来介绍我们的微服务架构搭建过程以及需要那些框架或组件来支持微服务架构。

为了直接明了的展示微服务架构的组成及原理,博主画了一张系统架构图,如下:
01.jpg

从上图可以看出,微服务访问大致路径为:外部请求 → 负载均衡 → 服务网关(GateWay)→ 微服务 → 数据服务/消息服务。服务网关和微服务都会用到服务注册和发现来调用依赖的其他服务,各服务集群都能通过配置中心服务来获得配置信息。
#服务网关(GateWay)
网关是外界系统(如:客户端浏览器、移动设备等)和企业内部系统之间的一道门,所有的客户端请求通过网关访问后台服务。为了应对高并发访问,服务网关以集群形式部署,这就意味着需要做负载均衡,我们采用了亚马逊EC2作为虚拟云服务器,采用ELB(Elastic Load Balancing)做负载均衡。EC2具有自动配置容量功能,当用户流量达到尖峰,EC2可以自动增加更多的容量以维持虚拟主机的性能。ELB弹性负载均衡,在多个实例间自动分配应用的传入流量。为了保证安全性,客户端请求需要使用https加密保护,这就需要我们进行SSL卸载,使用Nginx对加密请求进行卸载处理。外部请求经过ELB负载均衡后路由到GateWay集群中的某个GateWay服务,由GateWay服务转发到微服务。服务网关作为内部系统的边界,它有以下基本能力:

  1. 动态路由:动态的将请求路由到所需要的后端服务集群。虽然内部是复杂的分布式微服务网状结构,但是外部系统从网关看就像是一个整体服务,网关屏蔽了后端服务的复杂性。

  1. 限流和容错:为每种类型的请求分配容量,当请求数量超过阀值时抛掉外部请求,限制流量,保护后台服务不被大流量冲垮;党内部服务出现故障时直接在边界创建一些响应,集中做容错处理,而不是将请求转发到内部集群,保证用户良好的体验。

  1. 身份认证和安全性控制:对每个外部请求进行用户认证,拒绝没有通过认证的请求,还能通过访问模式分析,实现反爬虫功能。

  1. 监控:网关可以收集有意义的数据和统计,为后台服务优化提供数据支持。

  1. 访问日志:网关可以收集访问日志信息,比如访问的是哪个服务?处理过程(出现什么异常)和结果?花费多少时间?通过分析日志内容,对后台系统做进一步优化。

我们采用Spring Cloud Netflix框架的开源组件Zuul来实现网关服务。Zuul使用一系列不同类型的过滤器(Filter),通过重写过滤器,使我们能够灵活的实现网关(GateWay)的各种功能。
#服务注册与发现
由于微服务架构是由一系列职责单一的细粒度服务构成的网状结构,服务之间通过轻量机制进行通信,这就引入了服务注册与发现的问题,服务的提供方要注册报告服务地址,服务调用放要能发现目标服务。我们的微服务架构中使用了Eureka组件来实现服务的注册与发现。所有的微服务(通过配置Eureka服务信息)到Eureka服务器中进行注册,并定时发送心跳进行健康检查,Eureka默认配置是30秒发送一次心跳,表明服务仍然处于存活状态,发送心跳的时间间隔可以通过Eureka的配置参数自行配置,Eureka服务器在接收到服务实例的最后一次心跳后,需要等待90秒(默认配置90秒,可以通过配置参数进行修改)后,才认定服务已经死亡(即连续3次没有接收到心跳),在Eureka自我保护模式关闭的情况下会清除该服务的注册信息。所谓的自我保护模式是指,出现网络分区、Eureka在短时间内丢失过多的服务时,会进入自我保护模式,即一个服务长时间没有发送心跳,Eureka也不会将其删除。自我保护模式默认为开启,可以通过配置参数将其设置为关闭状态。

Eureka服务以集群的方式部署(在博主的另一篇文章中详细介绍了Eureka集群的部署方式),集群内的所有Eureka节点会定时自动同步微服务的注册信息,这样就能保证所有的Eureka服务注册信息保持一致。那么在Eureka集群里,Eureka节点是如何发现其他节点的呢?我们通过DNS服务器来建立所有Eureka节点的关联,在部署Eureka集群之外还需要搭建DNS服务器。

当网关服务转发外部请求或者是后台微服务之间相互调用时,会去Eureka服务器上查找目标服务的注册信息,发现目标服务并进行调用,这样就形成了服务注册与发现的整个流程。Eureka的配置参数数量很多,多达上百个,博主会在另外的文章里详细说明。
#微服务部署
微服务是一系列职责单一、细粒度的服务,是将我们的业务进行拆分为独立的服务单元,伸缩性好,耦合度低,不同的微服务可以用不同的语言开发,每一个服务处理的单一的业务。微服务可以划分为前端服务(也叫边缘服务)和后端服务(也叫中间服务),前端服务是对后端服务做必要的聚合和剪裁后暴露给外部不同的设备(PC、Phone等),所有的服务启动时都会到Eureka服务器进行注册,服务之间会有错综复杂的依赖关系。当网关服务转发外部请求调用前端服务时,通过查询服务注册表就可以发现目标服务进行调用,前端服务调用后端服务时也是同样的道理,一次请求可能涉及到多个服务之间的相互调用。由于每个微服务都是以集群的形式部署,服务之间相互调用的时候需要做负载均衡,因此每个服务中都有一个LB组件用来实现负载均衡。

微服务以镜像的形式,运行在Docker容器中。Docker容器技术让我们的服务部署变得简单、高效。传统的部署方式,需要在每台服务器上安装运行环境,如果我们的服务器数量庞大,在每台服务器上安装运行环境将是一项无比繁重的工作,一旦运行环境发生改变,就不得不重新安装,这简直是灾难性的。而使用Docker容器技术,我们只需要将所需的基础镜像(jdk等)和微服务生成一个新的镜像,将这个最终的镜像部署在Docker容器中运行,这种方式简单、高效,能够快速部署服务。每个Docker容器中可以运行多个微服务,Docker容器以集群的方式部署,使用Docker Swarm对这些容器进行管理。我们创建一个镜像仓库用来存放所有的基础镜像以及生成的最终交付镜像,在镜像仓库中对所有镜像进行管理。
#服务容错
微服务之间存在错综复杂的依赖关系,一次请求可能会依赖多个后端服务,在实际生产中这些服务可能会产生故障或者延迟,在一个高流量的系统中,一旦某个服务产生延迟,可能会在短时间内耗尽系统资源,将整个系统拖垮,因此一个服务如果不能对其故障进行隔离和容错,这本身就是灾难性的。我们的微服务架构中使用了Hystrix组件来进行容错处理。Hystrix是Netflix的一款开源组件,它通过熔断模式、隔离模式、回退(fallback)和限流等机制对服务进行弹性容错保护,保证系统的稳定性。

  1. 熔断模式:熔断模式原理类似于电路熔断器,当电路发生短路时,熔断器熔断,保护电路避免遭受灾难性损失。当服务异常或者大量延时,满足熔断条件时服务调用方会主动启动熔断,执行fallback逻辑直接返回,不会继续调用服务进一步拖垮系统。熔断器默认配置服务调用错误率阀值为50%,超过阀值将自动启动熔断模式。服务隔离一段时间以后,熔断器会进入半熔断状态,即允许少量请求进行尝试,如果仍然调用失败,则回到熔断状态,如果调用成功,则关闭熔断模式。

  1. 隔离模式:Hystrix默认采用线程隔离,不同的服务使用不同的线程池,彼此之间不受影响,当一个服务出现故障耗尽它的线程池资源,其他的服务正常运行不受影响,达到隔离的效果。例如我们通过andThreadPoolKey配置某个服务使用命名为TestThreadPool的线程池,实现与其他命名的线程池隔离。

  1. 回退(fallback):fallback机制其实是一种服务故障时的容错方式,原理类似Java中的异常处理。只需要继承HystixCommand并重写getFallBack()方法,在此方法中编写处理逻辑,比如可以直接抛异常(快速失败),可以返回空值或缺省值,也可以返回备份数据等。当服务调用出现异常时,会转向执行getFallBack()。有以下几种情况会触发fallback:

1. 程序抛出非HystrixBadRequestExcepption异常,当抛出HystrixBadRequestExcepption异常时,调用程序可以捕获异常,没有触发fallback,当抛出其他异常时,会触发fallback;
2. 程序运行超时;
3. 熔断启动;
4. 线程池已满。

  1. 限流: 限流是指对服务的并发访问量进行限制,设置单位时间内的并发数,超出限制的请求拒绝并fallback,防止后台服务被冲垮。

Hystix使用命令模式HystrixCommand包装依赖调用逻辑,这样相关的调用就自动处于Hystrix的弹性容错保护之下。调用程序需要继承HystrixCommand并将调用逻辑写在run()中,使用execute()(同步阻塞)或queue()(异步非阻塞)来触发执行run()。
#动态配置中心
微服务有很多依赖配置,某些配置参数在服务运行期间可能还要动态修改,比如:根据访问流量动态调整熔断阀值。传统的实现信息配置的方法,比如放在xml、yml等配置文件中,和应用一起打包,每次修改都要重新提交代码、打包构建、生成新的镜像、重新启动服务,效率太低,这样显然是不合理的,因此我们需要搭建一个动态配置中心服务支持微服务动态配置。我们使用Spring Cloud的configserver服务帮我们实现动态配置中心的搭建。我们开发的微服务代码都存放在git服务器私有仓库里面,所有需要动态配置的配置文件存放在git服务器下的configserver(配置中心,也是一个微服务)服务中,部署到Docker容器中的微服务从git服务器动态读取配置文件的信息。当本地git仓库修改代码后push到git服务器仓库,git服务端hooks(post-receive,在服务端完成代码更新后会自动调用)自动检测是否有配置文件更新,如果有,git服务端通过消息队列给配置中心(configserver,一个部署在容器中的微服务)发消息,通知配置中心刷新对应的配置文件。这样微服务就能获取到最新的配置文件信息,实现动态配置。

以上这些框架或组件是支撑实施微服务架构的核心,在实际生产中,我们还会用到很多其他的组件,比如日志服务组件、消息服务组件等等,根据业务需要自行选择使用。在我们的微服务架构实施案例中,参考使用了很多Spring Cloud Netflix框架的开源组件,主要包括Zuul(服务网关)、Eureka(服务注册与发现)、Hystrix(服务容错)、Ribbon(客户端负载均衡)等。这些优秀的开源组件,为我们实施微服务架构提供了捷径。

以上篇幅主要介绍了微服务架构的基本原理,其中有些比较细节的东西,比如Eureka的各项参数配置说明、动态配置中心搭建过程等,博主会在其他的文章中做出详细的说明,供大家参考。

原文链接:微服务架构:基于微服务和Docker容器技术的PaaS云平台架构设计(微服务架构实施原理)(作者:方福海)

使用开源软件和Tectonic,摆脱云服务供应商的锁定

龙影随风 发表了文章 • 0 个评论 • 3004 次浏览 • 2017-06-11 15:01 • 来自相关话题

【编者的话】本文介绍了Core Fest大会关于容器PaaS平台——Tectonic的相关内容,以及使用开源软件打破云服务供应商的捆绑,详细内容请浏览下文。 【3 天烧脑式 Docker 训练营 | 上海站】随着Docker技术被越来 ...查看全部
【编者的话】本文介绍了Core Fest大会关于容器PaaS平台——Tectonic的相关内容,以及使用开源软件打破云服务供应商的捆绑,详细内容请浏览下文。

【3 天烧脑式 Docker 训练营 | 上海站】随着Docker技术被越来越多的人所认可,其应用的范围也越来越广泛。本次培训我们理论结合实践,从Docker应该场景、持续部署与交付、如何提升测试效率、存储、网络、监控、安全等角度进行。

从第一个企业IT系统问世以来,信息技术为企业发展提供了更大的自由度和生产效率。然而每一代企业系统都需要相当大的资金支出,这使得供应商服务变得更加不合理。尽管云计算看起来会改变这个状况,但现实却受到限制。在今天的CoreOS Fest大会上,我们将展示Tectonic是如何专注于开源技术,打破这一限制。

CoreOS的使命是保护互联网。CoreOS认为自动化操作与云服务供应商提供的服务类似,这是实现使命的关键。然而,由于使用Amazon DynamoDB、Google Cloud Platform BigQuery、Amazon Athena等云服务供应商的服务,企业通常并没有意识到被专有的生态锁定。开源容器编排框架Kubernetes以及容器操作系统Container Linux,正在打破这些单一的生态,还原云计算的初衷。CoreOS首次实现了云的自动化操作和开源工具的开放性。
# 使用开源,打破商业软件周期的限制
Kubernetes提供了一个管理公共云和私有云应用程序的标准平台。在今天的CoreOS Fest大会上,我们将说明如何使用开源打破商业软件的周期限制。Tectonic建立在最新版本的Kubernetes之上,并且它正在添加开源云服务。无论基础设施是裸机、私有IaaS还是公有IaaS,Tectonic都提供自动化操作,以实现“云计算即服务”的运营模式。你可以在应用程序的生命周期中获取云的灵活性,从而不被云服务供应商的商业服务锁定。

根据451研究报告,71%的受访者表示正在使用Kubernetes,该软件的优势是释放资源,混合云支持和跨云服务供应商支持,自动计算和避免云服务供应商的锁定。
# Tectonic的开源云服务——Etcd as a Service和Kubernetes as a Service
今天,CoreOS推出第一个开源云服务:etcd as a Service。现在,Tectonic提供内置的Kubernetes开源云服务。Etcd正处于测试阶段,可以被部署在Tectonic上的应用程序使用。Etcd Operators自动处理etcd缩放,恢复和版本更新任务,以维护其所需状态。Etcd as a Service是第一个开源的“数据库即服务”,这是第一个基于Tectonic的开源云服务。
etcd-operator.png

而且,我们宣布由Tectonic支持的Kubernetes as a service。使用Kubernetes as a service,企业无需停机即可完成更新集群,智能订购,手动或完全自动化等操作。

Kubernetes as a service和Etcd as a service的发布,意味着企业IT人员可以在任何云服务供应商的Kubernetes上运行应用程序。这使得企业在选择云服务时,可以获得更大的自由选择权。
# Tectonic的自动化操作——Container Linux Operator
CoreOS发布了提供操作系统热修补功能的产品——Container Linux Operator,并将其集成到Kubernetes当中。在使用Container Linux和etcd Operators条件下,Tectonic提供节点级的容器操作系统Container Linux和etcd服务,以实现自动化操作。 通过自动更新Kubernetes集群的控制平面,worker节点的操作系统和etcd服务实例,Tectonic管理员可以显著提高操作的有效性和安全性。
cluo-example.png

Tectonic的自动化操作不仅帮助企业把精力放在重要的业务上,而且使企业的基础架构始终保持最新。
# Tectonic运行OSS
CoreOS Tectonic是唯一准企业级的Kubernetes平台,运行最新版本的Kubernetes。我们将通过充分利用最好的开源技术,以确保企业的基础架构始终保持最新版本,同时也给企业自由选择上云的服务。

原文链接:Breaking free from cloud vendor lock-in with Kubernetes and Open Source(翻译:Jack Yue)

译者介绍: Jack,开源软件研究者,研究方向是容器技术和深度学习,目前积极活跃于DockOne、Kubernetes、Tensorflow技术社区。

PaaS容器集群优化之路

难易 发表了文章 • 0 个评论 • 3455 次浏览 • 2017-05-06 08:42 • 来自相关话题

【编者的话】本文探讨了在一个复杂的PaaS系统中,如何系统化、科学化的进行全系统的性能优化工作。 # 1. 性能优化面对的挑战 以下是整个PaaS平台的架构 其 ...查看全部
【编者的话】本文探讨了在一个复杂的PaaS系统中,如何系统化、科学化的进行全系统的性能优化工作。
# 1. 性能优化面对的挑战
以下是整个PaaS平台的架构
1.png

其中主要包括这些子系统:

* 微服务治理框架:为应用提供自动注册、发现、治理、隔离、调用分析等一系列分布式/微服务治理能力,屏蔽分布式系统的复杂度。
* 应用调度与资源管理框架:打通从应用建模、编排部署到资源调度、弹性伸缩、监控自愈的生命周期管理自动化。
* 应用开发流水线框架:打通从编写代码提交到自动编译打包、持续集成、自动部署上线的一系列CI/CD全流程自动化。
* 云中间件服务:应用云化所需的数据库、大数据、通信和应用中间件服务;通过服务集成管控可集成传统非云化的中间件能力。

面对一个如此复杂的系统,性能优化工作是一个非常艰巨的挑战,这里有这么一些痛点:

* 源代码及开发组件多,100+ git repo,整体构建超过1天
* 运行架构复杂,全套安装完需要30+VM,200+进程
* 软件栈深,网络平面复杂
* 集群规模大,5k — 10k节点环境搭建非常困难
* 系统操作会经过分布式的多个组件,无法通过单一组件诊断发现系统瓶颈
* 无法追踪上千个处于不同层次的API的时延和吞吐
* 大部分开发人员专注于功能开发,无法意识到自己的代码可能造成性能问题

# 2. 优化分析
那么,对于这么一个大的、复杂的系统,从方法论的角度来讲,应该怎么去优化呢?基本思路就是做拆分,把一个大的问题分解为多个互相不耦合的维度,进行各个击破。从大的维度来讲,一个PaaS容器集群,可以分为3个大的子系统。

  1. 控制子系统:控制指令的下发和运行(k8s),例如创建pod
  2. 业务流量子系统:容器网络(flannel)、负载均衡(ELB/kube-proxy)
  3. 监控子系统:监控告警数据的采集(kafka, Hadoop)

这个看起来仅仅是一个架构上的划分,那么如何和具体的业务场景对应起来呢?我们可以考虑如下一个场景,在PaaS平台上大批量的部署应用。看看在部署应用的过程中,会对各个子系统产生什么压力。

* 应用软件包大小:400M
* 应用模板大小:10M
* 1000个节点,每个节点一个POD,一个实例
* 10种类型的软件包,依赖长度为3,10GB 网络
* 调度及资源管理 3VM

这是一个典型的部署应用的一些规格,那么对于这样的一个输入,我们可以按照架构把压力分解到每个子系统上,这样得出的子系统需要支撑的指标是:

  1. 控制子系统: Kubernetes调度速度 > 50 pods/s,仓库支持300并发下载,>40M/s
  2. 数据子系统:overlay容器网络TCP收发性能损耗 <5%
  3. 监控子系统:在上面这个场景中不涉及,但可以从别的场景大致告警处理能力100条/秒

这里的业务场景:架构分析:子系统指标,这三者是m:1:n的,也就是说在不同场景下对不同的组件的性能要求不同,最后每个组件需要取自己指标的最大值。

指标决定了后续怎么进行实验测试,而测试是要花较大时间成本的,所以在指标的选取上要求少求精,尽量力图用2-3个指标衡量子系统。
# 3. 优化测试 & 工具
上面讲的还是偏纸上的推演和分析,接下来进入实战阶段
2.png

对于服务器后端的程序来讲,推荐使用这个工具来做指标的定义和采集。Promtheus的基本工作原理是:后端程序引入Promtheus的SDK,自定义所有需要的测量的指标,然后开启一个http的页面,定期刷新数据。Promtheus服务器会定期抓取这个页面上的数据,并存在内部的时间序列数据库内。这种抓而非推的方式减少了对被测试程序的压力,避免了被测程序要频繁往外发送大量数据,导致自身性能反而变差而导致测量不准确。Promtheus支持这几种数据类型:

* 计数(对应收集器初始化方法NewCounter、NewCounterFunc、NewCounterVec,单一数值,数值一直递增,适合请求数量统计等)
* 测量(对应收集器初始化方法NewGauge、NewGaugeFunc、NewGaugeVec,单一数值,数值增减变动,适合CPU、Mem等的统计)
* 直方图测量(对应收集器初始化方法NewHistogram、NewHistogramVec,比较适合时长等的统计)
* 概要测量(对应收集器初始化方法NewSummary、NewSummaryVec,比较适合请求时延等的统计)

我们可以看看在Kubernetes项目里面是怎么用的:
var (
// TODO(a-robinson): Add unit tests for the handling of these metrics once
// the upstream library supports it.
requestCounter = prometheus.NewCounterVec(
prometheus.CounterOpts{
Name: "apiserver_request_count",
Help: "Counter of apiserver requests broken out for each verb, API resource, client, and HTTP response contentType and code.",
},
[]string{"verb", "resource", "client", "contentType", "code"},
)
requestLatencies = prometheus.NewHistogramVec(
prometheus.HistogramOpts{
Name: "apiserver_request_latencies",
Help: "Response latency distribution in microseconds for each verb, resource and client.",
// Use buckets ranging from 125 ms to 8 seconds.
Buckets: prometheus.ExponentialBuckets(125000, 2.0, 7),
},
[]string{"verb", "resource"},
)
requestLatenciesSummary = prometheus.NewSummaryVec(
prometheus.SummaryOpts{
Name: "apiserver_request_latencies_summary",
Help: "Response latency summary in microseconds for each verb and resource.",
// Make the sliding window of 1h.
MaxAge: time.Hour,
},
[]string{"verb", "resource"},
)
)

在这里,一个http请求被分为`verb, resource, client, contentType, code`这五个维度,那么后面在PromDash上就能图形化的画出这些请求的数量。 从而分析哪种类型的请求是最多,对系统造成最大压力的,如图
3.jpg

除了Promtheus,还可以引入其他的测量手段,对系统进行分析。
4.png


* 在Kubernetes调度过程中,各个状态Pod的数量,看哪一步是最卡的
5.png


* go pprof分析,哪些函数是最耗CPU的

# 4. 优化开发
发现了瓶颈之后,下一步就是解决瓶颈,和具体业务逻辑有关,本文在这里就不做过多的阐释。需要对相关代码非常熟悉,在不改变功能的情况下增强性能,基本思路为并发/缓存/去除无用步骤等。
# 5. 优化成果
这是我们在Kubernetes项目上控制面优化的成果:
A215B98F-15A4-4FC3-8E3B-E6A76B244222.png


这里仅仅显示了控制子系统的指标,其他子系统还没有支持那么大的集群,尤其在网络方面,不同用户的网络架构差别很大。所以数据仅供参考

# 6. 优化的优化
在上面的优化过程当中,基本上工程师要做几百次优化的测试和开发。这里会产生一个循环:

  1. 测试寻找瓶颈点
  2. 修改代码突破这个瓶颈点
  3. 重新测试验证这段代码是否有效,是否需要改优化思路

这就是一个完整的优化的迭代过程,在这个过程当中,大部分时间被浪费在构建代码、搭建环境、输出报告上。开发人员真正思考和写代码的时间比较短。为了解决这个问题,就需要做很多自动化的工作。在Kubernetes优化的过程中,有这么几项方法可以节省时间:
6.png


  • kubemark模拟器 :社区项目,使用容器模拟虚拟机,在测试中模拟比达到1:20,也就是一台虚拟机可以模拟20台虚拟机对apiserver产生的压力。在测试过程当中,我们使用了500台虚拟机,模拟了10000节点的控制面行为。
  • CI集成:提交PR后自动拉性能优化分支并开始快速构建
  • CD集成:使用I层的快照机制,快速搭建集群并执行测试案例输出测试报告

以上都是在实践过程中总结的一些点,对于不同的项目工程应该有很多点可以做进一步的优化,提升迭代效率。

在搭建完这套系统后,我们发现这个系统可以从源头上预防降低系统性能的代码合入主线。如果一项特性代码造成了性能下降,在CI的过程当中,功能开发者就能收到性能报告,这样开发者就能自助式的去查找自己代码的性能问题所在,减少性能工程师的介入。
#Q&A
Q:节点资源充足情况下,Docker的运行性能会持续下降,有什么方法可以检测Daemon?
A:这个问题是个好问题,我观察到的是Docker Daemon CPU耗的比较多,可以打开pprof测量下哪个函数耗的最多。

Q:再详细介绍一下如何进行性能优化的,有没有什么具体的优化指标?
A:Kubernetes管理子系统的指标是API时延,Pod从创建到运行时延,Pod从创建到启动吞吐。

Q:请问在优化的过程中有没有使用或者开发什么样的可视化工具,帮助直观了解可能存在的系统瓶颈?
A:工具上面提了几个,Promtheus,pprof,还有自己写的统计脚本。

Q:对于应用程序包分发是否做过相关优化,传统应用的程序包都比较大?
A:一个是要做好镜像分层,应用构建时就把运行时和应用分开,另一个就是在镜像下载时做P2P分发,这个我们内部做过,阿里的那个容器项目也做过不过都没开源,简单山寨一个其实也不难。

Q:每个节点1个Pod是什么意思?业务场景那张PPT。
A:那个场景是设想每个节点部署一个Pod,实际上应该不止,目前来看每节点部署20Pod比较合理。

Q:Pod从创建到启动不是由kubelet和Docker决定的吗?瓶颈会在哪儿,挂volume,加载network plugin?
A:Pod创建要从调用Kubernetes API创建Pod对象开始,后面要经过调度,调度的时延还行,但一旦大量Pod被创建,吞吐就慢了,要排队调度。kubelet的那些操作本身也还行,比下载镜像要快。很多问题是规模问题,在一个万节点的集群上你会发现不少操作都会慢。

Q:如果发现应用程序本身需要优化,如何增加断点分析哪一步逻辑业务可能造成了瓶颈问题,比如你们能不能模拟用户体验?看是哪一部用户操作造成了延迟?嗯?
A:这个问题比较泛,单从哪一部分用户来说。Promtheus内可以分用户的维度来统计。也就是说同样一些API操作,它能帮你按多个维度来分析,可以安增删改查,也可以按请求时延来排序,帮你发现什么操作是最慢的。断点方式,Kubernetes的代码里面有tracelog。

新智PaaS云平台能帮助企业做什么?

回复

新智云 回复了问题 • 2 人关注 • 1 个回复 • 1796 次浏览 • 2017-07-11 15:06 • 来自相关话题

论派的制作与平台的选择:Paas vs. CaaS

回复

tony20071205 回复了问题 • 4 人关注 • 1 个回复 • 2750 次浏览 • 2017-03-31 16:57 • 来自相关话题

PaaS的前景如何?CaaS了?

回复

tonybai_cn 回复了问题 • 25 人关注 • 13 个回复 • 11175 次浏览 • 2017-01-23 13:15 • 来自相关话题

支持Kubernetes的开源PaaS平台选择?

回复

木头人 回复了问题 • 21 人关注 • 8 个回复 • 21985 次浏览 • 2015-05-23 20:20 • 来自相关话题

基于Docker的PaaS的构建

回复

DaoCloud 回复了问题 • 11 人关注 • 6 个回复 • 6063 次浏览 • 2015-04-21 00:45 • 来自相关话题

详解宜信PaaS平台LAIN的功能和架构

aoxiang 发表了文章 • 0 个评论 • 222 次浏览 • 2019-05-24 07:14 • 来自相关话题

LAIN是宜信公司大数据创新中心开发的开源PaaS平台。在金融的场景下,LAIN 是为解放各个团队和业务线的生产力而设计的一个云平台。LAIN 为宜信大数据创新中心各个团队提供了统一的测试和生产环境,简化了服务的部署与上线流程,也降低了运维人员对系统管理的复杂 ...查看全部
LAIN是宜信公司大数据创新中心开发的开源PaaS平台。在金融的场景下,LAIN 是为解放各个团队和业务线的生产力而设计的一个云平台。LAIN 为宜信大数据创新中心各个团队提供了统一的测试和生产环境,简化了服务的部署与上线流程,也降低了运维人员对系统管理的复杂度。
#一、设计理念及解决问题
LAIN 规范了一个应用的开发、测试、上线工作流,提供了为应用做的容器编排、权限控制、SDN、流量管理、监控报警、备份、日志等 DevOps 问题的整体解决方案。如果你想和更多Docker技术专家交流,可以加我微信liyingjiese,备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态。

在 LAIN 上,应用是一个基本的概念,某个应用的开发者只需要定义一个 lain.yaml 即可定义应用的编译和运行方式,对应用代码侵入性很低。LAIN 基于容器技术,面向多样化的技术栈,并且天然隔离系统和应用的依赖。

当 LAIN 用户创建一个应用(服务)时,可以到 LAIN 上注册该应用,当前的用户自动成为了该应用的维护者,拥有了进一步操作该应用的权限。构建应用的环境需要 Docker 和 Lain 命令行工具,为了方便,我们创建了一个 vagrant box 即 lain-box. 在构建应用时,除了工程代码外,还需要一个 Docker 镜像作为基础镜像,即编译的环境。如果是二进制的工程,如 golang,则可以在运行时换掉一个底,否则会使用 build 镜像为 release 镜像。准备好镜像和编译/运行的脚本后,就可以编辑 lain.yaml 了。

具体来说,LAIN 解决了以下四个问题:
##1、应用开发之下的DevOps问题的整体解决方案
常见问题:

* 面对用户的应用级开发仅仅是冰山一角,在此之下有机房、网络、服务器、系统管理、运维管理、监控、告警、日志等等一系列背后的工作,而这部份的工作可能比应用级开发还要复杂
* 采用IaaS解决了服务器采购和上架问题,但是依然需要一个强大的devops团队来负责上述事务,否则基础设施很容易成为发展瓶颈,且越拖越难解决
* 上面的这些工作对于每一个产品可能都是同质化但又伴随着定制,会消耗大量的时间做这些重复的工作

Lain是怎么做的:

* 直接在几乎裸的IaaS或者服务器上即可构建lain集群,方便地进行在线的扩容缩容等集群底层资源操作
* 整合了业界沉淀下来的良好的运维整体实践,提供了冰山下的这一大块工作的整体解决方案
* 将纷繁复杂的系统管理和运维管理行为封装为更简单易用的工具包,极大简化大部分的系统工作,降低日常维护的技术门槛和人力需求
* 将同质化的工作整合在一起,避免重复劳动
* 开箱即用的各种管理组件,囊括了部署,扩容,监控,告警,日志等方方面面。还有附赠应用,包括mysql,redis的集群服务

##2、规范了应用开发的工作流程,并辅以适当的SCM支援
常见问题:

* 在个人开发者以及startup组织中,良好的工作流这件事几乎是不会被提及的,然而在日渐发展的过程中遗留的技术债务却会越来越多的影响开发部署的效率和质量
* 设计、开发和部署行为的不规范会引发各种问题

Lain是怎么做的:

* 提供本地开发环境的解决方案
* 提供本地开发过程的SDK / CLI工具链,使得开发和构建过程是嵌入在解决方案中的
* 隐性的提供了SCM支援,约束了开发者的开发和发布行为

##3、提高整体资源利用率,优化冗余资源池
常见问题:

* 传统的按照产品线规划资源池的情况下,会给各产品预留专属的资源池以及配备冗余,以便进行灾备以及服务突发流量
* 然而各产品线的资源需求类型不同,冗余类型也不同,无法共通共享,造成众多的重复冗余,资源利用率比较低
* 通过服务器资源的冗余,扩容缩容,以及资源迁移的操作比较复杂,时间消耗大,风险高

Lain是怎么做的:

* 通过容器技术的资源隔离和控制,实现多种技术栈多种应用在集群内安全的不相互影响的混合部署,通过统一的资源池进行冗余,有效提高资源利用率
* 容器技术的运用使得对下资源的使用形成完全统一的形式,扩容缩容以及迁移的成本很低,操作也更简单。

##4、TBD:架构上提供了服务治理的可能性和解决方案
#二、特征
在应用的层面上,LAIN 还有以下特征:
##1、基于配置文件定义应用

* 在现有的应用上只需要增加一个配置文件lain.yaml即可定义应用在lain集群里的编译和运行
* 对应用代码的侵入性很低

##2、SDN网络安全隔离

* 使用开源的calico项目构建SDN网络
* 高效率的应用内网络互通
* 应用间网络默认隔离
* 显式声明应用间的服务互访

##3、基于容器技术支持多样化的技术栈

* 使用开源的Docker项目构建容器云
* 扩展封装Dockerfile,使用自定义的yaml格式进行应用的集群定义
* 只需符合最简单的lain cluster runtime interface,可自由选择base image
* 容器技术天然的支持隔离系统和应用的依赖
* lain SDK / CLI以及可选的ci组件支援代码版本和镜像之间的对应关系
* 编译时和运行时镜像均可完全定制和隔离

##4、应用在线扩容缩容

* 使用开源的swarm调度应用部署
* 深度封装swarm docker API,自行开发集群控制器(deployd)以及应用控制器(console)
* 直接支持用户API调用进行容器实例数扩容,缩容
* 直接支持用户API调用进行容器单实例资源的扩容,缩容(CPU,MEM)

##5、节点在线扩容缩容

* 使用开源的Ansible开发集群管理运维工具包
* 集群的服务器节点(NODE)兼容同一个C段内的物理服务器,虚拟机,公有云服务器
* 集群管理工具包支持add NODE 和 remove NODE 指令,快速进行底层资源扩容和缩容

##6、服务自动维持和灾难恢复

* 自行开发集群控制器(deployd)
* 容器实例级别的服务巡检和维持,自动迁移和服务恢复
* 基于虚IP自动漂移的入口load balancer HA
* 高级API支持服务定制迁移

##7、内部服务依赖和发现机制

* 集群支援Service / Resource 机制
* 集群整体的服务应用
* 应用私有Service (即 Resource)服务应用
* 集群支援特别的服务应用类型和资源应用类型
* 在lain.yaml中显式声明使用的Service / Resource
* 基于DNS的服务发现机制
* 可编程的service/resource load balancer
* 默认提供可用的RoundRobin类型的load balancer

##8、统一认证

* 集群自行开发统一认证组件(sso)
* 支持oauth2的多种认证方式

##9、虚IP和负载均衡器统一管理

* 支援 virtual ip 和 应用 proc 的注册,应用可注册 virtual ip 来进行对外服务
* 基于etcd lock机制的virtual ip 漂移机制,应用 load balancer 可借此实现 HA

##10、web load balancer的自动配置

* 使用开源的Nginx和tengine封装web服务的负载均衡器
* 自研的watcher检测集群应用的整体 runtime 数据,自动为 web 服务生成配置
* 获取runtime变化的时间,判断是否需要进行配置变更
* 配置变更事件出发配置的渲染
* 触发 reload 生效

##11、集群体系化的日志收集

* 使用开源的heka配合docker的配置以及rsyslog封装集群整体日志收集
* 默认收集应用的stdout / stderr日志收集
* 支援应用显式声明需要收集的落地文件日志
* 支援应用显式声明结构化的监控数据日志
* 定制检测web服务load balancer的nginx日志收集和数据统计

##12、私有docker registry以及认证机制

* 使用开源的docker registry封装私有 registry 应用
* 集成支援集群的私有统一认证机制
* 定制支援可选的moosefs存储后端或者Ceph存储后端

##13、应用配置加密存储

* 使用开源的库封装的应用私有配置加密存储组件
* 集成sso组件实现用户管理和权限隔离
* 在应用运行时阶段将配置注入

##14、本地化开发环境

* 使用开源的vagrant,免费的centos和virtualbox组织统一的本地化开发环境
* 甚至支援本地使用上述工具链bootstrap出一个lain本地集群

##15、应用部署运维API以及相应的CLI客户端

* 应用的构建,发布,部署,运维都由集群的各组件提供API
* 使用lain SDK / CLI再次封装上述API,给用户提供良好的操作界面
* 集成集群的统一认证,进行用户管理和权限隔离

1.png

##16、集群管理CLI

* 使用开源的ansible开发集群管理运维工具包
* 再次封装ansible调用为简单的CLI使得操作更方便,包括增加节点,移除节点,迁移应用,集群健康检查等。

##17、规范化的开发workflow

* 基于上述组件,以代码 - 镜像的一一对应关系进行SCM,对镜像进行发布管理
* 使用lain SDK / CLI以及可选的ci组件进行本地开发,构建发布,会很自然的规范开发workflow
* 工作流运转的核心单位是镜像,lain cli封装了镜像的生成,更新,推送,部署,运维

2.png

##18、可选的集群体系化的备份和恢复(backupd + moosefs)

* 采用开源的moosefs作为分布式存储后端
* 支援在lain.yaml中显式声明volume备份需求和策略,以及设定备份策略的hooks
* 支援指定备份恢复

##19、可选的集群日志查询组件(Kafka + Elasticsearch + Kibana)

* 采用开源的Kakfa ,Elasticsearch,Kibana搭建外部依赖的卡夫卡集群和Elasticsearch集群,封装集群可选组件Libana
* rebellion集群日志收集组件支援发送所有日志到上述外部依赖kafka
* 在libana上支援对集群应用日志和web load balancer 日志的条件组合查询

##20、可选的系列预置应用

* MySQL的服务
* MySQL的资源
* Redis的服务-SM

#三、系统架构
##1、物理视图
从物理层面看,每一个 lain 集群是由一个或多个网络互通的节点(Node)构成的。
3.png

每个节点可以被赋予不同的 label ,供容器调度时进行节点选择使用。 目前的实现中,需要所有节点位于同一个路由器后。
##2、逻辑视图
从逻辑层面看,一个 lain 集群是由多个应用组成,应用和应用之间网络相互隔离(通过SDN技术)。
4.png

每一个应用是由多个 Docker 容器组成,每个容器都可能运行在不同的节点上。

应用开发者可以在一个应用中定义多种容器(称为 proc),每个 proc 可以指定为在集群上运行多份,每份即为一个容器,被称为 proc instance。Lain 集群会尽可能保证有指定份数的容器在运行,如果有容器 crash 或者节点 fail 的情况发生,集群会试图重启容器或者在节点间迁移容器。
##3、系统架构设计图
目标是做成一层一层可以深入的架构图。

总图:
5.png

节点:
6.png

##4、工作流程
7.png

GitHub地址:https://github.com/laincloud

白皮书:https://laincloud.gitbooks.io/white-paper/content/

原文链接:http://college.creditease.cn/detail/247

Serverless系列 | 云计算究竟如何进化出了Serverless?

灵雀云 发表了文章 • 0 个评论 • 545 次浏览 • 2019-04-10 16:14 • 来自相关话题

导读:近期灵雀云技术专家邵明岐翻译了Mike Roberts & John Chapin所著的《What is serverless》一书的部分内容,可以说是对Serverless科普与观察的上佳素材。本文为第1篇,他首先通过回溯云计算的发展史,来找出是什么原 ...查看全部

导读:近期灵雀云技术专家邵明岐翻译了Mike Roberts & John Chapin所著的《What is serverless》一书的部分内容,可以说是对Serverless科普与观察的上佳素材。本文为第1篇,他首先通过回溯云计算的发展史,来找出是什么原因导致进化出了 Serverless,然后解释 Serverless 到底为何物,最后总结为什么 Serverless 是云计算成长的必然产物,同时也是应用交付方式的巨大飞跃,非常值得一读!
原著:《What is serverless : understand the latest advances in cloud and service-based architecture》

作者:Mike Roberts & John Chapin
译文来源:深入浅出谈架构(ID:deep-easy-arch)
译者:灵雀云邵明岐

让我们回到2006年, 那时候还没有 iPhone 和移动互联网,Ruby on Rails 是一个非常热门的编程框架,Web 2.0 在当时是互联网最火热的名词。那时候大部分应用程序的后端服务,都是运行在托管或者自建的数据中心和物理服务器上。

云的诞生

2006年8月发生的事情将从根本上改变这种模式。 亚马逊新的IT部门 AWS 宣布推出Elastic Compute Cloud(EC2),EC2是众多基础架构即服务(IaaS)产品中的第一个, IaaS允许公司租用计算资源 (主要是面向互联网应用的虚拟主机),而不是购买自己的服务器, 它还允许人们在几分钟之内就可以获取到主机资源。 EC2的五个主要优势是:

1.降低人工成本
在 IaaS 出现之前,公司需要雇佣有专门技能的人来管理数据中心和里面的物理服务器,他们需要管理从电源和网络,到货架和安装,到修复机器的磁盘等物理问题,到设置操作系统(OS)。 通过IaaS,所有这些都消失了,而是都交给 IaaS 服务提供商,比如 AWS 或者阿里云。

2.降低风险
在管理自己的物理服务器时,经常会遭遇一些意外事件,比如硬件故障,从而导致系统不稳定或者长时间宕机,因为硬件问题很难预测,并且可能需要很长时间才能解决。 通过IaaS,客户虽然仍需要做一些工作来对抗硬件故障发生的风险,但不再需要知道如何修复硬件, 相反,可以简单地在几分钟内申请到新机器实例,并重新安装应用程序,从而限制了这些问题的风险。

3.降低基础设施成本
在大部分情况下,当您考虑电源、网络等成本的时候,EC2实例的成本比运行自己的硬件便宜,尤其是当您只想临时需要运行主机几天或几周而不是几个月时。

4.灵活扩展
考虑到IaaS带来的扩展优势,基础设施成本显着下降,通过IaaS,公司在扩展其运行的服务器的数量和类型方面具有更大的灵活性, 不再需要提前几个月预先购买10台高端服务器,相反,您可以从一个或两个低功耗,廉价的实例开始,然后随着时间的推移逐渐扩展您的实例数量和类型。

5.交付时间短
在托管服务器的旧时代,为新应用程序采购和配置服务器可能需要数月时间。 如果你想出新的想法,并且希望尽快尝试一下,在传统的方式下很难办到。 使用IaaS,交付时间从几个月缩短到几分钟。
基础设施外包
使用 IaaS,本质上我们可以认为是基础设施外包的技术。 当我们开发和运营软件时,我们需要做的工作大致可以分为两类:一类是针对需求需要定制的工作。另外一类是和其他公司都差不多,比较通用的工作。
基础设施就是属于第二种,其范围包括物理的设备,例如运行我们机器,电路,网络等,也包括一些通用的软件功能,比如用户认证。
基础设施外包通常可以由服务提供商(SP)提供。 例如,电力由电力供应商提供,并且网络由互联网服务提供商(ISP)提供,他们通过 2 种模式来减低成本和提高效率:规模化和技术创新。

规模化
几乎所有形式的基础设施外包都通过规模化的模式来降低成本,把大量工作打包在一起批量做,成本比单独一件一件做,效率大大提高。例如,AWS 可以以远低于小公司的价格购买相同规格的服务器,因为 AWS 一次性购买成千上万的服务器,而不是购买几十台服务器。 同样,AWS 的每台服务器运营成本远低于自建 IDC 的公司。

技术创新
基础设施外包通常也部分归因于技术创新。比如 EC2,是通过硬件虚拟化的技术来实现的。在IaaS出现之前,一些IT供应商已经开始允许公司来按月租用物理服务器。显然,EC2 的按小时租用主机的方式更具吸引力,而且,虚拟化技术可以将物理服务器细分为许多更小的,快速启动和关闭的虚拟机(VM),这样 IaaS 才变得可行。
基础设施外包与 IaaS 的五大好处完全一致:
• 降低人工成本 :减少人员,减少维护基础设施工作所需的时间;
• 降低风险 :消除了一部分对特殊技能专家的需求,并且能够获得及时的运营支持能力;
• 降低资源成本 :同样功能的成本更低;
• 提高扩展的灵活性:可以访问更多资源和不同类型的类似资源,而不会造成重大损失或浪费;
• 缩短交付周期:缩短从新想法到生产可用性的交付时间;
当然,基础设施外包也有其缺点和局限性,我们将在后面的部分介绍。

云计算的发展
云计算的发展是从IaaS开始的,比如EC2和AWS Simple Storage Service(S3), AWS是云计算早期的推动者,紧随其后的还有微软、谷歌、阿里云等。当我们谈论“云”时,我们通常指的是公共云,但是,我们也看到了私有云的市场发展的也不错,比如OpenStack。
公共云之后的另外一个潮流是PaaS,Heroku是当时最受欢迎的PaaS厂商之一, PaaS层面置于IaaS之上,将操作系统(OS)添加到外包的基础架构中,使用PaaS,您只需部署应用程序,云平台负责操作系统安装、补丁升级、系统级监控、服务发现等。
Heroku是公有云服务,Cloud Foundry是PaaS的一个私有云版本, 由于PaaS位于现有虚拟化解决方案之上,因此您可以在企业内部部署或者在IaaS公共云服务上部署“私有PaaS”,同时使用公共云和私有云通常被称为混合云, 能够在混合云环境中实现一个统一的PaaS平台对企业特别有用。
在虚拟机之上使用PaaS的最新方式是使用容器,Docker在过去几年中变得非常非常受欢迎,因为它可以从操作系统开始,更清楚地描述应用程序的系统需求,而管理/编排容器的云服务,通常称为容器服务(CaaS),比如Google的Container Engine和AWS的ECS。 一些私有云的CaaS是Kubernetes和Mesos,您也可以把它们搭建在公共IaaS或者私有IaaS之上运行。
就像IaaS一样,PaaS和CaaS都是基础设施外包的另外一种更加高级的形式,它们和IaaS的主要不同之处是,有更高级别的抽象性,允许我们将运行应用的更多技术细节交给云平台,因此,PaaS和CaaS带给我们的好处,与我们之前列出的IaaS的五个好处完全一样,所以,我们可以将所有这三个(IaaS,PaaS,CaaS)组合为计算即服务(Compute as a Service)。
**
Serverless时代到来**
前面解释了半天云计算的发展史,主要就是想引入主题——Serverless。它将会是云计算演进的下一个重要技术,也是另外一种形式的基础设施外包,它同样具有我们已经看到的云计算的五大优势,云厂商同样也是通过规模化和技术创新来提供这些优势。

Serverless 并不等于 FaaS
大部分人开始了解Serverless时,会有一个误区,以为Serverless就是FaaS,比如AWS的Lambda,Google的Cloud Function。但深入研究就会发现,Serverless实际上涵盖了一系列技术,我们将这些技术分为两类:Backend as a Service(BaaS)和Functions as a Service(FaaS),所以,简单来说Serverless=BaaS+FaaS。

BaaS
BaaS就是用现成的第三方服务替换原来自己编码实现或者自己搭建的服务器端组件,它在概念上更接近于Software as a Service(SaaS),不同之处在于SaaS通常是关于外包业务流程,比如人力资源或销售工具,或者像Github这样的服务技术工作者的产品。然而对于BaaS来说,实际上是将应用程序分解成更小的组件,并将其中一部分组件用第三方提供的服务来完成,这个第三方服务通常就叫做BaaS。
BaaS服务是通过API远程调用的组件,而不是SDK,或者Library,我们通过远程API的调用,来完成应用程序的一部分功能。这里有一个很好的例子是身份验证,许多应用程序通过自己的代码来实现注册、登录、密码管理等功能,但是这些代码在很多应用程序中非常相似,同样的事情无数的公司和团队做过了无数遍,已经非常成熟了,可以把它们抽象出来变成一个第三方公共服务再好不过,这正是Auth0和亚马逊的Cogono等产品的目标,这两种产品都允许任何人,不需要写一行代码的情况,就可以在移动应用程序和Web应用程序上实现非常完善的身份验证和用户管理功能。

BaaS最早的时候,在移动应用程序开发中特别受欢迎,一开始人们甚至把它叫做Mobile Backend as a Service(MBaaS),但是实际上,BaaS除了被用作移动应用的后端服务之外,还可以应用到非常多的场景,比如我们可以不需要自己搭建和维护Mysql实例,而是使用亚马逊的RDS服务,或者可以用Kinesis替换自己搭建和管理的Kafka消息队列,其他数据基础设施服务包括文件系统、对象存储和数据仓库、语音分析、以及我们之前提到的身份验证,这些服务都是BaaS,都可以作为一个应用的后端服务的一部分。

FaaS
Serverless的另一半是FaaS, FaaS是Compute as a Service的另一种形式,概念上容易混淆的地方在于,AWS有时候将自己的FaaS服务,Lambda,称为Serverless Compute。
FaaS是一种构建和部署服务器端软件的新方法,只不过粒度更细,能够独立的部署某一个函数,许多人认为Serverless就是FaaS,但是实际上并不完全正确。
我们通过传统方式部署服务器端软件时,从主机实例开始,通常是虚拟机(VM)实例或容器(参见下图), 然后我们在主机中部署应用程序,如果主机是VM或容器,那么应用程序是一个操作系统进程, 通常我们的应用程序中的代码实现了一些不同功能的操作,例如,Web服务提供检索和更新资源的操作。

pic2.jpg



FaaS改变了这种部署模式(如下图), 部署模型中少了主机实例和应用程序进程,我们只关注实现应用程序逻辑的各个操作和函数,将这些函数代码单独上传到云供应商提供的FaaS平台。

pic3.jpg



但是,这些函数在云服务托管的服务器进程中缺省处于空闲状态,直到需要它们运行的时候才会被激活(如下图), 通过配置FaaS平台来监听每个函数的激活事件。 当该事件发生时,FaaS平台实例化函数,然后使用触发事件调用它。

pic4.jpg



一旦该函数执行结束了,理论上FaaS平台可以销毁掉实例,不过,通常为了优化性能,会将函数实例保留一段时间,可以被下一个事件复用。
FaaS本质上是一种事件驱动的模型,除了提供托管和执行代码的平台之外,FaaS平台还集成了各种同步和异步事件源,HTTP API网关就是一种同步事件源,消息总线、对象存储或类似于(cron)的定时器就是一种异步源。
AWS在2014年就推出了Lambda,到目前为止成熟度和接受度已经获得大幅的提高,一些公司每天在使用Lambda处理数十亿的事件,到目前为止,Lambda集成了超过20种不同类型的事件源,可以支持各种不同类型的应用程序。
除了AWS Lambda之外,还有其他一些来自Microsoft,IBM,Google厂商的商业FaaS产品,正如我们之前讨论的各种其他计算即服务平台(IaaS,PaaS,CaaS)一样,也有可以运行在私有云上开源FaaS项目,私有的FaaS领域目前比较早期,没有绝对的领先者,一些比较活跃的项目有OpenWhisk、Fission、IronFuncions、Serverless、Nuclio等。

为什么FaaS和BaaS都叫Serverless?
从表面上看,BaaS和FaaS完全不同,BaaS是托管应用程序的一部分依赖组件,FaaS托管应用程序的代码,那么为什么我们把它们放在一起,都叫做Serverless呢?
这里的关键就是不需要管理自己的服务器主机或服务器进程,完全使用Serverless架构的应用程序,将不再需要考虑服务器或者进程,应用程序的所有逻辑。无论您是自己编写的,还是与第三方服务集成的部分,都运行在完全弹性的环境中,状态也采用以类似弹性的形式存储,无服务器并不意味着服务器已经消失,这只是意味着着您不再需要关心它们了。

Serverless带给云计算的重大变化
在云计算过去十年的发展中,我们已经将应用程序的运行环境和通用组件,越来越多的外包给云厂商。Serverless也同样符合这一趋势,主机管理、操作系统管理、资源分配、扩展、甚至应用逻辑的整个组件,都外包给云厂商,在成本和运营效率方面获得了显著的提升。
但是,在应用程序架构方面,Serverless有很大的变化。之前的云计算服务,并没有从根本上改变设计应用程序的方式,例如,当使用Docker这样的工具时,我们在应用程序周围放置了一个更薄的“盒子”,但它仍然是一个盒子,逻辑架构不会发生显著的变化,在云中托管MySQL实例时,我们仍然需要考虑工作负载所需的虚拟机资源,而且仍需要考虑故障切换。

这种情况随着Serverless而发生变化,并且是非常大的变化,FaaS本质上是和传统架构非常不一样的架构类型——事件驱动模型。它的部署方式更加细粒度,以及需要将状态保存到FaaS组件之外,BaaS使我们无需编写完整的逻辑组件,但需要将应用程序与云厂商提供的特定接口和模型集成。
那么,Serverless的应用程序架构到底有什么不同之处,它看起来到底长什么样子? 这是我们接下来要讨论的内容。

IaaS+PaaS+CMP在农商行的体系化建设实践

博云BoCloud 发表了文章 • 0 个评论 • 488 次浏览 • 2019-03-28 11:03 • 来自相关话题

作为全国首批由农村信用社改制的三家股份制农村商业银行之一,江苏某农商行在大力支持经济社会中,各项业务取得了快速、稳健发展,为地方经济发展作出了巨大贡献。 为适应互联网环境下计算资源弹性变化和快速部署等需求,开展云计算架 ...查看全部
作为全国首批由农村信用社改制的三家股份制农村商业银行之一,江苏某农商行在大力支持经济社会中,各项业务取得了快速、稳健发展,为地方经济发展作出了巨大贡献。


为适应互联网环境下计算资源弹性变化和快速部署等需求,开展云计算架构规划,制定云计算应用策略,该农商行携手BoCloud博云,从业务快速迭代、提升资源利用率、信息系统维护等方面,建设强有力的金融云平台。


传统IT架构制肘业务发展

伴随银行业务和服务的拓展,其传统IT环境对资源管理、应用交付、运维管理、成本控制上亟待提升,遇到的挑战如下:

  • IT资源无法统一调度管理,资源利用率较低,自身管控压力较大;
  • 传统虚拟化技术不具备应用快速发布、应用可视化编排等功能,无法快速响应业务需求;
  • 传统虚拟化技术不支持自动弹性扩容,手动扩容耗费大量时间,且闲置资源人工回收效率低;
  • 应用部署时计算、存储、网络资源需要专业人员半自动化选择,导致操作复杂、效率低;
  • 应用的开发部署各有各的开发管理流程,配置混乱,无法保证开发、测试、验证、投产的一致性。
我们的解决方案 该农商行为提升经营能力和管理水平,解决影响业务发展瓶颈,提出了建设统一云计算平台的需求。根据以上需求,博云为该农商行建设实施了基于私有云技术的基础设施服务、应用平台服务和统一云资源管理服务:
  • 搭建基于OpenStack框架的IaaS平台,通过云资源管理平台进行异构资源池纳管、配置同步、VMware管理、虚拟机运维管理等,提供计算、存储、网络的虚拟化能力和平台自动化管理能力。
  • 选择基于博云BeyondContainer容器PaaS云平台,构建以容器Docker+Kubernetes技术为核心的PaaS平台,保证多环境一致性,通过容器管理平台完善应用运行态管理功能,支持应用弹性伸缩、高可用等能力,以容器化应用的CI/CD能力,支撑DevOps落地,实现应用弹性伸缩、快速迭代发布;
  • 选用博云BeyondCMP云管理平台,建设统一云资源管理平台,对所有IT资源实现统一纳管、统一运维、统一运营,包括对现有VMware、新建OpenStack平台的多平台统一纳管,以及对x86物理机统一纳管,形成对多种异构资源的集中资源纳管的能力;BeyondCMP云管理平台也提供充资源流程自助服务功能,可快速按需获取资源,实现对云与非云资源的统一运营管理;且平台可对云平台物理机、虚拟机状态、资源进行监控以及报表生成,帮助决策和审计,实现IT资源和服务的运营管理统一化。


价值收益


1.实现快速IT资源交付

在新业务系统上线前,利用基于模板的虚拟机置备技术和自服务模式,只需数分钟即生成新业务系统的运行环境,交付能力大大提升。


2.更好的业务连续性,更高的资源利用率

通过弹性伸缩、故障自动迁移等技术手段,实现突发性业务暴增时的资源自适应供给,以及计划性业务周期运行时的资源自适应调整和偶发性IT资源故障时的资源自动化补充,实现更高的资源利用率。


3.应用容器化,弹性支撑高并发业务场景

基于Docker容器技术的PaaS平台,支持互联网类的业务的生产环境应用。目前手机银行的营销中心服务已率先运行于生产容器平台中,并且能适应高并发下自动弹性扩容、缩容,可以及时响应高并发等新型业务需求。


4.制定规范,提升速度

博云BeyondContainer容器PaaS平台提供标准化、容器化的中间件组件服务,使各个应用的开发和运行更加便捷与规范。


5.资源统一纳管、统一运营、统一运维

BeyondCMP实现了异构资源的统一,完备生命周期监测、管理与部署调度,对基于底层各类设备生成的各类业务实现统一管理;对云和非云资源的服务实现自助化管理,发挥云平台快速按需获取资源的优势,提升整体效率、减少自身的管控压力;通过平台掌握各个业务部门的云资源使用情况,实现IT资源和服务的运营管理统一化;并通过一体化平台建设实现统一的资源监控管理、自动化运维管理、流程管理等功能,帮助运维管理人员方便有效的定位系统问题,直观快速的诊断和分析问题。


在积极响应银保监关于“十三五”的发展规划监管指导意见下,博云助力该农商行成为苏南及江苏省内农商体系首家推进实施IaaS+PaaS+CMP的农商行,实现了异构资源统一纳管,提升了IT资源服务能力和效率和应用运维管理能力;以创新能力融合业务需求,助力该农商行数字化转型;也为未来该农商行整合当前IaaS、PaaS整体平台,推出面向内外部使用者及行业的SaaS服务能力,进行更多可行方案的探索。

容器环境应用一键拉起实践

大卫 发表了文章 • 0 个评论 • 931 次浏览 • 2019-01-18 20:43 • 来自相关话题

#背景 ##PaaS平台 基于唯品会Noah云平台,我们已经在内部研发环境建立了一整套PaaS基础设施,实现对开发和测试过程的支撑。通过PaaS平台上的CI/CD流水线,实现了从代码到镜像到环境部署的整体流程;通过自研的环境管理功能(P ...查看全部
#背景
##PaaS平台
基于唯品会Noah云平台,我们已经在内部研发环境建立了一整套PaaS基础设施,实现对开发和测试过程的支撑。通过PaaS平台上的CI/CD流水线,实现了从代码到镜像到环境部署的整体流程;通过自研的环境管理功能(Pandora),实现了对多种不同内部开发测试部署环境的管理,支撑业务快速创建部署环境和利用容器镜像拉起应用,提高业务开发效率。
01.jpg

如上图所示,我们的PaaS容器部署环境目前分为功能测试环境,联调测试环境和回归测试环境三大类,其中功能测试环境包含了多个有业务开发灵活实时创建的隔离环境,用于功能验证使用,而联调和回归环境部署了所有可以上云的应用,用于各类应用的集成大联调以及上线前的回归测试验证。各个环境间通过Kubernetes的namespace进行隔离,同时在微服务应用级别也通过我们微服务基础设施提供的分区功能实现逻辑上的配置和路由隔离,从而基于同一套Kubernetes集群提供面向业务的多个逻辑上独立的环境。
##功能环境与基础设施
针对功能环境的管理,PaaS平台的Pandora组件通过图形化的配置界面,对用户隔离了Kubernetes平台的各项细节,在Noah云基础上极大的简化了Kubernetes上的应用部署和管理。主要提供了以下功能:

* 逻辑隔离环境的管理;
* 应用镜像的部署,参数化配置和应用实例管理;
* 基础资源服务拉起:在Kubernetes集群中为单独环境独立拉起Memcached,Redis,MySQL等服务;
* 基础组件设施的集成和管理:为了支撑微服务应用生态,我们有配置中心,消息中间件服务,数据库中间件服务等。这些基础服务通过逻辑分区的方式可以灵活的提供独立环境支持;
* 服务路由管理:在微服务架构下,为实现一个功能链路,单独一个应用是无法独立完成的,往往是需要依赖与其它的应用服务。被依赖的服务可以在环境内部直接访问,或者通过环境依赖的配置将请求动态路由到其它预先指定的环境内的应用(这里除了功能环境,当然也包含联调和回归环境,最大层度的重用已有服务)。

2.jpg

##实际问题
尽管通过PaaS平台的Pandora图形界面极大的简化了在环境创建和应用部署管理工作,应用本身的部署依赖不是单单依靠容器的编排可以解决的问题。

通常我们部署一个容器化的应用前,需要为这个应用在配置中心创建/修改相关的配置,需要为隔离环境开通消息服务,需要准备新的数据库、Schema和初始数据或Redis容器实例为独立的应用服务,等等一系列的操作。

对于一个应用的业务测试部署人员而言,这些信息相对容易获取,但是其他人需要在一个环境中部署自己或其它开发组织开发的应用用于测试和联调时,就必须依赖阅读现有文档或者需求其他人的帮助以便正确配置依赖的基础服务,这同时也是一项比较耗时和容易出错的工作。这些准备工作往往会占用比部署应用本身更多的时间和精力。

我们希望达到的目标是能够非常快速的和可重复的一键拉起环境和应用,自动化的解决各项依赖问题,从而极大的减少人工工作,使得业务开发专注于业务的创新,从各项环境部署和管理工作中解脱出来,提高工作效率。

对于一个自动化的部署流程,我们期望是可以在分钟级别完成整套独立环境的创建,各项基础服务的开通,数据资源容器的拉起和数据初始化以及应用的启动。并且整个流程的执行是可以动态创建和监控的,从而可以同时作为一个工具服务提供给外部自动化测试以及软件工程管理系统使用。
#应用场景
对于一键拉起功能,主要有三大应用场景和阶段:

* 应用的开发和集成测试环境:通过版本化的环境定义,自动创建环境和应用以及相关数据服务和Mock服务,从而实现组件自动化测试中的全自动化部署。
* 软件项目的生命周期自动化的一部分:将实际测试环境管理创建工作从开发和测试团队工作中分离出来。开发测试只需要定义软件相关依赖和配置,各种环境完全根据配置创建出来,并且在项目结束后自动回收。作为整体项目周期,实现从项目创建开始,关联代码repo和分支,代码质量,部署配置,自动化测试,软件部署环境以及项目结束周期。
* 基于Noah云的整体CI/CD流程关键支撑:通过将版本化的环境定义作为单一数据源,实现研发测试流程中环境的创建测试验证过程中配置数据的管理标准化,进而打通测试完成发布上线步骤的配置变更自动识别生成对比,实现和推动全CI/CD流程自动化。

目前我们主要关注的是第一部分,即应用的开发和集成测试环境的快速自动化环境,用于简化开发测试阶段的环境管理。
##一键拉起与开发/集成测试环境
目前在业务团队中,开发与测试还是遵循比较传统的分工方式:开发完成代码修改,在测试环境或者本地完成简单功能验证后提交测试部署和完成测试验收。其中的自动化过程主要有单元测试,集成测试和系统测试。通常开发只负责单元测试和部分可在本地运行的集成测试自动化,其余涉及数据准备和环境部署的测试代码通常由测试团队完成和维护。

当我们需要一个敏捷团队以最快的速度来交付稳定的产品时,这种模式无法很好的帮助我们的业务开发团队在保证高质量的同时提高交付速度:

* 测试开发分离,需要更多的沟通和协调;
* 可用环境有限,提测需要排队,多个不同功能分支无法并发执行测试;
* 反馈周期长,开发阶段不能发现的问题需要等到提测合并到发布分支后才能得到反馈。

相对传统单元测试而言(更多偏向于单个类/文件本身逻辑的测试),目前更多的测试用例实际上是类似集成测试的,对于环境包括数据库、缓存以及其他服务有一定的依赖。这种模式下相应带来的好处在于我们可以更多的按照实际业务流程以BDD(Behavior-driven development)的方式来进行测试设计开发,专注于重要的业务需求。这也要求开发人员能够更多的参与到自动化集成测试用例的设计与执行过程中去,从而更快的获取测试执行结果,了解和解决出现的问题。

目前的自动化测试运行分两类:

* 类似单元测试,但是依赖数据库/缓存和简单mock服务运行:共享外部数据库资源,没有隔离,容易发生冲突,需要协调;
* AutoV集成测试,需要本地启动数据库/缓存以及依赖的服务或mock来运行:本地资源占用大,运行和调试比较费时,速度和体验不佳。

对于开发阶段,单个应用的自动化集成测试,主要需要关注的问题包括:

* 测试环境应该尽量只包含待测应用和相关基础服务依赖,如数据库、缓存等,其余需要依赖的服务尽量以mock形式配置,减少不确定性和环境复杂性;
* 测试环境可以随时可重复的创建和销毁,保证环境和测试的可重复性以及有效利用资源,更多的运行测试;
* 应用的行为可以通过参数化的方式来配置或者实时控制(例如通过配置中心下发配置改变应用行为)。

同样,对于同一产品线下面多个应用的集成测试也是需要遵循类似的原则,保证环境的可重复创建性以及通过Mock来隔离外部的依赖。

通过一键拉起方式管理环境,可以极大的简化环境的部署配置工作,让一般比较少接触应用部署的开发人员也可以方便快速的获取单独的开发/测试环境,进而推动和方便开发人员编写和运行更多的自动化测试用例,尽早发现问题,提高整体的交付效率。
#解决方案与工作流程
要解决实际使用中的困难,统一定义和维护一套适配唯品会应用基础设施实际情况的标准化应用模型是首先需要解决的问题。我们的应用模型具体会体现为应用描述的yaml文件,可以单独和自动化测试工程保存在git repo中,也可以与应用包和镜像的版本关联,保存到应用目录服务中,从而和应用一起实现版本化的同步管理。

针对我们的实际情况,应用会需要部署到不同的环境中,在不同环境需要对应用的配置按需调整,所以我们需要将应用部署描述和环境部署描述做一个分离,从而实现应用和环境描述的解耦,通过环境对应用的引用来自动化的动态组合各个应用。

对于单个应用而言,部署时除了标准的容器CPU/内存需求之外,还会有如下应用相关的配置元素:

* 应用启动需要的环境变量配置;
* 应用在配置中心的各种变量配置;
* 应用需要创建的消息队列;
* 应用需要消费的消息队列;
* 应用对于数据资源服务的要求:MC,Redis,MySQL以及通过数据中间件接入的配置;
* 应用对数据库Schema/初始数据的配置。

3.jpg

相应在部署阶段,会有对环境的描述要求,包括:

* 环境基础服务的依赖;
* 环境资源服务:是否有公用资源服务,还是需要单独拉起资源使用,资源如何分配给每个应用;
* 环境需要部署的应用,版本,系统资源分配;
* 环境依赖信息:额外的域名解析配置,对其他环境服务的依赖,Mock服务依赖。

对于一个最简单的环境部署配置而言,只需要声明需要包含的应用和版本,系统应该自动根据应用部署描述生成环境配置:

* 环境基础服务依赖:预先配置好可用的基础服务集合,部署只需要声明需要哪一组服务;
* 系统资源分配:按应用类型默认值或者使用应用最低要求;
* 资源服务的拉起:按应用描述要求收集汇总,拉起共享服务供应用使用;
* 环境依赖:需单独声明,和环境相关。

4.jpg

整体而言,我们需要实现:

* 通过流水线生成收集版本化的应用描述模板,生成应用目录;
* 基于应用目录,结合软件项目,定义每个项目的环境部署需求,生成环境部署描述;
* 基于应用描述和环境描述自动构建独立部署环境和应用配置:

* 自动关联环境依赖的各项基础服务;
* 自动创建所需数据服务资源,并且与特定应用自动绑定;
* 自动部署应用集成版本到环境,自动处理环境更新;
* 自动处理应用对环境的各项依赖。

##自动化测试的开发和运行
基于以上解决方案,对于开发人员,我们可以比较方便的通过环境描述的声明来快速的获取一个用于开发的部署环境。

在最简单的情况下,通过声明需要的应用版本即可快速创建一个环境供使用。需要依赖的服务,可以通过对Vmock的配置获取Mock服务或者直接在当前环境中拉起实例使用。由于预先提供的应用描述已经包含数据库、缓存等信息,对应的服务也会自动在这个隔离的环境中创建出来,并且初始化完成。

对于本地测试的开发,可以直接连接这个环境运行各项测试用例而不会干扰其他人的工作或者被其他正在执行的测试干扰。

对于持续集成,也可以在代码提交编译通过后自动创建单独隔离环境运行。从而快速的获取反馈,了解修改带来的影响以及是否成功完成。

同时,如果应用已经集成了Flyway的数据迁移工具,流水线可以自动打包相关迁移脚本,从而在环境创建/应用更新过程中执行迁移,保证数据库的自动同步,让数据库版本和应用版本一起管理,减少数据不一致带来额外排查负担。

更进一步,对于开发过程中的联调,我们也不再需要依赖某一个特定环境。对方应用提供一个简单的应用配置放入环境描述以后,我们就可以在隔离环境快速的获取一个用于联调的应用实例,更好的对接口功能进行验证。
#架构与实现
5.jpg

如前所述,我们在Pandora环境管理应用中实现了一键拉起的功能并且结合应用目录服务提供给脚本,项目管理工具和自动化测试使用。应用部署功能主要通过Noah提供的API实现容器镜像部署,同时也通过监控Kubernetes事件来实现应用和服务启动过程的跟踪,驱动整个环境拉起工作流。
##核心功能设计与实现
一键拉起的整体基于Pandora已经实现的环境管理功能,核心部分在于通过应用模型和环境模型的解析,根据声明和依赖动态生成环境、应用拉起工作流,进而通过对工作流任务的并发和顺序执行,完成资源准备,服务开通和应用部署等各项任务。

相对于目前公用云和各项开源软件提供的服务,一大优势在于用户无需显式的关注一个应用或者一组应用的初始化过程,仅仅需要按照标准模型来描述应用和部署环境要求,系统会自动确定各项任务的执行顺序和并发执行能力,以最快的路径来执行应用部署流程。

对于应用的版本更新,原理是一样的。用户只需要提供一个环境中应用的最终版本要求,系统会自动对比差异,确定需要重新部署或者重新启动的应用,自动完成环境更新。
6.jpg

##事件监控与分布式处理转发
工作流的执行是一个异步过程,因此我们需要一个事件管理机制来实现事件的统一处理和转发。这里的事件包含多个事件来源:

* Kubernetes Events:数据基础服务容器和应用容器的启动监控
* 服务调用完成事件:各基础服务初始化,数据初始化等事件
* 流程管理事件:比如取消流程执行等处理

我们使用Apache Kakfa作为统一的事件总线,多个Pandora流程调度器实例会订阅该事件Topic,各自实现对当前实例内管理的流程的处理。从而可以实现动态的扩容,无需担心大规模使用后流程的分布式管理问题。
7.jpg

##数据库的初始化与版本管理
数据的管理通常是比较复杂的。不同应用会采取不同的方式来管理Schema和初始数据。我们也提供了多种方式来兼容不同的数据管理机制,包括:

* SQL脚本;
* 从集中的数据Schema治理系统获取数据Schema;
* 基于Flyway的数据自动初始化和数据迁移管理工具。

从初始数据的注入来看,由于有些应用没有很好的维护数据脚本,通常需要从一个基础的测试数据库导出初始化的SQL脚本。这种情况下数据集通常会比较大。我们在初始化执行过程中进行了优化,采用批量提交执行的策略,能够快速的批量导入数据,降低数据准备时间。
#总结与使用实践
在完成核心功能开发以后,我们和一个业务小组联合对实际经常需要同时部署的一组应用做了试用和验证,总体而言比较好的满足了复杂应用部署的要求。

这一组应用的基本情况如下:

* 多个应用域(7~20个),需要在同一个环境部署实现端到端的验证;
* 资源服务配置复杂,目前维护了众多的虚拟机:

* MySQL,多达128个分库。初始数据多达18000行SQL;
* Redis:单实例/Sharding/Cluster配置并存;
* 数据库中间件:不同应用多项服务注册使用,并且有不同应用共用同一服务的情况.

* 消息队列服务众多,往常需要逐条Channel/Queue进行配置;
* 环境变量配置工作繁重:包括多个MySQL分库,Redis实例的配置信息;
* 经常需要切换各个应用配置适应不同测试场景。

我们从现有部署环境导出了应用描述以后,经过简单定义修改数据服务相关描述,快速实现了在6~7分钟内完成所有数据库实例的初始化和应用的配置和启动,并且该过程是可以重复执行的,也就是说可以非常方便的随时根据测试场景要求快速准备出测试环境,无需手工维护各项配置和应用。对于应用版本更新,由于各基础服务已经存在,我们只需要创建新增的基础服务以及重新部署应用,可以在1~2分钟内完成。

原文链接:https://mp.weixin.qq.com/s/uug7xeawWLQKXGxeXm5wkw

领域输出才是 PaaS 的核心竞争力

shaowenchen 发表了文章 • 0 个评论 • 727 次浏览 • 2019-01-13 20:57 • 来自相关话题

1. 我在思考什么 在大公司,有更多机会了解行业动态,参与行业变革。 大平台的运行,不是依靠某一个人或几个人。如果这样真的能实现,那也就不能称之为大的平台。一个萝卜一个坑,各自分工,相互协同,才是现代的管理方 ...查看全部
1. 我在思考什么

在大公司,有更多机会了解行业动态,参与行业变革。

大平台的运行,不是依靠某一个人或几个人。如果这样真的能实现,那也就不能称之为大的平台。一个萝卜一个坑,各自分工,相互协同,才是现代的管理方式。

平台做得好,有影响力,个人也会有加持。但常常会陷入一种认知误区:将平台的能力当作自己的能力。而实际上,自己只是负责其中一个小的模块。如果自己不主动学习、思考平台的框架设计,认识不到价值密集区域,那么平台的能力也就和自己无关了。

非常幸运,我有机会参与一场 ToB 的 IT 基础架构的技术变革。在平台产品取得成功、获得影响力时,我也在不断思考,平台的核心竞争力在哪里,如何继续扩张将影响输出到其他行业。下面的内容,就是我给这些问题的答案。

2. SaaS 的特点

SaaS 是通过随时可达的方式,直接对用户提供服务的互联网软件。常见的 SaaS 有在线邮箱、笔记、办公套件、CRM、ERP 等。

# 2.1 从产品侧看

多租户。SaaS 通常是一套软件,服务所有用户。多租户模式,压缩了 SaaS 提供商的运营成本。但为了保证租户数据的安全,需要对数据进行隔离。不同的租户使用不同的数据库实例,或者通过租户 ID 的外键,对数据进行过滤。

可定制。一套通用的 SaaS 不能够满足全部客户的需求。SaaS 提供商通常会提供一些配置给客户使用,甚至直接针对客户进行定制化开发。

面向企业。虽然有提供给个人使用的 SaaS ,但是 SaaS 主要是面向企业的。ToC 的 SaaS 收费困难,通常仅能通过广告获得一定收益。ToB 的 SaaS ,天生具有盈利基因,很容易就能收支平衡。这是由于,SaaS 通常提供的是工具、效能服务,企业更愿意为提升生产效率付费。

# 2.2 从开发侧看

质量要求高。ToC 产品出了问题,只能通过官方渠道投诉,然后不了了之。但是 ToB 不一样。企业会找到售后,处理不好,会直接影响合作是否继续。

无状态。为了能够平行扩展,满足租户不断增长地性能需求,SaaS 应该是无状态的。通过异地多机器部署 SaaS 实例,分担不同租户的访问请求。将缓存、持久化、消息队列等状态,全部使用集群的方式存储,对 SaaS 提供服务。

开发框架。SaaS 需要统一的开发框架。开发框架提供的公共模块,能够减少开发量、学习成本,加快定制化开发的速度。

功能性 API。通过 API 调用,SaaS 的能力边界会被扩大。发送通知、在线支付、查询地理位置等,如果让 SaaS 实现这些功能,需要消耗大量时间,同时还不能保证质量。因此 SaaS 依附的平台应该提供相应的 API。这些 API 直接影响到 SaaS 对平台的粘性。

3. 为什么要使用 PaaS

这两年多,我的主要工作就是做 SaaS 开发,也参与过少量 PaaS 的开发。我以使用方的角色描述,PaaS 能带来什么,更加合适。

开发框架。正如上面所说的,为了提升开发效率,SaaS 开发者需要开发框架。但 PaaS 提供的开发框架,实际上主要是为了解决一致性的问题。PaaS 在进行部署时,会对 SaaS 进行编译封装,SaaS 得告诉 PaaS 一些必要得信息,比如环境变量、日志格式、启动参数等。

状态服务。由于 SaaS 无状态,PaaS 需要提供 MySQL、RabbitMQ 等公共服务,不同的 SaaS 之间,这些服务又是相互隔离不可见的。

API SDK 包。PaaS 通过企业总线(ESB)或网关(API GATEWAY),提供了大量第三方服务。开发者直接通过 HTTP 请求调用 API,容易拼错参数。通过 API SDK 包的方式,将远程 API 封装成本地函数调用,对开发者更友好。

编译部署服务。提交代码之后,通过点击按钮可以完成 CI/CD 的全过程。

监控服务。PaaS 提供日志查询,进程、服务监控等监控服务。这些指标通常是开发者关心,用来定位问题、优化性能使用。

增强服务。基础的监控服务通常不具备侵入性,对 SaaS 没有影响,但功能较弱,不能满足开发需求。这时,就可以使用增强服务,比如 Sentry、APM、Ceph 等,需要进行配置,才能使用。

正是由于 PaaS 提供了这些公共服务,SaaS 开发者只需要关注代码,实现功能即可。PaaS 带来的是开发、运维、运营效率的整体提升。

4. 如何跨行业迁移 PaaS

SaaS 能对接场景,与营收、成本直接关联。但如果场景无法收敛到足够少,PaaS 会是一个不错的解决方案。



上图是,一个通用的 PaaS 解决方案。

对于 PaaS 平台,Gartner 把它们分为两类,一类是应用部署和运行平台 aPaaS(application platform as a service),另一类是集成平台 iPaaS(integration as a service)。 人们经常说的 PaaS 平台基本上是指 aPaaS,如 Force 和 Google App Engine。甚至衍生出了大量容器即服务的公司,直接提供容器部署服务。

我认为 PaaS 的核心价值在 iPaaS 层。

在我经历的 PaaS 技术变革中,最开始是通过本地目录隔离部署,之后改为 Docker + Slug 部署,现在直接使用的是 K8S + buildpack 部署。实际上,这些对 SaaS 开发者、用户来说,意义不大,反而是 PaaS 开发者获得了更多收益。平台更易维护,资源利用效率更高,对标业界标准等。

aPaaS 层同质化严重。一套好的 aPaaS 可以全行业通用。甚至,我认为 aPaaS 层可以与 DevOps 打通,aPaaS 直接执行 DevOps 流程即可。

但,iPaaS 层不一样。iPaaS 是领域知识密集型的一层。

在运维领域,配置管理,执行作业,都是运维才会接触到的概念。iPaaS 需要将其抽象产品化,通过 API 的方式对外提供服务。

在电商领域,iPaaS 提供支付、物流、商品管理等平台服务,这些细分的领域,需要专业的人员去抽象、合规,最终仅通过 API 的形式对 SaaS 层输出领域能力。

能够将需要长时间高强度训练才能掌握的能力,通过 iPaaS 传到给 SaaS、客户,才是 PaaS 的核心竞争力。

最新版本,请查看这里: https://www.chenshaowen.com/blog/domain-knowledge-is-the-key-of-paas.html

产品技术多方平衡,企业级容器 PaaS 如何满足用户的多样化需求?

tenxcloud 发表了文章 • 0 个评论 • 527 次浏览 • 2018-12-28 17:32 • 来自相关话题

容器 PaaS 从 2015 年初开始技术布道,到吸引众多企业的关注及技术追捧,再到企业的生产环境真正落地应用,经历了 3 年多的时间。这三年,企业从初期技术路线 Kubernetes、Mesos 的选择,到技术、用户需求、产品的平衡,再到面对国内云计算 to ...查看全部
容器 PaaS 从 2015 年初开始技术布道,到吸引众多企业的关注及技术追捧,再到企业的生产环境真正落地应用,经历了 3 年多的时间。这三年,企业从初期技术路线 Kubernetes、Mesos 的选择,到技术、用户需求、产品的平衡,再到面对国内云计算 toB 市场需求越来越多样化带来的挑战。这些都对容器、Kubernetes 及相关技术提出了很高的要求。

为此,TGO 鲲鹏会专访了时速云联合创始人兼 CTO 王磊,请他来分享时速云 PaaS 平台的整体架构及核心技术、遇到的问题和解决方案、以及如何搭建高效创新的技术和产品团队。

微信图片_20181228095313.jpg


时速云联合创始人兼 CTO 王磊

王磊,曾是 IBM 中国开发实验室资深软件工程师,IBM BPM 产品开发组团队负责人,现负责时速云企业级容器 PaaS、DevOps、微服务治理等多个产品、平台及相关解决方案的技术架构、设计和研发管理工作。对容器、Kubernetes 及相关生态技术有较深入理解和研究,致力于通过云计算为企业构建新一代以应用为中心的云原生技术平台。

基于 Kubernetes 打造全新企业级容器 PaaS 平台

TGO 鲲鹏会:能否详细介绍一下时速云 PaaS 平台的整体架构及核心技术?

王磊:目前时速云的产品体系包括企业级容器 PaaS 平台、DevOps 应用交付平台和微服务治理平台,而且结合平台的特点和扩展能力,快速地为合作伙伴的中间件提供云端支撑,比如 BPM、BI、分布式数据库、大数据等相关工具或者产品。

微信图片_20181228150813.jpg

产品整体功能架构

在产品、平台的核心技术或优势上,主要有以下几方面:

  • 对 Kubernetes 部署方式的改善,可以一键部署安全的 Kubernetes 集群,并最大程度保证环境的高可用,相对原生方案部署更简单,可用性更高;所有服务组件都以容器化的方式运行,便于管理、升级,可维护性更好。
  • 操作系统及 Kubernetes 的相关调优,对系统组件资源调配和节点资源预留的把控,保障节点和服务的长时间稳定运行,并经过了多个客户生产环境复杂场景下的各种考验。
  • 通过 Kubernetes 模型 控制器的友好扩展方式,实现了对数据库、缓存、消息队列以及第三方产品的完整生命周期管理,包括创建、集群维护、监控告警、健康监测、配置管理、数据备份恢复、运行指标监控等,由系统按照用户的要求维护其期望状态。
  • 基于 Kubernetes 自研 DevOps 产品体系,使 DevOps 和 PaaS 具备同样的架构背景和技术体系,任何 PaaS 层的经验积累都可以用来在 DevOps 平台上进行运用和创新;提供一致的数据视图,构建任务产生的日志、监控、告警等数据均可以由 PaaS 层统一管控。
  • 在微服务治理方面,实现对 Spring Cloud、Dubbo 等多种微服务框架的融合,减少平台和框架能力之间的冲突,简化工具本身的复杂性;对框架本身进行定制和扩展,满足服务治理层面更丰富的需求。同时,我们开发了云服务总线,用于实现 API 发布订阅、授权、监控和协议转换等能力,也包括 WebService 和 Restful 之间的转化,能够将传统 ESB 上的服务接入,进行统一管理监控,可以作为传统服务向微服务转换的过渡支撑平台。

此外,我们非常注重技术和产品之间的平衡,不断打磨产品设计和用户体验,尽量减少技术门槛的引入。

TGO 鲲鹏会:时速云 V3.0 已经发布半年有余,如何保持产品的研发和技术的创新?

王磊:目前正处于 v3.2 和 v4.0 并行紧张开发过程中,产品的研发和技术创新,简单来说有以下几个驱动力:

以市场需求为导向,同客户进行深入交流,挖掘实际场景下对产品的需求,结合新的技术来满足需求或者解决问题,这其中就会有很多的创新点。

挖掘产品层面可优化的点,努力将产品功能、体验做到极致。

不断跟进社区、生态中的相关技术发展,对产品能力进行快速的开发、迭代和转型,通过新技术推动自身产品和用户业务场景中的创新。

此外,我们还建立了完备的研发战略决策体系、高效的研发流程、人才培养机制等,也会继续加大研发投入,为企业提供更好的产品和服务,助力企业数字化转型。

TGO 鲲鹏会:时速云作为容器云计算服务提供商,其本身的管理运维也是很重要的工作之一。时速云在平台的自动化运维,或者智能化运维上面有什么经验可以分享?

王磊:在打造云原生应用平台的过程中,我们也逐步形成了自己的自动化运维产品体系,并在内部研发部门和企业中都得到了很好的应用实践。具体可以从用户服务、节点、集群、平台等多个维度展开,同时在不减少功能和服务质量的同时,对系统逐步进行简化与技术融合:

  • 服务层面包括故障自愈能力,自定义探针,灰度发布,打散热点二次调度,横向 / 纵向的伸缩,基于监控和日志的告警及行为策略等;通过模型 控制器的方式对集群模式的服务进行自动化管理,提供声明式的资源接口,并由系统维护其期望状态。
  • 节点层面涉及到驱赶策略、自动垃圾回收、故障摘除、运维升级等能力。
  • 集群层面包括日志监控数据的定期清理,平台资源的弹性伸缩,升级、迁移或者故障恢复的工具支撑。
  • 平台层面涵盖系统服务、集群系统组件的监控告警及默认行为策略,相关数据的定时备份及故障恢复;可对历史健康指标进行回溯,统计平台各个服务的 SLA。
  • 构建基于 Kubernetes 的 DevOps 服务,统一数据及管理运维方式。
  • 将微服务框架同 Kubernetes 进行融合,简化系统复杂度和降低管理运维成本。

k8s 及容器生态已经带来了很多新的理念和技术,我们也在围绕 k8s 进行很多自动化运维的相关工作,也希望新技术、新框架的管理运维工作也可以围绕 k8s 展开,既可以构建通用的自动化运维工具和方法,也可以实现各类数据指标的统一收集,为后续 ChatOps、AIOps 打下工具和数据基础。

技术、产品多方平衡,满足用户多样化需求

TGO 鲲鹏会:容器 PaaS 在落地应用过程中遇到过哪些困难,都是如何解决的?能否举一些具体的案例?

王磊:容器 PaaS 从 2015 年初开始技术布道,到吸引众多企业的关注及技术追捧,再到企业的生产环境真正落地应用,也经历了比较长的一段时间,这个过程中也碰到了各种各样的困难。这里从产品技术、市场客户两个方面简单列举一下:

产品、技术方面

初期技术路线的选择,开始一段时间并行尝试 Kubernetes、Mesos 两种方案,以 Kubernetes 为主,半年左右完全停止 Mesos 的相关工作,也让我们比其他厂家少走了很多弯路,有了更多的技术积累,期间也听到一些对 Kubernetes 质疑的声音,过程虽然有一些挑战,但最终我们还是比较幸运的。

作为一个偏技术的平台,需要在技术、用户需求、产品之间相互平衡,需要在不偏离产品方向的基础上,用最合适的技术满足企业市场的用户需求。在面对新的用户需求时,开始会是技术和产品分别进行调研设计,避免相互引导、影响,然后再经过讨论确定最终的产品形态,使研发人员逐步养成产品的思维习惯,产品也有了更多的技术背景,长期来看会减少彼此之间不必要的矛盾,更有利于产品创新。

PaaS 层相对更接近用户的业务系统,所以项目开展过程中难免会接触用户的业务系统,这里面就会涉及到用户应用的配置管理、迁移、改造、各种系统的对接、定制化等相关工作,而这部分的工作根据客户的实际情况可能会带来较高的成本。我们针对不同的场景也逐步积累了一些解决方式,比如在应用迁移时,先整体了解应用的整体架构,尽量将相关服务开发、运维人员聚在一起进行服务容器化和部署调试工作,尤其涉及到跨部门沟通时,前期要做好充分准备工作,必要时再投入研发力量,否则在效率和成本上有很大浪费;在系统对接层面,提供平台完整的 API 文档,在其他平台需要时,可以减少很多的沟通成本。

客户市场方面

新技术、新理念带来的学习成本,以及技术生态的飞速发展带来的复杂性,都给市场、客户的培养带来了很多成本,需要进行很多技术布道和客户培养工作。客户对新技术的追捧有时甚至超过技术公司的研发速度,也对如何快速运用和管理这些新技术带来了挑战。

国内云计算 2B 市场的需求越来越多,同样,进入这个领域的企业也越来越多,竞争日益激烈;而企业在云计算层面还处于初步扩张时期,成熟度还有待提高。在云平台比拼功能(实际使用的功能可能占很少一部分)、抢占市场的大环境下,产品更需要不断的打磨核心能力,在平台可用性、可靠性层面投入更多精力。

TGO 鲲鹏会:您刚才有讲到技术方面遇到的问题,那么目前技术和团队面临的挑战是什么?接下来的重点会放在哪里?

王磊:技术层面主要挑战是如何在新技术快速发展、迭代与企业所需稳定产品之间进行平衡,以及进行长远的技术、产品发展方向规划。左手是多样的、复杂的技术生态;右手是各类行业、众多企业的场景化需求,需要运用合适的技术并尽量通过产品化的方式满足特定用户的需求,有时候会比较头疼。

团队层面,构建一个高效的、快速响应市场变化的研发团队,并保持每个成员持续高涨的技术研发热情,是一件很有挑战的事情,尤其是在一个创业型公司中。后续的重点仍然是继续积累技术和行业经验,发挥团队的力量共同打造具备可靠、简单、自动化、集成扩展、协作等特点的容器 PaaS、DevOps 和微服务治理平台,让用户更快捷、安全的进行云原生应用的实践与创新。

TGO 鲲鹏会:作为 CTO ,您在技术管理上有什么心得可以分享?如何平衡技术和管理的时间?

王磊:作为一名 CTO,越来越感到这个 title 的不易,从个人履历上看比较简单,技术管理方面在外企作过技术 leader,然后就是在创业公司从 0 搭建目前的研发团队,这里跟大家分享三点:

在大公司作技术管理比在创业公司带团队要轻松很多,不同环境下的技术管理方式上会有较大差别。在创业团队,CTO 的首要任务就是招到合适的人,培养技术和产品骨干,使他们尽快成长,成为自己的左膀右臂;其次是技术和产品方向上的把控,在市场上为公司找到最合适的定位,并抢占有利位置,考虑公司业务的可扩展性;再就是研发体系、制度、流程的规范和逐步优化。

另外,CTO 的职责随着公司的发展也会有相应的变化,从开始的全栈工程师、架构师、产品经理、技术布道师,到后來的咨询、售前、解決方案,甚至销售工作,基本体验了各种角色的工作,视野越來越宽广,接触的人越來越多。此時把有限的精力花在人员培养、技术方向把控、研发流程优化、提高研发效率等管理工作上,可以带来更大价值。对于技术和管理的平衡,当企业规模和业务复杂度达到一定程度,我认为管理的重要性更大,也值得投入更多的精力,当然,CTO 一定也要拿得起技术,否则只有 CO,可能就会瞎指挥了。

花更多的精力放在公司、技术、产品的可扩展性和持续发展上,推荐阅读《架构及未来》学习更多的经验和相关案例,对技术管理者有很大帮助。IT 就是这样一个需要持续学习充电的行业,否则很快就会落伍了,我们需要保持对技术的热情,尤其是对当前或者下一个可能技术热点的学习与探索。

本文采访记者| Bella Wu 来源: TGO鲲鹏会

时速云黄启功:容器云PaaS平台将成为IT基础设施重要组成部分

tenxcloud 发表了文章 • 0 个评论 • 607 次浏览 • 2018-12-14 15:02 • 来自相关话题

近日,爱分析在京举办了 2018 爱分析·中国云计算高峰论坛,本次论坛以“云化万物,智动未来”为主题,探讨云计算行业的发展趋势。爱分析邀请了云计算领域标杆公司时速云创始人&CEO 黄启功进行主题演讲。 ...查看全部
近日,爱分析在京举办了 2018 爱分析·中国云计算高峰论坛,本次论坛以“云化万物,智动未来”为主题,探讨云计算行业的发展趋势。爱分析邀请了云计算领域标杆公司时速云创始人&CEO 黄启功进行主题演讲。

黄启功认为,企业采用基于云原生的技术和管理方法,可以更好地把业务迁移到云平台,从而享受云的高效和资源按需供给能力。容器云 PaaS 平台作为云原生在企业的主要落地形态,解决了应用完整生命周期的管理问题。未来,容器云 PaaS 将进一步深入行业应用场景,更好地支持企业数字化转型。

现将时速云创始人&CEO 黄启功的主题演讲实录与大家分享。

01演讲实录

黄启功:大家好!首先做一下自我介绍,我是时速云 CEO 黄启功,感谢爱分析的邀请,我今天分享的主题叫“云原生应用实践与未来趋势”。

云原生既包含技术(微服务,敏捷基础设施),也包含管理(DevOps,持续交付等),是一系列 Cloud 技术、企业管理方法的集合。企业采用基于云原生的技术和管理方法,可以更好的把业务迁移到云平台,从而享受云的高效和按需资源能力,而容器云 PaaS 平台则是云原生应用重要的落地形态之一。

企业在数字化转型中普遍面临IT系统架构缺乏弹性,业务交付周期长,运维效率低,高可靠性低等痛点。企业可以通过云原生的一系列技术,例如基于容器的敏捷基础设施,微服务架构等解决企业面临的这些IT痛点。

02云原生的三大特征

2.jpg


云原生应用架构包含三个特征:容器化、微服务和 DevOps。

容器其实已有10来年的历史,2013年开源的 Docker 容器引擎,被开发者所广泛熟悉,到如今发展成为包含容器云 PaaS 等一系列商业化应用实践。

3.jpg


容器技术具有占用资源少、部署快、易迁移等特点,容器可以理解为隔离环境的“运行时”,这也很好诠释了 Docker 集装箱的理念 --- Build, Ship and Run。容器看做是一个简易版的 Linux 环境(包括root用户权限、进程空间、用户空间和网络空间等)和运行在其中的应用程序。

云原生价值的最大体现之一在于对企业 DevOps 的支持,它将企业开发运维部门很好地结合起来,以前企业的开发、测试、运维是相互割裂的状态。我们所提倡的 DevOps 理念将打破开发、测试、运维部门之间的隔阂,让整体的应用交付变得更快速。从技术角度看,DevOps 涵盖了应用的开发、编译、构建、测试、打包、发布的自动化流程,并包含了很多 DevOps 工具链。

4.jpg


云原生的第三个特征是微服务,微服务是一种架构模式,它提倡将单一应用程序划分成一组小的服务,服务之间互相协调、互相配合,为用户提供最终价值。每个服务运行在其独立的进程中,服务与服务间采用轻量级的通信机制互相沟通(通常是基于HTTP的RESTful API)。以往企业应用主要是面向服务的架构(SOA),SOA 是一种粗粒度、松耦合服务架构,服务之间通过简单、精确定义接口进行通讯,不涉及底层编程接口和通讯模型。它的缺点是架构重,难以利用云的一些特点和优势。微服务倡导细粒度的轻量级应用架构,每一个服务相对独立的,具有轻量级、易迁移、更高效等特性。


03容器PaaS的特点及优势

容器云 PaaS 平台是云原生在企业重要的落地形态之一,它包含了 PaaS 本身,以及 DevOps、微服务等。

在 IDC 的时代,用户需要管机房、物理机、包括网络、业务应用。上云之后,我们简化了这种资源的交付流程,用户获取计算、存储、网络资源变的更简单。

5.jpg


发展到 PaaS 的时候,用户不需要去关心底层的基础设施,只需要专注业务应用本身,容器 PaaS 以应用为中心,标准化、自动化应用的构建(Build)、交付(Ship)、部署运行(Run)流程,支撑应用的完整生命周期管理。通过容器云 PaaS 提供的丰富基础服务及之上的 SaaS 服务,提高 IT 设施自服务能力以及新业务的交付效率。

PaaS 最早其实是跟 IaaS 同步发展的,2011年时,国内出现了很多 PaaS 平台,包括 SAE、BAE等。第一代 PaaS 侧重提供支撑应用运行的应用引擎,我们现在所说的容器云 PaaS,则是基于云原生理念,融入 DevOps、微服务,解决了应用的完整生命周期管理问题。

6.jpg


Kubernetes 是容器云 PaaS 平台的基石,它是承载整个 PaaS 的核心。Kubernetes 是 Google 开源的一个容器编排引擎,它支持自动化部署、大规模可伸缩、应用容器化管理。Kubernetes 未来将会成为企业的云基础设施的重要组成部分,它的目标是让用户快速、简单的开发适合自己的 PaaS 或者 DevOps 平台;随着容器技术的普及,将会有越来越多的企业基于 Kubernetes 作为大规模容器的调度管理引擎,并结合自身的优势打造适合企业的 PaaS 平台。

04云原生应用的趋势

关于如何实施云原生,这里简单给大家做一些参考,首先需要对企业 IT 内部有清晰的规划,结合企业自身的 IT 业务体量。很多互联网公司通过开源的 K8S 也能简单支持一些非核心业务,构建容器 PaaS 还需要考虑一些流程,包括前期的无状态服务迁移,后期有状态、重状态的服务。

7.jpg


最先得到商业验证的是 IaaS 和 SaaS,这符合市场客观规律。在云计算进入商业成熟期时,竞争将回归到效率和成本。PaaS 本质上是云计算模型中的能力层,让客户以更高的几率赢得竞争。PaaS 把构建上层应用场景的能力抽象化,降低重复造轮子的风险和成本。基于 K8S 的 PaaS 以应用为中心,容器技术大放异彩,将会成为未来 IT 基础设施的重要组成部分。

根据 Gartner 数据显示,在 IaaS 和 SaaS 逐步成熟的时候,企业越来越强调效率提升,而 PaaS 属于云计算的能力层,已迎来了一个非常好的发展时机。

8.jpg



根据 Google Trand,我们可以看到在去年7月份的时候,PaaS 和 IaaS两大代表性的开源项目的活跃度对比,Kubernetes 的活跃度已经超过了 OpenStack,目前仍处于快速发展阶段。

9.jpg



接下来,随着 DevOps 的深化、普及,将会形成更加标准化的应用交付流程。PaaS 会逐步弱化 IaaS 层的一些概念,在某些需求场景下甚至舍弃 IaaS,在物理资源上直接部署 PaaS。微服务、服务网格、APM 等应用侧工具逐步繁荣,用户的重心向业务架构及其治理方向转移。

随着云的类型增多及其复杂性的增加,多云管理、云管平台也会出现强烈需求,另外用户对“云原生”的更多理解,会带动新的开发模式、开发框架的产生,比如 Serverless 等。

文章来源:爱分析

石油巨头如何与Kubernetes, DevOps共舞?

灵雀云 发表了文章 • 0 个评论 • 727 次浏览 • 2018-12-05 11:08 • 来自相关话题

近日,中国石油自主知识产权的勘探开发梦想云(E&P Cloud)平台V1.0在京隆重发布。作为支持梦想云落地的唯一容器 PaaS 和云原生技术领域合作伙伴,灵雀云凭借强大的技术实力和卓越的服务能力,协助中油瑞飞全程深度参与了梦想云 PaaS 平台的建设。 ...查看全部
近日,中国石油自主知识产权的勘探开发梦想云(E&P Cloud)平台V1.0在京隆重发布。作为支持梦想云落地的唯一容器 PaaS 和云原生技术领域合作伙伴,灵雀云凭借强大的技术实力和卓越的服务能力,协助中油瑞飞全程深度参与了梦想云 PaaS 平台的建设。


在不久前召开的年度开源技术盛会 KubeCon+CloudNativeCon 上,灵雀云CTO 陈恺携手中油瑞飞资深架构师迟汇发表了以“Big Oil on Kubernetes and DevOps”为主题的演讲,对勘探开发梦想云平台项目进行了阐述。


演讲分为三个部分:
首先,由陈恺做项目背景介绍;其次,由迟汇介绍基于Kubernetes、微服务和DevOps等先进技术和理念的统一技术平台的设计思路和方案;最后,再回到产品和技术,由陈恺介绍灵雀云如何协助中油瑞飞将云原生技术成功落地。
以下为演讲实录:
灵雀云陈恺:


大家好,我是灵雀云的CTO陈恺,今天要为大家分享一下灵雀云为国内最大的能源企业建设企业级PaaS平台的案例。非常荣幸请到中油瑞飞负责DevOps的迟汇和我一起为大家分享,中石油如何落地 Kubernetes 和 DevOps 。

像中石油这样体量的企业,大家可以想象业务环境的复杂和规模的庞大。复杂的业务板块面临很多挑战,比如十几个油田以前没有统一的规划,各自运行自己的IT系统,那么数据就会散落在各个地方,没有办法串联和共享,因此就无法把数据真正地利用起来。从平台级别来看,每个油田也不会做统一的IT平台,难以对上面的业务做统一的支撑。


灵雀云协助中油瑞飞建设的勘探开发梦想云就是应对这些挑战的。在底层我们会建立统一的数据库,把散落在各个油田的各种各样的数据相互之间打通,集中到一起,对数据做一个治理;中间是统一的技术平台,也就是我们今天主要讲到的基于Kubernetes的PaaS平台,这当中主要涵盖三个场景:容器、DevOps和微服务治理,相当于是整个云原生的三个核心要素。


项目的最终目标是建立统一的数据湖和统一的技术中台,在上面解决整个中石油的通用的业务。


那么接下来有请中油瑞飞的迟汇介绍一下中石油项目采用的技术和整体建设思路和方案。


中油瑞飞迟汇:


中石油的DevOps平台主要包含三个模块,第一个模块是DevOps,第二个模块是微服务,第三个模块是容器平台。


我们讲DevOps分为八大体系,分别是项目管理、知识共享、持续构建与测试、持续交付、认证与改进、学习培训、运营统计、运营监控。



pic2.jpg




整个工具链支撑体系中,涉及到的工具是15个,大部分是开源的。



pic3.jpg



下面讲述一下平台建设的部分成果展示。做这个项目的过程当中,形成了14个角色,8个职责,5个权限组。右侧是所有的认证体系,这个认证体系里面我们现在已经准备了6个测试场景,4个课件,有新项目接进来之后我们会对它有一个针对性的培训,最后是一个成熟度的评估。

pic4.jpg




灵雀云陈恺:


下面就让我们回到产品和技术层面,来讨论一下怎么样通过灵雀云的平台,为中石油复杂的业务场景搭建DevOps开发体系的。


先来简单了解一下灵雀云的产品。灵雀云有两条主要的产品线。一个是Alauda Container Platform(ACP), 他是一个高度标准化的,专注于云原生应用管理场景的赋能平台,它本身覆盖了三个场景,分别为容器平台,DevOps和微服务,也是我们云原生技术的三个核心。


pic5.jpg




另外一条产品线是Alauda Cloud Enterprise(ACE),主要面对是大型企业的统一PaaS平台。刚才分享的中石油平台就非常符合这样的场景。


ACE本身包含了ACP所有的能力,在这之上,针对大型企业建设统一PaaS平台的场景的能力又有一些加强。举几个例子,比如说ACE的客户通常来说会有很复杂的基础设施的环境,一般都会有很多个数据中心。一些客户开始尝试公有云的话,不会只用一家的产品服务,最后就会是一个异构的、混合的、跨云的基础环境。我们在每一个数据中心,或者说每一个公有云厂商上面根据他的使用需要去搭建多个K8s的集群。也就是说,管理这些异构、复杂的基础设施以及对多集群的支撑是ACE的核心能力。


在集群管理方面,我们不光可以通过ACE去部署一个灵雀云提供的K8s集群(也就是ACP),我们也可以让用户去导入一个他们已经有的K8s集群,现在我们已经有了一些这方面的实践。


另外一个针对大型企业统一PaaS平台的场景,是企业内部共同的需求。一般来说,企业内部会有几大类职能用户,和我们直接合作的是企业内部的平台部门,这个Team对企业内部的业务部门来说,是云平台的提供者和服务团队。


在此基础之上,ACE典型的使用场景通常来说会有几千个开发者,甚至更多。他们之间也需要根据不同的项目或者不同的部门,去划分出不同的租户,租户内部有团队内部协作的需求,租户之间有一些权限隔离和资源隔离,这也是ACE需要解决的另外一个问题。


pic6.jpg




回到今天的主题DevOps。DevOps是ACE一个核心的模块,在我们跟企业客户了解做 DevOps 诉求的时候,每一家都已经在使用一些工具并且有自己的流程,我们需要把现有的系统进行完善,而不是提供一个封闭式的产品去替代以前用的工具。


所以ACE DevOps 的整体思路,是提供一个开放式的DevOps工具链的集成和编排平台,通过集成之前客户已经在用的,以及需要的新的工具变成一个工具链,然后通过编排把这些工具和平台变成一个整体,最后可以贯穿整个应用全生命周期的管理。ACE的核心价值是将 DevOps 的最佳实践,加以提炼形成一个自动化的平台服务,提供给用户。


DevOps工具链集成一方面需要每个工具通过API集成在我们的容器平台上,另一方面,每个工具和平台的用户权限需要打通。每一个企业级的工具都会有自己的租户模型,这些租户模型和平台本身的租户模型需要有联动和对应。这样平台上的数千个工程师,在不同的项目里面共享这些工具时,会有一定的规范。在ACE中,一些核心场景的主流工具,我们会做深度的集成。在这种情况下,80%以上的使用场景在平台本身就可以完成。


刚才有提到,使用ACE在大型企业内部搭建一个统一PaaS平台,分成两类用户:一个是平台部门,负责搭建、维护平台以及对其他业务部门提供支撑和服务,他是平台管理员;另一个是业务部门,可以理解为企业内部的一些项目,也就是平台上面的一个个租户。在使用上大致的流程是这样的:平台部门准备基础设施,需要去部署和准备一些已有的集群,然后会在平台上面创建租户,并且设置管理员,他可以把集群的资源分给租户。租户管理员获取资源后,可以在集群里面创建环境,可以主动把资源向下派分。


对于DevOps实现来说,管理员可以部署和集成一些工具,然后可以把工具发布出来让租户自行订阅。同时,他也可以给每个工具去创建一些资源,然后主动把这些资源分配给租户。从根部管理员这边获得DevOps工具的资源有三种方式,一是管理员主动分配的,二是开发者订阅了管理员发布的库,第三,开发者也可以在平台上自己部署一个工具。


由于时间关系今天就和大家分享到这里,如果想要了解更多关于灵雀云在各个行业的产品实践,可以会后交流,谢谢大家!

透视云原生热的背后

灵雀云 发表了文章 • 0 个评论 • 741 次浏览 • 2018-10-30 14:02 • 来自相关话题

PaaS热、容器热、Kubernetes热、微服务热、DevOps热,这么多的热汇聚到一起,形成了云原生应用热。云原生应用热与以往众多的技术热潮不同,因为它是由业务需求驱动的,是第一次在信息技术与业务之间产生了化学反应,也是自上层应用开始延伸至底层基础架构的自 ...查看全部
PaaS热、容器热、Kubernetes热、微服务热、DevOps热,这么多的热汇聚到一起,形成了云原生应用热。云原生应用热与以往众多的技术热潮不同,因为它是由业务需求驱动的,是第一次在信息技术与业务之间产生了化学反应,也是自上层应用开始延伸至底层基础架构的自上而下的一场具有颠覆性的变革。



自上而下的变革



“同行是冤家”,这是多少年来不变的商业规则。但是今天,颠覆往往不是来自于行业内部,而同行之间也未必是最直接的竞争对手。银行惧怕的是互联网金融,酒店业正在被Airbnb蚕食,出行不可缺少的是共享单车……



传统企业迫切希望像互联网公司那样思考,采用互联网架构实现应用的快速迭代,服务B端客户时也要像服务C端客户那样注重应用体验。传统企业与互联网企业竞争,非云原生应用与云原生应用竞争,这就是越来越多的企业用户选择云原生应用的原因。

“企业做不做云原生应用,这是由业务决定的。而如何实现云原生,则可以视企业的实际情况选择不同的技术路线。应用先上云再做架构改造,还是一步到位直接采用全新的云原生架构,企业用户要深思熟虑。”

——灵雀云CEO左玥



“云原生应用的兴起与数字化转型的节奏是一致的,是从应用层面开始的。如果不是业务在驱动,云原生应用的发展就不会像今天这么快。”灵雀云创始人兼CEO左玥如是说。


最近两三年,来自业务侧的压力推动着行业的快速发展与转变,金融科技、车联网、新零售,无一例外。生存还是死亡?这在今天看来并不是一道让人纠结的选择题。采用单体架构的企业如果不采用解耦的分布式架构,不采用新的DevOps开发流程,不能像互联网企业那样一天进行200次迭代,而是还像原来那样半年或一年进行一次应用更新,那么企业注定将无法继续生存。从物理机到虚拟化再到容器化、微服务和DevOps,更加灵活的IT架构、更加便捷高效的开发流程,这就是云原生,并不存在什么难以逾越的鸿沟。



左玥认为,云原生架构与传统IT架构之间是替代的关系,云原生架构是传统IT架构的下一步发展趋势。从传统IT架构过渡到云原生架构可能要经历很长一段时间,过渡的方式也有多种选择,既可以采用比较激进的方式,也可以采用循序渐进的方式。比如,因商业竞争所需,企业基于云原生架构重写应用程序,这就是比较激进的方式。采用这种方式,企业一定要下定决心,而且需要投入大量人力物力。这有点像壮士断腕,好处是可以一步跨越到云原生模式,便于以后的开发和应用。



然而对于大多数企业来说,他们不可能中断现有的业务,将全部精力用于打造云原生应用,因此可以采用相对保守的过渡方式,比如可以先将传统应用迁移到云上,然后再选择适合的时机转换为云原生应用。



应用上云与云原生应用,这是两个不同的概念。“企业做不做云原生应用,这是由业务决定的。而如何实现云原生,则可以视企业的实际情况选择不同的技术路线。应用先上云,再做架构改造,或者一步到位,直接采用全新的云原生架构,企业用户要深思熟虑。”左玥表示。



从技术的角度讲,采用了容器、微服务、DevOps就可以称为云原生应用,这听上去似乎很简单,但实际上已经覆盖了从研发到业务流程再到运维的企业IT的全部内容。云原生的概念从雏形到成熟,并得到整个行业的认可有一个发展过程。一开始,企业用户可能只是想通过采用容器、DevOps等加速开发流程,实现应用的快速上线和迭代。到整个行业都在谈论云原生的概念时,很多企业用户才意识到,原来他们正在做的就是云原生应用。



左玥告诉记者,在政府、石化等行业中,一些头部客户正准备在单位内部全面构建云原生应用,规模之大、应用之深有些出乎他们的意料。如今,越来越多的中国企业用户对云原生应用产生了强烈的需求,但在实际执行和实现的过程中可能还存在困惑或者障碍。这也是下一步致力于云原生应用的厂商需要突破的难关。



加速云原生应用的普及



左玥分享了他对全球云原生市场的观察:从时间上看,中国与国外几乎是同时起步,差距不大。但是从现在的普及程度上来看,中国与美国市场还是有差别的,比如两年前美国企业采用Kubernetes的也不多,但现在可能90%以上的企业都在使用。而中国各行业的头部客户虽然也在考虑云原生应用,但只是刚刚开始,还需要一个转变过程。


CNBPA.jpg



云原生技术实践联盟(CNBPA)火了



从用户的角度看,中国的云原生市场还需要教育和引导;从厂商的角度看,大家需要一个沟通和交流的平台,在理念、技术、应用的创新方面还要不断提高。由灵雀云发起的云原生技术实践联盟(CNBPA)近日正式成立,招商银行、中国石油、国家电网、树根互联、中科软、东华软件、北明软件、腾讯云、灵雀云、F5等成为首批创始成员。



左玥向记者表示:“成立联盟并不是一种商业行为,也不是为了制定规范或标准,就是单纯地希望为从事云原生应用的企业、同行打造一个跨业交流的平台。厂商与厂商、厂商与用户、用户与用户之间可以相互学习借鉴。意识和行动超前的用户可以成为学习的榜样,而在业务上各有侧重的厂商之间也可以形成互补,共同打造一个经过测试的成熟完整的云原生解决方案。”在联盟成立大会结束后,参会的很多企业用户主动找厂商索要联系方式,交流和讨论的氛围十分热烈。



在中国,云原生毕竟还是一个新生事物,在落地过程中,不仅技术上有一定门槛,管理上也存在问题。企业如果还守着原来的IT架构,也不改变原有的开发流程、组织架构,那么DevOps就是纸上谈兵。大多数国内企业已经习惯了采用外包或依赖第三方ISV。因此,在中国推动云原生应用的普及,点燃ISV、外包服务公司的热情也是非常重要的一环。CNBPA就吸纳了许多行业知名的ISV。



左玥表示,从今年开始,国内的许多ISV在云原生应用方面有了积极的转变,一方面是用户方的压力所致,另一方面ISV自身也有转型的需要。以前,ISV可以通过缩减人力来降低成本,现在则必须通过技术、流程和工具的改进来降低成本。CNBPA的首批成员——中科软、东华软件、北明软件都已经在云原生方面发力。只经过一两个月的接触,灵雀云就与北明软件达成了合作,未来双方在解决方案层面将以云原生作为首选。



数字化转型是所有企业的必由之路。所谓春江水暖鸭先知,那些站在行业前沿和“风口”、面临极大竞争压力的行业用户,比如金融、汽车、航空等行业的客户,在云原生应用方面表现得尤为积极。



云原生呼唤平台厂商



作为云原生应用的倡导者和实践者,灵雀云通过“平台+生态”的方式,助力企业用户快速实现数字化转型的同时,也在寻求自身的突破。


在CNBPA成立大会上,灵雀云发布了一站式云原生应用赋能平台Alauda Container Platform(ACP)、企业级容器PaaS平台Alauda Cloud Enterprise(ACE),以及云原生机器学习赋能平台Alauda Machine Learning (AML)。如果将企业的数字化转型分成应用现代化和数据现代化两部分,那么ACP与ACE就是应用现代化的坚实基础,而AML则是数据现代化的一种有益尝试。







左玥解释说,ACP是云原生应用的赋能工具,任何一个企业都需要这样一个工具。尤其是节点数不多的中小型企业,可以十分方便地在这样一个标准化的平台上快速建立和使用云原生应用。而ACE就是一个包罗万象的云平台,一个大型客户的所有业务都可以在这个平台上实现。它可以支持企业建立一个覆盖整个企业内部各个环节和组织结构的私有云平台,具有多租户、多集群等特性。



灵雀云的一个目标是将公有云上的各种功能都能以容器、开源的形式提供给企业客户,而机器学习就是其中的一个。AML集成了数据科学家的常用工具,可以创建分布式环境并展开实验。AML还可与ACP联动,实现从模型的开发、训练、验证、发布到再训练的流程自动化。通过AML与ACP等产品线的集成,最终可以实现模型持续训练、优化、验证的完整闭环。



“灵雀云将与合作伙伴携手,共同打造更多类似AML这样的工具,推动数据现代化的发展。”左玥表示,“未来,我们还会开发更多的产品,而这些产品的底座和核心就是ACP和ACE,以便更好地支持云原生应用和大型集团客户。”







云原生领域的参与者越来越多,大家在业务上各有侧重,有人关注垂直行业和领域,有人则着力打造通用平台。灵雀云就是后者,它一直在集中精力打造和完善云原生的私有云平台,同时也支持混合云和多云。虽然当前灵雀云的体量还不算大,但是致力于成为一家平台型企业的初心始终未曾动摇。无论从市场知名度、技术先进性还是客户基础来看,在PaaS云平台这一领域,灵雀云在私有云方面已经领先了一个身位。



灵雀云在金融、政府、石化等行业拥有许多大型客户。这些客户在选择供应商时通常非常谨慎,而最终他们没有选择所谓的大厂商,而是与灵雀云这样的成长型企业合作,一方面因为那些大厂商还没有成熟的云原生产品和服务,另一方面也因为灵雀云拥有过硬的产品和解决方案,而且自身业务快速增长、体量不断增加,还有许多具有行业影响力的大客户背书。让左玥感到自豪和有底气的是,灵雀云目前拥有一支100多人的云原生专业研发团队,这一规模在业内是首屈一指的。



今年国庆节假期的前一天,也就是9月30日,记者到灵雀云公司拜访左玥时,已经中午12点多,很多员工还在坚守岗位,公司所有的会议室都有人在开会。如果没有这种拼搏精神,灵雀云也不会有今天这样快速的成长。据记者了解,灵雀云已经在规划走向国际市场。



中国最不缺的就是App开发企业,而在企业级应用开发交付和管理领域,大型的核心平台厂商始终是空白。左玥有信心开创这一先河。具有颠覆性的云原生给了灵雀云这样一个机会。介入早、积累深、踏实肯干、愿意投入并长期坚守,虽然困难很多,但是灵雀云愿意去尝试和挑战。

企业上云不可或缺的关键环节

博云BoCloud 发表了文章 • 0 个评论 • 643 次浏览 • 2018-09-14 11:05 • 来自相关话题

云管理平台(Cloud Management Platforms,CMP)近两年来被业界广泛提及,但因为其市场较新,加之不少企业对 CMP 平台建设存在较多认知误区,此次InfoQ记者就此采访了BoCloud博云,带大家详细了解云管理平台。 ...查看全部
云管理平台(Cloud Management Platforms,CMP)近两年来被业界广泛提及,但因为其市场较新,加之不少企业对 CMP 平台建设存在较多认知误区,此次InfoQ记者就此采访了BoCloud博云,带大家详细了解云管理平台。

云管理平台发展的背景

随着云计算技术的普及,越来越多的企业都在上云。但是公有云、私有云、云原生及底层基础架构日趋复杂,企业级应用流程管理和云管理平台的诞生和发展显得迫在眉睫。

根据博云多年的企业服务经验来看,企业上云的步骤一般可分为尝试阶段和全面上云阶段两个部分。在尝试阶段,企业初始做云化,一般会从开发测试环境开始,尝试和对比不同云服务以及基础设施架构;在全面上云阶段,对基础设施进行改造,搭建云平台业务上云。

经过尝试阶段进入全面上云阶段的时候,企业会面临一些典型的问题,这些问题你可能也经历过或正在经历:

  • 在实施云战略的整个IT建设过程中,企业往往会面对不同的云平台甚至容器平台,不同的网络SDN,分布式存储和传统存储等多种异构环境。这些异构资源应该如何处理?
  • 在云服务场景下,不同部门或子公司在申请IT资源的时候,如何能够面向业务提供服务,通过资源统一配置,并在统一界面上提交申请最后获取资源?
  • 既使用私有云又使用公有云时,如何能对公有云和私有云进行统一管理和统一调度,来达到既使用公有云的弹性资源扩充,保证数据在本地?
  • 云平台搭建好业务上云以后,如何进行整体的运维管理?
  • ……
针对企业上云过程中主要面临的问题和场景,云管理平台应运而生。云管理平台(Cloud Management Platform,CMP)是由Gartner最先提出的企业云战略中一种产品形态,提供的核心能力包括以下几个方面:
  • 整合和管理多种异构基础设施和资源;
  • 跨平台调度编排,让用户高效、灵活地在不同云平台使用云资源;
  • 通过自助服务界面,统一管理资源访问和流程配置。

云管理平台在国外已经发展多年并且已经相对成熟。一开始是一些云厂商提供自带云管理平台,也就是只管理自有云平台的原厂云管;后来出现了所谓的管异构云的云管平台;然后是针对异构资源的管理平台,不仅对异构云,对物理机、数据库、传统存储等资源都要做统一管理,可以称为“大云管”。

如何建设云管理平台

云管理平台能够帮助企业管理好云资源,用好云服务,在企业云化过程中是非常重要,甚至可以说是不可或缺的。从整个行业的发展来看,最近这两年企业大规模上云之后,对云管理平台的需求非常明确,也很迫切。那么企业应该如何建设云管理平台呢?

Forrester曾在云管理平台技术报告中提供了一个参考架构,整个云管理平台主要的架构模块可以分为“Application Service Delivery(应用服务交付)”、“Infrastructure Service Delivery(基础设施服务交付)”、“Hybrid Cloud Operations(混合云运维)”和“Hybrid Cloud Goverance (混合云治理)”,并且需要对下提供多云接入API,对上提供自服务portal和管理portal。


图片1.png



在博云看来,整个IT架构底层是各种资源,资源之上为管理平台,在资源层和管理平台之间还应该有一个重点的调度层。

举例来说,每种公有云都有很多不同的资源,包括虚拟机,网络,存储以及安全设备。这些资源的操作大同小异,但是不同公有云的API不一样,应该有一层用来对公有云进行统一调度,对上提供统一的API。

此外,云管理平台的目的是统一纳管,统一运维管理,统一服务,它是由很多服务组成的,而在真正落地的时候,用户的需求又千差万别,并不是云管理平台中所有的服务都会用到。所以云管理平台的建设非常适合使用微服务架构。

以上就是博云BeyondCMP多云管理平台的设计思路。博云首先在云管理平台中增加了调度层,对存储、计算、网络等异构资源做统一模型,这里面的技术难度很大,也是博云BeyondCMP多云管理平台的突出功能。此外,从管理角度来说,因为CMP面向的对象很多,博云会把各种业务拆成微服务。


微信图片_20180912114306.png



具体而言,博云BeyondCMP多云管理平台的CMDB资产管理可以通过可视化进行流程的定制和编排,同时具有自动化和应用级别的自动部署能力。在技术上,博云BeyondCMP多云管理平台主要以自研为主,在公有云业务的纳管上,博云没用LibCloud的多云纳管的开源技术,自动化上则采用了Ansible,监控上用Zabbix来做。

博云的多云管理平台对公有云厂商开放,这是业务的需求。公有云厂商都有自己的云管理平台,但是彼此之间并不互管,一方不愿管,一方不愿被竞争对手管,自然需要有中间厂商来做跨云管理。

云管理平台的定位

我们都知道云计算一般分为三层:IaaS, PaaS 和SaaS,通常大家对于云管理平台的定位是在PaaS层之上。

在博云看来,在整个云计算技术栈中,云管理平台应该位于IaaS、PaaS和SaaS层的侧面,因为它不是提供资源的平台,而是管理资源和应用的平台。


图片2.png



很多企业都会有自己的运维管理系统,比如流程平台,监控平台等,云管理平台可以跟用户的流程平台和监控平台对接,把资源申请过程和云资源的监控都能接到用户方面。而云管理平台跟底层资源之间就是对异构资源的纳管关系。


微信图片_20180912115135.png



博云的云管理平台自己也有CMDB,可以通过CMDB准确地配置资源。如果客户有自己的CMDB,只需要跟博云的CMDB做同步就可以了。

弄清楚了云管理平台跟周边系统的关系,很多人还是会疑惑云管理平台跟PaaS和容器云的区别。一般来说,如果IaaS层挂了,整个数据中心的计算存储都没有了,如果容器层挂了,就没有来运营的运行基础,应用会出问题。但如果云管理平台出了问题,应用和业务还能正常运行,只是没法做管理了,所以云管理平台更多是做管理,它的能力是获取基础资源,而容器云,或者PaaS的能力是扩充资源。

博云也有BeyondContainer容器云平台,容器云跟云管理平台两者的区别简单来说,容器云平台管应用,利用微服务思想和DevOps理念,实现应用和服务的管理运维;云管理平台管资源,通过云管理平台管理数据中心等基础资源,给客户提供一个虚拟的可视化资源视图,客户可以在此基础上做资源编排,资源管理自动化的操作。


微信图片_20180912114832.png



云管理平台的发展趋势

目前全云化的世界已然形成,为了更好地帮助企业上云,云管理平台自身也需要不断发展演进。博云认为云管理平台在以下三个方面有长期演进的趋势:

统一运维管理上:现在很多平台已经具备了运维自动化的基础,能增强自动化部署减少手工操作。在运维自动化的基础上下一步就是运维智能化,如故障自愈,智能迁移,流量管理等方面还需要不断发展;

统一纳管上:云的统一相对简单,是PR操作,但是异构存储和分布式存储的纳管就比较难,整个网络的SDN的联动,就更是行业难点了,这也是云管理平台需要发展的方向;

运营服务上:目前博云提供了租户隔离、服务目录、计量计费统计报表等运营能力,这是一个基础。运营服务上的其他很多细节,包括SLA,计费模型,甚至多云之间的智能选择,都是要在运营分析方面长期去发展的。

总而言之,云管理平台是云时代充分发挥云计算特性优势大幅提升生产力、应对新增混合云多云资源管理问题的平台工具,而在国内企业的云战略建设过程中,普遍缺少云管理平台这一环。如今,云计算已经变成像水和电一样基础。企业如果不能及时转型,研发效率就得不到提升,导致跟不上业务,最终就会被时代抛下。使用云服务,用户无需花大精力在底层基础设施上,能将更大的精力投入到业务研发。而一旦开始上云,就需要云管理平台来帮助管理云资源用好云服务。企业上云的过程是需要规划的,那么云战略的建设规划过程中,千万不要遗漏云管理平台这一重要环节。
PaaS是Platform-as-a-Service的缩写,意思是平台即服务。把服务器平台作为一种服务提供的商业模式。通过网络进行程序提供的服务称之为SaaS(Software as a Service),而云计算时代相应的服务器平台或者开发环境作为服务进行提供就成为了PaaS(Platform as a Service)。