DevOps困局

开发、运维之间的“困局”很快引起了一阵DevOps风，大家都厌恶了在基础资源上的等待，厌倦了重复、枯燥的人工运维 ，为了按时交付软件产品和服务，开发人员和运营人员必须紧密合作，他们希望能够形成一套方法论，通过可编程方式来管理和控制基础架构资源，轻松、愉快地解决问题。
DevOps定义了如下明确的目标：

• 更小、更频繁的变更意味着更少的风险；
• 让开发人员更多地控制生产环境；
• 更多地以应用程序为中心来理解基础设施；
• 定义简洁明了的流程，尽可能地自动化；
• 促成开发人员与运营人员的协作；

部分开发人员转到DevOps的实现工作中，特别是全面自动化运维工具的实现工作。Chef、Puppet、Saltstack等DevOps工具陆续出现，它们有一致的中心控制-代理的应用架构，提供了一套可移植、去差异、管理成千上万台服务器的方法。但在可移植性上，必须重新定义一门抽象的语言来覆盖原各个OS平台。应用升级、文件替换、版本部署等运维操作都可以通过这门语言组合到一个模板中，从而实现复用、快速交付。开发人员被告知有越来越多的工具帮助我们快速交付，但运维工具的新语言本身又带来了复杂性。谁对这组语言模板负责，到底是开发人员还是运维人员？如果是运维人员来负责，那么仅仅做到了自动化，由于受标准化程度及运维工具本身的复杂度影响，在不同环境下的效率和收益会截然不同。而如果是开发人员负责，那么他们还需要花很长的时间去掌握一门运维“语言”来实现自动化，在模板、脚本执行过程中发生的任何问题，最终还是要辗转到运维人员处，问题貌似又回到了原点。

DevOps的十字路口

开发与运维在两条完全垂直的线路上运行工作，Dev从项目角度出发，垂直向下。Ops从运营角度笔直向前，他们的交汇处是应用版本的发布，最终的结果是一个完整可用的系统提供给用户。

IaaS 帮助有限

云计算是近年来的热点话题，实际上它仅仅是一种面向服务的理念，它将原本分散在全球各地的IT资源集中起来，通过虚拟化、分布式、多租户、自助服务、自动计费的方式递送给用户。云计算很巧妙地将服务模型划分为IaaS（基础设施即服务）、PaaS（平台即服务）、SaaS（软件即服务）。
IaaS关注基础架构中最基础的存储、计算、网络三大服务，它很好地解决了中小IaaS的出现企业对底层资源管理复杂性的问题，人们无须再购买硬件、租赁机房、管理OS。但对于解决开发、运维工作的困局是远远不够的，在存储、计算、网络之上还有支撑应用运行的各类中间件，需要将存储、计算、网络、中间件等资源绑定成一个整体，还需要对开发代码发布进行严格的安全控制。IaaS面向的用户是运维人员，PaaS面向的用户是开发人员。

IaaS帮助有限

PaaS 及时到来

PaaS将关注点从原有的基础资源上升到应用层面，它的目标是提供一个可简单操作的平台来帮助开发人员运行、管理Web应用，它的关注点围绕着开发者的可运行代码。PaaS提供一个环节给开发者创建、管理、部署应用，其收益不仅包括了IaaS原有的规模效应、固有成本，更看重的是提高代码发布的效率。在资源层面，PaaS提供底层计算、存储、网络、虚拟化、中间件等服务。在部署上，PaaS为了黏合开发、运维人员之间的关系，提供了一套自定义的部署工具，工具与企业的适用程度越高，意味着PaaS越有可能通过私有云方式提供。除了资源提供、环境部署，具体的PaaS甚至会提供团队协作、服务集成、负载均衡、安全控制、持久化、状态管理等各类型服务，随着PaaS提供的服务与代码的精密度越来越高，其对应用本身的约束也就越大。这就导致很难有一个标准的公有平台满足绝大多数企业的应用开发需求。

PaaS及时到来

PaaS for Ops

