译 | SINGULARITY破晓:回顾HUBSPOT在MESOS中的首年表现

dataman 发表了文章 • 0 个评论 • 610 次浏览 • 2016-01-06 17:32 • 来自相关话题

【编者的话】 HubSpot是营销自动化领域的独角兽。其技术团队基于Mesos打造了一套开源系统SINGULARITY。期间发现Mesos对Hubspot的最大好处是能够将其数据中心中的众多设备抽象化为了一台大型计算机,便于资源的共享和动态分配。借用Hubspot的一句话来说明Mesos的价值:我们将过去的一年总结为“一切应用归于Mesos”,那么在新的一年中,我们的座右铭也许可以汇总成“剩下的一切也归于Mesos”。

Hubspot拥有庞大数量的应用服务组件

HubSpot是一套面向企业的市场营销与销售平台,且几乎能够承载一切工作类型——从博客到分析再到客户关系管理通通不在话下。这款产品拥有可观的面向范畴,也因此包含多种独立的可移动组件:约170个单页面Web应用、300项RESTful Web服务、380种后台工作程序、260个cron任务以及400种一次性任务,且全部可以独立方式加以部署。

我们的HubSpot开发团队始终以速度为优先考量。开发人员每天需要完成近300次相关操作,具体涵盖代码提交、变更测试以及生产环境部署。这在很大程度上要归功于我们的平台即服务(简称PaaS)团队,他们的优先目标在于找到相关途径并借此减少开发人员可能遇到的障碍及摩擦。我们在过去一年当中凭借着将越来越多工作负载运行在Mesos——以及我们自主研发的Singularity PaaS方案——之上而获得了巨大收益,同时也给我们的软件、堆栈乃至文化带来了可喜的影响。

当人们问起Mesos给HubSpot带来怎样的切实助益时,他们预期的答案往往是“节约成本”或者“实现自动规模伸缩”之类的结论。诚然,这些都是切实存在的助益;我们节约了可观的资金,因为Mesos允许我们在大型设备之上承载密度更高的工作负载。另外,只需要几次简单点击,我们就能够对任意服务的容量规模进行扩展或者缩减。然而,Mesos的最大助益在于为我们带来了理想的便捷性——具体来讲,它能够将我们数据中心之内的众多设备抽象化为一台大型计算机。

采用Mesos之前的状态

在采用Mesos之前,我们的基础设施需要大量人为因素进行干预。无论是对新设备加以配置还是替换原有硬件都以全人工且容易出错的方式进行。作为传统层面的功能堆栈拥有者,因为托管其服务的设备出现了突发故障,开发人员们往往需要加班加点进行抢修。当然,我们也遭遇过一些单点故障状况,例如开发人员将所有cron任务运行在同一台设备之上。当这些“cron”设备发生问题,随之而来的更换与重新部署工作绝对令人头痛欲裂。

我们的基础设施在透明性方面做得也不够好。我们当然拥有良好的用于警示目的的遥测数据分析机制(例如服务标准与运行状态检查),但开发人员要想从他们的服务当中提取数据(例如提取转储记录或者上周的全部服务日志),则必须以手动方式查询每台设备——这自然带来了可怕的时间浪费。很明显,我们需要一套更简单且更安全的解决方案,使得开发人员能够轻松访问其服务的相关数据,同时又不至于对其它服务造成影响。





 

步入Singularity的世界

我们转向Mesos的理由是让我们的开发人员能够真正从事其所擅长的工作:编写软件,而不必对隐藏在引擎盖之下的HubSpot技术堆栈各个层面拥有全面理解。当我们踏上这段Mesos之旅时,我们首先以调查性方式尝试将Chronos(负责处理cron任务)与Marathon(负责处理Web服务与后台工作程序)纳入部署流程。而Singularity这一名称也因此而来(意为奇异点)——其初始设计目的在于充当一套Mesos框架以处理一次性任务,当时Chronos与Marathon还不具备此类支持能力。

我们最终决定放弃这条初始设计路线,转而将Singularity转化为一套更像是“开箱式PaaS”的解决方案。这意味着它只是单独一项服务,能够处理数据中心之内的大部分常见工作负载类型。大家可以将它视为一种面向数据中心的打包Heroku。

我们还为Singularity开发出了其它一些独特的功能,旨在应对现实世界中的具体需要:
 
能够通过“退役”机制正常中止运行在Mesos从节点上的全部任务(即将以反向启发方式在Apache Mesos当中出现)。能够在任意Mesos cgroup之外操作的人工下载服务。虽然有些反直觉,但这确实是在某些内核遭遇高磁盘I/O时非常有效的OOM中止手段。这是第一项尝试对超出对应内存分配区任务进行顺畅关停的出色OOM关闭服务。这也是一项通用型S3上传服务,能够处理长期日志记录以及与任务相关的其它数据存储操作。一款自定义执行工具,能够面向任务提供强化报告与日志回旋。

重启与恢复

Mesos能够对设备加以抽象,从而轻松应对2014年发生的Amazon“大规模重启”事件。尽管很多其它企业(也包括HubSpot内部的一些未使用Mesos基础设施的团队)都希望抢在自动重启之前对受影响实例进行更换,我们的PaaS团队则选择了启动新Mesos从节点并让受影响设备进行“退役”的作法。Singularity能够自动将进程迁移至正常运行的设备之上,这就意味着我们的开发人员能够继续正常完全日常工作——而不会遭遇到任何故障。
他们无需面临任何停机时间,也根本不知道曾经出现过这次差点给其造成重大影响的灾难。

Singularity这种可以快速对服务规模进行伸缩调整的能力已经多次发挥了作用。有时候,其负责应对预期当中的流量峰值,例如当我们的某位客户出现在《创智赢家》节目当中时。也有些时候,其负责响应我们后端服务所遇到的巨大压力,例如当规模可观的批量邮件一次性排入队列的状况。

在拥抱Mesos之前,这些应对举措需要耗时数十分钟。但如今整个过程只需要几十秒,这意味着我们的平均恢复时间得到了大幅改善。

自诞生之时即选择开源

Singularity之所以成为HubSpot基础设施核心体系中的独特组成部分,是因为它从诞生之日起就坚持走开源路线。如今,包括Groupon、Opentable以及EverTrue等在内的企业都开始使用Singularity,而我们的团队则在使用这款框架的同时为其添加更多实际价值。我们会强化组件、构建功能并在其给其它企业造成大麻烦之前进行漏洞排查。

它已经成为Mesos生态系统当中极具价值的闪亮新星。它不仅能够改进我们的现有基础设施,而且能够在不知不觉当中帮助其它企业拥有更为轻松愉快的日常运营状态。

下一步,我们的目标是将HubSpot基础设施当中的其它新组件迁移到Mesos当中,从而进一步扩大当前已经享受到的种种助益。其中包括Memcache、Kafka、Spark、Hadoop以及MySQL。如果我们将过去的一年总结为“一切应用归于Mesos”,那么在新的一年中,我们的座右铭也许可以汇总成“剩下的一切也归于Mesos”。当然,在数人云上可以快速部署Spark,Kafka,Hadoop …… ,一起努力让一切归于Mesos,归于云操作系统。 查看全部
【编者的话】 HubSpot是营销自动化领域的独角兽。其技术团队基于Mesos打造了一套开源系统SINGULARITY。期间发现Mesos对Hubspot的最大好处是能够将其数据中心中的众多设备抽象化为了一台大型计算机,便于资源的共享和动态分配。借用Hubspot的一句话来说明Mesos的价值:我们将过去的一年总结为“一切应用归于Mesos”,那么在新的一年中,我们的座右铭也许可以汇总成“剩下的一切也归于Mesos”。

Hubspot拥有庞大数量的应用服务组件

HubSpot是一套面向企业的市场营销与销售平台,且几乎能够承载一切工作类型——从博客到分析再到客户关系管理通通不在话下。这款产品拥有可观的面向范畴,也因此包含多种独立的可移动组件:约170个单页面Web应用、300项RESTful Web服务、380种后台工作程序、260个cron任务以及400种一次性任务,且全部可以独立方式加以部署。

我们的HubSpot开发团队始终以速度为优先考量。开发人员每天需要完成近300次相关操作,具体涵盖代码提交、变更测试以及生产环境部署。这在很大程度上要归功于我们的平台即服务(简称PaaS)团队,他们的优先目标在于找到相关途径并借此减少开发人员可能遇到的障碍及摩擦。我们在过去一年当中凭借着将越来越多工作负载运行在Mesos——以及我们自主研发的Singularity PaaS方案——之上而获得了巨大收益,同时也给我们的软件、堆栈乃至文化带来了可喜的影响。

当人们问起Mesos给HubSpot带来怎样的切实助益时,他们预期的答案往往是“节约成本”或者“实现自动规模伸缩”之类的结论。诚然,这些都是切实存在的助益;我们节约了可观的资金,因为Mesos允许我们在大型设备之上承载密度更高的工作负载。另外,只需要几次简单点击,我们就能够对任意服务的容量规模进行扩展或者缩减。然而,Mesos的最大助益在于为我们带来了理想的便捷性——具体来讲,它能够将我们数据中心之内的众多设备抽象化为一台大型计算机。

采用Mesos之前的状态

在采用Mesos之前,我们的基础设施需要大量人为因素进行干预。无论是对新设备加以配置还是替换原有硬件都以全人工且容易出错的方式进行。作为传统层面的功能堆栈拥有者,因为托管其服务的设备出现了突发故障,开发人员们往往需要加班加点进行抢修。当然,我们也遭遇过一些单点故障状况,例如开发人员将所有cron任务运行在同一台设备之上。当这些“cron”设备发生问题,随之而来的更换与重新部署工作绝对令人头痛欲裂。

我们的基础设施在透明性方面做得也不够好。我们当然拥有良好的用于警示目的的遥测数据分析机制(例如服务标准与运行状态检查),但开发人员要想从他们的服务当中提取数据(例如提取转储记录或者上周的全部服务日志),则必须以手动方式查询每台设备——这自然带来了可怕的时间浪费。很明显,我们需要一套更简单且更安全的解决方案,使得开发人员能够轻松访问其服务的相关数据,同时又不至于对其它服务造成影响。

20160106hubspot_high_level_670.png

 

步入Singularity的世界

我们转向Mesos的理由是让我们的开发人员能够真正从事其所擅长的工作:编写软件,而不必对隐藏在引擎盖之下的HubSpot技术堆栈各个层面拥有全面理解。当我们踏上这段Mesos之旅时,我们首先以调查性方式尝试将Chronos(负责处理cron任务)与Marathon(负责处理Web服务与后台工作程序)纳入部署流程。而Singularity这一名称也因此而来(意为奇异点)——其初始设计目的在于充当一套Mesos框架以处理一次性任务,当时Chronos与Marathon还不具备此类支持能力。

我们最终决定放弃这条初始设计路线,转而将Singularity转化为一套更像是“开箱式PaaS”的解决方案。这意味着它只是单独一项服务,能够处理数据中心之内的大部分常见工作负载类型。大家可以将它视为一种面向数据中心的打包Heroku。

