神刀安全网

回顾Java 发展,看 Docker 与Mesos

演讲嘉宾

数人云 COO 谢乐冰

在德国工作十年,回国后加入惠普电信运营商部门,拥有多年项目经验和创业公司工作经验。在数人云负责产品售前和运营,专注行业的技术应用领域,为金融、电信、电商等行业提供服务。

回顾Java的发展轨迹看容器技术

因为我自己写了十几年的Java,经常把容器和十年前的Java做比较。一个公司说自己是做“Java”的,实际上涵义是背后一整套企业IT基础架构。软件一般都是各个集成商(东软、文思)大量码农兄弟们开发,主要还是用Windows。打成了WAR、EAR包之后交付给甲方,就可以在Linux环境下跑起来。同样Weblogic WAS这些中间件在底层计算集群之上,实现了企业服务的大规模运行。

中间件之下是IOE昂贵的高性能硬件,虽然也是集群化,主要依靠Scale up来提升性能。虽然中间件理论上实现了应用和硬件资源解耦,但实际上依然对硬件有非常苛刻的要求,特别是跑数据库的部分。

整个架构为了向上实现SOA的架构,虽然现实中90%以上顶多做到了“面向对象”,但并不妨碍Java(J2EE)作为企业服务交付的“通用”形式,成为了开发单位和运行单位共同接受的标准。所以Java背后代表的不仅仅是一个语言,还是一个完整的IT基础架构和产业链 —— 昂贵的高性能硬件、闭源的中间件软件、Java作为交付接口、SOA架构和开发与运维分离的模式。

背后还有两个隐性的英雄,一个是北大青鸟这样的培训机构,大量产出Java程序员。另外就是Oracle数据库,当然这些年轻程序员写的代码效率不太高的时候,全靠数据库来救场了。当然这一切还是传统的企业业务决定的,例如ERP、CRM等等,并发较低、强事物性和强一致性、逻辑和关联关系复杂。

回顾Java 发展,看 Docker 与Mesos

如今时代发展到了蓝色的部分,云计算时代的IT架构底层不再是几台小机或者一堆刀片,更多的是企业私有云甚至是公有云,IaaS实现了资源层管理的自动化和标准化。

容器就像当年的Java一样,成为了开发和运维共同认可的接口。容器成为了应用上“云”的标准交付方式,不管是Java、Python还是C,只要用Docker打包,就可以丢到这个那个“云”上跑起来。

当然在底层各种计算资源(公有云、私有云甚至物理机)之间,也需要一个中间件来作为容器的大规模运行环境。下面是成千上万的主机,上面是乌央央的容器,中间的云计算中间件实现了两者的解耦。上面支撑的软件架构是“微服务”架构,就像当年的SOA。整体上也是实践了Devops一套运维开发方式。就像传统中间件包括了运行环境、消息队列、ESB(服务发现)和数据抽象等等,云计算中间件也都有类似的服务,例如Mesos、K8s这些容器运行环境,就对应着跑EJB的Weblogic Application Server。

总之,“容器”背后不是单个技术,而是完整的以开源软件为主的云计算IT基础架构和相应的开发和运维流程。当年虚拟机出现让大家尝到一点点云的滋味,但是毕竟局限于资源层,对开发、业务和软件架构没有影响。如今容器影响这么大,大家终于成为了应用上云的突破口,将对大家未来的职业生涯产生巨大的影响。就像今天很难招聘到懂EJB的大学毕业生,过两年很快容器和背后的互联网开源技术栈就会成为主流。

有关Mesos与K8s的老生常谈

言归正传,下面我来一步一步地介绍 Mesos 的实战。说起Mesos,大家往往第一个问题是Mesos和K8s有啥区别,哪个更好。我觉得这两个就像iOS和安卓,已经成为了新一代轻量调度框架的主流。两者都是源于Google的Borg,但Google自己没有使用任何一个。K8s胜在开发者多,用Go语言开发,社区活跃。Mesos是Apache项目,已经诞生了7年,目前有过超过万台规模的部署。总体上我们认为Mesos比较适合目前阶段的大规模生产环境部署,K8s目前还处于快速更新的阶段,两者都有很好的未来。当然Mesos也能兼容大数据等框架,未来目标是逐步把各种集群化的应用(Kafka集群例如)都搬到Mesos上来,实现一键安装和自动扩展。