Ops每天重复性运维工作内容主要是以下四项：

1. 资源分配
   我们大部分时间在进行资源分配，将服务器、存储、操作系统以及软件等分配给应用，工作的复杂性围绕着应用而产生。
2. 应用部署
   将开发兄弟提供的业务逻辑放到我们所分配的资源中去。
3. 服务发现
   如果让用户找到这个服务，如何让服务于服务之间可以互访问。
   通常的做法有负载均衡、域名解析、配置消息中心等方式解决服务发现问题。
4. 监控巡检
   监控巡检是运维之必须，在此不再累述。
   在这里我们讨论前三项，资源分配、应用部署于服务发现。

他们依赖于基本的运维管理工具，包括配置管理系统CMDB、监控管理系统以及标准的ITIL流程管理。

Ops全局工作图

既然说PaaS要彻底地填补开发、运维工作之间的沟壑，让开发的全部精力聚焦到业务逻辑上，那么我们有必要让PaaS解决的问题具体化。

1. PaaS提供的是一个应用的聚合，这里包含了功能各异的服务组件

• 应用服务中间件：直接包含业务逻辑代码、模块的中间件容器，提供数据库连接池、事务控制等接口以掩盖后端的复杂性。
• 数据存储服务：业务数据的存储区域通过标准的数据存储协议如文档型、SQL、key-value等交互。
• 消息服务：为了对应用组件间进行解耦，常常需要支持点对点、发布-订阅的消息服务。

2. PaaS要提供服务发现、可伸缩性、状态管理功能

• 服务发现：组件与组件之间如何查找、发现对方，如何将最新的地址信息通知到应用聚合，如何对外暴露统一的访问点，这是PaaS要考虑的一个功能点，具体的实现包括可编程的DNS服务器及IP注册分配器。
• 可伸缩性：涉及如何快速地对应用进行扩容，组件如何依据类型请求负载的分配，以及分配的基本机制。
• 状态管理：对于可快速复制、易扩容的组件，如何管理它们的会话状态。

3. PaaS中的服务监控、恢复与容灾
   对于应用聚合中的每一个组件，如何做到简单、自定义地监控，并且在服务异常时启动服务的快速恢复功能。容灾指跨数据中心的平台级故障恢复，涉及两个数据中心之间的逻辑计算单元如何保持通信，如何保持唯一性，业务数据如何进行备份。
4. PaaS的Portal门户
   PaaS提供了一个对用户友好的Portal，可以基于UI进行应用资源的聚合，并且可以快速地查找到配置信息、计费信息。
5. ITIL服务管理的相关内容
   在云计算之前，许多大中型企业的IT管理方式是基于ITIL管理方法论的，它们制订了一些适用于业务与IT服务稳定而快速交付的具体流程、工具和方法，但随着云平台、PaaS的出现，ITIL是否就没有必要存在了呢？笔者认为对于金融、保险行业生产环境的服务，如果能够将ITIL管理中的控制规则同样通过自定义的方式集成到PaaS平台，那么将会提高服务的可用性。
6. PaaS平台的安全管控
   PaaS平台的安全管控包括三方面：PaaS平台的组成组件自身的安全控制；PaaS中提供的服务的安全控制；PaaS对外部提供服务的统一出口的安全控制。
7. 部署发布的相关内容
   最后开发的代码如何通过工具自动、快速地发布到平台也是要考虑的，这部分与开发过程相关，包括代码单元测试、集成测试、打包、版本控制、部署等。

PaaS平台功能设计

为了能够实现PaaS平台，我们需要保证运维的四个主要工作内容实现自动化，下面这些功能全都是围绕着实现这个目标而引入的。

