云计算与 Cloud Native | 数人云CEO王璞@KVM分享实录

今天小数又给你们带来一篇干货满满的分享——来自KVM社区线上群分享的实录，分享嘉宾是数人云CEO王璞，题目是《云计算与 Cloud Native》。这是数人云在KVM社区群分享的第一弹，以后还有数人云CTO肖德时、COO谢乐冰的Docker与Mesos的应用实战经验分享，敬请期待！

嘉宾介绍

王璞，数人云创始人兼CEO
美国 George Mason 大学计算机博士。擅长分布式计算、大规模机器学习、海量数据处理。曾担任 Google 广告部门数据平台构架师，负责管理每秒访问量全球最高的架构平台。

分享实录

云计算技术源于互联网公司，如今云计算已是下一代企业级IT的发展趋势。云计算最大的特色是弹性和灵活，帮助企业应对复杂的业务需求。可是基于云计算的IT构架和上一代的IT构架有很大不一样，只有云原生应用（Cloud Native Application）才能充分发挥云计算弹性和灵活的特性。

目前，微服务是云原生应用比较主流的一种构架，微服务的理念是用服务来实现功能模块组件化，把大的业务逻辑拆为多个很微小的服务，每一个微服务实现一个简单的功能，微服务之间松散耦合。听从微服务构架的应用具备弹性和灵活的特性，可是在构架上，微服务比传统应用构架复杂不少。

PaaS平台的出现帮助开发人员打造云原生应用，让开发人员专一于业务开发层面，并为构架层面保驾护航。然而上一代的PaaS平台过于复杂和笨重，没有获得普遍的应用。基于Docker和Mesos打造的DCOS是下一代轻量级PaaS平台的典型表明，DCOS极大地下降了PaaS平台的复杂度，更加方便企业开发人员实现各类业务应用，帮助企业轻松打造基于云计算的软件基础设施。

Google如何作云计算

Google一直是云计算技术的领导者。我有幸在Google工做，接触到了Google强大的内部云计算平台。Google全部的数据中心加起来有大约数百万台服务器，这么多服务器被Google的分布式管理平台Borg统一管理，造成巨大的资源池，支撑了Google庞大的业务体系。Google把全部的服务器分红了近百个集群，每一个集群称为一个Cell。每一个Cell由几万台处于同一物理位置的服务器组成，每一个Cell由几个Borg主节点负责管理其他几万台服务器，被管理的每台服务器对应一个Borg从节点。

Google的开发人员会向Borg提交任务执行申请，Borg负责把任务运行在一个或多个Cell。Borg运行的任务有优先级，高优先级的任务会抢占低优先级任务的资源。为了防止过分抢占，Borg在管理每一个Cell资源的时候，任务优先级越高，可供分配的总资源越少，反之，任务优先级越低，可供分配的总资源越多，保证低优先级的任务也会获得很好的执行，而不会总被高优先级任务抢占。

Google内部虽然没有强调PaaS、容器、不可变基础设施（Immutable Infrastructure）以及微服务的概念，可是Google内部到处体现着这些理念。

首先，Google内部的云计算平台除了Borg，还有各类软件基础设施，好比Google File System、MapReduce、BigTable、Chubby、Stubby、PubSub等等，组成了一个功能无比强大的PaaS。这些软件基础设施知足了基于Google内部云计算平台开发时碰到的各类需求，使得Google的开发人员在开发时很是方便，能够专一于业务自己，而没必要过多考虑可扩展性、容错性等等复杂的问题，极大地提升了开发效率。这正是PaaS的功能，提升开发效率，下降开发复杂度，保证应用的性能、可靠性等等。

其次，Google内部的业务应用，都是把业务程序和各类依赖库打包在一块儿，造成巨大的二进制文件，这样应用程序在生产环境的服务器上运行的时候，不须要额外的依赖。更进一步，Google内部不一样应用程序在同一服务器上运行时，是用Cgroup技术进行资源隔离，防止某个程序占用过多资源。这些其实都是容器的理念，让应用程序具有了可移植性，并对应用进行资源隔离。