下面是一点点Mesos的科普,其实市面上类似的文章已经不少,这里我特别推荐平安科技余何老师的《PaaS实现与运维管理:基于Mesos +Docker+ELK的实战指南》,内容非常详细。

用两句俗话说Mesos和K8s的原理,就是像使用一台电脑一样使用整个集群,类似集群的操作系统。单机的操作系统是管理单机的计算、存储和IO,集群操作系统是管理管理一堆机器的资源。目前聚焦在计算和内存之上,存储部分需要单独的分布式存储(例如Ceph和GlusterFS),网络需要SDN的支持。不过传统上IOE也是各管一摊了。

回顾Java 发展,看 Docker 与Mesos

原理看起来也不复杂,Mesos 在每台Slave主机上安装一个Agent,不断地把剩余资源上报到Master。报告内容类似 { (node1, <2 CPUs, 4 GB>),(node2, <3 CPUs, 2 GB>) },这样Master就知道各个机器的剩余资源情况了,非常简单。

Master上面有很多框架Framework,例如Docker和Spark。你就可以把他们理解为Linux里面安装的JRE和Golang、C的运行类库。你想在Mesos上跑啥“语言”,就要部署个框架,例如跑Docker的框架就是Marathon。Mesos会把整个集群的资源按照一定的算法分配给各个框架,这个就是所谓资源调度的过程。因为Slave上报资源情况是不断更新的,所以就是所谓动态资源调度。

回顾Java 发展,看 Docker 与Mesos

每个框架收到分配的资源之后,会自行决定将任务和资源匹配,然后通过Master将任务下发到Slave上执行。Slave上面有每种任务的执行器(Executor),就是运行环境。例如Docker任务的执行器是Mesos预装,其他类型任务执行器可能会实时下载。所以通过安装不同的框架+执行器,就可以支持各种“分布式”的任务系统。请注意这里说的一定是集群化的系统,如果是单点部署一个MySQL之类的就意义有限了。

以管理Docker任务的Marathon框架为例,它收到了Master提供的资源之后,一个是负责进行任务调度,而且还能够通过Health Check监控任务是否还活着,发现失败就重新下发任务。

这些都是常规性的解释,下面我们看看Mesos集群,看看如何一步步搭建。初始一般需要准备3台主机承载Master节点,任意多的Slave,这里建议也是3台。还有几台机器存放log等等。下面的一些图片来自前两天数人云公众号(dmesos)翻译的文章《初次微服务体验:从Docker容器农场说起》。

回顾Java 发展,看 Docker 与Mesos

第一步 部署Zookeeper,负责整个集群的分布式一致性,例如Master领导选举

回顾Java 发展,看 Docker 与Mesos

第二步,部署Mesos本身。我们的分布部署了3个Master,管理3个Slave节点。大家注意到,配置Mesos的时候最重要的参数就是Zookeeper,不但Master要通过ZK来进行领导选举,而且Slave也可以通过ZK来知道谁是活跃的Master.

回顾Java 发展,看 Docker 与Mesos

到这一步,理论上已经可以用Mesos来管理集群下发任务了,大家看见下图里面资源(Slave)、任务(正在执行的已经介绍的)。

回顾Java 发展,看 Docker 与Mesos

甚至还能看到该任务的Stdout输出,就和SSH进去操作一样。

回顾Java 发展,看 Docker 与Mesos

不过仅仅有Mesos,还要自己来编写框架调用接口发布任务,非常不方便。所以需要一个框架来跑容器任务,那就是马拉松(Marathon)。顾名思义用来跑各种长时间运行的服务,类似Linux里面的Inti.d,例如各种网站服务。马拉松是用Scala编写的,本身提供自己的Web管理界面,通过这个界面我们可以“遥控”Mesos来下发并保证Docker任务长久稳定执行。