我们还为Singularity开发出了其它一些独特的功能,旨在应对现实世界中的具体需要:
 
  • 能够通过“退役”机制正常中止运行在Mesos从节点上的全部任务(即将以反向启发方式在Apache Mesos当中出现)。
  • 能够在任意Mesos cgroup之外操作的人工下载服务。虽然有些反直觉,但这确实是在某些内核遭遇高磁盘I/O时非常有效的OOM中止手段。
  • 这是第一项尝试对超出对应内存分配区任务进行顺畅关停的出色OOM关闭服务。
  • 这也是一项通用型S3上传服务,能够处理长期日志记录以及与任务相关的其它数据存储操作。
  • 一款自定义执行工具,能够面向任务提供强化报告与日志回旋。


重启与恢复

Mesos能够对设备加以抽象,从而轻松应对2014年发生的Amazon“大规模重启”事件。尽管很多其它企业(也包括HubSpot内部的一些未使用Mesos基础设施的团队)都希望抢在自动重启之前对受影响实例进行更换,我们的PaaS团队则选择了启动新Mesos从节点并让受影响设备进行“退役”的作法。Singularity能够自动将进程迁移至正常运行的设备之上,这就意味着我们的开发人员能够继续正常完全日常工作——而不会遭遇到任何故障。
他们无需面临任何停机时间,也根本不知道曾经出现过这次差点给其造成重大影响的灾难。

Singularity这种可以快速对服务规模进行伸缩调整的能力已经多次发挥了作用。有时候,其负责应对预期当中的流量峰值,例如当我们的某位客户出现在《创智赢家》节目当中时。也有些时候,其负责响应我们后端服务所遇到的巨大压力,例如当规模可观的批量邮件一次性排入队列的状况。

在拥抱Mesos之前,这些应对举措需要耗时数十分钟。但如今整个过程只需要几十秒,这意味着我们的平均恢复时间得到了大幅改善。

自诞生之时即选择开源

Singularity之所以成为HubSpot基础设施核心体系中的独特组成部分,是因为它从诞生之日起就坚持走开源路线。如今,包括Groupon、Opentable以及EverTrue等在内的企业都开始使用Singularity,而我们的团队则在使用这款框架的同时为其添加更多实际价值。我们会强化组件、构建功能并在其给其它企业造成大麻烦之前进行漏洞排查。

它已经成为Mesos生态系统当中极具价值的闪亮新星。它不仅能够改进我们的现有基础设施,而且能够在不知不觉当中帮助其它企业拥有更为轻松愉快的日常运营状态。

下一步,我们的目标是将HubSpot基础设施当中的其它新组件迁移到Mesos当中,从而进一步扩大当前已经享受到的种种助益。其中包括Memcache、Kafka、Spark、Hadoop以及MySQL。如果我们将过去的一年总结为“一切应用归于Mesos”,那么在新的一年中,我们的座右铭也许可以汇总成“剩下的一切也归于Mesos”。当然,在数人云上可以快速部署Spark,Kafka,Hadoop …… ,一起努力让一切归于Mesos,归于云操作系统。

快速搭建Jenkins持续集成环境加速产品迭代

dataman 发表了文章 • 0 个评论 • 1196 次浏览 • 2016-01-05 18:41 • 来自相关话题

互联网产品拼的就是迭代速度,这已是互联网行业中大家公认的秘诀。但为什么有人能做到?有人做不到呢?一个重要原因就是开发过程中的持续集成和持续交付(CI/CD)其实并没有那么容易做到,单是部署一个Jenkins持续集成环境,就是一个费时费力的事。

工欲善其事 必先利其器。下面给大家介绍如何通过数人云快速搭建Jenkins持续集成环境。

Jenkins

Jenkins 是基于 Java 开发的一种持续集成 (CI) 工具,使用数人云部署 Jenkins 能够在做到快速搭建的同时,实现资源的动态调度,提高资源利用率。

Jenkins Master

它负责提供整个 Jenkin 的设置、webui、工作流控制定制等。首先,将Jenkins-Master使用数人云发布,数人云会对其进行程序管理和健康检查,从而在应用程序由于某些意外崩溃后自动恢复,保证了Jenkins-Master构建系统的全局高可用,使用数人云部署Jenkins使您的Jenkins应用运行在一个资源池中,进一步实现了资源共享,提高了资源利用率。

Jenkins Slave

Jenkins利用在数人云上建立的集群资源,主要的目的是利用弹性资源分配来提高资源利用率,通过配置Jenkins-mesos-plugin插件,Jenkins Master可以在作业构建时根据实际需要动态的申请Jenkins-Slave节点,并在构建完成后的一段时间后,将节点归还。

Jenkins-mesos-plugin

Jenkins-mesos-plugin是用插件模式挂载到Jenkins Master上的。主要目的是要把Jenkins-Master当作集群的调度器使用,可以调度用数人云建立的集群资源为Jenkins服务。

数人云注册&登录&创建集群

因为数人云迭代很快,所以这里就不进行详细描述,最新数人云操作文档会在数人云用户手册中,需要参考的用户请点击:数人云用户手册

使用数人云部署 Jenkins

部署 Jenkins 应用很简单,下面是具体操作步骤:

选择应用管理,点击"新建应用",按照如下提示,新建 Jenkins 应用:
填写应用名称:jenkins选择集群:demo添加应用镜像地址:testregistry.dataman.io/centos7/mesos-0.23.0-jdk8-jenkins1.628-master填写镜像版本:app.v0.3选择应用模式:HOST模式选择应用类型:有状态应用选择主机:主机下拉列表中选择任一合适IP即可主机/容器目录配置: 数据挂载目录:/data/jenkins 容器目录:/var/lib/jenkins选择容器规格:CPU:0.2 内存:512MB





 
高级设置:

点击添加环境变量,填写环境变量参数:Key: JAVA_OPTS Value: -Xmx512M -Xms512M
Key: JENKINS_PORT Value: 8002





 添加环境变量填写完成之后,点击创建即可,创建完成后可看到应用部署状态等信息:





 
Jenkins应用部署中稍等片刻可看到应用已正常运行:






Jenkins应用成功运行打开浏览器,在内部代理配置好的情况下访问 Jenkins,访问地址为:yourip:JENKINS_PORT,看到如下页面,则说明 Jenkins 应用已经成功运行。






Jenkins主页Jenkins 数人云设置

如果我们想要将Jenkins作为mesos的一个framework注册到mesos上,需要在成功启动 Jenkins之后对其插件进行设置。

设置 Jenkins-Mesos 分三层,点击左上角"系统管理",然后在系统管理页面点击"系统设置"。
Jenkins 调用 Mesos 集群设置Mesos native library path 设置 Mesos lib 库路径,一般在/usr/lib/libmesos.so,拷贝无效,必须安装 Mesos。Mesos Master [hostname:port] 设置 Mesos-Master 地址加端口,如果单 Mesos-Master 模式,使用 mesos-master-ip:5050格式,如果是多 Mesos-Master 使用 zk://zk1:2181,zk2:2181,zk3:2181/mesos 格式Framework Name 设置 Mesos Master 查看到的应用框架名称Slave username 设置 Slave的名字Checkpointing 设置检查On-demand framework registration 设置是否在无任务的情况下,从 Mesos-Master 注销应用框架





Jenkins 调用 Mesos 集群设置Jenkins Slave 调用 Mesos-Slave 类型设置(可按资源)Label String 设置 Slave 标签Maximum number of Executors per Slave 每个 Slave 可以同时执行几个任务Mesos Offer Selection Attributes 选择在那些 Mesos Slave 标签资源上运行,格式{"clusterType":"标签"}





Jenkins Slave 调用 Mesos-Slave 类型设置Jenkins Slave 调用 Docker 镜像设置Docker Image 设置 Jenkins Slave 使用镜像Networking - Bridge 设置网络模式,这里一定要设置网桥模式Port Mapping -Container Port & Host Prot 设置容器端口关系,必须设置否则会导致 Mesos-DNS 因找不到端口映射崩溃,Host Port 默认设置为空(自动取),否则必须设置在39000以后的Mesos Slave 选定端口内。Volumes 挂载目录,必须挂载 slave.jar 和 docker in docker










 
 
 
开源:

所使用的 Dockerfile 和启动脚本全部开源,并上传到了数人科技的GITHUB,有兴趣的同学可以帮助一起改进。

至此一个基于 Jenkins 的持续集成集群环境已搭建完成,让我们一起快速迭代产品吧,给用户不断带来一个个的小惊喜。 查看全部
互联网产品拼的就是迭代速度,这已是互联网行业中大家公认的秘诀。但为什么有人能做到?有人做不到呢?一个重要原因就是开发过程中的持续集成和持续交付(CI/CD)其实并没有那么容易做到,单是部署一个Jenkins持续集成环境,就是一个费时费力的事。

工欲善其事 必先利其器。下面给大家介绍如何通过数人云快速搭建Jenkins持续集成环境

Jenkins

Jenkins 是基于 Java 开发的一种持续集成 (CI) 工具,使用数人云部署 Jenkins 能够在做到快速搭建的同时,实现资源的动态调度,提高资源利用率。

Jenkins Master

它负责提供整个 Jenkin 的设置、webui、工作流控制定制等。首先,将Jenkins-Master使用数人云发布,数人云会对其进行程序管理和健康检查,从而在应用程序由于某些意外崩溃后自动恢复,保证了Jenkins-Master构建系统的全局高可用,使用数人云部署Jenkins使您的Jenkins应用运行在一个资源池中,进一步实现了资源共享,提高了资源利用率。

Jenkins Slave

Jenkins利用在数人云上建立的集群资源,主要的目的是利用弹性资源分配来提高资源利用率,通过配置Jenkins-mesos-plugin插件,Jenkins Master可以在作业构建时根据实际需要动态的申请Jenkins-Slave节点,并在构建完成后的一段时间后,将节点归还。

Jenkins-mesos-plugin

Jenkins-mesos-plugin是用插件模式挂载到Jenkins Master上的。主要目的是要把Jenkins-Master当作集群的调度器使用,可以调度用数人云建立的集群资源为Jenkins服务。

数人云注册&登录&创建集群

因为数人云迭代很快,所以这里就不进行详细描述,最新数人云操作文档会在数人云用户手册中,需要参考的用户请点击:数人云用户手册

使用数人云部署 Jenkins

部署 Jenkins 应用很简单,下面是具体操作步骤:

选择应用管理,点击"新建应用",按照如下提示,新建 Jenkins 应用:
  • 填写应用名称:jenkins
  • 选择集群:demo
  • 添加应用镜像地址:testregistry.dataman.io/centos7/mesos-0.23.0-jdk8-jenkins1.628-master
  • 填写镜像版本:app.v0.3
  • 选择应用模式:HOST模式
  • 选择应用类型:有状态应用
  • 选择主机:主机下拉列表中选择任一合适IP即可
  • 主机/容器目录配置: 数据挂载目录:/data/jenkins 容器目录:/var/lib/jenkins
  • 选择容器规格:CPU:0.2 内存:512MB


A.png

 
高级设置:

点击添加环境变量,填写环境变量参数:
Key: JAVA_OPTS Value: -Xmx512M -Xms512M 
Key: JENKINS_PORT Value: 8002