再者，Google内部生产环境服务器，基本上是被Borg自动管理，每台服务器上只安装Linux、Borg程序以及必备的监控程序等，开发或运维人员几乎不会登录上去作什么操做。这样，Google每台生产环境服务器的状态都是不可变的，极大地简化了对服务器的运维管理工做，这正是不可变基础设施的理念。

另外，Google内部也是按照微服务的方式来组织构架团队。Google各个大的部门内部，按照不一样的业务功能划分出不一样的小团队，每一个小团队负责开发维护一个具体的功能模块组件，也就是一个“微”服务。不一样微服务之间经过远程过程调用（RPC）相互协同依赖，实现了很大规模的业务。好比我以前所在的团队，是负责Google广告平台用户数据收集的业务，所维护的微服务有数千个应用实例在运行。

云原生应用与传统架构

云计算最大的特色是弹性和灵活，企业采用云计算技术能够轻松应对复杂的业务需求。通常来讲，云计算分为三层，IaaS、PaaS和SaaS：IaaS提供资源弹性，PaaS提供应用弹性，SaaS提供服务弹性。目前IaaS和SaaS相对成熟，PaaS相对早期。PaaS最大的做用是帮助企业打造云原生应用（Cloud Native Application），使得企业的业务应用充分享受云计算带来的灵活和弹性。

传统IT构架最大的问题在于不能知足复杂的业务需求。企业信息化通过多年发展，不少企业的业务已经实现了IT化。每家企业都面临着激烈的商业竞争，业务的需求每每纷繁复杂，势必要求IT系统能灵活应对业务的需求，但实际状况并不是如此，每每是企业业务部门的需求很长时间IT部门才能实现。云计算的出现，很大程度缓解了企业内部IT跟不上业务发展需求的矛盾。

云原生应用的优势体如今具备良好的可扩展性、伸缩性和容错性：当业务需求发生变化时，云原生应用能够作到快速迭代；当业务规模发生变化时，云原生应用能够作到弹性伸缩；当IT系统出现软硬件故障时，云原生应用有良好的容错机制，能够作到让业务应用不宕机。云原生应用的这些特性，能极大地帮助企业提高业务能力，在激烈的竞争中占据优点。互联网公司的快速发展，已经印证了云计算技术和云原生应用相比传统IT构架的巨大优点。

可是云原生应用的种种良好特性并非很轻易就能实现的，企业开发人员在开发业务应用的时候，还要考虑将来应用的可扩展性和容错性，这极大地增长了开发的复杂度。因而PaaS的出现，正是要帮助开发人员下降云原生应用的开发复杂度，让开发人员仍是专一于业务应用的开发，为开发人员屏蔽底层细节。

PaaS每每会制定出一些开发范式，只要企业的开发人员听从这些范式，那么开发出的业务应用就能得到云原生应用的特性。可是以CloudFoundry为表明的上一代PaaS，因为规范过于复杂，没有在企业级获得很好的应用。下一代轻量级PaaS（Micro PaaS），特别强调轻量的特性，没有对开发人员制定过多的开发范式，更可能是在软件设计层面给出指导，极大地下降了使用门槛。好比，轻量级PaaS倡导应用听从微服务构架设计，就能具备良好的可扩展性；再如，轻量级PaaS倡导应用尽可能听从无状态设计，就能得到良好的容错性。微服务构架和无状态设计，更可能是软件设计理念，而不是诸如EJB、RESTful这样具体的编程规范，下降了开发人员的学习成本，对开发人员更加友好。

微服务和SOA异同点

微服务是眼下很是流行的应用设计框架。如前所述，微服务不是具体的编程规范，而是软件设计理念。微服务是伴随互联网公司业务规模快速扩张进而演化得来的设计模式，Google、Amazon、Netflix这些互联网巨头都是微服务的先行者和倡导者。听从微服务设计，使得互联网巨头的业务应用具备良好的可扩展性：一方面保持业务应用快速迭代，同时应用迭代速度没有随着业务规模扩展急剧减缓；另外一方面保证业务应用具备弹性伸缩能力，能处理海量业务带来的巨大负载。

微服务有几个主要的设计理念：

