最近几年很多公司实现了从VMware等传统虚拟化到IaaS的转型，很多公司正在或者已经建立PaaS平台。那么从项目研发角度看，PaaS产品的系统功能应该主要涵盖哪些，又该如何更好的为应用研发人员服务呢?本文由云计算专家bryan根据社区活动中的分享交流所整理。

　　一.PaaS 建议的意义何在，能够给企业带来哪些价值?

　　1. 实现应用运行环境的标准化，提升交付速度：通过容器的镜像技术保证开发测试和生产等诸多标准化，避免因应用运行环境不一致带来的各种故障和问题，同时，通过服务编排实现运行环境的自动化运维和快速交付，避免传统方式的应用系统运行复杂、交付周期较长等问题；

　　2. 实现运维过程的高度自动化，降低运维成本：PaaS 平台提供多种自动化运维工具管理应用集群系统，比如智能负载可以实时观测集群节点的变化并智能修改路由配置，自动伸缩可以实现不同业务负载下集群规模的自动调整等，多种管理功能的自动化减少人工运维工作量，节省运维成本；

　　3. 有效提升基础资源的管理水平和硬件利用效率：PaaS 平台资源的容器是基于操作系统的虚拟化，与 IaaS 基础环境实现解耦，平台自身的实现多数是应用较广的开发框架和标准 API，能够有效提升资源管理水平，有效避免厂商绑定;同时，合理调整单个操作系统之上容器密度的有效部署，可以更好提升资源使用率，降低硬件采购成本；

　　4. 有效实现软件研发的技术路径统一和把控研发质量：通过运行环境的标准化可真正做到全公司技术路线的精细把控，做到统一不同项目组的技术研发路线，通过部署工具的统一可以做到 CI/CD 思想的有效落地实施，有效提升软件研发过程的质量把控水平;

　　5. 有效提升公司 IT 架构治理：相较于传统开发运维各司其职的模式，PaaS 能有效实现 devops 思维的落地实施，推动企业 IT 流程和人员架构的企业治理，更好的提升 IT 部门各个研发团队的整体技术水平，从而更好的响应业务需求。

　　二. PaaS 的主要技术有哪些?企业如何进行建设?

　　PaaS 主要以容器云形式实现，容器云依赖容器基础技术，目前常见的有 Docker 和 garden 两种类型，其中 BAT、京东、华为和网易等互联网公司，还有一些大型商业银行更多的选择 docker 技术，当然也不乏 garden 成功案例，但较之 docker 案例相对较少。

　　独木难成林，容器要云化形式提供服务，必须以多个容器形成集群的方式，此时如何管理和调度集群是一个重要的任务，这个任务由编排引擎进行实现，目前比较流行的有 kubernetes、swarm 等。因此「容器技术+编排引擎」构成了容器云最初始的框架，当然要达到企业级应用还需要做更多企业级的功能，所以就出现了诸如 openshift、阿里飞天、华为等各种以开源软件为基础构建的多种产品。

　　那么企业在建设云的过程中需要考虑几个问题：

　　1)容器技术的选择：尽量选择市场比较流行的开源社区和生态发展比较完善的技术，编排引擎的框架选择遵循同样道理;

　　2)建设模式：一种方式是购买产品进行企业落地化定制化，一种方式是基于开源框架自研，两种方式各有优劣，需要结合企业自身特点进行总体考虑;

　　3)建设规划：PaaS 的建设涵盖很多方面，甚至需要企业流程和企业 IT 架构的梳理和调整，因此对大中型企业来讲不可能一蹴而就，需要一个循序渐进的过程，这也与企业发展和自身技术特点有关系

　　三. 容器云的负载均衡如何选择?

　　软件负载有硬件 F5 和软件 HAProxy、nginx 等。F5 的特点是价格贵、性能好，一般在物理机和虚拟机化时间做 LB;nginx 是一款 HTTP 服务器和反向代理服务器，可以提供 7 层负载均衡能力，主要应用场景有 web 服务器、反向代理、负载均衡等

　　HAProxy 是一款专业的负载均衡软件，可提供 4/7 层负载均衡，比 nginx 负载均衡性能好，并发上也优于 nginx。负载均衡的选择需要和企业自身特点和具体业务场景相关联，在 PaaS 的企业级产品中更多的选择 HAproxy

　　四. PaaS 的日志和监控如何进行处理?

　　PaaS 平台的日志和监控和传统架构的管理方式没有本质区别。日志的获取或采用安装 agent、或采用工具导出，业界已经都有很多成熟的产品和案例可以借鉴;监控分两部分，先要解决「监」的问题，同样也需要利用工具抓取信息，然后解决「控」，要么利用自动化运维的模式，要么采用手工的模式，目的其实一样，区别在于成本控制。

　　PaaS 可以从系统、网络、服务、应用监控 4 个层面入手：

　　1. 系统主要指底层基础资源，如磁盘、CPU、硬件或 IaaS 等基础资源

　　2. 网络一般采用 SDN 的方式实现，监控比较复杂，主要有连通性、流量、7 层状态码等

　　3. 服务主要是指 PaaS 中的各种中间件服务服务，比如数据库服务、缓存服务、web 应用服务等