B.png

 添加环境变量填写完成之后,点击创建即可,创建完成后可看到应用部署状态等信息:

C.png

 
Jenkins应用部署中稍等片刻可看到应用已正常运行:

D.png


Jenkins应用成功运行打开浏览器,在内部代理配置好的情况下访问 Jenkins,访问地址为:yourip:JENKINS_PORT,看到如下页面,则说明 Jenkins 应用已经成功运行。

E.png


Jenkins主页Jenkins 数人云设置

如果我们想要将Jenkins作为mesos的一个framework注册到mesos上,需要在成功启动 Jenkins之后对其插件进行设置。

设置 Jenkins-Mesos 分三层,点击左上角"系统管理",然后在系统管理页面点击"系统设置"。
  • Jenkins 调用 Mesos 集群设置
  • Mesos native library path 设置 Mesos lib 库路径,一般在/usr/lib/libmesos.so,拷贝无效,必须安装 Mesos。
  • Mesos Master [hostname:port] 设置 Mesos-Master 地址加端口,如果单 Mesos-Master 模式,使用 mesos-master-ip:5050格式,如果是多 Mesos-Master 使用 zk://zk1:2181,zk2:2181,zk3:2181/mesos 格式
  • Framework Name 设置 Mesos Master 查看到的应用框架名称
  • Slave username 设置 Slave的名字
  • Checkpointing 设置检查
  • On-demand framework registration 设置是否在无任务的情况下,从 Mesos-Master 注销应用框架


j1.png

  • Jenkins 调用 Mesos 集群设置Jenkins Slave 调用 Mesos-Slave 类型设置(可按资源)
  • Label String 设置 Slave 标签
  • Maximum number of Executors per Slave 每个 Slave 可以同时执行几个任务
  • Mesos Offer Selection Attributes 选择在那些 Mesos Slave 标签资源上运行,格式{"clusterType":"标签"}


j2.png

  • Jenkins Slave 调用 Mesos-Slave 类型设置Jenkins Slave 调用 Docker 镜像设置
  • Docker Image 设置 Jenkins Slave 使用镜像
  • Networking - Bridge 设置网络模式,这里一定要设置网桥模式
  • Port Mapping -Container Port & Host Prot 设置容器端口关系,必须设置否则会导致 Mesos-DNS 因找不到端口映射崩溃,Host Port 默认设置为空(自动取),否则必须设置在39000以后的Mesos Slave 选定端口内。
  • Volumes 挂载目录,必须挂载 slave.jar 和 docker in docker


j3.png


j4.png

 
 
 
开源:

所使用的 Dockerfile 和启动脚本全部开源,并上传到了数人科技的GITHUB,有兴趣的同学可以帮助一起改进。

至此一个基于 Jenkins 的持续集成集群环境已搭建完成,让我们一起快速迭代产品吧,给用户不断带来一个个的小惊喜。

对号入座,数人科技带你聊聊年会那些坑

杨y 发表了文章 • 0 个评论 • 466 次浏览 • 2016-01-05 14:23 • 来自相关话题

科普:年会(英文:annual convention)指某些社会团体一年举行一次的集会,是企业和组织一年一度不可缺少的“家庭盛会”,主要目的是激扬士气,营造组织气氛、深化内部沟通、促进战略分享、增进目标认同,并制定目标,为新一年度的工作奏响序曲。年会是企业的春节,也是标志着一个企业和组织一年工作的结束。

又是一年年会时,你们的年会是酱紫的吗?都来对号入座。






年会之折腾篇:
接下来,你将收到这样的年会通知:






And这样的年会通知:






So,如果你不会个琴棋书画,没有个十八般武艺,再没个可以穿得下紧身礼服的身条,那你就只能是你们公司年会上的看(low)客(货)。

此类形式的年会,折腾你没商量。


年会之走肾篇:

年会上没有美女那还敢叫年会,就地取材也好,求助外援也罢,总之,一些公司就是要让你知道他们是有妹子的,告诉你用一个(一堆)妹子的颜值足以撑起一场年会。






德艺双馨、大长腿神马的,你颤抖了吗?

年会之“穷”篇:

对,没错,就是穷,大写的。

比如一些刚刚起步的初创公司,或者由于当年度业绩不佳而拿不出预算操办年会,或者有些老板们自带抠门属性(如有雷同,纯属故意),花钱肾疼。

所以,今年年会就不举办了,希望大家理解(浓重官腔),但是年底了,为感谢大家一年来为公司做出的贡献,节日礼物还是要发的,请收下我们精心准备的新年大礼包:






简直贴心到令人发指有咩有,对于这样公司的员工,想告诉他,跳槽请联系我。

年会之走心篇:

多年服务(雾)于帝都,劳心伤肺。岁末年终,看有哪些公司愿意从实际出发,不花拳绣腿,想你之所想,带你来一场说走就走的洗肺之旅。






数人科技2015年会进行时,公司将带领全体员工及家属(自愿)在天朗气清、美不胜收的菲律宾长滩岛举办旅行年会,阳光,沙滩,龙虾,大长(白)腿。。。

插张图拉仇恨,随意感受下。






同样是初创,但我们绝不亏待兄弟姐妹;
也想让年会出彩,但我们不折腾自己人;
美女赛网红,只是不屑于显摆。

数人科技正在热招:
云平台应用开发工程师
售前架构师
运维开发工程师
市场经理



骚年,玩心吗?
加入数人科技,这样的年会离你只是一份简历的距离。





  查看全部

科普:年会(英文:annual convention)指某些社会团体一年举行一次的集会,是企业和组织一年一度不可缺少的“家庭盛会”,主要目的是激扬士气,营造组织气氛、深化内部沟通、促进战略分享、增进目标认同,并制定目标,为新一年度的工作奏响序曲。年会是企业的春节,也是标志着一个企业和组织一年工作的结束。

又是一年年会时,你们的年会是酱紫的吗?都来对号入座。

年会图1.gif


年会之折腾篇:
接下来,你将收到这样的年会通知:

年会图2.png


And这样的年会通知:

年会图3.png


So,如果你不会个琴棋书画,没有个十八般武艺,再没个可以穿得下紧身礼服的身条,那你就只能是你们公司年会上的看(low)客(货)。

此类形式的年会,折腾你没商量。


年会之走肾篇:

年会上没有美女那还敢叫年会,就地取材也好,求助外援也罢,总之,一些公司就是要让你知道他们是有妹子的,告诉你用一个(一堆)妹子的颜值足以撑起一场年会。

年会图4.png


德艺双馨、大长腿神马的,你颤抖了吗?

年会之“穷”篇:

对,没错,就是穷,大写的。

比如一些刚刚起步的初创公司,或者由于当年度业绩不佳而拿不出预算操办年会,或者有些老板们自带抠门属性(如有雷同,纯属故意),花钱肾疼。

所以,今年年会就不举办了,希望大家理解(浓重官腔),但是年底了,为感谢大家一年来为公司做出的贡献,节日礼物还是要发的,请收下我们精心准备的新年大礼包:

年会图5.png


简直贴心到令人发指有咩有,对于这样公司的员工,想告诉他,跳槽请联系我。

年会之走心篇:

多年服务(雾)于帝都,劳心伤肺。岁末年终,看有哪些公司愿意从实际出发,不花拳绣腿,想你之所想,带你来一场说走就走的洗肺之旅。

年会图6.jpg


数人科技2015年会进行时,公司将带领全体员工及家属(自愿)在天朗气清、美不胜收的菲律宾长滩岛举办旅行年会,阳光,沙滩,龙虾,大长(白)腿。。。

插张图拉仇恨,随意感受下。

长滩图2.png


同样是初创,但我们绝不亏待兄弟姐妹;
也想让年会出彩,但我们不折腾自己人;
美女赛网红,只是不屑于显摆。

数人科技正在热招:
云平台应用开发工程师
售前架构师
运维开发工程师
市场经理



骚年,玩心吗?
加入数人科技,这样的年会离你只是一份简历的距离。

年会尾图.jpg

 

译 | 像使用一台主机一样管理集群

laura 发表了文章 • 0 个评论 • 490 次浏览 • 2016-01-05 10:43 • 来自相关话题

【编者的话】不论是 YARN、Mesos 还是 Omega,都是某种意义上为集群设计的操作系统,让用户像使用一台单机一样来使用整个集群。向下集中管理所有物理资源,向上承载各种集群化的应用; 同时, docker 的出现也为云操作系统提供了更有力的支撑。






1984年,SUN 的 John Gage 说出了那句家喻户晓的名言 “网络就是计算机”

三十年后,Gage 的梦想“几乎”成为的现实。特别是随着 web 2.0 和云计算时代的到来,人们可以使用任何设备从任何地方通过互联网访问任何云端的资源。






不过即使在“云端”,实际上还是一堆物理服务器。每一台服务器的 CPU 和内存资源都是有限的,但是组合成集群就像云一样无穷无尽。套用 Gage 的名言,可以说**“集群就是计算机”**。

当单机的 CPU 性能和硬盘容量逐渐碰到了天花板,通过 Hadoop 这样的集群化技术来突破单机性能瓶颈就越来越流行。当然在 Hadoop 出现之前,集群方案早就应用于高性能的生产系统,例如 Weblogic 或者集群化的 WEB 服务器(复杂均衡按照 round-robin 算法将流量发送到集群中的 Web 服务器上)。这些集群方案都针对特定场景设计,无法像通用的计算机一样用来运行各种不同的软件。

Hadoop 是第一个具有通用的集群化计算平台特征的技术,而且目前已经发展地相当成熟。随着新的集群化计算技术层出不穷,例如 Spark、Storm 和 Cassandra,运维人员希望能够隔离它们以便更好的管理,同时,从节约成本的角度讲, 大家又希望公司内部各个团队能够共用这些昂贵的计算资源。

目前解决这个问题的两大法宝是 Hadoop YARN 和 Apache Mesos。Mesos 的设计受到了 Google 的 Omega 平台启发,而后者则来自 Google 内部久经考验的Borg任务管理平台。同样的事情当初也发声在 Hadoop 之上,它就是受到了 Google 的 GFS 和 Big-Table 启发。不论是 YARN、Mesos 还是 Omega,都是某种意义上为集群设计的操作系统,让用户像使用一台单机一样来使用整个集群。向下集中管理所有物理资源,向上承载各种集群化的应用。

因为 YARN 本身与 Hadoop/Map Reduce v2 绑定,对于使用早期 Hadoop 版本的开发者,升级到 YARN 也许是一个比较容易的决定。理论上可以将 YARN 跑在 Mesos 上,不过有些人担心随之而来的两层资源分配问题。

Mesos可以支持大量的框架(插件),逐步在构建一个快速增长的生态环境。例如 Twitter的 Aurora 就是用来在 Mesos 管理的集群上进行任务调度,已经成为了 Apache 的孵化器项目。此外 Ringmaster 则用来在 Mesos 上快速运行 Cassandra 和 Spark。

Chronos 相当于 Mesos 之上的 crontable,Marathon 则相当于 init.d,让大家用熟悉的方式来调度任务。

最激动人心的还是 Docker 与 mesos 的整合,几乎让 Mesos 可以运行任何语言编写的软件。






