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

云计算技术源于互联网公司，现在云计算已经是下一代企业级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这些互联网巨头都是微服务的先行者和倡导者。遵从微服务设计，使得互联网巨头的业务应用具有良好的可扩展性：一方面保持业务应用快速迭代，同时应用迭代速度没有随着业务规模扩展急剧减缓；另一方面保证业务应用具有弹性伸缩能力，能处理海量业务带来的巨大负载。

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

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

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

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

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

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

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

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

5、微服务构架使得持续集成和持续交付变得更加便捷。对比传统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的管理调度方面，包括服务发现、负载均衡、灰度发布、弹性伸缩等等。