　　4. 应用监控是最上层的也是非常重要的，比如应用服务质量、响应时间、请求成功率等

　　五. PaaS 如何更好的实现 CI/CD，实现应用敏捷开发

　　PaaS 平台的一个核心理念是为应用提供各种基础中间件服务和进行应用集群的管理。devops 是一种贯彻项目研发全生命周期的软件研发理论，打破传统的研发部门和运维部门泾渭分明的现象，尽量实现团队将研发和运维进行统一结合的模式，这种理念落地实施需要借助一定工具。CI 是持续集成，可以实现代码自动化的静态检查、动态检查、安全检查和单元测试、集成测试等功能，从而实现代码的尽快尽早集成，减少后期发现问题的概率、降低项目风险;CD 是持续部署或者持续发布，这种持续部署采用自动化工具，能够有效提高系统环境的部署效率和升级更新时业务的连续性。

　　jenkins 可视作一个平台，在这个平台中一方面可以用户定制各种插件，一方面可以将所有的工作以流程化的形式 (pipeline) 串联起来。这样可以将 CI/CD 的思维通过 jenkins 的落地实施来贯彻执行，同时 CI/CD 有多种自动化管理功能，而 PaaS 中的相关系统部署或者更新升级或者项目研发过程使用的环境都可以自动化，于是二者可以很好的进行关联。

　　Devops 理念的落地实现，可通过 jinkins 中配置自动化的 CI/CD 流程，更好的与 PaaS 进行深度集成，从而提高软件研发效率和软件研发质量。详情可以参考链接

　　六. PaaS 的研究过程中有哪些关键技术点和难点，一般市场是如何选择的?

　　PaaS 作为一个综合性的平台，在以」容器+编排引擎」的基础上有诸多关键技术点和难点，本次主要以开源框架和一些市场产品为依托，主要讲述关键点的实现

　　1. 容器技术的选择：容器技术是整个平台的基石，犹如开发 web 需要选择开发语言一样，目前有 docker 和 garden 两种主流技术，自研技术选择时尽量选择技术相对成熟、企业应用案例相对较多、技术生态圈发展更多的技术，一般建议选择 docker，如果华为的 PaaS 产品初期选择 garden，目前也已转向了 docker，docker 已经成为一种事实上的标准。

　　2. 编排引擎的选择：编排引擎的选择一般会依赖容器技术路线的选择，比如 docker 容器可以选择 kubernetes、swarm 等框架，garden 可以选择 cloud foundry，并且仅此选择。在 BAT、华为、京东等互联网公司中，选择 docker 系的产品更多的选择了 kubernetes，或许源于此框架出自 google 大家之手

　　3. 元数据存储的框架选择：由于整个 PaaS 的元数据需要一个高可用的存储结构，以便用作服务发现或共享元数据配置的相关元数据信息。基于 zookeeper 的性能和复杂性等问题考虑，更多的选择 etcd 框架进行使用，openshift、阿里等产品均采用了此框架

　　4.PaaS 容器网络的选择：容器的网络隔离是 PaaS 资源隔离的一个重要组成部分，每个容器的网络多采用内部 SDN 网络，SDN 网络的实现技术各不相同，一般主要考虑因素是网络的性能和网络变化的灵活性等因素。开源 kubernetes 采用 flannel 框架，openshift 的产品中考虑到网络性能等采用了 open vswitch，京东在经过各种研究后采用了基于 BGP 路由方式的 Calico

　　5.CI/CD 的工具选择：随着最近几年微软对 docker 技术的支持力度加大，各种产品，比如 window server 2016、TFS 等逐渐实现对 docker 的支持。TFS(team foundation server)的产品定位与 jenkins 类似。所以在 CI/CD 的技术落地过程中可以选择 TFS 或者 jenkins，不过大家更广发的采用 jenkins，并且有研发能力的均对其进行一定程度的插件研发和定制

　　6. 日志框架的选择：在集群环境中如何管理不同节点的日志是一个重要的问题，并且目前有一套成熟的解决方案。ElasticSearch+Logstash+Kinana(ELK)已成为一种通用解决方案

　　7. 负载均衡的选择：负载均衡需要在容器集群的容器成员发生变化时能够自动感知和自动修改路由策略，硬件 F5 和软负载 HAProxy、Nginx 均可做负载均衡，鉴于 HAProxy 的灵活性，更多的产品或者企业落地均选择了 HAProxy

　　8. 域名的使用：容器集群中的某个应用可以视作一个对外提供的服务，如果采用 IP，一方面不方便记忆，一方面 IP 有可能改变，因此 PaaS 产品多采用泛域名的形式，将对外提供服务的 IP 地址和域名关联对应，然后再提供一个 route 记录对外提供服务的 IP 地址(frontend)和内部集群 IP 地址(backend)，这样就可以实现从外部域名到内部集群 IP 地址的访问。

　　PaaS 平台的建议是一个长期的过程，需要不断持续的进行迭代优化，并且随着在 PaaS 之上运行应用系统的增多和使用经验的不断丰富，对 PaaS 平台会有更多深入的认知和体会。因此我们也希望论坛上从事这块研究和实践的朋友能够更多的进行技术交流，从而加深技术了解，让 PaaS 在企业内部更好的发挥其价值和优势。