一、经过服务实现组件化。传统的IT构架是把全部的业务逻辑用一个大而全的应用来实现，各个功能组件模块是在一个应用内部。这样作的后果是模块之间很容易紧密耦合，随着应用愈来愈大，失去了可扩展性，一旦要修改业务逻辑，就会牵一发而动全身，致使应用迭代很是缓慢。微服务使用服务的形式来实现各个功能组件模块，各个模块间的依赖经过服务的方式来组织，即一个模块经过远程过程调用来依赖另外一个模块，每一个模块是一个微服务。这样作使得模块之间很容易松散耦合，每一个微服务规定好服务的形式，诸如请求的格式以及响应的格式，而后多个微服务组合起来共同实现整个业务逻辑。如图一所示。

图一：总体型应用程序与微服务架构应用程序

二、微服务的松散耦合构架，使得企业能够按照业务功能来组织团队，每一个小团队负责一个微服务，以下降团队间的沟通成本。不少企业的研发团队一般按开发职责划分，诸如前端开发团队、中间件开发团队、数据库团队等等。这样按职责划分加大了团队间沟通成本，由于每一个具体的业务需求都有可能涉及先后端，所以多个职能团队要配合才能实现具体的业务需求，这样无疑沟通成本很高。按照微服务的方式，团队是按业务功能来组织划分，而不是按照开发职责划分，这样可让具体的业务需求落在某个团队内部，避免涉及多个团队，从而极大地下降了团队间的沟通成本。这也符合康威法则：任何组织在设计一套系统（广义层面的系统）时，其设计成果都会直接体现该组织所使用的沟通结构。如图二所示。

图二：康威定律的实际体现

三、企业按照业务功能来组织团队，每一个团队负责一个微服务，能够作到“谁构建，谁运行”，这将极大下降运维复杂度。若是按照传统的IT方式，开发团队开发出来的应用交给运维团队去上线维护，不只周期长，并且运维复杂度高，由于运维团队毕竟不了解业务实现细节，应用出了问题还须要涉及开发和运维两个团队来配合。若是按照微服务的方式，每一个团队开发一个微服务，并负责该微服务的上线运行，不涉及运维团队，这样作不只周期短，并且下降运维复杂度，某个微服务出现问题仅涉及所负责的开发团队。“谁构建，谁运行”还可让每一个团队都经历整个产品的生命周期。采用微服务构架后，运维团队将更多负责总体业务相关的工做，好比总体业务的资源规划、稳定性、性能等等。

四、有了微服务，能够方便地作到离散化数据管理。每一个微服务能够自行管理各自的数据，包括不一样业务的数据、不一样微服务的配置等等，更加切实匹配业务需求。如图三所示。

图三：微服务架构的离散数据管理

五、微服务构架使得持续集成和持续交付变得更加便捷。对比传统IT构架，有了微服务，集成和交付的单元从大而全的总体应用变成了各个微服务。这样，每一个微服务均可以灵活地集成和交付，下降了集成和交付的复杂度，提升了业务应用迭代的速度，进而提高了企业的业务能力。如图四所示。

图四：微服务构架使得持续集成和持续交付变得更加便捷

微服务常常被拿来与十年前就提出的面向服务架构（SOA）进行比较，由于微服务和SOA有类似的主张。SOA实际所指的是利用企业服务总线实现的集成化总体应用程序，企业服务总线一般包含复杂度极高的消息跌幅、编排、转换以及业务规则应用等机制。准确讲，SOA是中间件时代的一种开发范式，微服务是云计算时代轻量级PaaS的开发范式。

支撑微服务的问题和挑战

前面提到微服务最大好处是使得应用具备可扩展性，方便灵活应对业务的复杂需求。凡事必有两面性，微服务提高了应用的可扩展性，可是微服务也有其复杂性的一面。

首先，微服务以服务的形式实现组件化模块化，不一样功能模块组件之间经过服务的形式，即远程过程调用的方式，来相互通信。这样一来，模块或组件间的耦合度下降了，可是通信效率也下降了。毕竟远程过程调用比共享内存的方式要慢不少。此外，为了提升应用的容错性，通常微服务之间的远程过程调用都尽可能设计为异步通信的方式。异步通信显然比同步通信在开发复杂度方面增长很多。