回顾Java 发展,看 Docker 与Mesos

马拉松的界面也非常直接,大家看看发布Docker任务的界面,基本就是填入Docker Run后面的那些参数,然后告诉马拉松要发布多少份。马拉松会匹配每个Task和Mesos提供的资源,然后通过Mesos将任务下发下去。

回顾Java 发展,看 Docker 与Mesos

结果

回顾Java 发展,看 Docker 与Mesos

服务发现

服务发现是个比较晦涩的翻译(Service Discovery),大概不妨粗略地理解成负载均衡算了。例如马拉松下发了100个网站的容器,每个容器有自己IP(一般是宿主机)和端口。显然前面需要挡一个负载均衡来分配流量。对外暴露的就是负载均衡的某个服务URL,后面自动将流量转发到某个容器的IP+端口上。

回顾Java 发展,看 Docker 与Mesos

我们这里用HAProxy来做负载均衡,有个服务叫Bamboo会不断从ZK读出Mesos状态并且更新HAProxy的配置文件。这样新发下来的Docker会自动添加上HAProxy,而死掉的会被移除。

还有一直办法是用内网的DNS,这个DNS会维护现有的容器列表(IP+端口),并且返回任意一个的IP+端口,页实现了负载均衡和服务发现功能。不过目前Mesos DNS还不太成熟,我们一般用HAProxy。

回顾Java 发展,看 Docker 与Mesos

几百个Docker撒出去,绝对不可能再登到主机上去找看日志。日志必须集中收集,并且提供检索功能,才能有效的Debug。解法也不新奇,无非是ELK。请注意Docker日志可以直接从API读出,另外需要增加一些应用、主机和容器有关的Meta Data。

回顾Java 发展,看 Docker 与Mesos

此外分布式系统不能没有监控,黑盒子等于无法运行,所以监控要分为如下三个层面。

  • 主机监控:这个并非Mesos的关注点,因为主机是资源层,本身也有自己的监控体系
  • 容器层面的监控,主要是用cAdvisor,包括CPU、内存和IO
  • 最最重要的是应用层监控,因为PaaS本身对外提供服务,所以监控的关注点应该是全局最终结果和逻辑正确性,而不是太纠结于个别主机和容器的

这个是分布式系统和传统系统最大的区别,关注点不再是个别容器和主机,而是业务本身。这种系统设计本来就是希望软件脱离对特定和单点硬件的依赖,通过集群化实现大规模系统的高性能和高可用。所以监控不再是着眼于“源头”,而是看重效果。很多时候平台的自愈机制甚至“埋没”了底层的一些故障,那么就让他被埋没了,只要最后效果能够得到保证。

分布式系统在应用层监控要求远远大于普通的IT系统,例如下面是一个HTTP返回状态吗的直方图,这样能很快发现是否出现大规模异常,并且通过日志系统来定位问题。

回顾Java 发展,看 Docker 与Mesos

分布式系统和传统IT区别,就像市场经济和计划经济一样,不是要处处完全可控有计划,在最终结果保持可控情况下,突出灵活性、自由度和弹性,支持业务多变和快速发展。

回顾Java 发展,看 Docker 与Mesos

这样一个基本的分布式系统就搭建完毕,当然如果是生产级别还需要有大规模集群运行调优、集群化HAProxy,监控和报警对接、多租户管理、F5的对接、和Openstack等等的IaaS对接等,这样就需要数人云这样的商业化开源方案来支持了。

此外经常有用户问到,啥样的应用可以上云呢,下面的表格回答了这个问题。

回顾Java 发展,看 Docker 与Mesos

可以看到,这个问题的回答并不是黑白分明。最理想的当然是完全的微服务架构,可以发挥全部的作用。当然90%应用目前还是有状态应用,所以可以快速扩张,但是无法收缩,需要实现Graceful Stop功能,慢慢地收缩。所谓的无状态化改造,无非就是很标准互联网架构,不要用J2EE内置的Session就好。

回顾Java 发展,看 Docker 与Mesos

本来今天还要展示一个我们的客户案例,如何将一个分布式系统迁移到Mesos之上,因为时间关系,下次再分享吧。