Docker 的崛起本身和集群技术倒没有直接关系,它首先被用来代替传统的 VM(虚拟机)。容器分享了底层操作系统,远比传统 VM 更加轻量。类似技术在2000年就出现了,那就是“jail”命令。Wiki 有关词条描述了 35 年来 chroot 如何发展到 jails,最后的 Docker 和容器成为了集大成者。

Docker 化的应用像一个 tar 压缩包,在一台普通的物理机上,你可以轻松地运行数十个独立的 Docker。对于一个由 Mesos 管理的集群,而且恰好你的应用某种程度上使用了分布式的架构,那么瞬间你的集群变成了一台强大的大型机。其实 tar 本身意思是 “tape archive”,就是过去大型机磁带系统的文件格式。

使用 Docker 容器来完全取代传统的 jar 或者 ear 文件,一夜间用 Mesos 来完全取代 weblogic,还是有点操之过急——目前传统软件的架构依然是 web、计算逻辑和存储分开部署。不过对于互联网公司的后台,用 Mesos 来承载 web 服务器集群应付高并发业务,完全不是什么新鲜事儿了。

查看文中加粗部分超链接内容:http://blog.dataman-inc.com/yi ... cfa3f

原文作者:michaelmalak

  查看全部
【编者的话】不论是 YARN、Mesos 还是 Omega,都是某种意义上为集群设计的操作系统,让用户像使用一台单机一样来使用整个集群。向下集中管理所有物理资源,向上承载各种集群化的应用; 同时, docker 的出现也为云操作系统提供了更有力的支撑。

像使用一台主机一样管理集群.jpg


1984年,SUN 的 John Gage 说出了那句家喻户晓的名言 “网络就是计算机”

三十年后,Gage 的梦想“几乎”成为的现实。特别是随着 web 2.0 和云计算时代的到来,人们可以使用任何设备从任何地方通过互联网访问任何云端的资源。

Tar.png


不过即使在“云端”,实际上还是一堆物理服务器。每一台服务器的 CPU 和内存资源都是有限的,但是组合成集群就像云一样无穷无尽。套用 Gage 的名言,可以说**“集群就是计算机”**。

当单机的 CPU 性能和硬盘容量逐渐碰到了天花板,通过 Hadoop 这样的集群化技术来突破单机性能瓶颈就越来越流行。当然在 Hadoop 出现之前,集群方案早就应用于高性能的生产系统,例如 Weblogic 或者集群化的 WEB 服务器(复杂均衡按照 round-robin 算法将流量发送到集群中的 Web 服务器上)。这些集群方案都针对特定场景设计,无法像通用的计算机一样用来运行各种不同的软件。

Hadoop 是第一个具有通用的集群化计算平台特征的技术,而且目前已经发展地相当成熟。随着新的集群化计算技术层出不穷,例如 Spark、Storm 和 Cassandra,运维人员希望能够隔离它们以便更好的管理,同时,从节约成本的角度讲, 大家又希望公司内部各个团队能够共用这些昂贵的计算资源。

目前解决这个问题的两大法宝是 Hadoop YARN 和 Apache Mesos。Mesos 的设计受到了 Google 的 Omega 平台启发,而后者则来自 Google 内部久经考验的Borg任务管理平台。同样的事情当初也发声在 Hadoop 之上,它就是受到了 Google 的 GFS 和 Big-Table 启发。不论是 YARN、Mesos 还是 Omega,都是某种意义上为集群设计的操作系统,让用户像使用一台单机一样来使用整个集群。向下集中管理所有物理资源,向上承载各种集群化的应用。

因为 YARN 本身与 Hadoop/Map Reduce v2 绑定,对于使用早期 Hadoop 版本的开发者,升级到 YARN 也许是一个比较容易的决定。理论上可以将 YARN 跑在 Mesos 上,不过有些人担心随之而来的两层资源分配问题。

Mesos可以支持大量的框架(插件),逐步在构建一个快速增长的生态环境。例如 Twitter的 Aurora 就是用来在 Mesos 管理的集群上进行任务调度,已经成为了 Apache 的孵化器项目。此外 Ringmaster 则用来在 Mesos 上快速运行 Cassandra 和 Spark。

Chronos 相当于 Mesos 之上的 crontable,Marathon 则相当于 init.d,让大家用熟悉的方式来调度任务。

最激动人心的还是 Docker 与 mesos 的整合,几乎让 Mesos 可以运行任何语言编写的软件。

4afbfbedab64034f2227605babc379310b551d80.jpg.png


Docker 的崛起本身和集群技术倒没有直接关系,它首先被用来代替传统的 VM(虚拟机)。容器分享了底层操作系统,远比传统 VM 更加轻量。类似技术在2000年就出现了,那就是“jail”命令。Wiki 有关词条描述了 35 年来 chroot 如何发展到 jails,最后的 Docker 和容器成为了集大成者。

Docker 化的应用像一个 tar 压缩包,在一台普通的物理机上,你可以轻松地运行数十个独立的 Docker。对于一个由 Mesos 管理的集群,而且恰好你的应用某种程度上使用了分布式的架构,那么瞬间你的集群变成了一台强大的大型机。其实 tar 本身意思是 “tape archive”,就是过去大型机磁带系统的文件格式。

使用 Docker 容器来完全取代传统的 jar 或者 ear 文件,一夜间用 Mesos 来完全取代 weblogic,还是有点操之过急——目前传统软件的架构依然是 web、计算逻辑和存储分开部署。不过对于互联网公司的后台,用 Mesos 来承载 web 服务器集群应付高并发业务,完全不是什么新鲜事儿了。

查看文中加粗部分超链接内容:http://blog.dataman-inc.com/yi ... cfa3f

原文作者:michaelmalak

 

请问为什么一直停在了“等待主机链接....”???

[已注销] 回复了问题 • 2 人关注 • 2 个回复 • 619 次浏览 • 2015-12-30 18:11 • 来自相关话题

我的slave总是restart中

[已注销] 回复了问题 • 3 人关注 • 5 个回复 • 509 次浏览 • 2015-12-30 18:10 • 来自相关话题

三星:利用Mesos云操作系统助力物联网发展

杨y 发表了文章 • 0 个评论 • 598 次浏览 • 2015-12-29 11:26 • 来自相关话题

【编者的话】2016年将是物联网蓬勃发展的一年,物联网发展的核心其实是数据驱动的智能体验。韩国三星公司通过将其物联网平台部署在基于Mesos的云操作系统之上,提高了研发团队的效率,简化了Spark大数据集群的部署和管理成本,并通过提高资源利用率降低了整体成本。

物联网在重新确立消费者与物理世界间的交互方式之余,也彻底转变了应用程序开发人员与产品工程师在处理日常工作时的指导方针。
 
如今,单纯在产品的外观与功能上下功夫已经远远不够。消费者希望拥有的是智能化产品,其需要有能力创造、访问并分析数据,而后利用相关结果以实现更具意义的用户体验优化效果。更出色的油耗节约、更理想的牙齿清洁效果、更好的减重成果乃至可由语音控制的电视——所有这些最终用户产品都应当由数字化数据进行支持。

三星公司几前就意识到了这种需求转变,并开发出一套名为SAMI的平台以帮助开发人员通过智能数据分析机制在联网设备上提供更加卓越的用户体验。这套平台能够接收来自几乎任意来源的数据,而SAMI支持下的应用程序则能够将这些多源数据加以整理——这意味着数据源孤岛问题不复存在。除了数据访问能力,SAMI还能够对设备连接、云存储与处理乃至安全性及隐私保护等复杂性因素进行抽象化处理。

三星公司于2014年11月正式发布SAMI平台,而且其自诞生起就吸引到了众多支持者的关注,包括多家初创企业乃至大型厂商。三星方面预计物联网技术将重新定义用户同技术成果之间的交互方式,并因此在接下来的几年中向物联网领域投入了大量研发资源——SAMI正是这一愿景的具体表现之一,SAMI工程技术高级主管Jerome Dubreuil解释称。举例来说,三星公司目前正着手打造一套名为ARTIK的嵌入式物联网模块集合,而SAMI也已经成为其现场生成数据的默认处理后端。

“我们直接推出了完整的堆栈,涵盖由硬件到软件的全部相关元素,”Dubreuil解释称。“硬件正是ARTIK,而软件——或者说云环境——则由SAMI充当。在此之后,大家的惟一任务就是将该模块整合进用户设备当中,并以SAMI为基础进行应用程序构建。”





图片来源:三星公司

迈向Mesos

SAMI自立项之初就以微服务架构为基础,但2015年年初团队工程师们决定将其推向发展的下一阶段——立足于容器机制。当时,SAMI工程团队着力审视了一系列潜在系统选项,希望确保其能够让三星DevOps经理Niranjan Hanumegowda实现Docker容器在生产环境下的“快速增量”目标。最终,他们选择了Mesos、Marathon与Chronos——也就是云操作系统(或称为数据中心操作系统、简称DCOS)的三大核心组件,而它们也成为了SAMI平台的坚实开发根基。

这一举措的主要目标在于设计出一项具备高度可扩展能力的平台即服务(简称PaaS)方案,从而支持日益增长的微服务架构应用,并在其间改进SAMI的内部持续交付与集成(简称CI/CD)流程。三星公司希望借此帮助其它部门(包括QA及开发部门)得以快速将代码推送至生产环境,同时无需担心底层基础设施资源的配置难题。早期成功案例之一正是将Jenkins CI/CD平台运行在Mesos之上,这使得开发人员能够在几乎完全顺畅的情况下每天将数十套代码发布成果推送至生产环境中,且完全符合高质量要求。

SAMI团队最初于2015年2月对Mesos堆栈进行了调查,而SAMI则于今年5月将其运行在生产环境当中。Hanumegowda在今年7月发布的两篇博文当中解读了向Mesos的迁移过程及其采用的Jenkins架构:

· 物联网规模化工作负载容器解决方案:第一部分
· 物联网规模化工作负载容器解决方案:第二部分





面向内部SAMI开发人员的总体部署工作流程示意图。图片来源:三星公司

由于数据在三星的物联网发展战略中扮演着核心角色,因此SAMI的架构天然强调数据处理与存储系统。在最初发布的几篇博文当中,Hanumegowda指出这套平台由超过40项不同后端服务共同组成,其中包括“NoSQL数据存储、消息中转、服务注册、配置存储、图形数据库、HDFS、大数据处理工具、内存内缓存以及传统SQL数据库等等。”

不过,SAMI的永久数据存储机制尚未正式运行在Mesos当中,但三星已经计划随时间推移完成这一迁移工作。尽管SAMI团队已经拥有相当丰富的规模化分布式数据系统运行经验,但Hanumegowda表示该团队更倾向于通过将其部署在Mesos上以降低相关处理难度。作为规模庞大的Mesos技术社区,Mesosphere一直在为各类现有框架提供强有力的支持,具体包括Kafka、Cassandra、HDFS以及Elasticsearch,并不断为其添加新的集成选项。国内数人云也在为Mesos社区贡献着力量,即将推出可一键部署的Spark、Kafka、HDFS、Cassandra等分布式服务。





SAMI工作原理概括图。图片来源:三星公司

一套高效且持续扩展的集群