其次，对于按微服务构架设计的应用进行修改迭代的时候，若是要修改的部分仅限于某个或某些微服务组件内部，那就比较容易，不涉及微服务组件间的依赖，好比更改一个微服务内部的业务逻辑、把一个微服务组件分拆为多个微服务。可是一旦要修改的部分要牵扯到已有微服务组件之间的依赖，那改动起来仍是有必定工做量的，好比远程过程调用的接口修改，或者更进一步，从新定义两个或多个微服务之间的业务边界。若是微服务构架设计的很差，应用迭代的时候频繁更改微服务间的依赖关系，也就失去了良好的可扩展性。

再者，因为按照微服务构架设计的应用自然是分布式应用，势必在故障排除方面增长了复杂度。分布式应用的维护对远程监控的依赖很强，由于分布式应用会运行在不少台服务器上，并且会在不一样服务器上动态调度迁移，一旦发生故障，不可能要求运维人员逐一检查每台服务器，必须有统一的监控平台，实时监控应用的运行状况，并统一收集日志用于故障排查。此外，微服务之间若是是异步通信机制，也增长了错误检查的复杂度。

下一代轻量级PaaS：基于Docker+Mesos的DCOS

基于Docker和Mesos打造的Data Center Operating System（DCOS），是下一代轻量级PaaS的表明。以Docker为表明的容器技术，为DCOS和企业业务应用之间，定义了清晰的边界：DCOS提供统一的、标准的容器运行环境，知足容器运行时的各类需求，诸如调度、编排、容错恢复、弹性伸缩、服务发现、负载均衡、监控报警等等；容器内部封装企业的业务应用，为应用提供良好的可移植性。

DCOS的轻量特性主要体如今以下方面：

首先，企业的开发人员不须要了解容器以外的太多细节，使得开发人员能够专一于开发业务，下降了开发人员的开发复杂度。

其次，DCOS为云原生应用提供良好的弹性，包括可扩展性、伸缩性和容错性。开发人员听从微服务构架和无状态设计开发云原生应用，一方面能够经过DCOS快速集成和交付上线，加快迭代周期，另外一方面DCOS为云原生应用提供很好的弹性伸缩能力，能够按需使用计算资源，再一方面DCOS使云原生应用具备很好的容错能力。

再者，DCOS极大地下降了运维复杂度。DCOS实现了不可变基础设施，DCOS在每台服务器上只安装Linux、Docker、Mesos等DCOS的组件，不包括任何业务应用相关的依赖，再加上DCOS的容错机制，使得生产系统的运维复杂度大大下降。

总之，云计算是下一代企业级IT的发展趋势，云计算相关技术正在逐渐演化成熟，特别是PaaS领域的技术，正在快速发展。以DCOS为表明的下一代轻量级PaaS正逐渐为企业客户所接受。由于DCOS具备轻量的优势，只要企业开发人员听从微服务和无状态设计开发出云原生业务应用，DCOS就能保证云原生应用具备良好的可扩展性、伸缩性和容错性。这极大地提高了企业IT的灵活性，缓解了IT跟不上业务发展需求的矛盾，帮助企业快速应对业务需求，提高企业业务能力。

精彩问答

QQ群 | KVM虚拟化1群

Q1. 云计算弹性与灵活，更多在应用业务的弹性与灵活、快速上线，然而须要庞大的基础设施支撑、同时须要虚拟化、容器技术支撑，若没有这些技术云计算很难作到弹性、灵活，请问在银行业务，银行更可能是的使用 小机 Powervm 云计算该如何去作呢？

A1. 目前 DCOS 还不支持小型机。云计算的趋势是x86化。

Q2. 云计算解决了应用业务快速上线，弹性与灵活，基础环境的灵活弹性。我的认为云计算须要庞大的基础设施（Datacenter）环境及高效的设施，基础环境设施很重要。

A2. 的确是很重要。并且数据中心基础设施复杂度很高，不该该每一个公司都搞一遍。数据中心必需要有很大规模，才能下降边际成本。

QQ群 | KVM虚拟化2群

Q1. 请问，银行如何转型新型IT模式呢，云计算将如何在银行领域进行落地呢？我的以为 IT 市场仍是在银行领域，1. 银行有钱 2. IT服务银行用的最多，最普遍。