1. 计算单元
   虚拟机镜像、配置管理工具（puppet、saltstack、ansible）所负责的任务就是将应用逻辑计算单元进行打包。计算单元包含了运行业务系统的全栈组件，其涵盖了操作系统、中间件、依赖包等。PaaS平台中我们选择Docker替换原有的方式，作为一个轻量级容器，它比虚拟机更加节约资源，同时可以基于一份软件介质运行多个实例，Docker的仓库、镜像与容器三元素让应用逻辑计算单元大大得到了简化。诚然，ansible这类软件配置工具已经非常轻巧、快捷，并且满足95%以上的需求，但当决定将PaaS构建在跨IDC、跨第三方数据中心时，基于镜像的分发能够更加稳定的满足我们需求。Docker也有其缺点，例如不支持32位平台，不支持windows服务器。
   计算单元, 容器化替代虚拟机+软件配置
2. 资源分配
   与Cloud2.0的IaaS不同，用户并不关注如何获得CPU、内存、存储资源。他们仅关注自身应用计算逻辑的运行，他们希望资源是动态分配、弹性扩容的。数据中心需要一个统一的资源管理者，它将所有资源（无论虚拟、物理）抽象成一个整体，如同一个数据中心操作系统，这种资源的抽象不仅仅要满足服务型计算，还要满足大数据时代的MapReduce计算，以及今后的各种类型计算，这意味着资源分配与任务调度两部分功能是解耦的。
   在分布式资源管理领域，主流的选择是Mesos、YARN
   Mesos：Mesos最早由美国加州大学伯克利分校AMPLab实验室开发，后在Twitter、Apple、Netflix等互联网企业广泛使用，成熟度高。
   YARN：Apache Hadoop YARN一种新的 Hadoop 资源管理器，它是一个通用资源管理系统，可为上层应用提供统一的资源管理和调度。
   其他的选择还有Kubernetes、CloudFoundry、OpenShift等方案，但这几种不满足资源分配与任务调度解耦，对应用规则要求太高，并不容易兼容现有应用。在我们环境选择了Mesos，其独有的灵活性保证了支持更多类型的上层分布式计算应用。
   Mesos资源管理是符合兼容性的最佳选择
3. 任务调度
   任务调度器与资源管理器的最大不同在于其要对运行中的应用服务负责，包括启动、停止服务，监控服务以及在服务失效时故障转移。最初的分布式架构设计中，人们常常模糊了作业调度与资源管理二者间的界线，其一是分布式平台是为某一专属计算类型服务，例如Hadoop平台为MapReduce计算类型服务。其二，作业调度与资源管理的交互频度高，合二为一后的效率更高。但随后人们发现资源管理器的功能是相对稳定的，而作业调度因为计算类型多，并行计算有MapReduce、Stream，普通计算有Service、批处理等，每一种计算类型的作业调度方式完全不同，如果将资源管理器与作业调度器绑定在一起则会失去分布式平台的计算灵活性。
   是以Mesos为核心，支持多领域的分布式集群调度框架，包括Docker容器集群调度框架Marathon、分布式 Cron（周期性执行任务）集群调度框架Chronos和大数据的主流平台Hadoop和Spark的集群调度框架等，实现系统的资源弹性调度。
   Marathon到目前为止是最灵活的长服务任务调度框架
4. 服务发现
   服务发现有两种形态，一种是用户（人）来访问的，一种是应用之间互调的，对于前者需要保持一个稳定的入口（不变），而对于后者，如果在一个宽松的环境里，是运行变化，并接受变化通知的。而对于长服务型计算类型，除了解决服务发现外，还要考虑将任务分发到多个节点，亦即负载均衡问题。
   服务发现上可选的有通过动态写入DNS系统来满足用户需求，通过zookeeper之类的分布式协调系统充当配置中心通知外部系统。而在负载均衡上，企业级的专用设备，例如F5等都提供了API接口以供调用，而开源软件上通常采用Haproxy。
   服务发现的组件选择
5. 工作流程
   Mesos+Marathon+Docker的工作流程
   通过zookeeper实现服务发现流程

关于PaaS的架构设计以及实现细节可参考如下著作：

PaaS实现与运维管理.png

TO PaaS for Dev

开发人员的主要工作 容器化dockerfile与Jenkins集成发布是必备武器.png