尽管仍未完善,不过三星的Mesos环境已经极为庞大且仍在不断扩展。目前其以Marathon任务形式运行有超过50项微服务,同时利用Chronos进行着批量任务管理。Jenkins目前作为自有Mesos框架——类似于Apache Spark——加以运行,SAMI团队利用其运行面向大规模数据集的临时性分析任务。在这套框架的帮助下,技术人员得以回避了独立Spark主节点所带来的部署与管理难题。

从无状态应用到任务构建再到面向MapReduce的任务处理,这一切都运行在立足于公有云环境下的一套共享式集群。这套SAMI生产集群目前由约500个CPU计算核心与800 GB内存构成,且随时运行着约400套容器系统。其预生产集群则由约300个CPU计算核心及500 GB内存构成,随时运行着超过250套容器系统。

总体而言,Mesos与Marathon已经帮助SAMI团队节约了约60%的基础设施使用成本,而这要归功于其出色的规模化成本效益。三星公司已经拥有良好的整体资源水平掌控能力,足以准确预测何时需要对设施进行扩展,同时通过添加容器而非物理设备的方式在规模扩展当中实现资源节约。

“我们认为物联网技术的真正价值在于数据本身,而非那些物联网设备,”Dubreuil指出。“在我们看来,SAMI将确切为IT的下一轮革命提供助力。如果像Mesos这样的新型技术能够帮助我们打造出一套更出色的平台,从而允许开发人员构建起更接近理想效果的数据驱动型应用程序,那么我们非常乐意加以采纳。”

英文原文:https://mesosphere.com/blog/2015/12/21/samsung-is-powering-the-internet-of-things-with-mesos-and-marathon/ 

活动预告:






Hold 住高并发,唯架构与运维不可以辜负

主题:高并发,架构,运维,解决方案

时间:2016年01月10号下午14:00 - 17:00

地点:P2 联合创业办公社 • 北京市海淀区中关村 E 世界 A 座 B2


不管你是架构还是运维,抑或是产品,会不会经常遇到“高并发”问题的困扰?别担心,基于Mesos的云操作系统"数人云"带你一场活动看完所有你关心的“高并发”问题。

「宜人贷」讲述系统演化

「当当网」谈谈交易系统重构上线的经验

「京东网」解读京东分布式数据库支撑百亿数据量探索与实践

「数人云」分享使用 Go 开发秒杀系统的实践

不只是一次技术交流,他们多年的经验都在这里了,只等你来。
点击立即报名:http://form.mikecrm.com/f.php?t=aebQyy#rd 查看全部
【编者的话】2016年将是物联网蓬勃发展的一年,物联网发展的核心其实是数据驱动的智能体验。韩国三星公司通过将其物联网平台部署在基于Mesos的云操作系统之上,提高了研发团队的效率,简化了Spark大数据集群的部署和管理成本,并通过提高资源利用率降低了整体成本。

物联网在重新确立消费者与物理世界间的交互方式之余,也彻底转变了应用程序开发人员与产品工程师在处理日常工作时的指导方针。
 
如今,单纯在产品的外观与功能上下功夫已经远远不够。消费者希望拥有的是智能化产品,其需要有能力创造、访问并分析数据,而后利用相关结果以实现更具意义的用户体验优化效果。更出色的油耗节约、更理想的牙齿清洁效果、更好的减重成果乃至可由语音控制的电视——所有这些最终用户产品都应当由数字化数据进行支持。

三星公司几前就意识到了这种需求转变,并开发出一套名为SAMI的平台以帮助开发人员通过智能数据分析机制在联网设备上提供更加卓越的用户体验。这套平台能够接收来自几乎任意来源的数据,而SAMI支持下的应用程序则能够将这些多源数据加以整理——这意味着数据源孤岛问题不复存在。除了数据访问能力,SAMI还能够对设备连接、云存储与处理乃至安全性及隐私保护等复杂性因素进行抽象化处理。

三星公司于2014年11月正式发布SAMI平台,而且其自诞生起就吸引到了众多支持者的关注,包括多家初创企业乃至大型厂商。三星方面预计物联网技术将重新定义用户同技术成果之间的交互方式,并因此在接下来的几年中向物联网领域投入了大量研发资源——SAMI正是这一愿景的具体表现之一,SAMI工程技术高级主管Jerome Dubreuil解释称。举例来说,三星公司目前正着手打造一套名为ARTIK的嵌入式物联网模块集合,而SAMI也已经成为其现场生成数据的默认处理后端。

“我们直接推出了完整的堆栈,涵盖由硬件到软件的全部相关元素,”Dubreuil解释称。“硬件正是ARTIK,而软件——或者说云环境——则由SAMI充当。在此之后,大家的惟一任务就是将该模块整合进用户设备当中,并以SAMI为基础进行应用程序构建。”

三星1.jpg

图片来源:三星公司

迈向Mesos

SAMI自立项之初就以微服务架构为基础,但2015年年初团队工程师们决定将其推向发展的下一阶段——立足于容器机制。当时,SAMI工程团队着力审视了一系列潜在系统选项,希望确保其能够让三星DevOps经理Niranjan Hanumegowda实现Docker容器在生产环境下的“快速增量”目标。最终,他们选择了Mesos、Marathon与Chronos——也就是云操作系统(或称为数据中心操作系统、简称DCOS)的三大核心组件,而它们也成为了SAMI平台的坚实开发根基。

这一举措的主要目标在于设计出一项具备高度可扩展能力的平台即服务(简称PaaS)方案,从而支持日益增长的微服务架构应用,并在其间改进SAMI的内部持续交付与集成(简称CI/CD)流程。三星公司希望借此帮助其它部门(包括QA及开发部门)得以快速将代码推送至生产环境,同时无需担心底层基础设施资源的配置难题。早期成功案例之一正是将Jenkins CI/CD平台运行在Mesos之上,这使得开发人员能够在几乎完全顺畅的情况下每天将数十套代码发布成果推送至生产环境中,且完全符合高质量要求。

SAMI团队最初于2015年2月对Mesos堆栈进行了调查,而SAMI则于今年5月将其运行在生产环境当中。Hanumegowda在今年7月发布的两篇博文当中解读了向Mesos的迁移过程及其采用的Jenkins架构:

· 物联网规模化工作负载容器解决方案:第一部分
· 物联网规模化工作负载容器解决方案:第二部分

三星2.png

面向内部SAMI开发人员的总体部署工作流程示意图。图片来源:三星公司

由于数据在三星的物联网发展战略中扮演着核心角色,因此SAMI的架构天然强调数据处理与存储系统。在最初发布的几篇博文当中,Hanumegowda指出这套平台由超过40项不同后端服务共同组成,其中包括“NoSQL数据存储、消息中转、服务注册、配置存储、图形数据库、HDFS、大数据处理工具、内存内缓存以及传统SQL数据库等等。”

不过,SAMI的永久数据存储机制尚未正式运行在Mesos当中,但三星已经计划随时间推移完成这一迁移工作。尽管SAMI团队已经拥有相当丰富的规模化分布式数据系统运行经验,但Hanumegowda表示该团队更倾向于通过将其部署在Mesos上以降低相关处理难度。作为规模庞大的Mesos技术社区,Mesosphere一直在为各类现有框架提供强有力的支持,具体包括Kafka、Cassandra、HDFS以及Elasticsearch,并不断为其添加新的集成选项。国内数人云也在为Mesos社区贡献着力量,即将推出可一键部署的Spark、Kafka、HDFS、Cassandra等分布式服务。

三星3.png

SAMI工作原理概括图。图片来源:三星公司

一套高效且持续扩展的集群

尽管仍未完善,不过三星的Mesos环境已经极为庞大且仍在不断扩展。目前其以Marathon任务形式运行有超过50项微服务,同时利用Chronos进行着批量任务管理。Jenkins目前作为自有Mesos框架——类似于Apache Spark——加以运行,SAMI团队利用其运行面向大规模数据集的临时性分析任务。在这套框架的帮助下,技术人员得以回避了独立Spark主节点所带来的部署与管理难题。

从无状态应用到任务构建再到面向MapReduce的任务处理,这一切都运行在立足于公有云环境下的一套共享式集群。这套SAMI生产集群目前由约500个CPU计算核心与800 GB内存构成,且随时运行着约400套容器系统。其预生产集群则由约300个CPU计算核心及500 GB内存构成,随时运行着超过250套容器系统。

总体而言,Mesos与Marathon已经帮助SAMI团队节约了约60%的基础设施使用成本,而这要归功于其出色的规模化成本效益。三星公司已经拥有良好的整体资源水平掌控能力,足以准确预测何时需要对设施进行扩展,同时通过添加容器而非物理设备的方式在规模扩展当中实现资源节约。

“我们认为物联网技术的真正价值在于数据本身,而非那些物联网设备,”Dubreuil指出。“在我们看来,SAMI将确切为IT的下一轮革命提供助力。如果像Mesos这样的新型技术能够帮助我们打造出一套更出色的平台,从而允许开发人员构建起更接近理想效果的数据驱动型应用程序,那么我们非常乐意加以采纳。”

英文原文:https://mesosphere.com/blog/2015/12/21/samsung-is-powering-the-internet-of-things-with-mesos-and-marathon/ 

活动预告:

活动图.png


Hold 住高并发,唯架构与运维不可以辜负

主题:高并发,架构,运维,解决方案

时间:2016年01月10号下午14:00 - 17:00

地点:P2 联合创业办公社 • 北京市海淀区中关村 E 世界 A 座 B2


不管你是架构还是运维,抑或是产品,会不会经常遇到“高并发”问题的困扰?别担心,基于Mesos的云操作系统"数人云"带你一场活动看完所有你关心的“高并发”问题。

「宜人贷」讲述系统演化

「当当网」谈谈交易系统重构上线的经验

「京东网」解读京东分布式数据库支撑百亿数据量探索与实践

「数人云」分享使用 Go 开发秒杀系统的实践

不只是一次技术交流,他们多年的经验都在这里了,只等你来。
点击立即报名:http://form.mikecrm.com/f.php?t=aebQyy#rd

活动预告:Hold 住高并发,唯架构与运维不可辜负

laura 发表了文章 • 0 个评论 • 483 次浏览 • 2015-12-25 12:07 • 来自相关话题

双十一,双十二,
你欢喜清空购物车,我坐等零点秒杀,
他们通宵盯代码,求心理阴影面积…

春节回家抢票,
刚开放购买,立马被抢光,
我们和回家只隔了一张 12306 验证码的距离…

当架构与运维遇上“高并发”,「宜人贷」讲述系统演化,「当当」谈谈交易系统重构上线的经验,「京东」解读京东分布式数据库支撑百亿数据量探索与实践,「数人云」分享使用 Go 开发秒杀系统的实践 ,不只是一次技术交流,他们多年的经验都在这里了,数人云带你一场活动看完所有你关心的“高并发”问题。

分享嘉宾

孙军,宜人贷架构师  
2015 年 5 月加入宜人贷,主要从事宜人贷 P2P 借款与出借业务的架构设计与重构相关工作。10 年的 Java 开发经验,先后在人民银行、1 号店、人人网、当当网从事软件开发与技术架构工作。