精彩问答

QQ群

Q1:当初刚接触Linux的时候,最开始是在Virtualbox等虚拟机这种模拟环境里面摸索 Linux,代价低,比较容易动手和入门。对有一定基础的运维人员(但刚接触容器集群),你建议用什么配置的环境测试做 方便入门(比如测试 Mesos+ZooKeeper+Marathon+Docker)

A1:虚拟机就可以,VARGANT

Q2:Docker的数据持久存储采用何种存储,用Ceph之类?

A2:对,各种分布式存储,例如Glusterfs

Q3:我想问一下K8s+Docker 现在用作生产的话够成熟吗? K8s能达到高可用了吗?

A3:小集群的话可以倒腾倒腾,K8s的源码有浙大张磊老师的书

Q4:还有就是Mesos能否和Openstack结合起来,生产环境有没有Docker和Openstack结合的案例

A4:必须可以,我们就和Openstack厂商一起合做生产系统部署了。可以这么说,完整的DCOS是包括IaaS+PaaS,如果企业要对底层资源严格管理,就需要IaaS

Q5:我想问下Docker的性能,尤其是网络部分,比物理机和普通虚拟机差很多么,用集群性能会不会好些呢

A5:如何是Host模式,Docker网络性能和物理机一样,具体可以看 这里有一篇IBM的论文,讨论了差别:

http://domino.research.ibm.com … 1E7B/ $File/rc25482.pdf

微信群|云实名

Q1:一直想问Doceker会不会一定成为下一代虚拟化。

A1:反正Docker已经基本成为了开发和运维和厂商都比较接受的上云交付形式。

Q2:容器算不算虚拟化的一种,一台服务器,上边跑很多虚拟机怎么更好的提升性能。

A2:最好不要把容器当成虚拟机,虚拟机的意思是和特定IP或者宿主机绑定,而容器特点是在云上飘来飘去。例如经常有需求是给容器分配IP,其实就是当虚拟机了

Q3:有开源版供学习吗?

A3:Mesos这些都是开源的,可以参考平安余何老师的著作,数人云管理平台本身是不开源的。

微信群|运维前线

Q1:ELK本身也是Docker来部署么?

A1:目前有状态的服务很多都有Mesos框架,但是在生产环境中产品化还不多。我们目前不建议客户数据库等应用放上来。背后逻辑也是这些服务,一般还不太需要动态扩展和更新,就算实在互联网公司里面。下一步我们也会推出企业应用商店,会把一些经过测试已经产品化的集群化组件放出来,这个还需要一些时间。

Q2:首先说一下我还没有完全拜读完,这个话题很热,我也很感兴趣。我想问的问题,不是具体的技术问题。我是想问一下:传统的数据中心和传统的企业业务,如何在这场技术大潮中转移到新的技术架构。例如我们现在的数据中心怎样转移到您今天分享的这种架构上来?

A2:四个字“业务驱动”,不上云就宕机,或者看着满地黄金捡不起来,就自然有动力了。

一般说来是7个字,新业务上新平台。互联网的成功在于不是顶层设计,而是消费者的业务驱动。

当然,对于技术水平较高的大型企业,未来交付形式普遍容器化之下。他们引入容器的核心目的是推进自身架构云化改造。

Q3:你们回答的是什么应用适合上云还是容器云?

A3:首先“容器”是应用上云的Gateway,所以可以说泛指上云的应用,云端应用最好都符合Cloud Native架构。当然IaaS也是云,传统有状态应用理论上无需改造也能上虚拟机。不过传统应用强烈和底层硬件特定能力绑定,而虚拟机网络IO不一定满足需要,所以上云的过程同样需要改造。例如数据库分片来减少单节点压力等等。

Q4:安全性呢,公司有的业务不敢轻易放上去,这方面的问题如何解决

A4:适合内部私有云,公有云需要底层IaaS协助网络和虚拟机层面隔离

转载本站任何文章请注明:转载至神刀安全网,谢谢神刀安全网 » 回顾Java 发展,看 Docker 与Mesos

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址
分享按钮