标签：没有 exe polar master 工程 poi cal 耦合 机房
一切都从企业上云的三大架构开始。
如图所示，企业上的三大架构为IT架构，应用架构和数据架构，在不同的公司，不同的人，不同的角色，关注的重点不同。
对于大部分的企业来讲，上云的诉求是从IT部门发起的，发起人往往是运维部门，他们关注计算，网络，存储，试图通过云计算服务来减轻CAPEX和OPEX。
有的公司有ToC的业务，因而累积了大量的用户数据，公司的运营需要通过这部分数据进行大数据分析和数字化运营，因而在这些企业里面往往还需要关注数据架构。
从事互联网应用的企业，往往首先关注的是应用架构，是否能够满足终端客户的需求，带给客户良好的用户体验，业务量往往会在短期内出现爆炸式的增长，因而关注高并发应用架构，并希望这个架构可以快速迭代，从而抢占风口。
在容器出现之前，这三种架构往往通过虚拟机云平台的方式解决。
当容器出现之后，容器的各种良好的特性让人眼前一亮，他的轻量级、封装、标准、易迁移、易交付的特性，使得容器技术迅速被广泛使用。
然而一千个人心中有一千个哈姆雷特，由于原来工作的关系，三类角色分别从自身的角度看到了容器的优势给自己带来的便捷。
对于原来在机房里面管计算、网络、存储的IT运维工程师来讲，容器更像是一种轻量级的运维模式，在他们看来，容器和虚拟机的最大的区别就是轻量级，启动速度快，他们往往引以为豪的推出虚拟机模式的容器。
对于数据架构来讲，他们每天都在执行各种各样的数据计算任务，容器相对于原来的JVM，是一种隔离性较好，资源利用率高的任务执行模式。
从应用架构的角度出发，容器是微服务的交付形式，容器不仅仅是做部署的，而是做交付的，CI/CD中的D的。
所以这三种视角的人，在使用容器和选择容器平台时方法会不一样。
从IT运维工程师的角度来看：容器主要是轻量级、启动快。而且自动重启，自动关联。弹性伸缩的技术，使得IT运维工程师似乎不用再加班。
Swarm的设计显然更加符合传统IT工程师的管理模式。
他们希望能够清晰地看到容器在不同机器的分布和状态，可以根据需要很方便地SSH到一个容器里面去查看情况。
容器最好能够原地重启，而非随机调度一个新的容器，这样原来在容器里面安装的一切都是有的。
可以很方便的将某个运行的容器打一个镜像，而非从Dockerfile开始，这样以后启动就可以复用在这个容器里面手动做的100项工作。
容器平台的集成性要好，用这个平台本来是为了简化运维的，如果容器平台本身就很复杂，像Kubernetes这种本身就这么多进程，还需要考虑它的高可用和运维成本，这个不划算，一点都没有比原来省事，而且成本还提高了。
最好薄薄得一层，像一个云管理平台一样，只不过更加方便做跨云管理，毕竟容器镜像很容易跨云迁移。
Swarm的使用方式比较让IT工程师以熟悉的味道，其实OpenStack所做的事情它都能做，速度还快。
然而容器作为轻量级虚拟机，暴露出去给客户使用，无论是外部客户，还是公司内的开发，而非IT人员自己使用的时候，他们以为和虚拟机一样，但是发现了不一样的部分，就会很多的抱怨。
例如自修复功能，重启之后，原来SSH进去手动安装的软件不见了，甚至放在硬盘上的文件也不见了，而且应用没有放在Entrypoint里面自动启动，自修复之后进程没有跑起来，还需要手动进去启动进程，客户会抱怨你这个自修复功能有啥用？
例如有的用户会ps一下，发现有个进程他不认识，于是直接kill掉了，结果是Entrypoint的进程，整个容器直接就挂了，客户抱怨你们的容器太不稳定，老是挂。
容器自动调度的时候，IP是不保持的，所以往往重启原来的IP就没了，很多用户会提需求，这个能不能保持啊，原来配置文件里面都配置的这个IP的，挂了重启就变了，这个怎么用啊，还不如用虚拟机，至少没那么容易挂。
容器的系统盘，也即操作系统的那个盘往往大小是固定的，虽然前期可以配置，后期很难改变，而且没办法每个用户可以选择系统盘的大小。有的用户会抱怨，我们原来本来就很多东西直接放在系统盘的，这个都不能调整，叫什么云计算的弹性啊。
如果给客户说容器挂载数据盘，容器都启动起来了，有的客户想像云主机一样，再挂载一个盘，容器比较难做到，也会被客户骂。
如果容器的使用者不知道他们在用容器，当虚拟机来用，他们会觉得很难用，这个平台一点都不好。
Swarm上手虽然相对比较容易，但是当出现问题的时候，作为运维容器平台的人，会发现问题比较难解决。
Swarm内置的功能太多，都耦合在了一起，一旦出现错误，不容易debug。如果当前的功能不能满足需求，很难定制化。很多功能都是耦合在Manager里面的，对Manager的操作和重启影响面太大。
从大数据平台运维的角度来讲，如何更快的调度大数据处理任务，在有限的时间和空间里面，更快的跑更多的任务，是一个非常重要的要素。
所以当我们评估大数据平台牛不牛的时候，往往以单位时间内跑的任务数目以及能够处理的数据量来衡量。
从数据运维的角度来讲，Mesos是一个很好的调度器，既然能够跑任务，也就能够跑容器，Spark和Mesos天然的集成，有了容器之后，可以用更加细粒度的任务执行方式。
在没有细粒度的任务调度之前，任务的执行过程是这样的。任务的执行需要Master的节点来管理整个任务的执行过程，需要Worker节点来执行一个个子任务。在整个总任务的一开始，就分配好Master和所有的Work所占用的资源，将环境配置好，等在那里执行子任务，没有子任务执行的时候，这个环境的资源都是预留在那里的，显然不是每个Work总是全部跑满的，存在很多的资源浪费。
在细粒度的模式下，在整个总任务开始的时候，只会为Master分配好资源，不给Worker分配任何的资源，当需要执行一个子任务的时候，Master才临时向Mesos申请资源，环境没有准备好怎么办？好在有Docker，启动一个Docker，环境就都有了，在里面跑子任务。在没有任务的时候，所有的节点上的资源都是可被其他任务使用的，大大提升了资源利用效率。
这是Mesos的最大的优势，在Mesos的论文中，最重要阐述的就是资源利用率的提升，而Mesos的双层调度算法是核心。
原来大数据运维工程师出身的，会比较容易选择Mesos作为容器管理平台。只不过原来是跑短任务，加上marathon就能跑长任务。但是后来Spark将细粒度的模式deprecated掉了，因为效率还是比较差。
调度在大数据领域是核心中的核心，在容器平台中是重要的，但是不是全部。所以容器还需要编排，需要各种外围组件，让容器跑起来运行长任务，并且相互访问。Marathon只是万里长征的第一步。
所以早期用Marathon + Mesos的厂商，多是裸用Marathon和Mesos的，由于周边不全，因而要做各种的封装，各家不同。大家有兴趣可以到社区上去看裸用Marathon和Mesos的厂商，各有各的负载均衡方案，各有各的服务发现方案。
所以后来有了DCOS，也就是在Marathon和Mesos之外，加了大量的周边组件，补充一个容器平台应有的功能，但是很可惜，很多厂商都自己定制过了，还是裸用Marathon和Mesos的比较多。
而且Mesos虽然调度牛，但是只解决一部分调度，另一部分靠用户自己写framework以及里面的调度，有时候还需要开发Executor，这个开发起来还是很复杂的，学习成本也比较高。
虽然后来的DCOS功能也比较全了，但是感觉没有如Kubernetes一样使用统一的语言，而是采取大杂烩的方式。在DCOS的整个生态中，Marathon是Scala写的，Mesos是C++写的，Admin Router是Nginx+lua，Mesos-DNS是Go，Marathon-lb是Python，Minuteman是Erlang，这样太复杂了吧，林林总总，出现了Bug的话，比较难自己修复。
而Kubernetes不同，初看Kubernetes的人觉得他是个奇葩所在，容器还没创建出来，概念先来一大堆，文档先读一大把，编排文件也复杂，组件也多，让很多人望而却步。我就想创建一个容器玩玩，怎么这么多的前置条件。如果你将Kubernetes的概念放在界面上，让客户去创建容器，一定会被客户骂。
在开发人员角度，使用Kubernetes绝对不是像使用虚拟机一样，开发除了写代码，做构建，做测试，还需要知道自己的应用是跑在容器上的，而不是当甩手掌柜。开发人员需要知道，容器是和原来的部署方式不一样的存在，你需要区分有状态和无状态，容器挂了起来，就会按照镜像还原了。开发人员需要写Dockerfile，需要关心环境的交付，需要了解太多原来不了解的东西。实话实说，一点都不方便。
在运维人员角度，使用Kubernetes也绝对不是像运维虚拟机一样，我交付出来了环境，应用之间互相怎么调用，我才不管，我就管网络通不通。在运维眼中做了过多他不该关心的事情，例如服务的发现，配置中心，熔断降级，这都应该是代码层面关心的事情，应该是Spring Cloud和Dubbo关心的事情，为什么要到容器平台层来关心这个。
Kubernetes + Docker，却是Dev和Ops融合的一个桥梁。
Docker是微服务的交付工具，微服务之后，服务太多了，单靠运维根本管不过来，而且很容易出错，这就需要研发开始关心环境交付这件事情。例如配置改了什么，创建了哪些目录，如何配置权限，只有开发最清楚，这些信息一方面很难通过文档的方式，又及时又准确的同步到运维部门来，就算是同步过来了，运维部门的维护量也非常的大。
所以，有了容器，最大的改变是环境交付的提前，是每个开发多花5%的时间，去换取运维200%的劳动，并且提高稳定性。
而另一方面，本来运维只管交付资源，给你个虚拟机，虚拟机里面的应用如何相互访问我不管，你们爱咋地咋地，有了Kubernetes以后，运维层要关注服务发现，配置中心，熔断降级。
两者融合在了一起。在微服务化的研发的角度来讲，Kubernetes虽然复杂，但是设计的都是有道理的，符合微服务的思想。
http://dockone.io/article/4892
标签：没有 exe polar master 工程 poi cal 耦合 机房
原文地址：https://www.cnblogs.com/doit8791/p/9979461.html
