回顾Java 发展，看 Docker 与Mesos | 数人云COO谢乐冰@KVM分享实录

演讲嘉宾

数人云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等等，并发较低、强事物性和强一致性、逻辑和关联关系复杂。

现在时代发展到了蓝色的部分，云计算时代的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也是各管一摊了。

原理看起来也不复杂，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上报资源状况是不断更新的，因此就是所谓动态资源调度。

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

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

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

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

第二步，部署Mesos自己。咱们的分布部署了3个Master，管理3个Slave节点。你们注意到，配置Mesos的时候最重要的参数就是Zookeeper，不但Master要经过ZK来进行领导选举，并且Slave也能够经过ZK来知道谁是活跃的Master.

到这一步，理论上已经能够用Mesos来管理集群下发任务了，你们看见下图里面资源（Slave）、任务（正在执行的已经介绍的）。

甚至还能看到该任务的Stdout输出，就和SSH进去操做同样。

不过仅仅有Mesos，还要本身来编写框架调用接口发布任务，很是不方便。因此须要一个框架来跑容器任务，那就是马拉松（Marathon）。顾名思义用来跑各类长时间运行的服务，相似Linux里面的Inti.d，例如各类网站服务。马拉松是用Scala编写的，自己提供本身的Web管理界面，经过这个界面咱们能够“遥控”Mesos来下发并保证Docker任务长久稳定执行。

马拉松的界面也很是直接，你们看看发布Docker任务的界面，基本就是填入Docker Run后面的那些参数，而后告诉马拉松要发布多少份。马拉松会匹配每一个Task和Mesos提供的资源，而后经过Mesos将任务下发下去。

结果

服务发现

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

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

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

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

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

• 主机监控：这个并不是Mesos的关注点，由于主机是资源层，自己也有本身的监控体系

• 容器层面的监控，主要是用cAdvisor，包括CPU、内存和IO

• 最最重要的是应用层监控，由于PaaS自己对外提供服务，因此监控的关注点应该是全局最终结果和逻辑正确性，而不是太纠结于个别主机和容器的

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

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

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

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

此外常常有用户问到，啥样的应用能够上云呢，下面的表格回答了这个问题。

能够看到，这个问题的回答并非黑白分明。最理想的固然是彻底的微服务架构，能够发挥所有的做用。固然90%应用目前仍是有状态应用，因此能够快速扩张，可是没法收缩，须要实现Graceful Stop功能，慢慢地收缩。所谓的无状态化改造，无非就是很标准互联网架构，不要用J2EE内置的Session就好。

原本今天还要展现一个咱们的客户案例，如何将一个分布式系统迁移到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/library/cyberdig.nsf/papers/0929052195DD819C85257D2300681E7B/$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协助网络和虚拟机层面隔离