王胜军,当当网交易系统开发经理
2014 年 11 月加入当当,主导了整个交易平台重构项目。针对交易系统代码量大、业务逻辑复杂的特点,重构采用了比对、分流等策略,确保切换过程平滑稳定。经过 2015 双 11 和双 12 的考验,从各方面验证了新交易系统的可靠性。

彭安,京东架构师
2014 年加入京东,京东资深开发工程师,从事京东分布式数据库的相关研发工作, 擅长大规模数据,高并发高性能服务器开发以及大型分布式系统设计。喜欢写代码,喜欢读代码,善于将优秀开源项目的经典实现运用到自己的系统中。    

肖德时,数人云 CTO
负责云计算的研发及架构设计工作。关注领域包括 Docker,Mesos 集群, 云计算等领域。 肖德时之前为红帽Engineering Service 部门内部工具组 Team Leader。

议程安排
13:30 - 14:00    签到
14:00 - 14:15    开场
14:15 - 14:50  《宜人贷高并发系统演化》孙军 
14:50 - 15:25  《当当交易系统重构上线谈》王胜军
15:25 - 15:40    茶歇
15:40 - 16:15  《京东分布式数据库支撑百亿数据量探索与实践》彭安 
16:15 - 16:50  《使用 Go 开发秒杀系统的实践》肖德时
16:50 以后        自由交流

时间:1月10日 14:00 - 17:00
地点: P2 联合创业办公社 • 北京市海淀区中关村大街11号亿世界财富中心A座B2

数人云是做什么的
数人科技创立于 2014 年,其核心团队来自于 Google、Redhat 和 HP。专注于提供基于分布式和容器技术的 PaaS 服务,帮助用户搭建大规模、高可用、高并发的集群化服务。
旗下产品数人云是国内第一家基于 Mesos 和 Docker 的云操作系统,可以管理公有云和私有云数千节点的集群,部署和管理 Docker、Spark 和用户自行开发的集群化服务。








报名地址:
http://form.mikecrm.com/f.php?t=aebQyy#rd
  查看全部
segmentfault.png

双十一,双十二,
你欢喜清空购物车,我坐等零点秒杀,
他们通宵盯代码,求心理阴影面积…

春节回家抢票,
刚开放购买,立马被抢光,
我们和回家只隔了一张 12306 验证码的距离…

当架构与运维遇上“高并发”,「宜人贷」讲述系统演化,「当当」谈谈交易系统重构上线的经验,「京东」解读京东分布式数据库支撑百亿数据量探索与实践,「数人云」分享使用 Go 开发秒杀系统的实践 ,不只是一次技术交流,他们多年的经验都在这里了,数人云带你一场活动看完所有你关心的“高并发”问题。

分享嘉宾

孙军,宜人贷架构师  
2015 年 5 月加入宜人贷,主要从事宜人贷 P2P 借款与出借业务的架构设计与重构相关工作。10 年的 Java 开发经验,先后在人民银行、1 号店、人人网、当当网从事软件开发与技术架构工作。

王胜军,当当网交易系统开发经理
2014 年 11 月加入当当,主导了整个交易平台重构项目。针对交易系统代码量大、业务逻辑复杂的特点,重构采用了比对、分流等策略,确保切换过程平滑稳定。经过 2015 双 11 和双 12 的考验,从各方面验证了新交易系统的可靠性。

彭安,京东架构师
2014 年加入京东,京东资深开发工程师,从事京东分布式数据库的相关研发工作, 擅长大规模数据,高并发高性能服务器开发以及大型分布式系统设计。喜欢写代码,喜欢读代码,善于将优秀开源项目的经典实现运用到自己的系统中。    

肖德时,数人云 CTO
负责云计算的研发及架构设计工作。关注领域包括 Docker,Mesos 集群, 云计算等领域。 肖德时之前为红帽Engineering Service 部门内部工具组 Team Leader。

议程安排
13:30 - 14:00    签到
14:00 - 14:15    开场
14:15 - 14:50  《宜人贷高并发系统演化》孙军 
14:50 - 15:25  《当当交易系统重构上线谈》王胜军
15:25 - 15:40    茶歇
15:40 - 16:15  《京东分布式数据库支撑百亿数据量探索与实践》彭安 
16:15 - 16:50  《使用 Go 开发秒杀系统的实践》肖德时
16:50 以后        自由交流

时间:1月10日 14:00 - 17:00
地点: P2 联合创业办公社 • 北京市海淀区中关村大街11号亿世界财富中心A座B2

数人云是做什么的
数人科技创立于 2014 年,其核心团队来自于 Google、Redhat 和 HP。专注于提供基于分布式和容器技术的 PaaS 服务,帮助用户搭建大规模、高可用、高并发的集群化服务。
旗下产品数人云是国内第一家基于 Mesos 和 Docker 的云操作系统,可以管理公有云和私有云数千节点的集群,部署和管理 Docker、Spark 和用户自行开发的集群化服务。


合作伙伴.png



报名地址:
http://form.mikecrm.com/f.php?t=aebQyy#rd

 

基于Mesos的操作系统之RogerOS

杨y 发表了文章 • 1 个评论 • 694 次浏览 • 2015-12-23 16:38 • 来自相关话题

【编者的话】本篇译文将介绍基于Mesos的RogerOS。其已成为Moz工程技术发展的基础,并将开发人员生产力与资源使用效率提升至新的高度。数人云是国内基于Mesos的云操作系统。在设计思路上,和RogerOS有着异曲同工之妙。同样的思路,解决类似的问题,再次说明Mesos是云操作系统(数据中心操作系统)的内核首选。
 

内容简介

一年之前,我们为Moz Engineering设立了一个新的平台构建项目。项目的目标非常简单——打造下一代平台,将其作为Moz工程技术发展的基础并将开发人员生产力与资源使用效率提升至新的高度。尽管目标如此单纯,但实际操作起来却困难重重。而今天的博文就将向大家展示我们在推进项目开发当中的心路历程。


背景情况

过去十年以来,技术领域的发展变化可谓迅猛且影响深远。软件创新已经成为一股不可回避的浪潮,而且有越来越多行业开始利用软件作为其主要创新实现手段,这意味着软件系统已经在全球经济增速放缓的时代背景下逆流而上、继续保持着可观的发展进度。

计算基础设施在发展速度方面已经将“迅猛”一词作为常态。我们也由以往的内部、专有、耦合、单一性的平台转向开源、分布式且松散耦合性质的新环境。与此同时,世界的发展脚步也可谓一刻不肯停歇。不过相比之下,基础设施系统的更新周期往往无法同这种前进节奏相匹配,这意味着对于大多数企业而言,让新型软件同现有基础设施进行对接已经成为运营工作当中的核心挑战之一。

在Moz公司,我们当然也遇到了同样的难题。对产品核心进行持续创新已经成为我们在Moz的主要任务,而我们的客户也应当能够享受到由此带来的各类成果。不过正如在去年的一篇博文中所提到,我们的现有系统已经处于负载能力的临界点。其带来的最为直观的影响体现在我们的开发速度领域。目前产品的迭代周期变得越来越长,而工程师们则需要耗费更多时间来打理整套系统。另外一些外部问题也开始凸显,这意味着我们获得尝试新鲜技术成果所必需的原始资源开始变得愈发困难。实验是创新的生命基础,而我们也希望能让自己的工程师及产品经理尽可能多地尝试其新鲜想法。由于缺少对资源的支配空间,这就意味着整个团队需要继续“坚守”现有资源——即使其尚未得到充分利用——并在这一有限的范畴之内满足各类潜在的未来需求。

对于我们的技术运维团队而言,这项工作绝不简单。他们需要对数量惊人的各类语言、框架、数据库以及其它种种组件加以支持。从规划的角度来看,来自开发团队的每一项资源请求都会成为运维工作中既有资源使用习惯的恐怖噩梦。举例来讲,某个团队可能需要大量内存与计算核心资源,但却无需使用规模可观的高速磁盘驱动器——这样的要求与传统采购习惯显然完全背离。而且实际情况是,硬件采购是个耗时极长的过程——至少从软件开发周期的角度来衡量是这样。虽然Amazon Web Services等按需平台的出现能够在很大程度上解决此类难题,但着眼于Moz的业务规模,运行自己的硬件体系显然更具成本效益。而从运维工作的角度出发,理想的场景则是将采购划分成数个大规模批次,从而统一硬件规格与具体交货日期。但这种作法显然直接损害了开发人员的实际要求,他们更希望能够以频繁且种类各异的方式在极短的交货周期之内获得自己需要的资源。

另外,与初创企业不同,我们没有那种从零开始的能力或者说可能性空间。任何一套解决方案都必须能够同时应对新型开发项目与传统工作负载,且拥有足以适应Moz未来需求的出色灵活性。


RogerOS

RogerOS正是我们在面对上述问题时给出的答案。这一名称其实是种误读,因为其事实上并不算是真正的操作系统。不过它确实与操作系统存在着一定程度的相似之处。在开发过程当中,我们选择了这个名称并认为其完全能够代表这套平台的特性。开发团队参考了ClusterOS(DCOS)之类的项目。而且与桌面操作系统一样,RogerOS也会对物理硬件进行抽象化处理,并在用户面前体现为一套统一的高级界面——ClusterOS在数据中心或者设备集群当中也扮演着同样的角色,即对集群硬件加以抽象并提供一套特殊的高级界面。这种概念并不是什么新生事物,类似的系统也已经拥有相当长的发展历史。事实上,RogerOS还从谷歌公司的Borg系统当中汲取到了大量设计灵感。

以下几个章节将详细介绍这套系统的具体细节。


设计目标

其实第二篇博文才负责对设计目标的相关细节进行说明,不过幸运的是我们在这里可以先对其加以总结。我们希望能够为开发人员提供一套系统,从而帮助他们:

·在五分钟以内在笔记本设备上实现代码运行或者在数据中心内启动原型设计。

·在一天之内将能够正常运行的原型方案转化为能够接受一定程度外部流量的进阶版本。

·在一周之内将以上进阶版本转化为一套完全成熟的生产系统。

·能够在十分钟之内完成新版本的部署工作。

·不会对系统之上实际运行的具体工作负载类型做出限制,这意味着其能够彻底替代那些只能够承载虚拟机、容器或者批量工作负载的传统系统方案。

·尽可能多的专注于应用程序代码。这套系统应该能够对运行当中的应用程序进行各类必要处理,具体包括负载均衡、监控、日志记录、故障处理以及规模伸缩等等。


设计

RogerOS的核心为Apache Mesos。考虑到既定设计目标以及对该系统的灵活性要求,Mesos可以说是目前惟一合适的可选项目。不过Mesos的核心定位是一套通用型资源调度工具。要想真正实现RogerOS项目的既定目标,我们需要围绕Mesos建立起完整的生态系统。Mesos在以下架构示意图当中对应的是“ClusterOS Kernel”。






上图展示的是完整架构。正如我们提到,从核心角度来看,RogerOS采用Mesos调度机制,但同时又整合进大量协同服务并与之紧密集成。本系列博文的第二篇对这些设计细节做出了进一步说明。


使用体验