A1. 云计算将帮助金融类客户减轻IT系统的复杂度，让客户的业务应用更轻量、有弹性，灵活应对复杂多变的业务需求。下一代企业级IT确定是要往轻量化方向发展，注重应用的弹性。
金融机构对IT服务有需求，并且有付费意愿

Q2. 企业如何去构架一个真正的云计算数据中心呢？构架成什么样才能达到云计算特性呢？

A2. 云计算最根本的特性是弹性。云计算的弹性包括三层：
IaaS 提供资源弹性，PaaS 提供应用弹性，SaaS 提供服务弹性。
包含这三层弹性才是完整的云计算弹性。

Q3. 真正的要将云计算进行落地，从技术角度该如何作呢？要遵循什么样的机制去构建云计算数据中心，或者说怎样能达到云计算、灵活、弹性。须要用那些技术作构建呢？

A3. 其实主要是 IaaS 相关技术和 PaaS 相关技术。
IaaS 领域主要的技术就是虚拟化技术，包括虚拟主机、SDN、软件定义存储等。
PaaS 领域的技术相对不够成熟，目前 PaaS 领域最流行的技术就是 Docker，还有对 Docker 管理调度的技术，好比 Mesos、K8s、Swarm 等，以及 Docke r网络和存储管理的技术，好比Calico 和 Flocker。

微信群 | 云实名技术

Q1. DCOS 是否是在 Docker 之上还作了管理？

A1. 是的，DCOS目前用Mesos管理Docker

Q2. 微服务应该是对一个传统的应用进行拆分吧？

A2. 确定要拆分。微服务的拆分不只是业务应用实现层面拆分，对开发团队的组织也要拆分红小团队。微服务的拆分不是按照开发职责拆（不是按前端开发、后段开发来拆），而是按照业务职责拆

Q3. 能具体描述下 Mesos 的功能吗？Mesos 和 Marathon 是否均可以管理 Docker，其差异在哪里？

A3. Mesos 主要是用于资源管理，Mesos 不直接管理 Docker。Marathon 是基于 Mesos 作任务调度，Marathon 支持管理调度 Docker 任务。

Q4. 咱们如今用 Kubernetes，可是实践中，碰到了太多问题，想换 Swarm，有什么好的建议吗，若是用 Mesos 呢？

A4. K8s 和 Swarm 都比较新，尚未通过很大规模生产系统验证。Mesos 相对成熟一些，Twitter 用 Mesos 管理上万台物理服务器。这些开源技术在易用性方面都有缺陷，毕竟只是技术不是产品。

微信群 | 《运维前线》

Q1. Docker 如何解决网络流量隔离的问题？

A1. Docker 目前在网络方面还很弱，目前没有很是成熟的方案，Calico 是咱们目前在尝试的方案

Q2. 把全部的服务拆成微服务以后是否是会给整个系统带来复杂性？这个微应该微到什么程度？

A2. 的确微服务会提升系统复杂度，因此微服务很是须要PaaS来简化系统复杂度。
微服务该多微小，这个没有通常性标准，要按照业务来定。通常来说，一个微服务最好实现一个单一功能。

Q3. 谁构建，谁运行，那微服务团队内部懂各类技术的人员都须要存在了，懂开发语言的，懂平台软件的，懂运维的，人员的成本是否也上去了呢？

A3. PaaS平台的做用就是下降开发人员的开发难度，减轻运维工做复杂度。有了PaaS平台以后，懂平台软件的人能够减小，运维的工做变轻，开发人员能够专一业务开发而无需考虑不少底层细节。

Q4. 没有开发能力的运维能上不？

A4. 能够，运维原本就不要很强的开发能力。PaaS平台就是要下降运维复杂度。Immutable Infrastructure会极大减轻运维的工做复杂度。

Q5. 单单靠一个paas平台实现太多，势必会形成另外的一个极端。

A5. 是的。因此PaaS平台自己也要轻量化。上一代PaaS没有流行起来就是由于不够轻量，不够灵活。云计算时代，企业客户都偏向轻量化的平台和应用。

Q6. 数人云在docker领域主要作了哪些改进，提供哪些特点功能或者服务？

A6. 数人云对Docker自己没有什么改动，就是标准的Docker开源版本。数人云的主要工做在对于Docker的管理调度方面，包括服务发现、负载均衡、灰度发布、弹性伸缩等等。