13558人阅读
容器（95）
云管理平台（30）
文/&天云软件 技术总监 牛继宾
伴随着Docker技术的兴起，以及容器集群管理平台Mesos、Kubernetes、Swarm、Rancher等的大行其道，仿佛PaaS平台及其相关技术一下进入了黄金时期，各种各样的技术组合，各种各样的技术验证，以及伴随着容器相关的创业公司布道，仿佛只要有了PaaS平台及其相关的技术，就能解决一切的企业IT问题。但是，企业IT，尤其是非互联网传统企业，PaaS平台的构建与业务上云是一个长期的过程，绝不是一个Docker+kubernetes/Mesos/Swarm构建完以后就能完成的，IaaS年代是这样，PaaS年代也是这样。
在互联网公司或者自研发型的应用，开发环境与部署运行环境非常的类似，这也是Docker或者容器相关技术在应用上的一个很大的优势（比如构建开发、测试、部署的DevOps流水线），但是在传统企业便不一定能行得通，比如某个企业的IT应用开发维护是外包的，标准软件需要采购、应用开发需要在应用开发商完成、硬件是另外的硬件提供商，到货后需要硬件系统集成、标准软件部署、应用开发部署调试，需要很多供货商来完成，往往以项目经理统筹完成，很难由一套DevOps之类的平台来解决所有问题。
那么传统企业PaaS平台设计需要什么样的功能？上云时又需要进行如何改造？这是本文探讨的重点。
一、传统企业的应用架构与应用分类
大家对这种架构耳熟能详，但也请做云计算或者容器技术的同事不要对这种架构嗤之以鼻，因为这种架构也包含很多对我们有学习借鉴意义的技术模块：
SAN存储：包括高、低、中不同的存储，存储中磁盘的RAID配置、存储池配置、存储的集群配置、存储的容灾备份、数据的热点迁移、数据的缓存、存储之间的SAN交换机配置（划分Zoning，连接主机）等都需要专业的存储工程师（衍生出来了很多的认证），这种存储可以做到高IOPS、低延迟、高可靠性，是目前大多数的分布式存储难以匹敌的，且目前存储厂商在SAN上也做到了虚拟化；主机：小型机、x86服务器，小型机以IBM小型机为例，小型机虚拟化比x86虚拟化出现的年代早了几十年，当时是硬分区技术，后来发展到逻辑分区+IO虚拟化，逻辑分区可以做到分配0.1个CPU的细粒度，同时也在2007年就推出了类似于容器的技术，做到了进程级别的隔离，但因为不开源、不方便打包、镜像管理没有Docker方便，最终只在少数客户处进行了部署使用；DB：传统的数据库厂商比如Oracle为例，很早就推出了RAC技术，同时，2012年左右Oracle研发中心内部就开始使用Container技术搭建DB as a Service（这比我们目前大多数的Docker相关的创业公司还早）；APP：以IBM WebSphere为例，十年之前就有WAS集群的概念，可以部分做到横向扩展。
传统企业这种架构统治了企业IT数十年之久，在大的行业，通常以商用中间件、商用DB、小型机、SAN存储部署。这种架构存在扩展性不足的问题，但是在传统企业架构中大量存在。
我们部署一个IT系统，最终的目的是为了解决传统的问题，所谓把线下业务线上化，这些业务最终的服务对象是数据，而数据处理大致可以分成两大类：联机事务处理OLTP（on-line transaction processing）、联机分析处理OLAP（On-Line Analytical Processing）。
当然还有其他的业务类型，比如银行或者运营商的每月出账系统，这种系统为也是一种批处理系统，但是实时性很强，跟Hadoop MR所谓的批处理不是一个概念，也不在一个层级。这种应用我们暂时不考虑。
OLTP，也叫联机事务处理（Online Transaction Processing）系统，表示事务性非常高的系统，一般都是高可用的在线系统，评估其系统的时候，一般看其每秒执行的Transaction以及Execute SQL的数量。典型的OLTP系统有客户关系管理系统、电子商务系统、银行、证券等。
要求：一致性、高可用性。
OLAP，也叫联机分析处理（Online Analytical Processing）系统，有的时候也叫决策支持系统，就是我们说的数据仓库。在这样的系统中，语句的执行量不是考核标准，因为一条语句的执行时间可能会非常长，读取的数据也非常多。所以，在这样的系统中，考核的标准往往是磁盘子系统的吞吐量（带宽），如能达到多少MB/s的流量。
下面我们分别分析一下这两类应用的云化需求与云化的分析。
注意：这些要求分析与要求是在Docker与各类容器管理平台火起来之前总结与做的，不是依据Docker或者容器相关技术的要求做的。所以，对我们跳出容器的惯性思维，构建一个适合传统企业的PaaS云平台有很强的指导意义。
二、传统企业的应用云化改造需求
（一）OLTP类应用云化的要求
云化关键点1：系统弹性伸缩
通过应用与数据分离和集群化部署，实现系统快速扩容、处理能力灵活水平线性扩展、故障自动隔离。对于独立的应用主机可以进行灵活弹性伸缩。
弹性伸缩特点：
在线快速扩容：系统扩容操作低耗时、无数据迁移、服务不间断；处理能力线性扩展：系统处理能力可以通过新增节点近线性提升，实现高吞吐、高并发处理能力，应对业务爆发式增长；故障自动接管：集群可以自动发现故障节点并调整任务调度策略，在不影响处理的同时接管故障节点，保持系统高可用。
云化关键点2：应用集群化部署
将紧密耦合的大应用模块化拆分为多个模块化小应用，通过资源池提供系统资源的整体利用率，并将拆分后的子模块部署于资源池（后来我们搞Docker的称之为微服务化）。当硬件资源实施池化后，才具备了支撑应用的弹性伸缩，实现硬件的按需分配的基本需求，充分提高资源利用率。
云化关键点3：通过数据分级分类实现应用与数据分离
根据数据实时性、重要性、敏感性等因素，将数据分成数个级别，各个级别的数据对系统的作用、采用存储、保护方式也都有所不同。
通过对应用提供数据的透明访问，屏蔽数据的位置差异、数据分布差异、数据存储等差异：
位置无关性：数据在远程还是本地存储，对应用最好透明。分布无关性：数据分布在多个数据节点，对应用透明。比如查询某个客户的所有相关数据，虽然同一个用户信息分布在多个数据节点上，但对应用来说就好像一个集中数据库进行查询。存储无关性：数据存储在内存库、物理库（关系型数据库、NoSQL数据库）、File还是缓存等介质，对应用透明。
云化关键点4：合理规划实现数据分布式部署
对不同业务的数据、不同类型的数据进行有效规划部署。通过某种特定的条件，将存放在同一个数据库中的数据分散存放到多个数据库上，实现数据分布存储，通过路由规则路由访问特定的数据库。
数据库拆分方式包括：
垂直（纵向）拆分：将数据库表按业务、功能拆分到不同的数据库表，比如分为客户资料库、订单库、资源库、资料库等，这种方式多个数据库之间的表结构不同；目的是降低业务之间的影响，减少系统承载压力。水平（横向）拆分：将同一个表的数据进行分块保存到不同的数据表中，这些数据库中的表结构完全相同。
拆分以后，带来的问题，需要做到：对外提供统一访问，对应用屏蔽数据访问复杂度。数据访问层提供数据互访能力，拆分访问合并返回。
所以需要构建统一数据访问引擎，或者数据路由层（Data layer层）。开源的比如有Hibernate Shards、Ibatis-Sharding、淘宝TDDL等。
云化关键点5：数据平台化
数据平台化是指通过应用架构和数据架构的重新梳理、规划与调整，将业务处理中的业务数据和状态数据与应用分离，实现应用的轻量化、无状态；构建统一的数据访问层，实现数据的共享访问。数据平台化是数据处理水平线性扩展的前提和基础。
数据平台化特点：
应用轻量化：缩短开发周期，提升新业务响应速度；应用无状态：实现应用的同质化，应用层处理能力的独立扩展，实现应用灵活调度和分配；数据共享访问：逐步实现数据集中访问，跨地市的流量共享、流量统付、流量转移业务能够更高效支撑。
（二）OLAP型应用云化的需求
首先看一下传统的数据仓库典型架构：
这种架构以处理结构化数据为主，基本部署于Oracle、小型机、SAN存储之上，扩展性不足，难以处理海量数据。大数据处理技术的兴起让这类应用的云化找到了思路。云化时总体推荐混搭架构，即采用多种技术架构建设大数据中心：
1. 垂直混搭架构：
这种架构比较容易部署，但会形成多个相互独立的信息孤岛；未来缺乏可行的系统演进路；
2. 水平混搭架构：
企业级数据云平台：逐渐实现企业内数据的统一存储，承载数据的加工计算；未来提供企业数据的统一存储和计算能力；数据仓库、集市和挖掘库：计算逐渐迁移到云平台实现轻载化；直接从云平台加载应用结果数据，实现上层应用的兼容性；流处理平台：实时计算结果存储到云数据平台，可通过能力开放平台的消息中间件直接供应用访问。
OLAP云化关键点1：数据计算引擎开源化
M/R计算引擎：用HDFS文件保证每一步计算结果，避免硬件故障导致重头执行。
优点：可靠性高；缺点：数据处理任务是一系列M/R任务的串行执行，输入和输出都是HDFS文件，导致频繁的磁盘I/O，执行速度慢；局限性：原始单一的编程模型和数据结构，导致开发效率低，限制更多应用的产生。
Spark计算引擎：RDD是分布式内存的抽象。
优点：执行效率比起M/R提升100倍以上；提供丰富的操作算子增强编程能力，简化应用开发；缺点：对内存等资源要求高；可靠性不如M/R；Yarn实现资源调度和分配：一个节点上可同时执行M/R和Spark任务，资源相互隔离、执行互不干扰。
OLAP云化建设关键点2：数据集市云化建设
建设现状：传统小机+Oracle数据库和新建的MPP数据库两种建设模式。
演进策略一：用MPP数据库来取代小机+Oracle数据库；演进策略二：用数据云平台+开源MYSQL/PGSQL集群来代替小机+Oracle数据库。
数据云平台完成所有的后台计算。
OLAP云化关键点3：数据ETL云化建设
传输的实时化：支持MQ等分布式实时消息传输机制；基于内存的计算：数据不落地，避免海量数据的两次重复加载；计算的轻量化：清单级的过滤、排重、规则化，更多的计算任务由大数据存储和计算平台来完成；分布式并行执行：高可用性、分布式调度、资源分配；技术实现：Kafka+HDFS+MR/Spark。
三、基于容器的PaaS平台架构的构建
我们提到了传统企业中两类核心的应用，并且在Docker流行之前便规划了一些云化的关键点，并形成了PaaS平台，使之运行于IaaS平台与Hadoop YARN集群之上。
基于此架构有以下几个主要问题：
可以实现应用编排与部署，但是编排的基础单元是虚拟机模板，模板比较重，而且镜像很难修改，编排、分发、运行、持续集成等都有很大的困难，因此构建在模板上的应用形成的服务很难用；基于虚拟机的弹性伸缩相应时间也比较慢，我们尝试做过基于Cloudwatch+Autoscaling的虚拟机弹性伸缩功能，发现弹性伸缩对业务的响应时间有一个偏差，这个偏差大约在十几分钟，在抢购、秒杀等业务中基本不可接受；很难在企业内部形成一个统一的私有云集群来同时运行这两类业务，因此两个PAAS集群实际上是两个独立的集群，都是按照业务最高峰配置，存在资源浪费的现象，运维也是分开运维。
Docker及其相关技术兴起之后，我们基于容器的相关生态圈技术，构建了新一代PaaS平台。
使用容器+容器镜像管理替代服务目录管理+虚拟机模板管理。
在Instance PaaS（iPaaS）平台上除了基于Kubernetes的容器管理、镜像管理、应用管理等功能，还构建了如下子系统：
日志子系统：基于ELK实现；计算子系统：集成OpenStack与自研的Skyform CMP；存储子系统：通过Cinder，支持ISCSI、NFS、Ceph三类存储，与IaaS打通；网络子系统：我们选用了Netron+OVS的SDN解决方案；监控子系统：通过Ceilometer+MongoDB进行实施数据的监控、Phoenix+Hadoop进行历史数据分析；用户交互子系统：基于Node.js开发。
整体的PaaS平台构建基于Kubernetes、Hadoop、Spark on Mesos，构建完整的DCOS平台。
需要说明的是，在传统企业在云平台还需要对接大量的系统，比如ITIL、4A/3A、人力资源系统、审计系统等，这些系统与云平台的接口集成不在本次讨论范围内。
下面说一下基于以上的PaaS平台对传统应用云化关键点的解决。
针对OLTP类应用云化的5个关键点的解决：
系统弹性伸缩：通过Kubernetes RC+service实现；应用集群化部署：通过Mesos/Kubernetes构建x86集群，将应用分布式改造以后部署与集群；通过数据分级分类实现应用与数据分离：通过Big data PaaS的HDFS服务与Instance PaaS的DB服务可以提供部分数据分级服务的基础，但是数据分级与存储，以及访问透明性未能完全实现，需要在业务层面进行适配；合理规划实现数据分布式部署：通过在Instance PaaS提供数据库服务，以及开开源数据路由服务，实现，注：需要DBA规划数据的存储；数据平台化：应用改造后即可实现。
OLAP云化的3个关键点的解决：
数据计算引擎开源化：可由Bigdata PAAS直接提供MR、Spark服务；数据集市云化建设：可由Instance PaaS平台提供开源MySQL+TDDL实现；数据ETL云化建设：可由Instance PaaS提供Kafka、Big data PaaS提供MR、SPARK实现。
四、PaaS平台问题及传统应用上云改造的一些注意点
（一）基于Kubernetes、Hadoop、Spark on Mesos的问题
这种调度实际上是两级的调度框架，Mesos本身只管资源（主要是CPU与MEM），提供offer给上层的调度框架使用。一级调度即Mesos层有两种调度模式：
Mesos粗粒度，这种模式下，一旦一台机器（一个Node）分配给某个框架，其他框架便不能使用；Mesos细粒度，这种模式下，多个框架可以共享一台机器（一个Node）。
粗粒度存在资源还是不能完全共享的问题，因此仍然有资源浪费的问题，细粒度模式可以改变这种问题，但是又带来新的问题：
Mesos集群运行多种框架，包括Spark，也运行着很多Web、中间件、数据库等服务，但是Mesos不支持抢占，无法设置任务优先级，而Spark默认是贪婪模式，这样就会出现Spark运行时无法发布其他Web任务到Mesos集群上的情况。Hadoop与Spark在运行时，Shuffle阶段数据会交互写HDFS磁盘，这时网络资源会被大量占用（我们称之为东西向流量），导致Web服务基本不能响应（我们称之为南北向流量）。
（二）多租户的问题
目前多个框架之间每个都有自己的用户管理模式，默认情况下，如果多个框架之间有交叉使用，需要在多个框架之间租户互相打通，涉及到Mesos、Hadoop、Kubernetes的账号打通问题，需要开发独立的账户中心，并且完成同步。
最后讨论一下应用上云时的考虑点，并给出一个例子：
应用最好无状态，无状态化的应用天生适合上云。这时服务的注册于发现、应用的弹性伸缩完全交给云平台来做，比如Mesos+Marathon的HAProxy+etcd+Confd或者Kubernetes8s的service+RC；已经集群化的应用组件部署相对困难，比如基于PaaS平台发布单个实例的Redis容器，但是发布Redis集群就比较困难，苦难就困难在Redis集群中的节点需要相互通信，而容器如果重启或者IP发生变化都会对集群造成影响；服务注册与发现如果应用本身提供了，PaaS平台的服务注册与发现功能便不能使用，不能两套服务注册与发现同时使用。
这里给出一个应用上云部署的例子：
上图左边是某传统企业电商应用最初架构，Web部署于一台高配置x86服务器、APP部署于一台中端小型机、DB部署于一台中端小型机，右边是初步进行了改造后的架构，即迁移到PaaS平台之前应用已经做了模块化与集群化的初步改造：
前台用负载均衡将流量引入到三个Web节点中，每个Web节点部署于x86服务器，Session集中存在Redis集群（无状态化改造，交互用HTTP+JSON短连接）；APP层也通过Redis集中存放状态信息，做到了无状态化，每个APP节点部署于三台x86服务器；Web与APP在流量大的时候可以做到手动扩容，但是需要配置固定的IP，APP服务（提供给）的注册发现是基于ZooKeeper完成（应用自己来完成服务注册于发现）；DB层做了主从数据库，部署与x86服务器。
该应用里面还用到了Kafka，用来做数据总线，也采取了集群化部署。
针对目前的现状，如上图，应用迁移到PaaS平台需要做三方面的工作：
完成Web层的服务注册与发现，在此基础上实现web层的自动扩缩容，此处基于Kubernetes的ingress service（一个改造后的Nginx，运行在一个Kubernetes的POD里面）实现软负载+RC控制节点伸缩实现（每个Web部署于一个pod）；APP层的自动扩缩容，由于已经完成了基于ZooKeeper的服务注册于发现，所以只需APP层能够弹性伸缩部署即可；此处基于RC控制节点伸缩实现；DB层由于运行稳定，暂时不做PaaS化但是，基于访问路由做到分布式部署。
剩余一个问题需要探讨，Redis集群、ZooKeeper集群、Kafka集群（用作消息总线）要不要做PaaS化？如何做？
首先回答一个问题，Redis、Zookeeper、Kafka等集群PaaS化（容器化）的难点在哪儿？
主要是这些集群节点之间的互相通信与数据传输即东西向流量，要求这些节点之间的IP配置需要固定IP，而且重新启动以后相应的配置信息不能改变。容器自身的启动、网络配置比较动态化，对需要固定的集群配置而言是一个挑战。
比如大多数的PaaS平台提供单个实例的Redis缓存服务不是问题，但是提供任意配置的Redis集群便不支持。我们经过前期的测试，实现了容器平台下的此类应用的集群化部署，以ZooKeeper为例：
ZooKeeper自身部署要求：
ZooKeeper client依赖固定ZooKeeper server IP来完成服务；ZooKeeper server配置（所有成员IP必须固定）；至少3个独立节点；
解决方案（基于Kubernetes）：
Client通过固定3个service IP连接ZooKeeper server；构建3个单POD的RC；配置DeamonSet，指定ZooKeeper的POD所启动运行的主机；ZooKeeper自身配置使用Service DNS name；存储进行持久化。
最后，需要说明的是，应用上云后一个很重要因素，PaaS平台（Docker为基础的构建），稳定性与可靠性也是至关重要的，我们在部署迁移应用时，每次都会针对应用做较为详细的测试，测试案例包括：
无负载的POD并发测试；频繁创建带业务的POD及其稳定性；业务的并发性测试；不同业务的IO并发性能测试；容器间网络性能测试；几类常见的数据库性能测试；Nginx集群性能测试；Kubernetes Rc机制测试；Docker对MEM资源限制能力的测试；Docker对进程数量限制能力的测试；
等等。这些测试方面供大家参考，具体测试方法与步骤可针对应用自行设计，不在这里具体分享。
Q：在你的新一代PaaS平台中，我怎么对公司的很多个不同的应用做不同的集群，有些集群偏向于大量的IO占用，有些集群偏向于大量的网络占用，有些集群偏向于大量的内存占用，并且启用的集群间还有通信和交互，针对这些不均衡现象该如何处理？
A：所以PaaS平台硬件资源会针对不同应用去做区分，在企业私有云建设时，需要对应用进行梳理，将不同的应用分类，底层采取相应集群支撑，比如计算密集型、IO密集型等，同时综合考虑波峰波谷与业务特性进行配置。
Q：公司有很多Web系统，每一个Web系统都有自己的存储、数据库，所以如果融入PaaS平台的话，首先第一点软硬件问题如何做到全部满足，其次就是就算把我的DB层整合迁徙到你的PaaS的DB层，我是不是还要做其它方面的投入，比如开发成本等等，还有就是DB的兼容性是不是会有问题？
A：Web层我们推荐做无状态化，且要做应用与数据分离，session信息集中存放。DB迁移到PaaS层是一个比较慎重的过程，PaaS层优先考虑开源数据库。如果原先是MySQL基于PaaS平台也提供的MySQL数据库服务，那么开发成本基本比较小，只需考虑版本问题。
Q：请问MySQL部署数据应用能承载多大数据量，响应速度如何？
A：我们一个项目中，采用读写分离的MySQL架构，几千万的数据表，及时查询没问题，这也要看硬件配置与数据索引的建立等。
Q：有些传统公司，有些软件设备是以序列号安装使用的，所以这一块融入PaaS平台是不是不太可能？
A：比较困难，另外还有一个问题是License限制的问题，在弹性架构中也比较难。
Q：请问架构改造会不会导致应用要重新开发？
A：会，从IOE架构到x86架构，从x86物理机到虚拟机到Docker，应用需要以越来越小的模块化分布式部署，也就是说逐步向微服务化过渡。
Q：为什么Kubernetes和Mesos要一起用呢，考虑点在哪里？
A：针对单个应用Docker化，我们开始的选型定位在Kubernetes，主要考虑了POD的应用场景更类似虚拟机，另外Kubernetes的模块比较丰富，像负载均衡、服务发现等已经成熟，后来用Mesos是因为需要把大数据之类的应用进行整合。需要Kubernetes/Spark on Mesos。
Q：开发周期过长或者客户开发能力弱会导致整个架构流产 有配套的应用改造方案吗？
A：对传统企业而言，一开始就搭建一个大而全PaaS方案是不现实的，我们推荐从某一个典型应用做起。我们针对交易性应用、分布式应用、批处理应用等应用都有配套改造方案。
Q：Mesos使用集中式存储和分布式存储效率上有什么不同吗？
A：这个看应用，集中式存储在集群中应用时，如果针对单一与应用划分Volume，性能会好一些，如果是分布式应用，比如MR类的应用，分布式存储反而会好。
Q：容器弹性伸缩策略具体怎么考虑的，CPU？
A：CPU、内存、IO、用户连接数等都可以作为弹性伸缩的策略依据。
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：1639775次
积分：11911
积分：11911
排名：第1167名
原创：73篇
转载：53篇
评论：51条
(3)(4)(5)(4)(5)(4)(6)(4)(6)(6)(7)(24)(11)(13)(10)(7)(8)主题信息（必填）
主题描述（最多限制在50个字符）
申请人信息（必填）
申请信息已提交审核，请注意查收邮件，我们会尽快给您反馈。
如有疑问，请联系
傻丫头和高科技产物小心翼翼的初恋
如今的编程是一场程序员和上帝的竞赛，程序员要开发出更大更好、傻瓜都会用到软件。而上帝在努力创造出更大更傻的傻瓜。目前为止，上帝是赢的。个人网站：。个人QQ群：、
个人大数据技术博客：
人生得意须尽欢，莫使金樽空对月。
【CSDN现场报道】日-20日，由CSDN重磅打造的年终技术盛会 —— “2016中国软件开发者大会”（Software Developer Conference China 2016，简称SDCC 2016）在北京京都信苑饭店隆重举行。本届大会云集了100多位国内外顶尖专家和技术大牛，共设新趋势和新实践2大主题会场，14个技术专题。面向国内外的中高端技术人员，聚焦最前沿技术及一线的实践经验，助力企业的技术升级和改造、全面提升技术人员的综合实力。在11月18日上午的Keynote上，华为PaaS首席系统工程师俞岳带来了“新一代华为PaaS平台助力企业IT全云化转型”主题演讲，通过回顾云化挑战、技术发展趋势，以及华为PaaS平台的架构设计，全面分享了华为公司在云计算领域的思考和实践。企业转型素来说易行难，阻碍这一进程的三大山分别是组织流程、应用架构，和系统平台建设。他指出了“部门墙”烟囱式设计以及单体应用架构带来的升级时间窗等问题。同时分析了企业应用架构由单体应用到松耦合的SOA再到Micro Service一步步细粒度拆分的云化进程。此外，PaaS平台现在在企业内部显示出碎片化的形式，而未来的PaaS平台一定是一个统一架构的开发平台。最近的容器技术在PaaS平台的演进历程中扮演着重要的角色，Docker的出现给PaaS平台带来了新的技术和发展，“Docker是进程，PaaS是机器”。（）华为PaaS首席系统工程师 俞岳以下为演讲整理：各位来宾大家上午好，欢迎大家来参加中国软件开发者大会，我是俞岳，来自华为，现在担任PaaS平台的首席系统工程师。非常高兴能在这里跟大家一起探讨一下我们华为公司在云计算领域的一些相应思考和实践。我将从三个角度来阐述我们的PaaS平台：首先同大家回顾一下我们华为公司在和企业探讨云化转型中遇到的问题和挑战，以及PaaS最近的一些技术发展趋势。最后分析华为PaaS平台系统架构的构建，以及如何解决这个问题。企业转型三大挑战烟囱式应用系统常言道“江山易改，本性难移”，企业转型说来很容易，但在企业真正转型的过程中，遇到了很多困难的问题和挑战。我们通过和客户的调查，总结出来大概有3个非常大的挑战。第一个挑战是，现在企业内部在做系统架构时，应用架构设计采用烟囱式构造，不同的业务部门根据自己的需求采购，从底层的云平台到操作系统，到中间到上层的应用系统都是独立完成的，各分散的业务部门之间缺乏一定的共享，而且他们在构建应用系统的过程中，往往都按照资源最大利用率的情况来生产。比如说我们为了应对双十一，会按照资源利用率最高的工作负荷预留一个资源，这就会造成系统大多情况下都是闲置的。据统计，在一般的企业数据中心里，资源利用率只有10-20%，而一些大的互联网企业，比如谷歌、脸书，他们的资源利用率达到30-50%，这意味着巨大的资源浪费。此外，企业在构建应用系统时，技术架构、中间件有各业务部门（合作ISV）独立选型、采购，OS、中间件选择并没有完全统一，类型众多，我们称之为“七国八制”，而且革命应用系统根据他们业务的需求，采购的操作系统数据库也不相同，因此在企业的数据中心里，这种业务系统会非常繁杂，很难统一管理——这个第一个挑战造成了企业内部资源服务难以共享。单体应用架构随着业务部门的开发产品不断叠代，中间的代码变得越来越臃肿，传统的架构模式都是CS或者BS的结构，会把大多数的应用逻辑放到应用程序中间，就造成了应用程序的逻辑不断膨胀，使整个应用系统变成一个非常庞大的单体式应用。在我们内部的IT系统建设，最早也是基于这种模式。日积月累后发现，这种单体应用架构完全缺乏敏捷和弹性，部署扩容慢，产品升级尤其困难，往往需要通过业务中断的方式进行。开发与运维割裂 企业端到端的开发流程由来已久，由产品需求方——开发——测试——运维的流程尤为漫长，而且各个职能部门承担不同的工作，部门之间存在“部门墙”。有一句话，如果大家熟悉康危定律，就是“组织架构决定了产品架构”，由于组织的构建方式，造成产品整个开发流程非常长，而且每个环节都会有自己相应的环境，自己的系统。整个的开发流程中，开发环境的不一致，以及部门墙中间的隔阂，造成了整个企业IT的应用就无法做到非常敏捷。发展趋势应用向CloudNative演进现在先进的互联网公司他们都是怎么做的？首先看一下应用架构的转型，现在都讲究向CloudNative转型，CloudNative是一整套的理论方法工具的实践的结合，它强调的是应用的敏捷、应用的良好架构以及完善的治理方式，如果向这个方面转型，其中微服务一定是它的方向。回顾企业应用架构几个不同的阶段，最早我们叫做“单体应用”，就是传统企业IT基于CS、BS的构建，集中在应用服务器这一端，变得非常臃肿，都采用纵向的伸缩方式，横向非常难，只能通过传统的维度叠加，不能做更细粒度的拆分。后来通过解耦发展为松耦合SOA，对应用颗粒度做了一些拆分，把原来的单体应用拆散，按照不同的独立的功能，把它拆成不同的服务，每个服务对外有一个清晰的接口，通过一个企业的应用总线把这些服务串在一起，完成高级的服务逻辑。这是服务化架构的一个构建方式，好的地方在于让你做服务化结偶，职能单一，但是在系统和系统之间偶合的时候，强调引入这个ESB的方式，我们发现在很多企业的实践过程中，ESB成了一个新的瓶颈，而且它是偏集中的一个架构方式，整个的总线的好坏就变成了企业应用好坏的一个最关键的问题。它的敏捷性做了提高，应用的颗粒度做了一些拆分，但是还是不能满足云化的敏捷的要求。之后随着云化理念引入，在SOA的基础上最先提出来的就是微服务架构，它的理念也是进行服务化解，但在实践过程中更加强调的是点对点，完全分布，更强调的是服务之间的治理、容错，需要在不可靠的服务基础上，构建一个可靠的业务系统，这也是微服务的核心理念。方式是通过微服务之间的治理、容错、隔离这些相应的技术来实现这种能力，使应用从业务的角度看变得非常稳定。还强调了扩展高可用等，每个服务都是由一个小团队来开发，服务和服务之间通过松耦合的点对点方式组合在一起，变成小的网状式结构。PaaS平台演进PaaS平台的历史至少有十几年了，现在PaaS平台在企业内部呈现出一个碎片化的形式。在企业内部会发现，每个云化的平台上都或多或少有一些工具搭建的Erlang平台。这种碎片化的PaaS会在企业内部造成一个混乱，会造成开发流程的断裂，应用无法从一个PaaS平台到另外一个PaaS平台。最新一代的相应的技术，能够帮助我们有效规避这些问题。我们认为未来的PaaS平台一定是一个统一架构的PaaS平台，最重要的使命是能够让企业真正聚焦于自己应用的开发，开发出真正敏捷、具有弹性的高可靠应用。这个PaaS平台上的那些基础服务，一定标准化的。还也一些服务是专业化领域服务，由在某一个行业、领域有非常多经验积累的厂商来提供专业化的领域服务。由这个核心PaaS平台，加上外面堆加的统一PaaS平台，才能真正解决企业的问题。容器技术给PaaS带来新的机会看一下容器技术，为什么说PaaS平台发展这么多年，真正的容器技术发展出来了以后，才有一个真正的进展。其实最早也说了，现在看PaaS是机器，就说明PaaS平台随着容器技术的引入，才能给企业的数据中枢带来一个真正统一的架构，它可以作为这个企业的数据操作系统。我们面对这个平台都是从上往下看的，以应用的视角看，才能满足应用敏捷性的需要。容器技术是操作系统子代技术，基与Linux构建而成，它只是这个技术的一个实现，并不是代表所有的容器技术，因为无论是谷歌还是其他的厂商，他们都有自己相应的容器技术。Docker，这样的才能真正做到一次构建，多次运行，只要你有一个镜像，找到可以支持Docker的平台你就可以开跑。容器打包，更希望容器系统是开放的，并不是只有Docker一家来垄断。最近基金会也出现了这个标准，就是为了更加开放，让不同的容器技术能够在同一个标准下互相进行良性竞争。Docker技术和原来的虚拟化技术相比，有很大的优势，它可以让应用直接访问内核和硬件。由此带来的无论是扩容还是安装速度，都比以前的裸机有一个数量级的飞跃，非常敏捷、高效。华为FusionStage架构说了很多企业的问题和一些新的趋势，如果要做一个新的PaaS平台，应该怎么做？这是我们新的PaaS所考虑的问题，我们基于以上的思考，认为这个PaaS平台应该采用分层的架构，分成两层，底下叫做PaaS内核，就相当于数据中心的操作系统，面向应用的敏捷系统，内核里面有很多标准服务，和业务没有关系，比如缓存、数据类的数据库、大数据、消息类的管理等都可以使用这个中间服务。再下一层是PaaS平台核心框架，要满足企业应用的开发、部署、治理的共同要求。对开发态，我们希望有一个开发流水线的框架，能够把整个流程打通。运行态需要一个强大的“心脏”，我们叫做调度和资源的引擎。还有微服务的治理框架，微服务开发稍微复杂一点，但是最难的是治理，因为微服务把应用拆散成很多小的部分，互相之间的借用非常复杂。除了PaaS底层的内核以外，上面这层希望与我们的合作伙伴来构建，叫做领域的服务，希望由每个行业比较资深的，或是行业里面耕耘多年的，对行业的业务非常了解的人来帮我们构建，通过这种分层，我们就可以清晰地定位出平台来做什么，业务做什么，通过这两方面的结合，希望给企业一个统一架构的完整平台，能够满足应用敏捷开发、运行、运维的需要。开发流水线框架是用以解决端到端的流程打通问题。我们认为在企业内部，开发流水线可以分成两个层次，上层叫做流程编排，下层则是流水线的编排。流水线编排是什么意思？我们觉得当企业内部去完成一个特定能力的业务功能时，可能需要一个流水线。举一个例子，我持续构建，代码开发完之后就打成一个包，我们称之为“持续构建的流水线”，测试部门有一个持续测试流水线，就是拿到开发提供的包之后，立刻部署，去跑持续测试。还有持续部署的，就是拿到这个包后不断地部署。这些小的流水线的框架组合在一起，可以完成一个大的业务功能，我们叫它“DevOps”的流程。流水线引擎的核心就是基于容器的相关技术构建起来的。这个流程引擎还需要让它具备一些灵活性，可以对接企业已有的工具，包括构建工具，或者其它部署。重要的是，除了能够对接已有组建，还有一个比较强大的能力——一个自定义组建，包装成一个容器来跑，然后把它插到流水线里组成一个完整的流程。最后介绍一下微服务的框架，刚才徐昊也说了，微服务是未来的必经之路，我们认为一个好的微服务框架首先要对不同的开发语言、框架做一些适配，都要有一些开发方向来支撑，让你的编程变得更简单，只要有一些定义的模式就可以了。中间有一个多性能的通讯总线，保证了微服务之间可以互通。最下面核心的就是微服务的运行和治理能力。首先是有一个微服务的目录，启动的时候都会注册，这个服务目录就会放到注册中心。还有一个配置中心，每个微服务互相之间的调用，或者互相之间的通用都需要配置中心的统一管理。配置中心要管设备的一致性，在互联网企业，考虑得更多的是用最终一致性来解决，实际上在企业内部，还有很多需要强一致性的场景，比如说要保证跨数据库或者是跨服务的交易要全部成功或者是全部失败。还有一点就是容错。微服务拆散了之后，在云的环境中会被视作不可靠的，每时每刻都会有东西挂掉。这个就需要微服务有一个强大的容错能力，或者快速失败，这个都属于容错的范畴。此外，要做隔离舱，要做熔断，都是在这里统一管理。最后，微服务里还需要一个链条，因为微服务运行起来之后，端到端很难保证，把微服务拆散后，就是把实验加长了，端到端的实验和故障难以定位，此处需要一个微服务的分析，把整个业务连在一起，出了问题之后，可以定位到不同的微服务的点上。【总结】三个框架定位解决企业内部不同的问题，一个是开发流程一体化的问题，还有应用架构的问题，以及平台构建的问题。更多精彩内容，请关注图文直播专题：，微博：，订阅CSDN官方微信公众号（ID：CSDNnews），即时获取大会动态。