通过以上叙述大家应该能够想见,RogerOS是一款非常复杂的系统,而且已经经历了相当长的开发周期。在着手构建之初,我们其实并不太确定选择Mesos作为系统核心是否正确。当时我们已经通过实践证明了Mesos的适用性,不过其在Moz这类混合型环境下的表现却让我们有点担心。不过幸运的是,我们最终还是选择了Mesos,这一决定让我们至今都相当自豪。其不仅实现了既定承诺,还为我们带来更多惊喜。事实上,我们在系统稳定性、可扩展性以及性能表现方面都没有遇到任何问题。另外,Mesos还允许我们利用一小部分开发资源分步实现目标。目前,一套小型设备集群已经足以为Moz运行多种应用程序。关于这方面内容的具体细节,还请大家参阅本系列的第二篇博文。
开发人员对这套系统的反馈也相当积极。Moz Content项目就是从零开始在RogerOS之上打造而成的,开发团队对于这套平台给出了极高评价。具体来讲,通过硬件抽象与高级服务交付,RogerOS能够让开发团队将精力集中在对产品本身的琢磨之上。另外,除了各类新产品之外,相当一部分传统产品也已经能够在这套系统当中成功运行。

总结总体而言,RogerOS已经成为Moz一个极具野心的项目,而且其能够满足很大一部分我们在立项之初为其设定的发展目标。当然,发展完善的道路仍然漫长,但我们对于目前获得的成果感到相当满意!


另外同样重要的是,我们要向各位为当前成果做出贡献的参与者表示感谢:Jord Sonneveld、Manish Ranjan、Amit Bose、Chris Whitten、Josh Gummersal、Evan Battaglia、Tyler Murray以及整个Moz Content团队,谢谢你们!没有你们的参与,RogerOS根本不可能实现如今的成就。


点击可查看英文原文

对RogerOS的详细技术架构感兴趣?关注我们,本周会推出第二篇文章,为您详细介绍RogerOS。 查看全部
编者的话】本篇译文将介绍基于Mesos的RogerOS。其已成为Moz工程技术发展的基础,并将开发人员生产力与资源使用效率提升至新的高度。数人云是国内基于Mesos的云操作系统。在设计思路上,和RogerOS有着异曲同工之妙。同样的思路,解决类似的问题,再次说明Mesos是云操作系统(数据中心操作系统)的内核首选。
 

内容简介

一年之前,我们为Moz Engineering设立了一个新的平台构建项目。项目的目标非常简单——打造下一代平台,将其作为Moz工程技术发展的基础并将开发人员生产力与资源使用效率提升至新的高度。尽管目标如此单纯,但实际操作起来却困难重重。而今天的博文就将向大家展示我们在推进项目开发当中的心路历程。


背景情况

过去十年以来,技术领域的发展变化可谓迅猛且影响深远。软件创新已经成为一股不可回避的浪潮,而且有越来越多行业开始利用软件作为其主要创新实现手段,这意味着软件系统已经在全球经济增速放缓的时代背景下逆流而上、继续保持着可观的发展进度。

计算基础设施在发展速度方面已经将“迅猛”一词作为常态。我们也由以往的内部、专有、耦合、单一性的平台转向开源、分布式且松散耦合性质的新环境。与此同时,世界的发展脚步也可谓一刻不肯停歇。不过相比之下,基础设施系统的更新周期往往无法同这种前进节奏相匹配,这意味着对于大多数企业而言,让新型软件同现有基础设施进行对接已经成为运营工作当中的核心挑战之一。

在Moz公司,我们当然也遇到了同样的难题。对产品核心进行持续创新已经成为我们在Moz的主要任务,而我们的客户也应当能够享受到由此带来的各类成果。不过正如在去年的一篇博文中所提到,我们的现有系统已经处于负载能力的临界点。其带来的最为直观的影响体现在我们的开发速度领域。目前产品的迭代周期变得越来越长,而工程师们则需要耗费更多时间来打理整套系统。另外一些外部问题也开始凸显,这意味着我们获得尝试新鲜技术成果所必需的原始资源开始变得愈发困难。实验是创新的生命基础,而我们也希望能让自己的工程师及产品经理尽可能多地尝试其新鲜想法。由于缺少对资源的支配空间,这就意味着整个团队需要继续“坚守”现有资源——即使其尚未得到充分利用——并在这一有限的范畴之内满足各类潜在的未来需求。

对于我们的技术运维团队而言,这项工作绝不简单。他们需要对数量惊人的各类语言、框架、数据库以及其它种种组件加以支持。从规划的角度来看,来自开发团队的每一项资源请求都会成为运维工作中既有资源使用习惯的恐怖噩梦。举例来讲,某个团队可能需要大量内存与计算核心资源,但却无需使用规模可观的高速磁盘驱动器——这样的要求与传统采购习惯显然完全背离。而且实际情况是,硬件采购是个耗时极长的过程——至少从软件开发周期的角度来衡量是这样。虽然Amazon Web Services等按需平台的出现能够在很大程度上解决此类难题,但着眼于Moz的业务规模,运行自己的硬件体系显然更具成本效益。而从运维工作的角度出发,理想的场景则是将采购划分成数个大规模批次,从而统一硬件规格与具体交货日期。但这种作法显然直接损害了开发人员的实际要求,他们更希望能够以频繁且种类各异的方式在极短的交货周期之内获得自己需要的资源。

另外,与初创企业不同,我们没有那种从零开始的能力或者说可能性空间。任何一套解决方案都必须能够同时应对新型开发项目与传统工作负载,且拥有足以适应Moz未来需求的出色灵活性。


RogerOS

RogerOS正是我们在面对上述问题时给出的答案。这一名称其实是种误读,因为其事实上并不算是真正的操作系统。不过它确实与操作系统存在着一定程度的相似之处。在开发过程当中,我们选择了这个名称并认为其完全能够代表这套平台的特性。开发团队参考了ClusterOS(DCOS)之类的项目。而且与桌面操作系统一样,RogerOS也会对物理硬件进行抽象化处理,并在用户面前体现为一套统一的高级界面——ClusterOS在数据中心或者设备集群当中也扮演着同样的角色,即对集群硬件加以抽象并提供一套特殊的高级界面。这种概念并不是什么新生事物,类似的系统也已经拥有相当长的发展历史。事实上,RogerOS还从谷歌公司的Borg系统当中汲取到了大量设计灵感。

以下几个章节将详细介绍这套系统的具体细节。


设计目标

其实第二篇博文才负责对设计目标的相关细节进行说明,不过幸运的是我们在这里可以先对其加以总结。我们希望能够为开发人员提供一套系统,从而帮助他们:

·在五分钟以内在笔记本设备上实现代码运行或者在数据中心内启动原型设计。

·在一天之内将能够正常运行的原型方案转化为能够接受一定程度外部流量的进阶版本。

·在一周之内将以上进阶版本转化为一套完全成熟的生产系统。

·能够在十分钟之内完成新版本的部署工作。

·不会对系统之上实际运行的具体工作负载类型做出限制,这意味着其能够彻底替代那些只能够承载虚拟机、容器或者批量工作负载的传统系统方案。

·尽可能多的专注于应用程序代码。这套系统应该能够对运行当中的应用程序进行各类必要处理,具体包括负载均衡、监控、日志记录、故障处理以及规模伸缩等等。


设计

RogerOS的核心为Apache Mesos。考虑到既定设计目标以及对该系统的灵活性要求,Mesos可以说是目前惟一合适的可选项目。不过Mesos的核心定位是一套通用型资源调度工具。要想真正实现RogerOS项目的既定目标,我们需要围绕Mesos建立起完整的生态系统。Mesos在以下架构示意图当中对应的是“ClusterOS Kernel”。

翻译第一篇图.jpg


上图展示的是完整架构。正如我们提到,从核心角度来看,RogerOS采用Mesos调度机制,但同时又整合进大量协同服务并与之紧密集成。本系列博文的第二篇对这些设计细节做出了进一步说明。


使用体验

通过以上叙述大家应该能够想见,RogerOS是一款非常复杂的系统,而且已经经历了相当长的开发周期。在着手构建之初,我们其实并不太确定选择Mesos作为系统核心是否正确。当时我们已经通过实践证明了Mesos的适用性,不过其在Moz这类混合型环境下的表现却让我们有点担心。不过幸运的是,我们最终还是选择了Mesos,这一决定让我们至今都相当自豪。其不仅实现了既定承诺,还为我们带来更多惊喜。事实上,我们在系统稳定性、可扩展性以及性能表现方面都没有遇到任何问题。另外,Mesos还允许我们利用一小部分开发资源分步实现目标。目前,一套小型设备集群已经足以为Moz运行多种应用程序。关于这方面内容的具体细节,还请大家参阅本系列的第二篇博文。
开发人员对这套系统的反馈也相当积极。Moz Content项目就是从零开始在RogerOS之上打造而成的,开发团队对于这套平台给出了极高评价。具体来讲,通过硬件抽象与高级服务交付,RogerOS能够让开发团队将精力集中在对产品本身的琢磨之上。另外,除了各类新产品之外,相当一部分传统产品也已经能够在这套系统当中成功运行。

总结总体而言,RogerOS已经成为Moz一个极具野心的项目,而且其能够满足很大一部分我们在立项之初为其设定的发展目标。当然,发展完善的道路仍然漫长,但我们对于目前获得的成果感到相当满意!


另外同样重要的是,我们要向各位为当前成果做出贡献的参与者表示感谢:Jord Sonneveld、Manish Ranjan、Amit Bose、Chris Whitten、Josh Gummersal、Evan Battaglia、Tyler Murray以及整个Moz Content团队,谢谢你们!没有你们的参与,RogerOS根本不可能实现如今的成就。


点击可查看英文原文

对RogerOS的详细技术架构感兴趣?关注我们,本周会推出第二篇文章,为您详细介绍RogerOS。

把LinkedIn 的 “中枢神经系统” Kafka 搬上数人云

dataman 发表了文章 • 0 个评论 • 961 次浏览 • 2015-12-18 16:05 • 来自相关话题

什么是Kafka?

Kafka 是一个使用 Scala 编写的分布式基于发布/订阅的消息系统。它最初由 LinkedIn 公司开发,之后成为 Apache 项目的一部分。 Kafka 是一个分布式的,可划分的,冗余备份的持久性的日志服务。它主要用于处理活跃的流式数据。

它的架构包括以下组件:
 
话题(Topic):是特定类型的消息流。消息是字节的有效负载(Payload),话题是消息的分类名或种子(Feed)名。生产者(Producer):是能够发布消息到话题的任何对象。缓存代理(Broker),Kafa集群中的一台或多台服务器统称为broker。消费者(Consumer)可以订阅一个或多个话题,并从Broker拉数据,从而消费这些已发布的消息。







Kafka是LinkedIn的"中枢神经系统"

Kreps 将 Kafka 描述为 LinkedIn 的 “中枢神经系统”,管理从各个应用程序汇聚到此的信息流,这些数据经过处理后再被分发到各处。

LinkedIn在2011年7月开始大规模使用Kafka,当时Kafka每天大约处理10亿条消息,这一数据在2012年达到了每天200亿条,而到了2013年7月,每天处理的消息达到了2000亿条。在几个月前,他们的最新记录是每天利用Kafka处理的消息超过1万亿条,在峰值时每秒钟会发布超过450万条消息,每周处理的信息是1.34 PB。每条消息平均会被4个应用处理。在过去的四年中,实现了1200倍的增长。

Kafka 的常见应用场景

传统的消息

对于一些常规的消息系统,Kafka是个不错的选择;partitons/replication和容错,可以使Kafka具有良好的扩展性和性能优势. LinkedIn就使用Kafka作为传统的消息系统实现标准的队列和消息的发布—订阅,例如搜索和内容提要(Content Feed)。

网站跟踪分析

Kafka可以作为"网站活动跟踪"的最佳工具;可以将网页/用户操作等信息发送到Kafka中.并实时监控,或者进行离线统计分析等。例如,为了更好地理解用户行为,改善用户体验,LinkedIn会将用户查看了哪个页面、点击了哪些内容等信息发送到每个数据中心的Kafka集群上,并通过Hadoop进行分析、生成日常报告。

日志收集

Kafka的特性决定它非常适合作为"日志收集中心";application可以将操作日志"批量""异步"的发送到kafka集群中,而不是保存在本地或者DB中;Kafka可以批量提交消息/压缩消息等,这对producer端而言,几乎感觉不到性能的开支.此时consumer端可以使hadoop等其他系统化的存储和分析系统.

有哪些公司使用了神器Kafka?

一些耳熟能详的公司:LinkedIn, Yahoo!, BOX, Twitter, Paypal, Uber, Airbnb,…… 当然还有数人云:)






下面小编就给大家介绍如何在数人云上部署一套Kafka集群,并通过Kafka_manager web端管理工具来管理Kafka集群。让大家和上面这些公司一样玩转神器Kafka。

如何在数人云部署Kafka集群?

1. 建立集群(应用发布环境)

注册数人云,在数人云上建立一个集群。参考:数人云用户手册-建立集群

2. 发布Kafka应用

2.1 发布 Zookeeper

因为 Kafka 集群需要使用 Zookeeper来保证系统的高可用 ,所以需要先在数人云上发布Zookeeper集群。参考:快速搭建ZooKeeper集群指南

2.2 新建 Kafka 应用

1. 选择"应用管理"中的"新建应用",如图所示:






2. 新建应用
 
填写应用名称: kafka选择集群: your-cluster添加应用镜像地址: testregistry.dataman.io/centos7/jdk7-scala2.11-kafka0.8.22填写镜像版本: 20151201应用模式: HOST模式选择主机:your-app-ip(多选)选择容器规格: CPU:0.1 内存:1024 MB容器个数: your-kafka-number

点选:1容器/主机 <- 每个宿主机只能运行1个 app






添加应用地址:











添加环境变量:











3. 检查应用状态

简单的检查应用占用集群资源的情况,点击应用管理 -> 选择监控的 tab 页






至此,Kafka集群已经建立完毕, 可没有一个web界面来管理?别急,下面我们就开始介绍如何搭建一个基于Web的管理工具Kafka_Manager

Kafka_Manager 简介

Apache Kafka 在 Yahoo 内部已经被很多团队所使用,例如媒体分析团队就将其应用到了实时分析流水线中,同时,Yahoo 整个 Kafka 集群处理的峰值带宽超过了 20Gbps(压缩数据)。为了让开发者和服务工程师能够更加简单地维护 Kafka 集群,Yahoo 构建了一个基于 Web 的管理工具,称为 Kafka Manager,日前该项目已经在GitHub上开源。

3. 发布 Kafka_Manager 应用

因为 KafkaManager 是监控 Kafka 的工具,所以在启动 KafkaManager 前,请先按照上面的说明启动 Kafka。

1. 选择"应用管理"中的"新建应用",如图所示:






2. 新建应用
 
填写应用名称: kafka-manager选择集群: your-cluster添加应用镜像地址: testregistry.dataman.io/centos7/jdk8-kafka-0.8.x-manager填写镜像版本: 20151204应用模式: 网桥模式选择主机:your-app-ip(多选)选择容器规格: CPU:0.1 内存:512 MB容器个数: 1

点选:1容器/主机 <- 每个宿主机只能运行1个 app






添加应用地址:











添加环境变量:











3. 检查应用状态

简单的检查应用占用集群资源的情况,点击应用管理 -> 选择监控的 tab 页






4. 打开 Kafka_Manager 页面

游览器输入你的监控地址域名后,按照你的集群情况添加信息






5. 点击 save 后,就可以打开监控页面

可以看到刚才我们加入的 kafka 集群,数量是3个






现在包含web端管理工具的Kafka集群就搭建完成了,大家可以尽情的玩耍和测试了~ 有任何问题,可以在社区里直接提问哦。 查看全部
什么是Kafka?

Kafka 是一个使用 Scala 编写的分布式基于发布/订阅的消息系统。它最初由 LinkedIn 公司开发,之后成为 Apache 项目的一部分。 Kafka 是一个分布式的,可划分的,冗余备份的持久性的日志服务。它主要用于处理活跃的流式数据。

它的架构包括以下组件:
 
  • 话题(Topic):是特定类型的消息流。消息是字节的有效负载(Payload),话题是消息的分类名或种子(Feed)名。
  • 生产者(Producer):是能够发布消息到话题的任何对象。
  • 缓存代理(Broker),Kafa集群中的一台或多台服务器统称为broker。
  • 消费者(Consumer)可以订阅一个或多个话题,并从Broker拉数据,从而消费这些已发布的消息。


20151218kafka1.png



Kafka是LinkedIn的"中枢神经系统"

Kreps 将 Kafka 描述为 LinkedIn 的 “中枢神经系统”,管理从各个应用程序汇聚到此的信息流,这些数据经过处理后再被分发到各处。

LinkedIn在2011年7月开始大规模使用Kafka,当时Kafka每天大约处理10亿条消息,这一数据在2012年达到了每天200亿条,而到了2013年7月,每天处理的消息达到了2000亿条。在几个月前,他们的最新记录是每天利用Kafka处理的消息超过1万亿条,在峰值时每秒钟会发布超过450万条消息,每周处理的信息是1.34 PB。每条消息平均会被4个应用处理。在过去的四年中,实现了1200倍的增长。

Kafka 的常见应用场景

传统的消息

对于一些常规的消息系统,Kafka是个不错的选择;partitons/replication和容错,可以使Kafka具有良好的扩展性和性能优势. LinkedIn就使用Kafka作为传统的消息系统实现标准的队列和消息的发布—订阅,例如搜索和内容提要(Content Feed)。

网站跟踪分析

Kafka可以作为"网站活动跟踪"的最佳工具;可以将网页/用户操作等信息发送到Kafka中.并实时监控,或者进行离线统计分析等。例如,为了更好地理解用户行为,改善用户体验,LinkedIn会将用户查看了哪个页面、点击了哪些内容等信息发送到每个数据中心的Kafka集群上,并通过Hadoop进行分析、生成日常报告。

日志收集

Kafka的特性决定它非常适合作为"日志收集中心";application可以将操作日志"批量""异步"的发送到kafka集群中,而不是保存在本地或者DB中;Kafka可以批量提交消息/压缩消息等,这对producer端而言,几乎感觉不到性能的开支.此时consumer端可以使hadoop等其他系统化的存储和分析系统.

有哪些公司使用了神器Kafka?

一些耳熟能详的公司:LinkedIn, Yahoo!, BOX, Twitter, Paypal, Uber, Airbnb,…… 当然还有数人云:)

20151218kafka0.png


下面小编就给大家介绍如何在数人云上部署一套Kafka集群,并通过Kafka_manager web端管理工具来管理Kafka集群。让大家和上面这些公司一样玩转神器Kafka。

如何在数人云部署Kafka集群?

1. 建立集群(应用发布环境)

注册数人云,在数人云上建立一个集群。参考:数人云用户手册-建立集群

2. 发布Kafka应用

2.1 发布 Zookeeper

因为 Kafka 集群需要使用 Zookeeper来保证系统的高可用 ,所以需要先在数人云上发布Zookeeper集群。参考:快速搭建ZooKeeper集群指南

2.2 新建 Kafka 应用

1. 选择"应用管理"中的"新建应用",如图所示:

20151218kafka2.png


2. 新建应用
 
  • 填写应用名称: kafka
  • 选择集群: your-cluster
  • 添加应用镜像地址: testregistry.dataman.io/centos7/jdk7-scala2.11-kafka0.8.22
  • 填写镜像版本: 20151201
  • 应用模式: HOST模式
  • 选择主机:your-app-ip(多选)
  • 选择容器规格: CPU:0.1 内存:1024 MB
  • 容器个数: your-kafka-number


点选:1容器/主机 <- 每个宿主机只能运行1个 app

20151218kafka3.png


添加应用地址:

20151218kafka4.png


20151218kafka5.png


添加环境变量:

20151218kafka6.png


20151218kafka7.png


3. 检查应用状态

简单的检查应用占用集群资源的情况,点击应用管理 -> 选择监控的 tab 页

20151218kafka8.png


至此,Kafka集群已经建立完毕, 可没有一个web界面来管理?别急,下面我们就开始介绍如何搭建一个基于Web的管理工具Kafka_Manager

Kafka_Manager 简介

Apache Kafka 在 Yahoo 内部已经被很多团队所使用,例如媒体分析团队就将其应用到了实时分析流水线中,同时,Yahoo 整个 Kafka 集群处理的峰值带宽超过了 20Gbps(压缩数据)。为了让开发者和服务工程师能够更加简单地维护 Kafka 集群,Yahoo 构建了一个基于 Web 的管理工具,称为 Kafka Manager,日前该项目已经在GitHub上开源。

3. 发布 Kafka_Manager 应用

因为 KafkaManager 是监控 Kafka 的工具,所以在启动 KafkaManager 前,请先按照上面的说明启动 Kafka。

1. 选择"应用管理"中的"新建应用",如图所示:

20151218kafka9.png


2. 新建应用
 
  • 填写应用名称: kafka-manager
  • 选择集群: your-cluster
  • 添加应用镜像地址: testregistry.dataman.io/centos7/jdk8-kafka-0.8.x-manager
  • 填写镜像版本: 20151204
  • 应用模式: 网桥模式
  • 选择主机:your-app-ip(多选)
  • 选择容器规格: CPU:0.1 内存:512 MB
  • 容器个数: 1


点选:1容器/主机 <- 每个宿主机只能运行1个 app

20151218kafka10.png


添加应用地址:

20151218kafka11.png


20151218kafka12.png


添加环境变量:

20151218kafka13.png


20151218kafka14.png


3. 检查应用状态

简单的检查应用占用集群资源的情况,点击应用管理 -> 选择监控的 tab 页

20151218kafka15.png


4. 打开 Kafka_Manager 页面

游览器输入你的监控地址域名后,按照你的集群情况添加信息

20151218kafka16.png


5. 点击 save 后,就可以打开监控页面

可以看到刚才我们加入的 kafka 集群,数量是3个

20151218kafka17.png


现在包含web端管理工具的Kafka集群就搭建完成了,大家可以尽情的玩耍和测试了~ 有任何问题,可以在社区里直接提问哦。